《人月神話》專案/產品經理(PM)與軟體管理者必讀經典
身為在資訊軟體業擔任過專案經理(PM)與負責內部流程管理的角色，終於打開熱銷40年的軟體管理神話《人月神話：軟體專案管理之道》。第一次聽到這個名字時，以為是本小說；近一步瞭解「人月」(Man-Month)二字的定義時，不禁大吃一驚的意識到，目前在軟體業常用來計算軟體專案成本的「人天」(Man-Day)，在40年前以前早已被深入探討一番，甚至當時的觀點到現今都還適用，畢竟本書叫人月「神話」也不是亂命名的。距離1760年代的工業革命已約200多年，然而1946年世界第一台電腦發明到資訊軟體的興起，距今也不超過100年，軟體開發的方法論與管理學，還有許多激盪的空間，也怪不得軟體的社群相當蓬勃，人人都在找尋最佳的管理軟體專案之道。
一、100年內，軟體專案是一項管理學
《人月神話》標題的意思，便是指稱我們在估算與管理軟體專案時，使用「人月(Man-Month)」來計算成本始終是個神話，原因如下：
(一)2人需要20小時完成的事情，無法用10人在4小時內完成
孕婦懷胎需要九個月，
找三個孕婦懷胎不會變成三個月
軟體生產的過程核心並不是電腦，而是「人」，因此基於軟體的完整性與每位軟體設計師的邏輯獨立性，撰寫編碼所預估的時間，絕對不可能用增加人力來減少時間。
(二)資深工程師的時間成本，少於資淺工程師
通常專業的資深工程師所需的時間，絕對小於資淺的工程師，論時間來說成本是降低的，但這並不能完全作為管理軟體專案的成本基礎。
(三)發明來自於靈光乍響，又快又慢
軟體專案的技術開發過程不像生產晶片或印刷書本，每項專案即使相似度高，皆為客製化，甚至每項專案都幾近事件發明，因此撰寫編碼的過程並不是在複印標準答案，而是不斷地從X求Y的研究過程，不論設計師是否具有豐富的經驗或高專業的技巧，找到最佳解的時間很難被明確估算。
因此如何有效地管理好一項軟體專案，不是像硬體製造，透過數據來分析機台的生產力與良率，來規劃生產製造的時間與成本。除了專案本身的目標和架構，也必須瞭解每位工程師的能力、特性與軟體團隊，透過「管理」來驅動「人」生產軟體。
二、良好的溝通，從白紙黑字的定義開始
本書用《創世紀》中的「巴別塔」寓言，來強調「正式文件」與「完整架構」的重要性。巴別塔的故事是在描述諾亞方舟的大洪水後的世界，人類都說著相同的語言，後來諾亞的子孫們散布到世界各地後，為了傳揚自己的功名，決定共同建造一座高塔要通天，目的是彰顯人類的地位齊天，因為沒有語言障礙，高塔建設速度極快。後來上帝知道了人類的企圖，感受到權威遭到了質疑，於是悄悄變亂人類的語言，讓大家難以互通，失去了言語溝通的能力，使得建塔的工程無法繼續，使眾人分散在全地上，所以那城名叫巴別塔。
因為當我們需要執行一項大軟體專案時，勢必需要增添人力來共同撰寫編碼，但由於軟體程式的編碼特性，如何透過有效的分工，讓每個人所產出的程式，最終能共創完整的產品呢？最重要的環節就在於「溝通」。
這裡指的溝通涵蓋軟體開發的初期、中期、末期與專案結束後，初期的專案規劃，如何有效切割軟體工作，並且確保所有專案的人在各自分工狀態下的產出，最終能夠確實的整合。中期至專案結束，如何透過大家皆能看得懂與理解相同的「正式文件」，來確保編寫程式的過程中，邏輯性與完整性，未來若要修改或延伸時，能夠有所依據的延續下去。
三、將最慘烈的失敗作為軟體縝密規劃的一環
在人類誕生的200萬年間，程式編寫不到100年的歷史只佔了0.005%，因此如何可以有效地在發展尚未完全成熟的領域中，軟體工程師、軟體管理者、專案經理與產品經理，甚至是資訊軟體公司能乘上火箭般的光速領先他人呢？老話一句：
失敗為成功之母
這句話不只用於軟體業，包含學習很多技能，我們如何想要快速成長的放絕對不是複製成功人士的成功方法，因為促使成功的因素太多了，然而避免失敗則是可以讓我們離成功更近一步，尤其是「明顯的錯誤」。因此不論是在經營資訊軟體的管理者或軟體相關產業的團體或個人，記錄、分享與從Lesson Learned學習，絕對是讓軟體專案接近成功最穩定的方法之一。並且不要樂觀的看待軟體開發，接受與計畫「慘烈的失敗」，能讓我們在執行軟體專案管理時，更周全的考量到風險存在的可能，保留更多時間與成本的彈性，做好管理。
四、編寫程式，不等於開發產品
軟體就如同樂高一樣，藉由不同的組合方式，有無限的延展與可能性，因此當一行行的程式可能是一項簡單的指令，也可能是一個完整的系統或產品。所以有個非常重要的概念，「當我們在編寫程式時，絕不是在生產產品」。因為一項完整的系統或產品，包含的工作項目包含主要的編碼工作外，也包含其他附屬的工作，例如：測試、文件撰寫、資安等，甚至必須是其功能性是具有市場價值的。所以即使現在軟體公司遍地開花，每個人只要有一台個人電腦PC)，都可以立刻開始編寫程式(Code)，然而所謂好的軟體系統或產品，需要有完善的規劃。
即使不是軟體公司或工程師，當我們選擇使用一項軟體系統，或者決定要在公司或團隊討入某項軟體時，軟體的完整性與彈性，也都會是需要考量到的環節，以避免不完善的編碼，造成未來更高成本的修復與時間耗費。
五、聰明絕頂的程式設計師，絕不能埋頭苦幹
撰寫編碼的過程，就像是撰寫一項申論題，沒有所謂標準的答案，因此在開發軟體專案的過程中，充滿部分的未知性，所以才會有「人月神話」的出現。然而，當世界許多人都在腦力激盪軟體領域時，軟體技術如光速般的推陳出新，我們千萬不要當一個閉門造車的井底之蛙，因為當我們用鍵盤一行一行敲出可能的程式解法時，或許早有人寫出可用的套裝軟體。
就像是AWS每天不定期都可能推出新的雲端服務，取代原本需要透過一行一行代碼才能啟動的指令。所以在埋頭苦幹撰寫編碼時，記得隨時抬起頭，看看這個世界走到哪裡，變化的多快，讓我們用更敏銳的學習力，成為一位最有價值的軟體人。
後記
這本書有很多關於軟體專案管理細節的探討，包含組織與職位規劃、文件撰寫和編譯器使用等，每章節透過有趣的故事來做引言，說明軟體開發這條路上很多值得咀嚼的現象。這是我第一次閱讀《人月神話》，但我相信不會是最後一次看，畢竟熱銷40年的書，至今仍有許多人將之封為軟體專案管理必讀的經典，除了代表軟體這條道路上，還有許多未解之謎待大家共同找出解方；也警惕我們莫忘在執行軟體專案時，很多原則與觀念，存在的重要性與永續性。
身為制訂公司專案管理流程的角色，看著專案工時的報表和《人月神話》，還有許多的Y等著我來用X解開。
如果喜歡這篇文章歡迎拍拍手👏，給我一點鼓勵。
如果你單純路過這裏 — 1個拍手
如果你喜歡這篇文章 — 2–49個拍手
你希望看到類似內容 — 50個拍手有任何建議，歡迎寄信聯絡我：hua.palace@gmail.com
