e Process：COCOMO II》書中勾勒出的估計誤差，在項目先期誤差甚至達到4倍，隨著項目進展估計的誤差才逐步縮小，所以對進度和工作量的估計應(yīng)該是一個范圍，在項目中不斷根據(jù)實際情況去修訂，上面例子中合理的答案應(yīng)該是項目延期一倍。不過遺憾的是這種幾十年前的過時理論常常會被人忽略和遺忘，而去追逐先進而耀眼的靈藥。
估計就是估計，決不能被當成嚴肅的承諾。項目經(jīng)理的“英雄本色”情結(jié)經(jīng)常會鼓勵其尋找“銀彈”的沖動：利用現(xiàn)有資源按時完成已經(jīng)超期的項目，當然有時是有領(lǐng)導(dǎo)和用戶的重壓。根據(jù)項目管理中進度、質(zhì)量、資源和范圍的約束關(guān)系，這顯然是不可能的任務(wù)。如果期望在預(yù)計的時間內(nèi)完成，一般會在需求上下功夫：考慮優(yōu)先實現(xiàn)那些用戶業(yè)務(wù)所必須的需求，力求削減并非必要的需求，或是在后續(xù)版本提供——實踐證明通過充分溝通大約可以達到目的。當然調(diào)整資源也是一個辦法，問題是增加人手的時機，搞不好反而會更加延緩進度——“人月神話”的brooks法則。如果想在“質(zhì)量”上打主意，我個人認為不是好的選擇，原因是軟件系統(tǒng)對需求的實現(xiàn)程度是二元的——要么實現(xiàn)，要么沒有實現(xiàn)，不存在部分實現(xiàn)的情況，換句話說就是系統(tǒng)的質(zhì)量和所實現(xiàn)的需求是相關(guān)的，質(zhì)量的降低也就意味著需求沒有實現(xiàn)。
上面的解釋中存在邏輯上問題：將軟件系統(tǒng)開發(fā)的理論擴展到了系統(tǒng)產(chǎn)品的研發(fā)，不過應(yīng)該還是有些借鑒價值的。


一個荒禿的山坡。
一具血淋淋的尸體仆倒在地上。
從尸體的傷口上判斷頭顱是被野獸撕掉并叼走的。
“為什么還不提取DNA樣本？” 凱瑟琳問到。
“需要等法醫(yī)來確認他真的已經(jīng)死亡?！?格雷森無奈的聳聳肩。
——《CSI: Crime Scene Investigation》
點評：原來號稱制度建立完善的美國也會鬧出這樣的笑話！其實無論多么完美的流程制度都不能確保在任何實際情況下是適用的，如何平衡規(guī)范和靈活始終是個難題，其原因是你要解決的是現(xiàn)實問題，而不是在紙面上或在頭腦中。如何使流程適應(yīng)當前項目的特點，確定流程中各項活動的先后順序、執(zhí)行的程度、乃至是否需要執(zhí)行這項活動，關(guān)鍵是流程定義者和執(zhí)行者對活動及其影響的理解程度。
回顧一下軟件項目生命周期模型，包括瀑布（線性）模型、V模型、螺旋模型、增量模型、迭代模型、XP極限編程等等，其實包含的活動多是相似的，不同之處在于項目過程中各個活動的取舍、先后順序、執(zhí)行的程度——之所以出現(xiàn)如此多種的模型，關(guān)鍵在于無法用一種模型去適應(yīng)特性各異的項目。如果說有什么模型可以通用，那就是RUP（Rational Unified Process） ，不過它是一個靈活的軟件開發(fā)流程平臺，換句話說，它即指導(dǎo)你如何去做，同時又沒有明確告訴你如何去做——如何運用還得靠使用者的聰明才智。
對于研發(fā)項目而言、既然流程的定義和裁剪是無法回避的問題，那么就不要避重就輕的將它放在工作的角落里。一般的解決方法是根據(jù)項目特點（例如周期、工作量、投入資源、難易程度等等）將項目分類，并分別制定各類項目的開發(fā)流程；或者制定流程裁剪的原則，規(guī)定哪些活動可以裁剪、哪些活動可以合并。
另一種方法是針對各項活動，列出可裁剪屬性、可選項、裁剪指南，明確實踐中對單項活動的執(zhí)行情況。例如對“確定信息采集的方法”可以進行如下定義：

活動 可裁剪屬性 可選項 裁剪指南
確定信息采集的方法 技術(shù) 用戶評審 對于新需求
觀察 對于現(xiàn)有操作的充分理解
使用任何現(xiàn)有的應(yīng)用 如果應(yīng)用已經(jīng)存在，并且至少覆蓋用戶的一些需求

上面兩種方法分別從宏觀和微觀角度來指導(dǎo)流程的裁剪，都是非常必要的。有的QA、項目經(jīng)理可能會對其工作量提出疑問，我個人認為這項工作是項目管理的關(guān)鍵之一：一個良好的過

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://www.vanceur.cn/pmqhd/index.html