需求全流程管理.docx

技術經(jīng)營體需求全流程管理方案1 背景1 需求堆積，業(yè)務部門不滿2 開發(fā)團隊疲于奔命3 對需求缺乏有效的評估方法，難以保證所承接的需求合理，必要性4 陷入趕工的惡性循環(huán)，承諾的時間無法兌現(xiàn)，損害專業(yè)性、權威性，難以建立信任2 目標1 保證重要業(yè)務需求被及時滿足2 系統(tǒng)化提升技術部工作效能，充分發(fā)揮技術團隊價值3 避免資源占用隨意性，保證長期項目、核心產(chǎn)品的開發(fā)不受干擾4 使用系統(tǒng)方式對需求進行管理，解決人工管理的隨意、低效、混亂、難以追溯等問題3 流程3.1 流程圖見文檔尾部3.2 說明本流程對應trac系統(tǒng)，流程中各個環(huán)節(jié)在系統(tǒng)中指派、留痕需求管理員即需求提報入口，需保證人員唯一性基本的需求文檔管理和審核方式為在trac系統(tǒng)中上傳文檔或粘貼SVN文檔地址鏈接，相關人員進行確認在系統(tǒng)中留存確認日志。對于重要項目需求管理員可要求上傳的文檔中包含人工簽字版的掃描件3.3 名詞解釋業(yè)務需求由最終用戶或者領域專家從業(yè)務的角度提出的需求，無需技術知識。核心內容主要包括業(yè)務目標、業(yè)務流程、業(yè)務實體、業(yè)務規(guī)則、功能規(guī)則等。系統(tǒng)需求由系統(tǒng)分析師或者架構師從軟件系統(tǒng)的角度，以實現(xiàn)業(yè)務需求為目標提出的需求，核心內容包括功能設計、界面設計、用例或功能點描述、非功能性需求說明等。3.4 注意事項不可有例外 所有系統(tǒng)需求，無論大小都要納入系統(tǒng)管理。任何一個表面看起來改動很小的需求，都有未知的水下部分，必須通過完整的流程、評估、分析才能確定其真正工作量和風險 系統(tǒng)生命周期是連貫的，所做的任何功能變更必須被管理，任何一個功能邏輯需要有可追溯的需求，否則系統(tǒng)將快速走向混亂和未知，發(fā)生錯誤時也無法分析原因、判斷來源。如果一次修改不改變任何需求，僅僅是對原需求錯誤實現(xiàn)的修正，則屬于系統(tǒng)BUG，應該在另外的故障跟蹤系統(tǒng)中管理?？刹眉?粗評開發(fā)工作量在1小時以內或整體上線工作量在4小時以內的，可以歸類為“小修改”進行流程裁剪 粗評開發(fā)工作量超過1小時的需求，應該按照完成的流程進行正式管理，確保按時交付，符合業(yè)務目標和需求。需要專人集中進行方案設計和工作量評估，工作量應該以小時為單位，保證 粗評整體上線工作量超過1個人月的需求，應該作為長期項目，采用迭代開發(fā)方式，在PMS系統(tǒng)中單獨創(chuàng)建產(chǎn)品和項目進行管理。每次迭代時間不超過一個月，每次迭代完成后進行總結，確定下一次迭代的目標和范圍，直到整個項目目標完成。確保項目計劃完整 制定項目計劃時，需考慮和包含完成項目需要的所有任務和資源，而不是僅考慮開發(fā)人員。如需要業(yè)務部門提前準備的材料，需要外部系統(tǒng)開發(fā)的接口等等都需要包含在項目計劃中進行管理、跟蹤。本文檔是從需求管理角度描述需求的全流程，項目管理方面更具體規(guī)范另文說明。4 業(yè)務需求提報要求提報業(yè)務需求，需包含以下基本內容：n 業(yè)務需求文檔n 有效性說明（參見 有效性標準）n 預期效益說明 （參見 預期效益評估）n 上線公告（功能上線時提示所有業(yè)務人員了解系統(tǒng)變化影響的通知內容）n 是否緊急（需調整已有需求排期，保證最快上線的情況）有效性標準 正確性：邏輯清晰、無歧義；符合已知的領域知識、業(yè)務規(guī)則和常識，沒有自相矛盾 一致性：可能影響到的所有業(yè)務環(huán)節(jié)需要經(jīng)過具體分析，明確修改方案；各環(huán)節(jié)邏輯一致、呼應 必要性：需求實現(xiàn)后能產(chǎn)生可預測、顯著的商業(yè)回報；無可接受的替代方案 可行性：業(yè)務操作可行性；技術實現(xiàn)可行性可驗證：有明確具體的測試驗證標準、驗證數(shù)據(jù)預期效益評估 提升：如訪問量、重復購買率、客單價、毛利率、粘度、品牌形象等等降低：如庫存占用、跳出率、退貨率等等量化指