点击上方 “ 产品微言 ” ，马上关注

优秀的项目领导者，要尽可能地将团队成员从烦杂的工作量中解脱出来，投入到真正创造价值的工作中，为最终的产品交付贡献创造力

传统的项目管理，目的是为了控制计划。它首先认为计划是合理的，然后考虑如何把计划通过简单的流程能够转化为可预见某种结果的行动，遵从计划是传统项目的最大魅力，也是最大陷阱，因为软件开发需要的是创造力，而不是依章照搬的机械工作。

但实际情况是，客户并不了解，也不关心项目的工程任务，他们只知道他们想要的产品特性。当我们交付某个产品的时候，客户只会说“是的，这就是我想要的产品功能”，但是你如果说“我们完成了数据库链表设计”，这些对客户来说都是没有价值，这不是客户想要关心的，更不是他们优先考虑的问题。

敏捷项目和传统的首个重要区别就在于，是为了交付最终客户认可的产品，还是为了完成大量的项目任务，对敏捷来说，价值永远大于项目约束条件。

1传统项目的约束

回顾一下传统的项目管理方式和基于传统的项目分解清单，里面清楚的列出了所有涉及到项目的工作任务，可以说事无巨细的任务都有安排。之所以项目经理会列出这种清单，其一是要明确要完成的任务，确保所有工作都有专门的人负责。其实这种方式还有另外两个含义。

其一，是完成任务所代表的工作量在多数情况下都意味着项目的合同金额，其二则是为完成任务所需要的资源投入和时间周期。

这种模式带来的负面必然是繁重的文档输出和复杂的流程体系，且流程会随着项目推进而更加走向复杂化。结果是，团队为了追求任务的完成数，而不得不投身于浩如烟海的会议、文档和流程中。

传统的项目管理模式，典型的特征包括：

1、专注于明确的项目需求，确保在明确需求范围内完成项目；

需求不明确被视为传统项目最大的障碍，现实当中一旦项目出现状况的时候，所有人的第一直觉就是“需求是不是不清晰”，“功能是不是不完整”，“是不是需求有变更”。

所有人都惧怕需求和需求变更，因为任何需求的细微变动对项目来说都可能导致项目指标的红线，因为需求范围必然导致返工，进而导致延期交付，那么整个项目往往就会被宣判为失败，甚至导致回款困难的一系列后遗症。

2、强调可测量的指标（进度、范围和成本），把完成铁三角当作项目成功；

传统项目重视指标考核，把进度、范围和成本统称为项目金三角，项目经理的核心工作就是确保如何在三者的平衡下完成项目的交付。实际上，这是一种非常理想的项目管理思想，因为它与实际情况并不相符。

因为项目前期没有任何可以预料所有问题（业务问题、技术问题、人员问题），那么就必然存在“需求/技术变更”等一系列的问题，矛盾无法避免。

3、机械执行项目计划，通过对流程的管理控制变更；

由于针对团队的考核指标是铁三角约束，自然而然地项目团队也仅仅只对铁三角的约束条件负责，哪怕是项目需求明显与实际业务发生偏离，项目团队仍然会继续按照既定的目标按照固定的流程推行项目，直到被外部因素叫停。

传统项目的流程化，规范了针对不确定性环境的指导，但实际上也禁锢了团队的创造力，演变为机械式的完成项目指标，当这种局面演变到一定程度时，项目必然最终导致失败。

4、强调项目经理的流程控制，弱化了产品经理的职能价值

既然是为了完成项目交付，理论上确实是只需要完成既定的项目任务就应该被认定为项目完整的进行了交付，满足了预期的设计。因此，实际业务的需求的解决方案便不是最优先解决的问题，产品经理的介入往往会被延后，或者被忽视。

2持续流动的价值

敏捷项目相较于传统项目思维，典型的特征之一就是试图聚焦于交付产品的实际价值，首先强调交付的产品是否能够带来应用价值，团队把交付最能满足客户的产品价值作为第一目标，并努力平衡铁三角（范围、进度、成本）的约束。

敏捷项目仍然把项目的进度仍然作为关键性的考核指标，团队是通过时间盒的迭代周期来适应需求变更，只是它强调精力放在如何专注于执行来交付价值，这和传统项目的按完美计划执行的思路有本质区别。

敏捷项目需要产品经理和项目经理共同主导项目需求的优先级、功能清单、成本/效益分析，从价值的角度产品经理具有更重要的角色，因为只有产品经理才能更加凸显产品的商业价值，也要求项目领导者需要具备与利益相关方进行沟通管理的商业头脑。

对敏捷来说，产品的价值被认为是具有持续性流动的特性，他们会随着产品的版本迭代持续得到提升，且这种价值必然与企业或组织财务收益有关，比如提高市场占有率就能带来财务收益

这种持续性的产品价值观念，要求团队交付的产品除了交付的高质量以外，还应该能够适应未来的客户需求，因为产品价值随着产品功能的不断演变而产生，产品的未来收益取决该产品能否迅速、低成本适应新出现的能力要求，如果产品仅符合当前的客户需求，而不容易适应未来变化的需求，注定其生命周期会很短。

所以，如果希望交付的产品具有重大客户价值，就必须和客户建立长久的伙伴关系——一种双方共同承担责任和义务的关系，强调是对客户的业务提供实际帮助，因为只有用户才能真正定义产品的价值，他们通过产品的使用体验来判断产品价值。

从这个意义上出发，敏捷思维首先是一种用户至上的产品思维。

3卓越技术的创新

传统项目思维，由于过于强调项目的考核指标，为了满足于这种指标要求，整个团队自然而然地会把短期利益放在第一位，所以传统项目排斥变更，并抑制创新，他们也很难去鼓励技术卓越和个人的责任感。

因为创新，势必会带来更多的不确定性，包括技术的创新也可能让团队付出额额外的工作，这传统项目而言是极为不合适的选择。更为严重的是，历史上的低质量的技术开发方法累积的问题严重的拖累了项目交付，但他们罔顾现实，继续累积技术债务，而不是尝试解决根本问题。

但我们生活在一个由创造力、创新力和想象力推动世界发展的时代，客户的实际场景需求也需要有不断具有创造力的产品、技术、流程来支撑。这种供需双方的目标冲突日益加剧，事实上我们经常说B端项目很难落地，本质上是供需双方的立场和出发点不同带来的。

传统项目，追求效率和优化可以让交付我们能够想象得到的产品和服务，而创新交付的是我们想象不到的产品，这是这些看不见的产品才具有更强大的生命力，创新不应拘泥于形式，可以是新的产品，新的商业模式，新的工作流程，或者新的提升绩效的举措，只要是能够满足于未来的需求都可以是创新。

基于敏捷的创新，核心要求就是要持续的技术变革，增加竞争力，把团队从过去为了交付文档，转型为真正的交付高价值的迭代版本。只有将精力聚焦于交付产品相关的活动，就能够为项目项目增加价值，而将精力聚焦于计划和控制，则只是增加项目的开销。

敏捷项目领导者必须关注技术的卓越，因为它是适应能力和低成本迭代的关键，项目领导者需要和团队一起，讨论和决定项目的技术方法，而且在解决技术问题时，要让团队始终聚焦在业务目标上，而不只是为了完成任务。项目领导者应该协助团队做出关键的决策，他才能为项目交付做出贡献，而不是只是为了交付报告。

4简洁的迭代

传统的项目计划，制定的动机实际是来自于项目之外，他们所做计划本质上都是为了满足管理要求或者法律法规的要求，而不是基于项目本身的需求。所制定计划往往与管理控制欲有关，只是为了控制目的而制定任务计划，与工程师实际工作往往无关，或者关系不大。

严格来说，这就很容易制定脱离现实的计划，或者说是基于“愿望”的计划，导致整个团队实际上并没有能够更好的聚焦执行。过于烦琐的结构和流程，给了团队不去思考的借口，是否能够交付更大的产品价值没有成为团队追求的目标，差不多就行，搞完就行成了制约产品发展的重要因素。

控制性的项目计划，关注的是如何进行纠偏，它首先认为计划是合理的，然后考虑如何把计划通过简单的流程能够转化为可预见某种结果的行动，遵从计划是传统项目的最大魅力和陷阱，因为软件开发是创造力而不是依章照搬的机械工作。

与之对应的敏捷思维，则强调计划是为了更好的促进创建产品愿景并实现该愿景，而不是制定计划和进度表，控制进度，保证计划得以实现，所以敏捷项目要求更多的是适应团队的环境和能力，减少不必要的文档要求和繁复的流程，想办法来减少浪费，做较少的事但做正确的事，消除瓶颈更好的交付价值，避免为了项目过程的合规而让团队沉迷在文档当中。

要理解的是，过多的合规性要求和文档，不仅仅是消耗了大量的时间，而且扼杀团队的主动性和创造力，他们忽略了这些活动充其量只能减少错误、欺骗、劣绩和成本透支的风险，而无法确保交付高质量的成果（或者他们始终都不把最终的产品成果作为重点）。

敏捷项目思维不是排除文档和流程，而是认为不是这些举措本身没有价值，而是组织让这些流程凌驾于个人知识和能力之上，凌驾于价值交付之上，就完全是本末倒置。

这是敏捷精益思想和简洁原则的体现，为了尽快的交付产品并获取早期的财务收益，团队应该把精力集中在交付成果，并尽快从客户值得信赖的反馈，而不只是需求文档，敏捷的终极目标是为了帮助客户获得成果，而不只是为了完成工作。

客户很难在一大堆项目文档中找到真正所需要的东西，迭代开发的策略能够不断的推动团队自我纠正和完善，而时间盒的应用会在实际工作中强制项目领导者做出困难的决策，使得项目团队能够通过连续性的短期开发、评审和调整，来扩展交付版本的能力，最终交付的是满足客户实际应用场景的产品功能，而不是为了项目任务。

以简洁为本，极力减少不必要的工作量是一种艺术，速度不是简化的结果，但简化能提高速度，并且降低成本，从而增加价值。敏捷原则推动团队去裁剪和调整一套和实际情况接近的规则并加以实践，从最小集合开始试图避免描述团队成员应该做的每个活动细节，然后明智的随着需求而增加，这比一开始从全面规定然后逐步精简要更为有效。

———— / 往 · 期 · 回 · 顾 / ————