事由

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

　　討論

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

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

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

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

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

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

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

【編輯推薦】

1. 淺談項(xiàng)目管理中該如何review與重構(gòu)
2. 銀行核心業(yè)務(wù)系統(tǒng)項(xiàng)目階段性總結(jié)
3. 愚蠢的項(xiàng)目經(jīng)理與聰明的程序員
4. 項(xiàng)目設(shè)計(jì)與范圍管理之項(xiàng)目啟動(dòng)
5. 現(xiàn)代軟件工程之績(jī)效管理