需求全流程管理

技术经营体需求全流程管理方案

1 背景

1 需求堆积，业务部门不满 2 开发团队疲于奔命

3 对需求缺乏有效的评估方法，难以保证所承接的需求合理，必要性

4 陷入赶工的恶性循环，承诺的时间无法兑现，损害专业性、权威性，难以建立信任

2 目标

1 保证重要业务需求被及时满足

2 系统化提升技术部工作效能，充分发挥技术团队价值

3 避免资源占用随意性，保证长期项目、核心产品的开发不受干扰

4 使用系统方式对需求进行管理，解决人工管理的随意、低效、混乱、难以追溯等问题

3 流程

3.1 流程图

见文档尾部

3.2 说明

本流程对应trac系统，流程中各个环节在系统中指派、留痕 需求管理员即需求提报入口，需保证人员唯一性

基本的需求文档管理和审核方式为在trac系统中上传文档或粘贴SVN文档地址链接，相关人员进行确认在系统中留存确认日志。对于重要项目需求管理员可要求上传的文档中包含人工签字版的扫描件

3.3 名词解释

业务需求

由最终用户或者领域专家从业务的角度提出的需求，无需技术知识。核心内容主要包括业务目标、业务流程、业务实体、业务规则、功能规则等。

系统需求

由系统分析师或者架构师从软件系统的角度，以实现业务需求为目标提出的需求，核心内容包括功能设计、界面设计、用例或功能点描述、非功能性需求说明等。

3.4 注意事项

不可有例外

——所有系统需求，无论大小都要纳入系统管理。任何一个表面看起来改动很小的需求，都有未知的水下部分，必须通过完整的流程、评估、分析才能确定其真正工作量和风险

——系统生命周期是连贯的，所做的任何功能变更必须被管理，任何一个功能逻辑需要有可追溯的需求，否则系统将快速走向混乱和未知，发生错误时也无法分析原因、判断来源。如果一次修改不改变任何需求，仅仅是对原需求错误实现的修正，则属于系统BUG，应该在另外的故障跟踪系统中管理。

可裁剪

——粗评开发工作量在1小时以内或整体上线工作量在4小时以内的，可以归类为“小修改”进行流程裁剪

——粗评开发工作量超过1小时的需求，应该按照完成的流程进行正式管理，确保按时交付，符合业务目标和需求。需要专人集中进行方案设计和工作量评估，工作量应该以小时为单位，保证

——粗评整体上线工作量超过1个人月的需求，应该作为长期项目，采用迭代开发方式，在PMS系统中单独创建产品和项目进行管理。每次迭代时间不超过一个月，每次迭代完成后进行总结，确定下一次迭代的目标和范围，直到整个项目目标完成。

确保项目计划完整 ——制定项目计划时，需考虑和包含完成项目需要的所有任务和资源，而不是仅考虑开发人员。如需要业务部门提前准备的材料，需要外部系统开发的接口等等都需要包含在项目计划中进行管理、跟踪。 本文档是从需求管理角度描述需求的全流程，项目管理方面更具体规范另文说明。

4 业务需求提报要求

提报业务需求，需包含以下基本内容： ? 业务需求文档

? 有效性说明（参见有效性标准） ? 预期效益说明（参见预期效益评估）

? 上线公告（功能上线时提示所有业务人员了解系统变化影响的通知内容） ? 是否紧急（需调整已有需求排期，保证最快上线的情况）

有效性标准

正确性：逻辑清晰、无歧义；符合已知的领域知识、业务规则和常识，没有自相矛盾

一致性：可能影响到的所有业务环节需要经过具体分析，明确修改方案；各环节逻辑一致、呼应

必要性：需求实现后能产生可预测、显著的商业回报；无可接受的替代方案 可行性：业务操作可行性；技术实现可行性

可验证：有明确具体的测试验证标准、验证数据

预期效益评估

提升：如访问量、重复购买率、客单价、毛利率、粘度、品牌形象等等 降低：如库存占用、跳出率、退货率等等 量化指标：提升或降低的绝对数、比例 作用时效：可持续（长期），或特定时间周期（起止时间）

技术评估

技术可行性

系统开发工作量

风险分析——风险点、风险预案、可能造成的损失

需求提报人 1邮件沟通、会议讨论 一需求提出2业务需求提报需求提报人参见“业务需求提报要求”2.1在trac系统提报需求需求管理员2.2需求有效性评估、效益评估需求管理员2.3依次指派相关部门审核需求管理员2.4指派技术团队技术初评产品经理3系统需求分析确定SA、开发负责人、测试负责人需求有效性评需求管理员2.5需求受理指派PM执行技术可行性风险分析工作量初评产品经理4指派SA进行设计和估算SA5.1需求审核SA二需求实现5.2设计、估算任务分解、方案设计、工作量估算产品经理6.1方案与估算审核产品经理

6.2项目排期二需求实现组建项目组，制定时间计划产品经理7指派开发负责人进行开发开发经理8.1项目排期计划审核开发经理8.2计划执行分工、协调、跟踪纠偏、汇报产品经理测试负责人在测试环境中发布系统，对照业务需求和系统需求测试9指派测试负责人进行测试产品经理需求提报人对照业务需求验收（预发布环境）10指派需求提报人进行验收产品经理关键业务三需求验证11安排观察性上线（针对关键业务）或功能产品经理12指派运维人员上线产品经理13需求效果跟踪14项目执行总结讨论15需求评估总结

本文来源：https://www.bwwdw.com/article/lpxa.html