プロジェクトマネージャーは必要ありません

タイトルに疑問符がないことに注意してください。 私は、プロジェクト管理者が現代のソフトウェア開発に必要かどうかを議論したくありません。 実践は、そのことを示しています。 なぜ起こったのかを理解しようとしているだけです。

IT業界で20年以上働いてきた私は、プロジェクトオフィスからすべての新しい開発を構築し始めました。 さらに、何度か、経営陣にピエムを雇う理由を説明しなければなりませんでした。 部門の責任者にとって、ソフトウェアの開発に直接関与していない人々に、プロジェクトマネージャーが正確に何をするかを説明するのはそれほど簡単ではありません。 顕著な抵抗を克服しなければなりませんでした。

しかし、私にとっては、プロジェクトオフィスとプロジェクトマネージャーが成功の基盤であるという公理でした。 5年ほど前にプロジェクトマネージャーは必要ないと誰かに言ってください。最後まで彼と議論します。

編集者注：このテキストは、Piemnaya集会の到着からDmitry Kruglovが報告した結果です。

それともまだ必要ですか

この職業を保護することから始めましょう。 プロジェクトオフィスの建設が成功したことを含め、最後の作業場所で結果が達成されたという理由だけで。

プロジェクト管理はITの特権ではありません。 これは50年以上前の科学です。 独自の神聖な本を持っている科学。 もちろん、PMBoKは種類の1つではありません。PRINCEがあり、おそらく、栄誉を多少とも主張する書籍がさらにいくつかあります。 しかし、PMBoKは国際標準の基礎であり、これはその高いレベルの認識を示しています。 だから私たちはそれに基づいて構築します。

ゲームをプレイしましょう。プロジェクトマネージャーとして働いている場合、先を見越さずに、主要な活動分野を国際標準や50歳以上の機関の観点から思い出してみてください。

たとえば、プロジェクトの要件を管理します。 または期待を管理します。 時間管理について覚えているかもしれません。 確かにビジネスを代表する同僚は、まさにこのタスクまたはそのタスクの準備がいつできるかを定期的に尋ねます。 たぶん、あまり一般的ではない利害関係者の管理を思い出すでしょう。 他に何？ コミュニケーション管理。 後者は、利害関係者と同じくらいまれです。 しかし、これは、すべてのプロジェクト参加者がドラフト憲章で必要な電子メールではなく、Telegramで重要な情報を共有することを好む現在、重要かつ困難なタスクです。 たとえば、仕事の質などについて話し合うチャットに招待されていない場合、どうすればコミュニケーションを管理できますか？

思い出したものとPMBoKのリストを比較してください。

すべてのアイテムは非常に正気です。 このアクティビティは、すべてのプロジェクトマネージャーが本当に行う必要があるようです。 プロジェクト統合など、この一部はそれほど明白ではありません。 しかし、いくつかのチームの力を使って本当に大きな機能を作成し、それをローンチする前にまとめる必要がある場合、このポイントが何であるかを理解できます。 ところで、複数のチームで1つの機能を並行して開発するタスクは、まだ体系的に解決されていません。

ガントチャート

アクティビティがある場合、その結果がなければなりません。 私の個人的な意見では、作業は適切なアーティファクトで行われました。 プログラマーにとって、これは作業コードです。 テストの専門家、テストスクリプトの開発または実行、システムに導入されたエラー、または作成された自動テストの場合。 デザイナー向け-グラフィックレイアウト。

プロジェクトマネージャーのアーティファクトとは何ですか？ テレグラム内のメッセージを含む、考えられるすべてのアーティファクトのうち、「最後にチャットに追加してください。これなしではプロジェクトを管理できません！」、まずガントチャートに注目します。 これは、プロジェクトに関する多くの質問に答えることができ、プロジェクトマネージャーの活動のほとんどの領域を視覚化するのに役立つ素晴らしいツールです。 結局のところ、優れたガントチャートにはタイミング、リソース、コスト、依存関係が含まれています。 そこで、通信要件をタスクとして追加できます。 マイルストーンと期待される結果の説明を使用して、利害関係者とその期待に制御を追加することもできます。 それはすべての機会のための普遍的なツールであることが判明しました。

これらの領域のほとんどのタスクは、ガントチャートという1つのエンティティの管理を通じて解決されます。

その人気と汎用性は、ダイアグラムを作成できるツールとサービスの数によって確認されます。 「Gantt online」を検索してみて、あなたが得るすべての味と色のリンクのリストの長さを確認してください。

結局のところ、私たちには職業があり、活動があり、その結果として良い成果物があります。 それで、キャッチは何ですか？

ニュアンスがすべてです。 たとえば、ガントでは、すべてがうまくいくとは限りません。

まず、大規模なプロジェクトのダイアグラムは遅かれ早かれ読めなくなります。 Microsoft Projectで「1年以上」プロジェクトを扱った経験がありました。 彼の計画を印刷するには、6枚のA4を接着する必要がありました。 あるシートでは、テキストが小さすぎました。

第二に、大規模プロジェクトの図は、維持するのに非常に労働集約的です。 多くの場合、変更は作者自身が行うことができます。そうしないと、依存関係の複雑なシステムのために計画が崩れます。

第三に、プロジェクトマネージャーの多くが多くの図を読むことを認めなければなりません。 このアーティファクトはPMによって作成されたものであり、彼だけがそれを必要とし、理解していることがわかりました。

現代のソフトウェア開発では、ガントはほとんどの部分が放棄されました。 製品の作成時にこのアーティファクトの使用を停止しましたが、その作成者は本当に必要ですか？

ITのプロジェクトマネージャーの有用性のトピックをGoogleで検索しようとすると、この議論が長い間続いていることが明らかになります。 彼女は、iOSとAndroid、Windows、またはOS Xの恋人同士の対立など、もう1つのホリバーになりました。検索結果の引用だけが、より感情的です。 PMの仕事は無価値ですか？」

私は世界的な紛争のバランスがPMを拒否することを支持しているとは言いませんが、少なくともこの観点の支持者の数は重要です。

アジャイル手法

開発チームをゼロから再構築する仕事をしている会社で働き始めて、私は今後6か月から1年の間、PMの仕事がないことに気付きました。 まず、習慣から組織構造に追加しました。 そして、彼は自分の手で三振しました。 彼は直感的に消し去ったが、「なぜそれが起こったのか」と疑問に思った。

理由についての私の研究は、ITには柔軟な方法論の実装を可能にする多くのユニークな性質があることを理解することにつながりました。 家を建ててソフトウェアを開発するという古典的な比較があります。 これらはやや似た分野であり、建築家の役割が両方に理由がないわけではありません。 両方の機能要件と非機能要件があり、インフラストラクチャ、内部通信、アセンブリ、配信、統合があります。

しかし、建設は実世界で行われ、最初のテスト、最初のフィードバック、結果が得られるまで、非常に長く高価な生産サイクルがあります。 建設の間違いの価格は非常に高いです。

IT製品はデジタルです。 また、生産サイクルは非常に短い場合があります。 20年間、柔軟な開発方法論の出現につながるツールとテクノロジーを作成することができました。 ここで、因果関係はこれだけであると主張する準備ができています。迅速に実験し、作業結果を得る能力は、これを行う方法論の出現につながりました。 もちろん、これは短い肯定的なフィードバックであり、ツールは引き続き開発されました。 そして再び、方法論が完成しました。 そして、スパイラルで、市場投入までの時間の短縮に向けて急ぎます。

役割

アジャイル手法は事実上の標準となり、ソフトウェア開発プロセスに新しい役割をもたらしました。 そして、これらの新しい役割は、プロジェクトマネージャーから活動と成果物を奪い始めました。

製品所有者（PO）

複数の顧客、複数の所有者、複数の意思決定者がいるプロジェクトがあります。 彼らにとってのPMは、妥協を求める人です。 彼はそれらすべてをまとめ、優先順位付け、和解を助けます。 彼は誰かに言います：「いいえ」誰かのロビー活動。 しかし、ビジネスは、妥協点を継続的に検索する場合、リソースが無駄に浪費されることを理解しています。 最も貴重なリソースは何よりも費やされています-時間。

したがって、柔軟な方法論はまさにそれを行います。彼らは、ビジネスの一人に精神の中で何かを言います。「あなたはお金、トラフィック、そしてコンバージョンに対して極端です。 そして正直に言うと、私たちはあなたが製品で何をどのような優先順位で行うかを気にしません。 主なことは、年末までにコンバージョンが1％から1.1％に増加することです。そうしないと、プロジェクトは不採算になります。 また、POは個別に決定する権利を取得し、優先度を決定し、対応する成果物（計画、ロードマップ、要件）を作成し、PMから作業を引き継ぎます。

Techlide（TL）

約10年前、ITは確立されたアーキテクチャを変更し始めました。

これらの変更の前、テクノロジーとツールは主に「レイヤードアーキテクチャ」（データベースレイヤー、ビジネスプロセスのレイヤー、集約レイヤー、クライアントレイヤー）用に作成されていました。 しかし、このアプローチが古典的になるやいなや、企業が部門の対応する層を取得するやいなや、柔軟な方法論が生まれました。 そして全員が満場一致で「パフパイ」が悪いと判断し、職域を超えたチームを結成する必要がありました。

これが新しいアイデアであると言うわけではありません。 ユニバーサル開発者とは何ですか？ フルスタック インタビューで30歳以上の開発者の一人は、「フルスタックという用語が存在していなかった頃はフルスタック開発者でした」と語っています。 データベースの管理やディレクターのコンピューターのセットアップなど、すべてを行う必要があったため、すべてがフルスタックになりました。

機能横断型チームは、テクライドという新しい役割をもたらしました。 Tehlidは、部門の長を押すだけでなく、PMの作業の技術的な部分も引き継ぎました。 まず、複雑さとタイミングの評価に関連するすべてのもの。 柔軟な方法論への移行時までに、多くは開発チーム自身が作業の条件を評価しなければならないという事実に同意しています。

システムアナリスト（SA）

システムアナリストは新しい役割ではなく、多くのアジャイル手法はそうではありません。 確かに言うとは思いませんが、SAFEに明示的に含まれている可能性があります。 ただし、一般に、SAFEは境界線の方法論です。 ただし、この役割は非常に有用で興味深いものです。 彼女は、複雑なメカニズムの潤滑剤のように、彼が静かにスムーズに働くことを可能にします。 システムアナリストは、一部は製品の所有者、一部は建築家です。 ビジネス要件を特定の機能のレベルまで明確にし、詳細にします。 最高のシステムアナリストは、技術リテラシーとソフトスキルの組み合わせを使用して、両方向でアイデアとビジョンを推進できます。 システムアナリストが仕事をしている場合、プロジェクトマネージャーは要件管理アクティビティを奪われます。

スクラムマスター（SM）

スクラムマスターは、プロジェクトマネージャーの役​​割を大きく絞り込みました。 現在、SM自体が絶滅の候補になっているのは残念です。

真剣に、遅かれ早かれスクラムマスターは学校で教えます。 アジャイルに関するレッスンがあり、スクラムマスターは12歳の学生にアジャイル方法論がどのように機能し、どのプラクティスが存在するかを教えます。 すでに、アジャイルエクスペリエンスはユビキタスな開発エクスペリエンスになっています。 インタビューでは、20人中19人が2週間のイテレーションに取り組んでおり、プロセスについて話すと、パラメータのリストになります。

-評価とは何ですか？

-ストーリーポイント。

-Velocityとは何ですか？

-68。

-プロジェクトをどのように計画しますか？

-S、M、Lの「tシャツ」の評価

これは非常に迅速な会話です。 現在のテクライドでは、すべてのプロセスパラメータを1時間で議論できます。 その後、彼らはチームと一緒に働きに行きますが、これにはスクラムマスターは必要ありません。 業界はこの役割をほぼ消化し、進んでいます。

もちろん、これはどこでもそうではありません。 確かに、市場標準に到達する必要がある多くの企業があり、これは迅速なプロセスではありません。 ロシアでは、10年後、組織が3人のプログラマーをアジャイルに移行することを決定したときに、「Lenoblkhozpromlespoval」でスクラムマスターとしての仕事を見つけることが可能になります。

人気のある間に、スクラムマスターはプロジェクトチーム内のすべての質問をPMから完全に拾い上げました。 彼らはそれを自分自身ではなく、チームメンバーに引き継いで、設計作業への関与を促進しました。 ちなみに、これにより、ビジネスの目でITの成熟度が大幅に向上しました。

またはまだ必要ありません

残っているものは何ですか？ 私は、柔軟な方法論に取り組むとき、他の役割によって解決されるタスクを強調する自由を取りました。

この後、プロジェクトマネージャーには何が残っていますか？ 残ったコミュニケーション、統合、調達。 この役割に献身的な人を維持することはあまりないようです？ PMが必要ないということです。 しかし、ありません。

まだ必要

ITプロジェクトには、専任のマネージャーがいない場合の障害が実質的に保証されるカテゴリがあります。

実世界のプロジェクト

モバイル開発に携わる人は、変更の速度とエラーのコストにより、事態はそれほどスムーズではないことを知っています。 モバイル開発のミスを見逃し、すぐに気づかなかった場合、視聴者全体を更新することは困難です。 一部のユーザーはアプリケーションを更新せず、エラーが残ります。 たとえば、この問題から、モバイルアプリケーションの機能をリモート制御するアプローチが拡大しています。

しかし、これはソフトウェア開発を管理するPMの苦痛の100分の1の部分です。たとえば、商品の規模が500万単位の倉庫の仕分けコンベアを管理する場合です。 そのようなプロジェクトでは、機器サプライヤへの数十の依存関係、反復が月単位で測定され、エラーの価格は桁違いに高くなります。

機器関連のプロジェクトは、デジタルの世界から私たちを現実へと戻します。そこでは、従来のPMBoKコントロールが依然として関連しています。

傘プロジェクト

アンブレラプロジェクトでは、柔軟な方法論が滑っています。 このようなプロジェクトは大規模で複雑です。 複雑さとは、明示的および暗黙的な依存関係を意味し、特定の規模では、専用のプロジェクトマネージャーを使用しない開発は非常に非効率的になります。 そのようなプロジェクトにおけるPMの主なタスクは、プロジェクトの統合、依存関係、およびタイミング管理です。

エラーのコストが高いプロジェクト

医療、航空、宇宙産業、軍事分野など、エラーを最大限に排除しなければならない産業は常に存在します。 これらの領域では、エラーが発生すると、人々が死亡するか、多くのお金が失われます。 例はインターネットで簡単に見つけることができます。 Arian-5欧州ミサイルに関する話から始めましょう。

そのような分野では、PMが引き続き需要がありますが、能力と経験の観点から、PMには非常に高い要求が課せられます。 そして、そのようなプロジェクトの割合が小さいほど、候補者の選択は難しくなります。

役割の一部を持たないプロジェクト

人生は厳しいものであり、それぞれの役割に専任の人を雇うことは常に可能ではありません。 世界が完全になるまで、プロダクトオーナーの仕事をするPMが残ります。 または事実上テクライドとして機能するPM。 このような組み合わせは、多くの場合、スタートアップの特徴です。

現在業界で行われているこれらのトレンドを時間内に延長すると、純粋な形でのPMの役割が、まだ自動化または配布方法がまだわからない少数のソフトウェア開発プロジェクトに関連したままになる未来があります。チームメンバー。

---

作成者：

著者-Dmitry Kruglov

編集者-ユージン・シュクリアー、デニス・ボンサロフスキー

一部の問題に関する著者の意見は、ブログおよびYandex.Money社の編集委員会の意見と一致しない場合があります。