我在之前写了一篇管理｜产品迭代开发上线流程及产品发布确认单的文章，正如评论区有一位朋友回复说“感觉不实用”，确实。我们在后面实践过程中也发现了一些问题，最近和公司同事又沟通出一个版本，分享如下：
我们是通过邮件＋禅道来配合我们这个计划的执行，一次迭代计划从开始到结束都在这一个邮件中进行回复，迭代计划中的需求和BUG在禅道上记录和跟踪。
第一步：整理BUG
产品经理主导，［测试工程师］辅导，从BUG池里面整理出下周迭代计划需要处理的线上BUG清单。
输出：BUG清单
第二步：需求同步
［产品经理］整理完下周迭代计划需要处理的需求和［测试工程师］给出的BUG清单，发送邮件给相关的人（发送邮件的时间为周二下班前），并确定进行需求评审的时间（需求评审时间为周三下午） 。
输出：需求和BUG清单、需求评审时间
第三步：需求评审
完成需求评审。
输出：产品和研发确定可以完成的需求和BUG，并录入到禅道中
第四步：执行计划
［产品经理］编写需求prd文档及视觉稿设计，［测试工程师］编写测试用例，［项目经理］讨论开发计划。
输出1：［产品经理］邮件发送需求prd文档及视觉稿、［项目经理］回邮件确定研发计划（交付验收起止时间和发布验收时间，已和产品经理达成一致）和测试用例（已和产品经理达成一致）
输出2：［产品经理］把确定的需求录入到禅道，［测试工程师］把对应的测试用例录入到禅道
当然，这个研发计划可以不是一周的总时长。
第五步：进入研发
研发劳作中。
［项目经理］为了风险更加可控，在研发过程中需要建立一个个阶段性验收的时间点，这个是介于项目开始和交付验收开始之间的研发内部流程，当然为了方便［产品经理］跟踪进度，可以同步给［产品经理］。
阶段性验收需要提前和研发明确需要验哪些功能，以及验收的时间点，同时验收完之后［测试工程师］需要出一个《阶段性验收报告》，这份报告需要有一个状态明确记录是否合格。
目前制定的是通过率达到85%以上为合格，如果出现不合格时，有问题的功能需要在下次阶段性验收时处理掉，并且计入下次阶段性验收的通过率统计中。
研发需要在禅道上及时打卡，方便产品和测试及时跟踪，同时为了解决研发打卡难的问题，我们的所有任务都拆分成8小时之内，一个任务不得超过8小时。
第六步：交付验收
［测试工程师］在测试环境和预发布环境对本次迭代做完完整性测试之后需要交付给［产品经理］做交付验收。
每一个遗留问题研发需要出一个研发的处理方案，产品需要对遗留问题进行回复。
产品需要在迭代内容清单后面确定验收的结果。
输出：交付验收的《测试报告》。
第七步：发布验收
产品经理负责人、运营负责人、项目负责人在《产品发布确认单》中进行签字。
第八步：正式发布
研发拿到《产品发布确认单》才会进行发布，发布之后［产品经理］、［测试工程师］、［研发工程师］需要在线上做回归验收，对照冒烟测试用例和发布验收报告进行抽查。
最后要说的就是：很多规范都是通过一次次“不破不立”不断总结经验才制定出来的。并且没有最好，也没有更好，只有因地制宜、因时制宜的更合适。
欢迎大家一起交流。
同时也欢迎大家下载我们的产品进行体验。
