敏捷项目管理正转变为敏捷产品管理

按照定义，传统项目是指为实现商业论证中计划的特定收益而进行的临时性的团队工作。项目启动是我们对项目了解最少的阶段，然而它却是要确定项目预算、进度计划和预期价值的阶段。当项目结束时，项目团队解散，对项目不熟悉的运营团队被留下来支持客户和产品。如果还有额外的工作需要完成，则需要启动新的项目，组建新的团队，并且他们必须重新熟悉产品架构。项目通常在可交付物投入生产后结束，由其他团队对后续运营工作提供支持并评估项目对业务的影响。

如今，产品被认为是长期性的、创造价值的资产，需要永久性团队以迭代的方式对其进行细化、设计、开发、测试、集成、归档、支持，直到实现商业成果。一个高绩效团队要不断检查和调整产品，直到客户的问题得到解决。此外，团队还会保存来之不易的产品开发知识。团队和客户合作创造价值要高于遵循书面的规定。

我们越来越意识到项目驱动的方法限制了对客户价值的尽早和经常交付。然而，当采用敏捷方法进行产品开发时，你会专注于价值的交付而非对进度和成本的严格监控。当组织根据以下公式决定何时转变优先级时，能最有效地交付价值：

AC+OC>V，即实际成本+机会成本>价值

当开发产品额外需求的实际成本与未开发其他投资机会的机会成本之和超过剩余产品需求的预期交付价值时，开发团队需要转向开发更有价值的投资机会。

管理项目和开发产品的区别

管理项目和开发产品之间存在三个主要的区别：

>>产品从稳定的、长期的甚至永久性团队中受益最多。

>>产品不仅可以是短期资产，还可以是长期资产。活跃的产品从未真正完成，因为它们需要维护和改进。

>>产品是项目组合的一部分，旨在实现价值的最大化，而不是遵循规范。

永久性团队优于临时性团队

生命周期长的产品最好是由长期的甚至永久性团队进行开发和维护。团队在一起迭代开发新架构并且提升能力和绩效的时间越长，团队就越能理解客户需求，对团队的可预测性就会变得更强。聚焦于项目的团队在特定的一段时间内聚在一起工作，项目结束后，就各自奔向新的项目。当项目结束时，团队总结的经验教训可能不适用于下一个项目，因为人员、技术和客户极有可能是不同的。稳固的永久性团队能够实现信息透明、自我检查和自我调整（经验过程控制）。

小贴士大用途

永久性并不意味着敏捷产品团队不会改变，团队成员的职业抱负受到限制。然而，团队中的人事变更确实是一个特例而非惯例。那些因个人能力提升而变得更有价值的团队成员，会获得职业发展的机会。理想情况下，永久性团队成员表现得更像一个家庭，而不是一个只针对一个项目的、临时的团队。

产品是长期的资产而非项目可交付物

产品开发是有风险的，因为不确定性因素无处不在。但正是不确性因素才使得敏捷产品开发成为理想的方法。传统项目的任务是在固定的时间期限内完成特定的系统可交付物，然而敏捷产品开发是通过构建可使用的、功能完善的产品增量，并在产品开发过程中不断收集和实现客户反馈来不断迭代，以减少不确定性因素。这样，产品就成了对标客户需求、解决问题的资产。活跃的产品从未完成，因为它们必须被加以维护和改进。

在时间、金钱和人员上的投资，特别是在当下资本支出的策略下，可以将产品转化为既能提高营收又能节约成本的可折旧资产。将产品开发看作是资产创造而非成本支出，可以转变人们的观点。通过敏捷产品开发持续交付客户价值，增加了获得额外资金的可能性。

这叫技术支持

资本支出（通常被称为“CapEX”）是指公司用于购买、升级和维护实物资产（如房产、建筑、工厂、技术和设备）的资金。CapEX通常被用于开展公司的新项目或投资。

追求价值高于遵循规范

早期失败是敏捷的主要特征。敏捷团队热衷于通过冒险来创造客户价值。就像科学家一样，他们提出一个假设，在真实的世界中进行测验、评估结果，然后调整假设并再次测验。他们一遍又一遍地重复这个过程，每次迭代都使产品更接近客户的需求。敏捷团队不再遵循大量文档化的规范，而是力求获得客户的真实反馈。在敏捷产品开发中，产品功能的优先级是由对要解决的问题最熟悉的人决定的。

为何敏捷产品开发效果更好

在本书中，你将看到敏捷产品开发如何比传统方法运作得更好。敏捷方法能够创造出更成功的产品。在前面专栏“软件项目的成功与失败”中，我们提到斯坦迪什集团做过一项研究，该研究发现尽管29%的传统项目彻底失败，但是采用了敏捷方法后，这个数据下降到只有9%。敏捷产品开发失败率下降的原因是敏捷团队在频繁地检查进展和客户满意度的基础上对产品进行即时的调整。

下面是敏捷产品开发方法优于传统项目管理方法的一些关键之处。

>>项目成功率：在本书第17章，你将了解为什么在敏捷产品开发中，项目的灾难性失败风险几乎能降低至零。通过对商业价值和风险进行优先级排序，敏捷方法能在早期便确定项目是成功的还是失败的。敏捷方法中对产品开发的全程测试能帮助你尽早发现问题，而不是在花费了大量的时间和金钱之后再去发现问题。

>>范围蔓延：在第9章、第10章和第14章，你将看到敏捷方法如何在产品开发的全程中适应变化，把范围蔓延的可能性降至最低。按照敏捷原则，你能在每次冲刺开始的时候增加新的需求，而不需要干扰开发流程。通过全面地开发高优先级的特性，你能阻止范围蔓延威胁到关键的功能。

>>检查和调整：在第12章和第16章，你将详细了解在敏捷产品开发的过程中如何定期检查和调整工作。通过从完整的开发周期和交付可工作的功能中获得频繁的反馈，敏捷产品开发团队能够在每个冲刺中改进他们的流程和产品。

透过本书的许多章节，你将知晓业务敏捷性如何帮助你获得对产品成果的控制。尽早并经常测试，根据需要调整优先级，使用更好的沟通技术，定期演示并发布产品功能，如果你能做到这些，就能够对各种因素进行微调控制。