精益-敏捷项目组合管理 (Lean-Agile Portfolio Management)-IDCF（精益敏捷开发）

内容来源：企业级精益敏捷实践

作者：侯平然 Perry

本文主要探讨在组织敏捷转型的过程中，在项目组合Portfolio级别对项目组合管理所要做出的变革。希望本文能起到抛砖引玉的作用，带给你一些启发和思考。

引言

在敏捷转型的实践中，我们可以看到这样一个现实：大多数的企业，往往只是在团队级别（Team Level）或者项目级别（Project Level）导入了敏捷实践（比如Scrum等），少数的企业在项目集级别（Program Level）导入了某些规模化敏捷实践（比如SAFe等）；在项目组合级别（Portfolio Level），真正采用了敏捷实践的企业微乎其微，即使是那些采用了规模化敏捷框架SAFe的企业。

然而，对于一个企业来说，如果要真正的实现敏捷转型，就不能只是在组织的低层级运行敏捷实践，而必须向组织的高层级推进。当然，一个企业的敏捷转型，最好是自上而下地进行，而不是相反。

这里所说的敏捷向组织的高层级推进，从项目管理的角度来说，意味着组织中传统的项目组合的管理方式（Portfolio Management）也必须要进行转变，即转型为精益-敏捷的项目组合管理方式（Lean-Agile Portfolio Management）。因为项目组合管理与一个企业的战略紧密相连，或者说企业的战略需要通过项目组合管理来实施和落地，所以对一个企业来说，只有它的项目组合管理也敏捷和精益起来，才能形成上下一条线，牵一发而动全局，让敏捷的效力发挥出来。

那么，与传统的项目组合管理相比，精益-敏捷的项目组合管理有什么样的不同？会带来什么样的好处呢？

本文将从以下三个方面进行论述。

人员组织方式

在传统的项目组合管理中，来自于不同职能或者部门的人以项目为基础组成一个一个的临时项目团队。项目启动后，成员逐渐加入到项目团队；项目后期，项目成员逐渐离开，直至项目结束后，项目团队彻底解散。被释放出来的项目团队成员，通常会被打散后加入到不同的新的项目。

传统的基于项目的人员组织方式的弊端是显而易见的。

• 首先，项目团队是临时组建的，可能多数人没有一起工作过，彼此并不熟悉，因此，每个新的项目团队都必然要经历塔克曼（Tuckman）团队发展历程，即组建期（Forming）、震荡期（Storming）、规范期（Norming）、执行期（Performing）和休整期（Adjourning）。项目经理和团队成员必然要花费额外的精力和时间，排除困难，以确保项目团队能够尽快的到达高效执行阶段。另外，有些项目团队，会一直处在震荡阶段，永远也到达不了高效执行阶段。这些都必然带来潜在的浪费。
• 其次，在组织层面，会加剧项目间资源的冲突。常见的情况是，一个新项目开始时，往往没有可用的和足够的资源。此时，要么从其他正在运行的项目抢夺资源，造成项目间的冲突（甚至对抗）；要么从市场上招聘人才，但往往是远水解不了近渴。同时，如果一个公司不存在一个在组织级层面系统性地防止和解决资源冲突的机制，那么项目间的资源冲突在这样的公司将会是永恒的痛点。在以后的文章中我们可以有机会探讨组织级层面系统性的防止资源冲突的有效机制。
• 再者，多数情况下，项目团队成员很难培养和具备业务敏锐度（business acumen）。对项目团队成员来说，他们的任务就是完成一个又一个的项目，这几个月在一个项目，下几个月在另外一个项目，至于项目所承载的产品是不是成功，为什么客户服务的，他们不需要也没必要关心和关注。因为他们的工作和所在的团队是临时性的。

与此相反的是，在精益-敏捷项目组合管理中，人们是以业务线（line of business）和产品线（line of product）被组织起来。规模化敏捷框架SAFe中提到，人们以价值流或者敏捷发布火车被组织起来。但考虑到，价值流比较抽象以及很多公司并不了解精益思想和SAFe，所以在这里我宁愿使用业务线和产品线的概念。其实很多公司，无论其是不是了解或者使用精益和敏捷，都已经在使用业务线和产品线的概念。

一个业务线代表着一个业务方向，业务方向通常和公司的战略相关。一个公司为了实现其战略，往往会规划多个业务方向或者说业务线。一个公司为了开拓某个新业务方向，或者为了维持在某一业务方向上的领导地位，就需要保持创新，不断地开发新的产品，因此，一个业务线下面通常会有一个或者多个产品线。

因为团队是基于一个业务方向而创建，他们的责任和目标是为了所在业务线的成功，而不是完成一个又一个的项目。为了保证业务线的成功，他们会一起探索各种可能性和假设，识别、规划和定义各种适合市场和客户需要的产品，必要的时候会放弃或者转向。在这个过程中，会逐渐形成产品线，团队不再被称为XX项目团队，而是被称为XX业务团队或者XX产品团队。

在这样的团队中，团队成员是基本稳定的，他们的努力方向和目标是稳定的，只是他们的工作的具体内容可能会随着对业务探索和认知的加深而变化。显然，在这样的情况下，很容易培养出高效的团队，且能够长期保持高效。

另外一个好处是，团队的业务敏锐度会越来越高，而不仅仅是关注后端的实现技术。

再者，这样的组织方式下，资源冲突的根源几乎就不存在了，因为在一个业务线下，比较容易做资源规划，工作的范围和多少都是基于可用资源来进行的。

总之，完成一个项目并不是最终的成功，而通过产品实现业务的成功才是最终的成功。

预算计划和执行方式

在传统的项目组合管理中，组织在规划年度预算时，基本上都是基于项目的。也就是说，无论是新产品开发，老产品维护，以及服务和运营等等，都必须是一个一个的项目或者一个一个的条目。而这些项目或者条目往往都是由下向上（bottom-up）收集上来的。可想而知，在这个过程中，不同的部门基于自身利益的考量，必然会尽可能的提出更多的项目或者条目，以期从组织的总体预算中抢夺更多的份额。

毫无疑问，组织的年度预算肯定会有一个限额，且一定与组织的发展战略紧密相关。因此，这必然就会有一个由上向下（top-down）的分解过程。这个由上向下的分解必然会与由下向上的归集发生冲突，因为由下向上的归集预算额度往往会超过由上向下的分解额度。于是，你会看到很多的争论、冲突、协调发生在不同项目、不同产品、不同部门、不同业务单元中，而且，这一过程往往都需要持续一段比较长的时间之后才能在各方之间达成一致。显然，这里面有很多时间和精力的浪费。

另外，为了让一个项目成立而获得必要的预算，为此而设立的虚拟团队往往需要花费大量的时间和精力书写详细的业务案例（business case），并挖空心思地提出看似合理其实是具有投机性的ROI（return of investment，投资回报率）。而这些工作在随后的项目执行过程中往往因为偏差过大而被抛之脑后。这又是一种浪费。

而且，在预算的执行过程中，有的项目的实际成本会超过预算，但因为预算都被预先固定在各个项目上，所以超支的项目就很难获得额外的支持；有的项目可能已经没有什么实际意义（对业务来说），但因为有预算和不可言传的利益纠葛，也会照常执行下去，就是为了把钱花掉；等等情况，不一而足。这些都是潜在的巨大浪费。

然而，在精益-敏捷项目组合管理中，组织的年度预算是基于业务方向或者说业务线的。在一个业务线内，又基于实际情况分配到不同的产品线。同时，产品线的规划以及产品线获得的预算都是基于业务线的业务战略目标来进行的，在执行过程中会进行动态的调整。某种程度上说，预算是以业务和产品为中心进行分配，而不是以项目为中心。当然，在SAFe中提到，组织的年度预算应该是基于价值流并进行动态的调整的概念，我认为与此类似。

很显然，这样做的好处是，在预算执行过程中，在一个业务方向或者业务线内，业务领导团队（包括产品经理）可以围绕业务战略目标，基于业务探索行动和产品投放市场后的反馈，自主且及时地调整预算的投入方向和多少。这也就是所谓的去中心化决策（decentralized decision）。

而且，团队不需要预先书写详实的业务案例（business case），而总是基于“提出假设，识别最小可行产品（MVP），采用敏捷开发方式进行实现，获得业务反馈”这样的反馈环来检验业务认知，然后对预算的执行进行适当的调整。这也就是所谓的预算的精益-敏捷执行（lean-agile execution）。

总之，年度预算应该从企业战略出发，以业务线和产品线为基础，精益的规划，敏捷的执行，这样才能最大可能的减少浪费，提高预算计划和执行的有效性。

治理（governance）方式

在传统的项目组合管理中，因为人员和预算都是基于项目的，所以其治理方式往往也是围绕项目进行的。

比如，产品开发往往会分为几个阶段（phase gates），每个阶段退出时必须经过关键干系人的审查和批准；对工作进展的度量和里程碑（milestones）的达成通常是基于任务的完成情况来进行的；等等。这些都是非常典型的瀑布法（waterfall）的特征和思维。

另外，也会比较注重项目是否在预定时间、预定范围、预定预算以及规定质量的要求内完成，不太注重及时获得市场和客户的反馈，从而进行及时和适当的调整。

然而，在精益-敏捷项目组合管理中，因为人员和预算都是基于业务线和产品线的，所以其治理方式往往也是围绕业务目标和产品进行的。

比如，产品开发往往采用设计思维的方式进行，团队自我管理和检查开发进度；工作进度和里程碑达成始终围绕业务目标，以可工作的软件和方案为度量，以获得市场和客户反馈为目的等等。

结论

这篇文章，花费了作者比较长的时间才得以完成，期间断断续续，写写停停，因为关于精益-敏捷项目组合管理的话题太过庞大，思路难以理的很清晰。于此，以上也只是作者基于自己的经验和知识做出的一点点总结，或有偏颇，或有谬误，都只为抛砖引玉，供大家参考，并欢迎批评指正。

＋“CH050791”后 回“fdcc”，可入qun交流~