軟體專案的樂觀主義

本篇文章係投稿於 CNet / ZDNet Taiwan 的初稿，主要是探討開發者及管理者在軟體開發過程中，對專案時程與進度的過度樂觀現象的解決之道。不過，在投稿之後，因應在網路上也興起對專案收尾巴的討論熱潮，同人因此在網誌發表了一篇〈當軟體專案計劃趕不上變化時〉。

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

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

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

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

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

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

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

過程與目標的混淆

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

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

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

管理過程的溝通問題

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

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

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

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

進度追踪的數字迷惘

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

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

事實上，要讓管理發揮效果，必須掌握「行動要快，動作要小」曾昭屏譯（2006），溫伯格的軟體管理學－系統化思考（第一卷），經濟新潮社。的原則，要在專案偏離目標但還尚未迷航的情況下，就必須立即採取有效的行動，修正專案的方向。因此，專案績效的衡量不在於表象上的進度數字，而是在於掌握專案的目前實際狀態。專案績效不只要看是否有按照時程來投入資源，更要看所完成的實際產出是否符合預期。這也就是說，單憑開發者投入的總工時是不足以衡量專案開發的實際績效，因為這是假設資源的投入百分之百會變成專案的有用產出，事實上這個假設在實際上多半是不成立的。

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

如何客觀衡量開發績效？

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

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

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

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

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