模板
教程
環境
性能
功能
管理
怎樣從容應對客戶的需求反復？
在軟件項目的研發過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發，維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業的新動態，都為軟件帶來不斷完善功能，優化 性能 ，提高用戶友好性的要求。我在自己的軟件 項目管理
在軟件項目的研發過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發，維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業的新動態，都為軟件帶來不斷完善功能，優化性能，提高用戶友好性的要求。我在自己的軟件項目管理職業過程中，幾乎天天面對用戶的需求變更，切身感受到，如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，用戶的耐性漸漸消逝，研發人員的士氣也越來越低落，最后所有的人都在等待一個結果：項目最好馬上結束。所幸，在不斷的學習和實踐中，我總結了幾點比較有效的方法，在軟件研發階段能夠較好地解決這方面的問題。 1．需求分析階段采用原型方法明確用戶需求。
在軟件項目的需求分析階段，有大量需求信息需要收集、篩選、加工，這是需求管理的開始?？蛻艉脱邪l兩方面的人員對需求的理解呈現“大體上共識多，細節上差異多”的特點。即使通過反復溝通，最終在時間表限制之內也能拿出一份“用戶需求說明書”，但是以實踐經驗，用戶需求的描述永遠是“不夠清晰”、“不夠明確”的。這主要是因為在這個階段，所謂的產品都在大家的大腦中構思，正如100個人讀《射雕英雄傳》，就有100個郭靖的形象一樣，每個人的想法都是大致輪廓相同，而細節差異很大。在此階段，原型開發是一個較好的輔助手段，它將存在于大家頭腦中的虛境實實在在地表達出來，一個界面，幾個控件，外觀形式固定了，功能描述明確了，這就是研發部門對用戶的需求理解。此時與用戶再次溝通，用戶基本上可以說出來：“這是我想要的”，或者“不，這不是我想要的，我要的是……”。一般情況下，原型之后的需求溝通就實際得多，雙方的理解迅速向一個折衷方案靠攏，一個可以指導研發過程的需求說明書正式誕生了。
2．需求分析之后的研發過程采用嚴格的需求變更管理流程。
一旦需求分析階段結束，此后如果用戶要求有新的需求加入交付的軟件系統中，需要走需求變更管理流程。這個流程必須在軟件項目成立之初與用戶約定好，一般的軟件企業內部有需求變更的管理流程，可以向用戶解釋這種管理的必要性，直至與用戶就此問題達成共識為止。不必擔心用戶不會接受，有過多次成功研發軟件項目經驗的需求變更管理流程，有著它不容置疑的合理性，這正是軟件企業的經驗和價值所在，用戶最終會理解和同意的。
需求變更管理流程各家企業有各家的做法，借用CMM的需求管理KPA來講，需要兩級需求變更管理委員會（以下簡稱CCB）來處理，即產品CCB和項目CCB。產品CCB處理涉及到產品一級的需求變化，主要體現在需要多個職能部門，多個軟件項目，以及與其他產品線的協調等問題；項目CCB處理本項目內部的需求變更，如不同小組之間的協調，接口變化等等。每一個需求都要經過CCB的審批，決定這個需求的各種屬性描述是否合適，如時間緊迫性，采用的技術是否有風險，對系統的重要程度，需求變更的波動分析，需求實現的資源狀況。在與會人員對需求屬性取得共識之后，規劃需求實現的版本，確定時間計劃。
原文轉自：http://www.anti-gravitydesign.com
