不少创业公司的产品经理需要兼顾项目经理的工作，并且全职测试角色。这篇文章讲产品经理如何进行高效的敏捷开发项目管理。
一、背景交代
背景，利用公司原有的项目管理方式，产品无法按时上线，产品质量难以保障。老板决定把项目管理交由产品经理主导，务必保证后续产品的质量并按时上线。
首先，我组织项目组成员总结原有项目管理过程中存在的问题，主要有两点：
- 项目进度不可见，产品经理对项目失去掌控，开发每日进度不可见，老板也不知道大家每天在做什么。效率低下，项目延期，成本增加。
- 测试周期与开发周期分离，不能及时有效处理中间开发出现的偏差。开发实际结果与产品期望结果偏离，质量不过关，开发人员重复工作。
针对以上的问题，结合领导给出的敏捷开发项目管理要求，我对公司的项目开发管理过程进行了重新梳理补充。最终提出了敏捷开发项目管理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协议。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
