大家好，我是专注企业数字化转型20年的峰哥。今天来和大家聊一聊产品经理如何做好研发过程管理。
原创不易，转发引用请注明出处。
前面已经详细介绍了如何进行需求分析和需求管理，当需求评审通过，开发计划也确定了之后，需求的准备阶段就完成了。接下来进入到需求的实现阶段，即我们通常所说的开发阶段。
进入需求实现阶段
研发模式一般分为瀑布或者敏捷两种，在ToB的产品研发中各有千秋。这次我们不展开讨论两种研发模式的适用场景和优劣对比，仅仅结合我个人的经历做一个总结。
1、产品研发过程管理，本质上是一个研发性质的项目管理，即“在限定的资源（开发人员）和时间（研发计划）内，完成最终的交付（上线发布）”。因此优秀的项目管理经验都可以应用到研发过程管理上。
项目管理核心要素
2.使用敏捷开发中的“迭代”概念，可以更加精细的管控过程。
“迭代”指的是把一个完成的项目开发周期拆分成更小的阶段性子项目（比如计划三个月完成的工作，按双周迭代的话，需要拆分成6个迭代）。每个迭代都有明确的目标和任务项。但迭代的拆分不是简单的做一个加减法，还需要注意以下几点：
- 每一个迭代的目标必须是一个用户可验证的完整功能，否则无法评估迭代是否达到预期目标。
- 迭代的工作总量要和研发资源基本匹配，以保证整个开发过程的平稳推进。一般会在迭代初期安排的紧凑一些（计划工作量超过实际可投入资源），一来为后继出现变故预留了缓冲，二来未完成的工作还可以有顺延的余地。
- 要注意任务间的前后依赖关系，避免出现一个功能完成了，但其前置功能放到了后面的迭代。
迭代示意图
3.做好产品、UX、开发和测试的工作衔接，避免出现“一人干活，其他人干等”的局面。
做过敏捷培训的同学应该都玩过一个“翻筹码”的游戏，可以对比一下“一个人翻完所有筹码再给到下一个人”的模式与“一个人翻完一个筹码便给到下一个人”的模式究竟哪种效率高。
高效的流水线作业
4.如果团队规模比较大，建议按照业务领域分成几个小组。
比如研发一个HR管理系统，可以按HR业务分为核心人事组、薪酬组、考勤组、绩效考核组、员工服务组等等。但分组的同时，也要对各个组的迭代进行统筹，避免出现上面讲过的“依赖问题”（比如薪酬组这个迭代要实现基础算薪功能，但考勤组的迭代还未实现考勤统计，这就需要调整相关组的迭代内容，保证前后衔接顺畅）
5.每日的晨会需要坚持高质量、高效率的召开。
晨会的目的是让各个成员之间了解彼此的进度和计划，及时发现问题和风险，以便大家共同应对。敏捷组织中会有“SM”（scrum master）这个角色来组织大家进行晨会，如果没有，建议由PM来牵头组织（PM直接对交付结果负责，意愿会更强）
晨会站着开
6.坚持结果导向。
具体的说就是一项任务只有当所有环节都完成了，才算完成，否则依旧是进行中的状态。这样做的目的，一是要求PM在拆解任务时要有合理的颗粒度（还记得前面说的概要需求里，每一个功能点控制在5人天左右的建议吗？）。二是推动团队成员之间的协作，只有当所有环节的工作都圆满完成，才能创造出价值。三是督促团队坚持到底，不是说提测了就差不多了，“行百里者半九十“，只有测试通过才算完成。
7.研发过程最大的风险就是不考虑风险。
风险是很难避免的，需求变更了、人员变动了、发版时间提前了，甚至刮个台风也可能打断整个研发计划。兵法云：”为将者未虑胜，先虑败，故可百战不殆矣“，虑败就是考虑风险，事先做好预案。”走一步，看十步“是老鸟产品和菜鸟产品最大的区别。
提前识别风险
总结以下，研发过程管理的精髓就是下面四句话：
事事有着落（任务合理安排，落实到人）
人人有活干（工作衔接好，高效运转）
天天跟进度（及时发现问题，提前做好应对）
时时虑风险（防患未然）
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。