来自PMO的反击

敏捷管理模式给传统项目管理带来了前所未有的挑战，特别对传统组织中的PMO（项目管理办公室）来说，甚至是生死存亡之争。控制力减弱，权利被瓦解，这一切都让传统的PMO无法接受。

 

自从有了SAFe/Less等大规模敏捷框架，这些框架就成了传统PMO的救命稻草 ... ... 大规模敏捷框架真的可以让大规模组织敏捷起来吗？还是披着敏捷外衣，贴满了时髦词汇的噱头？

 

敏捷到底是什么？原文作者给出了答案，除了操作上的种种套路以外，更重要的是对待创新和协作的态度。没有了后者，那就只剩下一张皮了。

 

 

原作者简介

Marty Cagan 曾经在 eBay, AOL, Netscape, Continuus 和 HP等财富500公司和创业公司任高级管理职位。主要负责商业策略，产品设计，用户体验和产品研发。2008年出版了 "Inspired: How to Create Products Customers Love" 一书。经常在产品经理社区发布博客和文章，并为多家技术驱动的公司提供咨询服务。

 

译文：过佳昱

原文地址：https://svpg.com/revenge-of-the-pmo/ 

 

十五年前，我第一次接触到 Agile（敏捷）方法，当时的我刚开始面对多个产品团队，尝试使用新的方法进行产品开发。在此之前，我长期从事产品开发流程和工具的研究工作，由于这些方法都源自解决方案/项目领域，所以一直有人向我咨询如何在产品领域运用这些方法。

 

什么是敏捷？

 

刚开始接触敏捷时，我就被敏捷的几个核心原则所吸引，因为这些原则和我所认为的好团队所具备的几个最重要的特点非常一致。

 

虽然关于敏捷的说法各式各样，我个人的看法是，因为这是一种适用于产品团队管理的方法，其核心内容其实就是两个方面：

 

首先，通常最受关注的是，每周或两周（越频繁越好）发布一个稳定的小版本，这非常有益于我们及时获取客户反馈来调整我们的开发工作。对于那些习惯于按月甚至按季度发布产品的公司来说（对于传统公司来说非常正常），这意味着他们在构建、测试和发布产品的方式上发生了一些重大变化。这对许多团队来说是一个不小的挑战，这意味着他们必须在测试和自动化发布上做更多的投入，同时也意味着团队能够在这些方面做得更好。

 

另外很重要的一点，虽然这点经常被大家忽视，但我认为是敏捷最重要的原则。敏捷鼓励团队自发的寻找解决问题的方法。这听起来似乎应该是显而易见的，但在过去这并不是普遍的做法。相反，利益干系人会给团队非常具体的需求（例如产品规划），然后项目经理会非常明确地分配和跟踪特定人的任务，并一直驱动团队按照计划执行，直到发布到生产环境。

 

你会发现，第一个改变代表了软件的开发和发布方式的显著变化，第二个改变则更多的关注于团队如何协作和解决问题，以及谁对结果负责。

 

敏捷真正的挑战

 

第一个改变并没有真正困扰大多数公司，虽然他们的业务/市场人员要适应更频繁的版本发布，客户也需要适应这种改变，但最终都找到了有效解决这些问题的技术和方法。

 

然而，第二个改变却是另一回事。随着这一协作模式的变革，公司内部的各种政治斗争被显现出来。

 

许多利益干系人不愿意将权力下放给产品团队，尤其是在他们的 “产品负责人” 更多的只关注开发过程和工作计划本身，缺乏对于用户，数据，业务和乃至整个行业的深入了解，无法确保团队更高效的为业务解决难题的时候，这种抗拒就会变得更加强烈。

 

因此，在过去（包括现在）的大多数公司中，利益干系人仍然为团队提供他们认为应该实现的特性和产品规划。即便团队使用敏捷方法，团队也不能像我所描述的那样被赋予自我管理的权力，他们只是在执行任务。

 

虽然如此，除了依旧无法决定产品的发展和规划之外，团队基本上能够自我组织并按照他们认为最合适的方式运作，这肯定会带来一些改进，其中也包括能够提高生产力和团队士气。但是，在大多数公司中，有一个阵营显然对这种敏捷方法不满意。

 

被边缘化的PMO

 

在采用敏捷方法之前，大多数大公司都有一个相当强大的组织，叫做“PMO”，意思是项目管理办公室（译者注：这里作者使用的是 Program Management Office，而不是Project Management Office，意思是强调项目集或者大型项目，另外一个说法是 Portfolio Management。其实这两个说法类似，在大型组织中都有使用）。

 

这是一个由项目管理者构成的组织，他们负责管理公司的日常项目运作（产品规划、设计、工程、质量保证、运营等)，并确保 “按时、按预算” 交付产品，他们是项目型思维的化身。

 

大多数公司敏捷转型时，这个PMO被有意排挤在外。这样做的主要目的是为了能让产品团队站出来对这些关键因素拥有话语权。

 

在一些公司，PMO的工作实际上被取消了，但在另一些公司，PMO的工作在很大程度上被排除在软件开发工作之外，转而去负责部门间的协调工作。

 

你可以想象，敏捷在PMO领域不太受欢迎，但敏捷实在是太受整个行业欢迎了，同时整个行业日渐对旧式的工作方式感到失望，希望作出改变。PMO组织没有办法没辙，于是他们花了近十年的时间试图弄清自己在技术世界里面到底该是什么位置。

 

现在，他们终于回来了。

 

 

救命稻草

 

在过去的几年里，许多公司问我关于“规模化的敏捷”的看法，大多数的咨询都是关于SAFe (Scaled Agile Framework) 。不可否则，SAFe的市场推广做的相当不错（ 从我收到的垃圾邮件数量来来看）。

 

好吧，那我现在就来澄清一些我的看法。

 

通常情况下，我只写我实践过的流程和技术。但是这里有个问题，我个人并不知道有哪一家领先的科技产品公司正在使用SAFe。

 

所以，当我读了白皮书，看了视频，并和许多已经接受了培训并被迫使用SAFe的人交谈后，我所获取到的仍然都是第二手信息。

 

我发现的所有例子都是大型IT、项目型组织 … … 大银行和保险公司 … … 而不是技术驱动的产品思维型公司 … … 这些都不是我平常共事的公司。

 

我也承认我有强烈的偏见，从我所读到的和听到的一切来看，我不想在一家使用这种流程的公司工作。我无法想象我认识的任何一家强大的科技产品公司会选择使用SAFe，如果出于某种原因他们采用了，我敢肯定他们的顶尖人才会选择离开。

 

设计这个流程的人非常精明。他们采取了“拥抱和扩展”的营销策略，而不是对敏捷的正面攻击，所以你能从中发现敏捷和精益世界的每一个流行语，包括Scrum、看板、XP、精益创业、精益UX、持续交付和DevOps。

 

但这只是一种营销策略，大多数情况下，他们只是重新定义了这些术语的含义，以掩盖他们的目的。一个史诗（Epic）变成了“迷你商业案例（Mini Business Case）”；当被称为“精益管控（Lean Governance）”时，管控的理念听起来那么理所应当；当流程管理被定位为“敏捷流程管理（Agile Program Management）”时，流程管理可能会推行的更顺畅。这些关于迭代和敏捷的热点词汇掩盖了背后的真相。还有，他们的 “敏捷发布火车（Agile Release Train）”大部分每10周就会发车一次。

 

译者注：如果10周一次的发布都可以是敏捷的，那么大象早就是踢踏舞高手了。

 

我还可以继续举例，但希望你们明白，敏捷和精益的核心优势已经丧失。更准确地说，如果您遵循他们的流程，您将受限于此而无法实现创新。按照这些流程所推荐的方式，所有敏捷和精益的精华都荡然无存，我无法想象你可以使用这种流程实现创新的目标。

 

几年前，我写了一篇关于产品公司研发失败的根本原因的文章（Product Fail），并指出了瀑布模式和项目型思维模式的10个关键特征。我把这个特征列表和SAFe进行了比较，发现所有的10个特征都存在于SAFe中。事实上，我认为这十个特征都是这个流程固有的。

 

这里面的根本问题是，一个专业的产品团队的核心理念已经被彻底摧毁。在SAFe框架中，产品团队的理念已经被破坏和降级。现在的理念就类似于一台僵化的机器，包括自上向下的产品经理，架构师和发布经理，这些人做所有的关键决策，然后产品负责人给工程师团队分配工作。

 

根据不同的组织规模和你想获取的话语权的大小，SAFe提供了不同的定制化版本。如果你是一个保守的PMO，正在怀念你以前的权利，流程和项目管理方式，你恐怕会非常喜欢它。

 

退一万步讲，SAFe也仍然是一个自上而下、目标指向非常明确的模型。从角色设计，尤其是工程方面的角色来说，它并没有提供它所承诺的能力。一切都是都是为了完成任务，而不是产生价值；最终真正的结果只能是阻碍持续性创新的发生。

 

公平起见，我觉得这样的流程仍然在某些情况下是合适的（或者至少，而且也不比其他方案差多少），比如在以下场景中：

 

1. 大量使用外包团队或者供应商提供工程能力的组织；

2. 针对现有的成熟系统的重构，如果团队对所使用的架构和技术栈完全了解，不存在任何盲点；

3. 组织内部没有真正的产品经理或真正的产品设计师这类的角色，并且使用的都是技术一般或缺乏经验的工程师

 

对于大型项目型思维的组织，我理解这种对于控制力的需求。但是对于那些需要依赖持续创新才能生存的组织来说，这种做法无异于一种严重的倒退。

 

当我第一次从一家采用这种方法的公司（一家大银行）的工作人员那里听说这个方法时，我告诉他们这听起来就像瀑布模式的起死回生一样，并且我告诉她这种方式不会产生任何好处。但事实上，这种方式似乎与项目型思维的组织产生了共鸣；是的，仅仅因为它和硅谷的工作方式格格不入，并不意味着它在其他地方不会受到欢迎。

 

需要特别强调的是，现在几乎所有的大型公司都在进行“数字化转型”，而数身在其中的人都没有意识到，这种转型的核心正是从项目型思维向产品型思维的转变。

 

当你将 “利用敏捷和精益的现代理念” 与规模化带来的挑战放在一起考虑的时候，就不难看出大公司是如何成为这个营销策略的牺牲品的。然而颇具讽刺的是，这都成了“数字化转型”的代名词。

 

结束和开始

 

这类过程的兴起让我清楚地认识到，更整个行业中有很大一部分人仍然不理解项目型思维和产品型思维之间的区别，因此他们看不到敏捷或精益的真正价值，或者只有肤浅理解。

 

所以我要更加努力来帮助大家理解这些观点，推荐和写作更多关于团队和组织之间的差异的文章。

 

特别感谢 Jeff Patton 对本文的评论，也感谢 Ken Schwaber 和 Ron Jeffries 发表他们的思考。