产品迭代执行细节及思考
2020-06-30 本文已影响0人
深蓝And鸣峰
现在的研发模式基本都是采用敏捷的模式，即spint 迭代，为了让整个研发迭代推行的更顺畅，在国内具体执行时，又可以拆分为：产品设计迭代、研发迭代和测试迭代；
主流采用的是2周为1个迭代，产品设计迭代先行，早于研发1个迭代，研发迭代早于测试1个迭代。
关于产品设计迭代怎么推行，都有那些关键环节，这些关键环节的输入和输出是什么，这些问题一直是在产品迭代中比较容易出错和困扰的地方，之前也有零散的总结，现在又再次拾起来进行1次整理。
我把产品设计迭代整理成21个环节，针对每个环节定义出对应的输入、输出及要求，同时辅助规范和监督来完成整个过程；
利用的工具如下： wiki、jira
| 序号 | 主要环节 | 主要工作内容 | 工作依据及和要求 | 对应规范 | 监督 |
|---|---|---|---|---|---|
| 1 | jira系统接收需求，自动更新状态（需求池） | 1、确认当前提出的是否是需求以及是否要接收（jira需求管理系统的确认和未通过两个动作）； 2、与业务方确认需求优先级 | （1）每个月底向产线收集下个月需求； （2）每个月分两次来处理提出的需求，基于产品迭代的开启时间来安排，产品迭代开启前提的需求，优先级被我们确认在P1、P0的纳入当前产品迭代； （3）产品迭代开启之后，提出的被确认为P0的则需要评审是否纳入当前产品迭代（评审依据：产品迭代开启后，每个产线有1条P0级紧急需求可以插入当前产品迭代）； （4）产品迭代开启之后提出的P1~P3类的需求纳入下个产品迭代。 | 需求管理规范 | jira需求列表 |
| 2 | 更新jira需求管理系统中需求的状态（产品设计） | 1、及时更新纳入产品迭代计划上的需求状态 | （1）状态：由需求池更新为产品设计 （2）纳入产品迭代的需求，需要同时更新jira需求管理系统里需求的状态； （3）该操作可以在填写产品迭代计划时来操作； （4）未能按时进入产品设计的增加日志说明利用jira@功能通知报告人 | 产品迭代执行规范 | wiki产品迭代计划（贴上对应的jira需求链接） |
| 3 | 制定产品迭代计划 | 1、基于业务方提的需求和自驱的需求来制定产品迭代计划； | 1、产品迭代计划要包含与业务方确认后的P0~P1的需求； 2、要包含客户问题处理、自驱、研发效率工具类的P0~P1类需求。 | 产品迭代执行规范 | wiki产品迭代计划 |
| 4 | 产品迭代产品设计 | 1、基于产品迭代上的需求进行产品功能原型设计 2、与核心研发确认当前方案的可行性 | 1、符合产品、技能等老数据兼容原则； 2、符合产品功能交互设计基本原则 3、符合产品的易用性原则 | 产品设计常见规范和原则 | 产品功能设计院原则及规范 |
| 5 | 产品迭代第一次产品评审 | 1、基于产品设计的产出物，产品原型进行评审 | 1、评审涉及范围、老数据兼容、易用性、交互、合理性进行评估 | 产品迭代评审规范 | 产品评审会议纪要 录入wiki页面 |
| 6 | 产品迭代业务方需求评审 | 1、基于产品功能变化会影响到当前业务，则需要和每个业务进行确认 2、范围为自驱需求、某个业务方的需求，如果涉及其他业务方则需要所有产线进行确认 | 1、同步产品设计到业务方产品接口人群（钉钉群，由潘飞组建）； 2、线下完成当前业务影响的确认和评审。 | 业务方产品需求确认 | 产品评审会议纪要 录入wiki页面，发给产线确认群 |
| 7 | 撰写产品需求文档（研发需求文档格式规范） | 1、产品原型完成评审后更新详细规则和逻辑录入产品需求文档 | 1、基于工具和规范把产品需求文档更新到wiki上 | wiki产品需求文档规范 | wiki记录 |
| 8 | 更新jira需求管理系统中需求的状态（待排期） | 等待产品迭代评审通过后，则需求状态进行更新 | 1、状态：由产品设计更新为待排期。 2、未能按时进入排期的增加日志说明利用jira@功能通知报告人 | 需求管理规范 | jira需求列表 |
| 9 | 制定研发迭代计划 | 1、基于产品迭代完成结果制定研发计划 2、与研发确认研发计划 | 1、确保产品迭代P0~P1的需求进入研发迭代； 2、如果有冲突时，把自驱类需求降级。 | 需求管理规范 | wiki研发迭代计划 |
| 10 | 研发迭代需求讲解 | 1、基于研发迭代需求平射结果来完成与研发进行研发迭代计划的确认 | 1、基于当前研发迭代人力的预估完成研发迭代计划的确认 | 研发迭代规范 | 研发迭代计划会议记录 |
| 11 | 更新jira需求管理系统中需求的状态（开发中）和研发确认时间（完成时间，来自项目经理） | 1、把列入研发迭代计划的需求更新状态，由待排期改为开发中； 2、针对产品迭代完成设计，未能列入研发迭代的需求，不更新状态，增加说明：告知当前未列入计划的原因 | 1、增加原因说明 并抄送需求提出人使用jira系统的@功能 | 需求管理规范 | jira需求详情 |
| 12 | 跟进研发迭代开发进度 | 1、研发迭代中主动跟进需求开发进度，进行开发环境的验收 | 1、了解负责需求的开发进度和难点，确保进度的有效性 | 产品迭代规范 | 例会 |
| 13 | 进行迭代验收脚本准备 | 1、基于产品功能的使用场景准备验收的操作脚本 | 1、基于产品使用的正常状态流转、异常状态流转以及当前需求重要部分的验证 | 产品迭代规范 | 验收脚本wiki记录 |
| 14 | 验收迭代开发的产品功能 | 1、产品回顾会议进行迭代功能验收 | 1、按照脚本进行验收 | 迭代回顾会议 | wiki记录 |
| 15 | 更新jira需求管理系统中需求的状态（测试中） | 1、基于验收结果来更新jira需求管理系统中需求的状态 | 1、需求状态由开发中改为测试中 2、未能进入测试的增加日志说明，利用jira@功能通知报告人 | 需求管理规范 | jira需求列表 |
| 16 | 准备上线Releas Note | 1、基于研发计划中需求的测试情况来完成所需上线内容的整理 | 1、基于Releas Note填写规范完成上线计划内容的制定 | Releas Note填写规范 | wiki记录 |
| 17 | 准备上线 Check List | 完成需要上线功能的Check List的整理 | 1、基于Check List规范来完成上线需求的检查内容整理 | Check list规范 | wiki记录 |
| 18 | 准备产品功能的教程及FAQ | 1、基于产品功能整理该部分的教程和FAQ | 按照对外发布的标准完成教程和FAQ整理，确保基于教程和FAQ能解决当前遇到的问题 | 文档和FAQ规范 | 文档和FAQ更新到平台 |
| 19 | 线上环境功能验收 | 1、基于Check List来进行线上环境功能的检查 | 1、基于Check List来进行线上环境功能的检查 | CHeck list规范 | 检查结果同步在上线钉钉群中 |
| 20 | 更新jira需求管理系统中需求的状态（已完成） | 1、基于上线结果更新jira需求管理系统中需求状态 | 1、已经完成更新写 需求状态更新为已完成； 2、未能按时上线的增加日志说明，利用jira@功能通知报告人 | 需求管理规范 | jira需求列表 |
| 21 | 收集功能的优化意见，准备下个迭代计划。 | 1、针对问题部分收集确认需求纳入需求池 | 1、关注功能上线后的运行情况； 2、针对问题部分收集确认需求纳入需求池 | 需求管理规范 | 产品迭代计划 |
