神話の神話の男-月
公開: 2022-03-10テクノロジー企業の製品リーダーとして、私は底なしのニーズの落とし穴です。 Mailchimpのチーフプロダクトオフィサーとしての私の仕事は、非常に競争の激しい分野で勝つことになる製品を市場に出すことです。 Mailchimpの願望は高く、それを実現するには、かなりの量の製品を市場に提供する必要があります。 多くの場合、会社の多くの人にとって、私たちがやりすぎているように感じます。 私たちは常に車輪が外れる端にいます。
そして、あなたがやりすぎて、それ以上のことをすることに決めたとき、あなたは必然的に神話の男-月が言及されているのを聞き始めるでしょう。 それは、一方の端を絞ると、もう一方の端に神話の男月が飛び出すストレス解消ボールの1つに似ています。
1975年にFrederickBrooksによって発行されました（1975年を覚えていますか？ソフトウェア開発が2020年のソフトウェア開発に100％似ていたとき？）、この本はソフトウェアエンジニアの間でかなり有名です。 具体的には、本全体の中で有名な点が1つあります（本を読んだことがある場合は、この点以外は何も読まないとは思いません）。
「...男性を追加すると、スケジュールが短くなるのではなく、長くなります。」
簡単な修正。 これからは女性をプロジェクトに配置します（王の帰還とアングマールの魔女王との戦いを参照）。
しかし、問題のソフトウェアエンジニアの性同一性に関係なく、ブルックスの主張が成り立つと仮定しましょう。 重要なのは、複雑な相互依存関係がたくさんあるソフトウェアを構築するのは難しいということです。 そして、それを成し遂げるために、誰もが協力する必要があります。
私がチームに人を追加するとき、彼らはプロジェクトに参加し、移植する必要があります。 誰かが彼らのために正しい仕事を切り開く必要があります。 チームは、すべてが連携して機能することを確認するためにコミュニケーションをとる必要があります。また、人を追加するたびに、コミュニケーションの複雑さが幾何学的に増大します。 そして、ある時点で、人を追加することはプロジェクトの負担になりますが、利益ではありません。
その点を説明する本のグラフは次のとおりです。
これは絶対に公正な点です。 そういうわけで私は仕事でそれをとても聞く。 疲れ果てた個人の貢献者と疲れ果てたリーダーは同様にそれを投げ出します—私たちはより速く行くことはできません、私たちはそれ以上のことをすることはできません、雇用を止め、神話の男-月と絶望を読んでください！ 唯一の解決策は、明らかに成長を停止し、いくつかのプロジェクトを殺すことです。
私がCPOとして言うとき、「私たちはこのことをするつもりです！」 その場合、「OK、では何を殺すのか」という返事がよくあります。 Mythical Man-Monthは、製品開発をゼロサムゲームに変えます。 あることをしたいのなら、別のことをやめなければなりません。 さて、それは実際の神話であり、私はホグウォッシュと呼んでいます。
そして、病理学的に誤解されている（これについて説明します）結論を踏まえると、この本は明らかに、最速のテクノロジー企業は4人全員（4人の男性）を雇用している企業であると述べています。 それ以上のものはすべてを遅くします。 誰かが本のAmazon、Apple、およびGoogleのコピーを送信して、明らかに肥大化した組織を修正できるようにする必要があります。
このアプローチの唯一の問題は、競争が激化しており、反復と実行が行われているスペースでは、組織の成長を妨げるだけであり、それに合わせてワークロードを編集して集中させることが、絶滅の秘訣になる可能性があることです。 仕事がなくなるまで、あなたはより正気でストレスが少なくなります。
そして、私の会社の製品管理の所有者として、私はこの減速と集中の必要性に同情していません。 私たちは冷酷に優先しなければなりません！ 間違いない。 しかし、製品を実行することは矛盾した運動です。 私は自分が持っているものに優先順位を付け、同時により多くのことを成し遂げるために計画を立てなければなりません。 しかし、神話の男月に直面して私は何をすべきでしょうか？
驚いたことに、この質問への答えはブルックスの同じ本から来ています。 同じ章の別のグラフは次のとおりです。
製品開発のスケーリングには戦いがあります。 達成しようとしている作業が純粋にパーティション化可能である場合は、先に進んで人を追加してください。 あなたの仕事がすべてつながっているなら、ある時点で人を追加するのは間違っています。
別のプロジェクトを開始するために絶対にプロジェクトを強制終了する必要があると誰かが言った場合、そうではありません。 2つのプロジェクトで必要なコミュニケーションと調整がほとんどない場合は、規模を縮小できます。
これが、CPUにコアを追加することで、コンピューターまたは電話の経験豊富な速度をある程度まで向上させることができる理由です。これは、エンジニアが知っておくべきことです。 確かに、コアを追加しても、複雑なシングルスレッドの計算を完了するのに役立ちません。 しかし、それは私がたくさんの独立したタスクを実行するのを助けるかもしれません。
スケーリングと冷酷な優先順位付けの間の製品エグゼクティブの対立を管理することができます。
- シングルスレッドの場所では、容赦なく優先順位を付けます（たとえば、製品チームのバックログ）。
- 独立した作業を処理するためにコアを追加することでスケーリングします。
ただし、会社の他のすべてから完全に独立しているものはほとんどありません。 最低限、あなたの会社はボトルネックにつながるサポート機能（グローバルIT、法務、人事など）を一元化する予定です。
依存関係の管理がすべてです
プロダクトエグゼクティブの仕事は、戦略を立てるだけでなく、スループットを確保し、相互依存のリスクを可能な限り減らすことで、顧客とビジネスの価値を最大化する方法で実行することになります。 ここで重要なのは「可能な限り」です。 そうすれば、会社を前者ではなく後者のグラフのように見せることができます。 相互依存性は治療法のない病気ですが、その症状は多くの治療法で管理できます。
1つの解決策は、慎重に選択されたイニシアチブのポートフォリオを通じて、依存関係を最小化または制限する企業の戦略的方向性を組み立てることです。 ここで面白いのは、多くの人がこれを後押しすることです。 2つのオプションがあるとしましょう。1つは調整がほとんどないプロジェクトA、B、Cを実行でき（たとえば、異なる製品に影響を与える）、もう1つは相互依存性が高いプロジェクトD1、D2、D3を使用するオプションです（それらがすべて同じ製品に影響を与えるとしましょう）。 Mythical Man-Monthは、後者ではなく前者の計画に対して呼び出されることがよくあります。 紙の上ではもっと見えるからです。
確かに、それはあまり「焦点を絞っていない」。 ただし、依存関係の観点からは実際にはそれほど難しくないため、人員を追加することで公平性が向上します。
覚えておいてください、私は関係のない会社のためにたくさんの仕事を選ぶと言っているのではありません。 Mailchimpはすぐに電子レンジを構築する予定はありません。 すべての作業は、同じ長期的な方向に進む必要があります。 このアプローチは、顧客体験のリスク（後で説明します）だけでなく、顧客調査などのグローバル機能への負担を増大させる可能性があります。 それに注意してください。
もう1つの処理は、必要に応じてチームに調整を過度に負担させることなく、必要に応じて依存関係の調整とコミュニケーションを容易にする製品およびプログラム管理プロセスを作成することです。 より多くのことができるように調整を管理しようとすると、やっかいなプロセスが作成されて、作業が減ってしまうことがあります。 これは、調整が少なすぎてピースが相互運用できなくなることと、調整が多すぎてピースが構築されないこととのバランスです。これは、私たち全員が永遠に立ち上がっているためです。
Mythical Man-Monthでの論点は、ソフトウェアプロジェクトに人々を追加するにつれて、コミュニケーションを幾何学的に増やす必要があるということです。 たとえば、プロジェクトに3人いる場合、それは3つのコミュニケーションラインです。 しかし、4つある場合、それは6つの通信回線です。 この場合、1人余分に人がいると、コミュニケーションが2倍になります。 楽しい。 （もちろん、これはソフトウェア開発プロジェクトでのコミュニケーションの過度の単純化です。）
さまざまな人々がさまざまな役割を持っているため、さまざまな量の自律性を受け取ります。 おそらく、プロジェクトマネージャーはチームの全員とコミュニケーションをとる必要があります。 しかし、APIに取り組んでいるエンジニアは、製品のマーケティング担当者と通信する必要がありますか？ それとも、マーケティング担当者は製品マネージャーを経由するだけでよいのでしょうか。 優れたプロセスと会議のリズムにより、不要なコミュニケーションと会議を排除できます。 重要なのは、ブルックスの相互通信の公式は、死刑判決ではなく、調整の上限であるということです。
最後に、相互依存の兆候と戦うために、実際のコラボレーションに対する独立した作業と組み合わせたツール、原則、およびフレームワークを使用します。 たとえば、2つのチームの主要業績評価指標（KPI、つまり成功の測定値）を調整して、ほぼ同じ方向への動きを奨励できる場合、それらの独立した作業は、場合よりも「より近く」になる可能性が高くなります。それらのKPIは、直交運動を奨励します。 これは物事が完全に調和することを保証するものではなく、将来それらを調和させるために私がしなければならない仕事がそうでない場合よりも少ないということだけです。 他の例としては、「偶数」ステートメント、設計システム、自動テストの使用などがあります。
だから、スタートがあります。 しかし、相互依存関係は、コード以外にも多くの形を取ります。 Mailchimpの例を挙げましょう。
カスタマーエクスペリエンスのリスク：ファイアウォール作業の隠れた（しかし許容できる？）コスト
Mailchimpの顧客は、マーケティングの初心者である中小企業の所有者であることが多いため（そして、世界中に何百万もの中小企業の所有者がマーケターに転向している）、シームレスですぐに理解できるエンドツーエンドのエクスペリエンスを提供する必要があります。 フランケンシュタインの雲の怪物を、企業のプレーヤーができる方法で買収して組み立てるという贅沢はありません。 統合が不十分なソフトウェアについて、コンサルタントやアカウントマネージャーと話し合うことはできません。
消費者向け製品（Instagram、Nintendo Switch、Roombaなど）として、箱から出してすぐに使用できる必要があります。 あなたのビジネスを強化することを目的としたオールインワンのマーケティングプラットフォームにとって、それは難しいことです！ つまり、Mailchimpが構築するものはすべて、エクスペリエンスの観点からシームレスに接続されている必要があります。
ただし、プロジェクトを完全に分割すると、経験上のリスクが発生します。 コードを独立して記述できないわけではありません。 それは達成できますが、製品が異なるチームによって構築されたように見えるリスクがあり、その経験はユーザーにとって非常に混乱する可能性があります。 私たちはコンウェイの法則にぶつかります。お客様は、一方のチームの作業がどこで終了し、もう一方のチームの作業がどこから始まるかを知ることができます。
そのため、バックエンドだけでなくフロントエンドでも、すべての人の作業を結び付けようとします。 アップルのようなプレーヤーからのCXの卓越性によって支配されたエコシステムの時代では、これは消費者の分野でほとんどテーブルの賭けになっています。 しかし、これは神話上の人月の悪夢ですが、今回はエンジニアリングの観点からではありません。 これは、サービス設計の観点からです。 この「エンドツーエンド」の接続された作業すべてにさらに多くの人を追加すると、すべてが共同作業に遅くなります。
上記の3番目の修正以外に、オーバーウォッチャーやステージゲートではなくツールとフレームワークを使用して、別のリリースバルブがあります。それは、意図的なカスタマーエクスペリエンスのトレードオフを行うことです。 具体的には、他の部分から切り離された（つまり、標準以下の）エクスペリエンスをリリースするのに快適な場所はどこですか？ リスクを受け入れて前進することが、製品リーダーの仕事です。 そのため、いくつかの基準を使用して分類し（おそらく、アプリの新しいトラフィックの少ない領域を「ドル箱」と同じエクスペリエンス基準に保持していない）、決定を下します（たとえば、隣接するものでの反復と磨きの学習イノベーション）。 もちろん、これは設計を超えています。
完璧な世界ではファイアウォールで保護されるべきではない取り組みを含め、ファイアウォールでの取り組みを選択することで、ブルックスの法則をいつでも短絡させることができます。
「「
私が構築したソフトウェアは誰も殺さないと言って、これに注意します。 私が医療機器を製造している場合、私はこのアプローチを支持しません。 しかし、マーケティングソフトウェア会社では、人員を増やしてより速く移動することのトレードオフとして、非互換性の可能性を高めたことを知っているチームを意図的に隔離することができます。
Mythical Man-Monthが私の会社では現実であると認めるのは悲しいことですが、あなたの会社でもそうだと思います。 しかし、それは管理可能です—それが最終的な収益です。 並列化と依存関係の緩和は、 MythicalMan-Monthの神話に近いステータスを制限する方法を提供します。 ですから、次にあなたの会社で厳しい二分法が提起されたとき（遅くなるか、またはあなたの願望をあきらめるためにスケールする）、あなたが仕事をどのように並べるかについて賢いなら、あなたはまだ大きくなることができることを覚えておいてください。
スケーリングのソフト面を忘れないでください
Mythical Man-Monthを管理しても、エンジニアが黒魔術のようにそれを呼び出すのを止めることはできないことに注意してください。 彼らはその中にいくつかの真実があるという理由だけでなく、スケーリングが感情的および認知的観点から（常に）ただ吸うという理由で原則を呼び出しています。 私がコードを書いて顧客の問題を解決するためにお金を払っていると思うなら、私がしたい最後のことは私のルーチンを変えて、新しい人々とより大きなチームと働く方法を理解することです。
会社を拡大するときは、拡大と変化の苦痛に共感することを忘れないでください。 メンバーを1人でも追加したチームは、信頼と文化の観点からまったく新しいチームになります。 人々はこの変化にうんざりしています。 つまり、 Mythical Man-Monthの管理と軽減に取り組む一方で、成長を取り巻く感情を管理する必要があるということです。 それはおそらくすべての中で最も重要なタスクです。
チーム自体によるMythicalMan-Monthへの強い信念は、その結論を実現することができます。 これは基本的に、ピーターパンを飛ぶという信念に相当します。 チームがスケーリングによって速度が低下すると信じており、変更に同意しない場合は、実際に速度が低下します。
したがって、依存関係を管理し、拡張に役立つツールを導入する際には、プラクティスの背後にある理由を明確に伝えるようにしてください。 人月の問題を軽減する作業とプロセスの選択に人々を参加させます。なぜなら、彼らが変化の一部であり、見通しが変化すると、突然スケーリングが少なくとも文化的に可能になるからです。