最近，有一道新的思考題，就是為甚麼很多常識以內的事竟然不為人所認知？是明知不認、沒有常識、還是以為自己擁有打破常識的智慧和能力呢？
早前到台資書店，無意中找到一本天書，是論述軟件開發的經典。書由Dr. Fred Brooks於1975年完成，他曾經擔任IBM System/360超級電腦的項目經理，對大型軟件開發經驗甚豐。除了作者有來頭外，書名亦很有意思：The Mythical Man-month。
Man-month和man-day在管理上應該是很常用的概念，而經理亦常常問工作需要多少個man-day。不過，個人不喜歡用man-day來計算工作。說明文件，一般我會以topic作為預算單位，以topic數量乘以製作時間，加上整合所有文件所需的時間，便得到完成文件所需的總耗時。不過，這是我一個人做的時間，多一個人的話，時間要增加，而不是減少。除非你希望一本說明書有兩個架構、兩種寫法、兩種語文，和想得到從客戶來的兩巴掌...
如書名所言，man-month是個神話，“以成本會計（cost accounting）為基礎的時程預估技術，使我們誤把工作量和進度混為一談。人月是個危險並很容易遭到誤解的迷思（myth），因為它假設人力和工時可以互換”。的確，高層都覺得30個人時可以做出15個人時兩倍的工作。但現實多番證明這並不可行，只是行不通的方法依舊被採用，沒有人去question、去思考有沒有更好的方法。用相同的方法解決那個方法解決不了的問題的，就是我公司，實在令人洩氣。
比較公司的管理方法和書中提出的各種迷思，找到驚人的相似性。這也再次證明這是間錯誤管理的公司，最錯的是幾十年前已經發現錯的方法現在仍然繼續採用，而且還將繼續採用下去...
- 只有當工作可被切分，而且投入工作的人彼此不用溝通，人力和工時的互換才成立。
- 生小孩就是需要九個月，你叫多少個媽生都一樣，軟件工程就是像這樣的工作。
- 假設工作被切分的每個部份都必須各自和其他部份進行協調，那麼（增加人手）所增加的交流量便是n(n－1)/2倍。如果只考慮一對一的交流，三個人的交流量是兩個人的三倍，四哥人則要六倍...所增加的溝通代價到最後可能完全抵消掉因增加人力所帶來的好處。
關於交貨，高層的想法很簡單，先推出去，收了錢，然後再慢慢支援和解決問題，稱為“buy-time”策略。小規模的做，我不反對，但這次是要所有客戶更新的重大事件，道德和技術層面考慮都不應該這樣做。
作者幽默地指出做軟件和煮飯差不多，菜在預定時間內沒有做好，“顧客只有兩種選擇－繼續等，或者吃生的。你的軟件顧客也只有這兩種選擇”。“當然廚師還有另外一種選擇，他可以把火加大，那煎蛋卷就完蛋了－有一半燒焦，有一半還是生的。”我們的產品就是這種永遠都是生的爛東西。所以作者提出了一項定律：
Adding manpower to a late software project makes it later。
如何解決？
- 第一，不要發大公司夢，以現有的人手做好時程規劃、打好管理基礎。
- 第二，寫好文件、減少低效且不具再現性和追蹤性口頭溝通。
- 第三，不貪功能多，少做少錯，便能夠快。“功能多，不見得是好事”。
最後，再引用書中數句金句作結。
“軟件系統是人類創作中最錯綜複雜的東西”，進行如此複雜的創作，“短小精悍的團隊是最棒的。兩人團隊，其中一人當領導者，這通常是最佳的用人方式。（留意一下上帝對婚姻的設計）”。
認識軟件開發的本質，虛心學習前人經驗(http://en.wikipedia.org/wiki/The_Mythical_Man-Month)，“不要建構出必然失敗的系統”，才能持續發展下去。
沒有留言:
發佈留言