需求管理制度

零壹移動互聯(lián)需求管理制度（版，2015年）擬制人肖波日期審核人日期批準人日期修改記錄日期版本作者/修改者描述審核人肖波修改需求開發(fā)管理流程與相關(guān)人員分工

目錄第一章總則 3第二章職責與分工 3第三章需求總體說明 4第四章需求提交 7第五章需求評估 7第六章需求開發(fā) 10第七章系統(tǒng)測試 11第八章需求上線 13第九章生產(chǎn)問題管理 14第十章需求變更控制與管理 14第十一章需求進度監(jiān)控及查詢 17第十二章附則 17總則為規(guī)范零壹移動互聯(lián)（以下簡稱“零壹”）需求管理，明確各階段的工作內(nèi)容、處理流程、參與人員以及相關(guān)干系人的職責，在保證需求質(zhì)量的同時，提高需求實現(xiàn)效率，特制訂本制度。本制度適用于研發(fā)部的所有系統(tǒng)開發(fā)需求。本制度適用的讀者包括需求開發(fā)負責人、需求提交人員、需求評估人員、開發(fā)人員、測試人員、生產(chǎn)運維人員、項目管理員等。職責與分工職責分工角色職責需求提交人員負責需求調(diào)研與編輯、編寫業(yè)務(wù)需求申請表、提交業(yè)務(wù)需求審批。根據(jù)需求評審和評估意見，及時修改業(yè)務(wù)需求，并發(fā)給需求相關(guān)干系人。配合需求開發(fā)、測試人員提供業(yè)務(wù)知識的支持。協(xié)助確認需求開發(fā)結(jié)果。負責需求上線后驗證工作。項目管理人員負責需求審批、評估、技術(shù)文檔評審、測試、上線等需求管理流程的整體協(xié)調(diào)工作。組織需求評估會議。處理測試申請?zhí)峤粶y試部門進行分配與測試。維護需求信息、跟進需求變更以及需求處理進展，定期向相關(guān)領(lǐng)導(dǎo)、部門匯報需求進展。需求開發(fā)負責人參與需求評審，從技術(shù)角度對需求實現(xiàn)方式、風險等進行評估。制定需求開發(fā)計劃，分配需求開發(fā)人員。負責需求所有工作的溝通、協(xié)調(diào)管理。負責需求開發(fā)進度、成員、變更管理。負責或參與需求所有成果的審批。需求評估人員從架構(gòu)、業(yè)務(wù)、技術(shù)、風險等方面對業(yè)務(wù)需求的內(nèi)容和實現(xiàn)方式進行全面評估，并提出評估意見。審核根據(jù)評估意見修改后的業(yè)務(wù)需求。需求評估人員包括開發(fā)部門、測試部門、產(chǎn)品部門以及其他參與具體需求工作的人員。開發(fā)人員幫助需求提交人員分析、確定業(yè)務(wù)需求。編寫需求相關(guān)技術(shù)文檔。組織實施軟件需求、系統(tǒng)設(shè)計等文檔評審，參與測試計劃、測試案例、測試報告文檔的評審工作。負責需求的設(shè)計、開發(fā)，確保代碼符合編碼規(guī)范和代碼安全規(guī)范。負責系統(tǒng)集成、編譯部署及單元測試。提交測試申請，必要時提供技術(shù)支持，配合需求測試人員完成測試環(huán)境的搭建。配合需求測試人員處理環(huán)境問題，解決測試缺陷。負責提交上線申請，參加上線評審，配合上線部署，負責上線問題的查詢和解決、上線復(fù)核。需求測試負責人參與需求評審，從業(yè)務(wù)測試角度參與對需求實現(xiàn)方式、風險等進行評估。分配需求測試人員，對需求測試過程管理，負責需求所有工作的溝通、協(xié)調(diào)管理。制定/參與制定測試計劃，參與測試案例、測試報告文檔的評審工作。測試人員1.參與需求評估，參與技術(shù)文檔評審。2.制定測試計劃以及方案。3.編寫測試案例等相關(guān)測試文檔。4.實施技術(shù)測試工作，包括但部限于集成測試、功能測試、業(yè)務(wù)流程測試、易用性測試及用戶體驗測試、兼容性測試、性能與壓力測試、穩(wěn)定性測試、安全測試等。5.測試缺陷管理，測試缺陷處理跟進。6.組織產(chǎn)品經(jīng)理等人員體驗預(yù)發(fā)布產(chǎn)品。7.測試總結(jié)與相關(guān)業(yè)務(wù)知識文檔編寫與匯總。8.負責生產(chǎn)問題的協(xié)調(diào)處理。生產(chǎn)運維人員負責上線申請受理、組織上線需求評審。負責生產(chǎn)版本備份、上線、回退。（預(yù)留項）（預(yù)留項）當需求提交部門對需求評估小組的評估結(jié)果存在爭議時，由相關(guān)部門領(lǐng)導(dǎo)共同商議裁決。需求總體說明需求分類按需求的提交部門可以分為研發(fā)部內(nèi)部需求和業(yè)務(wù)部門需求。需求類型需求類型定義研發(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ǔ)上新增功能功能改進當前系統(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ù)影響較大、或可能存在風險、合規(guī)等問題系統(tǒng)問題系統(tǒng)現(xiàn)有功能可以正常使用，但是性能、安全、底層處理邏輯和架構(gòu)等即將或者未來可能成為業(yè)務(wù)進一步擴張的瓶頸APP界面類需求僅涉及APP前端頁面設(shè)計、開發(fā)、更新修改及維護，與其他系統(tǒng)沒有任何交互的需求。涉及APP前端頁面設(shè)計、開發(fā)、更新修改及維護，且與其他系統(tǒng)有交互的需求。數(shù)據(jù)需求面向客戶數(shù)據(jù)：是指運用于客戶、與客戶直接關(guān)聯(lián)的數(shù)據(jù)，包括向客戶發(fā)送短信、贈送積分、贈送權(quán)益禮品等后臺數(shù)據(jù)處理需求。管理數(shù)據(jù)：用于管理分析，或活動效果監(jiān)控和效果評估的報表及明細數(shù)據(jù)。按需求的緊急程度可以分為緊急需求和普通需求。需求類型需求類型定義緊急需求需求提交人員事先確定上線時間，且按常規(guī)資源分配和進度安排無法按時上線，必須通過領(lǐng)導(dǎo)特批增加資源，并對部分流程進行加急處理，才可滿足上線要求的需求。普通需求緊急需求以外的其他需求。按需求開發(fā)工時的大小可以分為大型需求、中型需求和小型需求。需求類型需求類型定義大型需求開發(fā)工時>200工時的需求。中型需求開發(fā)工時>100工時，<=200工時的需求。小型需求開發(fā)工時<=100工時的需求。需求開發(fā)管理流程圖需求開發(fā)管理流程為：（建議由項目管理員統(tǒng)一管理需求）需求管理主要包括以下內(nèi)容：需求的評估、開發(fā)、測試和上線階段的管理細則遵循本制度中相關(guān)規(guī)定。不涉及功能開發(fā)的平臺類需求和數(shù)據(jù)需求可根據(jù)實際情況對需求開發(fā)管理過程的部分工作進行裁剪。各階段包含的活動及流程請見以下各章節(jié)中的詳細描述。需求提交需求提交為提高需求質(zhì)量和處理效率，減少需求變更的次數(shù)，研發(fā)部各小組（開發(fā)、UI、測試）與產(chǎn)品部門就需求內(nèi)容和實現(xiàn)方式等達成一致，可形成會議紀要存檔，并與《需求申請表》（或郵件的形式）同時提交需求審批。需求提交前需確認的內(nèi)容包括：（一）與開發(fā)人員溝通，確定需求類型。（二）需求的可行性分析。各部門\小組進行可行性分析時需關(guān)注的內(nèi)容為：研發(fā)部對需求的技術(shù)可行性進行初步分析，并幫助需求提交人員識別關(guān)聯(lián)系統(tǒng)。需求關(guān)聯(lián)系統(tǒng)的歸屬開發(fā)人員就需求是否符合業(yè)務(wù)發(fā)展規(guī)劃，以及需求對系統(tǒng)中已有業(yè)務(wù)功能的影響進行評估。產(chǎn)品部、開發(fā)人員、測試人員對需求的業(yè)務(wù)邏輯、風險、合規(guī)等進行初步評估。需求會簽原則上中、大型項目或需求，需要通過會簽流程，征求各部門相關(guān)同事或領(lǐng)導(dǎo)審批，審批通過方可進入到后續(xù)開發(fā)流程。此條制度視公司具體情況需要，靈活運用。需求評估需求評估流程需求評估流程說明及職責分工：（一）需求調(diào)研，需求文檔完成開發(fā)后，產(chǎn)品經(jīng)理需將需求提交至項目管理人員統(tǒng)一管理，項目管理人員需要將需求文檔發(fā)送至研發(fā)部想干的各分部門會簽。會簽通過后組織需求評估會議。（二）項目管理員審核相關(guān)要素，包括：參與會簽審批的干系人是否齊全，各干系人是否審批通過。附：緊急需求另行處理（待完善，可劃分為業(yè)務(wù)需求、緊急需求、生產(chǎn)QC等三種類型）（三）需求評估會上要評估的內(nèi)容包括：確認需求內(nèi)容，分析需求合理性：需求開發(fā)負責人從技術(shù)層面對需求的技術(shù)可行性、性能等進行初步評估；測試部及其他相關(guān)產(chǎn)品部門從業(yè)務(wù)角度，對需求的業(yè)務(wù)邏輯、業(yè)務(wù)流程、業(yè)務(wù)目的、風險、合規(guī)等方面內(nèi)容進行評估。初步確認需求的實現(xiàn)方式。初步評估需求的開發(fā)工作量。明確需求系統(tǒng)設(shè)計、編碼、測試、上線階段的里程碑以及各階段的交付物和負責人。確定需求評估結(jié)論。（四）需求評估完成后，填寫《需求評估表》（待設(shè)計表格），需填寫的內(nèi)容包括：1.不予開發(fā)或者有變更的事項；2.該需求對其他關(guān)聯(lián)系統(tǒng)的影響；3.需求所需人力、工時、里程碑以及整體評估結(jié)論等。（五）評估表填寫完畢后，評估人員需當場簽字確認，項目管理員檢查需求評估表的信息是否填寫完整、準確。需求評估考慮層面需求評估主要從技術(shù)角度和業(yè)務(wù)角度進行考慮。若需求評估通過，會后需求提交人員根據(jù)需求評估的結(jié)論更新需求，更新后的需求將作為研發(fā)部開發(fā)的最終依據(jù)（避免需求多次變更）。若出現(xiàn)下列情形之一的，評估組出具意見后可退回需求至產(chǎn)品部重新更新需求或需要征得各部門領(lǐng)導(dǎo)審批。技術(shù)層面1.需對系統(tǒng)結(jié)構(gòu)進行大規(guī)模改造的。2.涉及系統(tǒng)架構(gòu)變更的。3.與其他需求有重復(fù)的。4.需求中有不合理事項的。5.需求不明確需做補充的。6.當前技術(shù)無法實現(xiàn)的。7.評估時發(fā)生重大變更，且變更審批未通過的。業(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ù)運作，或者存在運營風險的。因以上原因被退回的需求，需求提交部門如對需求評估小組的評估結(jié)果存在爭議，可提交各部門領(lǐng)導(dǎo)進行仲裁。需求開發(fā)需求開發(fā)流程 （略，具體流程有開發(fā)部門制定）設(shè)計開發(fā)：需求評估通過后，由需求開發(fā)負責人安排、協(xié)調(diào)需求的設(shè)計和開發(fā)工作。（一）開發(fā)人員根據(jù)需求評估會上通過的業(yè)務(wù)需求進行設(shè)計開發(fā)，同時完成《需求技術(shù)文檔》。（二）技術(shù)文檔通過需求開發(fā)負責人的審核后，開發(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ā)階段的部分工作在項目管理員審批通過后，可根據(jù)實際情況進行裁剪。單元測試&集成測試（一）編碼完成后，開發(fā)人員需進行單元測試、系統(tǒng)集成、編譯部署、及主功能測試。測試通過后編寫《單元測試報告》、版本部署操作文檔，并提交需求開發(fā)負責人審核。（二）需求開發(fā)負責人審核通過后，開發(fā)人員將源代碼、《單元測試報告》、版本部署操作文檔更新到SVN，需求開發(fā)負責人將《單元測試報告》、版本部署操作文檔上傳到SVN。系統(tǒng)測試系統(tǒng)測試：單元測試（包含系統(tǒng)集成）通過后進入系統(tǒng)測試階段，系統(tǒng)測試流程為：系統(tǒng)測試流程說明：需求開發(fā)負責人向項目管理員提交系統(tǒng)測試申請。項目管理員審核相關(guān)要素，包括：需求是否通過評估、技術(shù)文檔是否通過評審、單元測試是否通過、《需求技術(shù)文檔》、《單元測試報告》及版本部署操作文檔是否上傳SVN。審核通過后項目管理員向研發(fā)部質(zhì)量管理部測試經(jīng)理下系統(tǒng)測試通知單。如審核不通過，返回開發(fā)子流程。測試經(jīng)理分配系統(tǒng)測試人員。系統(tǒng)測試人員驗證SVN中的技術(shù)文檔、版本部署及需求主功能。驗證通過后制定測試計劃，如驗證不通過，返回開發(fā)子流程。系統(tǒng)測試計劃、測試案例、測試報告由系統(tǒng)測試人員編寫并組織評審，系統(tǒng)測試主管和需求開發(fā)負責人必須參加評審。補充：測試計劃、測試方案、測試案例等測試文檔，設(shè)計時間參考第六條（需求開發(fā)管理流程圖）；測試工作遵循盡早參與的原則，遇特殊情況，測試文檔也可在測試啟動時執(zhí)行。需求上線需求上線：測試驗收工作結(jié)束后，進入需求上線階段。需求上線主要分為業(yè)務(wù)上線、技術(shù)上線。需求上線流程需求上線流程說明：（一）需求上線申請需求測試通過后，測試經(jīng)理檢查測試負責人提交的測試工件，審核通過后提交項目管理員協(xié)調(diào)開發(fā)安排上線時間。（二）上線實施后，需求相關(guān)人員需進行上線驗證：（三）若上線復(fù)核或驗證失敗，則開發(fā)人員將上線版本從生產(chǎn)環(huán)境中回退，需求轉(zhuǎn)入開發(fā)流程。試運行為了對系統(tǒng)的功能、性能、可靠性、穩(wěn)定性、需求涉及業(yè)務(wù)和系統(tǒng)的影響情況進行驗證，需求上線后，由研發(fā)部、產(chǎn)品部，以及其他領(lǐng)導(dǎo)共同商榷，根據(jù)項目實際情況實行產(chǎn)品試運行。試運行的時間、方案、通過標準暫未制定。生產(chǎn)問題管理生產(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)問題測試通過后，上線流程與需求上線流程一致。需求變更控制與管理需求變更：指研發(fā)部受理需求后，需增加、修改、刪除需求內(nèi)容，或?qū)⑿枨髵炱?、退回、取消的現(xiàn)象。需求變更控制與管理流程：需求變更控制與管理流程說明及職責分工：（一）需求變更申請人填寫《需求變更申請表》（待設(shè)計表格），詳細說明需求變更的類型、變更原因及變更內(nèi)容。（二）需求變更申請人通過郵件\OA\或其他部門間工作聯(lián)系函將需求變更申請?zhí)峤恍枨箝_發(fā)負責人、相關(guān)測試負責人及關(guān)聯(lián)系統(tǒng)負責人審批。審批通過后需求開發(fā)負責人判斷是否為重大變更。如審批不通過，評審組說明原因后將需求變更申請退回申請人。（三）需求變更屬于重大變更時，需求變更申請人組織需求變更評審會，由評審組成員共同確定是否允許變更。如果不屬于重大變更，需求開發(fā)負責人有權(quán)決定是否允許需求變更。滿足以下任一條件的需求變更都屬于重大變更。1.需求變更引起開發(fā)工時增加量：大型需求≥10%，中型需求≥15%，小型需求≥20%（僅刪除需求內(nèi)容的變更可不考慮）。2.需求變