快速迭代&项目管理

image.png

导言

据我了解，很多公司移动端的开发会采用快速迭代的的方式。而我所在公司的现状是，App发版极不规律，小的版本需要2-3周，大的版本偶尔也会超过2个月。

前不久，技术部门换了一位领导，提倡我们也采用快速迭代方式，并且定在2周发一个版本。

快速迭代的好处和坏处

对于创业公司来说，产品迭代的速度至关重要，甚至在一定程度上可以决定公司的成败，为什么会这样呢？

快速迭代可以及时根据用户的反馈调整产品的方向，能尽量避免在不必要的功能或方向上浪费时间，快速的迭代可以快速响应公司的战略决策，赶超其他竞品公司。

但快速迭代也有一定的门槛，首先，不管是后台还是前台，系统架构必须足够的强大和灵活，封装性和扩展性要很好，能够支持快速的功能开发。如果系统架构原本就不好，做功能都是Ctrl c + Ctrl v，那么，功能迭代的越多，系统越混乱，不利于后期维护和优化。打个不恰当的比方，就像是在倾斜的建筑上继续做楼层。另外一点是快速迭代主要以功能迭代为主，很少能挤出时间对系统架构做优化，这样对每一位程序员自身有要求，在开发功能的过程中，要有意识去优化系统框架。

快速迭代方案（可用石墨表格做排期计划）

迭代流程.jpeg

快速迭代过程中有几个重要的时间点：

1. 需求评审：理想情况是领先当前版本2-3个迭代，但如果是实践起步阶段，可以不用那么长时间，但至少也得一周。此处评审是指把需求加入需求池
2. UI出稿：需求评审之后，迭代开始之前
3. 接口文档：需求评审之后，迭代开始之前，如果后台人力充足，在迭代开始之前，除了接口文档外，接口实现要也要准备好
4. 需求确定：迭代开始之前2-3天，此处确定是指从需求池中选出优先级最高的任务作为该迭代的内容
5. 开发阶段：如上图红色单元格，暂定在周五，因为橙色单元格周四是公司后台例行发版时间，后台发版后，待上线包需要在生产环境验证。如果验证没问题，Android端在周五直接发版，ios则在周五提审。如果有问题，开发人员配合测试人员在周五解决问题，务必保证周五下班前发版。周五也是下一个迭代开始的时间点，因为结合后面的6个工作日（开发时间），期间有2个周末，如果开发过程中遇到棘手的问题，可以利用这两个周末解决，保证项目正常的进度。
6. 提测：周一下班前，周二开始到周四是测试时间段

把握好上面几个时间点，就可以保证有序的快速迭代，但这是理想情况，接下来我们就会按照这种方式来实践。过程中肯定会遇到各种问题，但我相信，实践几次之后，该方案肯定能够运行的很顺畅。

项目管理流程

试想一下，如果某一迭代选定你作为项目经理，那么你该怎么办，才能够确保整个迭代正常进行？

可能很多人在平时工作的过程中，太过于把精力放在自己的事情上，而忽视了很多觉得与自己无关的事情。这种做法正常来说也没错，但却会严重阻碍个人的发展。如果你当前的状态就是这样，建议你要从自己的圈子里面跳出来，多跟其他端的人员沟通交流，扩展自己的视野。

言归正传，怎样管理一个迭代流程呢，以目前的经验来说，需要把项目划分阶段：

1. 项目开始前

• 提前一周或者更长时间提醒产品开需求评审会，会议过程中会讨论各种问题和一些不确定的需求。会议之后，叫App端的成员消化需求，并且评审开发时间，产品就去确定那些有疑议的需求。
• 一两天之后再召集App端的成员和产品开会，确定当前版本的具体需求。并且在会议过程中，通知设涉及的后台和web端开发人员。会议之后，定下各端的负责人，要求输出项目计划
• 汇总出整体的项目计划，周知各端，最好开个会，确定大家的目标是一致的，明确版本上线的时间点

2. 开发过程中

• 每天晨会（每日站立会）汇报进度和问题，协调各端的问题并动态调整项目计划，如果遇到不能按时完成的问题，最好不要延期，宁愿砍掉部分需求（适用于快速迭代）

3. 测试阶段

• 整体提测后关注测试进度，并且在测试完第一轮之后，通知产品人员体验功能。如果有必要，可以组织各端的人员召开产品体验会，不用很长时间，半个小时就行了

4. 上线当天

• 安排好各自的工作内容，确保后台服务的上线顺序，保证有序顺利上线（上线后需要测试人员验证，验证通过之后在群里通知项目组成员）

5. 项目结束后

• 定期进行项目总结，快速迭代可以一个月一次，总结经验和优化流程

每个阶段按部就班进行，就可以管理好整个迭代过程，期间肯定会遇到问题，不必惊慌 ，找寻解决办法。当解决的问题多了，就知道遇到什么情况该怎么办，这不就是成长的必经之路嘛！！还有一点就是要定期向上级汇报项目的进度。

写于2018.1.13下午15:00（位置：深圳南山区）