（Photo by  Parabol | The Agile Meeting Toolbox from Unsplash）

二. 階段式方法

看到前一篇文章提到的瀑布式方法的缺點，我相信多數組織都可能感同身受。接下來的問題是，組織當中有沒有人有膽識、有魄力，而且還有權力可以推動專案管理的改革。

很慶幸地，本案例的公司就有這樣有遠見的主管群。該公司的主管們痛定思痛、下定決心去做專案管理的變革，開始採用階段式開發方法。整個流程大致演化為像下圖這樣：

這樣的方法緩解了相當大部份使用瀑布式方法的痛點，例如，

1. 功能團隊之間，很快可以開始同步工作，專案的時程可以相對縮減不少。

2. 客戶開始有機會在每個階段結束就先看到一部分成果，可以有機會建議或要求做些變更，滿意度得到明顯的提升。

3. 功能團隊之間的溝通頻率增加，質量變好，技術與知識在組織內有更好的擴散和傳播，對產品設計的誤解減少，重工的情形也變少。

當然，要達到上述的成效，組織其實是付出不少代價的。例如，該公司就花了不少錢，多採購了幾套 FPGA 模擬器，以讓 IC Design 團隊和 FAE 軟體開發團隊可以同步工作。

這樣的結果是，最新設計出來的硬體邏輯電路，和最新的客戶端應用軟體，就能盡量無時差地、高頻率地整合和測試，以便早期發現問題，早期治療問題，大幅減少重工的成本。

此外，還有一個代價就是，組織內同仁的工作習慣也得做相應的改變。例如，以往不同功能團隊之間所需的溝通比較少，而階段式方法卻需要比較頻繁的、密切的，人和人的溝通，這對於平常大多只需跟電腦溝通的研發人員來說，可就是一個不小的挑戰了。

這種階段式方法，對許多組織來說，確實可以因應多數的業務需求。但是，在產品需求日益複雜、變化日益快速的今天，階段式方法其實已經顯得有點力不從心，捉襟見肘，這也就是為什麼許多組織開始感受到壓力愈來愈大的原因之一。例如，

1.專案團隊成員之間的本位主義仍然相當常見，非常不利於團隊績效的進一步提升。

2.專案的進度仍然難以被確實掌握，專案延誤仍然常見，加班趕工的情況依舊相當嚴重。

關於第一個問題，多數實施瀑布式或階段式開發方法的組織，不是沒有明確指派專案經理，就是隨意在某個部門找個人來當專案經理，而這樣的專案經理根本就沒有得到組織高層的授權，是很難叫得動其他單位的人，配合專案的節奏做事的。

這樣的專案管理方式，團隊成員間的凝聚力，和共同成就專案的動機皆較為不足，功能單位主管也多半會以自己單位的利益為優先考量，來安排部屬的專案工作和優先順序，因此也就常會和專案的利益有所衝突，造成本位主義氾濫的現象。

關於第二個問題，在《敏捷方法的成功密技：專案管理的「溝通斷層」》一文當中我曾經探討過，多數產品功能實作人員所認知的「需求」，和客戶／用戶的原始想像，其實早就已經「失之毫釐，差之千里」了。

因為，在客戶／用戶把腦中的需求，也就是「想像」，用文字或圖形轉換為文件的過程中，「需求的細節」其實早就已經一點一滴地消失或模糊掉了。也就是說，根據文件來打造產品，本來就不太可能讓客戶／用戶感到滿意，隨之而來的大量需求變更和痛苦的重工，當然也就再所難免了，而專案團隊通常都會把這種情況歸咎於「客戶為什麼都不先講清楚？」。

此外，根據國外的研究，以及我自己帶領研發團隊和管理專案的經驗，人腦對於時間的估算真的很不擅長，尤其是要對那些從來就沒有做過的專案工作來說，時間的估算，尤其困難。

如果某個新功能是與過去做過的某個舊功能類似，那麼，開發人員還能用比較或對照的方法，做出較為精準的時間估算。如果不是這樣，其實，開發人員也都只能用「猜」的，而且，這種猜測，還是在沒有跟客戶／用戶討論的情況下，自己瞎猜的。你覺得，這樣還有可能會估得準時間嗎？

原文轉貼自：威廉網紙（原文連結）