私は非常に短い時間（約1年）働いていたので、その前はプログラマーでした（研修生から建築家に至るまでのすべてのステップを経験しました）ので、私の管理職が犯した間違いはまだ新鮮であり、その後、せいぜい心が汚れました。 繰り返しますが、免責事項、これはすべて議論のためだけに書かれています...それでは、始めましょう。
チームについて
単一のプロジェクトが、それを実装するチームなしでは正常に終了（および開始）できないことは明らかだと思います。 ここでの主なことは、「チーム」と「開発チーム」があることを理解することです。 古典（Peopleware DemarcoとLeicester）は、チームの「結晶化」のプロセスを説明しています。 したがって、チーム内の人々のプロジェクトへの配分を最大限に制御し、彼らの分離を防ぐためにあらゆる手段（大声でfromりから監督のdirectorまで）を行い、すべてのプロジェクトで一緒に作業するようにしなければなりません。
ところで、1つのプロジェクトでの作業は、チームを作成するには完全に不十分です。 これに取り組む必要があります。 私は「チーム」と出会いました。これは、何らかの理由で同じオフィスに集まり、近隣のコンピューターに座っているフリーランサーのグループのようなものです。 原則として、集中的なチームビルド（ビール旅行、共同旅行など）が状況を改善できるとは思いません。 私の意見では、悪化するだけです。 ボーナスで先週ビールを飲んでいた人を解雇するか奪うことは、はるかに不快です。 チームの各メンバーが特定の役割を担い、プロジェクト内で継続的なコミュニケーションがとれていることで十分だと思います（Brooksが言ったように、メインの作業時間が費やされています）。 ここでの式1 + 1 = 2.5は、可能な限り効率的に機能します。 そして、チームで最も重要なことは相互尊重です。
敬意について
各チームメンバーが残りを尊重することは非常に重要です。 そしてこのためには、まず第一に、各リーダーを尊重する必要があります。 はい、確かに、Vasyaは怠け者であり、Asyaは他のすべての人をばかだと考えています。 Goshaは自分が実際よりもずっと賢いと考えており、Syomaは嫌なコードを書いています。 しかし同時に、非常に優れたアーキテクトであるVasya、AsyaよりもLinuxシステムをよく知っている人はいません。Goshaはきちんとしたクリーンなコードを書くよう努めており、Syomaは非常によく訓練されています。 そして、これが主なものです。
Vasyaに、他の誰もこのスクリプトを自動展開用に作成できないことを（公に）理解させ、クラスダイアグラムとGoshinコードのAsinを公に称賛してください。 Syomaに彼が間違っていることを説明し、コードが改善し始めたらすぐに賞賛してください。 これはたくさんあります。 チームに敬意が表れるのは、あなたがそれに取り組むときだけです。 そして、最も重要なことは、決して公にyour辱しないことです。 それは恥ずかしくて専門的ではありません。 はい、そして、できれば、脇に静かにtakingってください（これはよく知られたルールです）。 一般に、各人は一意であり、これを考慮する必要があります。
人格について
通常、各人と協力する必要があります。 そして、これはプロジェクトマネージャーの主な責任（および頭痛）の1つです。 残念ながら、PMは、それを忘れてしまい、不十分な顧客の計画、条件、要件、および手紙に圧倒されます。 どの開発者にも、効率的に動作させるために回す必要があるキーがあるように思えます。 最大のリターンを達成するのに役立つ一種の「ポイントG」。 （私はあまりにも軽薄な比較をお、びしますので、単語の効果からより良い「ポイントE」と呼びましょう）。 さらに、この点では、仕事中ずっと継続的な刺激が必要です。
例を挙げましょう。たとえば、Vasyaという男が私たちのために働いていました。 そしてそれだけではなく、「彼が失敗した」いくつかのプロジェクトの結果によると。 私は、大学時代から「真面目なコンピュータ技術者、ほとんど教祖」として知っていた専門家が、なぜこのような恐ろしい結果を示したのかを理解するために、1か月をお願いしました（ところで、損失は月に数万ドルと見積もられていました）。 すべてがシンプルで汚いことが判明しました。 Vasyaは優秀なプログラマーでしたが、自分でタスクを設定する方法を知りませんでした。 そして、要件が少なくとも少し不明確になるとすぐに、彼は無気力な夢に接するst迷に陥りました。 しかし、15分を費やす価値があり、タスクと期待される結果、すべてがどのように行われたか、さらに迅速かつ効率的に明確に定式化されました。 このモードで作業を開始した後、進捗状況は非常に明白になり、さらに促進されました。 明らかに、これには開発が行われるテクノロジーのリーダーによる最小限の理解が必要です。
自身の技術的スキルについて
プロジェクトマネージャーが自分のチームが使用しているテクノロジーを詳細に理解しているのは素晴らしいことです。 しかし、それはポイントではありません（Rainwaterの猫の放牧の専門家が何と言っても）。 管理に焦点を当てて技術的な部分を委託できる専門家があれば十分です。 私が認めるのは、私のチームが書いている言語についての一般的な考えしかないことです。 そうでないと、必然的に自分自身の、かなり狭い意見を押し付けることになっていたため、それはさらに良いと思うこともあります。 さらに、PMがコードを自分で書くことは非常に重要だと思います。 まあ、本当に、プログラマーが顧客との納期に同意し始め、販売スペシャリストがコードをテストするとどうなりますか？ チュコフスキーのように：「豚は鳴き声を上げ、猫はうなり声を上げた...」（この不滅の作品の全文は、 www.stihi-rus.ru / 1 / chukovskiy / 19.htmを参照 ）。
情報について
開発者は、プロジェクトの現在の状況、会社の現在の状況、およびその開発の見通しを認識する必要があります。 これは曖昧な論文です。 多くの人が開発者に持ち込む必要のないもの（たとえば、顧客が1時間の仕事に支払う金額）をリストすることは間違いありません。 しかし、本当に、開発者は彼から何も隠されていないことを感じれば、はるかにうまく機能します。 顧客が1時間の仕事に対して10ドル、20ドル、50ドルを支払い、同時に3、5、10倍少ない金額を受け取ることを彼に知らせます。 しかし、彼は収入、安定した収入、および給与が期限内に支払われるという保証を保証しました。 また、プロジェクトを自分で検索する必要はありません。 一方、プロジェクトが予算を超えるなどの事実（および理由）を隠さないでください。 開発者が適切であれば、プロジェクトが失敗した理由とボーナスを受け取らなかった理由を正しく理解できます。
有罪について
ところで、失敗したプロジェクトについて。 残念ながら、プロジェクトマネージャーから次のような声明を聞くことがあります。「このプロジェクトは失敗しました。プログラマーは十分な資格がないため、多くのミスを犯します。 そして、Vasyaは夕方にフリーランスをします」）。 プログラマーを責めるのに最適な方法です（そして、はい、テスターはまだエラーを時間通りに見つけられず、アナリストはトリックを行いました）。
実際、リーダー以外の誰もプロジェクトの失敗を責めるべきではありません。 そしてそれは非常に重要です！ プログラマーには資格がありません-訓練し、アプローチを探してください。これがまさに「ポイントE」です。 人が「完全に木造」である場合-解雇され、チームにまだ成長しておらず、他の人に置き換えられても心配することはありません。
これが行われない場合、プロジェクトは90％の失敗になります。 残りの10％は、おそらく、このチームではPMが原則的に必要ないことを示しています。
ケアについて
あなたのチームがあなたのすべてですので、人々が幸せであることは非常に重要です。 チームおよび各個人に対して快適な条件がどの程度作成されるかは、プロジェクトマネージャーのみに依存します。 概して、チームのキャリアと専門的成長の両方を決定するのはPMです。 したがって、従業員が昇進に値すると考えている場合は、これを目標として設定し、あらゆる方法でそれを達成する必要があります。 もちろん、専ら専門的な資質が考慮されるように予約します。 主なものは、個人的な愛着や偏見がそのような決定の採択に影響を与えないことを保証することです（再び、一緒にビールを飲むことの害について）。 ですから、人々の幸福と快適さにも取り組む必要があります。
結論について
結論は明らかです。 効果的なプロジェクトを実行するには、チームと協力する必要があります。 これは必要条件です（ただし、もちろん十分ではありません）。 それは次のように定式化できます。うまく調整され準備されたプロジェクトチームなしではプロジェクトで成功を達成することは不可能です。 長生きするキャプテンエビデンス！