方法二：有序管理需求變更
在實際項目中，實現(xiàn)需求變更的成本隨著開發(fā)進度呈指數(shù)級增長。需求變更的流程化管理能保障正常的開發(fā)進度，將變更及時反應(yīng)到開發(fā)和測試等部門。
以下描述的是一個典型過程（如圖1）。一項變更請求在需求管理系統(tǒng)中被提交后，與之關(guān)聯(lián)的各個部門，如市場、項目管理、產(chǎn)品研發(fā)、QA、測試等，都會有相關(guān)人員接到系統(tǒng)通知而介入。他們將組成評估團隊，根據(jù)實施難度、周期、費用、對其他機制的影響等指標，對該變更進行全面考察和評估。
DevSuite提供了靈活的工作流程定制和管理能力，圖形化工作流引擎將工作流圖形轉(zhuǎn)變?yōu)楣ぷ髁髂_本，因此項目管理員可以在圖形化界面中，輕松快速的定制項目組項目管理流程。
如上圖中紅色框內(nèi)為需求的工作流程，用戶可以根據(jù)公司的實際業(yè)務(wù)流程，定制符合需要的需求流程圖，系統(tǒng)可以同時定義多條項目工作流程，以適應(yīng)不同規(guī)模、不同類型的項目。
方法四：需求有效驅(qū)動開發(fā)與測試
在理想的研發(fā)管理平臺中，需求管理與所有規(guī)劃、開發(fā)、測試管理過程相集成。因此，需求的正規(guī)表達Spec，以及圍繞Spec正在或?qū)⒁M行的開發(fā)任務(wù)和測試任務(wù)，都能被納入綜合考慮的范疇，便于評估團隊估算該變更造成的“牽一發(fā)而動全身”的潛在影響。有時，還要結(jié)合商業(yè)需求進行考量，為了趕上產(chǎn)品的佳發(fā)布時機，有些變更將被拒絕。
變更請求被批準后，與之相關(guān)聯(lián)的開發(fā)、測試任務(wù)都會在系統(tǒng)中被一一標記出來，以提醒程序和測試部門的相關(guān)負責(zé)人，引發(fā)這些任務(wù)的需求已經(jīng)變更，請他們做出相應(yīng)的調(diào)整處理。在系統(tǒng)中跟蹤這些任務(wù)的進展，可以實時掌握該變更的落實情況。變更完成后，也可以核算它對開發(fā)周期和費用的實際影響，與評估時的預(yù)測相對比，找出差異的原因，為將來更準確地評估提供參考。
DevSuite提供了變更標識功能，通過變更標識子任務(wù)，我們可以選擇受影響的開發(fā)、測試任務(wù)，建立變更標識子任務(wù)，該子任務(wù)將以旗幟形式反映到開發(fā)、測試任務(wù)中。變更標識子任務(wù)不但能夠標識變更，還能夠幫助團隊進行變更反饋，通過文字記錄和狀態(tài)改變，任務(wù)負責(zé)人員可以將需求變更對于任務(wù)的影響及時回饋給需求管理人員。另外，對于需求實際改變的內(nèi)容，需求負責(zé)人員可以創(chuàng)建變更推送子任務(wù)，通過郵件系統(tǒng)，可以將變更信息發(fā)送給該需求的干系人。
方法五：需求指導(dǎo)項目規(guī)劃與執(zhí)行
縱使項目初都有比較全面的計劃，延期仍然會時常發(fā)生，即便是在管理機制比較成熟的大型研發(fā)企業(yè)中，跳票也不可避免。通常情況下，導(dǎo)致跳票主要有以下幾點原因：功能設(shè)計規(guī)劃過多，很多又無法刪除，如不增加開發(fā)時間，產(chǎn)品幾乎不能完成；缺乏有經(jīng)驗的管理或開發(fā)人員，不能準確估計工作量；任務(wù)執(zhí)行缺乏規(guī)范，開發(fā)人員隨意更改功能設(shè)計，影響整體進度；過高的人員流動率，導(dǎo)致知識的流失，任務(wù)不能及時跟進。
