優れたプロジェクトマネージャーにはプログラミングの知識が必要ですか？
場合によっては、プロジェクトマネージャーからさまざまなタスクの完了までの時間を見積もるように依頼されたときに、我慢できないことがあります。見積もりは推測であり、推測は間違っている可能性があります。一般に、要件とドキュメントが不適切だと、推測が悪くなります。
そのため、プロジェクトマネージャーが、XとYのタスクにかかる時間と、クライアントからほとんどわかっていないものに基づいて番号を割り当てるのがどれほど難しいかを推測しようとしているのではないかとよく思います。
私の質問は次のとおりです：優れたプロジェクトマネージャーにはプログラミングの知識が必要ですか？
または、問題は多分優れたプロジェクトマネージャーは以前に良いプログラマであった必要がありますか？相関関係はありますか？
ITプロジェクトの管理は、他のタイプのプロジェクトの管理とは明らかに異なります。 no ITの経験を持つプロジェクトマネージャーの話を聞いたことがある。彼は結局プログラマーを苛立たせ、基本的に彼らを怖がらせていました。
一方、プロジェクトマネージャーになったプログラマーは、コントロールフリークになり、プログラマーに適切に実行させることができない場合に修正できると考えます（同様の状況で私の問題でした）。
強い技術的背景を持つマネージャーは、通常、チームが「考える」方法をよりよく理解しています。あなたを理解できるマネージャーがいるほうがいいですよね。
いいえ。2つのまったく異なるスキル。悪いプロジェクトマネージャーは、必ずしもITを理解していない人であるとは限りません。逆もまた同様です。
合理的、合理的、組織的であり、プロジェクトの目標とそれに関連するビジネスを理解していること、および優れた動機付けは、プログラムを作成できることにまったく依存していません。
それ以外はすべて同等であり、強力なp-to-dateの技術経験を持つプロジェクトマネージャーを希望します。ただし、現実の世界では、フルタイムのプロジェクト管理を卒業するプログラマーは、スキルセットが古くて時代遅れになる可能性が高く、これは技術的なバックグラウンドがない場合よりもはるかに優れています。
私は優れたプロジェクトマネージャーとひどいプロジェクトマネージャーと協力してきました。正直に言って、彼らの管理能力と技術的背景の間にほとんど相関関係が見られなかったと言えます。最も重要な要素は、技術的な背景ではありませんが、ソフトウェアプロジェクトを管理した経験の程度です。 2人が最初のプロジェクトを管理している場合、プロジェクト管理を卒業するプログラマーは、ITのバックグラウンドがないプロジェクトマネージャーと同じくらい悪い人になるでしょう。どちらも急な学習プロセスを経ます。
技術的背景のないプロジェクトマネージャーの能力についての議論は、私にこれを少し思い出させます：
A PMは、プロジェクトが何を行うかを本当に知る必要があります。これには、技術的な背景が必要ですが、開発は必要ありません。
それ以外は、実際の知識よりも、フィールドと開発者を尊重することです。 A PMは、開発者を真剣に受け止める必要があります。必要なもの、できること、できないこと、どれだけの時間がかかりますか。A PM彼または彼女が知らないことについて何らかのアイデアを持っている人は非常に効果的です。APM彼または彼女がすべての答えを持っていると思う人は悪いです。これは彼を信じている元開発者かもしれませんまたは、彼女はすべてを知っていて、知らないか、開発したことがなく、管理するために特別な技術的知識が必要だとは思っていません。
正直、答えはノーだと思います。優れたプロジェクトマネージャーになるために必要な能力のすべての手荷物があり、プログラマーであることはそれらの1つではありません。優れたプロジェクトマネージャーは、プロジェクトチームに何をしているのかを知っている優秀な人がいれば、あらゆるタイプのプロジェクトを管理できます。プロジェクトマネージャーが持つべき主な品質はコミュニケーションスキルです。プロジェクトマネージャーの仕事は、プロジェクトのタスクを調整し、顧客、プロジェクトチーム、およびその他の利害関係者の間のコミュニケーションを維持することです。チームの進捗状況と障害が発生しているかどうかを常に知っている必要がありますが、問題が何であるか、または何を修正する必要があるかを知る必要はありません。問題を修正するために調整する必要があります。
見積もりを与えることに関しては、それはどんな仕事でも人生の現実です。電気技師が配線を行うのにどれくらいの時間がかかるかわからなければ、時間通りに家を建てることはできません。壁の男を予約するのはいつでしょうか。非常に多くの不可解なものがあるため、ITで見積もりを出すのは本当に難しいと私は同意します。顧客は常に自分が何を望んでいるかを知っているわけではなく、たくさんのことをあなたに伝えるのを忘れがちです。私がやっていたことは、だいたいどれぐらいの時間がかかるとおおよそだと推定して、それを2倍することです！そして、優れたプログラムマネージャーは、見積もりが間違っていることがわかったときにあなたを十字架にかけるべきではありません。スケジュールを再編成したり、顧客と話し合ったり、コストが高くなることを上司に説明したりするなど、いくつかの頭痛の種になります。それは彼らの仕事の一部です-繰り返しますが、良いコミュニケーションスキルはほとんどが必要とされるものです。
そして、私はプログラミングスキルがない方がより良い-元プログラマーが自分で見積もりをしようとするか、またはあなたの見積もりを推測するかもしれません。そして私たちは皆、ITスキルが非常に早く時代遅れになることを知っています。プロジェクトマネージャーが、タスクの所要時間や完了時間よりも、タスクの実行方法に関心を持っている場合は、質問を開始する必要があります。彼らは代替案を評価して詳細をハッシュ化するようにあなたに頼むかもしれませんが、主なポイントはあなたがプロジェクトのスケジュールにどのように影響するかを知ることです。
最後に、私はITプロジェクトを管理するためにITスキルが必要であると言っているわけではありません。ITの人々は、一般の人々（！）に対して言っていることを単に下品にできないように見えるタイプなので、それを知るのに役立ちますそれらと通信できるようにするための基本的な専門用語！また基本的な手順を知ることは重要です-Webサイトを実行する前にサーバーを設定する必要があります。壁を閉じる前に電気技師が配線を終えなければならないことを知らなかった場合、私は建設プロジェクトを管理することができませんでした!!
私は彼らがプログラミングの背景を必要としていると思います。そうでない場合、彼らは常にプログラマーにプレッシャーをかけ、タスクを迅速に行い、実際にタスクが多くの思考と献身を必要とする数時間以内に完了すると期待します。これらの資質は既知であり、プログラマーに精通しているため、プロジェクトマネージャーがプログラミングのバックグラウンドを持っている場合は、特定のタスクにかかる時間を理解し、部門内で議論がないため、最終的には優れたプロジェクトが進展します。
ITプロジェクトのプロジェクトマネージャーは思いません必須 ITの背景。しかし、彼/彼女は間違いなくITを理解する必要があり、ITプロジェクトの仕組みを知っている必要があります。
ITのバックグラウンドは追加の利点ですが、それがなくてもITプロジェクトマネージャーがそれほど良くないわけではありません。また、ITの背景を持つことも決定的な要因ではありません。
私は両方のタイプを扱ってきましたが、それぞれに独自の品質と問題のセットがありました。
ITバックラウンドの場合：
-コードがマルチスレッド化されていないため、パフォーマンスエラーと言えば理解できます
-しかし、状況によっては、「ちょっと待ってください。4行のコードを追加するだけで、10日で実行できます」
ITの背景なし：
-期限を変更するための交渉が快適にできると思います
-要件がまったくない（まだ）プロジェクトの場合、「100日のおおよその見積もりを示し、30％のバッファについて言及できますか。
私の経験では、経営陣は効果的なコミュニケーションと意思決定についてです。それを念頭に置いて、彼らが管理する人々によって利用される工芸品（少なくともコアコンセプトと用語）を理解する人は、理解度の低い人よりもマネージャーになるのに適していますが、間違いなく相関関係はありません。プログラミングの経験があるマネージャーも、プログラミングの経験がないマネージャーと同じくらい頻繁に成功したり失敗したりしました。
私の意見では、どちらの極端も悪いです。プログラミングの経験が少なすぎる人は、自分のプログラマ（羊に続く羊飼い）を盲目的に信頼することができます。経験が多すぎると、チームの取り組み（マイクロ管理）に継続的に疑問を呈する可能性があります。
個人的には、プログラミングのコアコンセプトはよく理解しているが、「ホットショット」ではないことに気付いている人は、理想的なマネージャーです。
ITの経験がなく、つまらないソフトウェア開発プロジェクトを管理できるプロジェクトマネージャーを見たことがない。私は非常に少数のプロジェクトマネージャーwithのどちらかがそれを行うことができるITの経験を見たことがありますが、彼らはそれを台無しにしないようでした。
@NimChimpsky同意する。
それはwhatの問題であり、方法ではありません（アクティブリスニングは素晴らしいツールです）。
見積もりは小さな技術的なタスクで機能しますが、計画では複雑さ全体を確認するために一緒に作業する必要があります。そして、あなたはライバルではありません。
特に彼らが優れたプロジェクトマネージャーでない場合、それは間違いなく役立ちます。優れたプロジェクトマネージャーにとって、それは本当に重要です。
番号。
優れたプロジェクトマネージャーは、建設現場、製造現場、ソフトウェア開発会社など、チームのニーズ、好み、機能について共感し、理解できる人です。
良いまたは悪いプロジェクトマネージャーは、あらゆる種類の背景を持つことができます。
技術的な背景を持つ悪いマネージャーは、ポインターのような平凡で「簡単な」概念を扱うときに初心者が直面する困難を理解していないエースプログラマであった可能性があります。
優れたマネージャーは、同僚ほど優秀でも賢いわけでもないが、プロジェクトの構造や要件を深く理解していて、The Mythical Man Monthのレッスンを暗記している平均的なプログラマーである可能性がありますlived悪いコーディングの日数は自分自身であり、成果物を予定どおりに完了しなかったために噛み砕かれました。
良いマネージャーは、彼自身がクライアントに与えた非現実的な約束のために、彼のコーダーの友達が週末に彼と一緒に出かけることができないことを知ったそのソフトウェアセールスの男かもしれません。
技術的な知識は、プログラマーのマネージャーとしての資格を事前に決定するものではありません。これは、両方のジョブで必要なスキルセットがまったく異なるためです。いいえ。
間違いなく。
これは実話に基づいているので注意が必要ですが、私の苦痛を説明しようと思います。
私はソフトウェアエンジニアとして働いており、最近一緒に作業しているプロジェクトマネージャーがいます。彼には技術的な背景がなく、まったく興味がないようですが、それは問題ではありません（誰もが自分の興味を持っています）。あなたが技術的なノウハウを持ちたくない場合、それはあなたのものよりも「奇妙」ですが、技術的なレベルで顧客と話すことがあなたの仕事である場合、彼が持っていない技術的な知識を持つことが不可欠です。持ってる。
とにかく、この男はサーバーの仕組み、Webページの仕組み、プログラミングの仕組みなどについて何も理解していません。時々、彼は何も知らないような気がします。ですから、私が彼に今私たちがしなければならないこと、または彼が何も理解していない現時点で私たちが抱えている問題が何であるかを明確にしようとするたびに。そして、彼は「ちょっと待って。私が本当にそれがよくわからないことを繰り返してもらえますか」というような人ではありません。いいえ、彼は会話の中で何も理解していなかったことを見せたくない種類の人です。
しかし、それがここで終わるわけではないので、彼は顧客に電話して、基本的に真実ではないことを話します。そして、それを明確にするためにお客様に電話をかけなければならないということになります。
だからこそ、いくつかの基本的な技術的背景と技術的ノウハウが不可欠であると私は言います。彼はコードを書くことはできないはずですが、何が起こっているのか、どのようなプロセスを実行する必要があるのかを理解できるはずです。
ところで私は彼と一緒に仕事をしているので、私の仕事はもう楽しくありません。
はい、彼はプログラミングの知識が必要です。マネージャーがプログラムするのがどのようなものかについての手がかりがない場合、マネージャーは開発とバグ修正について非現実的な見積もりを出すことになります。また、技術的な問題を十分に理解していないため、決定を下すことはできませんでした。チームのプログラマーは彼に嘘をつく可能性があり、彼は気付かない可能性があり、またプログラマーは彼に問題を伝える可能性があり、彼は彼らが周りででたらめであると思うかもしれません
技術的なスキルは優れたマネージャーにはなりませんが、優れた管理スキルは優れています。素人ができないプロセスを理解することができるので、マネージャーが「塹壕」で時間を費やした場合、それは役に立ちます。ただし、これは、コントロールフリークの素人のマネージャーでさえ実現できない、ある種のコントロールフリークをもたらす可能性もあります。彼らは自分ですべての仕事をしようとするか、非常に不快な方法であなたの仕事を精査しようとするかもしれません。
私の個人的な経験では、私が今まで持っていた最高のマネージャーはテクノロジーについてかなり無知でしたが、彼の下で働いている人々は彼らのことを知っていて、彼のチームの忠誠心と尊敬を得る方法を知っていました。私は彼の下で4年間働いていましたが、会社を辞めたのは、彼が辞任し、それほど良くないマネージャーに置き換えられたからです。
私がこれまでに経験した最悪のマネージャーの1人は、コーディング（ソフトウェアデザインでない場合）に精通しており、多くの作業を自分で行っているため、スクラップ、バグ修正、または不要なプロジェクトだけで残りの部分を残しています。自分でやる。
いくつかの混乱があるようです：
PMは開発者の上司ではありません。開発チームの責任者（チームリーダー、マネージャー）と採用を行い、評価を行う人は、十分頑張ってください。
見積もりは完璧ではありません。 PMはあなたが思っている以上にこれを理解していると思います。誰かが何かをするのにどれくらい時間がかかるか尋ねる人はいないと真剣に期待していますか？誰もがそれがいつ完了したかを知りたいので、それを追跡するのは首相の仕事です。
PM is you：A）プロジェクトの管理方法を理解するB）開発プロセスを理解するこれらはどちらもコーディングの知識は必要ありませんが、役立つ場合があります。
プログラマーが十分な成果を上げているかどうかを判断することは、PMがチームリーダーを兼任しない限り、PMの仕事ではありません。タスクを完了する時間について誰かが「煙を吹いている」かどうかを知るために、マネージャーは、何が関係しているかを理解していれば常に有利です。
見積もりは、特定のタイプのプロジェクトでの作業の履歴を持つ経験豊富なプログラマーと相性が良くなります。それらが完璧であるとは誰も期待していませんが、彼らはあなたが近づき、時間とともに良くなることを期待しています。
「ここで働くのに夢中になる必要はありませんが、役に立ちます」という古い格言を思い出します。
簡単に言えば、実践的なコーディング経験は優れたソフトウェアPMの必須条件ではありませんが、通常は推奨されます。有能であるために重要なことPMは、開発プロセス（使用されている方法論は何でも）を理解し、開発者が進んで自分の仕事を実行できることを信頼することです。開発経験は実践的なものです。そのプロセスの知識は、それゆえに役立ちます。会社のはしごを上に向かって進むPMは、企業文化（およびコードベース）をさらに知っており、開発チームの他の長期奉仕メンバーと親密な関係を持っています。 IMO最高のPMは、外部から持ち込まれるのではなく、内部から昇格されます。社内の誰かよりも社外の誰かがチームを上手に管理できる場合、事態は非常に良くありません。
私が言及した1つのことは、PMと開発チームの間の親密さです。これは対人レベルと技術レベルの両方です。ここでの鍵はコミュニケーションです。開発者は問題をもたらす可能性があると感じている必要があります。技術的および対人関係で、PMとPM=は、開発チームのメンバーが問題を説明するときに理解する必要があります。
あなたの質問の具体的な性質に関して、見積もりはまさにそれです。量に関する知識に基づく推測（将来のイベントの結果のより一般的な予測である仮説とは対照的）。マネージャは通常、最近の推定値と実際のタイムラインに基づいて、数学的にまたは直感的に何らかの修飾子を適用します。アジャイルはこれを推定プロセスに組み込みます。クライアントは要件の複雑さを直感的に推定し、開発者も同じことを行い、開発者は実際に出てソリューションを開発し、マネージャーデータポイントに、要件ポイントと開発ポイントの比率、および開発ポイントと人間の比率を計算させます。時間の要件。
つまり、マネージャーは次の3つのシナリオのいずれかで額面価格でのみ見積もりを取得します。
- 過去の同様のタスクの見積もりはかなり正確でした。
- 彼は配達を迫られており、あなたの見積もりは彼が思っていたよりも優れています。
- 彼はあなたを解雇する理由を探しています。
それがその最後の状況である場合、多分あなたは地獄を脱出する必要があるかもしれない他の多くの手がかりが職場の周りにあります。