关于 SAFe 和产品负责人角色，你想知道的一切 | Melissa Perri

Melissa Perri 2024-11-10

关于 SAFe 和产品负责人角色，你想知道的一切 | Melissa Perri

文字稿

Lenny Rachitsky： 有一个叫 SAFe 的概念，基本上就是大规模敏捷，对吧？

Melissa Perri： SAFe（Scaled Agile Framework，大规模敏捷框架）源自人们想弄清楚如何扩展 Scrum 和各种流程的需求。我不推荐使用 SAFe。我交谈过的每一个喜欢 SAFe、在 SAFe 上取得成功的人，最终都把它拆解掉，改造成了别的东西。

Lenny Rachitsky： 你近距离接触过很多公司，和产品负责人、SAFe 以及这些东西打过不少交道。

Melissa Perri： 产品负责人这个角色并不是从我们今天所知的产品管理中产生的。它最初是一种帮助开发人员确定工作优先级的方式。我后来参加了大量敏捷会议并发表关于产品管理的演讲，才开始了解到 Scrum 中有这样一个产品负责人的角色。

Lenny Rachitsky： 感觉它在不断增长，越来越多的公司在采用这种工作方式。

Melissa Perri： 许多大型企业转向 Scrum 或各种框架，是因为它们传统上并不是做软件起家的。当你审视敏捷方法论时，我们真正在说的是希望能够快速行动，为客户创造巨大价值。如果你拥抱这些原则，你会做得很好。

嘉宾介绍

Lenny Rachitsky： 今天的嘉宾是 Melissa Perri。Melissa 是产品管理界的传奇人物，是奠基之作《Escaping the Build Trap》的作者，最新著作是《Product Operations》。她还是 The Product Institute 的 CEO 兼创始人，该机构为各级别的产品经理提供培训。到目前为止，她几乎培训过每一家财富 500 强公司的 PM。在这次对话中，我们深入探讨了一个我在播客上不太涉及的话题——产品负责人、Scrum、大规模敏捷，以及在非常庞大的非科技公司中做产品。Melissa 分享了这些工作方式背后的历史，她在企业推行这些框架时看到的成功与失败，以及最重要的是——作为这些公司的领导者或产品负责人，你可以做些什么来提升你的组织和你自己。我从这次对话中学到了很多，也很期待听到大家的看法，因为我们在播客上不太涉及这类话题。如果你喜欢这个播客，别忘了在你喜欢的播客应用或 YouTube 上订阅关注，这是避免错过未来节目的最好方式，也对播客帮助极大。好了，下面请出 Melissa Perri。Melissa，非常感谢你的到来，欢迎来到播客。

Melissa Perri： 谢谢，Lenny。感谢邀请。

产品负责人：科技行业增长最快的角色之一

Lenny Rachitsky： 首先，让我介绍一下这次对话的背景。我觉得这期会有点特别。前段时间我在深入研究科技行业的就业市场，看到了一个令我非常惊讶的数据——产品负责人是科技行业增长第三快的职位，而且这只是我所看到的美国数据，但我认为在全球范围内大概也是如此。这让我非常吃惊，因为我从来没和产品负责人共事过，我的圈子里也没人谈论产品负责人，我也从没想过要招聘一个产品负责人。它就像是科技生态系统中一个截然不同的角落，在像这样的播客上你听不到太多关于它的讨论，但它显然在增长，所以我觉得花点时间帮助大家、也帮助我自己了解世界的这一面会很有价值。所以我邀请你来聊这个话题。你近距离接触过很多公司，和产品负责人、SAFe 以及所有这些东西打过不少交道，所以我想不到比你更合适的人选来帮我们理解这里正在发生什么，也帮助大家把这些做得更好。Melissa，再次感谢你来帮我们了解这些。

Melissa Perri： 是的，我很兴奋能聊这个话题。多年来我一直对这个话题充满热情，我一直在敏捷圈子和产品管理圈子里讨论它，所以很期待让听众了解外面的世界还有什么在发生。

产品负责人角色的实践观察

Lenny Rachitsky： 在我们深入产品负责人角色的历史和所有这些内容之前，有没有什么大致的背景信息你觉得分享出来会有帮助？

Melissa Perri： 也许可以先分享一下我是从哪里看到这一切兴起的，这样有助于建立一些背景。我刚进入科技行业的时候，完全是一个产品经理，之前从来没听说过产品负责人这个角色。在《Escaping the Build Trap》一书中，我谈到了很多我在创业公司和团队合作时使用 Scrum 的经历，那是我第一次听说它。那是 2011 年。当时教我敏捷的那个人态度很明确——“嘿，这是很灵活的。我们只是把工作拆分成 sprint，坐下来真正讨论工作内容。这是为了帮助我们真正提高工作效率。“我们对此很信服，而且从来不是教条式的。后来我在其他公司工作时，发现他们在 Scrum 方面、站会方面、实际运作方式上变得更加教条了。

之后我开始在会议上做演讲，我在纽约市演讲的最早一批会议中有一个叫 Lean UX，那里也有很多来自敏捷圈子的人。我意识到这比我们在公司里学到的、在那些公司里做的要大得多。外面有一大群人在实践敏捷，我就想，“哦，这太酷了。我想学怎么把事情做得更好。教教我你们的方法论。“结果我参加了大量的敏捷会议并演讲产品管理方面的内容。

当时人们非常兴奋想要了解更多。我也开始了解到，在 Scrum 中存在这个产品负责人角色，而我讲的是我们传统上谈论产品管理的方式——了解你的客户，出去测试东西，确保有假设，不要盲目地构建你想构建的东西。我发现很多采用 Scrum 并引入产品负责人角色的公司并不是这样做的。于是我开始通过我的 Product Institute 做大量培训，被叫进这些大公司——所有这些大银行——大概是 2014、2015 年左右，帮助它们学习产品管理。我当时非常兴奋，因为在此之前它们完全不想跟产品管理有任何关系。它们会说，“我不知道产品管理是什么。我不需要这个。”

我进去培训的时候发现，他们中很多人已经经历了敏捷转型，有了大量新的产品负责人。他们基本上就是走进来跟你说，“嘿，你现在是一个产品负责人了。你的整个角色都变了。“这些人背景五花八门——有些是开发者，但更多是来自银行业务端的人，很多是业务分析师，有些是项目经理。他们就是把一群人凑在一起说，“铛铛铛，今天你们就是产品负责人了，因为我们要搞敏捷了。“然后我进去帮这些人做培训。

我发现，这些人在敏捷和 Scrum 中被教导应该做的事情，跟我们公认的优秀产品管理之间，存在一个很大的认知偏差。过去差不多十年里我一直在与这些公司合作，努力弥合这个差距。我会去找他们的领导层，在这些敏捷转型的初期跟他们说，“你不能只做 Scrum。那不会让你在交付产品方面变得出色。这里面还有很多其他东西。“但领导们并不太理解这一点。

我注意到行业正在发生一个很大的转变，我们终于要走到那一步了。很多公司现在做得很好。Capital One 是一个很好的例子，他们在敏捷转型的基础上加入了产品管理，确实在信用卡业务上实现了逆转。但仍然有那么多组织还处于这段旅程的起点，它们处于我十年前看到人们所处的位置。我认为外面还有很多这样的公司。也许在科技行业或硅谷，我们对有多少公司在做这件事、这个规模有多大已经习以为常，但它们设立了这些角色，却并没有真正在做端到端的产品管理。这就是我所看到的各个领域的情况，过去十年里我一直在努力帮助组织建立稳健的产品管理实践。这不仅仅是开发的一个环节，而是我们到底该如何真正构建更好的产品。

Lenny Rachitsky： 我很喜欢 Capital One 这个例子。它确实可以运作得非常好，可以达到一个真正高效的境地。我们可以从几个方向来讨论这个问题。你觉得梳理一下产品负责人角色的历史，比如它最初是从哪里出现的，会有帮助吗？

产品负责人角色的历史溯源

Melissa Perri： 是的，我觉得这是一个很好的起点。我觉得这也能为正在发生的事情提供很多背景。人们忘记了这段历史。当我向别人解释的时候，我会说，我们在硅谷有产品经理，对吧？他们在 Google，在所有这些公司里——Amazon——他们是从一个商业角色中诞生的。对于一个软件原生公司来说，你的软件就是你的业务，对吧？它是你销售的东西，是你真正关注的东西。我们在硅谷的产品经理，他们在做市场调研，在和客户交谈，在和开发者协作，在迭代，在做端到端的产品管理。

而在另一方面，尤其是在大公司中，产品管理是从 Scrum 中、从产品所有权中兴起的。这些公司通常第一次接触产品管理就是通过实施产品负责人角色，然后才发现，“嘿，我们还是没达成目标。我们是不是在构建正确的东西？“然后它们才开始思考产品管理。这个角色的来源就是 Scrum。如果我们回顾一下敏捷的历史，敏捷是一场由软件开发者发起的运动。2001 年，《敏捷宣言》诞生了。一群开发者聚集在犹他州的帕克城，他们一起滑雪，然后说，“嘿，我们一直在各自探索如何更好地开发软件。”

有些人当时在实践我们今天所知的 Scrum，那就是 Ken Schwaber 和 Jeff Sutherland。也有人在做其他类型的敏捷框架，比如看板（Kanban），就是把工作在看板上流转。还有行为驱动开发（Behavioral-Driven Development）、特性驱动开发（Feature-Driven Development），那也是敏捷的一种风格。还有 XP，即极限编程（Extreme Programming），是由 Ron Jeffries 发起的。所有这些人互相发现了彼此，说，“嘿，我们一直在推动如何开发更好软件的边界，“于是他们聚在一起，写出了我们今天所知的《敏捷宣言》。

《敏捷宣言》实际上只是一个指导方针，描述了他们如何努力做到不仅仅是按别人的要求编码，而是构建更好的产品——我们如何通过软件开发来构建更好的产品？需要记住的前提是，我一直在强调——他们全部都是软件开发者。去参加那次会议的人里没有一个是产品经理。写《敏捷宣言》的人里没有一个是真正的产品经理。过去十年里我花了很多时间和这些人交流，就是想弄清楚，“嘿，这是怎么来的？这是从哪里来的？“

Scrum 的诞生与产品负责人角色

他们当中唯一与产品经理角色非常接近的人是 Jeff Patton，但他从未签署《敏捷宣言》，也没有参加那次会议。他和那些人交流很多，能看到正在发生的一切，但这一切本质上都是从开发者的视角出发，探讨如何构建更好的产品。这一点非常重要。签署《敏捷宣言》的其中两人，就是我前面提到的 Jeff 和 Ken，他们在各自的公司里独立发展出了 Scrum，后来他们走到一起，开始将其系统化，说，“我是这样做的，你是那样做的。“最终他们写出了《Scrum 指南》（Scrum Guide）。今天很多人的敏捷实践就是以《Scrum 指南》为基础的。《Scrum 指南》定义了开发团队中的一系列角色，然后说明了你应该如何开发产品。

现在大多数人都在用 Scrum，他们的做法是，“让我们把工作拆分成两周一个的冲刺（sprint）。“如果你愿意，可以调整冲刺的长度，但两周冲刺在初期是非常标准的做法。我们先定义要在待办列表（backlog）中做什么。产品负责人负责定义什么进入待办列表，为它编写用户故事（user stories），做所有这些工作。然后开发团队介入，讨论这些内容，产品负责人进行优先级排序，他们提问，然后开发团队承诺要构建的内容，接着就去做。最终产出的结果是一个”潜在可交付”的产品——不一定是真正可交付的，而是潜在可交付的。

他们试图把工作拆分成小块来逐步构建，而不是很多公司过去那种做法——花三年时间构建，然后一次性发布。所有签署《敏捷宣言》的人都意识到，如果我们反过来做，如果我们采用瀑布式（waterfall）的环境，就是那种线性的推进方式，风险会很大，因为如果我们花三年时间构建却不给任何人看，我们就没有用客户去验证它，也没有获得任何反馈。这确实开创了一种完全不同的软件开发方式。它说的是，让我们把东西拆小，更快地获取反馈。初衷是非常好的。

Scrum 中的三个角色

不过在《Scrum 指南》中，它引入了一些新的角色。有我们熟悉的开发者，还有产品负责人，以及 Scrum Master。Scrum Master 在 Scrum 中的职责是帮助大家更好地实践 Scrum。这就是他们的工作——“我如何更好地做 Scrum？我如何确保团队协作顺畅？“他们主持诸如回顾会议（retrospectives）这样的活动，在冲刺结束时我们讨论什么做得好、什么做得不好、我们应如何检视和调整我们的流程。而产品负责人这个角色，就是事情开始变得模糊的地方。

产品负责人角色的模糊性

产品负责人这个角色总体上最早出现在 Scrum 中。如果你去读第一版《Scrum 指南》——我确实找出来读过，因为我对它是怎么描述的非常着迷——上面说，产品负责人负责最大化工作成果的价值，团队负责执行工作。有意思的是，产品负责人并不完全是团队的一部分。团队由开发者组成，他们具备所有技能，能够将产品负责人的需求在每个冲刺中转化为潜在可交付的增量。团队通常是七人，上下浮动两人。

当你进一步阅读第一版《Scrum 指南》时，它确实说了，Scrum Master 与客户和管理层合作，识别并确定产品负责人的人选。Scrum Master 教导产品负责人如何履行职责，以优化 Scrum 的使用价值。如果他们做不到，Scrum Master 要被追责。再往深处看，还有一条建议：在商业开发中，产品负责人可以是产品经理。在内部开发中，产品负责人可以是用户部门的经理。

有趣的是，那是第一版《Scrum 指南》，而我经常和人争论《Scrum 指南》的内容。但 2013 年的版本——也就是你能找到的那个更新版，几乎每家公司进行敏捷转型时依据的都是那个版本——它删掉了”产品经理可以是产品负责人”这句话。那份指南里根本找不到这句话。这是第一版才有的，而且你能感觉到那只是一个附带说明。就好像，“哦对了，顺便说一下，Scrum 中的产品负责人不需要是产品经理，可以是客户，也可以是开发者。“通常就是客户。

从客户需求到待办列表的演变

他们在写这些的时候，有时候客户就是银行等机构内部的某个人，是他们需要软件所以才提出需求。他们会说，“给我做一个内部工具。去做这个。“于是在公司内部我们只是在接收需求，从这里你就能看到产品负责人角色是如何逐步演变成一个去问”嘿，你想让我构建什么？这里的需求是什么？“的人，然后只是听对方说”我需要这个功能，我需要这个功能，我需要这个功能”。Scrum 没有描述如何把内容放入待办列表，2013 年的手册中也没有。后来的手册都有了一些改进，都在某种程度上做了更新，确实更多地描述了必须从愿景出发，你需要分解产品愿景然后落实下去，但在 Scrum 的早期版本中，这些都不存在。

产品负责人培训的局限

当人们接受产品负责人培训时，实际情况是这样的——这是 Scrum 的另一整个领域——人们接受产品负责人培训，通常是两天的课程，教他们”嘿，这是如何拆解待办列表的。这是如何和你的团队做站会（stand-ups）的。这是如何思考优先级排序的。这是如何管理你的待办列表、为开发者排列优先级的。这是如何参与回顾会议的”。但它不教实验方法，不教市场研究，不教数据分析，不教任何我们成为产品经理所需要的东西。

大公司的敏捷转型

后来发生的事情是，这些公司开始进行敏捷转型，他们说，“嘿，让我们采用 Scrum 吧，因为 Scrum 就是为了更快构建更好产品而设计的。“这就是它的宣传语。所有人都说，“对，我想更快地构建产品。好的，让我们来做 Scrum。“这些大型组织，早在 2010 年代初、2000 年代，就纷纷说，“我们得在软件开发上做得更好。怎么做才能更好？否则在创新方面我们会输掉。“于是它们采用 Scrum 作为加快软件开发的方式。

**Melissa Perri：**那么，接下来发生的事情是，为了做 Scrum，Scrum 本质上是在卖培训。这就是 Scrum 的商业模式。所有这些敏捷教练会进来，教产品负责人——那些新出炉的产品负责人——把所有这些人拉过来，让他们变成产品负责人，送进一个两天的课程，然后说”去吧”。这就是所有敏捷转型的起点，也是很多公司今天仍然停留的地方。产品负责人这个角色并不是从我们今天所知的产品管理中自然产生的，它只是帮助开发者确定工作优先级的一种方式，仅此而已。产品负责人要为团队正在做最紧迫或最高价值的事情负责——他们确实这么说——但在我看来，如果你从开发者的角度看，这个角色也是你可以说”嘿，是你让我建的那个东西，对吧？我们没有建错。是你让我建的那个”的人。

这几乎进入咨询领域的逻辑了——你会说：“好吧，如果产品负责人替我把所有这些都排了优先级并告诉我要做什么，那如果建错了东西，不能怪我。“这种问题在很多努力采用敏捷、采用 Scrum 的团队中确实会出现。我觉得外界对这个角色到底是什么、我们到底该做什么，存在很大的误解。但这里的前提是，当我们谈论 Scrum 时，它只是拼图中的一块，而当人们现在谈论敏捷时，他们几乎总是把它和 Scrum 画上等号。

实际上我去搜了一下敏捷方法论，就像我说的，其他那些——看板是一种敏捷方法论，极限编程是一种敏捷方法论。它们没有产品负责人，这些方法论中不存在这个角色。那里就是开发者去做事情，或者团队去做事情。据我所知，极限编程会把产品经理视为团队的一部分，但 Scrum 把它看作一个独立的角色。敏捷方法论这块，所有人都说”哦，他们就是 Scrum 了”，所以它在业界就落了个不好的名声。我觉得 Scrum 如果你做得好倒也还行，但你必须理解它只是构建优秀产品的一部分，而不是全部，而公司采纳它的时候却把它当作会彻底改变一切的东西。公平地说，很多时候它也是被这样推销的。

初创公司需要框架吗？

**Lenny Rachitsky：**你谈到这些时，我想到一个更大的问题。我能想象正在听这些的创始人和小公司会说，“我们为什么需要这些？“尤其是硅谷的初创公司，“我们就是要把东西做出来。我们不需要这些框架，不需要 Scrum Master。我们有厉害的开发者和产品经理，我们就是要做出厉害的产品。“但我不认识有谁用这种方式做出了惊人的成果。你能谈谈到底是谁在寻找这些解决方案，这东西从何而来，哪些公司需要这些帮助，而哪些公司会说”我根本不需要这些”？

**Melissa Perri：**很多大公司转向 Scrum 或这些框架，是因为它们传统上不是做软件出身的。它们在寻找如何实施一套能在规模化下保持严谨性的东西，这就是 Scrum 大量出现的地方。当然，我也见过初创公司用 Scrum。有些做得挺好，他们理解这更多是关于每两周把东西交付出来去跟客户测试。我觉得如果你保持这种理念——就像我说的，我以前也用过，我们没那么多条条框框，这挺好的。当我在 OpenSky 带团队做 Scrum 的时候，到了某个阶段我们觉得”两周太长了，我们就每周发一次版吧”。

我们就是互相沟通，跳过了站会——这在 Scrum 里是大逆不道的——但我们跳过了每日站会。我们不需要站在一起讨论这些，我们每天都在互相交流。对我来说，真正令人惊叹的、也是我看到团队在使用 Scrum 时真正茁壮成长的情况，是当你去和人沟通的时候。你对工作进行讨论、拆解、理解，这样开发者和团队其他人就能立刻上手，人们可以提出重要的问题。如果你没有在做这些，那我觉得框架之类的会有帮助；但如果你已经在做了，你不需要框架，你不需要 Scrum，你不需要被规定在这个两周一轮的冲刺或类似的周期里。

只要你有一套方法论，甚至不需要是某种定义好的方法论。只要你有一种能把东西交付给客户的工作方式，那谁在乎呢？谁真的在乎呢？我觉得这个行业有很多包袱，也是我听到产品经理以及其他很多人——包括开发者——感到非常沮丧的地方，就是当你按部就班地做 Scrum，或者按别人教的方式、按书上写的方式做，那就是无穷无尽的会议。我知道设置这些会议的初衷是强制人们沟通，但当你已经知道自己应该做什么的时候，为什么还需要不停地开会？难道不应该直接去做事吗？

很多开发者抱怨，很多产品经理也抱怨 Scrum 有太多会议，根本没有时间真正做事情。这就是我认为你必须回到”检查与适应”这个环节的地方。很多对 Scrum 非常虔诚的人会跑来冲我喊。他们会说，“哦，那不是应该的做法。你应该检查与适应。“我同意，但很多人并没有这样做，这就是你要去审视的地方，你要问，“这些东西在为我们服务吗？如果不是，就把它扔掉。就不要做那些事了。“当你是一家小型初创公司的时候，我觉得你不需要这么多开销。它确实是为更大规模的公司设计的，而你所看到的真正采纳它的也正是那些公司。

**Lenny Rachitsky：**从我看到的数据来看，也正如你开头可能暗示的那样，这些公司不一定是以软件优先、产品优先的公司。感觉这在银行、电信公司以及那些不是产品优先和软件优先的公司中非常普遍。

**Melissa Perri：**确实也有 SaaS 公司在做 Scrum，而且他们喜欢用，我觉得他们并不那么教条。

**Lenny Rachitsky：**明白了。对。

**Melissa Perri：**他们这样做的原因只是想给团队提供更多关于规模化下如何协作的上下文。我也见过一些地方，他们不为团队规定用什么方法论，而是花更多精力拆解路线图，思考每个季度要做什么，设定那些主题，然后就让团队自己去跑，这也行得通。我觉得这真的取决于他们如何采纳，但我想说的是，并非所有初创公司都不做这些，这不是一条硬性规则。有些初创公司在做，只是我不知道他们做得怎么样。对我来说，如果你的团队已经在这方面相当有经验，这样做可能就有些过头了。

**Lenny Rachitsky：**我暗示的其实不只是 Scrum 这个一般概念，而更多是指那些非常结构化、僵化的流程，以及产品负责人这个角色。还有就是 SAFe 这个概念，我们可以聊聊。我们是要聊这个，还是先谈谈产品经理与产品负责人的区别以及人们在这方面的困惑？

SAFe 带来的困惑

**Melissa Perri：**我们来聊聊 SAFe 吧，因为很多困惑就是从那里开始变得混乱的。

**Lenny Rachitsky：**好，聊这个。对。

**Melissa Perri：**SAFe（Scaled Agile Framework，大规模敏捷框架）源于一个诉求——弄清楚如何将 Scrum 和各种流程进行规模化，并将其推广到大型组织。它起源于一种更结构化的敏捷方法，叫做 Rational Unified Processing。SAFe 并不是最早的规模化框架。还有 LeSS，也是一种大规模敏捷框架，以及 Scrum 的创始人 Jeff Sutherland 推出的 Scrum@Scale。它不是唯一的规模化框架，市面上其实有很多很多，但 SAFe 是营销做得最好的一个。它的营销方式就是告诉你，要让你所有的敏捷团队都用 Scrum，并且把它们全部整合在一起，你需要做的所有事情，它都替你想好了。

SAFe 的起源与运作模式

SAFe 的背后是 Dean Leffingwell 提出的理念。他真正想要展示的是，在一个组织中如何将多个大规模团队串联起来，以及如何为这个过程引入一定的严谨性和流程规范。那些超大型企业的高管们——我们说的是几万人的规模——非常喜欢 SAFe，因为它在开发方面规定了大量运营模型的具体做法，但与此同时，它也被包装成”这就是你做软件的全部模型”。你去看它的话，那是一张大家多少都会拿来调侃一下的大地图，上面描述了各种各样的事物。你可以点进去查看定义，了解各个领域里都在做什么。

SAFe 的那张图随着时间的推移越变越大。我想想，现在是什么版本？第六版了吧。我确实认识不少参与过 SAFe 的人，也认识很多培训师，跟不少公司合作过。我第一次接触 SAFe 是在 2015 年，当时我在为一家银行做咨询。我去培训他们的 PM，正在做培训，教他们如何去跟客户交谈、讨论假设、MVP 等等内容，这时有人走过来跟我说：“Melissa，这些内容都很好，但我没有时间去跟客户交谈，因为我是产品负责人。“我就问：“那你每天都在做什么？为什么没时间？“她说：“我得写用户故事啊。“我说：“好吧，那你每天写多少用户故事？“

SAFe 中产品负责人的困境

她说这是为了让开发者有一个满满的 backlog，这样他们就能全部忙起来，对吧？她说：“对啊，我基本上每天花四十个小时在写用户故事。“我问：“写什么内容？“我们问：“你在管理什么？“她说：“银行的登录 API。“我问：“能正常登录吗？“她说：“能。“我又问：“那你还在做什么？有没有新的项目？新的任务？“她说：“没有，我被重新编排到一个团队里，成了产品负责人。我有一个 PM 负责去跟客户交谈，然后她来告诉我该构建什么，我就围绕这些写用户故事，然后放到团队的 backlog 里。“我说：“这是什么操作？“然后他们说：“这就是 SAFe，我们正在朝这个方向做。”

这是我第一次接触 SAFe 的经历，之后我又遇到另一家公司也是这样做的，再一家公司，同样的模式一遍又一遍地重复——所有这些产品负责人基本上就是努力让 backlog 保持填满，供开发者使用，而且他们工作的范围非常狭窄。我还看到很多组织在重组为敏捷团队时，是按组件来划分的。每个人都在负责一个极小的功能点，这些团队的范围却非常庞大，很多东西根本没有被优先排序。该做的已经做完了，不需要再继续做。他们在给自己找活干，这样就不会被裁掉。产品负责人就是这么运作的。公司里还有各种各样的历史遗留包袱，人们被按组件重新分配到各个位置上，然后就是在那里编造工作来做。

SAFe 的组织结构与发布列车

SAFe 引入了 PM 和产品负责人之间的这种分工。如果你看那张图，产品负责人是敏捷团队的一部分，他们与 Scrum Master——也就是 SAFe 里所称的团队教练——以及开发者坐在一起，而 PM 则与系统架构师以及他们所谓的发布列车工程师坐在一起。SAFe 的做法是将一批敏捷团队整合到一个发布列车上，当你准备好发布时就上车，确保整个过程顺利推进，最终交付一个潜在的可用增量，或者在 SAFe 下完成一次大型功能发布。

SAFe 在规范如何做到这一点方面确实很擅长，他们很好地描述了如何运作发布列车，如何将这些团队整合在一起，如何让他们上车。然后他们还有一个叫”大房间计划”的做法——把整个发布列车相关的所有人，所有的团队，都召集到一个房间里，每个季度拆解出我们所有人要做什么。每次我去培训团队时，我听到的最大挫折就是：做大房间计划的时候，很多时候它就变成了一种承诺。你在季度初开始，他们之前没有做过充分的探索，因为你要记住，这些人没有接受过好的探索训练，所以他们并不真正知道自己应该做什么，很多时候也没有出去跟客户交流过。他们就是匆忙拼凑，搞清楚需要做什么。通常他们确实有一堆 backlog 里的事情需要处理，该做的总归要做。他们在一个大房间里把所有内容规划出来，做出承诺，然后这个季度就这样了。

他们问我：“那我什么时候做探索？“我说：“理想情况下，在那之前你就应该有一个愿景。你应该把它拆解，把探索融入那个愿景里，去跟客户交谈，把这些信息输送到里面。“然后我听到的是：“我们没有时间做这个，因为我们一个冲刺接一个冲刺不停地跑。“我问：“这是什么意思？“他们说：“作为一个团队，我们基本上就是两周冲刺接着两周冲刺接着两周冲刺地跑，我得确保开发者是满负荷的。我得确保他们有东西可以做。如果我抽出时间去跟客户交谈——而且去跟客户交谈本身也不是我作为产品负责人的工作，那是我的 PM 的工作——她会把客户的反馈传达给我，然后我把它拆解成功能点，再和开发者一起推进。“所有这些东西就是这样运转起来的。

低效的协作模式

组织在这里没有意识到的是，这并不是最高效的工作方式。我看到很多开发者几乎变得……怎么形容呢？依赖于 PM 或产品负责人来告诉他们该做什么。即使你给他们描绘了一个很好的愿景，解释了需要做什么，他们也会说：“哦，我没法做这个，因为产品负责人还没有给它排优先级。“然后他们问我：“如果我没有足够的特性工作让开发者做，他们应该做什么？“我说：“我保证有大量的技术债务他们可以去处理。你不需要把这些都规划出来。让他们自己选择最重要的内容。他们应该作为开发者和架构师一起协作，想清楚怎么处理那些技术债务，怎么着手去干，与此同时你再去搞清楚这是不是正确该构建的东西。”

所有这些东西加在一起，人们觉得自己没有时间，因为他们要参加无数的会议，而这些公司的期望是每个冲刺都要交付软件，去推进上个季度承诺的路线图，却不去检验这些方向是否正确，不去检验它们是否真的在帮助我们向前推进。很多时候，组织内部没有建立正确的反馈机制、正确的用户研究和正确的数据来告诉我们一切是否在正常运转，从而将这些信息输入到下一次发布计划中。他们就是不停地规划、规划、规划，拆解成冲刺，然后埋头干。

Melissa Perri： SAFe 并不擅长描述你怎么做那些其他的工作。在很多这类东西里，他们还往 SAFe 的地图上放了一些模块，比如说”你应该做 OKR”，然后解释”OKR 是这样的。你应该做路线图。路线图是这样的。“但所有这些环节如何协同运作——如何在探索和交付之间取得平衡并将信息回输入系统——在组织内部确实让人非常困惑。然后它基本上说的是，大量的探索工作落到了 PM 身上，而产品负责人向 PM 汇报。我看到的行不通的地方在于，你基本上把这些产品负责人变成了接单员。他们极其战术化，等到真正需要更战略性思考的时候，比如你想晋升为 PM，在一些组织中，那甚至不是同一条业务线，不是同一条职业发展路径。产品负责人走这边，PM 走那边，他们向不同的人汇报。

如果你想从产品负责人转到 PM，很多时候你根本没有机会积累策略方面的经验——去弄清楚客户想要什么、做拆解、看市场研究、判断这件事有没有价值、这是不是我们应该投入的方向。他们甚至没有机会接触或尝试这些，因为 SAFe 会说：“不，那是 PM 的工作。你的工作是深入下去，跟开发者一起干活。”

Lenny Rachitsky： 哇，好吧。作为听到所有这些细节、看着这张图的人来说，很多东西听起来相当荒谬。话虽如此，很多公司正在采纳这套东西。感觉它还在增长，越来越多的公司在采用它作为工作方式。我能想象背后的动机是我们只想构建优秀的软件，但不确定具体怎么做，而现在有这么一套流程可以拿来即用，能帮我们把这件事做起来。我想听听你对此的想法——你觉得它能奏效吗？是经常奏效还是经常失败？你对人们采用这套东西及其结果的观察是什么？

Melissa Perri： 我知道大量公司在八年前左右采用了 SAFe，现在已经弃用了。Capital One 刚刚公开宣布他们取消了所有敏捷角色、所有 Scrum 角色。他们是 SAFe 的早期采用者，现在不做了。他们在报纸上写了这件事。我看到这种情况越来越普遍。另外，在我们很多组织中，我也看到一部分业务线做 SAFe，另一部分不做。不同业务线之间情况不同。但我认为人们并没有意识到 SAFe 在外面的存量有多大。我每天在播客上都会收到关于 SAFe 的问题。每个人都问我：“我们为什么还在做这个？“原因就是你说的，高管们购买 SAFe，因为它是市面上唯一一个基本上给你画好地图然后说”即插即用，照着做就行”的框架。

这就是为什么大家都对它很兴奋——因为它是唯一一个把事情规定到这种程度的框架，他们一看就说：“哦，这是一个我能理解的东西，一个真正有定义的东西。“公平地说，作为营销工具，这对 SAFe 来说是一件很棒的事。 Bravo，他们创造了一个所有人都想要的东西，一个好卖的产品，但它用力过猛了。而这也是我不断从组织中听到的反馈——它基本上把领导者自己想清楚怎么做事的责任给拿走了。如果你是一个新晋领导者，刚刚被放到这个位置上，我对他们有很大的共情，因为确实，你从哪里开始？你怎么去管理一个技术组织？

有人来告诉我，CIO 来跟我说”现在你负责了”。你负责所有的开发者，或者你负责所有的 PM。那你怎么起步？我完全能理解为什么人们采用 SAFe，因为你会想：“哦，我一直在找这本手册。我一直在找这里该做的事。“问题在于它只解决了谜题中的一小部分，就是把那些团队聚在一起。人们确实说它在这一点上做得很好，但它也没有告诉你作为领导者该怎么做好你的工作，这些它全都略过了。他们在 SAFe 里也谈到了产品组合愿景和产品组合管理，但更多时候，我走进去发现产品负责人和 PM 之上的所有人——我们说的产品总监、产品 VP——他们不知道作为产品 VP 或产品总监应该做什么。就像”我的角色是什么？我应该在这里输入什么？”

SAFe 里甚至没有这部分内容，那甚至不是一个角色。从 PM 往上到那些层级的内容基本是空白的。当你在组织中拥有一整条产品线时你该做什么？当你是一家银行信用卡业务的产品负责人时你该做什么？对吧？我的工作是什么？它没说。我在这些组织中合作的很多人，我会跟他们说：“你应该做策略，策略是这样做的。这样去跟客户交谈。这些是我们在软件中的模式。你在做平台策略吗？你需要 API 吗？你怎么思考你的应用策略、怎么推进上线？你怎么在这里做这些事？“所有这些东西不是来自工作方式层面的——而 SAFe 做的就是工作方式层面的事。它关乎的是你在那些领域怎么做好自己的工作。

很多采用 SAFe 的组织没有意识到，你需要一位产品负责人——我说的是 head of product——需要有人真正把愿景一路往下传递，确保它在各团队间拆解得当，把控产品组合愿景，把所有这些事情做到位。我并没有看到 SAFe 在被采用方面有放缓的迹象，我看到越来越多的组织在采用它。我觉得我们在硅谷也会想当然，不知道有多少人还处在数字化转型旅程的起点。有大量的制药公司、银行、保险公司，他们把开发外包出去，或者有一个 IT 团队，但以前从来不需要真正去想这件事，因为数字化没有现在这么重要。现在他们不得不想了。

这些公司中，大部分是财富 50 强企业，对吧？财富 100 强企业。至少我看到的很多银行——他们很早就意识到，“嘿，说到应用以及人们如何与我们的产品交互，软件很重要”，但还有很多公司没有赶上那趟车，他们才刚刚起步，然后转向 SAFe 这样的东西，因为它给了他们一条指南。“嘿，我以前从来没做过这个。我在这家银行待了 40 年。我只知道瀑布式开发。我们该怎么办？“然后他们说：“去看看 SAFe。“

如何真正做好数字化转型

Lenny Rachitsky： 我很高兴我们花了时间讨论这个话题，因为我觉得它真的很重要。你可以对这一切嗤之以鼻，觉得”这些人到底在想什么？简直疯了”，但正如你所描述的，人们只是有一个需要解决的问题，他们以前从来没做过这件事，于是去寻找解决方案，找到了一个看起来对的东西，看到别人也在这么做，就说”好吧，我们试试这个。“而你观察到的是，SAFe 那套特定的做法很少真正奏效。

我觉得有几种方式可以帮助这些人。一种是针对那些正在做敏捷转型或数字化转型的人，你对如何真正做好这件事的建议。然后我还想谈谈，如果你是一个身处这样运作的组织中的产品负责人或 PM，你能做什么？也许我们先从第一个问题开始。假设有人正在想”我们需要做出更好的产品，有些地方不对劲”，SAFe 是一个选项，而你的建议可能是别走那条路。那人们应该怎么做？我知道你没法用简短的回答给出完整的答案，但总体来说，人们应该怎么思考这件事？

转型的关键在于产品运营模型

Melissa Perri： 是的。当我和公司一起做数字化转型时，你需要的是一个开发运营模型。这也是很多敏捷方法论最初诞生的根源。你要明白，那只是开发运营模型，它并不能真正帮到你的市场推广、产品发布和产品管理。我给公司的建议是，首先坐下来想一想：“我们怎么构建自己的运营模型？“当我思考产品运营模型、与公司一起做这件事时，我们会拆解出几个方面：你怎么确定产品策略？你有没有一个好的产品策略？然后看你的组织设计——我们围绕产品的组织方式是什么？我们的产品经理覆盖得好不好？我们的产品经理在整个组织各个层级是否都具备足够的能力？

接下来要看产品运营。我们有没有支撑这些团队的基础设施？他们能不能拿到数据来做决策？他们能不能真正接触到客户？很多大型组织实际上并没有把这些赋能产品经理和开发团队成功的步骤想清楚。他们没有让团队去和客户交谈的途径，所以他们才不做这件事。我对这些组织中那些因为官僚体系或周围环境的制约而无法做好产品管理的人也有很多同理心。领导者需要解决这个问题，对吧？他们需要理解这个角色是什么，需要为团队打开通道。

然后我们还要审视文化和激励机制。我们是不是只是在奖励人们尽可能多地发布东西——“嘿，把所有能塞的东西都塞进那个发布列车或 Backlog 里”——还是我们会回过头来问：“嘿，这有价值吗？这跟我们业务挂上钩了吗？“很多组织没有一个好的产品策略，我合作过的很多大型组织都是如此。关键在于把事情跟价值联系起来，跟”这是否能达成我们的公司目标”联系起来。如果你是一家庞大的组织，假设每年营收几十亿美元，而你的目标是拓展地理版图，那么你在产品组合里做了什么来真正支撑这个目标？你在打造什么产品来实现地理扩张？太多组织甚至没有足够的透明度来看到这些。

流程不是敌人

有一件很荒唐的事——很多人对大型组织在流程上花心思这件事批评得很厉害，我知道 Marty 也是这样——觉得流程就是问题所在。我不认为流程是敌人。比如，如果我听到有人真的在担心要不要引入一个路线图工具之类的，我会说”是的，你需要它，因为你根本不知道你那 4000 个团队在做什么。“如果他们真的要回溯到业务目标，你没有任何基础设施能够看到那种透明度。这类基础性的工作对于转型、对于一个组织围绕软件产品管理搭建起来是绝对必要的。你必须拥有透明度才能真正看到这些事情。

你确实需要有足够的流程，使你作为一个组织能够高效地把东西推上线，我觉得这也是 SAFe 试图做的事情，但它没有奏效，因为它没有解决产品管理的问题，也没有解决将价值与产品团队连接起来的问题。相反，产品管理被视为一个几乎像保姆一样看管开发者、或者告诉所有人该做什么的角色。探索在哪里？这些东西从哪里来？我知道 SAFe 的那张图上，他们试图把 Lean UX 之类的东西塞进去，Jeff Gothelf 觉得这很滑稽，但它并没有真正把所有东西整合起来——我们怎么按节奏做这件事？我们怎么帮助人们走出去真正与客户交谈？我们怎么赋能他们去做这些？

不要忘记职业路径

如果你正在启动一个转型，不能只考虑怎么构建产品，还应该考虑怎么发布产品，怎么确保这是正确的产品。这才是关键所在，也是所有产品策略发挥作用的地方。你还应该审视职业路径。这是敏捷转型中让我非常困扰的地方，也是 Scrum 和 SAFe 让我困扰的地方——当我们在大型组织中按照敏捷团队来组织时，我们创造了一大堆叫”产品负责人”的新角色，而很多组织没有为他们设计职业路径。所以他们给我发邮件问：“我的职业路径是什么？我接下来该做什么？我应该往哪里去？”

十年来我一直在说，这不只是一个团队角色，它是一个业务角色，它一路往上延伸，帮助你推进业务。你必须确保团队中的人可以晋升到管理多个团队，可以晋升到管理整条产品线。在我们硅谷的原生软件公司看来，这是再简单不过的事，但在其他组织中仍然闻所未闻。还有一个问题，这也是我觉得领导层和 C 层高管需要真正关注的地方——因为我们正在转向这种新的工作方式，我们之前的一些角色现在已经不适合了。也许我们不需要那么多的项目经理了，也许那些过去决定我们做什么产品的业务人员，他们是不是适合带进产品管理的下一个阶段？他们能学会吗？他们能理解软件吗？他们懂这些东西吗？这才是我们需要追问的。

组织有时候很害怕把这些职业阶梯放进去，因为这几乎颠覆了他们传统的工作方式，然后他们有在公司待了 40 年的人，现在你跟他说”嘿，其实不是你负责这件事了，是产品经理负责这件事”，这很可怕。很多人正因为这个原因成为阻碍。但如果你真的想转型，C 层必须站出来说”我们要往这个方向走”，把它定下来。因为我见过太多由中层管理者主导的转型，而当你开始转型、需要重新培养技能、需要想清楚怎么做的时候，中层管理者的岗位往往是最岌岌可危的——他们不愿意面对这件事。他们不会是那些跳起来喊”嘿，我们干吧”的人。

关于 SAFe 的立场

Lenny Rachitsky： 我想从你刚才分享的内容中提取几点。首先，明确一下，你建议不要使用 SAFe，你认为那不是一个好的方法？

Melissa Perri： 我确实不建议使用 SAFe。是的。

Lenny Rachitsky： 好的。

Melissa Perri： 有人喜欢 SAFe。我想说明一下，确实有人从 SAFe 中获得了成功。但每一个我交谈过的、声称喜欢 SAFe 并从中获得成功的人，最终都把它拆掉，改造成了别的东西。那实际上已经不是照本宣科的 SAFe 了。如果你这样做，没问题，任何流程都可以这样。如果你最终采用了 SAFe，然后回过头来看，说”实际上我们去掉那些不奏效的部分，保留有效的部分”，那可以，但你要愿意承认——这不是我们做好产品管理的方式。SAFe 中关于做好产品管理的内容并不多。这一点我们必须理解。它可能在某些方面有帮助，我也确实认为它在某些方面能带来一些规范性，但如果你走得太远，它会造成破坏。

实际上有一个很好的故事，关于荷兰的一家水务公司，他们决定采用 SAFe，几个月前上了新闻。他们决定在 IT 团队中采用 SAFe 并开始使用。结果他们破产了，破产的原因是团队在学习 SAFe 的流程上花费了太多时间，他们的新计费系统和收款系统部署得太慢，以至于无法向客户收取费用，因为他们深陷在流程之中。

流程与目标的错位

这就是我在很多组织中看到的情况。我们没有在谈论真正重要的事情——“嘿，我们怎么服务客户？我们怎么在这个市场中取胜？我们怎么遏制流失？我们怎么做所有这些事情？“——反而在谈论”我们在做什么站会？哦，我们怎么做这个发布计划？天哪，你们没有连续冲刺，你们做错了。“我们在谈论关于工作的工作，却没有真正触及我们到底在达成什么。这就是我不喜欢僵化流程的原因。

Lenny Rachitsky： 这触及了我想提出的另一个主题——感觉这些东西像是 skilled、有才华的人、懂得如何做这些事情的产品领导者的替代品，一个有产品品味、能组织团队打造出色产品的人。感觉大家只是在想”我们没有这样的人，所以我们要创造这个流程。这个流程会解决我们所有的问题。“你能谈谈人的重要性吗？你招聘来运营这些事情的人是否是关键所在？如果确实如此的话。

人才与流程的关系

Melissa Perri： 在很多组织中，购买 SAFe 的人之前并没有运营过大规模技术组织，或者他们对这种工作方式很陌生，所以他们采用了 SAFe，希望它能奏效，因为正如我们所说，它看起来像是一个不错的计划，可以去执行各种事情。当你进行转型时，很多公司是第一次把人放进这些角色里。我从第一天起就和公司合作时就一直在说，想要培训人才、把他们放到不同角色中，这是可以的，我认为这也值得尊敬。如果你要花钱提升员工的技能，那就做吧，但你也必须穿插一些知道自己在做什么的人。我认为在领导层面，引进一个知道该怎么做的人来帮助运营这类事情非常重要。

现在有更多的人、更多的领导者之前做过这件事，因为我们已经做了十年了。Shruti Patel，她是 US Bank 小企业银行的首席产品官。我刚邀请她上了播客。她在 Shopify 工作过，见识过优秀团队的运作方式，然后她能够来到银行帮助应用这些经验。她是有经验的人，对吧？她是一个经验丰富的产品人，进来帮助推动变革。Melissa Douros 是 Green Dot Bank 的首席产品官，她曾在 Discover Financial 主导那里的转型，完成了所有那些工作，然后能够把它带到 Green Dot Bank。她能看清需要做什么，这里实际上需要发生什么。

我们有越来越多的做过这件事的人，他们正在寻找机会在银行这样的环境中去做。我认为 C 层高管引进这些人来审视情况非常重要。在我见过的所有组织中，转型最成功的地方都是做到了这种混合——保留一部分自己的人，同时也引进人来学习。我经常被请去做培训。到目前为止，我几乎和每一家财富 50 强公司合作过，财富 100 强也是。我进去，培训很多产品经理。我们通过 Product Institute 来做这件事，培训所有人。大约八年前的情况是，他们培训所有人，然后说”去吧”。请了咨询师做完培训之后，你往哪里去继续学习？如果组织中没有做过优秀产品管理的人，他们怎么看到别人在组织中做出色的产品管理？

幸运的是，我认为很多组织意识到了这一点，所以越来越多的领导者在说”嘿，我必须在这里穿插技能。我需要引进一些更有经验的总监，一些更有经验的个人贡献者。“我认为这些组织非常成功，因为他们认识到了这一点，说”我必须确保人们能从他人那里学习。“这就是你持续发展的方式，也是我们所有人持续发展的方式，不仅仅是上外部课程。我认为正是在这些地方，事情才变得真正强大。你可以在各个层面都这样做。你不必只在团队层面做，你可以在总监层面做，也可以在 VP 层面做。这才是我们应该思考的方向。

大型组织中的领导者学习与成长

Melissa Perri： 现在，有一些大组织的 CPO 和产品 VP 对这种工作方式还很陌生，但他们已经决心学习，努力弄清楚如何做到最好。他们不是在说”嘿，我就采用 SAFe，或者随便这边有什么我就用什么”，他们真正在问的是”我有什么不知道的？“我看到他们主动去找其他 CPO 交流，做各种各样的事情。他们通常拥有出色的市场知识、出色的业务知识，在战略方面也非常强，然后在下面招聘擅长其他部分的人，比如执行和软件交付。我认为这些人也会成功，因为他们注意到了自己的技能缺口，并像任何优秀的领导者一样为此进行招聘。

在这些组织中，我确实有时看到 SAFe 对于那些不知道自己在做什么的人来说成了一种拐杖，被拿来支撑。如果你真的去思考”嘿，我如何让这一切变得更好？“并且拥有持续学习的心态和推动前进的意愿，我认为你会考虑其他选择，开始思考比 SAFe 更广泛、比敏捷更广泛的东西——我们需要什么才能让这一切成功？

产品管理与 Scrum 的关系

这其中关键的一点是认识到，产品管理不仅仅是 Scrum 中的某个角色。我在我的演讲中也说过，我说把 Scrum 拿走，你仍然需要产品管理，对吧？产品负责人没有 Scrum 就不存在，这不是一个独立的东西，但你仍然需要产品经理，这就是为什么所有产品负责人都应该是产品经理，他们从根本上就应该是产品经理。这就是为什么我不喜欢那些将两者分开的职业发展路径。当然，如果你想设一个首席 IC 产品经理，就像硅谷很多大公司做的那样，很好，让人们继续在这些方面工作。他们不一定要进入管理层，但这并不意味着他们是不同的。一个 IC 产品负责人和一个 IC 产品经理之间不应该有区别。

Lenny Rachitsky： 完美的过渡，正好引向我想聊的下一个话题。假设你现在就是一位产品负责人，正在听这期节目，你说”天哪，这完全就是我的生活”，对于处于这个角色中的人，你有什么建议，关于如何可能成为产品经理，培养他们所需的技能，而不是仅仅困在一条没有前途的职业路径上？

给产品负责人的建议

Melissa Perri： 我认为第一件事是要意识到，你的角色不仅仅是和开发者一起工作。很多领导者跟我争论说我们需要产品负责人，因为它就是没法扩展。你见过那些规模巨大的公司，他们没有任何产品负责人。我不理解这一点。对我来说这是一个站不住脚的论点，非常站不住脚。它只是意味着你不知道如何均匀分配工作，给产品负责人——或者产品经理——一点点战略指导，让他们能够在团队中构建愿景、裁剪功能等等。如果你是一个产品负责人，你会说”嘿，我没有机会和客户交谈，那是产品经理做的事，我只是和团队一起工作。我想更有战略性，我想思考更长远的东西”，我会说试着在这方面主动承担一些责任，对你被分配的工作提出质疑和挑战。

早年我在 Mind the Product 做一次工作坊，我的工作坊里有一位产品负责人，她说”我觉得我们在做的东西不是正确的方向”，他们当时在做 SAFe。我说”你应该把这个意见带给你的经理”，她说”我不知道。我可能会被开除。我觉得它不是正确的方向，但如果我们不做什么这个，我还能做什么？“我说”嗯，这就是产品优于项目之美妙之处，我们始终与产品在一起。“你的项目结束了并不意味着你会失去工作。她整理了一份完整的材料，去找领导说”我认为我们不应该做这个”，然后他们晋升了她。他们说”太好了。“她迈出了这一步，开始发声说”还有更多要做的事情。我们需要做更多。”

我认为如果你是一个产品负责人，面前没有职业路径，那就开始问领导者你的职业路径是什么，因为这会让他们去思考”哦，好问题。职业路径应该是什么？“关于如何制定职业路径，外面有大量文献，你可以从那里开始。问问在这个产品负责人角色之后你的下一步是什么。如果产品经理在做所有的客户研究，去问他们能不能和你一起做客户研究。去旁听这些。很多人会说”我没有时间。我没有时间做这个。“把你手上所有那些用户故事减掉一些，别再把它当成一个只需要不断上升的量化指标。相反，真正去思考你和你的团队正在交付的价值。这是正确的事情吗？

当你和领导者沟通、陈述你的观点时，你这样说：“嘿，我正在做 X、Y、Z 功能。这里的目标是什么？当我们发布这个的时候，我们希望发生什么？“我认为这是任何人如果担心自己的公司没有聚焦于成果时能问出的最好的问题。当我们发布这个时，我们希望发生什么？我们要改变什么指标？我们如何设置监测来确保这一点成立？然后我们可以回头去看它是否真的改变了。仅仅一个简单的问题就能让大家对齐目标，然后你就可以开始说”哦，那个没有效果”或者”这个有效果”。太好了。为什么有效果？你可以开启这些对话。

自下而上推动变革

我想说有很多事情你可以做来帮助推动你的公司前进，而且我在很多组织中也看到过，产品负责人和产品经理形成了一股自下而上的力量，说”嘿，我的下一步是什么？到底怎么回事？“这会促使组织去想办法解决。不久前我在和一家财富 10 强公司合作，他们的 C 层高管，我已经和他们合作了很长时间，他们终于说”嘿，我们要规范化产品经理这个角色，让它在整个组织上下都存在，我们要定义角色，明确职责。“对我来说这简直是天籁之音，但他们这样做的原因也是因为他们注意到这个角色的人员流失率很高，而且他们也意识到这是一个关键角色。

他们在流失优秀的人才，因为外部的人想加入这家做得非常好的大组织，太好了，但他们进去之后说”我的职业路径在哪里？我应该做什么？我应该往哪里去？“现在很多领导者意识到”嘿，我们确实必须把自己的事情理顺”，他们得出这个结论的另一个原因是他们环顾四周看到其他人在这样做，他们从团队那里听到，从产品经理那里听到。我不想让人们觉得”嘿，我没有任何力量。我在一个一万人的组织里。“你越是提出这些问题，你的领导者就越会重视它，因为他们不想失去你，他们不想失去优秀的人才。如果你想在你的工作中做到出色，需要更多的支持，那就发声，发声。

寻找更好的环境

Melissa Perri： 在某个节点上，我确实会告诉人们这一点。如果你觉得自己在当前组织里无法做好产品管理工作，试着去找另一个组织。我知道这话很难说出口，我也理解人们受制于保险等各种现实因素，换工作不容易，但如果你确实有机会去寻找一个做得更好的组织，我会去那里。我也想说，在大公司里也是如此，我看到过某些业务线和某些部门做得非常出色，而其他部门则不然。如果你在一家大公司里，也许可以考虑内部横向调动到另一个团队，看看能不能去那里工作。找到那些知道自己在做什么的领导者，去为他们工作，这通常是最好的选择。

Lenny Rachitsky： 你提到的那个观点——很多公司根本没有产品负责人却规模做得很大——我想再强化一下，我们之前做的关于就业市场趋势的数据分析显示，基本上没有科技公司有产品负责人这个角色，没有哪一家顶级科技公司有。我知道这里有一个重要的区别。这些是以技术为先、产品为先的企业，它们的业务就是自己开发的软件，而我们这里讨论的很多公司不是这样的。它们是银行、电信公司、制药企业。我理解这是一个非常不同的世界，但我觉得很重要的一点是要强调，“你可以做得非常大。“据我所知 Google 没有产品负责人，Amazon、Microsoft、Netflix，你能想到的科技公司都没有产品负责人这个角色。他们全都是产品经理，全都是产品经理。

产品负责人的简历该如何写

Melissa Perri： 是的。我不想让人们觉得这些大公司里没有人在做优秀的软件，因为确实有。有那么一群一群的人在做得非常、非常好。如果你是其中之一——一直在推动边界、做出优秀工作——而你的头衔是产品负责人，我总是告诉人们，在你的简历上，如果你在找下一份工作，这样你就不会被打出那些大公司——比如 Google 或类似的地方——如果你想去科技公司工作的话，一定要确保你从价值的角度来描述你是如何工作的。不要谈论你的敏捷节奏。把 Scrum 从简历里去掉。谈论你为用户带来了什么价值，你推动了哪些指标，你的简历应该这样来组织。

我确实阅读过大量简历来招聘人员，作为首席产品官也是一样。如果我一眼看到”在全组织范围内实施了 Scrum 流程”，我就想，“不，这不是我需要的。这不是我要找的。“我要找的是你打算怎样推动那个部门的战略？你打算怎样真正为客户打造更好的产品？等你到了面试环节，你可以谈你具体做了什么来实现这些，但你要确保自己的重点在于真正理解客户并将其转化为优秀产品，以及我们在做的过程中所追求的成果。在简历上这样做，我觉得很重要。

产品负责人与产品经理的核心区别

Lenny Rachitsky： 好。我想在这里多花些时间，因为这太重要了。这里凸显出来的就是产品负责人和产品经理之间的区别。如果你想进入产品管理领域成为一名优秀的 PM，如果你现在是一名产品负责人——即使你不是产品负责人，只是想进入产品管理——你能再强调一下最大的区别是什么，以及人们在 PM 身上最看重的技能是什么、和产品负责人有什么不同吗？

Melissa Perri： 好的。当我看到产品负责人写简历或描述他们的工作职能时，他们总是从流程的角度来切入。我优先排列了 Backlog，我和开发人员一起拆解工作，我检查了开发人员的工作成果并制定了验收标准，我写了用户故事（User Story）——这些职能就是我在产品负责人的简历中一遍又一遍看到的内容。而你应该做的是说，“我主导了——“我们甚至可以拿登录 API 举例——“我主导了登录 API 相关的工作。我要解决的问题是通过增强登录协议的安全性来满足监管要求。我访谈了大量用户，我深入了解了监管要求，我和法务团队、合规团队紧密合作，将这些转化为能够保障我们银行安全的方案。上线后，我们满足了合规要求，为银行节省了几百万美元，并且在服务四百万客户的过程中平滑过渡到新的安全要求，没有造成任何服务中断。”

这和”我优先排列了 Backlog 然后把需求交给开发人员”是完全不同的故事。再进一步，如果你在做面向客户的东西，你的客户是谁？你有没有走出去和他们交谈？“通过与客户接触并理解他们，我解决了 X、Y、Z 问题，这带来了可量化的 X、Y、Z 业务指标提升。我运营了这个功能，我推出了这个功能，我从头到尾跟进，我不断迭代，我做了让这一切成功所需要做的所有事情。“这才是我想在简历上看到的。

即使你的头衔是产品负责人，我依然会读你的具体描述，其他人也会。但我得说，这个头衔有时会带来不太好的联想，这很遗憾，因为 agile 这个词附带了很多包袱。哪怕只是在简历上，我建议写上”产品负责人/产品经理”这样的组合，让别人知道我知道怎么做这件事，而且一直做得很好。如果你在要点描述中这样做了，同样也能体现出来。还有一个我们甚至还没涉及到的话题，就是认证。人们一直问我，如果我想转行做产品管理，我应该考一个认证吗，一个敏捷认证？“我觉得这些东西在几年前更大行其道，但到现在仍然很流行。如果你曾在某人的个人简介末尾看到 CSPO，你可能在 LinkedIn 上见过，它就是认证 Scrum 产品负责人（Certified Scrum Product Owner）。

敏捷工业复合体

现在有一点要记住，这关乎所有敏捷相关的东西——我们称之为敏捷工业复合体（Agile Industrial Complex），敏捷教练、敏捷培训师，整个 Scrum 体系——scrum.org、Scrum Inc、SAFe，所有人——他们赚钱的方式就是通过咨询来教你这些流程，以及让人们接受培训获取这些认证。他们走进来说，“你们所有的人都需要成为认证 Scrum 产品负责人。每人交 2500 美元，“然后在两天课程结束后拿到一张证书，说你是一名认证 Scrum 产品负责人。这并不一定意味着你能胜任这份工作，不一定意味着你能做产品管理。但当我们讨论要不要采用 SAFe、要不要采用这些东西的时候，想一想这些组织是怎么赚钱的。

他们在卖认证。当然他们希望越来越多的人采用。道理就在这里。他们卖给你一个梦想，说你只要让所有人都获得认证，然后就可以运转起来了。他们把所有这些人拉去上两天课之类的，然后把他们推出来，说”去吧，你现在是一个全新的角色了。“事情不是这么运作的。这不符合你公司的最佳利益，也不是我们真正想要的结果。这就是为什么所有这些事情都需要更深入地去思考。如果你上过 CSPO 课程并拿到了那个认证，它可能有助于你进入另一家正在采用 Scrum 和 SAFe 的大型企业。在那边大概能帮到你。

证书不等于能力

Melissa Perri： 如果你想转型进入科技行业，进入我们谈论的那些公司，他们看了这个证书很可能说，“这个人不知道自己在做什么。这不算什么。“如果你确实知道自己在做什么，而且拿那个证书是有原因的——因为有些人需要它来升职，有些公司确实要求这个，这很疯狂，但为了升职或者担任那个角色——我对此深表理解。但你在转型时需要在简历等材料中做大量工作来解释你远不止于此。你不只是一个上了两天课的 CSPO，你确实做了实实在在的工作。这就是为什么在简历上逐步积累这些经历变得非常、非常重要。这不仅仅是拿证书。

有人问过我，“你能不能直接认证产品经理？“我说，“不行。如果有人上我的课，我会给他们一张结业证书，仅此而已。“就像任何其他课程一样，你完成了一门课。但我不会去认证产品经理，因为我不认为你可以通过一个短期课程就说某人已经准备好了、能够胜任这份工作。当然，有一些敏捷机构做的培训要深入得多，设有不同级别。他们的做法是培训人员，然后让他们去做实际工作，配备一名教练与他们对工作，来回反复，他们需要能够在一段时间内展示自己确实能胜任工作，才能达到下一个级别。

这有点像 PMP，项目管理认证，你必须有实际工作经验才行。那是不同的，是一种不同类型的技能，不同类型的认证。但如果你看到任何 CSPO，通常就是参加了一个两天的工作坊然后拿到认证。这就是区别所在。我想说的是，如果你是一名产品负责人想成为产品经理，要小心只靠证书这条路。我了解的所有大型科技公司，招聘时不会看产品管理或产品负责人的认证，他们看的是经验。但那些可能不太知道自己在做什么的组织，他们确实在找 CSPO，在找那个证书。

如果你的组织要求这个，你可能需要问一问，“我们在这里真的能做好工作吗？这是我能够学到如何成为更好的产品经理的地方吗？“不过我也为人们感到惋惜，因为做产品经理很难，入门也很难。我对此很纠结，因为确实有些组织招聘时要求 CSPO，所以当然，如果这能帮你入门、帮你得到这份工作——但如果它帮不了你，也不能把你放到你想走的职业路径上，我觉得这笔钱不值得花。

Lenny Rachitsky： 我认为贯穿这整个对话的一个有趣线索是，几乎没有哪个即插即用的简单方案能解决你的问题——无论是接入 SAFe 就能帮我们构建出色的软件，还是上堂课就能让你成为优秀的产品经理——对这类东西要保持怀疑。

Melissa Perri： 没错。做这些事情没有捷径，没有快速通道。你不可能跳过所有那些困难的部分。

Lenny Rachitsky： 是啊。真遗憾。

Melissa Perri： 是啊。我也希望有。

产品负责人还是产品经理？

Lenny Rachitsky： 有一个问题我想澄清一下。当你进入一个组织，他们有产品负责人，你是鼓励他们去掉产品负责人这个头衔和角色，让他们变成产品经理，还是保留产品负责人？

Melissa Perri： 我认为应该有一个层级体系。团队里全是产品经理，他们是 IC（个人贡献者），所以可以是助理产品经理（Associate Product Manager）——如果他们还没有掌握所有探索（Discovery）方面的经验，或者他们只懂基本的 Scrum，完全没问题，你可以做助理产品经理。但如果他们不知道如何与客户交谈、消化客户说的话并将其转化为特性方向和 Backlog，不知道我们该怎么做这些工作——所有这些都需要掌握。如果他们不知道应该如何度量事情，那你还算不上产品经理。

助理产品经理，然后是产品经理，再然后是高级 PM。高级 PM 也可以在 Scrum 团队或开发团队中工作。我确实鼓励他们这样做，我会说，“去掉这两种不同的头衔，因为它把所有人都搞糊涂了。“我也帮很多人设计职业路径。我见过有的公司有 47 个不同的产品经理头衔——这个组织里有人叫产品助理，那边有人叫产品经理，那个人是平台产品经理，那个人是平台产品负责人，这个人又是 API 产品负责人。你可以有产品经理、高级产品经理等等，但我不建议用产品负责人和产品经理这两种不同的头衔把人搞糊涂。

Lenny Rachitsky： 但关键的是，对于谁能被称为产品经理是有门槛的，因为如果你把一个产品负责人直接说成产品经理，按你之前说的，他们会是一个糟糕的产品经理。你的建议是让他们先做助理 PM，等达到一定水平后再晋升为产品经理。

Melissa Perri： 这要看情况。我不会把这当作一条死规矩，因为确实有产品负责人把工作做得非常好。仅仅因为他们有一个产品负责人的头衔，并不意味着他们不能做产品经理的工作。很多人只是因为公司给他们起了这个名字，但他们知道自己在做什么——所以不要一概而论。当我们做这件事的时候，通常会先说每个人的头衔上都是产品负责人，把它改成产品经理，但我们会回过头来看实际的技能组合是什么。

产品转型的真实故事

当我进入公司帮助做转型的时候，通常的做法是这样的——我被引入的方式通常是，他们来找我寻求针对所有产品团队的某种培训，然后我们引入 Product Institute 做在线培训。培训结束后，我会与组织一起工作，我说，“既然所有人都已经统一了基线并接受过培训，我们就要弄清楚谁会成为优秀的产品经理、谁不行。“这样大家就有了一个认知。你知道有意思的是什么吗？一旦人们搞清楚了这个工作到底是什么，很多人会主动退出。

我在 Athenahealth 做转型的时候，我们有 365 名产品经理，他们的头衔也各不相同——产品创新什么的，五花八门。我们把他们都改成了产品经理，培训了所有人，给每个人学习的机会——我觉得这很好——然后我们给他们机会去实践技能。结果到了培训结束时，很多人举手说，“哦不不不，这不是我想做的。我以为会很不一样。我没意识到有多少人际沟通方面的工作。我得去影响那些人，我得做所有这些事情。这其实不是我想要做的。“

人员分流与角色调整

我们为这些人找到了符合他们意愿的其他角色，或者他们自己选择离开。这由他们自己决定，我们没有裁掉任何人。我们把一些人调到了运营岗位，因为他们更想埋头做事，钻研流程——那就是他们的兴趣所在。我们把擅长 SQL 和数据分析的人调到了数据岗位。我们把想和客户交流但不想承担产品管理带来的责任和问责的人调到了用户研究岗位，因为他们意识到这个工作强度太大了。

我在大型组织中见过很多这样的情况。你给所有人统一基线，向他们展示这个角色是什么样的，然后让他们去实践。到那时，一些人会选择退出，然后你需要重新审视你的人员，说：“好的，我们现在怎么重新校准水平？谁做得很好？谁做得不太好？哪些团队需要有经验更丰富的人加入，因为团队里没有人可以学习？“这时候我们就会说：“嘿，让我们在这里招一些 IC，或者招一位产品管理总监，来帮助培训这些人，帮助他们持续成长。“这个做法非常成功。我见过有人引进更多的总监，分散到各个团队，他们提升了那些原本做得不太好的产品负责人，现在这些人表现得非常出色。

在这些不是天生做软件或者正在进行转型的组织中，我见过非常出色的领导者。找到合适的人，你就能培养出优秀的产品经理。给他们一到两年的时间，就能彻底扭转局面。这完全可能。完全有可能培养人、训练人，我坚信这一点。但你必须让他们接触到什么是”好的标准”。如果你在一个组织中，到处都看不到”好的标准”是什么样，那就是一个危险信号。这时候领导者需要审视自己的组织，说：“我是否有具备这些技能的人分散在各处，让每个人都能开始学习，让每个人都能真正走上提升之路，确保我们的团队结构是平衡的？”

Lenny Rachitsky： 这个补充非常精彩，非常有深度。我回顾了一下我们讨论的所有内容。我们涵盖了很多话题——敏捷、Scrum、SAFe 和产品负责人的历史，还有关于作为公司领导者、作为产品负责人、甚至作为考虑在产品管理领域发展的人如何做得更好的各种建议。还有什么我们没有涉及到的、你觉得值得谈谈或者作为总结的？

敏捷的本质与反思

Melissa Perri： 我想告诉大家的是，当你审视敏捷方法论时——如果你看的是小写的敏捷（agile），我们真正在说的是我们希望能够快速行动、为客户创造巨大价值。如果你拥抱这些原则，你就会做得很好。但如果你把敏捷看作一个定义好的、刻板的流程，认为必须遵循每一个细小的步骤，那它不会对你有帮助，因为你没有回到”我们为什么要做这件事”这个问题上。

有一些非常优秀的敏捷教练。他们以第一性原理的方式来做好产品工作和开发工作。他们存在是因为他们不只是为了卖 Scrum，他们是为了让人们变得更好。我认为这些敏捷教练可以打造出非常出色的团队，我与很多这样的人合作过，我认为他们真正的目标是让工作环境变得更好，帮助公司产出更好的产品。这就是他们的全部目标。

但也有一些人对流程的死板遵守到了执迷的程度——“这就是 SAFe，你必须照着书做”、“这就是 Scrum，你必须照着书做”。对此我会非常警惕，因为最终目标是什么？他们的最终目标是什么？就像我说的，很多人靠给人做认证和就这些流程做咨询来赚钱。麦肯锡为此建立了一个庞大的部门，很多 SAFe 实际上是通过麦肯锡和类似的大型咨询组织引入企业的。他们走进来说：“对，你就这么做。我来教你做 SAFe，我来教你做 Scrum。“他们一直在靠敏捷转型来支撑自己的咨询业务。

当我与其他做转型和教练的人交流时，我们总是笑着说：“为什么麦肯锡总是跑来做这个？“我跟在他们后面进了太多组织，然后感叹：“哇，他们搞砸了，让我来收拾。“有句老话说，雇麦肯锡不会有人被开除。麦肯锡很大，人们信任他们的品牌。但麦肯锡里很多人之前并没有做过这件事，他们从来没有深入组织内部去做转型并长期留在那里。这就是为什么我对谁在推销这些东西会非常警惕。

回归敏捷的核心价值

如果你从”我想变得敏捷，因为我想快速发布产品、从客户那里获得反馈、确保产品很好”这个角度来对待敏捷，用同样的标准审视你的所有流程，问自己：“这是否符合我们公司和文化以及客户的最大利益？这是否让客户为我们感到自豪？这是否帮助客户获得了好的价值？“如果你的流程做不到，就去修复它、改变它，检视并调整——这是一个小写的敏捷原则。我们应该审视自己做的每一个流程，问”它有效吗？“并且不要害怕去改变它。

Lenny Rachitsky： 我认为很重要的一点是强调这是可行的。有办法重新组织你在大型公司中构建产品的方式，让你能够持续交付出色的产品。你见过很多这样的例子。在这一点上还有什么想补充的，给大家一些希望？

大型组织的数字化转型希望

Melissa Perri： 有的。我从大型组织那里听到最大的反对意见——特别是那些不是天生做软件的公司，比如银行、保险公司等等——就是”我们不是 Google，我们不是那些 SaaS 公司”。没错，你确实不是 SaaS 公司。你做事的方式会和 Amazon 运营的方式或 Google 运营的方式有所不同。我没见过多少公司实际上以相同的方式运营，而且仅仅因为某个方法在 Google 有效，并不意味着它就适用于一家有一百年历史的保险公司。这没关系，但你仍然可以从那些大规模生产软件多年的人身上学习。你仍然可以学习是什么让他们成功，然后你可以把其中一些原则应用到你的组织中，再找出哪些地方需要调整。这是我会去看的。

我看到软件战略和数字化战略正在与公司的整体战略深度融合，无论你是保险公司、银行还是其他什么类型的企业。它们正在与 C 层高管的战略紧密交织在一起。我首先要说的是——也是我看到很多公司在这方面挣扎的一点——你必须确保这个问题在 C 层高管层面被认真对待。有些组织会说：“哦不，那是 IT 的工作。我把所有软件战略往下推就行了。“如果你这样做，你就错失了创新的机会。这就是产品角色发挥作用的地方，也是为什么我认为更多组织需要 CPO（首席产品官）——因为他们是 C 层高管中那个会说”软件如何能让我们好十倍、碾压竞争对手——无论我们是银行、保险公司还是制药公司？我们能用软件做什么来领先于竞争、领先于市场？“的人。

如果你在思考公司长期战略时没有进行这些对话，你就落后了。你之所以落后，是因为每一个试图颠覆这些大公司的小型高增长创业公司都在做这些事情。大公司很成功，资金充裕，因此它们不像那些较小的公司那样有紧迫感去改变——或者说，它们不像那些不改变就会失败的公司那样有紧迫感。这就是为什么一切推进得如此缓慢。但与此同时，如果我们不关注这些问题，不去认真思考，危险就恰恰潜伏在这里。

Lenny Rachitsky： 我想大家会有很多问题，也希望能够获得更多建议。最后还有几个问题。如果大家想在线上找到你，沿着这些方向提出更多问题，或者在某些方面寻求你的帮助，应该去哪里找你？最后一个问题，听众怎样能帮到你，Melissa？

Melissa Perri： 你可以在 LinkedIn 上找到我。搜索 Melissa Perri，P-E-R-R-I，就能找到我。我的 LinkedIn 地址是 /melissajeanPerri，我很乐意和大家建立联系。我的学校叫 Product Institute，如果你对产品管理培训感兴趣，或者在这些方面需要帮助，可以访问 productinstitute.com 联系我。我也运营一档播客，叫 The Product Thinking Podcast，每周回答问题，很多都是关于 SAFe、敏捷和各种相关话题的。所以如果你有问题，想说”嘿，我该怎么做这件事？“，一定要联系我们，告诉我。

Lenny Rachitsky： 太棒了。Melissa，我学到了很多。我觉得很多听众会有同样的感受——“我之前对这些完全不了解，现在终于弄明白了那些偶尔听到的术语。“感谢你来和我们分享这一切，尤其是给那些正在这个世界中摸爬滚打的人提供的建议。

Melissa Perri： 谢谢你的邀请。

Lenny Rachitsky： 大家再见。

Melissa Perri： 再见。

Lenny Rachitsky： 非常感谢你的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留下评价，这真的能帮助其他听众找到这档播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于这档节目的信息。下期再见。

术语表

原文中文
agile coaches敏捷教练
Agile Industrial Complex敏捷工业复合体（Agile Industrial Complex）
Agile Manifesto《敏捷宣言》
Associate Product Manager助理产品经理（Associate Product Manager）
AthenahealthAthenahealth
BacklogBacklog（待办事项列表）
baselined统一基线
Behavioral-Driven Development行为驱动开发（Behavioral-Driven Development, BDD）
Big Room Planning大房间计划（Big Room Planning）
C-suiteC 层高管
Capital OneCapital One
career ladder职业阶梯
career path职业路径
churn人员流失
CIOCIO（首席信息官，Chief Information Officer）
CPOCPO（首席产品官，Chief Product Officer）
CSPOCSPO（认证 Scrum 产品负责人，Certified Scrum Product Owner）
Dean LeffingwellDean Leffingwell
digital strategy数字化战略
Director of Product产品总监（Director of Product）
Discovery探索（Discovery）
Extreme Programming (XP)极限编程（Extreme Programming, XP）
Feature-Driven Development特性驱动开发（Feature-Driven Development, FDD）
Fortune 10财富 10 强
Fortune 500财富 500 强
go-to-market市场推广
grok真正理解（grok）
Head of Product产品总监（Head of Product）
ICIC（个人贡献者，Individual Contributor）
inspect and adapt检视并调整
Jeff GothelfJeff Gothelf
Jeff SutherlandJeff Sutherland
Kanban看板（Kanban）
Ken SchwaberKen Schwaber
Lean UXLean UX
LeSSLeSS（大规模 Scrum，Large-Scale Scrum）
MartyMarty（指 Marty Cagan，硅谷产品集团创始人）
McKinsey麦肯锡
middle manager中层管理者
Mind the ProductMind the Product（知名产品管理社区/大会）
MVPMVP（最小可行产品，Minimum Viable Product）
OKROKR（目标与关键成果，Objectives and Key Results）
OpenSkyOpenSky
operating model运营模型
Park City, Utah犹他州帕克城
people work人际沟通工作
PMPM（产品经理，Product Manager）
PMPPMP（项目管理专业人士认证，Project Management Professional）
Portfolio Management产品组合管理
Portfolio Vision产品组合愿景
Product InstituteProduct Institute
product operations产品运营
Product Owner产品负责人
project manager项目经理
Rational Unified ProcessingRational Unified Processing（统一软件开发过程）
Release Train发布列车（Release Train）
Release Train Engineer发布列车工程师（Release Train Engineer）
Ron JeffriesRon Jeffries
SaaSSaaS（软件即服务，Software as a Service）
SAFeSAFe（Scaled Agile Framework，大规模敏捷框架）
ScrumScrum（敏捷开发框架）
Scrum MasterScrum Master
Scrum@ScaleScrum@Scale
software native天生做软件的（software native）
Sprint冲刺（Sprint）
Tech Debt技术债务（Tech Debt）
User Story用户故事（User Story）
VP of Product产品 VP（Vice President of Product）
Waterfall瀑布式（开发）

此文档由 AI 分片翻译（translate_long_document）