軟體專案時程總是過於樂觀?(下)

| | | | | | 留下回應

    

(前文)

進度追踪的數字迷惘

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

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

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

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

如何客觀衡量開發績效？

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

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

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

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

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

附註：

曾昭屏譯（2006），溫伯格的軟體管理學－系統化思考（第一卷），經濟新潮社。