需求全流程管理.docx

1 背景

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

需求堆积，业务部门不满

开发团队疲于奔命

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

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

2 目标

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

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

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

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

流程

流程图

见文档尾部

说明

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

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

名词解释

业务需求

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

系统需求

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

注意事项

不可有例外

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

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

可裁剪

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

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

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

确保项目计划完整

——制定项目计划时，需考虑和包含完成项目需要的所有任务和资源，而不是仅考虑开发人员。如需要业务部门提前准备的材料，需要外部系统开发的接口等等都需要包含在项目计划中进行管理、跟踪。

本文档是从需求管理角度描述需求的全流程，项目管理方面更具体规范另文说明。

业务需求提报要求

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

业务需求文档

有效性说明（参见有效性标准）

预期效益说明（参见预期效益评估）

上线公告（功能上线时提示所有业务人员了解系统变化影响的通知内容）

是否紧急（需调整已有需求排期，保证最快上线的情况）

有效性标准

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

自相矛盾

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

环节逻辑一致、呼应

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

可行性：业务操作可行性；技术实现可行性

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

预期效益评估

提升：如访问量、重复购买率、客单价、毛利率、粘度、品牌形象等等

降低：如库存占用、跳出率、退货率等等量化指标：提升或降低的绝对数、比例

作用时效：可持续（长期），或特定时间周期（起止时间）

技术评估

技术可行性

系统开发工作量

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

需求提报人

1邮件沟

一需

求提出

需求提报人

在

需求管理员

需求有效

需求管理员

依次指

需求管理员

指派技

参见“业务需求提报要求”

产品经理

3系统需求

需求有效性评需求管理员

需求

产品经理

4指派SA

SA

5.1

SA

5.2设计、估算

二

需

求

实 产品经理

现 6.1方案与估算

产品经理

6.2项目排期

二

需

求 产品经理

实 7指派现

开发经理

8.1

开发经理

8.2计划执行

产品经理 测试负责人

9指派

产品经理

10指

需求提报人

产品经理

三

需

求 产品经理验 12指证

产品经理

13需