因緣際會在開發同事B的桌上看到一本書《人月神話》(The Mythical Man-Month),第一個反應(恕我孤陋寡聞.),怎麼一個軟體開發進度管控的人會看這種”神話”故事呢?好奇的拿起來翻閱了一下,我才知道這是一本暢銷了近三十年的書籍,講的就是軟體開發的管理,活靈活現的,讓我一讀不可收拾…
我不是來推薦圖書的,因為過去幾年工作下來,除了主導過幾個軟體開發專案外,還有一些管理上有待釐清的疑慮,正如先前跟一位軟體開發幾十年的前輩洽談之後,他也表示,軟體開發雖然有幾十年的歷史,但仍舊是一個新興的產業,很多管理上的規範,仍舊沒有一個標準,大家都是根據一些經驗,自己找出一條管理的路…
為什麼說軟體專案管理大不易呢?因為它具備了幾種特性,複雜性(complexity)、一致性(conformity)、易變性(changability)、不可見性(invisibility)…
我想先表達一個觀點,我非常認同作者Frederick P. Brooks, Jr.所說的一句話,也是本書的重要觀點,「在一個時程落後的軟體專案增加人手,只會讓它更加落後….」,分享一下我過去帶領軟體開發的心得來對比《人月神話》一書的觀點吧…
我認為在軟體專案開發的過程中,第一個問題就是開發需求一再變動,而這個變動產生自從頭到尾沒有很清楚的知道想要做的是什麼東西,因為一般企業普遍面臨著時間、資金的壓力,經營成本不小,又有不少的競爭對手,因此一般都是先作再說,但這就造就了,開發的過程需要變更需求,因為過程中原本預想的實現方式,也許時間過高,也許成本過高,也許根本就做不到,而這是一種致命的傷害,輕則開發進度落後,重則做出一個四不像的軟體產品,因此作者提到所謂的第二系統效應,以及需求規劃與溝通的重要性,他認為一個軟體專案的開發,其實前期規劃的時間應為整個時程的1/3,而真正寫程式的時間其實只有1/6…
第二點,溝通與進度掌控的重要性,延續上述的概念,規劃的時間至少是整個專案時程的1/3,就是要把概念跟其他部門溝通清楚,並且跟每個開發的工程師也溝通清楚,甚至在開發的過程中都需要不斷的跟進溝通,作者引用了聖經啟示錄中巴別塔的故事,因為所有餐與建築巴別塔的人員彼此間語言不同無法溝通導致了失敗,突顯了溝通的重要性,經常開發上一個小細節沒有溝通清楚,導致了南轅北轍的結果,這不僅浪費時間,也導致開發成本的增加,所以除了溝通之外,隨時要掌控即時的開發進度,作者提到,「為什麼專案會落後一年,因為每次落後一天」,就是如此的無關痛癢造成的,其實同樣的,李開復先生在其《世界因你不同》一書中,也專章提到利用白板做為研發溝通工作的重要性…
第三點,或許這點有些爭議,至少對於公司的管理層,因為軟體專案的開發是一個團隊的工作,團隊的合作很重要,團隊每個人各司其職,但他們必須對於這個專案整體都了解,如果他沒有通盤了解整個專案的目的與邏輯,很可能他完成的程式是無法使用的,這就如同外科手術一樣,然而,站在公司的立場,總是希望公司的商業機密越少人知道越好,這必須要突破,或者找出一個折衷的方式,不然專案成果將跌破大家的眼鏡…
第四點,軟體測試以及系統商品化的整合過程,較有經驗的工程師懂得幫自己預留較多的測試時間,因為軟體開發本身具有較高的不確定性,然而,如果公司所給的專案開發時間有限,那麼測試以及整合的時間也受到壓迫,最終導致一個不穩定、不好用的軟體系統商品,這點作者就提到寫程式的時間容易估算,但是除錯(debug)是個大學問,而除錯以及軟體整合的過程,經常是造成整個專案延誤的主因,所以作者說,依據他的經驗,除錯以及系統整合測試的時間應該安排一半的專案時間,因為這是軟體專案過程中,最難也最耗時的部份,而這點對於不懂軟體開發的人來說,非常不可思議…
最後一點,開發工程師的素質以及人數,這也是本書《人月神話》的主要觀點,軟體專案開發一般以「多少人、幾個月」的方式來評估成本,但是軟體開發並不像種田一樣,加越多人進來進度就越快,相反的因為人越多溝通成本越大,更可能導致一個已經延誤的專案,進度更慢,這是因為軟體開發是一種腦力智慧,中途換工程師或者新增工程師,往往需要不少時間來熟悉溝通,因而導致了時間的延誤,再者,工程師的素質也有很大的差別,作者就提到一個熟手甚至比十個生手還堪用,這也是軟體開發的一大特性,而這也就是作者質疑以「人月」來評估軟體開發成本的一大弊端…
其實,進度延誤應該是經常會發生的事情,我想不盲目加人是個關鍵,更重要的是大家坐下來檢討進度落後之因,透過分析找出趕上進度的方式,是否有哪些功能規劃有缺失,或者是工程師對於需求的掌控度有落差,這才是根本的解決之道…
閱讀了《人月神話》之後,我又想到了一個更有趣的課題,軟體開發過程有苦有樂,而為何我們所生活的世界中,卻有越來越多免費的open source誕生呢?甚至這些open source更是多半走在科技產業的最前端,如果這些專案不是這樣的非營利團體來進行,而是在某個知名的軟體公司之內,又將是什麼情況呢?
B看来是Brian了 哈
建議也看一下『Peopleware』。與這本書算是專案管理裏算相當經典的2本。作者個性是完全不同,但一樣有經驗與真本事。
@Eric, 恩,這本書也有,正準備看!
我遇過最多的就是老闆給的時間太短,導致沒有時間整合與測試,所以軟體上線後總有處理不完的bug。
記得這本書中有一句話,印象深刻,”不管科技再怎麼變,人還是人”。
您不能不知道,專案管理軟體界的一匹黑馬
介紹您2010年度雲端專案管理軟體 – 雙料冠軍 – Clarizen.
> 2010美國資訊與軟體產業協會最佳專案管理軟體大獎冠軍
> 2010Top10Reviews年度最佳雲端專案管理軟體大獎冠軍
30天免費試用, http://www.clarizen.com.tw
Clarizen自學中心, http://www.ganttera.com 萬碼奔騰科技
SCRUM google it.
您好,請問可以分享此文章給我們的SW團隊嗎? 謝謝您~
@Pearl, 感謝您的來訪,歡迎取用,請多多支持:)
重點在時間