同人很喜歡 David Ko 兄提到愛因斯坦為 Insanity 這個字所下的定義：「Doing the same thing over and over again and expecting different results」我認為這個定義很貼切地描寫許多人在軟體開發過程所展現的心態；過去做過行不通的做法，卻認為在今天可以行得通，結果讓人一直瘋狂或是不斷地精神錯亂。

但為什麼人們要盲目地做些行不通的事呢？其實以同人這麼多年軟體開發的經驗來看，他們不見得是意識不到這些做法行不通，而是可能因為害怕與恐懼，讓他們不敢嘗試新的方法來解決問題。

縱使無法解決問題的挫折是令人沮喪的，但如果要放棄過去習慣的做法來開發系統，他們更會茫然不知所措，擔心因此對現況失去掌控能力。於是明知過去的做法有問題，但更害怕失去它就會一無所有，於是只好將它緊緊地捉在手上，並期待這一次會有奇蹟出現，改寫過去失敗的命運。

不過如果人們理性一點，都會意識到要改變命運不應該期待奇蹟，而是需要「勇氣」讓我們改變心智模式，然後採用有效的方法來解決問題。在這方面，同人覺得比較幸運的是我常碰到好主管，能夠支持我想要把事情做好的想法。

記得過去的主管 Y.L. Liu 曾經告訴過我的話：「如果過去這樣做行不通，那今天就應該嘗試不一樣的做法」即使改變必然會遭遇到阻礙，然而當我們勇於面對阻礙而因應問題時，才能促使我們打破過去的習慣來進行有紀律地思考與行動，進而更有效地解決問題。

紀律，也就是 discipline 這個字。它的意義並不是做我們過去熟悉的事，而是熟悉了解問題是什麼，並加以解決問題的過程。如同我過去的文章所強調的，軟體開發不只是工程，或是工藝，而是解決問題的過程。敏捷開發其實並非依賴制式的軟體開發流程或方法，而是基於重要價值觀與原則發展出來的實務，而最重要的價值觀就是為了思考如何「解決問題」，至於使用流程方法都只是手段而不是目的。

然而，根據同人的經驗，想要軟體開發過程運用以上的觀念，我認為最困難的是對專案目標的混淆。在這次的分享會之中，同人也發現有些 PMP 背景的朋友，他們很關心如何準確預估專案的範圍、時程與資源，因此希望了解敏捷開發如何來解決這樣的問題。但其實敏捷開發方法根本不需要做精確的預估，因為改變是無法預估的。所以它強調的是反應變化的能力，而不去為預期或抑制變化做太多的努力。

或許有人會把精確的專案預估，看成是專案成功的重要目標之一。但以同人這位 PMP 對專案管理的認知來看，精確預估並非專案的目標，而是達成降低專案風險目標的手段之一。或許用這種手段來蓋房子，或生產看得到、摸得著，可以明確度量的產品可以做得很好，但用它來開發軟體卻不見得可以行得通。

我們應該改變對軟體開發專案的傳統思維；假如軟體開發的本質，就是難以精確預估，那麼我們就不該將力氣浪費在預測上，而是應該用來進行對專案更有效益的事情上。但這不代表敏捷開發方式不做規劃，而是規劃的重點不在精確地預測未來，而是用來定義專案的基準線；利用每一次的反覆過程的回饋，用來改善或調整後續的計劃，以增進我們回應變化的能力。

因此，使用敏捷開發我們不需要具細彌遺地預測未來的改變，只需集中心力面對今天所發生的問題。換句話說，開發者也不需要一份不會變更的功能需求清單，而是了解專案目前所要解決的實際問題，進而運用(adopt)思考及創意、調適(adapt)方法然後再熟練(adept)所需要的技能來解決問題。

那麼，以上敏捷開發的思維是否打破專案管理的基本觀念？同人從不認為如此。依照 PMBOK 的專案管理知識領域與流程本來就支援管理改變的做法，問題只在於管理者是否掌握住變更管理的重要原則並熟練它們：

首先、必須確認改變對專案有正面效益；

其次、必須確認影響變更的因素已發生；

最後、最重要的是管理變更。（PMI，2000）

我們看到這些原則不但並不違背敏捷開發的思維，同時兩者是相通並且相輔相成的。的確，對於軟體專案而言，改變意味著增加軟體開發的風險，但害怕專案風險的心態，也代表你的團隊面對風險只能迴避它們以確保安全，但你所獲取的利潤也相對變得較低（DeMarco & Lister，2007）。於是你必須辛苦地在市場上試圖降低軟體價格來與對手競爭，除非你能夠勇敢地面對挑戰，選擇快速回應變化才會創造機會，為專案產生更大的正面效益。

那麼對於環境或需求的變化，軟體開發團隊要如何快速回應呢？依據同人的經驗，大規模的事先設計（BDUF，Big Design Up-Front）通常無法立即迅速地反應變化，而且常常會造成過度的工程化（over engineering）的問題。而依賴開發組織導入某些流程、工具或方法論其實也並非成功的關鍵。我認為只有增進團隊溝通與合作，讓團隊能為面對問題而共同努力，才能夠快速地回應變化。

或許有人會認為詳盡的文件可以增進溝通，但實際上它的成效不高而且常常要人們花費很多的心力，除非你發現它真的有幫助，否則你應該只需要寫必要的文件。雖然工具或方法論可以增進開發的效率，但它們也會讓工作變得艱難。因為無法被替除的工作，它們是更具備知識密集的特性，需要更有才幹的人來完成任務（DeMarco & Lister，2007）。所以在導入任何工具或方法論之前，你應該提醒自己，敏捷開發是以人為基礎，面對的是現實而非理想。

誠如 David Ko 在分享會中說得好，任何方法的導入如果最後變成政令宣導時，那就非常不妙了。同人則以為快速回應的關鍵不在於遵循方法論的做法，而在於面對專案的現實問題，讓團隊共同因應問題而改變。David Ko 提出了很多他的專案所導入的做法，同時分享他感受到團隊成員自動自發的喜悅，也讓同人希望能夠見賢思齊。

到了候車大廳，站務人員表示請趕時間的乘客可以直接出站。同人看到排隊處理悠遊卡出站手續的人實在太多，於是同人聽從站務人員的建議直接出站，而沒有處理悠遊卡的出站手續。但這樣一來，不能用悠遊卡坐公車，身上又沒零錢，只能期望捷運站的免費接駁公車。但沒想到花了一個小時等捷運接駁車，卻都還坐不到內湖線的接駁公車，發現捷運公司的免費接駁車的調度，還真是離譜。

在松山機場站，捷運公司的人告訴我們，免費接駁車可以坐到動物園站，但內湖線的接駁公車沒有進入機場的站牌，所以必須坐接駁車到中山國中站，再轉搭內湖線的免費接駁公車。大家等了好一會兒，終於坐接駁車到中山國中站，但內湖線的公車怎麼一直都等不到呢？看到對面往動物園方向的車子一班接一班，而在內湖線接駁公車等待的地方，就只能看到公車一班接一班開走，卻絲亳不見接駁公車的身影。

等了半小時，讓同人的耐心已經將要消耗殆盡了，於是問了在站牌捷運公司的服務小姐。我問：「為什麼對面的接駁車都已經開走三班了，為什麼到內湖線的公車卻一班都還沒來呢？」服務小姐表示因為對面的接駁車是從松山機場發車會比較快，往內湖線的接駁車已由麟光站在 8:30 分發車，開過來要花一點時間，請我們耐心等待。

旁邊有一位小姐聽到服務小姐的說法，覺得很不合理。她說：明明捷運發生系統異常是在晚上 8:00 左右，為什麼直到 8:30 才發車？服務小姐辯稱是因為與公車業者協調需要時間。不過這樣的說法讓在場等接駁車的乘客不能接受。在這段期間，同人又看到往動物園的接駁車又過去一輛了，而且乘坐的人非常少。大家開始質疑，為什麼不從對面的接駁車調度一些過來支援內湖線的接駁車呢？

後來，好不容易看見我們這邊有接駁車開過來，但卻不是往內湖的車子，而是開到松山機場站。可是，看到班班幾乎空車就令人生氣；排隊的人龍那麼長，接駁車卻是開往沒有人要去的地方；讓同人不得不說，捷運公司實在是沒有規劃好接駁車正確的需求。

往內湖線的接駁車終於來了，但坐上車的人只有一位，因為它「客滿」了。這讓在場的乘客愈來愈生氣，服務小姐只能用手中的無線電詢問公車調度的情況，但似乎情況難以掌握而對事情沒有幫助。讓同人最後不想浪費時間，放棄坐免費接駁車回家的計劃，選擇自己花錢坐計程車回家。

對於台北捷運內湖線的系統異常，同人一直都是抱持著同情的態度。我自己也經歷幾次的系統失常的事故，不過看到捷運公司人員，為了處理或解決系統狀況而奔忙，加上自己系統開發的經驗，讓我比較能接受新系統出現不穩定的情況。

然而，看到這次離譜的調度，讓我很懷疑真正的問題是捷運公司面對問題的態度。在處理問題前沒有把腦袋放在正確的位置，不能針對客戶的需要來思考問題，而只是浪費資源在不重要的事情上。顯然捷運公司對解決問題的訓練是不足的，問題不是服務人員盡了力沒有，而是他們在盡力之前，到底有沒有把問題想清楚呀！

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

同人對同事甲的看法沒有什麼意見，因為說實在的，我也吃不出這道菜有什麼不好。不過，如果精於美食的同事甲說得是正確的，那麼就代表這家店的這道菜品質有問題。於是我說：這其實代表他們 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）。需要是抽象而片斷的，本身是非結構化的，而可用的軟體需求卻必須是具體而完整一致的，具備結構化的特性。

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

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

要如何充分溝通？

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

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

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

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

大家都不喜歡 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.

在日常生活上，我們常會發現從不同觀點中體會出一致性的道理，如同專案管理與易經，我們可以從專案管理的觀念與方法中，常會發現它們與易經的觀念是相通的。尤其在軟體開發團隊中，不管是在問題的解決上或對團隊成員的管理上，都與易經有不謀而合的地方。

其實專案所談的不外乎談人與事，而軟體與其它類型的專案並沒有特殊的差異。因此，我們可以普遍性地說，表面上專案管理與易經看起來各自呈現出不同的風貎，但本質上它們的背後其實存在著共通的一致性的道理。

為什麼會有這種巧合呢？易經所探討的是事物變化的道理，而專案本身就是企業在面臨環境變化的挑戰所應運而生的一種概念。在變化無常的環境中，變是唯一不變的真理，正因為如此，企業要因應環境的十倍速變化，端賴於在專案管理過程中，了解變化的道理來達成專案使命，以滿足企業的實際需求。

所以專案管理和易經的哲理自然是會相通的。換句話說，專案管理雖然是基於專案需要，依照西方的管理理論所發展出來管理概念與方法，但它必然會符合易經的基本原理。

所以，對於專案管理者而言，如果能善用易經哲理，可讓他們在重要概念上具備理解掌握變化原則的能力，同時培養在管理上以簡御繁的技巧。易經的觀念並不複雜，雖然它是探討事物變化的道理，但事物變化的本質是簡易的，是可以被掌握的，事物會遵循著不變的自然法則而改變，而非沒有章法的改變。這就是所謂的易之三義－變易、簡易與不易的道理。

在專案過程中，因應專案可能發生的變化所發展出來的管理實務，我們可歸納為專案管理的九大知識領域，如同易經中的先天八卦，是古人觀察大自然，將各種自然現象以八種概念表示，歸納成先天八卦。先天八卦代表事物的對待觀點，也就是象徵陰陽相互對立的原則，也就是易經說卦傳中所言的「天地定位，山澤通氣，雷風相薄，水火不相射」，這段話的意思是，先天八卦是陰陽對立的，它們是乾坤相對、艮兌相對、雷巽相對、坎離相對，圖示如下。

先天八卦代表事物的本體，因此相當於專案管理中的不同知識領域。九大知識領域中，專案整合管理是專案管理各領域的整合，因此它和所有知識領域是一體的，不可分割的，而剩餘的八大知識領域，照理可以易經的先天八卦來類化它們。

首先思考乾坤的「天地定位」，乾乃統天，坤乃順承天。高階管理者(Management)從混沌之中找到企業成功的機會，制定出專案 (Project)必須要達成的目標，並指派專案經理(Project Manager)來領導專案的進行；而專案經理必須建立專案團隊(Project Team)，並且讓利害關係人(Stakeholder)貢獻其心力在這個專案上，這正是範疇管理(Scope Management)及人力資源管理(Human Resource Management)的工作內容。因此用乾卦來類化規模管理，用坤卦來類化人力資源管理。

那接下來艮兌的「山澤通氣」呢？遇到艮為險阻與兌之毁折，專案經理必須注意專案不確定性因素所造成的困難與產出的缺陷問題，這正是風險管理(Risk Management)與品質管理(Quality Management)的工作內容。因此用艮卦來類化風險管理，用兌卦來類化品質管理。

至於震巽的「雷風相薄」，雷以動之，風以散之。專案經理必須了解專案執行的步驟為何，找到最適合執行的方法來達到專案目標；並且在適當的時機將專案利害關係人所需的資訊以正確的格式傳遞給當事人。這正是時間管理(Time Management)與溝通管理(Communication Management)的工作內容。因此用震卦來類化時間管理，用巽卦來類化溝通管理。

最後坎離的「水火不相射」，坎水流通，離火為文章。專案經理必須掌握專案資源並有效控制成本；以及管理外包商的合約之履行。這正是成本管理(Cost Management)與採購管理(Procurement Management)的工作內容。因此用坎卦來類化成本管理，用離卦來類化採購管理。

我們從先天八卦在專案管理知識領域的歸納結果中看到，乾卦代表專案的範疇管理、震卦代表專案的時間管理、坎卦代表專案的成本管理、艮坤代表專案的風險管理，這些與事有關的管理，都是以陽卦所主的。而在另一方面，坤卦代表專案的人力資源管理、兌卦代表專案的品質管理、離卦代表專案的採購管理、巽卦代表專案的溝通管理，這些與人有關的管理都是陰卦所主的。因此，從易經的分類觀點來看，專案管理的知識領域可簡單地區分人的管理與事的管理。

然而，這種區分，其實只是一種簡化的譬喻，目的是讓我們抓著管理的重點。但實際上，專案的人與事是一體的、無法分割，無論是專案的人或事的管理，管理者都必須兼顧另一方的觀點，太重視事而不注重人，專案的任務會找不到人可以委以重任；太重視人而不注重事，團隊的成員會不知因何而忙、為何而戰。

因此，管理者應運用陽卦的積極求知精神，讓成員可以很容易地理解問題，使他們能夠面對問題，專心地運用他們的專業，有效地解決問題，以發揮作業的效率與品質；同時管理者也要運用陰卦的柔順包容態度，制定簡單的團隊規範，以適合每一位成員，讓他們很容易就能遵從而產生團隊紀律，以促進團隊成員的個人成長與團隊士氣。這正是從易經繫辭中所言的「易則易知，簡則易從」的易簡之理在專案管理上的實際應用呀。

乾以易知，坤以簡從；易則易知，簡則易從；易知則有親，易簡則有功；有親則可久，有功則可大；可久則賢人之德，可大則賢人之業，易簡而天下之理得矣。天下之理得，而成位乎其中矣。

易經除了先天八卦代表事物的對待觀點外，還有後天八卦代表事物變化的流行觀點，也就是說明事物的演變過程。易經說卦傳以季節的更替來解釋後天八卦的演變與所代表的方位。我們可以舉一反三，後天八卦象徵事物的變化過程，對專案而言，其變化過程就相當於專案管理的過程。所以，後天八卦正可說明專案的過程（Project Processes）。

萬物出乎震，震東方也。齊乎巽，巽東南也，齊也者，言萬物之潔齊也。離也者明也，萬物皆相見，南方之卦也，聖人南面而聽天下，嚮明而治，蓋取諸此也。坤也者，地也，萬物皆致養焉，故曰致役乎坤。兌正秋也，萬物之所說也，故曰說言乎兌。戰乎乾，乾，西北之卦也，言陰陽相薄也。坎者，水也，正北方之卦也，勞卦也，萬物之所歸也，故曰勞乎坎。艮，東北之卦也，萬物之所成終而所成始也，故曰成言乎艮。

上面這段話說明了後天八卦與季節和方位的關係，以震卦、巽卦代表春天的來臨與消退，方位分別代表東方與東南方，離卦、坤卦代表夏天的來臨與消退，方位分別為南方與西南方，兌卦與乾卦代表秋天的來臨與消退，方位分別為西方與西北方，坎卦與艮卦代表冬天的來臨與消退，方位分別為北方與東北方，圖示如下。

所謂「萬物出乎震」，寒冬已盡，春天來臨，萬物生機開始萌發；所以震卦代表專案起動，「帝出乎震」相當於專案的起始流程（Initiating Processes）。

接著「言萬物之潔齊」，萬物生機萌發有早有晚，但會是一個接著一個，有其一定的順序與規則；所以巽卦代表在專案流程中，制定規章與標準(Regulations and Standards)，見賢思齊，使專案執行過程中，專案團隊能使用一致的語言（Language）及術語（Terminology）。

然後「離也者明也，萬物皆相見」，夏天的太陽散發著光與熱，照耀萬物顯得大自然生意盎然；所以離卦代表專案流程中，與專案成員見面，說明專案目標，並公開專案管理計劃書（Project Management Plan）。

由以上說明，不難發現從「齊乎巽」到「相見乎離」相當於專案的規劃流程（Planning Processes）。

專案有了規劃之後，接著「坤也者，地也，萬物皆致養焉」，萬物受大地滋養，自取其所需；所以坤卦代表投入資源，依照專案計劃來執行專案，「致役乎坤」相當於專案的執行過程（Executing Processes）。

接下來，「萬物之所說」，這裡的「說」字應作悅字解。秋天來臨，萬物呈現出宜人的景象，令人和悅。有了春夏的努力，秋天是收割的季節，當然令人愉悅；因此兌卦代表在專案執行的專案交付成果（Deliverables)，也就是專案團隊依照專案管理計劃書，投入資源所得到的工作產出（Work Product）。

然而，到了「言陰陽相薄也」，收成以後，卻讓人感到一股肅殺之氣逼近，因為這時陽氣漸消，陰氣漸長，寒冷的冬天的腳步慢慢接近了；因此乾卦代表專案可運用的專案資源逐漸減少，此時浮現的問題將會造成對專案嚴重的衝擊，將會造成天人交戰（天：不確定性所造成的危機，人：專案團隊），也是危機及專案衝突（Project Conflict）最容易發生的時候，必須持續監督專案的狀況，加以控制使之符合專案目標。

因此，由以上說明可知，從「說言乎兌」到「戰乎乾」相當於專案的監控流程（Monitoring and Controlling Processes）。

接著「萬物之所歸也」，寒冬來臨，萬物將停止活動，大自然呈現出一片死寂；所以坎卦代表專案告一段落或遇到困難而停止，此時應該停下來檢討專案執行過程中發生的問題，收集經驗及教訓（Lessons Learned），以提供其它相關專案，在未來當成規劃或執行專案之參考依據。

最後，「萬物之所成終而所成始也」，萬物經由寒冬之螫伏，等待春天之來臨再出發，休息是為了走更遠的路；因此艮卦代表專案現階段的結束，同時也代表專案下階段或新專案的將要開始，專案雖具有臨時性的特質，但組織卻是不斷地發展的。

因此，由以上說明可知，「勞乎坎」到「成言乎艮」相當於專案的結案流程（Closing Processes）。

可能我們會訝異，東方《易經》哲理竟和西方專案管理理論如此不謀而合。先天八卦與專案管理知識領域相通；而後天八卦與專案管理流程相合。但其實正如《易經》繫辭所言：

天下同歸而殊途，一致而百慮。

一陰一陽之謂道，繼之者善也，成之者性也；仁者見之謂仁，智者見之謂之智，百姓日用而不知，故君子之道鮮矣。

真理的本質雖然是不可見的，但卻會以各種不同的面貌呈現，因此，管理的精髓並不拘抳是東方或西方，亦不受限於哲學或科學，只在於我們是否能領悟其關鍵。易經的管理心法與專案管理的實務應用其實是殊途而同歸，一致而百慮的呀！