賈伯斯規定每個專案的人數不得超過一百人的故事,不過團隊的人數增加在任何一個業界都是百害而無一利。
美國軟體工程師福瑞德.布魯克斯(Frederick Phillips Brooks)二○○四年出版《人月神話:軟體專案管理之道》(The Mythical Man-Month: Essays on Software Engineering,繁體中文版由經濟新潮社出版),書中提到為了縮短專案工期而增加人力,進度反而會拖延。
一如【圖4-7】所示,在系統開發的世界裡,十個人要花十個月才能完成的專案會形容成一百個月,此時若將人數改成二十人,也無法將工期縮短為五個月。
我過去曾多次挽救快要來不及完成的系統開發專案,而每次最先著手改善的就是減少人數,因為這些專案的專案經理都是因為誤信「程式設計師的人數不足,所以專案才會一拖再拖」的說法,才導致專案的進度一再落後。
反過來說,只要減少人數,就能不再繞遠路,專案也會跟上進度。
接下來本節將按部就班,介紹打造小團隊的方法。
每增加一人,產能就跟著下降
請大家回想一下,公司有新同事報到的情景。
這位新同事報到之後,理論上,舊員工的工作量應該會減少才對吧?
不過,其他成員真的會因為多了這位新同事,而不用常常加班嗎?
如果這位新同事真的像是超人降臨,所有人或許可以不用再加班,但大多數都不是這樣,即使人數增加,所有人還是一如往昔地加班。
有趣的是,假設這位新人調到其他部門,就會發現原本按照進度執行的工作突然停擺,這其實是因為我們習慣製造新的工作。
英國政治分析學家西里爾諾斯古德帕金森(Cyril Northcote Parkinson)在《帕金森定律》(Parkinson’s Law)書中提到:「工作量會隨著參與人數呈正比增加」。
各位讀者是否都有過下列這種經驗:
●明明換了更大台的冰箱,卻還是一下子就塞滿,而且要報廢的食品反而變多。
●明明買了儲存空間加倍的智慧型手機,但是影片與應用程式卻變得更多,儲存空間一下子就不夠用了。
●明明升了官、加了薪,但是存款還是沒有變多。
簡單來說,只要資源增加,就會不自覺用掉增加的資源,所以在增加團隊成員之前,務必三思而後行。
例行公事盡可能不要由內部負責
不管是哪個團隊,當然都渴望怪物級的新同事報到,各位讀者應該也有過不少次「這麼一來,工作就會變得比較輕鬆」的期待對吧?
要是結果一如預期,那當然是再好不過的事,但各位可別忘記,例行公事還是一個人做最有效率。
如果只是單純的例行公事,可寫個程式自動完成,也可以發包給便宜的外國公司負責,雖然這兩種方式在一開始都得投入一定的成本,但從後續的效率來看,還是有一試的價值。
比方說,我曾透過下列的嘗試減少例行公事。
●花了一週寫了統整五十個部門的Excel檔案的Excel巨集,讓原本需要花三天整合的工作縮短成五分鐘。
●取得資料之後,不在日本確認資料的內容,而是外包給菲律賓的公司,以兩倍的人數進行確認,藉此大幅削減成本與提高正確率。
建議大家盡可能讓這類工作內包轉外包,將時間用在需要發揮創意的工作。
應用「兩個披薩原則」
到目前為止,介紹了不少小團隊的優點,但到底是幾個人以下的團隊才算是小團隊呢?
對此,我總是不斷提醒自己記得亞馬遜網站創辦人貝佐斯(Jeff Bezos)所提倡的「兩個披薩原則」。
這個亞馬遜的原則是指「團隊的規模不要超過兩個披薩能夠餵飽的人數」,以兩個披薩可餵飽的人數來看,差不多是五個人的小團隊吧?
此外,準備如【圖4-8】所示,擴大組織的時候,也可以應用「兩個披薩原則」訂定相關的制度。比方說,由各團隊負責人參加的會議若以五人為上限,就能打造一個五乘以五等於二十五人的大團隊,然後底下的小團隊則由小團隊的負責人管理。
如果是能隨時看到彼此的五人團隊,就不需要另外建立分享資訊的制度。不過,當團隊的規模擴大至二十五人,就得建立分享資訊的制度或是最基本的上班規矩。
如果團隊人數超過二十五人,該怎麼辦?
此時就必須建立各種制度,讓分成三個階層的組織得以正常運作。