回顾下以前经历的两类项目

春节期间一直在读一本书，《项目管理修炼之道》，理论性非常强，但又极具实践价值，其中不少话也点出了开发的一些的痛处，现摘录几句：

“不是每个人都善于估算，有些人会过于乐观，对于任何任务都会少估算50%的工作量。有些人过于悲观，为每个任务添加缓冲的时间，有些人在估算不超过3～4天的小任务时没有问题，但是对于超过一周的任务，却很难估算准确。”

“使用日期范围，可以让项目不至于受过早承诺之苦，不必在一个不可能的日期前完成。”

“日程安排并不是预言，仅是猜测而已。但是有些项目经理的出资人会将这个猜测视为承诺。”

可以看出，作者也是在实践中一步步走过来，在考虑一个项目的成功标准时，总要涉及到几个方面：功能集合、低缺陷率、发布时间。在项目开始阶段，如果因为不科学的管理，销售在外吹牛，和客户承诺了一个不可能的日期，若强求按时发布，又要求十分完备的功能，那就等着无穷止的加班和满天飞的bug吧。

读是次要的，最主要的是思考，可以结合曾经接触过的项目及其管理方式，与书中描述的范式作比较理解。本人曾经历的项目主要有两类，一类是10人左右的小团队互联网项目，一类是50多人的中型项目。大型项目比较少见，即使在一些大公司，也是按项目分组的，有些项目也不过十几人，几十人。

开发人员10人左右

小团队项目刚开始开发总是有些随意的，最适用于敏捷生命周期，在急于将新产品推向市场，面向用户的情况下，在从0到1阶段，定义出可运行的最小功能集合，在评估的日期范围内开发上线。随后就是1～4周一个迭代，每个迭代都是一个时间盒，每个时间盒产生通过测试并可运行的功能，其间包含设计、编码、集成和测试活动，迭代过程中，需要维护一个产品代办事项列表，并排列优先级，在一个迭代周期内划定本次迭代待完成功能，迭代开始时，迭代内容不得变化，一切的新增功能和变更都安排到下一个迭代中。这当然是理想情况，有时候，我们不得不面对客户或管理层的日程游戏，比如

“我们必须马上拥有这个功能，否则就完蛋了！”

“时间太长了，这些都要提前n天做完。”

对此，可以把一部分较低优先级待办事项移到下一个迭代，将新要求的功能添加进去，或者要求更多的时间或资金。

如果对功能集合、发布时间、开发成本都没办法调整，且开发人员都在高效率工作状态，那加班似乎就是唯一的选择，因为不加班，匆忙开发，bug满天飞的情况很可能出现，而承接这一技术债务的还是技术人员。

有些初始小项目还不到五个人，这样迭代可能更为随意，也更为频繁，一天一迭代也是十分常见的现象，这或许是产品和流程不成熟的体现，因为任何一个盈利可观的项目，稳定运行是放在至关重要的位置的。

开发人员50人左右

这是一个中型项目，敏捷生命周期同样适用于这类项目，区别是由于项目管理者难以一次性带领50多人，因此人员自然就按功能模块分组，5-10人一组，每组设立一个技术组长，其间可能还涉及到与跨职能部门的沟通，比如DBA、运维人员和架构组（项目团队若按架构组织，容易阻止人们协同工作，难以共同完成完整的功能，打乱项目节奏）。迭代周期比10人项目更长，一般为一个月即四周一迭代。而且，项目刚开始是增量式生命周期，等第一个版本发布后，转为敏捷生命周期。因为中型项目在初始阶段人们对它知之甚少，为了更好地避免一些架构风险，收集更多信息，相对于敏捷，前期是要做更长时间段的规划的，不过前期规划和需求收集要设立一个时间限制，后续新需求都安排在下一个迭代中进行，否则需求来了一茬又一茬，项目便一直无法顺利进行。注意，需求变更也属于新需求。后面为了更好地适应新需求和更快地反馈，可以转向迭代更短增量更少的敏捷生命周期。

另外项目不管大小，如果运营和开发同时进行，开发人员便处于多任务状态，这极其影响效率，一些在线运行的互联网项目尤其如此，必须采取措施处理这些干扰，如将运营工作作为迭代内容的一部分，加入到产品代办事项列表，并在评估开发时间时将它考虑进去，安排专人优先负责运营工作，这些人最好喜欢“灭火”任务。

希望了解其他项目生命周期内容及其他精彩有趣片段，欢迎关注我的知识星球，另外，从开发转管理，沟通交际能力的培养是一个重点，我会推荐三本书，这三本书我都在看，而且每本都是操作性强的干货，看了这三本书，并按照他的方法行动，可以让你在这方面的表现从40分至少提高到70分，从60分至少提高到90分。