需求管理制度

零壹移動互聯(lián)需求治理制度〔版，2023 年〕擬制人擬制人肖波日期審核人批準(zhǔn)人日期日期修改記錄作者作者/修日期版本描述審核人改者肖波修改需求開發(fā)治理流程與相關(guān)人員分工名目!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽!未定義書簽第一條為標(biāo)準(zhǔn)零壹移動互聯(lián)〔以下簡稱“零壹”〕需求治理，明確各階段的工作內(nèi)容、處理流程、參與第三條本制度適用的讀者包括需求開發(fā)負(fù)責(zé)人、需求提交人員、需求評估人員、開發(fā)人員、測試人員、生產(chǎn)運維人員、工程治理員等。角色 職責(zé)需求提交人員工程治理人員

負(fù)責(zé)需求調(diào)研與編輯、編寫業(yè)務(wù)需求申請表、提交業(yè)務(wù)需求審批。依據(jù)需求評審和評估意見，準(zhǔn)時修改業(yè)務(wù)需求，并發(fā)給需求相關(guān)干系人。協(xié)作需求開發(fā)、測試人員供給業(yè)務(wù)學(xué)問的支持。幫助確認(rèn)需求開發(fā)結(jié)果。負(fù)責(zé)需求上線后驗證工作。負(fù)責(zé)需求審批、評估、技術(shù)文檔評審、測試、上線等需求治理流程的整體協(xié)調(diào)工作。組織需求評估會議。處理測試申請 提交測試部門進(jìn)展安排與測試。需求進(jìn)展。參與需求評審，從技術(shù)角度對需求實現(xiàn)方式、風(fēng)險等進(jìn)展評估。制定需求開發(fā)打算，安排需求開發(fā)人員。需求開發(fā)負(fù)責(zé)人 3.負(fù)責(zé)需求全部工作的溝通、協(xié)調(diào)治理。負(fù)責(zé)需求開發(fā)進(jìn)度、成員、變更治理。負(fù)責(zé)或參與需求全部成果的審批。從架構(gòu)、業(yè)務(wù)、技術(shù)、風(fēng)險等方面對業(yè)務(wù)需求的內(nèi)容和實現(xiàn)方式進(jìn)行全面評估，需求評估人員 并提出評估意見。審核依據(jù)評估意見修改后的業(yè)務(wù)需求。開發(fā)人員需求測試負(fù)責(zé)人

需求評估人員包括開發(fā)部門、測試部門、產(chǎn)品部門以及其他參與具體需求工作的人員。幫助需求提交人員分析、確定業(yè)務(wù)需求。編寫需求相關(guān)技術(shù)文檔。組織實施軟件需求、系統(tǒng)設(shè)計等文檔評審，參與測試打算、測試案例、測試報告文檔的評審工作。負(fù)責(zé)需求的設(shè)計、開發(fā)，確保代碼符合編碼標(biāo)準(zhǔn)和代碼安全標(biāo)準(zhǔn)。負(fù)責(zé)系統(tǒng)集成、編譯部署及單元測試。提交測試申請，必要時供給技術(shù)支持，協(xié)作需求測試人員完成測試環(huán)境的搭建。協(xié)作需求測試人員處理環(huán)境問題，解決測試缺陷。負(fù)責(zé)提交上線申請，參與上線評審，協(xié)作上線部署，負(fù)責(zé)上線問題的查詢和解決、上線復(fù)核。參與需求評審，從業(yè)務(wù)測試角度參與對需求實現(xiàn)方式、風(fēng)險等進(jìn)展評估。安排需求測試人員，對需求測試過程治理，負(fù)責(zé)需求全部工作的溝通、協(xié)調(diào)治理。制定/參與需求評估，參與技術(shù)文檔評審。制定測試打算以及方案。編寫測試案例等相關(guān)測試文檔。實施技術(shù)測試工作，包括但部限于集成測試、功能測試、業(yè)務(wù)流程測試、易用性測試人員 測試及用戶體驗測試、兼容性測試、性能與壓力測試、穩(wěn)定性測試、安全測試等。測試缺陷治理，測試缺陷處理跟進(jìn)。組織產(chǎn)品經(jīng)理等人員體驗預(yù)公布產(chǎn)品。測試總結(jié)與相關(guān)業(yè)務(wù)學(xué)問文檔編寫與匯總。負(fù)責(zé)生產(chǎn)問題的協(xié)調(diào)處理。負(fù)責(zé)上線申請受理、組織上線需求評審。生產(chǎn)運維人員〔預(yù)留項〕

負(fù)責(zé)生產(chǎn)版本備份、上線、回退?！差A(yù)留項〕當(dāng)需求提交部門對需求評估小組的評估結(jié)果存在爭議時，由相關(guān)部門領(lǐng)導(dǎo)共同協(xié)商裁決。需求類型需求類型需求類型定義研發(fā)部內(nèi)部需求產(chǎn)品部門需求研發(fā)部內(nèi)部提出的系統(tǒng)開發(fā)、性能優(yōu)化、軟件升級等需求。研發(fā)部以為的部門提交的系統(tǒng)開發(fā)需求，主要指產(chǎn)品部。需求類型需求類型定義需求類型需求類型定義業(yè)務(wù)功能已有系統(tǒng)中沒有此功能，需要在原有根底上增功能當(dāng)前系統(tǒng)已經(jīng)有此功能，因組織架構(gòu)、制度標(biāo)準(zhǔn)、業(yè)務(wù)處理流程等發(fā)生功能改進(jìn)變化，需要對現(xiàn)有系統(tǒng)的某些功能進(jìn)展優(yōu)化調(diào)整功能開發(fā)需求參數(shù)調(diào)整已有系統(tǒng)中已經(jīng)存在該參數(shù)，需研發(fā)部對參數(shù)內(nèi)容進(jìn)展維護(hù)需求變更系統(tǒng)功能上線前，要在原有需求的根底上增加、修改或刪除需求內(nèi)容，但需求內(nèi)容的變動會引起本錢增長過大、對現(xiàn)有業(yè)務(wù)影響較大、或可能存在風(fēng)險、合規(guī)等問題系統(tǒng)現(xiàn)有功能可以正常使用，但是性能、安全、底層處理規(guī)律和架構(gòu)等系統(tǒng)問題馬上或者將來可能成為業(yè)務(wù)進(jìn)一步擴(kuò)張的瓶頸APP界面類需求僅涉及APP前端頁面設(shè)計、開發(fā)、更修改及維護(hù)，與其他系統(tǒng)沒有任何交互的需求。涉及APP前端頁面設(shè)計、開發(fā)、更修改及維護(hù)，且與其他系統(tǒng)有交互的需求。數(shù)據(jù)需求面對客戶數(shù)據(jù)：是指運用于客戶、與客戶直接關(guān)聯(lián)的數(shù)據(jù)，包括向客戶發(fā)送短信、贈送積分、贈送權(quán)益禮品等后臺數(shù)據(jù)處理需求。治理數(shù)據(jù)：用于治理分析，或活動效果監(jiān)控和效果評估的報表及明細(xì)數(shù)據(jù)。需求類型需求類型定義需求類型需求類型定義緊急需求一般需求需求提交人員事先確定上線時間，且按常規(guī)資源安排和進(jìn)度安排無法按時上線，必需通過領(lǐng)導(dǎo)特批增加資源，并對局部流程進(jìn)展加急處理，才可滿足上線要求的需求。緊急需求以外的其他需求。需求類型需求類型定義需求類型需求類型定義大型需求中型需求小型需求開發(fā)工時>200工時的需求。>100<=200工時的需求。<=100工時的需求。需求開發(fā)治理流程為：〔建議由工程治理員統(tǒng)一治理需求〕需求的評估、開發(fā)、測試和上線階段的治理細(xì)則遵循本制度中相關(guān)規(guī)定。不涉及功能開發(fā)的平臺類需求和數(shù)據(jù)需求可依據(jù)實際狀況對需求開發(fā)治理過程的局部工作進(jìn)展裁剪。各階段包含的活動及流程請見以下各章節(jié)中的具體描述?！查_發(fā)、UI、測試〕與產(chǎn)品部門就需求內(nèi)容和實現(xiàn)方式等達(dá)成全都，可形成會議紀(jì)要存檔，并與《需求申請表》〔或郵件的形式〕同時提交需求審批。需求提交前需確認(rèn)的內(nèi)容包括：〔一〕與開發(fā)人員溝通，確定需求類型?！捕逞邪l(fā)部對需求的技術(shù)可行性進(jìn)展初步分析，并幫助需求提交人員識別關(guān)聯(lián)系統(tǒng)。需求關(guān)聯(lián)系統(tǒng)的歸屬開發(fā)人員就需求是否符合業(yè)務(wù)進(jìn)展規(guī)劃，以及需求對系統(tǒng)中已有業(yè)務(wù)功能的影響進(jìn)展評估。產(chǎn)品部、開發(fā)人員、測試人員對需求的業(yè)務(wù)規(guī)律、風(fēng)險、合規(guī)等進(jìn)展初步評估。批通過方可進(jìn)入到后續(xù)開發(fā)流程。此條制度視公司具體狀況需要，敏捷運用。需求評估流程說明及職責(zé)分工：〔一〕需求調(diào)研，需求文檔完成開發(fā)后，產(chǎn)品經(jīng)理需將需求提交至工程治理人員統(tǒng)一治理，工程治理人員需要將需求文檔發(fā)送至研發(fā)部想干的各分部門會簽。會簽通過后組織需求評估會議?！捕彻こ讨卫韱T審核相關(guān)要素，包括：參與會簽審批的干系人是否齊全，各干系人是否審批通過。附：緊急需求另行處理〔待完善，可劃分為業(yè)務(wù)需求、緊急需求、生產(chǎn)附：緊急需求另行處理〔待完善，可劃分為業(yè)務(wù)需求、緊急需求、生產(chǎn)QC等三種類型〕〔三〕需求評估會上要評估的內(nèi)容包括：確認(rèn)需求內(nèi)容，分析需求合理性：需求開發(fā)負(fù)責(zé)人從技術(shù)層面對需求的技術(shù)可行性、性能等進(jìn)展初步評估；測試部及其他相關(guān)產(chǎn)品部門從業(yè)務(wù)角度，對需求的業(yè)務(wù)規(guī)律、業(yè)務(wù)流程、業(yè)務(wù)目的、風(fēng)險、合規(guī)等方面內(nèi)容進(jìn)展評估。初步確認(rèn)需求的實現(xiàn)方式。初步評估需求的開發(fā)工作量。明確需求系統(tǒng)設(shè)計、編碼、測試、上線階段的里程碑以及各階段的交付物和負(fù)責(zé)人。確定需求評估結(jié)論?！菜摹场泊O(shè)計表格〕不予開發(fā)或者有變更的事項；該需求對其他關(guān)聯(lián)系統(tǒng)的影響；需求所需人力、工時、里程碑以及整體評估結(jié)論等?！参濉吃u估表填寫完畢后，評估人員需當(dāng)場簽字確認(rèn)，工程治理員檢查需求評估表的信息是否填寫完整、準(zhǔn)確。需求評估主要從技術(shù)角度和業(yè)務(wù)角度進(jìn)展考慮。假設(shè)需求評估通過，會后需求提交人員依據(jù)需求評估的結(jié)論更需求，更后的需求將作為研發(fā)部開發(fā)的最終依據(jù)〔避開需求屢次變更〕假設(shè)消滅以下情形之一的，評估組出具意見后可退回需求至產(chǎn)品部重更需求或需要征得各部門領(lǐng)導(dǎo)審批?！惨弧臣夹g(shù)層面需對系統(tǒng)構(gòu)造進(jìn)展大規(guī)模改造的。涉及系統(tǒng)架構(gòu)變更的。與其他需求有重復(fù)的。需求中有不合理事項的。需求不明確需做補(bǔ)充的。當(dāng)前技術(shù)無法實現(xiàn)的。評估時發(fā)生重大變更，且變更審批未通過的?！捕硺I(yè)務(wù)層面與目前的業(yè)務(wù)操作流程、運營有沖突的。,增加大量人工后續(xù)處理本錢。業(yè)務(wù)需求與業(yè)務(wù)目的不符的。需求引起的業(yè)務(wù)流程未在需求內(nèi)一并表達(dá)的。業(yè)務(wù)流程未理順,業(yè)務(wù)規(guī)章未明確或者沒有表達(dá)，有可能導(dǎo)致上線后 ,無法正常進(jìn)展業(yè)務(wù)運作，或者存在運營風(fēng)險的。因以上緣由被退回的需求，需求提交部門如對需求評估小組的評估結(jié)果存在爭議，可提交各部門領(lǐng)導(dǎo)進(jìn)展仲裁?！猜?，具體流程有開發(fā)部門制定〕第十二條設(shè)計開發(fā)：需求評估通過后，由需求開發(fā)負(fù)責(zé)人安排、協(xié)調(diào)需求的設(shè)計和開發(fā)工作。〔一〕開發(fā)人員依據(jù)需求評估會上通過的業(yè)務(wù)需求進(jìn)展設(shè)計開發(fā)， 同時完成《需求技術(shù)文檔》〔二〕技術(shù)文檔通過需求開發(fā)負(fù)責(zé)人的審核后，開發(fā)人員提交工程治理人員。此技術(shù)文檔有必要從架構(gòu)、環(huán)境、安全、性能等層面對技術(shù)文檔進(jìn)展評審，準(zhǔn)時提出評審意見。〔三〕工程治理員審核相關(guān)要素，包括：技術(shù)文檔是否符合要求、評審人員參與度、是否評審?fù)ㄟ^。審核通關(guān)干系人評審?！菜摹臣夹g(shù)文檔評審?fù)ㄟ^后，開發(fā)人員將評審?fù)ㄟ^后的技術(shù)文檔更到

SVN中并開開放發(fā)工作。緊急需求必需通過需求評估后，才可開展設(shè)計開發(fā)工作。設(shè)計開發(fā)階段的局部工作在工程管理員審批通過后，可依據(jù)實際狀況進(jìn)展裁剪。第十三條單元測試&集成測試〔一〕編碼完成后，開發(fā)人員需進(jìn)展單元測試、系統(tǒng)集成、編譯部署、及主功能測試。測試通過后編寫《單元測試報告》、版本部署操作文檔，并提交需求開發(fā)負(fù)責(zé)人審核。〔二〕SVN，需求開發(fā)負(fù)責(zé)人將《單元測試報告》、版本部署操作文檔上傳到SVN。第十四條系統(tǒng)測試：單元測試〔包含系統(tǒng)集成〕通過后進(jìn)入系統(tǒng)測試階段，系統(tǒng)測試流程為：系統(tǒng)測試流程說明：〔一〕需求開發(fā)負(fù)責(zé)人向工程治理員提交系統(tǒng)測試申請。〔二工程治理員審核相關(guān)要素包括需求是否通過評估技術(shù)文檔是否通過評審單元測試是否通過、《需求技術(shù)文檔》、《單元測試報告》及版本部署操作文檔是否上傳 SVN。審核通過后工程治理員向研發(fā)部質(zhì)量治理部測試經(jīng)理下系統(tǒng)測試通知單。如審核不通過，返回開發(fā)子流程?！踩硿y試經(jīng)理安排系統(tǒng)測試人員?！菜摹诚到y(tǒng)測試人員驗證SVN不通過，返回開發(fā)子流程?！参濉诚到y(tǒng)測試打算、測試案例、測試報告由系統(tǒng)測試人員編寫并組織評審，系統(tǒng)測試主管和需求開發(fā)負(fù)責(zé)人必需參與評審?！擦逞a(bǔ)充：測試打算、測試方案、測試案例等測試文檔，設(shè)計時間參考第六條〔需求開發(fā)治理流程圖〕；測試工作遵循盡早參與的原則，遇特別狀況，測試文檔也可在測試啟動時執(zhí)行。第十五條需求上線：測試驗收工作完畢后，進(jìn)入需求上線階段。需求上線主要分為業(yè)務(wù)上線、技術(shù)上線。需求上線流程說明：〔一〕需求上線申請需求測試通過后，測試經(jīng)理檢查測試負(fù)責(zé)人提交的測試工件，審核通過后提交工程治理〔二〕上線實施后，需求相關(guān)人員需進(jìn)展上線驗證：〔三〕假設(shè)上線復(fù)核或驗證失敗，則開發(fā)人員將上線版本從生產(chǎn)環(huán)境中回退，需求轉(zhuǎn)入開發(fā)流程。證，需求上線后，由研發(fā)部、產(chǎn)品部，以及其他領(lǐng)導(dǎo)共同商榷，依據(jù)工程實際狀況實行產(chǎn)品試運行。試運行的時間、方案、通過標(biāo)準(zhǔn)暫未制定。第十八條生產(chǎn)問題：指存在于生產(chǎn)系統(tǒng)中的特別現(xiàn)象或缺陷，不包括辦公設(shè)備、網(wǎng)絡(luò)故障等非生產(chǎn)系統(tǒng)引起的故障。生產(chǎn)問題處理流程說明：〔一〕技術(shù)人員收到生產(chǎn)問題后，對問題根源進(jìn)展深入分析，并對系統(tǒng)問題進(jìn)展處〔二〕生產(chǎn)問題修復(fù)完畢后部署到測試環(huán)境，提交測試流程?！踩臣夹g(shù)人員提交測試申請，工程治理員審核通過后下測試通知單。四〕生產(chǎn)問題測試通過后，上線流程與需求上線流程全都。第十九條需求變更：指研發(fā)部受理需求后，需增加、修改、刪除需求內(nèi)容，或?qū)⑿枨髵炱?、退回、取消的現(xiàn)象。需求變更掌握與治理流程：需求變更掌握與治理流程說明及職責(zé)分工：〔一〕需求變更申請人填寫《需求變更申請表》〔待設(shè)計表格〕，具體說明需求變更的類型、變更緣由及變更內(nèi)容?！捕承枨笞兏暾埲送ㄟ^郵件或其他部門間工作聯(lián)系函將需求變更申請?zhí)峤恍枨箝_發(fā)負(fù)責(zé)人、相關(guān)測試負(fù)責(zé)人及關(guān)聯(lián)系統(tǒng)負(fù)責(zé)人審批。審批通過后需求開發(fā)負(fù)責(zé)人推斷是否為重大變更。如審批不通過，評審組說明緣由后將需求變更申請退回申請人?！踩承枨笞兏鼘儆谥卮笞兏鼤r，需求變更申請人組織需求變更評審會，由評審組成員共同確定是否允許變更。假設(shè)不屬于重大變更，需求開發(fā)負(fù)責(zé)人有權(quán)打算是否允許需求變更。滿足以下任一條件的需求變更都屬于重大變更。需求變更引起開發(fā)工時增加量：大型需求≥ 10%，中型需求≥15%，小型需求≥20%〔僅刪除需求內(nèi)容的變更可不考慮〕需求變更導(dǎo)致里程碑點推遲的。需求變更涉及關(guān)聯(lián)系統(tǒng)變化的。需求變更可能存在風(fēng)險、合規(guī)問題的。需求變更涉及或影響已有業(yè)務(wù)流程、規(guī)章、后臺運營的。測試人員、關(guān)聯(lián)系統(tǒng)負(fù)責(zé)人、關(guān)聯(lián)產(chǎn)品部門。如不屬于重大變更，可裁剪此活動。評審的內(nèi)容包括：技術(shù)可行性分析。需求合理性、業(yè)務(wù)方案可行性分析。關(guān)聯(lián)系統(tǒng)影響分析。變更風(fēng)險分析。對需求工作量、工期、本錢等的影響分析。評審結(jié)論：〔1〕〔待設(shè)計表格〕評審不通過：在《需求變更申請單》中填寫拒