簡単な紹介：大規模な組織で働いており、数百万ドルから数十億ドルのプロジェクトを管理している場合、これは明らかに読む価値がありません。あなたは私に同意しません。 問題のレベルは異なります。 そして、私の論文は一般的に受け入れられているプロジェクト管理の慣行に反することが多いことを完全によく理解していますが、個人的にプロジェクトを成功させることは、それに従う場合のみです。
チーム
プロジェクトを直接作成するチームは、プロジェクトの最も重要な部分です。 彼女との良好な関係と優れた相互理解がなければ、プロジェクトを最初からすぐに埋めることができます。 優秀なチームとあなたに対する態度のみが、完全に絶望的なプロジェクトを完全なロバから引き出すことができます。
1.チームと同じ言語を話します
プロジェクトで特定の人々が何をしているのか理解していない場合、ある時点で彼らと通信できなくなります。 そして、ほとんどの場合、これはプロジェクトの最も重要な瞬間です。 私は自分自身に気づきました：最も知的で、責任があり、美しくさえ。 同僚が特定の時点で、自分が何について話しているのかわからないことに気付いて、「ママは不合理な子です」というコミュニケーションスタイルに切り替えます。 つまり 開発者は、「a-ta-taの方が多くなるため、このプロジェクトではデータベースを使用できません。 そして、あなたはそれらからより論理的な説明を得ることはありません。 特にあなたが彼らのリーダーのような状況にある場合、これはコミュニケーションの良いスタイルではないことに同意します。
2.プロジェクトを起動します-一緒に書き込みます
あなたのプロジェクトが、ここで結果を表示する必要がある重要なポイントに達した場合、またはそうでなければ射撃する場合、労働者の偉業のために同僚をやる気にさせる唯一の方法は、彼らと「戦場に落ちる」ことです。 つまり 明日締め切りがあり、義務を果たさなかった場合、顧客と経営陣の大規模な弾圧が発生します。従業員の隣に座って、従業員と一緒に（またはそれ以上）把握する必要があります。 あなた自身の例によってのみ動機づけることができます。 あなたがまだ助けができないので、あなたが電話に正確に立ち上がって家に帰るなら、誰も夜に座ってあなたを耕すことはありませんので安心してください（特定の数の狂った完璧主義者を除いて、今のところは彼らについてではありません）。
3.私たちは最高の仕事をします
管理者が特定のプロジェクトのチームを選択することを許可している場合（および許可していない場合、あなたまたはあなたの会社は「プロジェクト指向」ではありません）、この特定のプロジェクトに最適な人を募集する必要があります。 もちろん、他の人のレビューや推奨事項に頼ることはできますが、それらは非常に間違っている可能性があります。 例：顧客がオフィス全体をナパームで焼く準備ができているプロジェクトに投入される開発者達がいます。 そのような開発者の実績は失敗したプロジェクトであり、それを思い出すのは残念です。 そのような開発者の資質について他のRPに尋ねると、彼らは覚えていません。 その瞬間、火を消す必要があり、個人的な資質については考えませんでした。 そして、この開発の第一人者を犠牲にして重要なプロジェクトを整理しているのか、単に大砲の餌を投げているだけなのかはまったくわかりません。
したがって、既存のエンジニアのプールがどれだけの能力があるかを正確に理解していれば、チームの理想的な構成をまとめることができ、問題に最小限の関与ですべてを非常にスマートに行うことができます。 反対に、あなたがあなたのチームを理解し、彼女がそれを感じれば、チーム自体があなたのプロジェクトを要求します。 確かに、部分的に見知らぬ人を妨害しますが、私は仕事で利己的な動機からのみ進みます。
お客様
1.通訳なしでお客様と話します
最近、技術者（システム管理者、内部開発者、ITセキュリティ担当者）は、ビジネスユーザーを除くすべてのプロジェクトに顧客を惹きつけています。ビジネスユーザーは、会議に出席し、緊急の、しばしば不快な質問をするのが好きです。 これらすべての質問に答えるために「オフィスの情報を明確にする」必要がある場合は、その方法を理解できます。 問題の解決は遅れます。 あなたは絶えず逃げ出し、専門家と相談します。 しかし、今ここでいくつかの問題を解決する方が良いです。
2.「オオカミさん」
この項目は前の項目から続きます。 顧客がすべての問題についてどこかで相談することに気付いた場合、プロジェクトでは、ほとんどの場合、メールサーバーの役割を果たします（そうでない場合でも、印象はまだあります）。その後、顧客の専門家が直接開始しますチームとチャットします。 あなたはこれらの交渉の背後のどこかに留まり、決定の一部は事後的に一般にもたらされます。 これは、すべてを管理しなければならない人にとって最良のポジションではないと確信しています。 お客様にとっては、「問題を解決するウルフ氏」でなければなりません。
そのようなコミュニケーションから成長できるもう1つの迷惑があります。 必要なコミュニケーションの資質を持ち、RPの役割を果たそうとする彼の魂のある従業員は、プロジェクトからあなたを完全に「絞り」、コントロールすることができます。 エゴイズムについて覚えていますか？
3.インスタントセール
小さなアイテム。 時々、顧客はいくらか余分に売ることができます。 彼が望むまで、サービスはすぐに適所にあります。 この場合、問題の範囲全体をより正確に提示し、より良い評価を行うことができれば、その後の血なまぐさい計算をせずに追加のプロジェクト資金を得るチャンスが増えます。
その他のデザインバン
1.プロジェクト予算
理論的には、上記のすべての問題は、プロジェクトに特別に訓練された人々を引き付けることによって解決されます。 リード、ティム。 リードなど。 しかし、そのような専門家が参加すると、プロジェクトから得られる利益が減少します。 また、利益はプロジェクトの成功の重要な指標の1つです。 プロジェクトで非常に高価なリソースを使用して自分でトリミングすることのポイントは何ですか？
2.プロジェクトの範囲
プロジェクトの作業範囲は、ユーザーの知らないうちに変更されることはありません。 顧客はあなたの後ろのチームに同意しないからです。 いくつかの高価な「もの」はプロジェクトに詰め込まれず、それはあなたの無知のために本当のささいなことを示しますが、最終的にはロバの痛みになるでしょう。 リーダーシップは、知的無力を利用して、意図的に不可能なプロジェクトをあなたに押し付けることはありません。 などなど。
ガイド
あなたのリーダーはあなたが持つすべての「サイド」知識から何を得るでしょうか？ プロジェクトの成功、何が起こっているのかを常に監視する必要がない、満足している顧客、満足しているチーム、CSWの圧倒的な感覚で満足している:)
このアプローチの短所
私がこのアプローチをどのように気に入っても、もちろん、欠点があります：
- マイクロ管理に陥る危険。 すべてに精通している場合、開発されたすべてのコード行、TKで書かれたすべての単語を制御し始める可能性があります。 それは、増加した自己制御でのみ扱われます。
- 2つまたは3つの「ポスト」で並行して開発する必要性。 RPとしても、チームの他の開発者、エンジニア、アナリストとしても、より良くなる必要があります。 これには時間がかかりすぎるため、妥協点を探す必要があります。 まあ、または技術的な知識を吐き出し、古典的な「ダムマネージャー」になります（この場所の「ダム」という言葉は知性ではなくアプローチによって特徴付けられます）。
- 「世紀の建設」を導くことができない。 残念ながら、このアプローチは1日で24時間しかないため、この方法では機能しません。実際、寿命は短すぎます。 チャンスが何か素晴らしいもので地平線に現れ、あなたも欲望があるなら、そのようなアプローチは放棄され、あらゆる種類のヘルパーで大きくなり過ぎなければなりません。 しかし、私は、あなたが本当に地平線でそのような機会を持っているなら、あなたは私のアドバイスを必要としないと思います。