人月神話-軟體專案管理實務歷久彌新的經驗談

專案管理的歷史可以追溯到上個世紀的軍火工程,然後推展到各種製造行業,近代由於資訊科技的蓬勃發展, Project Manager  成為一個普遍的工作選擇,專門討論軟體行業專案管理的文章、研究、認證也爆炸性的增加,友人問該如何進入專案管理的世界呢?

我答說每個領域都有幾本歷久彌新的經典作品,例如想學投資,我會建議先閱讀幾次 Malkiel 的《漫步華爾街 ( A Random Walk Down Wall Street ) 》;如果是對策略有興趣,Nalebuff & Brandenburger 合著的《競合策略 ( Co-Opetition ) 》是必讀大作;若談到專案管理,比起很多人考完即丟的 PMP ( Project Management Professional ) Hand Book ,Brooks 以自身經驗為基礎的《人月神話 ( The Mythical Man-Month ) 》我認為是更好的選擇。

《人月神話》並不是一本技術導向的著作,這種談道理的書很多,但這本有點古老的書特別珍貴的地方是裡面的管理經驗是從真正的大型專案系統的過程中領悟出來的,要知道,真正的大型專案其實很稀有(以書中的作業系統開發專案為例,專案規模大於 5,000 個人年),絕大多數的專案管理師與傳道者都沒有這種經歷與機會,而使得不少傳授內容來自憑空想像,正由於大型專案的複雜度很高,從中更能夠窺見專案管理作法的極限與價值。

藉著推薦書的機會,也好好重讀了幾遍,當中有許多片段與我自己專案經驗裡面的觀察相符,底下是挑出的要點結合一些個人心得。

專案管理的一般性原則

一個專案是否成功有許多背景因素,共同的成功基礎則離不開早期的需求釐清以及建立合理的專案與資源評估。越是多方參與、規模大的案子,專案規劃的分量就會越重,但在實務上可以觀察到許多時候事前準備都是極不充分的,如果專案經理沒有在起步階段做好功課並提交評估意見給管理層,很容易讓客戶或是管理層產生非理性樂觀期待,進而引發在「面對現實」的過程中一系列的負面影響。

專案規劃並不是什麼 rocket science ,雖然有些人認為要力求完備,我則是覺得應該充分但盡量精簡,使用直覺可以理解的邏輯而不要弄得太過複雜,這不僅是想減輕多方溝通的負擔,也是考量了軟體工程易變的特性,大部分的規劃都會面臨被修改的命運,過早制定所有細節無助於專案的推進。

普遍來說,專案規劃考量的基本分析包括:

  • 專案目標

這是關於要達成的目標說明,需要有明確可測量的完成/成功/失敗的定義,依據專案的大小也可能進一步分裂成目標管理 ( MBO ) 體系中層層拆分的大目標與小目標。「定義」本身是否清楚是一個很重要的細節,很多無形的目標往往有定義不清的問題,一個有效的方式是給予定義多個同義描述,藉由比較等價的文字描述比較容易消除語言不夠精確產生的歧異。

  • 執行規格與產出

與個別產出項目有關的規格描述,依據專案不同可能是 5 x 5 大小的雕花石板或是一個有 30 個 input options 能承載1 萬 TPS 的 API 或是一份 20 – 50 頁包括 6 個規定章節的檢驗報告;好的規格概述與專案目標緊密相連,而好的細部規格與測試案例的設計有高度相關性。

  • 預算評估

專案內的所有工作項目與需求都是成本,預算分析不可能獨立於要達成的目標與規格之外,而時間也是影響預算的一個重要因素;預算清單的面向應該是多元的,不應該只有錢這麼單調,整體的 man-days 是一個考量,而實際上會佔用哪些人的多少精力也是一個因素;預算方案之間的換算與比較會有助於管理層與客戶進行有效的評估而不是被淹沒在無法理解的數字中。

  • 專案時程評估

包括專案的整體時長、各階段的時間跨度等等,時程經常與目標、預算牽扯不清,當然所有人的目標都是時間越短越好、品質越高越好而且成本越低越好,但顯然很多時候這些需求彼此之間互相衝突,因此單獨拆開來看是有其好處的。

時程規劃裡面一個對於化繁為簡很有幫助的技巧是制定合理的專案里程碑,這些里程碑也跟目標一樣是需要明確定義並且可測量的,里程碑的使用除了可以從概觀的角度執行 PERT / Critical Path 或是甘特圖式的時程分析之外,對於視覺化、文件化與管理層會議來說也很有用。

軟體工程的特殊專案管理議題

除了上面提到的這些基本常識之外,有幾條「漏網之魚」,在實際的軟體開發專案中經常被忽略、一旦出錯卻會造成重大影響,它們包括:

  • 重設計風險

軟體設計跟寫作有一些相似之處,描述一個恐怖小說的場景可能有一千種表達方式,直到寫出來以前很難評斷哪一種比較好;軟體工程還有一個額外的挑戰,儘管有多個方式可以達到需求,不同方式之間的隱性技術取捨、可兼容性、可維護性與成本可能截然不同,這導致某些時候修改設計,甚至修改需求可能對整個專案最有利。

客戶的需求也可能隨著專案演進而改變,有時候一個概念上的小更動將違反直覺地造成專案極大的負面影響。在專案計畫中留下一頁空白給予這樣的改變是重要的,因為從來沒有任何專案計畫一開始就能完美無缺。

  • 評估失準與重新對校

對於軟體工程師來說,針對從未執行過的需求進行工時評估永遠是一項難題,除了前導的研究時間外,練習與測試並思考不同的執行邏輯都需要足夠的時間醞釀創意,在一個大專案中可能有成千上萬個這樣的小項目隱藏在計畫中,當其中的一部分預測失準時(主要是完成所需時間,也可能是某些功能達不到),就會對整個 Critical Path 造成「長鞭效應」,越是複雜的專案最終失準的情況越是被放大。

為了避免最後一刻才開天窗,定期針對整個時程波動進行重新檢討常常是必須的手段,而專案經理人則必須承擔相應的目標與時程更動帶來的壓力並展現高超的溝通協調技巧,尤其是在事情往糟糕的方向前進時。

  • 人員流動

工程師的程式碼產出與邏輯巧思有很高的獨佔性,即使一群人做好各種協同工作機制,也比不上全部由一個熟練老手製作來得完整,實務上卻很少專案計畫裡面會提到這一點,在時間跨度長達數月甚至數年的專案裡面,人員的更動是一項很大的成本與不安定因素。

一旦有人從專案裡退出,就必須多花時間找人、訓練、交接、熟悉並接軌進度,這些都是「本來不包括在專案裡的工作項目」,毫無疑問地將延遲專案的進度,而工作品質也會隨著人員不同而浮動。

由於每個人的能力、經驗與評估標準都不一樣,隨著新人加入,原有的計畫像是可行性、使用工具或設計邏輯甚至時程的假設可能都不再有效,若是新加入的人員又再次流動( 在今日的職場生態裡越來越常見! ),專案領導人真不知該如何是好?

大型專案中可能動輒數十、上百甚至更多成員,專案領導人不可能一一掌握每個人的情況,因此需要搭配專案組織的切割與分工,依賴各小組的主管來管理這些風險,並將其列為正式的工作項目,把內部組織變化當成專案風險的一部分來考量在今日的軟體專案管理中已經越來越不可避免。

  • 非核心工作的干擾

軟體工程師除了寫程式之外還有很多週邊工作,例如團隊主管提交給專案經理的每個項目的工時點數,往往是由工程師提供再與主管一同討論的,又例如當客戶或是專案中其他同事想了解某些程式碼的細部執行邏輯並尋求建議時,這些調查、討論與開會也會佔去很多時間,更不用說工程師最不擅長卻難以避免的文件撰寫了。

因為非核心工作很可能會降低工程師的生產力,因此許多團隊都有設置小團隊產品經理/專案經理或直接由團隊主管/系統分析師擔任對外窗口,形成一道寶貴開發資源的防火牆,用來過濾多餘或不必要的干擾。

無論如何,把這些延伸的非核心工作考慮進來,我們才能得到一個比較有效的基本時程單位,許多技術團隊現在都採取直接將 5-6 個小時的工作量歸為一個人天或一個點數,並根據個別工作項目由團隊共同評估決定(可能是用便利貼或其他方式)所需要的人天或點數。

有些時候非核心工作本身也會被給予相應的點數並進行計算,如果是專門提供軟體開發服務的團隊,這麼做有個額外好處,一旦形成慣例,就很容易根據歷史資訊來推算各種工作類型佔去專案開發時間的比例,以改善傳統線性外推的評估方式。

Brooks 書中則提到自身經驗,軟體專案的工作比例約為:

1/3 測試

1/6 寫程式

1/4 組件測試與早期系統測試

1/4 完整系統測試與整合

  • 人月神話

業務與客戶方對程式設計團隊最常有的誤解與爭辯其中之一就是:我們是如何決定一個 manday 單位的? 雖然表定一天工作 8 小時,實務上 manday 的單位幾乎不可能用 8 小時的工作量來代表一天。

這其實有充分的原因,軟體設計是腦力創意工作,不像某些重複性高的工作一樣可以簡單的將單位工作量線性外推以得到長期生產力,軟體工程涉及大量的整合、測試與除錯,一個 100 人天的工作並不真的等於一百個 1 人天的工作,而且在真的做出來以前也無法驗證或保證其成果。

再加上前面說到的人員流動與非核心工作原因,當一個專案落後 30 個人天進度的時候,給開發團隊增加一個可使用一個月的人力並不會真的幫助到專案進度,反而有很高的機會讓專案更加落後。這個狀況雖然對於初次接觸的人來說很難接受,但其實我們生活中充斥著類似性質的現象:一個孕婦需要懷胎 10 月產子,找來兩個孕婦並無法讓懷胎時間縮短成 5 個月。

「人月神話」,或者作者自稱的 Brooks 定理簡要地總結了這個觀察:在一個已經落後時程的軟體專案中增加人手,只會讓它更加落後。

  • 文件管理

文件是現代軟體工程/產品管理中不可或缺的一環,常見文件的類型包括開發需求說明書 ( Statement of Requirement )、使用者手冊 ( User Guide )、技術參考手冊 ( Technical Reference )、執行/佈署手冊 ( Implementation/Deployment Guide )、版本管理手冊 ( Version Control Reference ) 等等,依據專案的類型可能會有不同的文件組合。

實務上有幾個跟文件相關的議題可以思考一下:

  1. 產品手冊/使用手冊應該由產品經理或是主要工程師撰寫?
  2. 程式碼邏輯說明應該以備註形式融合在代碼中或是獨立維護一套文件?
  3. System Processing 的邏輯說明應該要放在哪一個文件裡面?
  4. 流程圖的必要性、顆粒度與使用時機

標準文件的管理通常比較沒有問題,而其他細節則有時會被忽略,例如各種會議記錄經常沒有被妥善的分類管理;程式碼本身也是需要被管理的文件;專案協作文件與共享資料的權限管理;測試計畫與結果紀錄;專案末期與結案後的稽核文件等等。

準備及維護一套好的文件所耗費的時間心力經常超乎預期,但對於一個將長期營運的系統來說,投資時間在這方面絕對會有所回報。

  • 系統測試

系統測試是軟體產品開發過程及上線之前一道重要的工序,在敏捷的原則下,旨在確保最低可行產品的運作正常並且預防上線後才檢查到無法立刻修復的問題。

有些團隊採用了測試驅動開發 ( TDD ) 的作法,另一些雖然不走 TDD ,也會在寫功能代碼之前利用 Dummy Component ,例如快速製作一個空殼 API 僅能回傳固定但合格的資料以供其他系統使用,這種情況多半是為了製作原型 ( Prototype ) 。

標準的測試大致包括幾個分類:

  1. 常見合法案例
  2. 罕見合法案例
  3. 常見不合法案例
  4. 罕見不合法案例

具體的測試內容除了工程角度的輸入輸出、資料格式之外,也包含使用者角度的介面操作等等,由於光是收集測試案例的過程可能就會花上不少功夫,因此一定要留下足夠的時間給測試,當專案緊急時,測試工作就像是升學主義下的國高中家政課或美術課一樣,是會被優先犧牲的項目,但是讓一個複雜的系統未經完整測試就上線的風險很高,因為幾乎沒有一開始全部都做對的系統。

出乎許多人意料之外的是,儘管產品改版的幅度不大,進行全面測試花掉的時間卻會隨著改版演進大幅增加。理想情況下,對於每一次改版都應該進行 Regression Test ( 跟統計的迴歸沒有關係 )  ,例如版本一擁有 1,000 個功能共測試了30,000 個案例,平均一個功能測 30 個案例,在版本二中新增了 5 個功能,Regression Test 將進行至少 30,000 + 5*30 個案例,以此類推。

測試案例如果考慮到功能與功能之間的交互作用情況就會變得更加複雜,執行 Regression Test 的成本將會指數上升。許多經驗指出 Regression Test 雖然成本很高但是很值得考慮,因為軟體系統的天性就是當你改動了一些預期要修復的問題,卻意外的弄壞了一些本來沒問題的東西。

專案組織與分工

今天見到的大型軟體系統開發「執行」組織通常有很明確的以團隊為單位的前後台區分,前台是面對團隊外部的人員,像是團隊主管或是產品/專案經理,後台是團隊內部人員,像是測試員或工程師。但在軟體系統「設計」方面,有時候分工就不夠明確,關鍵的問題像是:誰應該對於用戶的需求擁有最終詮釋權?

  • 區分系統需求架構師與系統工程架構師

這個問題在一個大型專案組織裡面是很微妙的,不一定有很好的答案,但是在組織設計上可以用點巧思來減少這類問題,例如將歸納需求架構的工作 ( 系統需求架構師 ) 與規劃系統面 ( 系統工程架構師 ) 的工作分開給不同團隊。

這是一個由上而下的模式,需求架構師團隊擁有對用戶商業需求的最終解釋權力,而系統工程團隊則對於自己使用的技術內容與執行方法有主導權,將負責區域劃分清楚後,雙方主要的互動內容就會跟著明確:哪些需求實作上太過昂貴而需要重新檢視?哪些技術特性可以做為額外的用戶選項變成功能的一部分?

不論是需求架構師或是工程架構師,團隊的組成人數不能太多,否則會很難就所有問題達成共識,另外就是系統的風格與特性會不容易統一,有流於大雜燴系統的危險。

為什麼風格是大型系統開發重要的因素?我很喜歡的一個例子是書裡提到的歐洲教堂,大部分的歐洲建築在不同時代呈現的風格都不一樣,不同建築師對於整體設計的概念與強調的細節也各具特色,其中有一些費時百年才建好的城堡及教堂,假如後人不沿用前人的風格而擅自更動設計,就有可能破壞整個建築的美感與歷史價值;雖然軟體系統不太可能沿用數百年,但其中道理是一樣的。

一個值得留意的細節是,架構師團隊產生的文件與說明書應該由盡量少的人來主筆撰寫,再提供給團隊其他成員檢視以統一共識,因為在書寫的每個部分都有許多 mini-decision ,像是用字遣詞的方法及表達風格,由少數人操刀可以盡量維持相同的溝通意念,這對於使用這些文件的外部團隊來說有比較容易閱讀理解。

  • 外科手術團隊

由架構師團隊層層往下傳遞的需求與設計最終會被切割並落到組織裡的基本執行單位中,與之而來的問題則是:什麼樣的團隊設計可以讓生產力最大化?

通常,我們有兩個直覺選擇,找來 10 個工程高手或是 50 個普通人。大部分經驗顯示, 10 個高手組成的團隊績效會比 50 個普通人更好,就組織角度,這是得利於溝通成本的極簡化,以及更低的整體人事與其他固定成本。但是我們都知道,高手之所以很容易被辨識出來就是因為稀有,寄望所有人都具備高手資質是不切實際的。

同時,全部由高手組成的工作團隊在真正的大型系統專案中也不敷需求,因為大型系統動輒數百上千個「人年」,如果堅持用小團隊開發大概得等待人類移民火星的時代來臨才能完成。

作為折衷方案, Brooks 提出一個貼近現代軟體開發團隊不約而同採用的真實情況:「外科手術團隊」。

外科手術團隊的概念是,一個基本工作單位中只有一位主要的程式設計師 ( 主程 ) 擔任相當於主治醫師的角色,他對於程式開發的細部決定有主導權力,也是主要的產出者。

另外也會有一位「副程」擔任助理醫師的角色,相當於主程的分身與 back-up ,需要對於程式開發的內容有與主治醫師相同的理解,也協助一部分的程式產出,這位分身可以是團隊對外溝通日常技術問題的主要窗口,讓「主程」將所有精力留給程式開發。

最後是麻醉師的角色,在真正的外科手術團隊中麻醉師是掌握病人即時資訊的人,如果麻醉師認為病人身體情況不佳那可能手術也必須延後,在軟體開發團隊中麻醉師可能相當於系統分析師/專案經理/產品經理的映射,掌握外部的需求變化、互相關聯的其他工程團隊進度以及資源協調工作。

外科手術團隊的具體隱喻角色並不需要斤斤計較,重點是其團隊設計理念,圍繞在主程 ( 高手 ) 身邊建立一個能與他互補的支援團隊,讓主程能夠最大程度的發揮他所具備超越常人的生產力。

一旦實現了外科手術團隊的組織設計,我們就能用 10 個高手分別擔任主程,快速建立總規模可能達到 50-100 人的多個小工作團隊。

看得完真是太厲害了!也許你還想知道:

* 重讀《經理人的一天》,與我在高階主管們身邊的日子(一)

* 重讀《經理人的一天》,與我在高階主管們身邊的日子(二)

* 目標管理的理想與現實

* 讀 HOW THE MIGHTY FALL,強權為何隕落?

* 從蘋果經驗看無縫接軌的接班人計劃( SUCCESSION PLANNING )思維

(Visited 294 times, 27 visits today)

Wendell.Huang

科技公司嫌棄太活潑,消費品牌挑剔太沉悶…, 經常必須解釋自己在學什麼, 不小心就摔破對方眼鏡的業餘書呆子。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *