项目管理有很多理论，并且相关内容非常丰富，例如经典的项目管理的教材《项目管理：计划、进度和控制的系统方法》，字数达到了100万字。

但是从源头来说，经典项目管理理论都是源自于对生产项目的过程中需要的管理的总结。对于一个大型硬件设备的生产，需要组织庞大的供应链体系、工厂部门，所以需要合理的理论做指导。但是这种理论应用于互联网环境时，由于本身出发点要解决的问题的场景的巨大不同，变得并不是很适配。

项目管理，是计划、进度和控制的系统方法，也就是说，是一种方法论。所有的方法都是为了解决问题的，总体上来概括，可以认为项目管理的目的是在明确的目标下，让资源的利用率最高，成本最低。

对于一般的互联网团队来说，没有传统意义上的资源的管理了（连机器的管理都是云服务化），那需要控制的，基本就是人。所以，很多内部团队，不配置，也不需要配置项目经理，项目推进的工作就由产品经理顺手干了。

但是问题在于，人力这个东西，尤其是智力型人力这个东西，伸缩空间极其之大。我曾经跟的一个项目，开发给排出了96人月的排期。然而最终差不多是6个人干了三个月完成的一期交付。

同样的，还遇到过需求评审完了，在旧的功能上迭代，一个前端下拉框的修改，前端工程师给出0.5人日的排期。

不合理的排期有可能是开发本人的原因，大概率其实往往是团队管理的原因。一个管理不善的组织，会让开发来回的交叉做事情，经历过一两次吃亏后，再进行需求排期时，他就会留出非常非常大的余量。这样，如果有交叉的工作了，还能应付，不至于加班到半夜，要是没来交叉的工作，还能轻轻松松早点下班或者在公司磨磨洋工。这种情况，最终导致整体组织效率非常低下，而员工也不满意。因为要么一堆活加班到半夜，要么闲着磨洋工。

以人的特新来说，对于任何事情，最怕的是不可控，对于不可控人心里是会恐惧的。

消除多人协作的混乱的一个很好的方法，就是节奏感。就好比交响乐、那么多人每个人都在独立演奏，但是指挥带来的节奏让几十号人能够有条不紊的进行自己的演奏，每个人都清晰的知道自己什么时候该做什么，并且相信其他人也会按时完成自己的事情。从而达到整体的清晰明畅。

什么是节奏感呢？

音乐的节奏感的最直接的提现就是节拍器，固定时间打一个拍子。工作也可以有这种节奏感，就是固定时间周期，一个节点。

节奏感的不同，是瀑布式项目管理和敏捷式的一个重大区别。

瀑布式和敏捷式

瀑布式项目管理的典型表象特征：

1、产品经理产出需求文档
2、设计、开发、测试评审
3、设计、开发、测试工作量评估，一般是基于功能产出工时表格。
4、设计师基于设计的工作量评估，预估交付设计稿的时间，然后在规定时间出设计稿，评审
5、开发启动开发、基于工时评估，确定提测日期
6、提测后，测试基于工时评估定完成测试日期。
7、产品和项目验收、确定上线日期、上线。

这种方式的项目管理，每个时间点是以及与每个角色的人对于自己工作量的评估来决定的。所以，每个节点的耗时可长可短，由相关角色或者角色的主管来确定。每个节点的时间是随机的，是依赖前一个人的工作的。

敏捷式的项目管理的一些表现：

1.日会、周会
2.设定固定迭代周期
3.大迭代里套小迭代
举个例子，以周为周期迭代，工作流程如下图：

按周迭代的敏捷项目管理

第一周，产品设计和 UI设计，同时拆分工作。

第二周，产品设计下一模块（如果需要），开发开始开发产品第一周设计的产品（基于优先级）并提测。

第三周，产品继续下一模块设计（如果需要），开发进行下一模块设计，测试启动第一模块测试。

这里的周期设定为周，实际可以给予团队规模、项目特征，设定为双周或者月。例如，微信团队是多个部门多个团队要协作开发，他们设定的迭代周期为月。每个月的最后一周，项目经理组织多个部门的产品经理共同制定下个月的开发计划。

对于敏捷式执行顺利的团队，每个角色，对于每周做的事情，交付的内容都有明确的目标。对于工作量的预估，不再是基于一个事要做多久，改为一周能做多少事情。为了配合整体节奏，整个团队就要尽可能保持相同步骤、相同节奏。带来的好处是显而易见的：

1.不再完全依赖开发主管对于工作量的长周期评估——这种评估很大程度上并不是很靠谱。
2.不再产生由于开发资源紧缺导致的来回切换工作的并行开发——最起码这一周，这个人就是这个事情。
3.团队配合更加默契，这种项目推进方式，一般要求相对固定的产品、开发、测试人员。团队之间在几次迭代之后，变得更加默契，效率更高。
4.团队成员焦虑感减少。每个人每周需要做什么、交付什么是很明确的、可预期的。不确定感减少。产品不需要每次需求再跑去申请资源，开发不用担心来回插入工作、测试也不用来对插入工作。
5.综上，带来的是整体效率的提高，水分的减少。

习惯瀑布式项目推进方式的团队或者个人，切换到上面迭代的方是时会有巨大的不适应。包括提出巨多关于实现上述项目推进方案的难点或者可行性的问题。典型的包括：

不可能工作都刚好拆到一周做完；
不可能给你固定的人；
要和其他团队合作，经常有插入需求。

还有一些阻力来自于，修改项目推进方式，可能会让某些成员觉得自己的话语权降低（比如之前主要工作是决定人力分配而很少写代码的开发主管），进而抵制。

对于习惯瀑布式的人来说，切换到敏捷式的另一个阻力在于，他会觉得工作被打散了，目标不够清晰。

关于目标的问题，其实是另一个问题，不管是敏捷式还是瀑布式，都是在目标清晰的情况下组织人力工作的方式。也就是说，目标清晰，是进行项目开发前需要完成的工作。敏捷式不是产品经理偷懒的理由。

目标是会变动的，但是项目推进过程中目标应该是清晰的。敏捷式带来的另一个好处是，应对目标的变动会更加及时。

即使推进团队接受敏捷式的项目方式，由于人们巨大的行为惯性，依然会习惯的拿一个需求，问下排期，定下哪天到哪天开发。由于这种思维习惯，就让敏捷的节奏特征被打破了。所以要推进团队进行敏捷式的项目推进，要没完没了重复强化一种思维，就是评估工作不在是工作要做多长时间，而是固定时间内能做多少工作。当思维方式从明确工作估时间转变成了固定时间塞工作，你就掌握了敏捷式的精髓了。

总结一下，如果团队遇到下面这些问题，可以考虑改为使用敏捷式开发：

1.各种紧急需求来回插入，项目总是延期
2.产品经理抱怨开发评估时间乱估
3.定好的开发总被挪走去支援紧急需求
4.产品经理需求变来变去，经常开发到一半前面废掉了
5.需求方经常冒出来紧急需求，应付困难。
按周迭代的敏捷式，执行的要点：
1.给与所有需求方一个预期，提任何需求，最少提前两周，也就是需求本周提，最快下周开发，最快下下周上线。
2.产品经理能给出大致的总体目标，需求详情可以分阶段产出。
3.产出的需求详情能够基于逻辑和依赖关系进行分层和分块，合理标注优先级
4.日会同步最新进展和问题
5.周会，总结本周开发进展，开发内容提测，安排下周开发的工作，切记是按照下周的时长塞入具体工作，不需要开发评估具体工期，就问这些工作，下周能完成多少。总结测试进展，将能够上线的模块整合上线，安排下周测试任务。
6.月度总结。