有些處在這種情況下的 PM，會訴諸於量化一些不需要量化的事物。由於不確定該做什麼，或者害怕去做最需要做的事，他們會以次要事情占據時間。當 PM 與專案之間隔閡變大時，把注意力放在不必要的圖表、資料表、查核清單、以及報告的情形就會增加。PM 在某一時刻開始相信資料流程就是專案，這是有可能的。他們把焦點擺在不重要而容易做的事情上（試算表或報告），而不是重要而難做的事情上（程式設計成果或進度）。他們也許會自欺說，如果照著特定程序執行，然後把查核清單上的事做好，專案就可以保證成功（或者比較嘲諷地說，任何會發生的失敗，技術上都不是他們的錯）。
上述這段話其實並沒有反對軟體專案預測與規劃，Berkun 認為「不要把焦點擺在流程及方法上，專案經理應該把焦點放在團隊上，簡單的規劃和追踪系統當然還是要用，但必須符合專案的複雜度，以及團隊的文化。更精確地講，規劃和追踪應該支援團隊達成專案的目標，而不是設限」。Tom Democro 曾說「沒有度量就沒有控制」，站在管理的角度來看，人們無法管理不能度量的事物。所以在專案管理過程中，軟體度量扮演著重要的角色。這也正如同喲哪桑學長所說的：
聲稱無法評估、不能衡量，只是沒有努力嘗試的藉口。如果你真的想要成長、要進步，要當PRO的工程師、PRO的團隊，你一定要量。
不過，站在務實的角度來看，我們也要小心軟體度量會帶來的數字陷阱。許多專案管理者迷失在軟體度量的數字遊戲中，他們所度量的結果忽略了目標，結果讓專案徧離軌道。其實軟體度量的重要性並不在於準確的預測數字，而是在於軟體開發實事求是的態度。把軟體開發過程都巨細彌遺地表達成數字，用來衡量專案績效，其實並不容易做到，而且很容易讓管理變得很複雜。雖然，理論上，我們可以運用經驗法則找出軟體開發所需的努力拿來做軟體度量，然後再用軟體系統開發控制理論的機械觀點來看軟體專案的進行，只要投入資源就可以把軟體產生出來；但這種論點其實是假設軟體專案開發是線性模式，而忽略其它非線式因素的影響，但這些非線性因素，卻往往是專案複雜度大增以致無法掌控的主因。
我認同學長提到了「要成長、要進步，度量不可少」的看法，但卻想提醒「數字只是表象」，專案團隊必須探索隱藏在數字所透露的訊息。沒有錯，或許對於專案想要開發的軟體，我們只要想量，就一定能量。但量子力學的測不準原理卻告訴我們：在微觀粒子層面，當我們愈清楚知道粒子的位置時，我們就愈不可能知道粒子確切的運動情形。專案軟體開發牽涉複雜的人事變化，所以適用於微觀子層面。於是，當我們花愈多時間想要掌握開發產出時，我們就愈沒有時間掌握開發團隊。軟體度量採用的量測模型只是可以用來解釋我們可以如何來掌控軟體開發的進行（不是唯一）的方式。因此，度量的重點不在於它完全正確，而是在於對你現在的專案團隊完成專案目標是有用的，因此是讓數字來幫助團隊進步，而不是讓團隊照著數字來照章行事。世界上最珍貴的東西其實是金錢與數字所無法衡量的，問題不要只看表面這是《小王子》一書中的名句。，所以千萬不要掉入數字陷阱而讓我們忽略問題本質，這也是身為 PRO 的軟體開發人員所必須注意的呀。
Powered by ScribeFire.
