1.业务需求收集
产品经理收集用户提出的需求,并整理在册。以一段时间内为里程碑,如一周、半个月、一个月;
方式两种:1、用户主动提出 2、主动收集用户反馈;
此时可评估提出的需求合理性,不合理的可直接对用户解答并拒绝该需求。
需求描述 记录用户提出的需求详细内容 | 需求类型 需求变更/新增 | 提出时间 | 提出人 |
例:增加导出运单数据功能。 用户提供导出模版,详见附件《XXX.xlsx》 | 新增 | 2019-04-02 |
|
例: | 需求变更 | 2019-04-02 |
|
2.业务需求确定
根据收集到的业务需求表,召集与会人员进行需求会议,包括需求提出人、决策者、产品经理、需求影响到的用户,进行需求讨论。
讨论需求提出的合理性,否决掉不合理的需求,确认要开发的需求,以及待确定的需求。
对于确定开发的需求,进行需求补充或完善,列出需求开发设计的优先级。
需求描述 | 需求类型 需求变更/新增 | 提出时间 | 提出人 | 评审时间 | 需求评审结论 | 优先级 重要/紧急 |
例:页面,增加导出运单数据功能。 用户提供导出模版,详见附件《XXX.xlsx》 | 新增 | 2019-04-02 |
| 2019-04-02 | 否决 |
|
例:导出财务账单报表的表头变更 | 需求变更 | 2019-04-02 |
| 2019-04-02 | 待确定/待补充 | 紧急不重要 |
| 新增 | 2019-01-01 |
| 2019-04-02 | 确认且通过 | 重要紧急1 |
| 新增 | 2019-03-01 |
| 2019-04-02 | 确认且通过 | 重要紧急2 |
本次会议结束后,应将确认的需求与待确定的分开整理出来。待确定的需要进行再次讨论确定。
3.需求设计
进入需求设计阶段的需求都应该是“确认且通过”的需求,摘选出需求评审表中确认的需求。
按照需求优先级,制定需求设计进度计划表。
模块名称 | 序号 | 工作内容 | 输出 | 备注 | 计划进度 | 实际进度 | 负责人 | ||
开始日期 | 结束日期 | 开始日期 | 结束日期 |
| |||||
意大利代采业务 | 1 | 业务梳理 | 业务流程图、思维导图 |
|
|
|
|
|
|
2 | 业务梳理评审会 |
| 确保业务与产品理解无偏差 |
|
|
|
|
| |
3 | 需求文档 | 软件需求说明书、数据字典、原型图 |
|
|
|
|
|
| |
4 | 需求评审会 |
| 系统实现是否是业务想要的,技术人员是否清楚 |
|
|
|
|
|
该阶段应是一个封闭的设计阶段,如果此时有新的业务需求提出,应仅仅只记录下该业务需求,到下个设计阶段来讨论。
如果新的业务需求与当次设计有冲突或有关联的时,需要产品经理慎重衡量,是否加入到本次设计过程中,如果确定加入本次设计中,应告知决策人进行再次确定。
4.开发计划
根据产品经理设计的需求文档,提交到禅道管理系统,技术人员制定开发计划。
模块名称 | 序号 | 工作内容 | 输出 | 计划进度 | 实际进度 | 负责人 | ||
开始日期 | 结束日期 | 开始日期 | 结束日期 |
| ||||
意大利代采业务 | 1 | 数据库设计 | 数据表 |
|
|
|
|
|
2 | 功能点拆分 |
|
|
|
|
|
| |
3 | 功能开发 | 测试地址 |
|
|
|
|
| |
4 | 功能测试 | 测试地址 |
|
|
|
|
| |
5 | 产品经理验收 |
|
|
|
|
|
| |
6 | 生产环境部署 | 生产地址 |
|
|
|
|
| |
7 | 培训、试运行 | 用户培训手册 |
|
|
|
|
|