釋出一個軟體，需要多少人？

“換一個燈泡需要多少個______？” 類似的笑話有無數個版本。

有時候我在工作中嘲笑我們的專案牽扯了太多人。這個專案大約需要三個月，包括我和另一個程式設計師還有 20 – 30 個其他人可以算進來。由數不清的副總（VP）經過大約 6 個月的評審之後，所有的需求都定妥了，但變更還是不斷出現。 最重要的是，它跟另一個團隊的專案沒什麼區別（但是程式碼卻不能重用），而那個專案已經快要釋出了。

為什麼要這麼多人？為什麼大公司要用大團隊做出不那麼大的東西，這真是個謎。我得出的結論是，你給一個專案投入的人越多，你就需要越多的人來管理這些人，再加上管理這些管理者的人，等等等等。“團隊越大，人數就越多；人數越多，團隊就越大。”

回顧1988年，我們開發了 Deltagraph，在圖表/圖形列印細分市場曾處於領先地位。但整個團隊只是 4 個程式設計師，還有一個負責我們專案的 QA，而軟體發行商則有一個 QA 和一個產品經理。就這些人，做出的產品在大小和複雜程度上接近1993年前的 Excel。直到我們開發產品的最後一個版本時，發行商才給我們加了幾個人。

我之前第三個工作是在一家知名旅遊公司（可惜現在是別人的了），全球有1000名左右的員工。我們的移動開發團隊有20個人左右，但是截至去年我們就提升銷售額 15%，如果我們繼續做下去將可以達到到 20% 。我們維護 7 個不同的應用（原生和web端）和一個移動 API。有QA，有產品經理，設計師和程式設計師，多數時間在一處工作，由一個經理全權管理。我們的 API 和 web 應用是自己在 AWS 上搭建的。公司其他部分在美國和歐洲各有一個主網站。我們每年平均釋出 70 -80 次，主網站一年也改不了幾次。

我以前講到過一款app，我們用很少的人、花了兩個月開發的，而且app會成為什麼樣一開始也無從得知。 (原網址如果無法開啟，可參考 bing.com 快取頁 )

我作技術顧問（不是承包商）的時候，工作內容是幫助客戶解決問題，經常是一個人同時當分析師，專案經理，架構師，程式設計師和 DBA，有時還不得不設計非計算機系統的流程。我記得我們用了近一年時間參與一個大專案，只有兩個人，什麼都做。

有時我驚訝於小型初創公司沒有多少人、僅一點點管理就作出讓人叫絕的產品，但由於我也有過類似經歷，至少我能想象他們是怎麼做到的。我一直認為最小規模的團隊能實現卓越的產品，只要能掌控做什麼、怎麼做。通常大公司的情況是每個人都要控制所有事，大規模的精細分工，僅僅是為了讓眾多團隊都能分一杯羹。

專案裡的人越多，你需要的溝通和管理就越多，資訊傳遞和問題報告就越慢。你必須用更多的流程來確保工作得以完成。當然，耗費的時間和金錢也更多，所以你經常要捨棄產品特性，只是為了把東西釋出出來。任何需要管理一大堆人的負責人，都會擔心難以預料的問題突然冒出來咬他們一口，所以決策就變得保守和謹慎。很自然地，這會讓釋出產品既困難、又費錢，而且經常拖延很久。再加上以前有著類似問題的專案留下的陰影，工作會更加的小心謹慎、慢慢吞吞。

相比之下，小型創業公司就不會受限於謹慎的作風、繁瑣的流程、孤立的管理和憂慮。即使我們那個旅遊移動專案組也甘冒風險，使用小團隊、嘗試 AWS 這樣的新事物而不是自行建造一個帝國，儘管我們處於一個龐大笨重的商業實體內。我們是在這樣的條件下做到的：在一開始就沒有任何管理上的支援，只是希望把移動產品推出來趕個時髦，這使得團隊保持精幹，同時帶來了越來越多的銷售額。

看看政府專案，你會禁不住笑話他們，搞那麼多人來管所有事情。我記得在諮詢公司工作的時候，有兩個人為美國國防部的一個專案工作，從主承包商那兒算下來，他們大概是四或五級分包商。經常的情況是，他們不知道發生了什麼也不知道該做什麼。最近的一個笑話是 TSA（Transportation Security Administration，美國運輸安全管理局）花了 $350,000 做的 app，除了兩個箭頭和一個 random() 呼叫什麼都沒有，這個例子也太搞笑了。有個地方，我曾在那兒做架構師，他們有個專案我預估需要 2 個人周的編碼。他們花了六個月、經過幾十次的會議和一份 120 頁的需求文件，得出了同樣的結論。我們本可以把這 app 做十次還多，而那些人在會上都幹了什麼呢？

有些跟我合作的人，他們幾乎沒空寫程式碼，總是被繁多的會議和電話纏身，根本無法再勝任工程師工作。時間都耗費在協調、解釋、計劃、爭執和籌備那些一成不變的事情上，根本沒有多少時間用於產出。

謝天謝地，在我整個 35 年的程式設計師生涯裡參與的唯一一個大型團隊專案，是在墨西哥的一次三個月的“死亡之旅”，結果最後什麼也沒做出來。有時候，你需要更多的人和更詳細的計劃，比如開發一個 OS，但多數時候更少的人始終是更好的。再強調一次，只要這幾個人能掌控做什麼、怎麼做。你不能使用最小團隊然後把流程、標準、報告和會議等一股腦的堆過來還指望他們出活兒。

我現在工作的地方，即使程式碼寫完了，也還是要跟好幾個小組見面、評審、填表、協調、得到不同的 VP 簽字，才能進行下一步，哪怕釋出到測試環境也是如此。搞這麼多的流程真是瘋了。我猜其他的地方也沒什麼區別甚至更糟糕吧，這也確實增加了不少就業機會。

我還肯定，很多人認為所有的這些審慎的複雜性是必須的，或至少讓高層感覺更穩妥。有時候這些也許是必須的（我從未給核電站寫過程式碼），但是我見過的所有大型團隊專案裡，多數從未真正讓參與的人發揮全部作用。

如果你有一個具有大量自主權的極其精幹的團隊，你的成就將超出你的想象。但是公司是不願意冒這個險的，他們更喜歡建立一個帝國，臣民的責任範圍越來越窄，這樣就能讓更多的人蔘與，並且讓領導層自我感覺重要。你真的需要創新/設計、動畫、模仿、專案管理、產品管理、發行管理、開發管理、推廣管理、運維、DBA、多層的QA還有其他我壓根兒不知道的東西，加上好幾層 VP，來釋出一個只需兩個程式設計師的作品嗎？

我打賭你不會的。我懷念那些小團隊、大產出的日子。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者