開発者がプロ​​ジェクトマネージャーの上司である場合に機能しますか?


11

私はプロジェクトの計画段階にあり、プロジェクトマネージャーを募集しています。コーディングを行い、プロジェクトのすべての部分に注目したいと思います。しかし、私はプロジェクトマネージャーがより良い結果を得るだろうと感じています。次のオプションがあります:1)コードではなくプロジェクトを管理する2)プロジェクトマネージャーを雇って自分でコーディングする

私は、プロジェクトマネージャーが開発チームにプロジェクトオーナーを置くことによって妨げられるのではないかと心配しています。プロジェクトを実行すると、チームがバラバラになり、プロジェクトが失敗する可能性があります。予算内に収まるためには、何らかの能力に関与する必要があります。

誰でもこの状況を経験したことがありますか?

詳細:それぞれが特定の領域を担当する4人の社内開発者。開発者は、プロジェクトマネージャーの同意がある場合、作業を外部委託することもできます。


あなたが開発チームの一員である場合、プロジェクトマネージャーはより良く働くだけです。
-superM

@superMに感謝します。それは私が疑うことです。これはあなたが関わった状況ですか?
-marabutt

実際には同じではありませんが、かなり近いです。私の上司はプログラマーであり、現在は管理チームで働いています。彼は、ほぼすべての技術的な詳細を知っているため、成功しています。彼はコードを書かないことを除いて、彼を開発者と見なすことができました)))
superM

チームの大きさは?また、チームメンバーを問題なく管理してきましたか?
ユスボフ

@ElYusubovはまだそれらを管理していませんが、彼らは良い人のようです。
-marabutt

回答:


10

プロジェクトマネージャーの開発と採用をお勧めします。

私が働いている会社では、いくつかの管理方法を見てきました。私の上司はプログラマーです。彼は現在コードを書いていませんが、彼は長い間使用していました。しばらくの間、彼はすべての管理を自分でやろうとしていましたが、これは実際には成功しませんでした。

現在、彼はプロジェクトマネージャー(2人)を雇用しており、チームはより良く機能しています。彼は技術面と管理面の両方の議論に参加し、時には自分で文書を準備します。

また、私は開発チームと上司が同時にいることを心配しません。結局のところ、あらゆる種類の人々と仕事をすることができなければならない専門家を雇うつもりです。

PS imhoのプロジェクト管理は、特に小さなチームで作業する場合、習得するのはそれほど難しくありません。おそらく、プロのプロジェクトマネージャーと仕事をした後、あなた自身ですべての管理を行えるようになるでしょう。


1
PSのための+1しかし、そのためにはまず良いプロジェクトマネージャーを雇う必要があります:)。
ゼノン

3

最も重要なことは、誰がどの決定について権限を持っているかを事前に明確にすることです。おそらく最大の間違いは、プロジェクトマネージャーをマイクロ管理することです。

合理的な合意としては、「全体的な予算と雇用を決定し、リソースの割り当て、計画、運用上の決定は、たとえ自分の開発作業に影響がある場合でも、あなたに任せます。


3

簡単な答え:ビジネスを成長させるために専門家雇う必要があり、プロジェクトオーナーとしてプロジェクト/会社内の責任と権限を明確にする必要があります。

長い答え:プロジェクトマネージャーについての私の理解は、ソフトウェアプロジェクトの計画と指導です。

1)仕事を管理し、誰が何をしますか?

2)作業負荷の計画-いつ何を提供するかのタイミング?

3)与えられた予算とリソース(人/ハードウェア/空間/時間)の下で意思決定を行う

(*)完全なリファレンスについては、以下のリンクを参照してください

良いスタートポイントウィキペディア-ソフトウェア開発のPMが何を期待しているかに関するソフトウェアプロジェクト管理。また、私は見にお勧めしますQ&A - プロジェクト管理費は全体のソフトウェア開発プロジェクトの大きさによって変化しない方法


2

それは機能します-プロジェクトマネージャーによって定義されたルールを確実に守れば。あなたは彼を管理するために雇いました- あなたがあなた自身を管理することによって彼の仕事を弱めるなら、あなたはそもそも彼を雇うべきではありませんでした。


1

私の経験から、あなたは開発チームに関与してプロジェクトマネージャーを持つべきではありません。マネージャーの責任は、特定の時間枠と予算内で設定された数の要件を完了することです。

プロジェクトの所有者がプロジェクトに関与しすぎると、範囲が広がります。彼らは可能性の半分を感じ始め、わずかな変更としてのみ追加機能を含めることを望んでいます。


ご意見ありがとうございます。仕様が変更される可能性が高いことに同意します。2008年にDiablo 3のデモを見たのを覚えていますが、それは今年だけでした。誰かがそれを構築している間に誰かがより良い何かを引き出した場合、その場でプロジェクトを変更できる必要があると思います。
marabutt

非常に真実-あなたは世界に適応できなければなりません。ただし、ここでの違いは、スコープの漸進的な変化によって製品が遅延しないことです。何らかの理由で製品の設計を変更する必要がある場合、開発方法論でこれを許可し、所有者とプロジェクトマネージャーは、これを達成するための明確な要件を開発チームに提供する必要があります。また、これらの側面を分離することで、競合他社と市場を評価する機会が増え、方向を変えるための俊敏性が向上すると思います。
ジョンD
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.