需求管理制度

1、精選優(yōu)質(zhì)文檔-傾情為你奉上零壹移動互聯(lián)需求管理制度（2.0版，2015年）擬制人肖波日期審核人日期批準(zhǔn)人日期修改記錄日期版本作者/修改者描述審核人V2.0肖波修改需求開發(fā)管理流程與相關(guān)人員分工   目錄第1章 總則第1條 為規(guī)范零壹移動互聯(lián)（以下簡稱“零壹”）需求管理，明確各階段的工作內(nèi)容、處理流程、參與人員以及相關(guān)干系人的職責(zé)，在保證需求質(zhì)量的同時，提高需求實現(xiàn)效率，特制訂本制度。第2條 本制度適用于研發(fā)部的所有系統(tǒng)開發(fā)需求。第3條 本制度適用的讀者包括需求開發(fā)負(fù)責(zé)人、需求提交人員、需求評估人員、開發(fā)人員、測試人員、生產(chǎn)運維人員、項目管理員等。第2章 職責(zé)與分工

2、第4條 職責(zé)分工角色職責(zé)需求提交人員1. 負(fù)責(zé)需求調(diào)研與編輯、編寫業(yè)務(wù)需求申請表、提交業(yè)務(wù)需求審批。2. 根據(jù)需求評審和評估意見，及時修改業(yè)務(wù)需求，并發(fā)給需求相關(guān)干系人。3. 配合需求開發(fā)、測試人員提供業(yè)務(wù)知識的支持。4. 協(xié)助確認(rèn)需求開發(fā)結(jié)果。5. 負(fù)責(zé)需求上線后驗證工作。項目管理人員1. 負(fù)責(zé)需求審批、評估、技術(shù)文檔評審、測試、上線等需求管理流程的整體協(xié)調(diào)工作。2. 組織需求評估會議。3. 處理測試申請-提交測試部門進行分配與測試。4. 維護需求信息、跟進需求變更以及需求處理進展，定期向相關(guān)領(lǐng)導(dǎo)、部門匯報需求進展。需求開發(fā)負(fù)責(zé)人1. 參與需求評審，從技術(shù)角度對需求實現(xiàn)方式、風(fēng)險等進行評估。

3、2. 制定需求開發(fā)計劃，分配需求開發(fā)人員。3. 負(fù)責(zé)需求所有工作的溝通、協(xié)調(diào)管理。4. 負(fù)責(zé)需求開發(fā)進度、成員、變更管理。5. 負(fù)責(zé)或參與需求所有成果的審批。需求評估人員1. 從架構(gòu)、業(yè)務(wù)、技術(shù)、風(fēng)險等方面對業(yè)務(wù)需求的內(nèi)容和實現(xiàn)方式進行全面評估，并提出評估意見。2. 審核根據(jù)評估意見修改后的業(yè)務(wù)需求。3. 需求評估人員包括開發(fā)部門、測試部門、產(chǎn)品部門以及其他參與具體需求工作的人員。開發(fā)人員1. 幫助需求提交人員分析、確定業(yè)務(wù)需求。2. 編寫需求相關(guān)技術(shù)文檔。3. 組織實施軟件需求、系統(tǒng)設(shè)計等文檔評審，參與測試計劃、測試案例、測試報告文檔的評審工作。4. 負(fù)責(zé)需求的設(shè)計、開發(fā)，確保代碼符合編碼規(guī)

4、范和代碼安全規(guī)范。5. 負(fù)責(zé)系統(tǒng)集成、編譯部署及單元測試。6. 提交測試申請，必要時提供技術(shù)支持，配合需求測試人員完成測試環(huán)境的搭建。7. 配合需求測試人員處理環(huán)境問題，解決測試缺陷。8. 負(fù)責(zé)提交上線申請，參加上線評審，配合上線部署，負(fù)責(zé)上線問題的查詢和解決、上線復(fù)核。需求測試負(fù)責(zé)人1. 參與需求評審，從業(yè)務(wù)測試角度參與對需求實現(xiàn)方式、風(fēng)險等進行評估。2. 分配需求測試人員，對需求測試過程管理，負(fù)責(zé)需求所有工作的溝通、協(xié)調(diào)管理。3. 制定/參與制定測試計劃，參與測試案例、測試報告文檔的評審工作。測試人員1. 參與需求評估，參與技術(shù)文檔評審。2. 制定測試計劃以及方案。3. 編寫測試案例等相關(guān)

5、測試文檔。4. 實施技術(shù)測試工作，包括但部限于集成測試、功能測試、業(yè)務(wù)流程測試、易用性測試及用戶體驗測試、兼容性測試、性能與壓力測試、穩(wěn)定性測試、安全測試等。5. 測試缺陷管理，測試缺陷處理跟進。6. 組織產(chǎn)品經(jīng)理等人員體驗預(yù)發(fā)布產(chǎn)品。7. 測試總結(jié)與相關(guān)業(yè)務(wù)知識文檔編寫與匯總。8. 負(fù)責(zé)生產(chǎn)問題的協(xié)調(diào)處理。生產(chǎn)運維人員1. 負(fù)責(zé)上線申請受理、組織上線需求評審。2. 負(fù)責(zé)生產(chǎn)版本備份、上線、回退。（預(yù)留項）（預(yù)留項）當(dāng)需求提交部門對需求評估小組的評估結(jié)果存在爭議時，由相關(guān)部門領(lǐng)導(dǎo)共同商議裁決。第3章 需求總體說明第5條 需求分類按需求的提交部門可以分為研發(fā)部內(nèi)部需求和業(yè)務(wù)部門需求。需求類型需求

6、類型定義研發(fā)部內(nèi)部需求研發(fā)部內(nèi)部提出的系統(tǒng)開發(fā)、性能優(yōu)化、軟件升級等需求。產(chǎn)品部門需求研發(fā)部以為的部門提交的系統(tǒng)開發(fā)需求，主要指產(chǎn)品部。按需求的內(nèi)容可分為功能開發(fā)需求、平臺網(wǎng)站類需求、數(shù)據(jù)需求。需求類型需求類型定義功能開發(fā)需求新業(yè)務(wù)功能已有系統(tǒng)中沒有此功能，需要在原有基礎(chǔ)上新增功能功能改進當(dāng)前系統(tǒng)已經(jīng)有此功能，因組織架構(gòu)、制度規(guī)范、業(yè)務(wù)處理流程等發(fā)生變化，需要對現(xiàn)有系統(tǒng)的某些功能進行優(yōu)化調(diào)整參數(shù)調(diào)整已有系統(tǒng)中已經(jīng)存在該參數(shù)，需研發(fā)部對參數(shù)內(nèi)容進行維護需求變更系統(tǒng)功能上線前，要在原有需求的基礎(chǔ)上增加、修改或刪除需求內(nèi)容，但需求內(nèi)容的變動會引起成本增長過大、對現(xiàn)有業(yè)務(wù)影響較大、或可能存在風(fēng)險、合規(guī)

7、等問題系統(tǒng)問題系統(tǒng)現(xiàn)有功能可以正常使用，但是性能、安全、底層處理邏輯和架構(gòu)等即將或者未來可能成為業(yè)務(wù)進一步擴張的瓶頸APP界面類需求1. 僅涉及APP前端頁面設(shè)計、開發(fā)、更新修改及維護，與其他系統(tǒng)沒有任何交互的需求。2. 涉及APP前端頁面設(shè)計、開發(fā)、更新修改及維護，且與其他系統(tǒng)有交互的需求。數(shù)據(jù)需求1. 面向客戶數(shù)據(jù)：是指運用于客戶、與客戶直接關(guān)聯(lián)的數(shù)據(jù)，包括向客戶發(fā)送短信、贈送積分、贈送權(quán)益禮品等后臺數(shù)據(jù)處理需求。2. 管理數(shù)據(jù)：用于管理分析，或活動效果監(jiān)控和效果評估的報表及明細(xì)數(shù)據(jù)。按需求的緊急程度可以分為緊急需求和普通需求。需求類型需求類型定義緊急需求需求提交人員事先確定上線時間，且按

8、常規(guī)資源分配和進度安排無法按時上線，必須通過領(lǐng)導(dǎo)特批增加資源，并對部分流程進行加急處理，才可滿足上線要求的需求。普通需求緊急需求以外的其他需求。按需求開發(fā)工時的大小可以分為大型需求、中型需求和小型需求。需求類型需求類型定義大型需求開發(fā)工時>200工時的需求。中型需求開發(fā)工時>100工時，<=200工時的需求。小型需求開發(fā)工時<=100工時的需求。第6條 需求開發(fā)管理流程圖需求開發(fā)管理流程為：（建議由項目管理員統(tǒng)一管理需求）需求管理主要包括以下內(nèi)容：需求的評估、開發(fā)、測試和上線階段的管理細(xì)則遵循本制度中相關(guān)規(guī)定。不涉及功能開發(fā)的平臺類需求和數(shù)據(jù)需求可根據(jù)實際情況對需求開發(fā)

9、管理過程的部分工作進行裁剪。各階段包含的活動及流程請見以下各章節(jié)中的詳細(xì)描述。第4章 需求提交第7條 需求提交為提高需求質(zhì)量和處理效率，減少需求變更的次數(shù)，研發(fā)部各小組（開發(fā)、UI、測試）與產(chǎn)品部門就需求內(nèi)容和實現(xiàn)方式等達成一致，可形成會議紀(jì)要存檔，并與需求申請表（或郵件的形式）同時提交需求審批。需求提交前需確認(rèn)的內(nèi)容包括：（一）與開發(fā)人員溝通，確定需求類型。（二）需求的可行性分析。各部門小組進行可行性分析時需關(guān)注的內(nèi)容為：1. 研發(fā)部對需求的技術(shù)可行性進行初步分析，并幫助需求提交人員識別關(guān)聯(lián)系統(tǒng)。2. 需求關(guān)聯(lián)系統(tǒng)的歸屬開發(fā)人員就需求是否符合業(yè)務(wù)發(fā)展規(guī)劃，以及需求對系統(tǒng)中已有業(yè)務(wù)功能的影響進

10、行評估。3. 產(chǎn)品部、開發(fā)人員、測試人員對需求的業(yè)務(wù)邏輯、風(fēng)險、合規(guī)等進行初步評估。第8條 需求會簽原則上中、大型項目或需求，需要通過會簽流程，征求各部門相關(guān)同事或領(lǐng)導(dǎo)審批，審批通過方可進入到后續(xù)開發(fā)流程。此條制度視公司具體情況需要，靈活運用。第5章 需求評估第9條 需求評估流程需求評估流程說明及職責(zé)分工：（一）需求調(diào)研，需求文檔完成開發(fā)后，產(chǎn)品經(jīng)理需將需求提交至項目管理人員統(tǒng)一管理，項目管理人員需要將需求文檔發(fā)送至研發(fā)部想干的各分部門會簽。會簽通過后組織需求評估會議。（二）項目管理員審核相關(guān)要素，包括：參與會簽審批的干系人是否齊全，各干系人是否審批通過。附：緊急需求另行處理（待完善，可劃分為

11、業(yè)務(wù)需求、緊急需求、生產(chǎn)QC等三種類型）（三）需求評估會上要評估的內(nèi)容包括：1. 確認(rèn)需求內(nèi)容，分析需求合理性：需求開發(fā)負(fù)責(zé)人從技術(shù)層面對需求的技術(shù)可行性、性能等進行初步評估；測試部及其他相關(guān)產(chǎn)品部門從業(yè)務(wù)角度，對需求的業(yè)務(wù)邏輯、業(yè)務(wù)流程、業(yè)務(wù)目的、風(fēng)險、合規(guī)等方面內(nèi)容進行評估。2. 初步確認(rèn)需求的實現(xiàn)方式。3. 初步評估需求的開發(fā)工作量。4. 明確需求系統(tǒng)設(shè)計、編碼、測試、上線階段的里程碑以及各階段的交付物和負(fù)責(zé)人。5. 確定需求評估結(jié)論。（四）需求評估完成后，填寫需求評估表（待設(shè)計表格），需填寫的內(nèi)容包括：1.不予開發(fā)或者有變更的事項；2.該需求對其他關(guān)聯(lián)系統(tǒng)的影響；3.需求所需人力、工時

12、、里程碑以及整體評估結(jié)論等。（五）評估表填寫完畢后，評估人員需當(dāng)場簽字確認(rèn)，項目管理員檢查需求評估表的信息是否填寫完整、準(zhǔn)確。第10條 需求評估考慮層面需求評估主要從技術(shù)角度和業(yè)務(wù)角度進行考慮。若需求評估通過，會后需求提交人員根據(jù)需求評估的結(jié)論更新需求，更新后的需求將作為研發(fā)部開發(fā)的最終依據(jù)（避免需求多次變更）。若出現(xiàn)下列情形之一的，評估組出具意見后可退回需求至產(chǎn)品部重新更新需求或需要征得各部門領(lǐng)導(dǎo)審批。（1） 技術(shù)層面1.需對系統(tǒng)結(jié)構(gòu)進行大規(guī)模改造的。2.涉及系統(tǒng)架構(gòu)變更的。3.與其他需求有重復(fù)的。4.需求中有不合理事項的。5.需求不明確需做補充的。6.當(dāng)前技術(shù)無法實現(xiàn)的。7.評估時發(fā)生重大

13、變更，且變更審批未通過的。（2） 業(yè)務(wù)層面1.與目前的業(yè)務(wù)操作流程、運營有矛盾的。2.需大規(guī)模的更改原有的業(yè)務(wù)流程,增加大量人工后續(xù)處理成本。3.業(yè)務(wù)需求與業(yè)務(wù)目的不符的。4.新需求引起的新業(yè)務(wù)流程未在需求內(nèi)一并體現(xiàn)的。5.業(yè)務(wù)流程未理順,業(yè)務(wù)規(guī)則未明確或者沒有體現(xiàn)，有可能導(dǎo)致上線后,無法正常進行業(yè)務(wù)運作，或者存在運營風(fēng)險的。因以上原因被退回的需求，需求提交部門如對需求評估小組的評估結(jié)果存在爭議，可提交各部門領(lǐng)導(dǎo)進行仲裁。第6章 需求開發(fā)第11條 需求開發(fā)流程（略，具體流程有開發(fā)部門制定）第12條 設(shè)計開發(fā)：需求評估通過后，由需求開發(fā)負(fù)責(zé)人安排、協(xié)調(diào)需求的設(shè)計和開發(fā)工作。（一）開發(fā)人員根據(jù)需求

14、評估會上通過的業(yè)務(wù)需求進行設(shè)計開發(fā)，同時完成需求技術(shù)文檔。（二）技術(shù)文檔通過需求開發(fā)負(fù)責(zé)人的審核后，開發(fā)人員提交項目管理人員。此技術(shù)文檔有必要從架構(gòu)、環(huán)境、安全、性能等層面對技術(shù)文檔進行評審，及時提出評審意見。（三）項目管理員審核相關(guān)要素，包括：技術(shù)文檔是否符合要求、評審人員參與度、是否評審?fù)ㄟ^。審核通過后需求進入開發(fā)階段。如審核不通過，項目管理員將技術(shù)文檔退回給開發(fā)人員，開發(fā)人員處理完畢后再提交相關(guān)干系人評審。（四）技術(shù)文檔評審?fù)ㄟ^后，開發(fā)人員將評審?fù)ㄟ^后的技術(shù)文檔更新到SVN中并開展開發(fā)工作。緊急需求必須通過需求評估后，才可開展設(shè)計開發(fā)工作。設(shè)計開發(fā)階段的部分工作在項目管理員審批通過后，可

15、根據(jù)實際情況進行裁剪。第13條 單元測試&集成測試（一）編碼完成后，開發(fā)人員需進行單元測試、系統(tǒng)集成、編譯部署、及主功能測試。測試通過后編寫單元測試報告、版本部署操作文檔，并提交需求開發(fā)負(fù)責(zé)人審核。（二）需求開發(fā)負(fù)責(zé)人審核通過后，開發(fā)人員將源代碼、單元測試報告、版本部署操作文檔更新到SVN，需求開發(fā)負(fù)責(zé)人將單元測試報告、版本部署操作文檔上傳到SVN。第7章 系統(tǒng)測試第14條 系統(tǒng)測試：單元測試（包含系統(tǒng)集成）通過后進入系統(tǒng)測試階段， 系統(tǒng)測試流程為：系統(tǒng)測試流程說明：（1） 需求開發(fā)負(fù)責(zé)人向項目管理員提交系統(tǒng)測試申請。（2） 項目管理員審核相關(guān)要素，包括：需求是否通過評估、技術(shù)文檔是否

16、通過評審、單元測試是否通過、需求技術(shù)文檔、單元測試報告及版本部署操作文檔是否上傳SVN。審核通過后項目管理員向研發(fā)部質(zhì)量管理部測試經(jīng)理下系統(tǒng)測試通知單。如審核不通過，返回開發(fā)子流程。（3） 測試經(jīng)理分配系統(tǒng)測試人員。（4） 系統(tǒng)測試人員驗證SVN中的技術(shù)文檔、版本部署及需求主功能。驗證通過后制定測試計劃，如驗證不通過，返回開發(fā)子流程。（5） 系統(tǒng)測試計劃、測試案例、測試報告由系統(tǒng)測試人員編寫并組織評審，系統(tǒng)測試主管和需求開發(fā)負(fù)責(zé)人必須參加評審。（6） 補充：測試計劃、測試方案、測試案例等測試文檔，設(shè)計時間參考第六條（需求開發(fā)管理流程圖）；測試工作遵循盡早參與的原則，遇特殊情況，測試文檔也可在測

17、試啟動時執(zhí)行。第8章 需求上線第15條 需求上線：測試驗收工作結(jié)束后，進入需求上線階段。需求上線主要分為業(yè)務(wù)上線、技術(shù)上線。第16條 需求上線流程需求上線流程說明：（一）需求上線申請 需求測試通過后，測試經(jīng)理檢查測試負(fù)責(zé)人提交的測試工件，審核通過后提交項目管理員協(xié)調(diào)開發(fā)安排上線時間。（二）上線實施后，需求相關(guān)人員需進行上線驗證： （三）若上線復(fù)核或驗證失敗，則開發(fā)人員將上線版本從生產(chǎn)環(huán)境中回退，需求轉(zhuǎn)入開發(fā)流程。第17條 試運行為了對系統(tǒng)的功能、性能、可靠性、穩(wěn)定性、需求涉及業(yè)務(wù)和系統(tǒng)的影響情況進行驗證，需求上線后，由研發(fā)部、產(chǎn)品部，以及其他領(lǐng)導(dǎo)共同商榷，根據(jù)項目實際情況實行產(chǎn)品試運行。試運行

18、的時間、方案、通過標(biāo)準(zhǔn)暫未制定。第9章 生產(chǎn)問題管理第18條 生產(chǎn)問題：指存在于生產(chǎn)系統(tǒng)中的異?，F(xiàn)象或缺陷，不包括辦公設(shè)備、網(wǎng)絡(luò)故障等非生產(chǎn)系統(tǒng)引起的故障。生產(chǎn)問題處理流程說明：（一）技術(shù)人員收到生產(chǎn)問題后，對問題根源進行深入分析，并對系統(tǒng)問題進行處理。如不屬于非系統(tǒng)問題，技術(shù)人員拒絕報障并說明原因，測試人員需整理歸檔。（二）生產(chǎn)問題修復(fù)完畢后部署到測試環(huán)境，提交測試流程。（三）技術(shù)人員提交測試申請，項目管理員審核通過后下測試通知單。（四）生產(chǎn)問題測試通過后，上線流程與需求上線流程一致。第10章 需求變更控制與管理第19條 需求變更：指研發(fā)部受理需求后，需增加、修改、刪除需求內(nèi)容，或?qū)⑿枨髵炱?/p>

19、、退回、取消的現(xiàn)象。需求變更控制與管理流程：需求變更控制與管理流程說明及職責(zé)分工：（一）需求變更申請人填寫需求變更申請表（待設(shè)計表格），詳細(xì)說明需求變更的類型、變更原因及變更內(nèi)容。（二）需求變更申請人通過郵件OA或其他部門間工作聯(lián)系函將需求變更申請?zhí)峤恍枨箝_發(fā)負(fù)責(zé)人、相關(guān)測試負(fù)責(zé)人及關(guān)聯(lián)系統(tǒng)負(fù)責(zé)人審批。審批通過后需求開發(fā)負(fù)責(zé)人判斷是否為重大變更。如審批不通過，評審組說明原因后將需求變更申請退回申請人。（三）需求變更屬于重大變更時，需求變更申請人組織需求變更評審會，由評審組成員共同確定是否允許變更。如果不屬于重大變更，需求開發(fā)負(fù)責(zé)人有權(quán)決定是否允許需求變更。滿足以下任一條件的需求變更都屬于重大變更。1.需求變更引起開發(fā)工時增加量：大型需求10%，中型需求15%，小型需求20%（僅刪除需求內(nèi)容的變更可不考慮）。2.需求變更導(dǎo)致里程碑