不少创业公司的产品经理需要兼顾项目经理的工作,并且全职测试角色。这篇文章讲产品经理如何进行高效的敏捷开发项目管理。
一、背景交代
背景,利用公司原有的项目管理方式,产品无法按时上线,产品质量难以保障。老板决定把项目管理交由产品经理主导,务必保证后续产品的质量并按时上线。
首先,我组织项目组成员总结原有项目管理过程中存在的问题,主要有两点:
- 项目进度不可见,产品经理对项目失去掌控,开发每日进度不可见,老板也不知道大家每天在做什么。效率低下,项目延期,成本增加。
- 测试周期与开发周期分离,不能及时有效处理中间开发出现的偏差。开发实际结果与产品期望结果偏离,质量不过关,开发人员重复工作。
针对以上的问题,结合领导给出的敏捷开发项目管理要求,我对公司的项目开发管理过程进行了重新梳理补充。最终提出了敏捷开发项目管理5步走的方法,并在后续项目管理过程中得以有效利用。相比于之前项目管理方式,新的方式把团队工作效率提高30%以上。
二、说明
以下过程只针对项目开发过程,不包括需求分析,UI设计,原型设计等过程。这些模块在此之前已经完成。敏捷开发项目管理过程,主要分5个步骤(以某小程序项目开发为例)。
二、目录
- 工时评估,列出功能清单与完成开发工时评估
- 计划排期,列出里程碑计划与开发计划,具体到功能模块责任到人
- 阶段测试,功能模块完成开发,开始阶段测试
- 项目管理过程中需求变更处理
- 完成综合测试,项目上线
三、具体步骤
1. 工时评估,列出功能清单与完成开发工时评估
产品经理梳理好要做产品的功能清单,找项目组对应的开发负责人进行工时评估,评估完成之后找技术主管确认,确认无误,完成工时确定。
此外,测试周期另找测试主管评估即可。开发工作量评估完成,具体如下图(1.0):
(1.0)
2. 计划排期,列出里程碑计划与开发计划,具体到功能模块责任到人
如何排模块时间点,基于功能清单工作量评估结果,产品定功能模块开发截止时间,与开发人员一起开会确认。
如何排优先级,可把功能点划分为两种,一种属于前置条件,一种是基于前置条件功能点。举个例子,你要卖商品,会涉及订单和商品两个要素。没有商品也就没有订单,所以商品管理功能实现必须先于订单管理。商品管理就是前置条件,订单就是基于前置条件功能点。
开发计划如下图(2.0):服务端比前端少一个接口字段,就不放图了,里程碑计划也可以从开发计划里面进行提取,就不多说了。
3. 阶段测试,功能模块完成开发,开始阶段测试
如何保证信息同步,利用线上协同办公工具,开发每次完成对应功能模块开发之后,会对表格信息进行实时同步更新,在用的协同工具是石墨文档。
如何体现项目进度,开发人员每天对工作进度进行更新,前端开发包括两部分,静态页面和接口,开发完成之后,文档中对应模块记下“V”。实际完成时间是开发自己写。前端开发计划以实际接口对接完毕时间为准,服务端以接口完成时间为准。如下图(2.0)
(2.0)
如何进行阶段测试,产品测试人员,每天看文档对已开发完毕的功能模块进行测试。测试之后在对应功能模块后面写明测试情况,有问题要求开发在进行下一模块开发的过程中把问题修复。因为是上个功能周期未完成的部分,这一阶段必须补上。
例如开发人员完成了商品管理静态页面和接口,产品看到之后就去测试商品管理模块,比如新增,商品列表里的搜索,商品编辑,页面样式等。
注意:这里的测试算作模块测试,不要求面面俱到,涉及到与其他未开发模块相关联的内容无需测试。保证主体功能没有大的问题,
每次完成一个功能模块,都要对已开发完成的所有功能进行测试。包括已测试过的功能模块,关联起来在进行测试。直到最后把所有模块开发完成,开始最终的系统测试。
栗子;商品管理已经测试完成,当订单管理开发完成,那么商品管理和订单管理需要进行关联测试。如确认订单的时候,把商品下架,然后下单等等。
4. 项目管理过程中需求变更处理
项目开发过程中,如果有需求变更,记录下来,如图(3.0) 。
如何处理,根据项目开发进度,决定是否要做以及要做哪些部分。这部分按照项目上线时间灵活协调至时间既可,一般我会把小的一些变更需求放到功能开发过程中。
如果是要加新的大模块,上线时间还足够,会跟大家商量争取把它做掉。时间不够的话,找领导说明情况,申请延长上线时间或者放到下次迭代做更新。
(3.0)
5. 完成综合测试,项目上线
系统测试,各模块功能开发完成,开始所有功能模块阶段测试之后,各种关联性测试。上述的阶段性测试如果做的比较好的话,系统测试基本不会有太大问题。这一阶段主要是完善细节,完成全模块交互逻辑测试,测试完成之后,完成项目上线。
四、总结
做项目管理其实像是在滚雪球,从小到大的每一个过程中,尽力把雪球的每次层裹的坚固稳定。这样,就算雪球滚得足够大了也不至于立刻全盘崩坏。
另外,有什么好处,我就不多说了,比如,降低项目风险,可每日汇报项目进度,成本可见,提升开发测试效率。
最后,方案是死的,人是活的,实际应用中需要结合项目场景灵活调整相关细节。产品经理切忌拿来主义,别人给你的是你能得到,剩余不能给你的需你自己悟。
本文由 @王想 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Unsplash,基于CC0协议。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。