聽到有人說 TDD 是個測試的 practice，跟 RD 不是那麼有關，我想這是誤會了。TDD是一種設計的活動，它並不是單純在做 verification，它是一種 spec 確認的活動。

David Ko 還分享了一篇探討 TDD 的文章供大家參考。這讓同人想到我之前曾經對 InfoQ 的一篇有關軟體開發信仰問題的文章做過的評論。

在那篇文章的評論當中，同人認為作者不應該拿 TDD 與驗收測試相提並論，因為 TDD 並不是測試的 practice，而是設計的活動。如果這兩種實務可以相提並論，似乎就像是爭論有了良好品質的設計就可以省略測試，或是增加測試的效率就可以取代設計的重要性。同人當時在我的評論中提到：

測試的涵蓋面要夠廣，軟體開發所需的開發成本與時間就要增加，所以與其靠檢驗來控制品質，還不如把設計做好。所以，品質是設計出來的，而非檢驗出來的。

不過，雖然品質並不是檢驗出來的，但軟體要具備足以信賴的品質，卻不能省略測試。舉個例子來說，不管開發者如何確保他的開發所產出的品質，驗收測試是絕對不可能省略的，否則客戶是很難信任軟體是合乎他們需求的。良好的軟體設計可以減輕測試的負擔與壓力，但它絕對無法否定軟體測試的價值。

因此，同人認為不該拿 TDD 來與各種形式的測試來做比較，但在 David Ko 提出這個主題後面的討論，我卻看到一個我不太認同的說法。Steven Mak 提到：

世上總有些傻人愛做傻事，阻止不了他們的 不單是由測試去訂定功能規格，更不要忘了 Refactoring!

同人以為由測試去訂定功能這個觀點不符合 TDD 的精神，因為正如同我之前一直強調的，TDD 並不是測試。至於 Refactoring 是不改變功能的情況下使程式的結構可以更有彈性或是更簡單，它也無法用來訂定功能規格。但 Steven Mak 卻說：

TDD 就是由測試去驅動開發功能，寫測試就是第一步，到底有什麼不符合 『TDD 精神』？還有，Refactoring 本身是 TDD 三步之中其中必要的一步，沒有訂定功能用的。但我相信把 TDD 以為是測試的人是忘掉了 Refactoring 這一步。

看來 Steven Mak 以測試驅動開發的第一步就是寫測試程式為理由，以為測試並沒有不符合 TDD 的精神，只是認為人們忘卻去做 refactoring，才會以為 TDD 只是用測試來訂定功能規格。同人認為這樣的觀點混淆了測試驅動開發的目的不在測試驅動本身，而是主導開發過程中可以具體落實簡單設計。也就是說測試並非目的，而只是手段而已！

事實上功能不是由測試來訂定的，而是由使用者實際需求來決定。測試程式只是讓開發者找到更具體的方法，來具體驗證使用者的實際需求，這也就是 David Ko 所說確認規格的活動。因此，測試驅動開發的目的是讓我們開發的程式碼能夠符合實際的需要，用可驗證的程式來確定我們開發的程式是符合實際需要的，以避免 over-engineering 或是 under-engineering，所以其目的是為了讓我們發現更符合實際需要的設計。

運用測試驅動開發，可以讓開發者的設計儘量簡單，因為開發的目標很具體地呈現在眼前。開發者已經事先對需求的確認花過一番心思考量，把現階段已經確認而且最重要的需求寫成測試程式，一旦開發的程式符合測試程式的要求，那就代表程式已然滿足實際的使用者需求，而使開發者不致浪費心力在不重要或是目前無法確定的需求上。

因此測試驅動開發可以讓開發者立即用最簡明而單純的設計完成開發工作，好處是讓開發者知道自己在做什麼，而非浪費時間在做沒有意義或無關緊要的事。但任何一開始簡明而單純的設計，在系統不斷演進及需求不斷改變之下，也可能會使架構或設計愈來愈複雜而變得難以維護。這時候單靠 TDD 的簡明與單純也可能沒辦法容納這種複雜性，而是要運用 Refactoring 來增加設計的彈性；也就是在不改變系統功能的情況下，改善系統設計的結構，使它可以因應未來增加需要的功能。

因此 Refactoring 與 TDD 是兩個相互獨立的 practice，雖然 TDD 可以讓重構更為可行。但兩者不必要要混為一談，也就是 Refactoring 並不必然是 TDD 的必要的步驟。

在大部分的情況下，用 TDD 落實簡單的設計就已經夠用了，除非我們真的發現到我們需要更大的彈性才需要進行 Refactoring 的行動。敏捷開發不是強調方法論的教條，因此不管是 TDD 或是 Refactoring，都是為了真實世界的問題的需要，而非方法論的信仰，這也是同人之前評論 InfoQ 那篇文章，最主要想要批判的重點。

因此，雖然 TDD 這三個字母或是測試驅動開發這六個字當中，測試驅動就佔掉了這個名詞的 2/3，但切莫以為 TDD 就是以測試去訂定功能規格，這只是對 TDD 流於表相的認識，而看不清楚這個名詞最重要的兩個字「開發」的真相。

測試驅動開發的精神，不應該用一般機械論的觀點來進行工作或任務的化約，而是基於複雜理論的重要觀念；維持穩定與變化的動態平衡，不在於掌握系統核心而在於邊緣，讓變動限定在人們可以掌握的範圍內，這或許才是測試驅動開發最關鍵的精神吧！

但沒想到第二天，不到八點半同人和老婆就聽到電鑽和榔頭敲打的聲音了。這個時間出現這些聲音，會干擾女兒的睡眠而影響她的正常發育與成長，這實在令我們十分困擾。

其實早在幾個月前，同人就曾要求裝修承包商，要她請工人在九點前不要使用會發出巨大聲響的機具，以免干擾女兒的睡眠。最近發現在九點前，還是會發現工人使用那些機具發出聲響，本來以為他們就快完工了，所以就沒有向承包商反應噪音問題。但現在噪音的問題很嚴重，於是同人在上班前打電話給承包商，向她反應噪音問題，並得到她的允諾會讓工人遵守及配合。

後來老婆告訴我接下來的故事發展。她和女兒被噪音吵得受不了，倉皇走避時碰到承包商。她質疑承包商為什麼時間還沒到就開始施工，害她連早飯都來不及吃，好像逃難一樣。承包商連忙向她賠不是，但表示是工人沒有按照規定的時間來施工。老婆聽到這理由更生氣，如果承包商不能約束工人照規定施工，那住戶根本不能信任承包商在公告所做的承諾。

大樓管委會主委這時候出現了，老婆藉這機會消遣他。問他說：「不是說保證今後不會有噪音出現了，怎麼今天噪音那麼吵？」主委聽到也不甘示弱的轉向承包商說：「我最倒楣了啦，他們租房子還好（指我的老婆）受不了退租不住了就好。我呢？跑也跑不掉！」老婆看到主委只會抱怨而不想解決問題，而且又戴口罩，所以不想跟他吵，就先離開了。

還好住我們家對面的媽媽這時候經過，在弄清楚大家的爭議之後，想到解決問題的方法。她建議請大樓警衛在施工開始時間之前，阻擋工人不讓他們進入大樓施工，等施工開始時間到了之後才放行。結果這個方法果然得到效果，讓大樓的住戶不用清早就忍受噪音的襲擊。

同人聽完老婆告訴我以上故事的後續，讓我覺得對面的媽媽果然是處理問題的高手，不像主委只會感情用事。如果我聽到主委說那句話，我大概會說：「主委您真是愛說笑，你怎麼可能會倒楣呢？大不了你把房子租給別人，這樣就可以把你的問題變成別人的問題呀！」不過話說回來，我相信承包商有誠意解決問題，但當工人無法配合遵守她訂出的辦法時，問題該如何解決呢？

解決問題的關鍵就是正視「人不是完美的」的事實。同人是工程師出身，我很能體會工人希望早點把事情做完早點走的心態，對擾鄰後果的嚴重性他們可能沒有明顯的感受，而不是故意不去配合。所以以為訂下工作時間的規則就可以讓他們去遵守，其實是太天真的想法。那位媽媽的辦法正是對人性弱點的積極管理，不去假設人們一定會照你的方法去做事，而去思考問題的對策。看在同人的眼中，實在是令人激賞呀。

某同事甲指著一道菜，跟負責點菜的同事乙說：下次就別再點這道菜了。他說那道菜的肉，咬下去裡面是白的，顯見豬肉並沒有先醃過，吃起來就不夠味。這時候，有些同事表示認同，紛紛也附和同事甲的意見來評論這道菜。

同人對同事甲的看法沒有什麼意見，因為說實在的，我也吃不出這道菜有什麼不好。不過，如果精於美食的同事甲說得是正確的，那麼就代表這家店的這道菜品質有問題。於是我說：這其實代表他們 QA 沒做好。

這時候，大家好奇的眼光看著同事丙，也就是公司 QA Leader。他說 QA 沒有辦法提昇產品的品質，它只能確保有問題的產品不會送到客戶的手中。

顯然同事丙和同人對 QA 的定義有顯著的不同，他所說的 QA 是針對產品本身的控制流程，而非針對產出保證產品品質的執行過程，我認為那是 QC 而非 QA。但同人並不想挑戰對方對 QA 的定義，以免把吃飯的氣氛弄得太嚴肅，於是我用另一種方式來表達我的觀點：

我的意思是作這道菜的流程出了問題，導致產出無法符合顧客對品質的要求。所以他們應該設法改善這道菜的製作流程，讓它更完整並且可以符合客戶的需求。

終於，同事丙沒有再質疑同人的說法。不過，這也讓人看到一個現象，就是在台灣，品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外，以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」，讓開發人員認為品質是品質部門的責任，而品質部門則認為提昇品質不是他們的責任，以為最多只能做到知道產品有問題，而不知道如何改善它們，只能退回到開發人員那邊來解決。

在一個重視品質文化的公司，QA 人員對產品的意見當然可以擲地有聲，善盡到品質管制的責任。然而，在台灣軟體開發的環境，尤其是大部分以專案型態的軟體開發，品質往往是時間或成本不足第一個被犧牲的對象。同人想到我過去在一個大型政府公共建設委外 BOT 專案中，因為業主對文件要求嚴格，使開發團隊要花費相當多的心力來寫文件。想不到上層負責監督的 VP 卻說：沒有時間，品質目標只要設定為達到 30% 就夠了。

同人很清楚那位 VP 的說法是不會 work 的，因為品質不能妥協，否則你必將付出更大的代價。果然那個因為延誤而讓公司損失慘重的專案，在我離開那個專案兩三年後才勉強結案驗收。不幸地，這種不重視品質文化的開發方式，在今天卻還在台灣各地持續上演之中。

因此，與其將品質寄望在強大的 QA 人員或嚴謹的品質流程，還不如在開發過程中織入品質的面向，形成品質保證的全像圖。高品質是全員參與的必然結果，在分析、設計過程就加入如何提昇品質的思維，以達到符合顧客的需求，並且創造他們的價值，這便是執行所謂的 QA，也就是真正的品質保證。

當然，能夠為客戶創造價值的品質流程並非絕對的，就像負責點菜的同事乙後來表示，她不覺得那道菜難吃呀。其實同人也覺得那道菜也還好，品質和你的客戶是誰有很大的關係，事實上，並不是每一個人都對吃很講究，所以那道菜的品質，其實是因人而異呀。

後記：

本篇文章已刊登於 ZDNet Taiwan 部落格文章專區。

先問自己一個問題，一個程式有幾個 Bugs？如果是不可數，那～～它的穩定是相對非絕對，所以穩定不是絕對的，也不是必然的。

同人覺得這位噗友的觀點很有趣，於是加入這則噗浪的討論。我問如果最開始的程式都是穩定的，那麼是什麼原因讓後來的程式變得不穩定？對這個問題，一些噗友提出了他們的看法，其中有一位噗友回應「是我的機器弄好的程式，跑到別人機器就不穩定了」，發送此則噗浪的噗友認為還蠻接近實際的情形。

他提到 Bugs 在自己的機器沒產生，在別人那邊可能會產生，問題可能是因為自己的機器有 Bugs，而不是別人的機器，他說假設機器不會出問題是會有副作用的。

那麼為什麼不在應用系統要運作的目標環境下直接開發程式呢？因為，嚴格來說，開發者不可能有完全一致的環境，因此開發者只能假設環境是不會改變。但實際上，在不同的機器上、甚至在相同的機器上，不同的時間可能也會出現難以預料到的變化，結果使得程式變得不穩定。

這位噗友認為，當我們愈信任一個系統，其實可能是一個災難，因此程式的穩定非絕對而是偶然，它是由一連串的偶然所累積而成的。同人發現這個觀點讓人很難反駁，在我過去程式開發的經驗中，並不乏遇到原來運作正常的程式，在不同時空環境出現問題的現象。正如同這位噗友提到的，作業系統與程式語言它們本身也都是程式，很難確保它們不會出問題。

相信很多人都曾遇到過，程式發生失常通常只因為一個令人難以捉摸的小錯誤，因此似乎真的可以說「穩定的程式是偶然的」。不過，如果穩定的程式真的是偶然的，程式的穩定就只能依賴運氣而不是人為努力，事情真的是這樣嗎？其實這位噗友太過強調環境變化的隨機性，卻忽略了適應環境變化，程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的，雖然演化的過程是偶然、但其最後結果卻是必然。換句話說，穩定的程式是偶然下的必然。

程式的運作通常需要處在多變的環境中，使得開發者很難確知他的程式有多少 Bugs。因此在本質上，程式開發過程是一個偶然，由一連串的隨機事件所構成的。雖然開發者可以使用與將來應用系統所運作環境相同的硬體及作業系統，但實際上終究並非同一台機器。它們可能會因為使用者的差異，而安裝了無法與應用系統相容的軟體或設定了會使系統出現問題的系統組態。就算是兩台機器能夠完全一模一樣，時空環境的變化也可能造成系統運作出現問題的關鍵，即使兩者的差異相當微小。

以上的現象就是程式開發的「蝴蝶效應」，就像天氣很難預測準確的道理一樣。一隻蝴蝶在巴西輕拍翅膀，會使更多蝴蝶跟著一起輕拍翅膀，最後將有數千隻的蝴蝶都跟著那隻蝴蝶一同振翅，其所產生的巨風可以導致一個月後在美國德州發生一場龍捲風。這是「混沌」理論所討論的現象，未來的狀態對初始條件敏感而造成無法預測。在混沌系統中，初始條件十分微小的變化，經過不斷放大，對其未來狀態會造成極其巨大的差別。^[1]

除非所有 Bugs 都出現為止，否則程式開發者不會知道他的程式有多少 Bugs。因為他無法預測他的機器和實際運作的機器，有那些差異會造成程式運作出現功能失常。而且問題可能不是因為他的程式錯誤，有時候問題是出在作業系統或程式語言本身的 Bugs；它們都是程式，只要程式都有可能會有 Bugs。

現實真是令人沮喪呀，如果不確定因素使得環境變得如此難料，那要如何期待穩定的程式出現呢？我們不能期待環境不再變化，因為軟體開發的現實就是變化無常，唯一不變的真理就是變。我們也不能不去面對問題，進行規劃及管理，因為隨性地處理問題，只會讓問題變得更加混亂而讓情況失去控制。我們應該讓系統可以 適應環境的變化，發展出兼具穩定與彈性的程式，這樣我們就能在界於混亂與穩定的過渡地帶中，逐步演進出複雜的行為來維持整體系統的動態平衡。

這就是複雜理論的複雜適應性系統的觀念，系統透過自我組織來穩定自己，不會因為無法控制混亂而崩解為混沌一片，同時也保有足夠變化的彈性來進化系統行為。就像同人在過去的文章中，曾經提出複雜系統來比喻專案管理的隱喻一樣，複雜適應性系統的演化過程是不斷經歷觀察、假設、調整、再假設的重覆循環過程。

整個專案環境所能供給的資源是有限的（成本限制），而演化競爭者會和我們爭奪這些有限資源（時間限制），所以對一個複雜系統而言，必須達成演化的使命而創造對整體系統的價值最大化（規模限制）。要做到這點，複雜系統必須能依現狀來演化系統，用最經濟的方式創造最大的價值（技術限制），演化則是先對環境的做出假設，然後依據適者生存不適者淘汰的原則來進行演化，過程中會不斷地修正對環境的假設並改變系統行為以求適應環境。

因此，對於程式開發的專案當然也是相同的道理，演化的過程是無法預料的隨機行為，但演化的結果卻是必然的；發展出最適應環境及產生最大價值的穩定系統。假設的目的是為了做到將廣大的可能性限制在一小部分，這是同人在另一篇文章引用 Peter Ho 所提到讓系統停留在混沌邊緣必須做的三件事之一。另外兩件事則是必須保持足夠的穩定，即使有輕微的改變，系統仍不會崩解成混沌一片、以及必須在靜止不動的死寂與過度活動的「混亂政體」間達到平衡。

這也就是同人提出先前穩定的程式，最後卻變得不穩定，到底問題是出在什麼地方？問題並不在我們對環境做出假設，而是無法意識到假設所帶來的風險，以讓開發程式停留在混沌邊緣以達成系統的動態穩定。因此，噗友提到假設會有副作用的問題不在假設，而在於開發者面對環境的反應的變化太慢，以致於造成局面的紊亂而使得問題無法收拾。

然而，如何及早反應環境的變化維持程式的穩定與彈性呢？同人推崇測試、重構與整合三項實務，誠如 Peter Ho 所說的「未經重構，系統將會沒有空間來容納新功能來適應新的變化驅力；未經測試，開發者不會知道系統邊緣在那裡；未經整合，生命火光將逐漸消散。」用紀律來維持系統彈性與穩定，雖然環境的變化是無可預料的，但我們仍將體會到穩定的程式是偶然下的必然！

1. 維基百科編者 (2008). 混沌理論. Wikipedia, . Retrieved 03:15, 1月 9, 2009.

專案經理常會面臨天人交戰的情境。當專案「計劃總是趕不上變化，變化總是比不上老闆的一句話」之時，許多專案經理總是會擔心專案無法如期完成或害怕資源不足，而拒絕或延後專案變更的要求。但這樣的行為，卻往往造成工作成果無法符合專案實際需要的結構性因素，而使得專案的失敗機會大為增加。這對於具備智慧及膽識的專案經理而言，當然並不會樂見專案發生這樣的事情。

筆者前一陣子看到喲哪桑在〈換了屁股，我也換了腦袋〉的分享，提到他在時間緊迫的情形下，接受了專案的功能變更要求。那個變更要求原來是由他所提出，當時前任專案經理以時程緊迫為由而答應延後處理，而一直到他接任專案經理仍然還留在原處。但他認為他不能任由「行為造成結構」的情形發生，於是決定不要再讓這個專案變更要求再次拖延下去，並在當下對專案進行變更。

筆者認為喲哪桑的作為令人激賞，並且覺得那篇文章值得推薦。其原因並不是因為他針對專案變更做了什麼樣的決定，而是欣賞他在決策過程中，展現出面對自己的勇氣與解決問題的思考。不過，卻有其他讀者對那篇文章抱持相反的意見。

某位網友對喲哪桑的分享，批評他是靠感情衝動來管理專案，甚至用了「發瘋了你」、「不適任該離開的時候」等情緒性的字眼來指責喲哪桑的不是。他指出喲哪桑的文章所傳達的意念，實在有不可思議的謬誤，並且擔心那篇文章會透過 ZDNet 的報導，將不正確的知識與觀念誤導一般社會大眾。

然而，他對這篇文章的批評卻使人感到困惑，那位網友認為喲哪桑文章傳達的意念有不可思議的謬誤，但看在專業人士眼裡，這樣的觀點又何嘗不是相當嚴重的偏頗呢？筆者認為他的觀點傳達的意念本質上是一種面對不確定性的焦慮感，進而對改變的抗拒而產生無知的迷惘。

專案變更的基本原則

身為專案經理固然不應該因為個人一時的感情因素而使專案陷入危險之中，但在對專案缺乏可供客觀評論資訊的情況下，只憑專案經理接受專案變更的決定，就加以批判其決策感情衝動是否真的恰當？專案管理並不是神學或是玄學，而是屬於管理科學的範疇。因此，如果有人要批評某個專案經理是用感情衝動來管理專案，必須提出具體的事實根據，否則那只是無憑無據的推論而已，而這樣的推論多半只是源自於自我的偏見與扭曲。

以專案變更管理的原則來看，依據《PMBOK》的說明，專案經理在管理專案變更的時候，必須注意三件事。首先他必須確定變更對專案的影響有其正面的價值；其次，他必須確認造成專案變更的因素已經發生；最後，他必須對變更加以管理。

從以上的原則我們可以發現，專案經理決定接不接受專案變更的要求，不應該源自於個人的主觀認定，而是必須經過客觀的評估。只有在蒐集了專案變更的各種相關資料，並加以評估之後，我們才能確知在專案現狀下，變更的正面效益或負面影響為何、到底值不值得立即採取行動來進行變更。而在未經評估之前，沒有人可以作出專案是否應該接受、拒絕或延後變更要求的決定。

喲哪桑的文章並沒有提到他所進行的專案變更並未經過事前的評估。相反地，他在對該位網友情緒漫罵性的言辭感到莫明其妙的文章中提到，在部落格發表的文章中，他不能揭露太多工作細節，並且提到了在重提該項專案功能變更要求之前，提出者已經評估過變更對專案的影響。因此，依據我們可以觀察到的事實來看，認為喲哪桑用感情衝動來管理專案，本來就是沒有根據的偏見。

個人信仰的偏見

既然沒有證據可以證明喲哪桑在未經事先評估的情形下，就逕行進行專案變更，那麼為什麼那位網友卻堅稱喲哪桑是用「感情衝動」來管理專案，並且說他並不適任專案經理的工作該離開呢？他提到每個人相信自己所相信的，本來就是人生信仰的一環。而他的信仰是「PM 不該因為個人情感的因素等非理智的理由，而貿然做出提升專案風險的決策」，因此根據這樣的信仰，他認為貿然接受了專案變更要求會增加專案的風險，這只是出於一時的感情衝動。

如果以上的理由是可以成立的，那麼一個人的確不應該用個人情感因素，來進行非理性的決策。但當我們真的這樣說時，我們卻忽略了這句話在邏輯上將會出現必然的謬誤；個人信仰本身也是出自個人情感因素，那麼為什麼別人的情感不理智，而我們的情感卻是理智了呢？

這種出自個人信仰的偏見，正讓我想到在〈新官上任三把火〉與對不同軟體文化的情緒化貶抑正有著異曲同工之妙：

如果主導改革者的心態不是基於解決問題或客戶要求，而是基於自己情感的訴求，所謂的改革也只不過為了遂行其願的私心，卻讓專案與團隊成為無辜的陪葬品。

就像上述主導改革者的心態一樣，在專案面臨變更要求的時候，許多專案管理者會傾向用一己的偏好或私心來決定是否接受變更的要求。尤其是他們常會以開發資源不足或進度落後來當做理由，拒絕或延後專案變更的要求，以減輕他們的工作負擔。但如此一來，接受、拒絕或延後專案變更要求卻變成無法理性討論的議題，也很少人可以正視它們對專案所產生正面的助益或負面的影響。

專案風險的迷思

那麼這種無法正視專案變更要求的信仰從何而來呢？依據筆者對許多專案經理的觀察，我發現許多人會為了減輕對未來不確定的恐懼所產生的焦慮，以為不去正視專案變更要求就可以降低風險，但實際上卻反而對專案風險造成迷思。

當專案經理接受專案變更要求時，增加開發工作當然會影響專案時間表，這得確會為專案帶來一些風險。因為如果時間表的最後期限改變，會增加對完工時間與預算的不確定性或衝擊而造成風險、即使最後期限不改變，時間表的調整卻有可能造成要徑（其內的任務一旦延誤，就會影響專案完工日的工作）數增加的風險、或是為了趕工或因為作業重疊、省略品質流程等作業而產生重工率增加的風險等、這些都是接受專案變更可能帶來的風險。

既然接受專案變更要求會增加專案風險，那麼拒絕或延後專案變更要求是否意味著就不會增加風險了呢？當著眼點處於整個專案成敗的高度與視野時，我們將會發現答案是否定的。如同《專案管理之美學》提到的專案應該兼顧並協調各種觀點的平衡，這些觀點包括了技術面、客戶面與營運面。技術開發對於專案很重要，但除此之外，客戶需求與營運策略更是不可偏廢。

換句話說，因為技術觀點而拒絕或延後專案變更要求，很可能會影響客戶的滿意度或信任度、或是因為產品推出時效的問題而影響競爭力，這些風險的影響可能會比技術所造成的風險還來得嚴重而深遠的。

拿過去筆者曾經參與大型軟體專案的例子來說明，那是一個規模數億的政府部門的公共建設 BOT 計劃，包含了十幾個子專案。在各個專案設計開發告一段落的時候，筆者負責與業主及顧問商討該如何制定軟體程式設計規格的標準。

由於我們開發的系統很多，彼此又有相當的差異性，這使得我們在制定出一致性的標準的過程面臨相當大的挑戰。雖然這些問題很複雜，但整合起來其實並不困難，然而真正困難的地方是業主對我們的不信任，經常使得筆者藉著技術專業，很難說服他們可以接受我們的建議。

當時筆者就經常聽到業主對我說：「我當然瞭解你們提到的開發觀念，但問題卻發生在每次你們都說這個問題是什麼時候或什麼人會處理，但最後總是沒有人會處理這樣的問題」這總是令人無言以對，我們對客戶的要求經常拖延與事後相應不理，客戶當然也就學會了對峙之道。結果最後是誰吃虧呢？答案很明顯，即使他們的考績會因此受到影響，但對專案開發組織而言，專案一直遲遲無法驗收的結果，卻是讓我們損失慘重！

應生無所住之心

既然拒絕接受改變的信仰會使我們因為無知，而處在專案風險的迷思當中，那麼身為專案經理對待專案變更要求，到底該不該「換了屁股，也要換了腦袋」呢？筆者認同其他人主張的「換了屁股，也要換了腦袋」說法，但卻想提出一個思考重點。

那就是不管專案經理決定要不要換腦袋，關鍵還是在於他面對問題的本質性思考。所以我認為對於專案經理而言，如何坐在他的位置上並不重要，重要的是他決定怎麼坐上位置之前的思考是什麼。

其實不同立場與觀點的衝突只是提昇其高度及視野的契機，專案經理應該好好利用這樣的機會，去反思為什麼換屁股，就必須換腦袋？或是如何換屁股而不換腦袋？想通了，就會讓自己的思慮變得更成熟而完整，使自己可以勇敢地面對無知而得到智慧。這也就是為什麼筆者會認為喲哪桑的作為令人激賞的主要原因，重點在面對自己的理性，而非對結論的情緒化反應。

筆者很喜歡用《金剛經》的「應生無所住之心」來類比專案管理的智慧，若專案經理太偏重於技術、客戶、業務任何一個觀點，都會造成執著而無法針對問題真相來進行思考，因為我們的心有所染著；但如果為了不去染著任何的觀點，無心讓自己變得冷漠卻也什麼事都做不成。換句話說，專案經理對專案展現熱情是必要的，它將會使得專案經理展現出慈悲與智慧的作為。

慈悲作為需要專案經理的情感，否則無從激勵專案團隊，也就很難產生出良好的專案績效。同時專案經理也必須搭配智慧作為，運用客觀評估與思考能力使得專案範疇、時間、成本等三重限制（triple constraint）能夠達到平衡。

總而言之，專案管理的智慧正是「若菩薩心住於法而行布施，如人入暗，則無所見；若菩薩心不住法而行布施，如人有目，日光明照，見種種色。」的道理，當人們偏執專案特定觀點時，專案問題對於當事者而言，也只是視而不見呀。

軟體專案開發常常會面臨時間不足的問題，尤其在台灣，Price on Cost更是不容易達到的理想，迫於現實，開發者只能硬著頭皮上陣去執行不可能的任務。但最後的結果卻常常是賠了夫人又折兵。即使透過不斷地加班，任務依舊還是無法完成，而且還會造成團隊士氣低彌，使得開發者缺乏工作的成就感與滿意度，甚至使專案開發人力大量流失。

其實大多的軟體開發者都期望專案能爭取到足夠的開發時間，不希望他們的青春浪費在無意義且永無休止的加班上。然而，軟體開發的現實就是如此殘酷，受到開發組織的營運面影響，通常專案總是很難爭取到足夠而充裕的開發時間。專案常會受限於市場競爭壓力的考量，為了爭取專案的機會常常會不得不遷就營運觀點而放棄工程與技術的堅持，因而使得專案無法爭取到合理的開發時間。

工程與技術的妥協

在台灣，軟體的定價通常是由市場供需機制所決定的，而不見得可以考量到軟體開發的成本。當市場競爭愈激烈時，軟體的價格就相對地會降低。開發者為了獲利，於是就必須想辦法降低開發成本，才能獲取相當的利潤，於是軟體的品質就會受到影響，因為軟體價格實在太低了，開發者只好捨棄一些可以增進或維持軟體品質的作業。結果軟體品質就會變成時間允許才能夠達到的一個理想，而現實通常是「時間總是不夠」。

當軟體專案把軟體價格當做專案成本估算的基礎時，這樣軟體開發就會沒辦法重視專業，只能讓外行（市場因素）領導內行（研發設計專業），軟體開發者的痛苦夢魘於是從此開始。

所以，Price on Cost 的理想是很難達到的，現實就是這樣，專案就是難以爭取到足夠的充裕時間。但這樣要如何才能達到專案不可能的任務呢？從筆者在工作上的觀察中發現，不少的管理者會將這個問題焦點放在團隊生產力上，以提昇軟體的開發效率來縮短開發時間。不過，實際上卻不見軟體開發成果獲得到顯著地提昇。

生產力的迷思

通常，管理者會希望軟體開發者加班或是增派開發人力，來提昇軟體開發的生產力。軟體開發每日的總工時增加了，照理說應該是可以增加軟體開發的效率，但卻也因此引發出新的問題，也就是軟體開發出錯的機率也會隨每日工作時數或開發人力增加而增加，反而降低了軟體開發的效能。

為什麼會這樣呢？綜歸一句話，增加了生產力卻讓軟體開發變得更複雜，使得團隊無法有效整合、發揮綜效。而這種現象又可從兩個方面來看，一方面是加班讓開發者身心耗弱、無法集中心力來完成任務，因此常因為工作上的疏忽而產生錯誤，反而讓問題變得更複雜，需要花更大的心力才能解決。另一方面則是團隊規模變大，人與人之間需要更多的溝通時間與成本來整合工作成果，因此每個人的工作量不減反增，同時又有意見分歧可能引發團隊衝突影響專案績效的風險。

理論上，壓縮專案時程可以運用趕工（crash）或作業重疊（fast tracking）的方式來減少開發時間。趕工必須讓工作者加班而增加開發成本，作業重疊則會增加工作產出重工（rework）的風險。因此，似乎只要多付一些成本來支應加班的需求或加強風險管理，應該就可以達到時程壓縮的目標。然而，由前面的分析我們卻可以發現到，軟體開發的複雜度其實是經常超乎我們想像的，由此可知，軟體專案的時程上的妥協其實是很難用成本來彌補的。

筆者最近才聽到朋友告訴我一個軟體專案失敗的案例，該專案是以另一個將近結案的專案為基礎。原來他評估勉強半年可以完成，本來公司把專案交由他負責，但最後專案經理卻因為客戶的意見而交由負責該客戶的業務來掛名，實際上專案則由我的朋友來負責開發該專案。

然而，當我的朋友才開始需求訪談時，專案經理卻告訴我的朋友他程式開發時間要在三個月內完成。而在我的朋友在研讀前一個專案的程式碼，以求了解程式架構以後才能根據客戶需求加以修改，那位專案經理卻要我的朋友立刻著手動手修改程式，問題留待後面再來處理。

雖然我的朋友還是在時限內完成了程式，不過，這時候問題才真正開始。客戶驗收後提出了上百個程式錯誤。這時候我的朋友才發現，這專案所依據的快結案的專案本身就有很多問題，並不是像那位專案經理所說的「沒有問題」，因為有 3/4 的 bug 都是那個專案本來就存在的問題。

此外，客戶還提出了一些原先沒談到的需求，而那位專案經理則要求我的朋友要在不增加時間的情況下予以照單全收。因此在需求不斷膨脹的情況下，這個專案最後還是失敗了。當然，最後那位專案經理把失敗的所有責任都推到我的朋友身上。

相信任何有經驗的軟體開發者看到這故事都會了解，那個專案經理實在是太外行了，他以為軟體開發只是依據客戶的需要來產出程式，認為只要壓縮開發者的時間來產出更多的程式就可以解決問題。卻殊不知軟體開發在缺乏產能的情況下，再多的產出也只是徒增軟體的複雜度與風險，這樣要成功地達到專案目標只能靠聽天由命了。

開發產出與產能之平衡

由此可知，在專案開發時間不足的情況下，用生產力的迷思所生產的程式產出，其實多半是無法具有實質效用的。因為開發者在龐大時間壓力是很難會有思考的空間，將使他的產能逐漸耗竭殆盡。即使在剛開始，可以一時滿足了客戶的需要，然而長久下來，卻在無形之中增加了專案的複雜度，最終只會在耗盡了開發者的青春與熱情之後，得到專案失敗的苦果。

因此，在專案時間不夠的情況下，要達成不可能的任務必須要提昇軟開發的產能，必須讓開發的產出與產能可以相互配合。但至於要如何增進良好設計架構的產能呢？依筆者在軟體專案開發的實務經驗來看，關鍵在於必須同時兼顧客戶價值與開發風險。而要做到這一點則必須要讓開發者與客戶充分溝通，讓專案產出確實可以為客戶創造最大的價值，同時也能有效地降低專案的風險。

筆者常觀察到許多開發者習慣把客戶提出來的功能直接當做軟體需求規格，卻沒有深入分析客戶真正遇到的問題。他們以為問題領域、業務流程或現場作業等知識是客戶的專業，開發者無從介入，因此往往在不知客戶要求之所以然的情況下，直接把客戶的話轉換成軟體規格。

然而，客戶所知道的並不是軟體需求（requirements），他們對系統的觀點只能顯露出他們對系統的需要（needs）。需要是抽象而片斷的，本身是非結構化的，而可用的軟體需求卻必須是具體而完整一致的，具備結構化的特性。

因此，如果開發者沒有針對客戶需要分析他們的問題，設計解決方案，只是直接把客戶的想法直接轉成軟體規格的話，客戶心中想的那朵雲，隨時都會變幻出各種不同的形狀，需求不斷變動當然是必然的，如果開發者沒做適切的分析及設計，只靠技術是很難滿足客戶多變的渴望與需要的。

事實上，軟體開發是知識與腦力密集的工作。自許為知識工作者，重要的不在於產出的數量，而在產出的品質。要讓產出具有足夠的水準，必須要有足夠的時間在問題領域的分析上，才可能為客戶設計出可以解決他們問題的軟體，為客戶創造價值；也才能讓軟體具備足夠的彈性來適應客戶千變萬化的需求，有效地降低開發風險。

要如何充分溝通？

於是，當我們用以上的思路來看軟體開發時，縱使專案沒有足夠的開發時間，我們依然要會從客戶的立基點中去思考問題，並從中找出最可行的技術來創造客戶的最大價值。同時，在這樣的情況下，開發者展現了足夠的專業，客戶也會很自然地信任開發者誠意與專業，形成了良性的雙向溝通。

在這種客戶與開發者良性溝通的情況下，客戶可以決定了時程、成本、品質等限制條件，而專案範疇的限制條件則應該由開發者與客戶溝通後依業務需求及技術架構的取捨來決定。這也就是說，客戶提出他的問題、以及希望解決的時限及願意付出的成本。開發者則應該針對問題分析出需求規格、發展出技術架構，並據此實作出軟體後再交由客戶驗收。然後客戶再依軟體實際使用狀況予以回饋，開發者再依照客戶的意見反覆地演化系統，以使軟體更趨於完善。

客戶應該優先提出最關鍵及最核心的業務問題，而開發者則必須針對這些問題分析，發展出軟體需求、找出解決問題應採用的技術與方法、優先將最高風險及最核心的架構與程式實作出來。如此客戶最重要的問題可以優先被解決，而開發者也可以針對客戶問題而設計，而不會浪費時間與成本在過度設計上，降低了軟體開發的風險與複雜性，使得產出與產能可以相互配合。

開發產出與產能相互平衡，才不會偏廢於需求面或技術面，使技術可以面對現實地解決客戶的問題。就算開發時間真的不夠，至少也可以用空間換取時間呀。因為無論如何，客戶至少都會擁有一個可用的系統，而不是一堆無法正常運行的程式碼與文件。

軟體專案團隊在專案開發的過程中，常會面臨許多問題，例如需求的不斷變化、資源的短缺、時間的急迫性、以及技術的難以掌握等。這些事件雖然都將直接影響專案的產出與品質，並且會令開發者會感到相當困擾，但只要存在希望，問題都還是可以有解決之道的。然而，在什麼情況下，專案發生了什麼事會讓開發者完全失去希望，並且感到他的世界相當悲慘呢？

相信許多人都會同意，總要等到專案驗收前，才發現程式品質有問題是一件很令人沮喪的事情。而筆者根據軟體專案實務經驗也發現，對軟體開發者而言，最悲慘的事件莫過於在專案臨驗收之際，才發現程式沒有合乎品質上要求。

軟體開發者的悲慘世界

筆者用一個笑話來比喻這種開發者的悲慘世界。話說有三兄弟開車回家，就在車停妥在停車場時，突然發現大樓停電了。很不巧的是，他們住在五十樓，停電沒辦法坐電梯，於是他們只能用爬樓梯的方式回到他們居住的地方。

爬到十樓的時候，大哥建議每人講一個最悲慘的故事，並且從他開始。大哥說：「從前有一個人從小就沒有父親，是由母親含辛茹苦地養大，好不容易稍稍有了一點小成就想要報答母親時，母親卻病死了。」，說完時他們己經到了二十樓。

二哥接著說：「從前有一對情侶非常相愛，男孩要出國留學，女孩也發誓不管多久一定會等他回來，四年之後男孩終於學成歸國，女孩也堅貞如是，但是女孩卻在去接他的途中出車禍，當場死亡。」講到這裡時，不知不覺的已經到了四十樓。

這個時候，沒想到三弟只不過說了一句話，三兄弟馬上坐在樓梯上大哭。他說：「大哥，二哥，對不起，我忘了把鑰匙放在車上了！」

軟體開發者的悲慘世界就像這個笑話一樣，眼看目標就在眼前，這時卻發現最關鍵的地方，亦即軟體品質沒有達到要求而將導致前功盡棄。而更令人絕望的是，在最後一刻才發現這樣的窘境，此時要及時彌補缺失卻是相當困難的。

就像笑話中的三兄弟一樣，他們必須有人回車上拿鑰匙，而原來走過的路要再重新再走一次。軟體專案開發也是一樣，先前沒做好的開發作業必須回過頭重新把它們做好，而後續的開發作業也必須重做一次。但問題是客戶馬上就要驗收，開發者通常已經沒有足夠的時間來解決問題了。

對於開發者而言，這樣的悲慘世界可真是可怕的夢魘呀。然而，這樣的現象為什麼老是一而再，再而三地發生，到底是什麼地方出了問題呢？顯然問題多半出在開發者無法儘早發現程式瑕疵並及時因應，卻讓自己在茫然無知的狀況下，讓問題不斷地惡化下去。而依據筆者的實務經驗顯示，這種現象可以從開發者的紀律、確認與驗證的過程兩方面來理解。

開發者的紀律

可能有些人會把無法早期發現程式瑕疵歸咎於「無常」兩字，就像笑話中大哥、二哥所提供的故事一樣。得確，軟體專案的本質是充滿不確定性的，實際上會發生的問題是很難事先預料得到的。然而，但當我們經過深入地去檢討後卻常常可以發現，藉由良好的開發者紀律可以減少因為一時疏忽而產生不良後果。就如同笑話中三弟所言的疏忽一樣，許多程式的瑕疵是因此在剛開始分析或設計時就己經存在了需求或設計規格中，但卻直到最後一刻才會被發現。

依據筆者的觀察，一些軟體開發者在分析或設計時，經常不會事先思考需求或設計規格的驗證問題，而是等到程式實作出來過後才會開始思考測試該如何進行。由於在需求或設計規格上，並沒有思考到如何驗證的問題，其內容就常常就會因為不夠完備而顯得草率而馬虎，自然使得程式碼的產出常常會缺東漏西，甚至產生一些錯誤。

而等到開發者在開始進行編程時，規格上所缺漏的部分自然就不會被實作出來，而需求與設計的錯誤更會具體地被實作在程式碼當中。當然部分需求或設計的疏漏與錯誤，可藉由在實作的過程中被發現。但對於一些經驗、能力不足、或態度不夠積極的程式實作人員而言，他們通常只會按照規格來開發程式，而不會去進行溝通並發展良好的程式結構來解決工作上的問題。

另外，有些開發者會習慣於暫緩程式的驗證，他們總以為進行程式的開發遠比進行測試驗證還來得要有生產力，甚至在面對時程的壓力時，會選擇省略功能測試，期望以整合測試或系統測試來將測試問題延後處理。

因此，以上種種原因，使得測試作業太慢開始、程式碼之中散佈著因為需求或設計規格、或實作結構問題所產生的一些疏漏或錯誤，這些現象使得程式瑕疵擴散或蔓延的速度比修正的速度還來得快。當程式的瑕疵愈變愈多、除錯就會顯得更困難，對程式的除錯與測試都是個沉重的負擔，更不用說可以及早發現程式中的瑕疵了。

確認與驗證的過程

在軟體工程的領域中，確認過程代表確定開發產出滿足及符合原始的設計，也就是把事情做對。而驗證過程則代表檢查開發設計滿足或適合預期的使用，也就是做正確的事情。在台灣，一般大型軟體專案多半採用 V-Model 的軟體開發流程模式來進行軟體的確認與驗證。此開發模式展現了不同抽象層次觀點的開發作業與相關的測試作業之間的關係。

一般而言，我們會將軟體專案開發分為三個開發層次，高階的抽象層次為處理使用者的需求分析；中階的抽象層次則將重點置於將所了解的需求轉化為軟體架構；低階的抽象層次主要為系統功能的細部設計與系統實作。

在每個開發作業完成之後，開發者應當進行確認過程來確保開發作業符合需求及設計規格後才能進行下一個開發作業。而直到程式被實作出來之後，開發者必須依序按照不同開發層次的要求來進行驗證過程，以各種不同類型的測試作業來檢查軟體是否真能符合實際使用上的需求。如下圖所示。

此開發模式配置了良好的結構方法，讓每個開發作業都可以根據前一個開發作業的詳盡產出來進行作業。而測試計劃可以很好地提早在編程前就開始進行規劃，如此將為專案省下大量的時間。但事實上，採用 V-Model 在專案後期仍然還是會從程式碼當中出現不少瑕疵，似乎按照規格來開發系統仍然無法解決需求與設計在專案後期因為經常變動而影響程式碼品質的困境。

為什麼會如此呢？從 V-Model 的開發流程結構我們其實不難發現到，愈高階層次的開發作業是愈晚被驗證的，而在它尚未被驗證前，較低階層次的開發作業都會因為它的變動而受到影響。例如，在系統測試時，如果發現軟體無法通過驗證的原因是因為需求規格的瑕疵，如此就必須回過頭來修正需求規格的瑕疵，並重新進行設計與程式開發。

換句話說，愈高階層次的開發產出，其瑕疵是愈晚才會被驗證出來。而相較於低階層次的開發產出，其衝擊影響力又是相當嚴重的，因為這代表瑕疵將會在較低層次的開發產出中擴散與蔓延。因此在實務上要做到「早期發現、早期治療」，讓需求或設計的瑕疵盡早被發現與解決其實並不容易。除非需求與設計規格能夠儘早驗證完全無誤，然而，在程式在尚未實作出來之前，開發者又該如何做到這一點呢？

如何早期發現、早期治療？

如果對於需求或設計，開發者無法先驗證其可行性與正確性，而必須等待程式實作出來才能靠測試作業來加以驗證的話，那麼我們將會期望測試作業必須具備相當高的效率及足夠的涵蓋面。但實際上，測試的效率與涵蓋面會受限於專案的時程與成本，因此希冀測試作業能夠有效率地找出程式所有的瑕疵的想法往往是不切實際的。

一旦我們愈晚進行測試，因未驗證的分析設計而產生的遺漏或缺陷將會使程式中的缺陷不斷地擴散，如此將會使開發人員更窮於應付。換句話說，不良的需求或設計往往會加重測試的負擔與壓力。

因此，要用較低的成本與時間來達到最佳的程式品質，其關鍵並不在於測試的效率與涵蓋面，而是在於提昇需求與設計規格的品質。然而，我們該如何發展出較佳的需求與設計規格，並且能夠及早發現存在需求與設計規格的瑕疵以適時加以修正呢？

筆者認為，開發者在進行分析及設計的過程中，就應該同時思考需求規格與設計該如何驗證的問題，而不是等需求或設計規格完成後才去設計驗證的程序。同時，在需求或設計規格交付之前，應該讓團隊針對欲交付產出進行實質上的技術審查，以集思廣義的方式促進集體反思，以找出分析或設計者所忽略的潛在問題與瑕疵。

如此將使因個人盲點而產生之需求或設計的瑕疵會因此大幅減少。因為，為了要找出如何驗證需求或設計規格的方法，就會強迫我們客觀思考自己的想法是否完備、有沒有被我們所忽略的問題沒被考慮到，進而完善我們的思慮。另一方面，請別人來一齊檢查自己所分析或設計的開發產出，更可以站在更客觀的立場來看問題，透過不同的觀點來了解自己是否忽略了什麼。透過集體思考的過程，我們可以得到更為一致的需求與設計觀點，就不會流於個人的執著與徧頗。

在驗證需求或設計方面，在分析或設計過程就必須思考驗證需求或設計的具體方法。這代表了不一定要等實作設計的程式完成後，才能開始寫測試程式。如果我們無法依據設計來寫出測試程式時，其實正代表著我們設計的思慮多半是有問題的，我們對設計的想法可能還不夠具體，如此的設計是很可能存在許多我們所想不到的缺陷與瑕疵的。當然，先寫測試程式並不是唯一可以「在分析或設計過程中思考需求或設計如何驗證」的方式，不管採用任何形式的開發方法論，筆者認為都應該先想到如何以具體可行的方式來驗證需求與設計。

舉個例子來說，架構設計必須包含架構的概念驗證（POC，Proof of Concept）。架構設計者不應該省略驗證架構的程式，卻期待程式實作者來幫他實現未經驗證的設計構想。他必須自己親自驗證架構，如此才能透過驗證，使自己設計的架構趨於成熟，而不致讓開發團隊在使用架構的過程中出現問題叢生的困擾。

而在技術審查方面，在設計過程中進行 software inspection，除了可以提早發現需求或設計的瑕疵，更能促進團隊成員相互學習以提昇開發能力。品質不只要靠檢驗，而是不去設計有缺陷及瑕疵的系統。然而，不管開發者的分析或設計能力有多強，都不能保證其開發產出絕對沒有問題。在這種思維下，全員參與是一個好主意，於是讓同僚參與需求或設計規格的審查可讓系統設計更趨於完善，一來可以用比較客觀的方式來確保設計符合需求及使用者需要，二來也可以讓同僚更清楚我們在做什麼，相互觀摩學習並增進團隊的效能。

因此，在思考如何驗證需求與設計的過程中，會讓我們不知不覺地把焦點放在最主要目標的達成上，可以讓我們更有效地整合開發作業與測試作業。而讓同僚參與分析與設計的討論過程中，將有效撤除開發作業之間的藩離，透過同步的協同作業可得到截長補短的好處，如此將發揮一加一大於二的團隊綜效。其實同步與整合，正是讓程式瑕疵得以早期發現、早期治療的有效的做法呀。

大家都不喜歡 Late Changes，我也不例外。不過，也不要有受害者的心態，把 Change 當做誰的疏失、誰的錯誤、是誰害的。我們還是得認清事實，就是專案初始時的需求規格永遠是不完整的。

好的機制，是要讓產品專案能夠快速應變，而同時間又能把品質的傷害、生產力的影響降到最低。

好的 manager，要懂得取捨。Late Changes Can Be Good.

學長所提的觀念其實並不難理解，但依據同人實務上的觀察卻發現，在面對壓力時，專案管理者往往無法做適當的取捨。理想上，大家都會以為加一點東西、做一點小改變，程式應該不會有什麼問題才對。但事實往往是「千金難買早知道，萬般無奈想不到」，改變對軟體品質的傷害、生產力的影響總是超乎我們的想像，更可怕的是變更所造成的災難似乎永無止盡。當初取捨時的樂觀，事後我們才會發現那其實是無知。

就拿同人在〈沒有說出來的衝突〉中所提到的故事為例。某個專案在面臨即將驗收之際，一些開發者因為專案的壓力而不遵守修改紀律時，該專案的管理者以為應該不會發生太大問題也沒有予以糾正，但結果卻讓專案失去了控制。經歷過這次經驗及教訓，他分享了他的體會：以放縱不遵守紀律來因應變動需求其實是不智之舉。而從他的經驗我們不難發現到，人們總是習慣高估了自己的能力，低估了風險。因此，在做出自認為臨機應變的取捨之前，不妨先想一想，我們憑什麼認為這次的變更是個好變更？

理論上，依據《專案管理知識體系指南》（PMBOK）的指引，我們可以找到在專案的範疇、成本、以及時間變動管理必須注意的共通要點，以確保專案在變更過程中能夠確實因應實際變化，包括了：

1. 確認變更對專案有正面的影響。
2. 確認造成變更的因素已經發生。
3. 管理變更。

這也就是說，好的變更必須反應專案實際現況、並對專案有實際助益、同時必須要是可管理的。因此，如果只是想到什麼就做什麼並不是好的變更。因為那代表我們對專案變更的想法只是停留在觀念階段，我們必須找到客觀資料來證明它是可行的，然後再進一步地發展出具體可實踐的方法。否則專案將充滿著許多未知的不確定性，將很容易讓專案陷入危難之中。

《孫子兵法》說：「多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」如果我們發現了變更會帶給專案實際助益，更需要週全的可行計劃來確認它是可以被實現，這才是專案的致勝之道呀。然而，具體做法又是如何呢？同人認為必須客觀而穩定地觀察專案現況，並依據客觀資料來分析變更將對專案所造成的影響。然後再進一步因應實際問題來調整計劃，以做採取行動的有效控制基準。

因此，不須把問題推到收尾巴過程才來解決，也不用在此黑暗時期讓無窮無盡的壓力來讓我們喘不過氣。只有在當我們懂得面對變化不斷地對計劃進行調整時，這才是真正的認清事實。

「菩薩畏因，眾生畏果」，變動所造成品質的傷害、生產效率的低落的苦果往往是因為我們太重視執行結果，卻忽略了規劃與控制的過程。如果我們不懂得專注於過程中，把注意力放在因應變化來進行可行計劃的調整上，我們將很難判斷這次的變更結果是否會造成下次變更原因。過程對了，結果自然就不會錯。雖然 Late Changes Can Be Good，但好的變更也必須是來自於可行計劃呀。

Powered by ScribeFire.

那篇文章提到期待專案問題藉由收尾巴的過程而得到解決的想法，往往是要付出很慘痛的代價的，但很多人卻無法從這些寶貴的經驗中得到教訓。同人在那篇文章提到一個觀念，就是不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計很難會有足夠的空間來容納新功能。因此，最好還是採取務實的做法，針對變化而適時修正計劃，不要樂觀而天真的以為收尾巴就可以解決問題。

在那篇文章的迴響中，志威兄與可樂魔也分享了他們的經驗。志威兄提到了，專案的控管真的是一門藝術，需要累積許多豐富的經驗。每次專案的歷史重演，真的會讓人抓狂。可樂魔則提到，他看到他們公司的眾家 PM 們，他們的心態還是希望在這最後的階段可以「修復所有問題」，但真的有價值的「記取錯誤經驗」和「再利用經驗」都像是狗屁一樣。

對於他們的分享，本篇文章正巧提出同人因應相同問題的實務做法。我認為如果那篇文章指出了對待樂觀主義的心態問題，那麼本篇文章所討論的則是如何處理軟體專案樂觀主義的問題。本篇文章在 CNet / ZDNet Taiwan 分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。

在軟體專案的開發過程中，時程提供了專案進度追踪與資源運用的控制基準，讓專案管理者能夠可以用更有效率的方式達成專案目標。通常，軟體開發者會藉由軟體開發的經驗或專業預估合理的專案時程。理論上，專案時程代表軟體開發者對軟體需求者的承諾，同時也是專案團隊合作、與進度追踪的重要依據^[1]。

不過，軟體開發專案與其它的產品開發在開發流程上卻存在顯著的不同。就本質而言，軟體本身具有抽象化的特質，因此，軟體開發的專案時程預估大多是靠個人的直覺或主觀認定。每個人對時程預估都有所不同的認知，對同一個軟體開發作業，經由不同的人所預估所需花費的時間與成本往往會有不同的結果，但卻沒有人會確切知道該作業實際的完成時間與所耗資源與成本。

實際上，合理的軟體專案的開發時程往往要在接近完成時，才會真正地出現。在接近專案的尾聲時，我們才會真正知道我們預估的開發作業時間是否合理。但直到專案後期才發現時間不足或需要投入更多的資源時，卻會為開發團隊帶來巨大的壓力，結果常使整個開發團隊措手不及而造成專案的迫切的危機。

為什麼計劃總是與現實差別那麼大，莫非真的是「計劃趕不上變化，變化比不上老闆一句話」嗎？難道軟體專案的時程真的是無法預估的嗎？事實上，沒有時程的預估，專案就無從管理；而依照筆者在實務上的觀察中發現，問題的核心並不在時程無法正確預估，而是在於對時程的預估抱持太過樂觀的想法，因而對專案進行了無效的管理。

過程與目標的混淆

以管理的觀點來看，專案時程只是為了要達成專案目標，所採用的最可行的方案。但在規劃過程中，專案的不確定性將使得時程的預估變得很複雜，而為了增加規劃的效率，通常需要做一些假設來簡化這些的複雜性，以使時程規劃可以順利進行。

換句話說，專案時程本身存在許多的前提假設，這代表專案時程並非達成專案目標的唯一途徑，而是依計劃進行的一種可能性。但換個角度來看，專案時程有時候可能會無法實現，或是就算它真的被實現了，卻不一定能達成專案的真正目標。例如，軟體開發者常常在緊要關頭才會發現到，原先所規劃的時程其實是太低估了開發作業所需要的時間，或是發現專案時程遺漏了重要的工作項目，使得整體的工作產出無法整合。

因此，在開發過程中，造成軟體專案無法按時程進行的最主要原因，其實是在於把計劃錯認為專案目標，而忽略了該檢視存在專案時程中的假設是否依然成立，因而造成了專案目標與過程之間產生了混淆。依照筆者的觀察，這種混淆往往會造成管理過程的溝通問題、以及進度追踪的數字迷惘的兩大後遺症。

管理過程的溝通問題

在軟體工程領域中，理論上，依據軟體的功能與複雜度，可運用軟體度量的概念來具體客觀度量軟體規模，以協助軟體開發者預估合理的開發時程與成本。不過，在實務上，要準確地度量合理的開發時程，其實還是取決於軟體開發團隊的歷史經驗與度量的成本。

如此看來，只要時程規劃者擁有足夠的歷史經驗並且願意投入相當的度量成本，發展出精確的專案時程是可行的。但事實上，為專案做這樣的投資卻是不見得會划得來的。因為，軟體開發的過程常常會牽涉許多複雜的人際溝通與事物的變化，要巨細彌遺地將它們表達成數字，並不是一件容易做到的事情，同時也很容易讓管理變得很複雜，結果往往會未蒙其利，先得其害。

例如，筆者常常會發現有些專案管理者，只會一味地要求開發者提供開發作業的的進度，卻沒有深入理解開發過程的實際狀況，也不去專注於溝通與協調。因此，對於團隊成員在開發的過程中所出現的困難，往往無法提供立即而有效的協助，而在無力改善問題的情形下，讓問題不斷地擴大而造成時程延宕也是必然的結果。

其實，預估開發作業的工期並不在於數字的精確性，而是為了形成團隊成員彼此分工合作的基礎。換句話說，要讓管理更有效率，時程規劃與進度控管必須兼顧專案的複雜性與團隊的文化。更明確地說，時程規劃與進度追踪應該支援團隊達成專案目標，而不是用來產生對團隊的限制。因此，專注於專案時程數字的表象而忘了忽視了團隊的溝通，很容易形成在管理上的本末倒置。時程規劃的重點，應該是放在如何增進團隊的溝通與互動上。

進度追踪的數字迷惘

軟體專案的開發產出，是非常難以具體客觀衡量的。一般而言，在軟體功能完成之前，沒有人能夠穩定而客觀的量測出軟體開發工作的實際完成比例，而大多僅能憑開發者的直覺與主觀認定。筆者常看見開發者所回報進度完成比率，感覺好像在菜市場在喊價（叭啦拳）一樣，流於沒有意義的數字遊戲。我們很難從這些數字中了解到真實的專案狀況，一切都只是估計，而這些估計只是開發者的樂觀想法而已。

沒有穩定而客觀的具體衡量，我們就看不到專案的實際狀況；不了解專案的實際狀況，我們就難以知道專案是否偏離目標，及時採取行動以調整專案計劃。結果，大多數的情形都是，發現專案已偏離目標時，其落差已經相當大而必須採取激烈的手段才能挽回，但卻無形中卻增加了更多的副作用，因而使專案陷入了惡性循環之中。

事實上，要讓管理發揮效果，必須掌握「行動要快，動作要小」^[2]的原則，要在專案偏離目標但還尚未迷航的情況下，就必須立即採取有效的行動，修正專案的方向。因此，專案績效的衡量不在於表象上的進度數字，而是在於掌握專案的目前實際狀態。專案績效不只要看是否有按照時程來投入資源，更要看所完成的實際產出是否符合預期。這也就是說，單憑開發者投入的總工時是不足以衡量專案開發的實際績效，因為這是假設資源的投入百分之百會變成專案的有用產出，事實上這個假設在實際上多半是不成立的。

所以，管理者應該按照已驗證的軟體功能或模組來衡量專案進度，而不是開發者憑感覺的估計，這樣才不會掉入問題的陷阱而忽略了問題本質。在管理的過程中，必須要能比較出目前專案所投入的成本與專案的目標、以及時程計劃之間的差距為何，如此才能明白專案未達預期到底是要改善資源的運用，還是需要調整計劃，才能朝向達成專案目標而努力，否則就好像瞎子摸象一樣，一切都只能聽天由命罷了。

如何客觀衡量開發績效？

然而，軟體開發不比其它的專案，想要做到客觀而穩定地衡量出開發績效，其實並不容易。然而，依據 Gilb’s law 的法則：「任何東西只要需要度量就會找到方法可以度量，有量總比沒量好」，以最經濟的方式，針對需要來發展出適當的客觀績效衡量方法。績效衡量的重點並不在於精確度，而在於促進團隊的溝通以及有助於專案目標的達成。但要如何才能做得到呢？在此，筆者分享一些個人的實務經驗。

許多軟體開發者習慣用開發流程來做任務分工，也就是用分析、設計、實作、測試等作業來分工，但如此開發作業不容易有客觀的衡量標準；而且也容易遺漏了一些重要的作業，例如常常在測試過程才會發現分析或設計的瑕疵與遺漏。

因此，筆者認為，開發作業應該依軟體功能來分類，這樣不但可讓開發作業彼此獨立，同時也容易讓軟體需求者清楚功能是否有所遺漏，使軟體開發作業可以達到「彼此獨立，全無遺漏」（MECE，mutually exclusive, collectively exhaustive）的良好結構。

有了良好的開發作業結構後，我們就可以依開發過程的階段來衡量專案進度了。例如，開始進行開發時，就代表此功能進度達到 25%、功能開發完成時，就代表此功能完成進度達到 50%、功能驗證或審查完成時，就代表此功能完成進度達到 75%、而完成功能的交付後，則此功能完成的進度才算是 100% 完成了。

當然，筆者所提的方法，不見得可以適用所有的軟體專案，不過，此方法是基於軟體開發的實事求是的原則與精神。依照此原則，我們可針對專案實際需要發展出確實可用的績效衡量方法。讓軟體專案可以具體客觀衡量，這樣才不會被無可救藥的樂觀主義所矇騙了呀！

1. 陳建勳，陳漢山譯（2006），專案管理之美學，歐萊禮。
2. 曾昭屏譯（2006），溫伯格的軟體管理學－系統化思考（第一卷），經濟新潮社。

對此，志威兄提到，從程式設計者、網站委外服務之業主、專案管理者之間，存在了觀點的差異。而他指出，讓專案順利及圓滿完成的解決方案就是找到一個稱職、有能力的專案經理。志威兄認為良好的專案經理除了具備相當的領域知識與時程控管能力外，最重要的就是溝通協調能力，他提到了：

他必須將老闆時長過於遠大的夢想，找到執行與實做的方法，更要能溝通協調把像在各星球各自為政、不同部門的理性嚴謹工程師與行銷、美工等創意人員，通通揉合在一起朝相同目標前進。也能夠事前就規劃好整個專案的時程，並且設定適當的check point，隨時掌控進度與各部門狀況。

事先做好規劃，按照時程追踪進度無疑是確保專案成功的基本動作，相信大家都能了解這個道理。但事實上，在軟體專案的開發過程中，要完全做到卻又發現窒礙難行，因為軟體開發本身存在著抽象性與變動性，要事前就規劃好整個專案的時程，恐怕只是個無法實現的理想。

然而，雖然「計劃趕不上變化，變化比不上老闆一句話」，但趕不上或比不上並不代表要放棄計劃，否則專案的成功也只是聽天由命的偶然罷了。同人認為，軟體專案要成功，關鍵不在於如何照計劃進行，而是要「計劃」當計劃趕不上變化時該怎麼辦。換句話說，當軟體專案管理者把計劃當成死的名詞時，他將不會成為稱職的專案管理者；稱職的專案管理者會把計劃當動詞，用以採取適當行動，才會讓專案走向成功。

實際上，根據同人在軟體專案開發的實務經驗，期待專案問題藉由收尾巴的過程而得到解決的想法，往往是要付出很慘痛的代價的，但許多人總是無法從這些慘痛教訓中得到啟示。在專案後期所發現的問題、或產生變動，其所花費的成本與消耗的開發人員的青春，與產出軟體的功能與品質相比往往是划不來的。於是，歷史不斷地重演，軟體開發的痛苦經驗也一再地被經歷。

問題並不在於軟體功能無法說加就加、說改就改，而是在收尾巴的過程中自廢武功。不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計怎麼會有足夠的空間來容納新功能？就好像想在堆滿東西的房間中，還要硬塞一些東西進去，這樣的結果當然很容易會讓我們在這房間中跌倒。

為什麼不採用較為務實的做法呢？在放新東西進去前先好好地整理一下房間，把不必要的東西收起來，才能有足夠的空間放得下新東西呀。增加軟體功能也是同樣的道理，根據需求思考現有架構及設計概念如何適當地做調整。

只有設計概念的完整性才能幫助我們形成簡單可行的計劃，然後才能讓軟體開發者採取更有效的行動，否則在變化無常的情況下很容易讓專案成果失去控制呀。這或許就是 XDite 所說的「完全不想去理解技術方面的事」的人最容易犯的毛病，簡化軟體開發的技術問題，認為一切只是 INATT（It’s not about the technology）。

理論上，專案管理中的專案收尾過程（project closeout）本來就不是用來讓開發者增加功能、修改缺陷的，而是吸取專案的經驗及教訓（Lessons Learned），以利後續專案當作規劃參考。因此，期待在專案收尾巴才來修改軟體的想法，事實上，正代表著專案在規劃、執行及控制的過程中有所遺漏。然而，一廂情願地認為收尾巴可以彌補這些在專案過程中的遺漏，這種想法實在是太過樂觀了呀。

Powered by ScribeFire.