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

事由

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

討論

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


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


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

 

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

 

以下是我們對待國內(nèi)企業(yè)進(jìn)行CR所需要的步驟：

 

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