優秀なプロジェクトマネージャーにはプログラミングのバックグラウンドが必要ですか？[閉まっている]

プロジェクトマネージャーがさまざまなタスクを完了するための時間を見積もるように求めたときに、我慢できないことがあります。推定は推測であり、推測は間違っている可能性があります。一般に、要件とドキュメントが適切でないと、推測が誤ってしまいます。

ですから、プロジェクトマネージャーが、XとYのタスクにかかる時間と、クライアントからほとんど知られていないものや収集したものに基づいて番号を割り当てるのがどれだけ難しいかを推測しようとしていたのではないかとよく疑問に思います。

私の質問は次のとおりです。優れたプロジェクトマネージャーにはプログラミングの背景が必要ですか？

あるいは、問題は、優れたプロジェクトマネージャーが以前は優れたプログラマーであった必要があるということでしょうか？ 相関関係はありますか？

ITプロジェクトを管理することは、他の種類のプロジェクトを管理することとまったく同じではありません。ITの経験がないプロジェクトマネージャーのことを聞いたことがあります。彼は結局プログラマーを失望させ、基本的に彼らを追い払った。

一方、プロジェクトマネージャーになるプログラマーはコントロールフリークになる可能性があり、プログラマーが適切にそれを行うことができない場合（それは同様の状況で私の問題でした）

強い技術的背景を持つマネージャーは、通常、チームがどのように「考える」かをよく理解しています。あなたのことを理解しているマネージャーがいる方がずっと良いですよね？

いいえ。2つのまったく異なるスキル。悪いプロジェクトマネージャーは、必ずしもITを理解していない人であるとは限りません。

合理的、合理的、組織化され、プロジェクトの目標と関連するビジネスを理解し、良い動機付けをすることは、プログラムを作成できるかどうかにまったく依存しません。

他のすべてが同じであれば、私は強力で最新の技術経験を持つプロジェクトマネージャーを好みます。しかし、現実の世界では、フルタイムのプロジェクト管理を卒業したプログラマーは、スキルセットが古くなり、時代遅れになる可能性が高くなります。

私は優れたプロジェクトマネージャーといくつかのひどいプロジェクトマネージャーと仕事をしてきましたが、正直に言って、私は彼らの管理能力と彼らの技術的背景との間に相関関係がほとんど見られなかったと言えます。最も重要な要因は技術的背景ではなく、ソフトウェアプロジェクトの管理経験です。2人で最初のプロジェクトを管理している場合、プロジェクト管理を卒業するプログラマーは、ITのバックグラウンドを持たないプロジェクトマネージャーと同じくらい悪くなります。両方とも急な学習プロセスを経る予定です。

技術的背景のないプロジェクトマネージャーの能力をめぐる議論は、このことを少し思い出させます。

私は正直に答えはノーだと思います。優れたプロジェクトマネージャーになるために必要な能力はすべてありますが、プログラマーであることはそれらの1つではありません。優れたプロジェクトマネージャーは、プロジェクトチームに自分が何をしているかを知っている優秀な人がいることを考えると、あらゆる種類のプロジェクトを管理できます。プロジェクトマネージャーが持つべき主要な品質はコミュニケーションスキルです。プロジェクトマネージャーの仕事は、プロジェクトのタスクを調整し、顧客、プロジェクトチーム、その他の利害関係者の間でコミュニケーションを維持することです。チームの進捗状況とロードブロッキングが発生しているかどうかを常に把握している必要がありますが、チームの他の人が時間に影響を与えない限り、問題の内容や修正の必要性を知る必要はありません問題を修正するために調整する必要があります。

見積もりを与えることに関しては、それはどんな仕事でも人生の現実です。電気技師が配線にどれくらいの時間がかかるかをあなたに伝えることができなければ、時間通りに家を建てることはできませんでした。しかし、多数の不可思議な要素があるため、IT部門で見積もりを出すのは非常に難しいことに同意します。顧客は自分が何を望んでいるのかを常に知っているわけではなく、多くのことを言うのを忘れがちです。私がやったことは、だいたいどれくらいの時間がかかると思ったのかを概算して、それを2倍することです！優れたプログラムマネージャーは、見積もりが間違っていることが判明した場合に十字架につけるべきではありません。それは彼らの仕事の一部です-再び、 ほとんどが必要なものです。

また、プログラミングスキルを持たない方がさらに良いと言えます。元プログラマーが自分で見積もりをしようとする場合もありますし、見積もりを推測する場合もあります。そして、ITスキルが急速に時代遅れになることは誰もが知っています。プロジェクトマネージャーがタスクの所要時間や完了時期よりも、タスクの実行方法に関心がある場合、質問を開始する必要があります。彼らはあなたに代替案を評価し、詳細をハッシュ化するように頼むことができますが、主なポイントはあなたがプロジェクトのスケジュールにどのように影響するかを知ることです。

最後に、ITプロジェクトを管理するのにITスキルは必要ない、と言っているわけではありません。それらと通信できるようにするための基本的な専門用語！また、基本的な手順を理解することも重要です。Webサイトを実行する前にサーバーをセットアップする必要があります。壁を閉じる前に電気技師が配線を終えなければならないことを知らなければ、建設プロジェクトを管理できませんでした!!

PMはプロジェクトが何をするのかを本当に知る必要があります。これはおそらく技術的な背景を必要としますが、開発はしません。

それ以外は、実際の知識よりも、フィールドと開発者を尊重することです。PMは、開発者を真剣に考える必要があります。必要なもの、できること、できないこと、どれだけ時間がかかるか。自分が知らないことを知っているPMは非常に効果的です。彼または彼女がすべての答えを持っていると思うPMは悪いです。これは、自分がすべてを知っていて知らないと信じている元開発者、または管理するために特別な技術知識を必要としないと開発したことがある元開発者の場合があります。

ITプロジェクトのプロジェクトマネージャーがITのバックグラウンドを必要とするとは思わない。しかし、彼/彼女は間違いなくITを理解しなければならず、ITプロジェクトがどのように機能するかを知っている必要があります。

ITのバックグラウンドは追加の利点ですが、そのバックグラウンドがないからといってITプロジェクトマネージャーはそれほど良くありません。また、ITのバックグラウンドを持つことが決定的な要因ではありません。

私は両方のタイプを扱ってきましたが、それぞれに独自の品質と問題がありました。

ITバックラウンドの場合：
-コードがマルチスレッドではないため、パフォーマンスエラーを言うときは理解します
-しかし、状況によっては、「さあ、4行のコードを追加するだけで、10日でできる」と言うでしょう。

ITのバックグラウンドがない場合：
-納期を変更するための交渉は非常に快適です-
要件のない（まだ）プロジェクトの場合、「100日間の大まかな見積もりを与え、30％のバッファーについて言及できますか？」

プログラミングのバックグラウンドが必要だと思います。そうでない場合、彼らは常にプログラマにタスクを迅速に圧力をかけ、実際にタスクが多くの思考と献身を必要とする数時間以内にそれが行われることを期待します。これらの品質はプログラマーに周知であり、プログラマーに精通しているため、プロジェクトマネージャーがプログラミングのバックグラウンドを持っている場合、特定のタスクにかかる時間を理解し、部門内で議論がなくなるため、最終的には良いプロジェクトが発展します。

@NimChimpsky同意します。

方法ではなく、何が問題になります（アクティブリスニングは優れたツールです）。

見積もりは小さな技術的なタスクで機能しますが、計画を立てる際には、全体の複雑さを確認するために協力する必要があります。そして、あなたはライバルではありません。

特に優れたプロジェクトマネージャーでない場合、特に役立ちます。優れたプロジェクトマネージャーにとって、それは本当に重要です。

いや

優れたプロジェクトマネージャーとは、建設現場、製造現場、ソフトウェア開発会社など、チームのニーズ、好み、能力が何であるかを共感して理解できる人です。

良いまたは悪いプロジェクトマネージャーは、あらゆる種類の背景を持つことができます。

技術的なバックグラウンドを持つ悪いマネージャーは、ポインターのようなありふれた「簡単な」概念を扱う際に初心者が直面する困難を理解しないエースのプログラマーかもしれません。

優れたマネージャーとは、同僚ほど優秀でも賢くもないが、プロジェクトの構造や要件を深く理解し、コーディングの日々が悪かったためにThe Mythical Man Monthの教訓を心から理解していた平均的なプログラマーのことです。時間通りに成果物を完成させなかったために噛み付いた。

優れたマネージャーは、彼自身がクライアントに与えた非現実的な約束のために、彼のコーダーの友人が週末に彼と一緒に出かけることができないことを知ったソフトウェア販売員かもしれません。

両方のジョブに必要なスキルセットはまったく異なるため、技術的知識はマネージャーとしてのプログラマーの資格を事前に決定しません。だから

ITの経験のないプロジェクトマネージャーが、非常に価値のある重要なソフトウェア開発プロジェクトを管理できるのを見たことはありません。ITの経験があり、それを行うことができるプロジェクトマネージャーはほとんどいませんでしたが、それを台無しにすることは少ないようです。

私の経験では、管理とは効果的なコミュニケーションと意思決定に関するものです。それを念頭に置いて、管理する人々が利用する工芸品（少なくともコアの概念と用語）を理解している人は、あまり理解していない人よりもマネージャーになるのに適していますが、相関関係なし。プログラミング経験のないマネージャーと同じくらい頻繁に、プログラミング経験のあるマネージャーが成功したり失敗したりするのを見てきました。

私の意見では、どちらの極端でも悪いです。プログラミングの経験が少なすぎる人は、プログラマーを盲目的に信頼することができます（羊を追うシェパード）。経験が多すぎる人は、チームの努力に継続的に疑問を抱くことができます（マイクロ管理）。

個人的には、コアプログラミングの概念をよく理解しているが、それらが「ホットショット」ではないことに気付いている人は、理想的な種類のマネージャーだと思います。

間違いなく。

実話に基づいているため、この1つの原因に注意する必要がありますが、私の痛みを説明しようとします。

私はソフトウェアエンジニアとして働いており、最近プロジェクトマネージャーがいます。彼には技術的なバックグラウンドはなく、まったく興味がないようですが、それは問題ではありません（誰もが自分の興味を持っています）。技術的なノウハウを持ちたくない場合、それはあなたよりもちょっと「おかしい」ですが、技術レベルで顧客と話をするのがあなたの仕事であれば、彼が持っていない技術的な知識を持つことが不可欠です持ってる。

とにかく、この男がいて、サーバーの仕組み、Webページの仕組み、プログラミングの仕組みなどについて何も理解していません。時々、彼は何も知らないように感じます。だから、私は彼に今何をしなければならないのか、あるいは何が問題なのかを彼にはっきりさせようとするたびに、彼は何も理解していない。そして、彼は「ちょっと待ってください。私が本当にそれをよく理解していないということを繰り返してください」と言うような人ではありません。いいえ、彼は彼が会話全体で何も理解していないことを見せたくないような人です。

しかし、ここで終了するわけではありません。彼が顧客に電話し、基本的に真実ではないことを話します。そして、それを再び明確にするために顧客と一緒に電話をしなければならないということです。

だからこそ、いくつかの基本的な技術的背景と技術的ノウハウを持つことが本当に不可欠だと言っています。彼はコードを書くことはできませんが、何が起こっているのか、どのプロセスを行う必要があるのか​​を理解できるはずです。

ところで、私は彼と仕事をしているので、私の仕事はもう面白くありません。

はい、彼にはプログラミングのバックグラウンドがあるはずです。マネージャーがプログラミングをどのようなものであるかについての手がかりを持たない場合、彼は開発とバグ修正のための非現実的な見積もりになります。また、決定を下すほど技術的な問題を十分に理解していません。チームのプログラマーは彼にうそをつくことがあり、彼は気づかないかもしれません。

技術的なスキルは優れたマネージャーにはなりませんが、優れた管理スキルにはなります。マネージャーが「トレンチ」で時間を過ごした場合、素人にはできないプロセスを理解できるので便利です。しかし、それはまた、異常な素人のマネージャーでさえも制御できない一種の制御異常を引き起こす可能性があります。彼らはすべての仕事を自分でやろうとしたり、非常に不快な方法であなたの仕事を精査しようとするかもしれません。

私の個人的な経験では、私がこれまでに持っていた最高のマネージャーはテクノロジーについてかなり無知でしたが、彼の下で働く人々は自分のものを知っていて、彼のチームの忠誠心と尊敬を得る方法を知っていました。私は彼の下で4年間働きましたが、会社を去ったのは彼が去り、あまり良くないマネージャーに置き換えられたからです。

私が持っていた最悪のマネージャーの1人はコーディングに精通しており（ソフトウェア設計ではない場合）、自分自身で多くの作業を行っているため、私たちの残りの部分にはスクラップ、バグ修正、または望まないプロジェクト以上のものがありません自分でやる。

混乱があるようです：

PMは開発者のボスではありません。開発チーム（チームリーダー、マネージャー）の責任者であり、雇用と評価を行う人は、あなたが十分に努力しているかどうかを判断する必要があります。

推定は完全ではありません。PMはあなたが思っている以上にこれを理解していると思います。誰かが何かをするのにどれくらいの時間がかかるかと尋ねる人はいないと真剣に思っていますか？Everyboyは、それがいつ完了したかを知りたいと思っており、それを追跡するのはPMの仕事です。

あなたはPMになれます：A）プロジェクトの管理方法を理解するB）開発プロセスを理解する これらはどちらもコーディングの知識を必要としませんが、役立ちます。

プログラマが十分な成果を上げているかどうかを判断することは、チームリーダーを兼ねない限り、PMの仕事ではありません。誰かがタスクを完了する時間について「煙を吹いている」かどうかを知るために、マネージャーは、何が関係しているかを理解していれば、常に有利になります。

特定のタイプのプロジェクトに携わった経験がある経験豊富なプログラマーの方が見積もりが良くなります。それらが完璧であることを誰も期待していませんが、彼らはあなたが近くに来て、時間の経過とともに良くなることを期待しています。

「ここで働くのに夢中になる必要はないが、助けになる」という古いことわざを思い出します。

簡単な答えは、実践的なコーディングエクスペリエンスは優れたソフトウェアPMの必須条件ではありませんが、通常は望ましいことです。有能なPMになるために重要なのは、開発プロセス（どの方法論を使用する場合でも）を理解し、開発者が自分の仕事を進んで行うことができることを信頼することです。開発経験は、そのプロセスの実践的な知識を提供するため、役立ちます。会社のはしごを登っているPMは、企業文化（およびコードベース）をさらに知っており、開発チームの他の長年のメンバーと関係を持っています。外から持ち込まれることの 社外の人が社内の人よりもチームをうまく管理できる場合、事態は非常に間違っています。

私が言及したことの1つは、PMチームと開発チームの関係です。これは対人レベルと技術レベルの両方です。ここで重要なのはコミュニケーションです。開発者は技術的および個人的な問題をPMにもたらすことができると感じ、PMは問題を説明するときに開発チームのメンバーを理解する必要があります。

あなたの質問の特定の性質に関して、推定はまさにそれです。量に関する知識に基づいた推測（将来のイベントの結果のより一般的な予測である仮説とは対照的に）。通常、マネージャーは、最近の推定値と実際のタイムラインに基づいて、数学的にまたは直感的に何らかの修飾子を適用します。アジャイルはこれを推定プロセスに組み込みます。クライアントは要件の複雑さを直観的に推定し、開発者も同じことを行い、開発者は実際にソリューションを開発し、マネージャーのデータポイントを使用して要件ポイントと開発ポイントの比率を計算し、開発ポイントと人間を比較します時間の要件。

つまり、マネージャーは、次の3つのシナリオのいずれかで、額面どおりの見積もりの​​みを取得します。

• 過去の同様のタスクの見積もりはかなり正確でした。
• 彼は配達を迫られており、あなたの予想は彼が思っていたよりも優れています。
• 彼はあなたを解雇する理由を探しています。

それがその最後の状況であるなら、あなたが多分あなたが地獄を出るべきであるかもしれない職場の周りの他の多くの手がかりがあります。

私にはわからないが、私の飼い葉doはいくつかの技術的な知識を必要とします。彼を時々説明することは不可能です。