目的：为了控制开发节奏，并且及时获得反馈。迭代时间一般不进行固定周期，根据实际需要来定，但为了稳步推进特将以下规范整理如下：
常规迭代
时间周期与重要节点
分为：前期准备阶段、kick-off需求评审阶段（包含运营kick-off 以及开发kick-off时间）、研发阶段、测试阶段、产品发布 。整个周期大致为3周 共17个工作日。
迭代周期中第一周：产品准备阶段并完成需求评审
迭代周期中第2周和第三周为研发开发阶段和测试验收阶段。
迭代周期图
节点：期间运营将需求在迭代周期的第三周前（即为最后一周前）反馈到产品，由产品进行消化整理，并最终确认。
与运营kick-off时间为版本上一期迭代周期的（第二周）进行kick-off
与开发kick-off时间为本期迭代周期（第一周前3天）进行kick-off
开发加内部测试时间共2周（12个工作日）。
关于需求分类：
运营需求在tapd中分为3类：活动需求、优化和新需求、客户反馈需求
需求记录规范：
活动需求：即为运营想要举办某个活动产生的需求，都将记录在活动需求。
记录中需要包含以下内容：
活动时间
活动详情
需要提供的支持
想要达到的效果
优化和新需求：即为对产品使用中发现可以调整后让用户体验变得更好的需求，都将记录在优化需求中。以及所需要的新功能都在优化需求中进行记录。
管理后台的使用都可以记录在【优化和新需求】分类中，记录时区分 管理后台和用户后台。
记录规范一：
现在的实现方式：
造成的问题：
想要实现的方式：
原因是（如果有数据，可以直接粘图）：
解决的问题：
记录规范二：
1. 这个需求要解决什么问题:
2. 用户操作的前置条件或场景是什么：
3. 用户的操作是什么(描述下需要的功能或是使用流程):
4. 还需要什么补充规则:
客户反馈需求：运营人员在客户维护过程中收集到的需求，都将记录在客户反馈需求中
客户反馈需求记录规范：
1. 客户反馈的原句或截图
2. 相关产品或功能
3. 客户反馈途径
4. 是否需要产品回访(如建议回访，请包含客户的联系⽅式)
处理优先级 与 流转机制
产品处理优先处理顺序为客户反馈需求->活动需求->优化和新需求
需求流转机制：
1、新->规划中（产品规划该需求）->实现中（开发正在实现该需求）->已实现（开发已经实现该需求）->测试中（产品和运营测试验收该需求）->已发布（线上正式环境已完成）
2、新->已关闭（该需求将不予实现，并注明关闭原因）
3、新->规划中->已拒绝（技术认为无法实现或实现代价过高）
Bug如何记录与处理机制
记录位置：tapd中缺陷
bug记录规范：
1. 缺陷位置:
页⾯链接
相关账号、⽤户名、业务编号(如订单流⽔水号、财务流⽔水号)
关键操作步骤(截图)
2. 预期结果
3. 实际情况
Bug处理流程和反馈机制
1.暂不处理->给出暂不处理的原因【产品】
2. 延缓处理->给出缺失的资源或需要的处理条件【产品】
3. 即时处理->产品将tapd指定给处理⼈【相应处理⼈员】
4.处理完成后，指向相应的创建人和产品
5.创建人进行验证，确认bug已处理将状态更改为【已验证】
注意：无法复现的bug，将直接进行关闭。【产品】
bug响应时间：一个工作日内给出反馈
bug修复时间：研发评估后及时给出修复的结束时间，一般bug修复时间尽量在3日内完成
时间无法预估的bug修复需要注明原因。
关于重要需求临时讨论处理机制
重要需求讨论将提前三天将信息共享给所有干系人，并在第2天组织讨论。
关于大版本的迭代周期与需求对接流程：
大版本迭代周期为7周
具体分为3周准备阶段、期间产品需要完成（需求确定、概念设计、范围层确定、完成与运营的讨论确定）
研发kick-off 开发阶段 测试阶段 发布上线
沟通与管理
目的：项目所有干系人做到对整个项目有最清晰的了解和认知统一化。
遇到需求变更以及研发实现过程中出现问题时影响到开发进度，需及时进行邮件告知所有干系人【产品、技术】
与研发kick-off结束后，时间周期需要以邮件的形式告知所有干系人【产品】
运营遇到紧急需求需要在迭代周期内进行临时增加需求时，需要以邮件形式告知所有干系人【运营、产品】
测试完成并上线，以论坛形式在全公司进行通知【产品】
以上是我在公司中与业务或者运营人员进行协作的机制，希望可以帮到大家与其他业务部门建立起良好可持续的协作机制，最后还是希望大家持续关注，微信公众号中搜索“小宝谈产品”，让我们一起在产品和运营的路上不断前行～
网友评论