PMが何か有用なことをすることと、そのために必要なことは本当ですか？

興味深い観察：社内のプロジェクトマネージャー向けのセミナーを開催し、定期的に主要な技術専門家（建築家、デザイナー、チームリーダー）を招待しています。 最初はややしぶしぶと来て、約1時間座って、突然書き留めて質問を始めます。 一日の終わりには、「あなたは怠け者であり、悪鬼だと思っていましたが、あなたには懸命で責任ある仕事があることがわかりました。」 このようなトレーニングは、チームメンバーがお互いをよりよく理解するのに役立ちます。

さまざまな役職で10年以上にわたり、プロジェクト管理に携わってきました。 彼は4つの主要なインテグレーターで働いており、現在私は100人の部門を率いています。 作業中、管理する必要のなかったプロジェクト：SAPの実装、企業の活動の自動化、政府顧客向けのICの開発、ユニークなデータセンターの設計と構築、軍事RCの作成、複雑なIP移行の実施...-ベラルーシのターンキー発電所やチェルスキー（ヤクーツクから2000 km）。 そのときの主な困難は、機器と材料の配送でした-川は年に5ヶ月しか通れませんでした。 締め切りを過ぎた、またはちょうど寒い年になった-7か月間失われました。 または高価なヘリコプター。 すべてのプロジェクトは異なり、それぞれが独自の方法でユニークです。

あなたのチームは曲がったコードを書き、アンロードのためにサーバーを落とし、機器が時間通りに到着しなかった、顧客が受付を遅らせ、技術要件が大きく変わり、タイミングと予算が違います...これはすべてPMAの頭痛の種であり、これは彼の仕事のほんの一部です。
しかし、主なことは最終結果に対する個人の責任です！

プロジェクトマネージャーはどのレベルで機能しますか？

わかりやすくするために、単純化した「テクノロジーピラミッド」を使用します。 分割はかなりarbitrary意的ですが、指の多くの複雑なことを説明するのに役立ちます。

1. ビジネス目標はピラミッドの最上位です。 特定のビジネス目標が形成されるレベル。 たとえば、「クライアントが申請を提出した時点からのローンは、銀行によって15分以内に承認および発行されなければなりません。」
2. プロセスレベル-ビジネス目標を達成するために組織内でプロセスを構築/再構築する方法。
3. 適用レベル-自動化、ソフトウェア、およびそのアーキテクチャ。
4. インフラストラクチャレベル-VK、SHD、DBMS、システム全体のソフトウェアのアーキテクチャ。
5. LDSレベル-SCSを含むデータ伝送ネットワークのアーキテクチャ。
6. 工学レベル-電気、換気、給水、アクセス制御システム、ビデオ監視、空調など
7. 建設、または「コンクリートレベル」-どの建物、どこで、敷地内の内訳など。
8. セキュリティ-すべてのレベルを通過します。 ピラミッドの下部-物理的、上部-情報（標準、規制、ポリシーなど）。

これは、いくつかの仮定を使用して、複雑なプロジェクトを完全に分解できるモデルです。 上記の各レベルでの実装管理には、PMから特定のスキルと知識を必要とする独自の組織的および技術的特性があります。

たとえば、発電所の建設とソフトウェアの開発は根本的に異なるプロジェクトです。 さまざまな管理方法（PMI、アジャイル、スクラム...）、プロジェクトチームのさまざまなロールモデル、コミュニケーションの編成、保証されたさまざまな資金調達モデルなど。各プロジェクトには独自のアプローチがあります。 普遍的な知識はありませんが、使用されるアプローチの普遍性があります。

1つまたは2つのレベルのみを対象とするプロジェクトがあります（たとえば、企業データネットワークの近代化、小さなソフトウェアの開発）。 そして、7つすべてをカバーするものがあります（たとえば、「Safe Cities」）。 彼らは、コンサルティング、ソフトウェア開発、エンジニアリングシステム、そしてもちろんITを備えた建物の建設を行っています。 そのようなプロジェクトには、PMAからの特別な準備と蓄積された経験が必要です。 このようなプロジェクトでのPMの重要なタスクの1つは、常に主要な専門家の採用と大規模なチームの作業の適切な組織化です。

これらの各レベルで機能するPMの詳細と能力に関する知識は、PM​​を普遍化し、プロ意識の程度を決定します。

目標を達成するためにプロジェクトのPMを制御するものは何ですか？

最初は、この質問に対する答えは難しくなく、多くの人は予算、スケジュール、品質があることをすぐに覚えています。 その後、少し振り返った後、人々はチームとリスクがあることを覚えています。 ファンタジーはすぐに終わります。 しかし、説明するように頼むとき、主なst迷が来ます：「そして、あなたはこれをどうしますか？ すべてをどのように管理しますか？」

実践が示すように、私たちが日常生活でよく使用するプロジェクト管理の最も一見シンプルなカテゴリでさえ、プロジェクトチームの主要メンバーだけでなく、PM自身にも困難をもたらします。

予算（コスト）管理

古典が言ったように、「十分なお金と時間があれば、どんな問題も解決できる」。 これは部分的に真実ですが、現代の市場には微妙な違いがあります。 市場は縮小し、顧客の予算は削減され、競争は拡大しています...生存のための闘争では、市場はIT企業に積極的に行動することを強制し、以前はリスクの高いゾーンと見なされていたプロジェクトに参加するようにしました。たとえば、会社に十分な経験とリソースがない場合です。

競合他社がこのようなプロジェクトの専門家であることがなく、価格がお客様のコストよりも低いかそれに近い場合、競合他社が競合に参加する状況に対応することがますます頻繁に行われています。

これは何ですか：合計計画エラー、明確な計算、意図的なダンピングまたは死の苦痛？！

プレセールでのPMaと管理グループの役割は劇的に増加しました。 この段階での質の高い仕事は、プロジェクトの成功の半分です。 コストを明確に決定し、コストを最適化し、リソースの可用性と必要なコンピテンシーの可用性を評価し、適切な実装戦略を選択し、トランザクションの財務モデルを開発し、競争の場合のリスクと財務力を評価します-これらすべてを短時間で実行します。 このようなトレーニングを短時間で編成することは非常に困難ですが、これはプレセール段階でのPMの主なタスクであるため、さらなる実装が成功します。

時間管理

プロジェクトの始まりは不確実性の最高点です。 さまざまな方法で目的地に到達できますが、RPのタスクは、最適なルートと移動速度を選択することです。 途中で考慮すべき多くのニュアンスがあります。

最短経路が必ずしも最適ではないのはなぜですか？

たとえば、私は1日12時間、週7日間働くことができ、他のすべてのプロジェクト参加者にこれを行うように説得することができます。 特定の時間にサイトまたはシステムにアクセスする必要がありますが、顧客にはこのための特別な手順があります。 ダウンタイムが必要ですが、顧客にはビジネスクリティカルなシステムがあり、シャットダウンに同意する準備ができていますが、月の最初の土曜日の22:00にのみです。

一般的に、顧客はパフォーマーの選択したペースに対応する準備ができていないことが非常に多くあります。 これは、多くの場合、顧客の専門家向けのプロジェクトの実装が主要な機能活動ではなく、管理に代わって追加の負荷がかかるためです。 顧客は、技術的な要件について話し合ったり、文書を分析したり、コードをテストしたり、必要なシステム設定をメインのアクティビティで許可されているよりも速くしたりすることはできません。 そして、あなたが彼にそれをやらせることさえできれば、否定性と間違いは単に避けられません。 また、請負業者やベンダーの仕事にも微妙な違いがあります。 しかし、最も困難で予測不可能なのは、政府機関、特に治安当局と規制当局との相互作用です。 それらを効率的に機能させることは単に不可能であり、ほとんどの場合、彼らはあなたのプロジェクトのためにドラムに乗っています。 しかし、これは別の話です。ここにはいくつかのニュアンスがありますが、それらについてはこの記事にはありません:)。
プロジェクトを早期に完了したという事実だけのために、プロジェクトを「分散」することは意味がありません。
チームを捨て、多くの「熱」を捨て、顧客との関係を台無しにします。

これはすべて「仮定と制限」と呼ばれます。 不確実性の程度が高いため、プロジェクトの開始時には、それらのほとんどがあります。

また、作業計画は生活量であり、プロセス自体は創造的です。 納期に間に合わなかったり、納期が間に合わなかったり、ソリューションの選択を間違えたり、顧客が要件を変更した場合、プロジェクトのスケジュールと予算の修正が必要になります。

品質管理

専門家コミュニティで最も論争を引き起こすパラメーターの1つ。 一方では、すべてが非常に単純に見えます。品質とは、指定されたパラメーター/要件への準拠を意味します。 参照条件があり、すべての要件が閉じられている場合、品質の実装を検討できます。 しかし、そうですか？

そして、顧客との最初の会議で、彼の期待があなたが実現しようとしていたものとは非常に異なることに突然気付いたとき、どうしますか？ 一般に、要件と期待は同じものですか？ そして、なぜ彼らは突然変わったのですか？ 私はよくインタビューでこれらの質問をしますが、奇妙なことに、経験豊富なPMでさえも浮かんでいます。 開発を率いるPMが目の前にいると、二重に動揺します。

トレーニングを説明するために、例を挙げます。 ITキャリアの夜明けに、妻のためのWebサイトを構築していました。 私はデザイナー/開発者を見つけ、100万のサイトをレビューし、私には思えたように、私が望むものを明確に理解しました。 要件について尋ねられたとき、彼は自信を持って発表しました：美しい、モダン、便利、スケーラブル-そしてそのような多くのもの。 開発者は耳を傾け、次のように述べました。 そして、要件は何ですか？ どのエンジン、どの管理パネル、支払いシステムとの統合、構造など？「当然、私はそのとき答えることができませんでした-これは私の最初の経験であり、最初のサイトでした。 今ではできますが、それは複数回起こったからです。

もちろん誇張しますが、同様の要件があるため、顧客はしばしば競争に参加します。 そして最初の会議で、彼は彼が仕事の声明に書いたものを望んでいないことが判明した。 そして、あなたがこれで何もしなければ、プロジェクトの終わりに、誰もが大きな「驚き」、宣誓、長く退屈なレセプションを持つことになります。 作業指示書に従って構築されましたが、顧客が望んだ方法ではありません。 システムは動作しますが、その期待を満たしていません。 現在のニーズを満たしていますが、スケーリング、成長、統合のために備蓄されていません。 そして、実際に提示するものは何もありません。書かれているとおり、彼らはそれを構築しました。 次に何をすべきか-特に改訂の予算がなくなった場合、誰も知りません。 デッドロック、フラストレーション、顧客との関係の崩壊...

経験豊富なPMは、そのような状況に対処する方法を知っています。 特に顧客が最初に何かを導入したり、製品を作成したりするときに、ユーザーバックエンドがまだない開発された特性について、特にピラミッドの最上部で発生します。
このようなプロジェクトにおけるPMの主なタスクの1つは、プロジェクトの過程で期待と要件が収束することを保証することです。

ソフトウェア開発を伴うプロジェクトでは、現代的で人気が高まっているアジャイル、スクラム、およびその他の方法論が役立ちます。これは、顧客がプロジェクトに深く関与することを意味し、動作機能のデモでの短いスプリントを意味します。 請負業者と顧客は、「我々はそこに行きますか？ それはあなたが望んだものですか？」 これにより、常に特定の方向に移動し、エラーを最小限に抑えることができます。 同じアジャイルはいつでもどこでも良いという一般的な信念に反して、軍事OCDや古典的な「滝」よりも急なエンジニアリング建設プロジェクトに適しているものはほとんどないことに注意してください。 これがシステムの仕組みです。 各方法論には、独自の適用分野があります。 これは宗教ではなく、プロジェクトパラメータを効果的に管理するためのツールです。

たとえば、プロジェクトの要件が十分に詳細ではない場合（その解釈により大きなばらつきが許容される場合）、またはプロジェクトの過程でそれらの改良が暗示される場合、「プロトタイピングとスプリント」の方法は非常に優れています。

要件が明確に定義されている場合、段階的な実装には規制当局と規制当局の厳しい要件があり、実装にはGOSTと規制文書の使用が含まれます-ウォーターフォールなどの古典的なモデルはうまく機能します。

リスク管理

リスクもあるため、まったく簡単ではありません。 多くの本や記事がリスク管理について書かれているという事実にもかかわらず、それらを効果的に管理することは決して些細な仕事ではありません。 実際、私たちは本質的に確率的であり、特にあなたのプロジェクトではまったく起こらないかもしれないイベントを予測および評価しようとしています。 そして、彼らは、識別、分類、定性的および定量的評価を行い、対応戦略を開発し、監視し、レビューする必要があります...

実際、これは複雑で多面的なプロセスであり、PMの参加だけでは明らかに十分ではないので、同僚に助けを求める必要があります。 さまざまな方法論がリスク分類のみの無数のカテゴリとサブカテゴリを提供するという事実にもかかわらず、実際には、無数の方法論が最も理解しやすく評価しやすいものを使用しています。 IT企業の中で、リスク管理プロセスが根本的に異なる（高度な）レベルになっていることはまれです。

リスク評価には通常、プロジェクトチームの主要メンバーとPMに関係する会社のサービスが含まれます。 通常、実際の分離は次のようになります。

1. 組織的および方法論-仕事の組織およびPMによって管理される知識の領域に関連するリスク。 PMAおよびプロジェクトオフィスの責任範囲。 技術-ソリューションの開発されたアーキテクチャ、使用される技術などに関連するリスク。アーキテクトとチームの主要な技術専門家の責任範囲。
2. 財務-会計、規制要件の順守、使用される財務モデルなどに関連するすべて。会計および財務の責任範囲。
3. 法的-適用される法律、規制、契約条項の要件、監督当局との調整規則などに関連するリスク。弁護士の責任範囲。
4. 特定のリスクは、通常、業界固有のリスクや高度な専門知識を必要とするリスクです。 ここでは、プロジェクトによっては、定期的にサードパーティの専門家の助けを借りる必要があります。

評価が定性的に行われている場合、そのような分割は通常、最も重大なリスクを回避するのに十分です。

最も簡単な方法は、事前に知っているリスクを使用することです。 それらの一部は表面にあり、一部には以前に実装されたプロジェクトからの蓄積された経験があるため、私たちはそれを知っています。 それらは通常「既知のリスク」と呼ばれます。 このようなリスクは分析が容易であり、事前に対応を計画できます（対応戦略）。 たとえば、プロジェクトを初めて実装する場合はさらに困難です。 蓄積された経験はなく、彼らの能力は必ずしも十分ではありません。 そのようなプロジェクトでは、特定のリスクの存在に気付かない場合があり、それらの存在を想定すると、正しく評価することができません。 このような状況では、緊急時の予備力とチームの専門家による評価のみが保存されます。

リスク管理の「最大目標」は、プロジェクトの目標と指標に悪影響を与える可能性のある単一のイベントが発生しないようにすることです。 しかし、それはほとんど不可能です。 リスクの一部は常にあなたの外部にあり、それらへのあなたの影響は非常に限定されます。 また、プロジェクトが大きく複雑になるほど、これらのイベントの1つが発生する可能性が高くなります。 したがって、PMAの主なタスクは、発症の影響を最小限に抑えることです。

リスク管理は、プロジェクト全体で進行中のプロセスです。 プロジェクト自体と同時に開始するときの大きな間違い。 評価時間と「操作する場所」が大幅に短縮されます。 開発した計画エラーやリスクがプロジェクトのマージンを消費するだけでなく、会社と一緒にプロジェクトをown死させる状況を見てきました。 このプロセスは、プロジェクトに入る決定のかなり前に、ディーププレセールの段階で開始するのが適切です。 これは、企業が顧客や規制当局の厳しい要件を持つ新しい、なじみのないプロジェクトに参入するときに上で書いた現在の市場状況で特に当てはまります。 そのようなプロジェクトでの販売前のリスク評価の結果は、この競争にまったく参加しないという管理グループの決定である可能性があります。

チーム内では内部的に利益相反があるため、企業内でのこのような決定は常に困難です。 これは、販売単位の「欲」が保守主義と生産の「恐怖」と戦うときの同じ線です。 成熟した管理プロセスとビジネスプロセスを備えた企業では、この紛争の真相は常に中間にあるため、このような競合はさらに有用です。 そのような紛争の主なものはアービターの存在であり、そのため、論争の激しい議論の場合、バランスのとれた意識的なリスクが冒険主義と宝くじに変わります。

プロフェッショナリズムPMA

残念なことに、多くの人は、PMの専門性は職業に費やされた時間で測定されると心から確信しています。 私は違うと思う：経験、知識、スキル。 それらが多ければ多いほど、PMはより専門的です。 実際の「戦闘」プロジェクトで得られた実践的な経験は非常に貴重であり、競争上の優位性です。 もちろん、誰も間違いから安全ではありませんが、人々が言うように、「彼らはoneられたのに二人をgiveられない」と言います。 あなたの額であなたの庭のすべての熊手を集めたので、あなたはそれらを再び踏むことはまずありません。

特定のプロジェクトにPMaを選択するとき、いくつかのパラメーターに注意を払い、同じ「技術ピラミッド」を使用します。 たとえば、建物を建ててそこにエンジニアを雇う必要がある場合は、経験豊富なビルダーを優先し、ITをアップグレードする場合は、経験豊富なインフラストラクチャエンジニアになります。 技術および業界の詳細、請負業者、落とし穴、および確立されたチームに関する知識は、不必要な間違いを避け、予算と時間を節約するのに役立ちます。

私は、最も普遍的で独立したPMをチームに持ち込もうとしています。 ピラミッドのすべてのレベルで、また不確実性の高い状況で効果的に作業することができます。 PMaの個人的な資質とその内部的な動機付けに多くの注意を払う必要があります。 人がすぐにチームに参加し、快適になり、チームにとって「快適」であることが重要です。 市場の優秀な専門家-大きな不足。

興味があれば質問してください。喜んでお答えします。 さまざまな非標準的な状況に関する特定のプロジェクトの例と、それらからどのように抜け出したかについてお話します。

このテキストは、エンジニアリングコンピテンスセンター「Technoserv」のプロジェクトマネージャー兼副ディレクターであるYuri Korchukovによって作成されました。