神話神話人月
已發表: 2022-03-10作為一家科技公司的產品負責人，我是一個無底洞的需求。 作為 Mailchimp 的首席產品官，我的工作是將產品推向市場，從而在競爭激烈的領域中獲勝。 Mailchimp 的抱負很高，要實現這些抱負，我們需要向市場提供大量產品。 通常對公司的許多人來說，感覺我們做得太多了。 我們總是處於車輪脫落的邊緣。
當你做的太多而你決定做更多的事情時，你將不可避免地開始聽到提到的神話人月。 這就像一個減壓球，如果你擠壓一端，另一端就會彈出神話人物月。
這本書由 Frederick Brooks 於 1975 年出版（你還記得 1975 年，對嗎？當軟件開發 100% 類似於 2020 年的軟件開發時？），這本書在軟件工程師中相當有名。 具體來說，整本書中有一點很有名（如果他們讀過這本書，我不相信人們會讀到這一點）：
“......增加更多的人會延長而不是縮短時間表。”
輕鬆修復。 從現在開始，我只會讓女性參與項目（參見國王歸來和與安格瑪巫王的戰鬥）。
但是讓我們假設 Brooks 的觀點與所討論的軟件工程師的性別認同無關。 重點是：具有許多複雜的相互依賴關係的軟件很難構建。 每個人都需要共同努力來完成它。
當我將人員添加到團隊中時，他們需要加入並移植到項目中。 總得有人為他們安排合適的工作。 團隊必須進行溝通以確保他們的所有東西都能協同工作，並且每個額外的人都會以幾何方式增加溝通的複雜性。 在某些時候，增加人員會成為項目的負擔，而不是好處。
這是書中說明這一點的圖表：
這絕對是一個公平的觀點。 這就是為什麼我在工作中經常聽到它。 筋疲力盡的個人貢獻者和筋疲力盡的領導者都會把它扔掉——我們不能走得更快，我們不能做得更多，停止招聘，閱讀The Mythical Man-Month並絕望！ 唯一的解決方案顯然是停止增長並終止一些項目。
當我作為 CPO 說：“我們要做這件事！” 回答通常是，“好吧，那我們要殺什麼？” 神話人月將產品開髮變成了一場零和遊戲。 如果我們想要一件事，就必須阻止另一件事。 現在，這是一個真正的神話，我稱之為廢話。
考慮到其病態的誤解（我們會得出這個結論），這本書顯然說最快的科技公司是僱傭全部四個人的公司——顯然是四個人。 更多的只是減慢這一切。 有人應該向亞馬遜、蘋果和谷歌發送這本書的副本，這樣他們就可以修復明顯臃腫的組織。
這種方法的唯一問題是，在競爭日益激烈、迭代和執行的空間中——僅僅阻礙了組織的增長——編輯和集中工作負載以匹配可能會導致滅絕。 你會更清醒，壓力更小——直到你失業。
作為我公司產品管理的負責人，我對這種放慢速度和專注的需要並不同情。 我們必須毫不留情地優先考慮！ 毫無疑問。 但是運行產品是一種矛盾的練習。 我必須優先考慮我已經完成的工作，同時計劃完成更多工作。 但是面對神話中的人月我該怎麼辦？
令人驚訝的是，這個問題的答案來自布魯克斯的同一本書。 這是同一章中的另一個圖表：
在擴展產品開發方面存在一場戰鬥。 如果您嘗試完成的工作是完全可分區的，那麼請繼續添加人員！ 如果您的工作都是相互關聯的，那麼在某些時候添加人員就是錯誤的。
如果有人說我絕對必須終止一個項目才能開始另一個項目，事實並非如此。 如果這兩個項目需要很少的溝通和協調，那麼我們可以縮小規模。
這就是為什麼在 CPU 中添加內核可以將您的計算機或手機的體驗速度提高到一定程度——工程師應該知道的一切。 當然，添加內核不會幫助我完成複雜的單線程計算。 但它可能會幫助我運行一堆獨立的任務。
產品經理在擴展和無情的優先級之間的衝突可以得到管理。
- 你無情地優先考慮單線程的地方（比如說產品團隊的積壓工作）。
- 您可以通過添加更多內核來處理獨立工作來進行擴展。
然而，很少有任何事情完全獨立於公司的其他一切。 至少，您的公司將集中支持功能（全球 IT、法律、人力資源等），從而導致瓶頸。
一切都與依賴管理有關
產品主管的工作不僅變成了製定戰略，而且通過確保吞吐量和盡可能降低相互依賴風險以最大化客戶和業務價值的方式執行。 “盡可能”是這裡的關鍵。 這樣，您可以使公司看起來更像後者而不是前者。 相互依賴是一種無法治癒的疾病，但可以通過多種治療方法來控制其症狀。
一種解決方案是為公司製定戰略方向，通過精心挑選的舉措組合最大限度地減少或限制依賴性。 有趣的是，很多人會反對這一點。 假設我有兩種選擇，一種是我可以執行幾乎沒有協調的項目 A、B 和 C（假設它們影響不同的產品），另一種選擇是具有大量相互依賴的項目 D1、D2 和 D3（假設它們都影響同一個產品）。 通常情況下，神話人月將針對前一個計劃而不是後者被調用。 因為在紙上看起來更多。
確實，它不那麼“專注”。 但是，從依賴的角度來看，它實際上並不那麼困難，因此增加人員會更好。
請記住，我並不是說要為不相關的公司選擇一堆工作。 Mailchimp 不會很快製造微波爐。 所有工作都應該朝著同一個長期方向發展。 這種方法會增加客戶體驗風險（我們將在後面討論）以及客戶研究等全球職能部門的負擔。 請注意這一點。
另一種處理方法是創建一個產品和程序管理流程，以便在必要時促進依賴關係協調和溝通，而不會使團隊在不需要時的協調負擔過重。 有時在嘗試管理協調以便我們可以做更多事情時，我們最終會創建如此繁重的流程，以至於我們最終做得更少。 這是在協調太少導致碎片無法互操作和協調太多導致碎片永遠無法構建之間的平衡，因為我們都在永遠站立。
Mythical Man-Month中的論點是，當您將人員添加到軟件項目中時，溝通需要以幾何級數增加。 例如，如果項目中有 3 個人，那就是 3 條溝通渠道。 但如果你有 4 條，那就是 6 條通信線路。 在這種情況下，一個額外的人會導致雙倍的溝通！ 樂趣。 （當然，這是對軟件開發項目溝通的過度簡化。）
不同的人有不同的角色，因此獲得不同程度的自主權。 也許項目經理需要與團隊中的每個人溝通。 但是開發 API 的工程師需要與產品營銷人員溝通嗎？ 還是營銷人員可以直接通過產品經理？ 一個好的流程和會議節奏可以消除不必要的溝通和會議。 關鍵是布魯克斯的互通公式是協調的上限，而不是死刑。
最後，使用工具、原則和框架結合獨立工作而不是實際協作來對抗相互依賴症狀。 例如，如果我可以協調兩個團隊的關鍵績效指標（KPI，即成功的衡量標準）來激勵或多或少相同方向的運動，那麼他們的獨立工作更有可能最終“更緊密地聯繫在一起”，而不是如果他們的 KPI 激勵正交運動。 這並不能確保事情完美地結合在一起，只是為了讓它們在未來結合在一起，我需要做的工作比其他情況下要少。 其他示例可能包括使用“均勻”語句、設計系統和自動化測試。
所以有一個開始。 但是相互依賴在代碼之外還有很多形式。 讓我舉一個 Mailchimp 的例子。
客戶體驗風險：防火牆工作的隱藏（但可以接受？）成本
由於 Mailchimp 的客戶通常是營銷新手的小企業主（全球有數百萬小企業主轉變為營銷人員），因此我們必須提供無縫且可立即理解的端到端體驗。 我們無法像企業玩家那樣通過收購來組裝弗蘭肯斯坦的雲怪物。 我們不能用顧問和客戶經理來掩蓋集成不良的軟件。
作為消費產品（想想 Instagram 或 Nintendo Switch 或 Roomba），我們必須開箱即用。 對於一個旨在為您的業務提供動力的一體化營銷平台，這很難！ 這意味著 Mailchimp 構建的每一件事都必須從體驗的角度無縫連接。
但是，完美劃分項目會帶來經驗風險。 並不是說代碼不能獨立編寫。 這是可以實現的，但仍然存在產品看起來像是由不同團隊構建的風險，並且這種體驗可能會讓用戶感到非常困惑。 我們違反了康威定律——我們的客戶可以知道一個團隊的工作在哪裡結束，而另一個團隊的工作從哪裡開始。
因此，您嘗試將每個人的工作聯繫在一起——不僅在後端，也在前端。 在生態系統時代，以蘋果等公司的卓越客戶體驗為主導，這幾乎已成為消費領域的賭注。 但這是一個神話般的人月噩夢，雖然這次不是從工程的角度來看。 這是從服務設計的角度來看的。 隨著我們在所有這些“端到端”連接的工作中增加更多的人，一切都變慢了協作爬行。
除了我上面提到的第三個修復之外，使用工具和框架而不是過度觀察者和階段閘門，還有另一個釋放閥：做出一些慎重的客戶體驗權衡。 具體來說，我們在哪裡可以輕鬆地發布與其他體驗脫節的體驗（即低於標準的體驗）？ 接受風險並繼續前進是產品負責人的工作。 因此，您使用一些標準對其進行分類（也許它不會將應用程序的新的、低流量的區域與您的“搖錢樹”保持相同的體驗標準），並做出決定（例如迭代和學習對相鄰區域的優化）創新）。 當然，這超出了設計範圍。
您始終可以通過選擇防火牆來縮短布魯克斯定律，包括在完美世界中不應設置防火牆的工作！
“
我將通過說我構建的軟件不會殺死任何人來警告這一點。 如果我正在製造醫療設備，我不會提倡這種方法。 但是在一家營銷軟件公司，我可以故意隔離團隊，因為我知道我增加了不兼容的可能性，作為擴大人員規模和加快行動速度的權衡。
我很遺憾地承認，在我的公司裡，神話般的人月是一個現實，我也懷疑在你的公司裡。 但它是可控的——這是底線。 並行化和依賴性緩解為我們提供了一條限制神話人月的近乎神話狀態的出路。 因此，下一次在您的公司提出明顯的二分法時（擴大規模以放慢速度或放棄您的抱負）請記住，如果您對如何安排工作很聰明，您仍然可以發展壯大。
不要忘記縮放的較軟的一面
請記住，管理神話人月不會阻止工程師像黑魔法一樣調用它。 他們之所以援引這一原則，不僅是因為其中有一些道理，而且因為從情感和認知的角度來看，縮放（總是）很糟糕。 如果我認為編寫代碼和解決客戶問題是有報酬的，那麼我最不想做的就是改變我的日常工作並弄清楚如何與新人和更大的團隊合作。
當你擴展你的公司時，記住要理解擴展和改變的痛苦。 從信任和文化的角度來看，即使增加一個成員的團隊也會成為一個全新的團隊。 人們厭倦了這種變化。 這意味著當你開始管理和緩解神話般的人月時，你需要管理圍繞增長的情緒。 這也許是最關鍵的任務。
團隊本身對神話人月的堅定信念可以將其結論變為現實。 這基本上相當於彼得潘的飛行信念。 如果團隊認為擴展會減慢他們的速度並且他們不接受這種變化，那麼他們確實會放慢速度。
因此，當您努力管理依賴項並引入有助於擴展的工具時，請確保您清楚地傳達實踐背後的原因。 讓人們參與選擇減輕人月問題的工作和流程，因為當他們參與變革並且他們的前景發生變化時，突然擴展至少在文化上成為可能。