事由

　　北京程序員王XX遭遇車禍成植物人，醫生說活下來的希望只有萬分之一，喚醒更為渺茫。可他的Lead和親人沒有放棄，他們根據王XX工作如命的作風，每天都在他身邊念：“XX，需求又改了，該干活了，你快來呀！”，奇跡終于發生了，王XX醒來了，***句話：“需求又改了？”。

　　討論

　　此故事說明了什么？程序員遭遇需求變更（CR）是非常常見的事情，如果哪位程序員還沒遇見過需求變更的話，那堪稱神人啊。 尤其是當下念頭瀑布開發模式以及逐漸被敏捷開發(XP/SCRUM)所代替，在需求每天隨時都可以變化的今天，開發人員們如何來應對呢？大家可以來討論一下。

　　其實關于需求變更，和客戶合作一般有2種方式，一種是簽署框架協議，按headcount來算錢的，也就是按照多少人花費多少月時間來算錢，這種情況比較爽，因為大部分的實施都是按照ODC的形式來做的，有時候客戶方也有技術人員，所以如果一個很大的需求變更出來的話，客戶自己也會衡量一下有沒有必要，另外就算有必要，也要看所花費的時間和優先級，因為這牽涉到錢，和項目的Delivery時間，不過這種形式一般不會牽涉到需求變更的簽字啥的，但是偶爾有的項目也會有的（不信任的情況下），目前我們就是按照這種模式來做。

　　另外一種形式，往往是Project base的，或者是和國內一些國企干活的時候要這樣，尤其是一個項目在客戶那邊有多個領導的這種情況，非常難搞，因為在簽署項目的時候我們都會有非常明確的來定義需求變更的處理流程，要求雙方必須按照確定的流程來操作，都是要約定變更需求的優先級，Delivery的時間點是否有變化，金額是否增減等事項，否則就要按照合同來辦事了哦。

　　不知道大家在日常工作中是如何處理CR這種事情的？

　　以下是我們對待國內企業進行CR所需要的步驟：

同時最終的CR記錄應該是和如下表格差不多的：

原文鏈接：http://www.cnblogs.com/TomXu/archive/2011/12/15/2289008.html

【編輯推薦】

1. 淺談項目管理中該如何review與重構
2. 銀行核心業務系統項目階段性總結
3. 愚蠢的項目經理與聰明的程序員
4. 項目設計與范圍管理之項目啟動
5. 現代軟件工程之績效管理