軟件項目失控的原因是從(cong) 八十年代起就有許多人研究的課題。眾(zhong) 多見仁見智的結論中有兩(liang) 點大家達成了共識：一是不穩定的需求，二是不合理的估算。

不穩定的需求我們(men) 往往無可奈何，屬於(yu) 不可控因素，那麽(me) 不合理的估算從(cong) 何而來？我們(men) 經常見到的是，過於(yu) 樂(le) 觀的估算帶來了不合理的項目進度目標，結果自然是逼著項目各種走捷徑，從(cong) 頭到尾都處於(yu) 救火模式，交付有各種埋雷的產(chan) 品也是意料之中。

四十年過去了，各種軟件估算方法層出不窮，然而軟件估算現狀並無大的改觀，依然困擾著軟件團隊。CMMI2.0已經把估算升級為(wei) 一個(ge) 獨立的實踐域，歐美敏捷圈子一些人則直接喊出“放棄估算”。兩(liang) 種截然的態度昭然！

估算怎麽(me) 這麽(me) 難？是軟件估算的三個(ge) 自帶病毒讓其深陷泥潭。

病毒一：估算發生在錯誤的時機、由錯誤的人決(jue) 定

估算一般都是項目初期的活動，這往往也是我們(men) 對項目各種信息了解最少的階段。需求不清晰，解決(jue) 方案不確定，風險未識別，估算自然不靠譜。

誰來做估算？正常情況下應該是幹活的人，估計大部分CMMI組織的估算流程也是這麽(me) 寫(xie) 。但真正做估算的人往往是客戶、市場部、老板。技術人員隻是走個(ge) 估算流程，讓交付時間合法的同時順便給自己挖了個(ge) 大坑。當然，許多組織也會(hui) 做個(ge) 像模像樣的可行性分析，雖然，我還沒有看到一個(ge) 說No的。

錯誤時機、錯誤的人做的估算隻是自己挖坑自己跳的遊戲。

病毒二：堅決(jue) 不改的估算

初始估算不靠譜可以理解，可是項目執行中發現它是錯的還是不改就不能原諒了。後牆不倒是我常聽到的一句話，完全脫離實際的估算已經失去了意義(yi) 。

病毒三：用不靠譜的估算考核團隊

如果估算真是走走過場倒也傷(shang) 害性有限，可實際上估算的目標對項目團隊影響巨大。不按期交付在領導和客戶眼裏就意味著失敗，不努力，沒能力。所以加班成了常態，捷徑成了習(xi) 慣，隱患成了必然。

攜帶這三種病毒的任何一種的估算方法都不可能有效，市場的壓力和強勢的客戶是產(chan) 生病毒的原因，真正破解確實不容易，這需要大環境發生一些根本變化。但也不代表我們(men) 什麽(me) 也做不了，這裏提供兩(liang) 個(ge) 緩解的招數供參考。

招數一：客戶/老板4選3，團隊4選一

估算不外乎考慮四個(ge) 選項：進度、成本、實現需求範圍、質量要求。可以先讓客戶或老板選擇其中任何三項，但把剩下一個(ge) 控製權留給團隊。馬不吃草還要快跑的想法實在有點想太多。

緩解招數二：輕量，做中學，做中估，管控風險

哪怕不能改變強加的估算結果，團隊還是應該實事求是的做估算，把它當做風險識別管控的重要手段，如果估計值和目標差別大，需要盡早想辦法, Do more with less。

估算要輕量，just enough，遠粗近細。團隊對項目的了解隨著時間不斷遞增，這些新的知識要用在項目管理中。敏捷大大縮短了學習(xi) 反饋周期，重估算是每個(ge) 迭代的選項。但計劃驅動模式也可以在一些點重新評估項目，如，解決(jue) 方案的確定，每個(ge) 重要的裏程碑節點。

管控風險有可能意味著項目創新，也可能意味著放棄一些影響不大的活動。多年前我提過一條建議，國內(nei) 絕大多數軟件組織都需要一個(ge) “緊急項目管理流程”，這個(ge) 流程絕不需要覆蓋CMMI的幾百條實踐，三級的組織並不一定所有項目都按三級來管理。

合理假設也是CMMI對估算的要求之一，無法根治，起碼理解約束條件，這也是我寫(xie) 這篇文章的意義(yi) 。

以上內(nei) 容來自公眾(zhong) 號《老叢(cong) 講桌》

了解更多CMMI認證