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