需求管理制度V0

1、零壹移动互联需求治理制度2.0版,2021年拟制人肖波日期20210630审核人日期批准人日期修改记录日期版本作者/修改者描述审核人20210701V2.0肖波修改需求开发治理流程与相关人员 分工目录第一章总那么3第二章责任与分工3第三章需求总体说明4第四章需求提交7第五章需求评估7第六章需求开发10第七章系统测试11第八章需求上线13第九章生产问题治理14第十章需求变更限制与治理14第十一章需求进度监控及查询17第十二章附那么17第一章总那么第一条 为标准零壹移动互联以下简称“零壹需求治理,明确各阶段的工作内容、处理流程、参与人员以及相关干系人的责任,在保证需求质量的同时,提升需求实现效率,

2、特制 订本制度.第二条本制度适用于研发部的所有系统开发需求.第三条 本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、工程治理员等.第二章责任与分工第四条责任分工角色责任需求提交人员1 .负责需求调研与编辑、编写业务需求申请表、提交业务需求审批.2 .根据需求评审和评估意见,及时修改业务需求,开发给需求相关干 系人.3 .配合需求开发、测试人员提供业务知识的支持.4 .协助确认需求开发结果.5 . 负责需求上线后验证工作.工程治理人员1 .负责需求审批、评估、技术文档评审、测试、上线等需求治理流程 的整体协调工作.2 .组织需求评估会议.3 .处

3、理测试申请-提交测试部门进行分配与测试.4 .维护需求信息、跟进需求变更以及需求处理进展,定期向相关领导、部门汇报需求进展.需求开发负责人1 .参与需求评审,从技术角度对需求实现方式、风险等进行评估.2 .制定需求开发方案,分配需求开发人员.3 .负责需求所有工作的沟通、协调治理.4 .负责需求开发进度、成员、变更治理.5 .负责或参与需求所有成果的审批.需求评估人员1 .从架构、业务、技术、风险等方面对业务需求的内容和实现方式进 行全面评估,并提出评估意见.2 .审核根据评估意见修改后的业务需求.3.需求评估人员包括开发部门、测试部门、产品部门以及其他参与具 体需求工作的人员.开发人员1 .

4、帮助需求提交人员分析、确定业务需求.2 .编写需求相关技术文档.3 .组织实施软件需求、系统设计等文档评审,参与测试方案、测试案 例、测试报告文档的评审工作.4 .负责需求的设计、开发,保证代码符合编码标准和代码平安标准.5 .负责系统集成、编译部署及单元测试.6 .提交测试申请,必要时提供技术支持,配合需求测试人员完成测试 环境的搭建.7 .配合需求测试人员处理环境问题,解决测试缺陷.8 .负责提交上线申请,参加上线评审,配合上线部署,负责上线问题 的查询和解决、上线复核.需求测试负责人1 .参与需求评审,从业务测试角度参与对需求实现方式、风险等进行 评估.2 .分配需求测试人员,对需求测试

5、过程治理,负责需求所有工作的沟 通、协调治理.3 .制定/参与制定测试方案,参与测试案例、测试报告文档的评审工 作.测试人员1 .参与需求评估,参与技术文档评审.2 .制定测试方案以及方案.3 .编写测试案例等相关测试文档.4 .实施技术测试工作,包括但部限于集成测试、功能测试、业务流程 测试、易用性测试及用户体验测试、兼容性测试、性能与压力测试、 稳定性测试、平安测试等.5 .测试缺陷治理,测试缺陷处理跟进.6 .组织产品经理等人员体验预发布产品.7 .测试总结与相关业务知识文档编写与汇总.8 .负责生产问题的协调处理.生产运维人员1 . 负责上线申请受理、组织上线需求评审.2 .负责生产版

6、本备份、上线、回退.预留项预留项当需求提交部门对需求评估小组的评估结果存在争议时,由相关部门领导共同商议裁决.第三章需求总体说明第五条需求分类按需求的提交部门可以分为研发部内部需求和业务部门需求.需求类型需求类型定义研发部内部需求研发部内部提出的系统开发、性能优化、软件升级等需求.产品部门需求研发部以为的部门提交的系统开发需求,主要指产品部.按需求的内容可分为功能开发需求、平台网站类需求、数据需求.需求类型需求类型定义功能开发需求新业务功能已有系统中没有此功能,需要在原有根底上新增功能功能改良当前系统已经有此功能,因组织架构、制度标准、业务处理流程等发生 变化,需要对现有系统的某些功能进行优化

7、调整参数调整已有系统中已经存在该参数,需研发部对参数内容进行维护需求变更系统功能上线前,要在原有需求的根底上增加、修改或删除需求内容, 但需求内容的变动会引起本钱增长过大、对现有业务影响较大、或可能 存在风险、合规等问题系统问题系统现有功能可以正常使用,但是性能、平安、底层处理逻辑和架构等 即将或者未来可能成为业务进一步扩张的瓶颈AP的面类需求1 .仅涉及APP前端页面设计、开发、更新修改及维护,与其他系统没 有任何交互的需求.2 .涉及APP前端页面设计、开发、更新修改及维护,且与其他系统有 交互的需求.数据需求1 .面向客户数据：是指运用于客户、与客户直接关联的数据,包括向 客户发送短信、

8、赠送积分、赠送权益礼品等后台数据处理需求.2 .治理数据：用于治理分析,或活动效果监控和效果评估的报表及明 细数据.按需求的紧急程度可以分为紧急需求和普通需求.需求类型需求类型定义紧急需求需求提交人员事先确定上线时间,且按常规资源分配和进度安排无法按时上线,必须通过领导特批增加资源,并对局部流程进行加急处理,才 可满足上线要求的需求.普通需求紧急需求以外的其他需求.按需求开发工时的大小可以分为大型需求、中型需求和小型需求.需求类型需求类型定义大型需求开发工时200工时的需求.中型需求开发工时100工时,=200工时的需求.小型需求开发工时=100工时的需求.第六条需求开发治理流程图需求分析价段

9、需求订划阶段设il开发阶段山坝H值理14堆等在呷13.150l|2hilllli I那Ihli ifllllh i林I一线阶段田求国新,编L?需求文料?年华北目管砰员埴写产局常求评估1：表.相关开发.蒿:区贝贞儿隹孑*：进人反C原日计理员如也需求评书会以,评曲需求实瑁方式、拿坎恭度.风卷存亦争说褥分十条人导'审:m需求菱型处理.更“山工h：需求定必星可乾怡在仃 帮沟通衽步后期需求费里麴费史内容.需 末町泻嗟晚犍5t以屋开发,测试酎闻sr 端写需求技木聊美工检明确荐阶段完成时T 闽康交付有1刈国前汉,臼刈!率达支配.讨论山说X对能与湖试希户期状案例般计期泌 审£非件反便,可:7

10、涮式商力i上前询】堆几洲试.臂写甲匕恻试罹占我打那么式编写OUiAlftM?开常箱出*胎第k帏I 要通过相大入房中核, 后由期H瞥理西统- ftftA：涮斌耳境近调上城复核上拷沆程可用凯军陈情比荷/相小血瞬1黑忖相片河蟹对测试输出的谛血需求开发治理流程为：建议由工程治理员统一治理需求需求治理主要包括以下内容:需求的评估、开发、测试和上线阶段的治理细那么遵循本制度中相关规定.不涉及功能开发的平台类需求和数据需求可根据实际情况对需求开发治理过程的局部工作进行裁剪.各阶段包含的活动及流程请见以下各章节中的详细描述.第四章需求提交第七条需求提交为提升需求质量和处理效率,减少需求变更的次数,研发部各小组

11、开发、UI、测试与产品部门就需求内容和实现方式等达成一致,可形成会议纪要存档,并与?需求申请表?或邮件的形式同时提交需求审批.需求提交前需确认的内容包括：一与开发人员沟通,确定需求类型.二需求的可行性分析.各部门小组进行可行性分析时需关注的内容为：1,研发部对需求的技术可行性进行初步分析,并帮助需求提交人员识别关联系统.2 .需求关联系统的归属开发人员就需求是否符合业务开展规划,以及需求对系统中已有业 务功能的影响进行评估.3 .产品部、开发人员、测试人员对需求的业务逻辑、风险、合规等进行初步评估. 第八条需求会签原那么上中、大型工程或需求,需要通过会签流程,征求各部门相关同事或领导审批,审批

12、通过方可进入到后续开发流程.此条制度视公司具体情况需要,灵活运用.第五章需求评估第九条需求评估流程需求评估流程说明及责任分工：一需求调研,需求文档完成开发后,产品经理需将需求提交至工程治理人员统一治理,工程治理人员需要将需求文档发送至研发部想干的各分部门会签.会签通过后组织需求评估会议.二工程治理员审核相关要素,包括：参与会签审批的干系人是否齐全,各干系人是否审批通过.附：紧急需求另行处理待完善,可划分为业务需求、紧急需求、生产QC等三种类型三需求评估会上要评估的内容包括：1 .确认需求内容,分析需求合理性：需求开发负责人从技术层面对需求的技术可行性、性 能等进行初步评估；测试部及其他相关产品

13、部门从业务角度,对需求的业务逻辑、业务流程、业 务目的、风险、合规等方面内容进行评估.2 .初步确认需求的实现方式.3 .初步评估需求的开发工作量.4 .明确需求系统设计、编码、测试、上线阶段的里程碑以及各阶段的交付物和负责人.5 .确定需求评估结论.四需求评估完成后,填写?需求评估表?待设计表格,需填写的内容包括：1 .不予开发或者有变更的事项；2 .该需求对其他关联系统的影响；3 .需求所需人力、工时、里程碑以及整体评估结论等.五评估表填写完毕后,评估人员需当场签字确认,工程治理员检查需求评估表的信息是 否填写完整、准确.第十条需求评估考虑层面需求评估主要从技术角度和业务角度进行考虑.假设

14、需求评估通过,会后需求提交人员根据需求评估的结论更新需求,更新后的需求将作为研 发部开发的最终依据防止需求屡次变更.假设出现以下情形之一的,评估组出具意见后可退回需求至产品部重新更新需求或需要征得各 部门领导审批.一技术层面1 .需对系统结构进行大规模改造的.2 .涉及系统架构变更的.3 .与其他需求有重复的.4 .需求中有不合理事项的.5 .需求不明确需做补充的.6 .当前技术无法实现的.7 .评估时发生重大变更,且变更审批未通过的.二业务层面1 .与目前的业务操作流程、运营有矛盾的.2 .需大规模的更改原有的业务流程,增加大量人工后续处理本钱.3 .业务需求与业务目的不符的.4 .新需求引

15、起的新业务流程未在需求内一并表达的.5 .业务流程未理顺,业务规那么未明确或者没有表达,有可能导致上线后,无法正常进行业务运作,或者存在运营风险的.因以上原因被退回的需求,需求提交部门如对需求评估小组的评估结果存在争议,可提交各部门领导进行仲裁.第六章需求开发第十一条需求开发流程略,具体流程有开发部门制定第十二条 设计开发：需求评估通过后,由需求开发负责人安排、协调需求的设计和开发工作.一开发人员根据需求评估会上通过的业务需求进行设计开发,同时完成?需求技术文档?c二技术文档通过需求开发负责人的审核后,开发人员提交工程治理人员.此技术文档有必要从架构、环境、平安、性能等层面对技术文档进行评审,

16、及时提出评审意见.三工程治理员审核相关要素,包括：技术文档是否符合要求、评审人员参与度、是否评审通过.审核通过后需求进入开发阶段.如审核不通过,工程治理员将技术文档退回给开发人员,开发人员处理完毕后再提交相关干系人评审.四技术文档评审通过后,开发人员将评审通过后的技术文档更新到SVN中并开展开发工作.紧急需求必须通过需求评估后,才可开展设计开发工作.设计开发阶段的局部工作在工程管理员审批通过后,可根据实际情况进行裁剪.第十三条单元测试8集成测试一编码完成后,开发人员需进行单元测试、系统集成、编译部署、及主功能测试.测试通过后编写?单元测试报告?、版本部署操作文档,并提交需求开发负责人审核.二需

17、求开发负责人审核通过后,开发人员将源代码、?单元测试报告?、版本部署操作文档更新到SVN需求开发负责人将?单元测试报告?、版本部署操作文档上传到 SVN第七章系统测试第十四条 系统测试：单元测试包含系统集成通过后进入系统测试阶段,系统测试流程为：产总经理11淤死京巾1K1 U.认米；r需求开发他识人项II治理心输III测试经理测试人诂:i叫II映不林Ml卜巾导加产中商捏结耳推七池it十濡助皿雨区续.节 先败彳人事件可返HJF发 了雌程* 愧4*片后国疵M字注注版本EK判 h-K前试口通系统测试流程说明:学如次申仄励:浅虺行通过：分配试人M M'根岭tf忐丽而 能楣口就式:长,此不加雷：

18、拗试想小忖1口.一 ,巾 I 1 r.l.通过口 J飞廉府号情况,遍HTT 町M松杓k幅代玛、#认相关,档一需求开发负责人向工程治理员提交系统测试申请.二工程治理员审核相关要素,包括：需求是否通过评估、技术文档是否通过评审、单元测试是否通过、?需求技术文档?、?单元测试报告?及版本部署操作文档是否上传SVN审核通过后工程治理员向研发部质量治理部测试经理下系统测试通知单.如审核不通过,返回开发子流程.三测试经理分配系统测试人员.四系统测试人员验证 SVN中的技术文档、版本部署及需求主功能.验证通过后制定测试 方案,如验证不通过,返回开发子流程.五系统测试方案、测试案例、测试报告由系统测试人员编写

19、并组织评审,系统测试主管 和需求开发负责人必须参加评审.六补充：测试方案、测试方案、测试案例等测试文档,设计时间参考第六条需求开发 治理流程图；测试工作遵循尽早参与的原那么,遇特殊情况,测试文档也可在测试启动时执行.第八章需求上线第十五条 需求上线：测试验收工作结束后,进入需求上线阶段.需求上线主要分为业务上线、技术上线.第十六条需求上线流程需求上线流程说明：一需求上线申请需求测试通过后,测试经理检查测试负责人提交的测试工件,审核通过后提交工程治理员协调开发安排上线时间.二上线实施后,需求相关人员需进行上线验证：三假设上线复核或验证失败,那么开发人员将上线版本从生产环境中回退,需求转入开发流程

20、.第十七条试运行为了对系统的功能、性能、可靠性、稳定性、需求涉及业务和系统的影响情况进行验证,需 求上线后,由研发部、产品部,以及其他领导共同商榷,根据工程实际情况实行产品试运行.试 运行的时间、方案、通过标准暂未制定.第九章生产问题治理第十八条 生产问题：指存在于生产系统中的异常现象或缺陷,不包括办公设备、网络故 障等非生产系统引起的故障.生产问题处理流程说明：一技术人员收到生产问题后,对问题根源进行深入分析,并对系统问题进行处理.如不 属于非系统问题,技术人员拒绝报障并说明原因,测试人员需整理归档.二生产问题修复完毕后部署到测试环境,提交测试流程.三技术人员提交测试申请,工程治理员审核通过

21、后下测试通知单.四生产问题测试通过后,上线流程与需求上线流程一致.第十章需求变更限制与治理第十九条 需求变更：指研发部受理需求后,需增加、修改、删除需求内容,或将需求挂 起、退回、取消的现象.需求变更限制与治理流程：需求变更限制与治理流程说明及责任分工：一需求变更申请人填写?需求变更申请表?待设计表格,详细说明需求变更的类型、变更原因及变更内容.二需求变更申请人通过邮件或其他部门间工作联系函将需求变更申请提交需求开发负责人、相关测试负责人及关联系统负责人审批.审批通过后需求开发负责人判断是否为重大变 更.如审批不通过,评审组说明原因后将需求变更申请退回申请人.三需求变更属于重大变更时,需求变更申请人组织需求变更评审会,由评审组成员共同 确定是否允许变更.如果不属于重大变更,需求开发负责人有权决定是否允许需求变更.满足以下任一条件的需求变更都属于重大变更.1