什么是技术债务？

「债务」这个比喻非常恰当。最早提出「技术债务 Technical Debt」比喻的工程师 Ward Cunningham 对此做了详细的解释：

有了借来的钱，你可以比采用其他方式更快地做某件事情，但在还清这笔钱之前，你需要支付利息。我认为借钱是个好主意，我也认为赶快对外发布软件以获得经验是个好主意，但当然，你最终会回到这来，并且随着你愈加了解软件，你会通过重构程序来偿还那笔贷款，以此反映你所获得的经验。

本文将与你讨论技术债是如何产生的。但在那之前，我们先了解一些与技术债的产生原因和本质有关的常见误解。

误区一：技术债务 == 坏代码

到底什么是「坏代码」？

好的代码或许是整洁的代码，也可以概括为不会迫使你在未来做出特定决策的代码，它保留了选择的余地。而坏代码则不留余地，还会强加上一些原本不存在的约束。

我几乎没见过由「糟糕的开发者」编写的「坏代码」，至少在生产项目中没有（这正是代码审查的作用）。我遇到的大多数「坏代码」都出自受到约束影响的优秀的开发者。

误区二：技术债是错误的

技术债务和金融债务一样不分对错好坏。在非理想状态下——即没有足够的「现金」来满足需要——它就是产品开发工具箱中的一个有效工具。

误区三：构建完成就万事大吉

最常见的软件开发的比喻是修建建筑。在建筑行业，工作是按顺序进行的：

• 建筑设计师设计建筑并绘制图纸；
• 工人们挖掘地基、修建上层建筑、铺设管线并进行室内装修；
• 业主和租户高兴地搬进来，如有任何问题，再找维修人员解决。

这是一个通俗易懂的比喻，但却和软件行业不怎么类似。

与建筑相比，软件更像是园艺——它比混凝土更有机。你根据最初的计划和各种条件在花园里种植许多花木。有些花木茁壮成长，另一些注定要成为堆肥。你可能会改变植株的相对位置，以有效利用光影、风雨的交互作用。过度生长的植株会被分栽或修剪，颜色不协调的会被移栽到从美学上看更怡人的地方。你拔除野草，并给需要额外照料的植株施肥。你不断关注花园的兴旺，并按照需要（对土壤、植株、布局）做出调整。——《程序员修炼之道》

在（错误的）建筑比喻中，大部分成本是预先产生的。维护成本要么是名义上的，要么被视作偶发事件而忽略不计。

在园艺的比喻中，构建功能是漫长工作中的一个步骤（就像种植作物）。花园越大，所需的维护就越多。这是在重新种植以改变布局（重构），或扩大花园并种植新作物（添加新功能——这也需要维护）之外的工作。

90% 的软件成本均与维护有关——我很多年前就知晓这个数据，但每每想到还是觉得难以置信。

技术债是怎么产生的？

那么，技术债究竟从何而来？它可以避免吗？

技术债务的另一种理解可能是，项目当前所处的状态与「假设利用积累的知识重新开始而现在应处的状态」之间的差值。

技术债有两个来源：

• 决策的权衡和取舍（鲁莽 vs 谨慎）
• 制定和执行决策时所具备（或缺乏）的知识，即有意和无意

理想情况下，你会在充分了解情况且不向约束条件妥协的前提下做出决策。但现实可能是，你在没有全盘了解信息和背景时就启动了项目，还要根据时间限制（如利益相关者给的截止日期）或成本限制等约束做出权衡。

如何避免技术债是一门学问，而对「技术债可否避免」这一问题，我的回答是：

“可以避免，但技术债是一种工具，不是敌人。”

如何量化技术债？

「现在有多少技术债？」这么抽象的概念真的能被量化吗？

真的很难，或者说你无法可靠地跟踪技术债。如果向软件工程师了解如何实现某个功能或修复产品的某个部分，他们可能会提供一个估算结果，并将需要偿还的技术债务涵盖在内，但你仍然无法追踪它。

Chelsea Troy 提出了一个与技术债务高度相关的可量化指标：维护负载（maintenance load） 。

维护负载描述了开发团队花费多少精力来保持现有功能同以前一样运行。—— Chelsea Troy

维护负载是有关项目年限和构建实践的函数，其衡量单位是持续付出维护精力的开发者数量（ongoing developer effort）。

需要说明的是，维护负载 != 技术债务。

但它依然是一个非常不错的技术债务指标。如果需要更多的工程师来防止系统/项目崩溃，那么很可能意味着你有很多技术债。如果仅靠十几个人就能建立一家价值 10 亿美元的公司，那么他们大概率很好地控制住了技术债。

（作者 Jacob Bennett，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

技术分享 | SpringBoot 流式输出时，正常输出后为何突然报错？

用 MVP(最小可行性产品) 做低成本快速验证，为什么不灵了？

6 大原则！助你构建高绩效的研发强军 | Liga译文

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

然而，尽管出现了许多理念和项目管理框架，例如敏捷（Agile）、Scrum、极限编程（XP）、看板（KanBan）和团队拓扑（Team Topologies）等，但只有少数企业知道如何高效地开发软件。我遇到过许多错误模式，最终导致进度延迟、软件质量恶化和客户满意度下降。为了避免无效管理并达成更优秀的表现，你应该了解软件项目/产品管理的最佳实践、理念及原则。

其中影响范围最大的实践之一是搭建团队结构的方式。许多研究（如康威定律）证明，如果用错误的方式搭建团队结构，团队绩效将受到极大的制约。在本文中，我将根据自己的经验和深入研究，解释能够在组织中构建有效结构的几项原则。

1. 系统设计先行

搭建高绩效研发团队的第一条原则，是在设计团队结构之前，先设计你想要的系统。美国计算机科学家和计算机程序员 Melvin Edward Conway 于 1967 年提出康威定律（Conway’s Law），该定律描述了组织的结构和沟通方式将制约其生产的系统设计。如果一个组织组建了设计团队、业务团队、前端团队和后端团队，那么系统的输出也将是业务文档、设计组件、前端组件和后端组件，这需要大量的团队沟通才能完成最终的整合并交付给用户。康威定律下的团队结构是最普遍的反模式之一，直到今天仍有许多组织在使用。

下面这种团队结构无需频繁交流，也能让团队独立地为用户提供价值（尽管无法做到完全独立）。它也被称为流对齐团队、功能团队或跨职能团队。

2. 考虑认知负荷

Matthew Skelton 和 Manuel Pais 于 2019 年出版的《高效能团队模式：支持软件快速交付的组织架构》描述了软件研发组织中的四种基本团队：流对齐团队（Stream-aligned team） ，使能团队（Enabling team） ，复杂子系统团队（Complicated subsystem team） ，以及平台团队（Platform team） 。这四种基本团队的背后是一个重要的心理学理论：认知负荷——指工作记忆资源的使用量。

上一条原则所解释的团队结构在《高效能团队模式》中被称为流对齐团队。流对齐团队是跨职能的，也是独立为用户提供价值的主力军。然而，流对齐团队太忙了，以致于无法赶上新玩意儿，比如新的技术、管理方法或领导力，也无法处理基础设施。如果把过多的责任压在流对齐团队身上，他们就无法处理任务，团队表现也会变差。 因此，为了减轻他们的认知负担，其余三个团队（使能团队、复杂子系统团队和平台团队）都要前来支援。

• 使能团队帮助流对齐团队学习向用户交付更高价值所需的新事物，诸如技术、架构、UI/UX、管理方法等。使能团队可能由内部/外部导师、教练或顾问组成，他们可以在流对齐团队中教授和实施新事物。
• 复杂子系统团队负责需要特殊技能或可与正常交付隔离的特定组件，例如机器学习模型、特殊图形/动画或认证 API。复杂子系统团队所处理的组件将通过讨论确定，因为它们与流对齐团队之间没有明确界限。
• 平台团队负责构建和提供一个平台，以让流对齐团队可以在该平台顺利地部署和发布，向用户交付价值。 在团队拓扑的背景下，平台是一个包括文档、指南、DevOps 和基础设施的综合概念，旨在帮助流对齐团队顺利部署。

3. 保持团队精干

原则之三是让团队保持「小而精」。 许多研究和知名企业都表明，「小而精」有比「大而全」更高的效率、更好的业绩——这是因为小团队的沟通更加有效，团队中的每个人都能随时了解情况，并提高参与度。亚马逊自创立之初就实行「两个披萨」原则（即组建团队和参加会议的人数不超过 9 人）并取得了真正的成功。

《敏捷革命》的作者 Jeff Southerland 在「Scrum 指南」中也解释说：“Scrum 团队小到可以保持灵活性，大到能够在一个迭代内完成重要工作，通常是 10 人或者更少。总的来说，我们发现较小的团队沟通更顺畅，工作效率更高。”

4. 仆人式领导力

Daniel H. Pink 在《驱动力》一书中提出了「驱动力 3.0」。他认为自工业时代以来，人类的行为动机已然发生了变化，他还审视了驱动力的三大要素：自主、专精和目的——它们可以持续激励我们。

• 自主（Autonomy） ：人类想要决定如何做。
• 专精（Mastery） ：人类想要成长。
• 目的（Purpose） ：人类寻求意义。

由 Robert K. Greenleaf 提出的「仆人式领导理论」正是驱动力 3.0 的体现。这是领导哲学的一种，其主要实践是为团队服务，使团队成员在工作中保持高度的参与度、积极性和可持续增长。在传统的领导方式中，领导者（老板）以命令和控制的方式命令团队成员（下属）做什么以及如何做。传统的领导风格无法激励个人，也无法提高他们的参与度和工作表现。

而仆人式领导者会设定一个目标和愿景（目的），将实现目标和愿景的方法下放给个人（自主），并提供学习新东西的机会（专精） 。

5. 持续改进

截至 2024 年 1 月，丰田是全球最大的汽车公司，其实践和理念一直影响着所有商业行业，如七大浪费、5S（Seiri 整理、Seiton 整顿、Seiso 清扫、Seiketsu 清洁、Shitsuke 素养）和 3M（Muri 超负荷、Muda 浪费、Mura 不均匀）。其中，最著名的理念是 Kaizen（改善）即持续改进业务流程。无论业务类型或情况如何（即使公司拥有行业最高的市场份额），都 100% 有改进的空间。 没有完美的企业，因此必须不断成长。

从长远发展来看，持续改进会产生复利效应。该术语最初来自金融学中的「复利」，意为利息长期呈指数级增长并产生被动收入。同样，如果团队和业务持续改进，他们的业务流程也将大幅改善，销售收入会成倍增加；其弊端在于大多数人由于短期看不到显著效果，会停止持续改进，但长期来看，持续改进所带来的效益是巨大的，因此需要坚持不懈和耐心。

Scrum 是最流行的敏捷框架，起源于丰田，也是持续改进的实践。在 Scrum 中，持续改进发生在「迭代回顾 Sprint Retrospective」中，Scrum 团队讨论他们在未来的工作中可以做得更好的地方。这是 Scrum 解决团队表现问题并成为应用最广泛的敏捷框架的最大原因之一。

6. 稳定性

搭建高绩效研发团队的最后一项原则是稳定性，即团队结构/成员和工作流程应保持稳定。不稳定会使团队混乱，影响工作效率和表现。

首先是团队结构和成员的稳定，这意味着他们不应频繁变动或调动。 比如，如果组织经常在不同团队之间调动开发人员，那么开发者被分配到新团队时就需要重新熟悉工作方式、代码库和文档，从而降低工作效率。

其次是工作流程流转的稳定性。如果工作流程不规范、不统一，团队成员就会对如何工作感到困惑，产出质量也会不一致。 丰田将标准化定义为业务最关键的实践之一，因为大野耐一强调工作应该顺畅地进行，没有阻碍和浪费。作为丰田生产方式（TPS）的成果，用于将工作流程和任务状态可视化的看板（Kanban）应运而生。

总结

在软件研发组织中，构建有效的团队结构对提高团队效率和工作表现至关重要。本文总结了构建高绩效研发团队的六项原则，它们分别是：

原则一： 系统设计应该比团队构建更早完成。

原则二： 充分考虑认知负荷并组建支持团队（使能团队、复杂子系统团队和平台团队），以协助核心团队（流对齐团队）工作。

原则三： 让团队保持在小而美的规模。团队规模越大，沟通也会变得更加复杂，进而降低工作效率。

原则四： 实践仆人式领导，围绕驱动力 3.0 帮助团队提高参与度和工作表现。

原则五： 无论如何都要坚持持续改进。哪怕在行业遥遥领先，也一定有进步空间。

原则六： 维护团队结构和工作流程的稳定性。这对于避免混乱和追赶成本，提高团队绩效非常重要。

（原文作者为 Eiki，内容经 LigaAI 翻译整理）

>> LigaAI 往期精彩阅读 <<

技术分享 | 弹窗开发中，如何使用 Hook 封装 el-dialog？

LigaAI x 极狐GitLab，共探 AI 时代研发提效新范式

宁波银行：在「金融科技」引擎上，沉浸式提效减负

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

（小剧场：某天午饭时间）
“最近怎么有这么多会议！上午开了两个小时的会，需求又做不完了 。”
“别提了，我今天排了三个会，根本没时间处理其他工作，还不知道几点能下班呢……”

根据微软对全球 31, 000 名员工开展的一项调查，低效的会议是影响工作效率的第一大干扰因素，其次是召开过多的会议。

大大小小的同步会、讨论会、审查会、复盘会不仅将工作时间拆解得支离破碎，还会让成员因「会议恢复综合症」而无法立即从无效会议中恢复过来，重新集中注意力投入工作。无法打造沉浸式工作时间，维护深度专注状态，极大地影响了个人和团队的工作效率。

为了克服会议疲劳，Shopify 在今年一月份宣布取消所有三人或三人以上的定期会议，并禁止周三举行所有会议。该举措涉及大约 12, 000 次的日程安排和活动，相当于节省了 322, 000 个员工工时。

大刀阔斧地砍掉会议是不是提高团队效率的灵丹妙药？ 或许，首先要弄清楚「我们为什么要开会？」

我们为什么要开会？

我们为什么要开会？

这个问题看似简单，但却值得深思。我认为开会是为了推进工作、完成工作，尽管实际情况并不总是如此（或者说，通常不是这样），但会议声称旨在推进目标、完成工作、共享信息、做出决策，或者至少要以一种异步沟通无法实现的方式取得进展。

毕竟，这就是会议的独特之处：大家聚在同一个物理或虚拟空间里，能够进行实时对话。这应该是非常高效的——不是文档或邮件、没有滞后的反馈信息，只有进展。

我们选择开会，因为这是更好的协作方式。

以上是会议应该达成的目的，但却不是我们开会的真正原因。你是否也曾对着自己的日程安排感到沮丧和无奈？因为你充分意识到自己会在一种效率极低的状态下忙得不可开交，却对此无能为力。我有过，那真的太糟糕了！

这种看似无解的「会议滥用症」，实际上是其他更糟糕的问题的表征。

问题一：协作流程支离破碎

频繁开会是流程瓦解的表现。我们把开会当成倚仗和退路，每当不知道该如何完成工作，或者不愿意投入真正能够推进目标的流程时，就安排一场会议。我敢打赌，那些对流程嗤之以鼻或者不愿参与其中的管理者们，正是导致会议泛滥的元凶。

问题二：对工作内容一无所知

频繁开会也是对工作内容茫然不知的表现。这通常是因为没有人愿意花时间弄清楚并解决这个问题。

我们将「会议」与「生产力」混为一谈，如果不开会，就不知道该做什么（或者不知道如何证明自己的工作价值）。 于是，我们说服自己「开会就是我的工作内容」，或者「无法提高工作效率是因为我没有参加会议」。即便真的是这样，那也更像是对会议的控诉，而不是疯狂开会合理化的理由。

问题三：职场权斗的必然结果

频繁开会也可以是权力斗争的表现。「接连不断的会议邀请不就说明‘我很重要’吗？每个人看到我满满当当的日程表都会这么想的。」

这种情况下，在踏进会议室的那一刻起，会议桌上的位置就比任务完成的实际效果更重要了。

是时候该反抗了！

几年前，当我意识到自己究竟在为什么而开会（还参加了如此多的会议）后，我开始了「会议抗争之旅」。

我拒绝参加那些我认为无须出席或者浪费时间的会议；我取消了所有单纯为了彰显身份地位的会议。 我深刻意识到我拥有着怎样的特权——大多数人都不能直接取消或拒绝出席会议。

我分享这个经历，是因为它让我认识到会议对我们的影响。虽然花了六个月的时间，但我逐渐将会议减少到原来近一半的数量。作为团队负责人，我本该频繁地参加各种会议，但我没有。

与我的同事和大多数直属下级相比，我参加的会议要少得多。坦白说，一开始的感觉并不好，我觉得自己一天什么事都没干成，总害怕错过什么；我担心砍掉会议实际是搞丢了自己的工作。但慢慢地，我意识到我为自己创造的所有时间都是一份礼物。砍掉会议并不代表与团队脱节，而是可以着手解决潜在问题的信号灯。 我有更多时间思考、设计、做出贡献，还可以处理那些需要我的问题。

我仍有一半以上的时间穿梭在各个会议室，但在这些会议中，我变得更加专注，准备也更加充分。我能够花更多的时间进行有效沟通，虽然会议减少了，但高效的即时通话增加了。

为了达成这一目标，我不得不重新学习一些东西，但我意识到砍掉一半的会议是一种提高管理效率的策略。

「会议滥用症」的疗愈之法

我对自己的日程安排有一定的控制权，但并不是每个人都能这样，而且一个人的日程表也不能解决真正的问题。一个急需解决的结构性问题是，管理者该做什么？

大多数人指出，优化会议规范是解决办法。问题的关键不在于会议过多，而在于「无效会议」太多，即会议效率低下。如果能够提前发送议程、阅读材料，并严格控制会议节奏和进程，那么所有会议都将变得极其高效。

我非常喜欢这个想法，但我从未见过它真正奏效——可能是因为这种方式就像在用创口贴和消炎药治疗复合性骨折。不过，如果你认真对待它，了解真正的隐藏病灶，或许能够摆脱「会议滥用症」。

下面是我实践过的具体做法。

最重要的治疗方法是建设优秀的流程。
无论你在做什么——产品、营销、研究、政策或服务——你都需要一个清晰的、完整的、端到端的流程路径将它实现。否则在此之前，你可能会陷入会议泥潭。

开会就像用仅有的锤子砸东西——用它，是因为没有其他工具了。良好的流程应该是轻量的、高效的、有强适应性的。 你需要清晰的项目计划流程以及井然有序的全功能产品开发与设计流程；你还需要专门负责处理这些事务的项目经理。一个优秀的项目经理可以通过减少会议，证明自己的价值。

你还需要改进开会的方式。会议中存在许多浪费时间的情况，以下是三个减少会议时间浪费的技巧。

1. 专注实时讨论，提高会议质量

用其他方式完成所有与高质量开会无关的事情。会议的独有优势是可以展开实时讨论，所有与此无关、与会议无关的部分，比如更新、参考信息同步、文档整理、幻灯片更新等等都应该去掉（全员会议和庆祝活动等文化会议除外）。

在取得项目进展上，实时对话和讨论比其他任何方式都更加高效。

2. 开门见山，才是高效的开始

立刻解决最难的问题。在会议开始的 5 分钟后，请开始讨论最困难的问题。我参加过很多长达一小时的会议，其中大部分是在前 55 分钟浪费时间，直到最后 5 分钟才进入重头戏。那为什么不直接从这开始呢？

3. 有效的会议，离不开信息透明

关于会议规范，有一点我完全认可——会议总结与共享。你需要记录会议纪要，然后同步给所有人。如果一个会议产出了决策，但没有让该知道的人都知道，那还算有效开会吗？

以前，我曾专门开会了解其他会议的情况……不能重蹈覆辙了，真的！

写在最后

即使你无法控制所有会议，了解会议泛滥和滥用的原因及解决方法也非常有用。你可以为解决「会议泛滥」创造条件，采取行动使会议变得不再必要，并让每一个人都注意到这点，还可以对自己的日程安排有更多的掌控权。

请记住，除了极少数的例外，你的本职工作不是参加会议，而是取得进展，达成目标。如果开会是你知道的唯一实现途径，那么你将不得不安排一次会议来讨论这个问题。

（原文作者为 Judd Antin，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

宁波银行：在「金融科技」引擎上，沉浸式提效减负

生成式 AI 如何释放开发者的生产力？

新晋技术管理者如何推动组织变革？

欢迎试用 LigaAI-智能研发协作平台，体验智能研发协作，一起变大变强！

生成式 AI 可以将程序员的开发速率提高两倍。技术管理者有望通过 AIGC 应用，大幅缩短四类关键开发任务的完成时间，进而提升组织生产力。

——麦肯锡《通过生成式 AI 释放开发者生产力》

01 生成式 AI 将如何影响研发效能？

麦肯锡最近的一项实证研究发现，生成式 AI 工具可以显著提升程序员的开发速率，进而显著提升组织生产力。

该研究对来自美国和亚洲各地的 40 余名开发者展开了观察和实验。参与者们需要执行三种常见的开发任务——代码生成、代码重构和文档编写，而开发者特征、任务的完成时间和复杂性，以及代码质量等数据被科学地记录下来。

研究结果表明，在生成式 AI 的辅助下，可维护性代码文档可以在一半的时间内完成，新代码生成效率提升近一倍，而代码重构类任务的完成时间也节省近三分之一。在新工具和流程的推动下，结合正确的技能提升和企业赋能，这些速度的提升可以转化为生产力的提高，并超越过去工程生产力的进步。

不过，任务完成时间的减少也可能会因开发任务的复杂性和开发者经验而有所差异。对于高复杂度任务，由于开发者缺乏必要的背景知识，其时间节省不足 10%。此外，在某些情况下，使用了 AIGC 工具的初级开发者（指经验不足一年的开发者）比不使用工具要多花 7%-10% 的时间。

研究还发现，当开发者和工具协作时，研发质量并不会因为速度提升而牺牲或降低。有 AI 辅助的代码在缺陷率、可维护性和可读性等方面的表现更佳。参与者们指出，开发者们正在迭代中积极地应用工具以实现更高的质量，是以该技术应该用于赋能开发者，而不是取代他们。

综合来看，想要使用生成式 AI 并最大限度地提高生产力和降低风险，技术管理者需要采取结构化方法，比如生成式 AI 的培训和辅导、用例选择、技能提升和风险控制。

02 生成式 AI 在四个方面卓有成效

1. 更快完成手动和重复的工作

生成式 AI 可以处理常规任务，例如自动填充标准函数、完成键入中编码语句、根据给定提示按一定标准格式书写代码功能文档等。在此过程中，AI 就能解放开发者，让他们能够解决更复杂的业务挑战，快速开发新功能。

2. 更高效地启动新代码的初稿

面对空白文件时，开发者可以在 AI 工具中获得编码建议。参与者反馈到，AI 辅助工具提供了有用的代码建议，这使他们摆脱了写作障碍，可以更快地开始创作。「这类工具使我能够更快地进入心流状态」，一位参与者如是说到。

3. 加速现有代码的更新

如果能提供有效的提示词，开发者使用生成式 AI 还可以更快地对现有代码展开更多更改。例如，为了减少从在线编码库调整代码和改进预写代码的时间，开发者可以将代码作为提示词，提交迭代查询，要求工具根据事先提供的标准进行调整。

4. 提高开发者应对新挑战的能力

虽然生成式 AI 对复杂任务的提升效果比较有限，但它可以帮助开发者快速温习完成工作所需的陌生代码库、语言或框架。在面临新挑战时，他们可以转向工具来获得如概念解释和框架使用指南等帮助，以更好地完成工作。

因此，使用 AIGC 工具执行复杂任务的开发者在规定时间内完成任务的可能性要比不使用工具的开发者高出 25%-30%。

除了生产力的提高，研究还发现，让开发者发挥出最大生产力可以显著改善开发者的体验，从而帮助公司留住并激发最优秀的人才。使用生成式 AI 工具的开发者，其总体幸福感、满足感和心流状态是其他人的两倍多。

03 依赖开发者专业知识的三个领域

生成式 AI 可以做很多事情，但其使用效果取决于使用它们的开发者的技能水平。从参与者的反馈来看，人类的监督和参与在以下三个领域至关重要：

1. 检查代码的漏洞和错误

生成式 AI 有时会提供不正确的编码建议，甚至会在代码中引入错误。一名开发者表示，她必须输入大量的提示来纠正工具的错误假设，然后才能得到答案。

2. 贡献必要的背景信息

虽然现成的 AIGC 应用拥有很多编码知识，但它们不知道项目和组织的具体需求。要确保最终的软件产品能与其他应用程序无缝集成，满足公司的性能和安全要求，并最终解决用户诉求，这些信息必不可少。

开发者需要通过提示词为 AI 提供背景信息，包括代码如何使用、由谁使用、接口类型以及软件将与之交互的其他系统，使用的数据等等。

3. 应对或分解棘手的编码要求

参与者还提到，生成式 AI 更适合回答简单的问题（如优化代码片段），而不是复杂的需求（如将多个框架与不同代码逻辑相结合）。

一位开发者分享到，为了获得可用的解决方案来满足多方面的需求，他首先必须手动地组合各个组件，或将代码分解为更小的片段。「当问题变得更加复杂并且需要考虑全局时，生成式 AI 提供的帮助最小。」

写在最后

ChatGPT 之后，不计其数的 AI 应用和辅助工具涌现，从代码生成、调试到审查、优化，我们都能发现许多令人兴奋的新面孔。也许在不久的将来，生成式 AI 会构建出新的规则，改变代码编写、审查和优化的方式，甚至成为开发者工作的必备工具。

麦肯锡认为，生成式 AI 应该成为开发者探索复杂任务的最强辅助，为其赋能，而不是取而代之。 这与 LigaAI 的观点不谋而合。

作为一款面向开发者的、以人工智能技术为核心的研发管理工具，LigaAI 自成立的第一天起就坚信，开发者最宝贵的时间和精力不该被机械重复的繁杂琐事绊住，形如信息同步、状态更新、任务流转等工作就该交给机器完成。只有这样，开发者才能专注地钻研技术、解决问题、交付价值，释放更多生产力。

相较于上一代工具，LigaAI 创新提出了「智能协作」概念，致力于以 AI 赋能每个用户，真正为研发团队提升效能。如果你正苦于滞后的、失真的进度数据、无法了解团队和项目的真实进展，或者疲于应对各种通知、提醒和干扰，欢迎注册使用我们的产品，体验新一代智能研发协作。

立即注册使用：新一代智能研发协作平台 LigaAI

关于变革的挑战总是复杂，而如何在不同的环境和问题中影响团队也是一项艰巨的任务。在实践中，我发现以更加实际的视角看待问题会有所帮助。

# 技术管理者的工具箱

尽管公司和技术团队各不相同，但大多数情况下，技术管理者有权决定团队如何开展工作，以及如何评估团队成员。这意味着他们拥有三个重要的变革工具：系统流程、行为和奖励。

技术管理者可以通过改进内部流程（System），提升团队的研发效能；通过自身的行为（Behavior），影响成员行动；使用奖励机制（Reward），激励成员做出正确行为。

它们在应对不同挑战时很有帮助。技术管理者了解自己能够撬动哪些杠杆，在行动时也会目标更明确，方向更清晰。那么，在软件开发领域，有关系统流程、行为和奖励层面的变革如何落地？

01 系统流程层面

系统和流程是最常见且讨论得最多的实践方法。每个团队都有很多正式的、非正式的工作流程。技术管理者可以对流程进行优化，以改善预期结果。

尽管我们都知道优化流程非常有效，但实践起来并不简单。我曾经失败过，也目睹过许多失败的流程改进计划。从中，我总结出四条系统优化原则：

• 从问题开始，而不是从解决方案开始

当你有一把锤子时，每个问题都会变成钉子。随着职业生涯的发展，技术管理者将不断地遇到问题、解决问题，同时习得许多行之有效的解决方案。因此，经验固然重要，但更重要的是先了解其他成员是否同意问题的存在。

• 就问题达成共识，并提出解决方案

作为团队领导者，技术管理者有义务帮助研发团队找到解决方案。理想情况是与团队协作共同寻找答案，但鉴于「管理者」在组织中天然具有权威性，你的考量和意见会变得格外重要。

一个有用的原则是，共识不是「每个人都同意」，而是「每个人都感受到自己的声音被倾听和认真对待」。技术管理者的职责是倾听所有观点，并提出一个能够周全考虑所有想法的解决方案。

• 全面地思考，有针对性地解决

尽管针对当前问题评估改进意见很重要，但在决定如何改进时，技术管理者应当考虑整个系统的影响。技术团队使用的大多数策略都取决于团队情况和其他重叠的系统，如果不了解相关背景就盲目遵循「最佳实践」，那么很可能导致不好的结果。

• 变革是痛苦的

「即便所有人都齐心协力，变革仍旧是痛苦的。」

团队流程与习惯一样，改变或塑造都需要反复不断地克服、适应和重新调整；尤其在变革早期，阵痛感会更加明显。我们经常看到一些伟大的变革因为实施时间不够长而失败，团队还没体会到变革带来的任何好处，就又回到了以前的工作方式。

02 行为层面

除了对团队流程/系统采取行动，技术管理者还可以利用团队最宝贵的资源——注意力——来塑造团队行为。领导者的行为会受到团队的观察和效仿，因而技术管理者可以利用这份关注，向团队传达正确的工作与协作方式。

这是一种微妙的、潜移默化的方式，它可以在许多场景下应用。例如，在团队会议上，技术管理者提出的问题会被视为重要问题；在项目中，其关注的领域也会受到更多的关注。

• 场景一：技术升级

如果团队需要优化某个技术领域（如测试或架构），技术管理者可以通过集中提问和讨论，为对话创造空间，推动团队朝期望的方向发展。

• 场景二：流程优化

当团队正在改进流程时，技术管理者可以通过关注流程并提醒团队所需的变化，帮助组织往正确的方向前进。与任何习惯养成的练习一样，定期提醒和小助力将有助于建立新的行为。

• 场景三：定期同步

在所有定期会议上，比如每日站会或迭代回顾会，技术管理者可以对需要关注的重点领域提出问题，引导团队的关注。例如，如果研发团队经常被提醒「质量 ＞ 速度」，那么最终这一原则也会在组织的行为和成果上有所体现。

03 奖励层面

通过提供奖励来影响团队可能是最明显直接的方式。毕竟，技术管理者要负责团队的成员招聘，有权决定岗位晋升以及项目的人员配置；还可以通过将成员安排在特定的职位，影响团队的工作方式。

提到「奖励」，大家通常会联想到大而明显的东西，比如新成员、职场晋升或物质奖励。但有一点经常被忽略：技术管理者可以通过小型反馈循环，为团队注入动力。

大部分人喜欢收到反馈，但却不那么愿意主动贡献反馈意见。我的一个独门秘笈是，在工作中积极地观察成员，并有意识地给予反馈。 举个例子，参加项目同步会议时，认真地做笔记并向大家提供反馈；阅读技术文档时，对内容和文档形式发表意见和看法；主动地表扬在团队聊天中提出问题的成员，给予正向反馈等。

其操作要点是，如何利用奖励并以独特且包容的方式激励团队，而不因个人偏袒产生人际问题。

作为技术管理者，你对团队成员观察得越多，对改进并获得成功的领域越重视，就越容易改变成员们的工作方式，进而改善团队的协作模式。

LigaAI 总结

同任何复杂系统一样，以上三种方法常常相互交叠、相互影响。技术管理者可以综合流程、行为和奖励，推进可能给团队带来重大影响的变革。

透过广阔、宏观的视角看待这些选择，将帮助你决定如何调整自身的管理者行为，提升团队影响力；进而，让组织变革变得更加容易。

>> LigaAI 往期精彩阅读 <<

向上管理：三个技巧，教会你如何与上级、老板高效协作

如何提高技术领导力？与你分享 5 个心得

产品路线图如何制定？斯坦福大学产品管理课程前来支招

「程序员转型技术管理」必修的 10 个能力提升方向

了解更多技术管理进阶、研发管理实践、程序员成长 等干货内容 ，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

“为什么呢？”我开口问道，“难道联合创始人看不到这些变化吗？”
几杯啤酒落肚，一位程序员同事给出了回答：“他真的很擅长向上管理！”

而后几年，我一直将「向上管理」与「拍马屁」「职场政治」和「出馊主意」联系在一起。

是的， 我错了。

大错特错。

向上管理——此处定义为「知道如何成功与上级互动和交流」——有助于推动公司和组织的发展。 它还能为你的职业成长提供助力，而无需阿谀奉承或使用暗中操控等不光彩的手段。

下面分享向上管理中，你可以立刻行动起来并看到效果的三个技巧。它们将对你、对你的上级以及你所在的团队都产生益处。

首先，注意力和精力是最稀缺的资源。

管理者认为自己的时间很紧张，但其实，他们最稀缺的资源是注意力和精力。

无论什么时候都有大量的进行中的事件，任何管理者都无法将它们一一照顾到；许多与人有关的事件会同时发生，大部分管理者也很难全都深入参与、处理。而随着管理者权力范围的扩大，该感受会越来越强烈。

以我所在的组织为例，我目前管理着 12 个产品和近 700 名成员，而我的上级管理的产品和人员数量是我的两倍。我通常知道这一年要发生的所有事情：目标、战略计划、进度指标、关键阻碍因素，甚至每个产品的月度/季度进展，但我能够（或者说应该）更加深入参与的部分却很有限。对我的上级来说，情况更是如此。

因此，从逻辑上讲，管理者取得成效的关键在于，选择那些能吸引极大注意力和精力的领域。实现的方法有很多种，管理者工具箱中也有一个重要工具：定期与直属下级进行一对一沟通。

这正是向上管理发挥关键作用的地方，它有助于将管理者的注意力和精力引导至效益最高的事情上。具体该如何操作？

01 做好信息的过滤、组织与结构化

第一步，会前做好信息过滤。 许多一对一的会议充斥着杂乱无章的更新、对棘手问题的抱怨，以及脑海中突然冒出的想法。更好的做法是，退一步，像老学究一样思考如何在有限的关注和空间内，向忙碌的上级领导展示信息。

• 当下哪些事情最值得管理者关注并投入精力？
• 哪些事情可以暂缓？
• 哪些内容即使当下很重要，也可以忽略不提？
• 哪些更新或参考信息未来需要进一步讨论？

充足的信息过滤能有效引导管理者关注最重要的事情，也会对你自身的成长和发展带来好处。我和我的上级每 2-3 周会进行一次 30 分钟左右的一对一沟通。在这几周的时间里，我会把在团队合作中想到的主题收集起来，并在会议开始前，对内容进行筛选和优先级排序，以确保我们能专注讨论「应该讨论」的内容，而不是很多「可以讨论」的事情。

除了精心准备会议内容，优秀的信息组织和结构化也至关重要。在复杂的、快速变化的环境中，你所选择的每一个议题都是富有深度和内涵的，可能需要花费好几小时才能彻底解读清楚。而时间非常宝贵，所以向上管理要求你需要像写文章一样思考，

• 哪三个要点（Bullet point）可以传达大部分内容，推进你与上级的沟通？
• 信息应该以何种顺序呈现，才能易于理解？
• 1-2 个需要上级提供意见的重点问题是什么？

从我的经验来看，大部分人很少或几乎不会考虑信息的组织和结构化——这会导致对话效果变差，也会降低上级领导的工作效率。对我来说，虽然会议只有 30 分钟，但我可能会花上 90 多分钟整理并记录信息要点，以求能够充分利用时间。

02 高质量的问题比解决方案更重要

你听过这种说法吗？

除非你有解决方案，否则不要给你的上级带来问题。

同所有「至理名言」一样，这句话被广泛地传播，然后以分毫之差被逐渐误解和曲解。爱因斯坦曾说过——也可能是杜撰的——如果给我一个小时拯救地球，我会用 59 分钟定义问题，用 1 分钟解决问题。不管爱因斯坦有没有说过，我们都可以在向上管理中实践它。

实际上，向管理者提出高质量的、明确的问题，远比向他们同步无关紧要的更新、说明你已经解决/有能力解决的问题重要得多。

棘手的问题会让管理者化身参谋长。又因为大多数管理者会与每位直属下级进行交流，因此从不同来源听到类似的问题能够凸显其重要性，并引起管理者的关注。此外，高质量的问题还能让管理者充分发挥经验、模式匹配能力以及情感距离方面的优势，以辅助找到问题潜在的解决方案。

对信息进行过滤、组织和结构化处理时，一定要带着定义明确的问题工作，这样才能让管理者和自己都更加高效。问题列表必须经过筛选、排序和整理；在管理者的协助下，我们也要找到「应该讨论」的问题范围。

03 做管理者和团队之间的桥梁

于所有管理者而言，如何在提供指导或反馈的同时，与整个组织保持沟通是一个永恒的挑战。组织规模越大，挑战难度也越大。

管理 5 人团队时，你可以同每位成员详细交流，确认大家都了解你的期望，并定期监控进展；

管理 25 人时，你仍然可以采取一对一的沟通方式，但不得不将详细的期望设定和后续工作留给管理人员；

如果是 700 人甚至几千人的团队呢？你无法与每个人一对一交谈，甚至无法确保所有人都会阅读你的通知和消息。

好的向上管理能为管理者和团队架起桥梁。

• 你如何将从管理者那获得的信息，翻译成团队/同事最容易理解的内容，并传递给大家？
• 当上级要求的一项工作进展不顺利时，你如何代表团队收集和综合管理者需要的反馈意见？
• 当管理者做出不受欢迎但正确的决策时，你如何利用同上级的直接联系，缓和同事与上级之间的微妙氛围？

糟糕的向上管理表现为盲目地为管理者背水一战——一个经典槽点是 「老板是这么说的，所以我们必须这样做」。另外，不加筛选地传递信息，像搬运工一样、不作任何处理地同步一切管理者的声音，也是错误的。同样，受家长作风影响或出于对权力的渴望，不将信息共享出去，只让自己知道，也是向上管理的错误模式。

如同桥梁一般的向上管理是怎么做的？管理者不必依赖自上而下的指令，而是知道你会以正确的方式帮助他们实现目标——提供正确的背景，会根据对象的不同做出正确的差异化，有正确的后续行动——并基于进展和问题向他们提供反馈。

# LigaAI 总结

虽然所有管理者都有自己独特的工作习惯和协作偏好，但本文提到的三个向上管理的技巧在某种程度上是普遍适用的。

• 价值导向的信息过滤、组织和结构化
• 提供高质量的问题描述
• 成为管理者和团队之间的桥梁

最后，希望你能在永无止境的任务和工作中，不懈努力并持续进步，以更好地方式管理工作、管理团队、管理上级。

（原文作者是 Saumil Mehta，内容经 LigaAI 翻译整理。）

>> LigaAI 往期精彩阅读 <<

如何提高技术领导力？与你分享 5 个心得

产品路线图如何制定？斯坦福大学产品管理课程前来支招

「程序员转型技术管理」必修的 10 个能力提升方向

如何用 NPS 确定研发优先级，打破技术与业务的次元壁？

了解更多 程序员成长、技术管理进阶、研发管理实践等干货内容 ，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

事实上，卓越的团队并不一定在才能、技术或者机会上更有优势，好的工作习惯和工作方式才是他们脱颖而出的关键。 诚然，成员自主的工作文化、组织领导者的支持以及清晰的愿景和目标非常重要，但它们不足以造就优异的、高绩效的团队表现。

除了寻找合适的伙伴并为他们提供恰当的机会，打造一个高绩效团队还要注重培养正确的工作习惯，并要能将其运用在工作和生活中。下面是高绩效团队的 5 个优秀习惯，看看你能 Get 几个同款。

第一点：不做完美的决策，不犯可预见的错误

做出正确的决策是很难的。许多在当下看来正确的选择在未来可能被证明是错误的，而这些失败在事后看来往往又是显而易见的。

高绩效团队不做完美决策。他们与其他团队的不同之处在于，高绩效团队始终在用能消除认知偏见、降低项目风险的方式工作——运用事前分析法（Premortem）评估各种可能性、了解后果、预测失败并寻找规避失败的办法。

事前分析法由美国心理学家 Gary Klein 提出，是一种用于高效评估风险，主动识别潜在阻碍的决策思考方法。它的具体工作方式如下：

1. 将自己置于未来时刻并回顾过去；
2. 假设要做的项目/任务已经彻底失败；
3. 反推可能导致项目/任务失败的错误和原因；
4. 制定解决计划，通过消除已预见的风险和障碍，提高成功几率。

优秀的团队并不总能做出最佳选择，但是他们始终能避免明显的、糟糕的错误。

第二点：以团队利益为先，始终为他人提供支持

判断一个团队健康与否的依据之一，就是看成员们是否愿意公开表达不同意见，并（在立场不合时）能否为对方提供支持。

团队意见相左又无法达成共识时，如果采用「求同存异」的方式继续合作，就很容易产生消极心态。成员们可能无法客观地理解事情本身无关对错，也不分你我，反而会因为无法赞同其他观点而轻视决策，因心存芥蒂而无法向他人提供必要支持。

相比之下，「坚持不同观点但承诺支持」维护了团队团结，它可以成熟地区隔角色和观点，让成员们在各执己见的情况下仍为他人提供支持。它既不掩盖分歧的存在，也不否定不同观点的价值；它只指导成员了解该在何时放下争执，以团队效益为先与他人合作，而不是与之作对。

高绩效团队的成员不会让意见分歧恶化成「赢过对方」的个人执念。他们能够跳出个人立场，认真考虑其他人的看法；当最终决策与预期不符时，也能在坚持己见的基础上，承诺全力支持团队。

高绩效团队成员专注于履行合作承诺，为互相冲突的意见提供支持。他们通常会这么做：

1. 将自己与意见/立场剥离；
2. 分享自己的考量和意图；
3. 调查冲突产生的原因；
4. 评估和理解不同的观点；
5. 表明自己对观点的坚持，同时承诺无论结果如何都会支持最终决定。

第三点：以绝对坦诚的方式提供和获取反馈

得不到反馈的人都有一个共同点——他们将「提供正确反馈」的全部责任推到反馈者身上，让自己置身事外。他们怪别人含糊不清、不诚实或不愿意分享反馈，却忘了自己也承担着接收反馈的责任。

如果缺乏正确反馈，团队就无法知道自己做错了什么、哪些改变可以帮助他们提升和进步；而无法体验及时反馈的好处也反过来阻止了他们与别人分享有价值的信息。

高绩效团队会创造一个利于反馈的环境。他们不仅会不断地向他人汲取反馈和建议，也会毫不犹豫地贡献反馈。这是他们最常向自己和他人提出的两个问题：

• 我们如何更好地工作？
• 我们如何一起提高？

高绩效团队承担起给予和获取反馈的全部责任，以自驱的方式实现个人成长，而不指责别人没有提供足够的燃料。

第四点：能以高能动性应对未知与挑战

高能动性意味着成员会主动出击，自发探索实现目标的途径，而不是一味地等待「完美时机」或者抱怨环境不好。 他们能在逆境中挺身而出，也能想方设法地扭转逆境，实现目标——要么找到一条路，要么造出一条路。

高能动性是一种驾驭未知和挑战的能力，是在条件不完美时主动为成功开路而不空等的态度。它会指导我们牢牢掌握自己的生活、行为和决定的控制权，督促我们努力拓宽能力边界，积极探索未知领域并完成所有成功所需的任务。

高绩效团队拥有将逆境转化为机会的能力。 工作中的很多事情都可能出错，比如优先级冲突、期望不一致、沟通有偏差、任务完不成等等。在别人对此心生抱怨而中途放弃时，高绩效团队则坚持不懈地寻找解决方案，迎风向前；遭遇失败或犯错时，他们也会感到失望和沮丧，但绝不会让负面情绪成为前进的阻碍。

在《明智领袖的 15 个承诺》一书中，Jim Dethmer 称其为「承担根本责任」。他写道，「当我们责备他人时，就会把生活的控制权置于己身之外；当我们承担起责任时，就能在内心深处找回对生活的控制力。」

第五点：将「持续学习」列为首要任务

在工作中，我们需要不断更新技能、职责和工作方式。如果不跳出舒适圈，克服揭开未知的不适感，不学习如何解决复杂问题，也不培养应对不确定性的能力，就无法实现个人成长和职业发展。

高绩效团队深谙此道。他们不断挑战自我，寻找新机会，解决以前从未遇过的问题，并主动完成技能拓展相关的工作。 将长期学习列为首要任务不仅能帮助团队将障碍转变为机会，还能减少成员们的压力和焦虑。

就像运动员从不放弃训练一样，高效能的人永远不会停止主动调节和强化习惯。真正的成功——全面的、长期的成功——不是来自于自然的、明确的、方便的或自动的事情。通常情况下，当目标更大的挑战颠覆了我们对舒适和确定的定义，一趟伟大的旅程便开始了。——布伦登·伯查德

LigaAI 总结

高绩效团队会主动识别潜在问题、评估风险并找到克服的办法；他们通常使用「事前分析法」来完成这一目标。

高绩效团队成员愿意坦诚地分享自己的观点和看法，并承诺全力支持最终决定，哪怕会与他们的预期背道而驰。为了发挥出团队的最佳水平，他们会利用一切机会提供或获取反馈，并对自己的过程和结果负责。

此外，他们还会主动地、有意识地跨出舒适圈，拥抱新机遇，承担更多风险。他们也将学习放在首位，以更好地应对工作和生活中的挑战和要求。

（原文作者：Vinita）

>> LigaAI 往期精彩阅读 <<

研发质量指标大 PK：MTTR vs MTBF，谁是靠谱王？

9 个研发质量管理指标，一次理清！

3 个技巧，让你像技术专家一样解决编码问题

ChatGPT 之后，B 端产品设计会迎来颠覆式革命吗？

了解更多开发者提效、 研发管理、 研发效能管理、前沿技术等消息，欢迎关注 LigaAI。欢迎体验我们的产品，期待与你一路同行！

LigaAI 在 John Cutler 的一篇分享中找到了答案：团队健康度评分。就像我们都很关心自己的身体健康一样，研发管理者也应该时刻关注「研发团队的健康」，定期度量和检测与成功、健康有关的关键指标，并在每日管理中发现问题，持续进步。

具体是怎么做的？

John Cutler 制作了一个「团队健康日查表」，拟定了 12 个与团队健康状态相关的问题，分别为其赋予了权重值并每日更新打分。 通过分析和对比每日评分，就能比较清晰地掌握研发团队的工作状态和表现，在必要时及时投入指导。

下面就和 LigaAI 一起了解 John Cutler「健康日查表」的具体问题以及对应的原始分计算规则（下文简写为规则）吧！

# 今天，我们的团队……

Q1 – 判断题：至少有一人与客户进行了交流吗？

规则：「没有人与客户交流」计 0 分，「有交流」计 1 分；如果有跨职能成员参与交流，则再加 1 分。

不要把客户隔离在一线。研发团队不应该像接口一样被动地接收信息，这样只会让数据囤积，并在过滤和处理中造成信息丢失。定期与客户沟通和交流才能培养、锻炼用户视角，更好地理解需求。

Q2 – 判断题：讨论了客户需求、使用反馈等事实，而非假设、猜测和预测吗？

规则：「讨论了事实而非猜想」计 1 分，「没有讨论事实」计 0 分。

如果会议上充满了「我认为/觉得」「可能/应该」等不确定的想法，研发团队就很难正确地工作。尝试着把对话重点转移到客观事实和数据上，会议会变得更加高效（甚至有趣）。

Q3 – 计数题：有两个小时无干扰的专注工作时间吗？

规则：「一个人不受干扰地工作两小时」记为一次专注，每两次计 1 分，统计整个研发团队的平均专注得分。

计算公式：若研发团队总人数为 M，有 N 个人一共专注工作了 X 次，那么原始分为（X/2 * N/M）。

如果一个团队的时间被持续打断，大家就不可能正常工作。连续的两个小时是比较理想的专注时长；如果能在充满干扰的环境中，获得两个不被打扰的两小时，就已经很不容易了。

Q4 – 计数题：学到了新东西吗？

规则：统计学习新知识的人数占比，若有内部分享则分数翻倍。

如果团队没有持续学习关于客户、行业、技术或自我提升等知识，那就是在退步。学习新知识会正向激励团队，证明现在所做的一切是有价值的；如果一直没有任何收获，那可能要考虑跟大家「说再见」了。

Q5 – 计数题：应用/实践了最近学到的东西吗？

规则：统计应用了新知识的人数占比，若有内部分享则分数翻倍。

掌握一项新技能的最好方式就是使用它。今天的工作有没有用上最近学到的新知识？不是那种大几年前就掌握了的，而是最近几周了解到的新的知识。

Q6 – 判断题：有 10 分钟以上的关于工作的热烈讨论或全员讨论吗？

规则：「有超过 10 分钟的讨论」计 1 分，「没有」计 0 分。

这不需要正式的会议邀请，扭下头、转个椅子、走两步到同事旁边或者发起一个语音通话，直接开始沟通和讨论就可以了。

Q7 – 计数题：进入了心流状态，觉得工作有挑战性且非常高效吗

规则：统计进入心流状态的人数占比。

心流是一种很棒的体验，你会感觉时间飞逝，工作充满挑战且富有成就感；不会觉得自己在做没用的事情。

无法进入心流状态的原因有很多：消极的心态、工作的干扰、缺乏使命感和糟糕的工具等等。心流状态是有「传染性」的——当团队里有一个人进入了状态，那么其他所有人都会被影响到。所以，今天有多少成员成功进入了心流状态呢？

Q8 – 计数题：有组织成员展开某种结对协作吗？

规则：统计团队的结对率，若有跨职能成员结对协作则分数翻倍。

结构化结对可能会让人感到压抑（尤其是在被迫和强制的情况下），但与其他人一起工作一段时间会是一种积极的体验。跨职能合作说不定会产生令人惊喜的结果，比如让 UX 和工程师合作。

Q9 – 判断题：有就已经发生和未发生的事情，展开至少 10 分钟的坦诚交流吗？

规则：「有超过 10 分钟的坦诚交流」计 1 分，「没有」计 0 分。

研发团队足够「真实」吗？大家是否能够诚实坦诚、毫无保留、毫不美化地共享信息？如果是的话，这就是一个很好的迹象。缺乏开放、信任和充满安全感的氛围，研发团队几乎不可能持续进步。

Q10 – 计数题：有（面向内部）产出高收益、可复用、可获取和必要的贡献吗？

规则：统计有提供贡献的人数占比，若有在内部分享成果则分数翻倍。

研发团队的工作并不都是面向客户的。有时候我们也要迎难而上，抓住机会优化内部工具或流程，这会给团队带来很多好处。

Q11 – 判断题：有让大多数成员体验并享受到短暂的乐趣/幽默时刻吗？

规则：「在工作中感受到乐趣」计 1 分，「没有」计 0 分。

要开心地工作！前几天我们在 Slack 上讲了一个笑话，所有人都笑得很开心。快乐的力量是强大的，如果伙伴们不能一起找乐子，就……还挺难度过产品开发低谷期的

Q12 – 计数题：庆祝了胜利，并在专业或个人角度形成了共鸣吗？

规则：统计觉得自己产生了胜利共鸣的人数占比。

大多数里程碑的达成并没有真正引起成员共鸣，对于影响的感知很大程度是个人感受。今天团队中有多少成员觉得自己在工作上取得了胜利呢？

# LigaAI 解读

John Cutler 使用简单的「YES or NO」判断和人数/次数统计，将研发团队的健康状态量化，避免了主观评分可能存在的标准出入和分数差异。

值得关注的是，在团队的不同发展阶段，各项问题的权重值也会发生变化。比如在团队建设早期，分享、沟通和交流等与组织文化相关的问题重要性会更高，而在快速增长期，有关专注度、心流等问题则更重要。

研发管理者可以根据团队的实际情况，制作专属的「团队健康检查表」。其重点在于要建立清晰的评分标准，尽可能基于客观事实将所有分值量化出来，避免主观打分。同时，要根据研发团队的成长状况，定期维护和更新检查项目，持续进步。

>> LigaAI 往期精彩阅读 <<

清单推荐：常见的研发效能度量指标（科学管理版）

新任技术管理者如何更快更好地适应角色转变？

管理研发团队后，我发现用「速率」做度量错得离谱……

前端进阶：如何在 Web 中使用 C++？

LigaAI 将持续分享更多技术成长经验、研发效能管理实践，陪伴每一个研发团队和开发者成长。欢迎关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

Product/market fit means being in a good market with a product that can satisfy that market. —— The Pmarca Guide to Startups

聚焦到产品研发环节，验证 PMF（即 Product/Market Fit）要求研发团队在找准市场定位的同时，根据市场和需求的变化及时调整战略，为用户创造价值，并实现经济效益的增长——这也是敏捷开发的基本核心。

理想情况下，敏捷团队的产品负责人（PO）、Scrum Master 和开发团队各司其职，在价值优先、增量构建和紧密协作中，持续交付可工作的软件，逐步验证市场价值和商业价值。

而现实情况往往是，需求源源不断地涌入，产品和开发团队迷失在所谓的「用户需求」和「用户反馈」当中，抓不住真正的「价值浮板」。最终，结果导向的「敏捷开发」沦陷为产出导向的「快速开发」，并落下「中华田园敏捷」的恶名。

01 结果导向 VS. 产出导向

敏捷开发以结果导向（Outcome Oriented） 为内核，强调价值交付，以优先级排序、产品待办列表等最佳实践保障敏捷团队专注于用户价值创 造。

而产出导向（Output Oriented） 的快速开发则专注于消除技术风险和快速上线功能。在紧迫的迭代周期内，研发团队追求高效率、高速度和高质量的功能实现，却可能忽视产品价值的市场验证。

研发过程过分强调速度和质量（现实中质量可能无法得到绝对保证），而忽略价值，等同于在无限的功能上线和堆叠中「隔靴搔痒」；若无法直击痛点，为用户提供真正的解决方案，无论开发速度有多快，产品都会被市场淘汰。

另一方面，如果过度关注用户价值而弃质量和效率于不顾，在风云难测的市场和外部环境中，产品也会因此口碑下滑、错失东风，而被市场抛下。

只有在迭代循环中，结合产品生命周期目标，平衡好价值交付和产出效率，兼顾产品价值、技术价值和用户价值的创造，才有可能小步快跑地验证 PMF。

02 研发三大价值

敏捷开发主张产品负责人要与研发团队一起商讨功能明细，为高产品价值的待办事项评定优先顺序和工作量，再结合团队容量制成产品待办列表和迭代待办列表。

那么，实践中的「三大价值」应该如何衡量？

产品价值 – Business Value

产品价值，也称商业价值（Business Value），可以理解为是技术价值和用户价值的总和。提升产品价值的本质是以尽可能少的努力和代价，最大程度满足利益相关者和用户的经济期待。

技术价值 – Technical Value

研发团队将产品想法和创意落地的过程中，为提升研发效能而做出的所有技术努力，共同组成产品的技术价值（Technical Value）。

例如，在迭代实践中，制定软件和开发工具的基本框架，选用合适的自动化工具，消除技术不确定性并解决重大技术问题；

以及，在轮复一轮的磨合与协作中，摸索出最恰当的研发协作模式，形成产品开发相关的技术知识，建立技术规范和要求，并达成共识等。

用户价值 – Customer Value

用户价值，也称客户价值（Customer Value）是产品的各个功能为用户提供的价值；好的功能和模块总是能清晰直观、易于使用地为用户解决问题。

常见的用户价值评估模型包括 RFM 模型、CLV 模型、帕累托模型和顾客社交价值模型等。

• RFM 模型：通过用户最近一次的购买行为（Recency）、总体消费频率（Frequency）以及消费金额（Monetary）三项指标来描述该用户的价值状况。
• CLV 模型：CLV 即客户生命周期价值（Customer Lifetime Value），有时也称 LTV（Life Time Value）；它考虑含客户获取和客户流失在内的完整客户生命周期。
• 帕累托模型：基于二八定律的客户价值评估模型，可以帮助团队判断出「谁是利润效益最高的用户」。
• 顾客社交价值模型：涉及顾客社交活跃度和影响力两个方面，对于产品传播和口碑营销有较好的评估及预测效果。

03 价值增长曲线

David Theil 根据阶段性目标的不同，将产品生命周期划分为知识构建期、产品成长期和稳定增长期，并绘制了技术价值和用户价值的增长曲线。

P.S.: 价值增长曲线图以趋势呈现为主，在具体数值上不存在必然的对应关系。

信息构建期 – Knowledge Building

地基不牢，地动山摇。在产品开发最早期，研发团队以技术建设为主，着重消除技术风险，为用户价值提速做好准备。

研发团队通过构建系统架构和基础设施、选用工具和自动化、制定技术决策，以及使用 Spike（探针法）消除技术不确定性，快速提升技术价值，并建立起用户价值创造所需的技术规范和知识。

同时，团队会设计 MVP 并交付少量功能，不断探索真正的用户价值，在持续、频繁的价值交付中逐步验证 PMF。

产品成长期 – Product Focus

寻找 PMF 的征途总是曲折，但一旦实现，便会迎来爆发式的业务增长和产品扩张。

基于前期牢固的「技术基建」和已被市场验证的产品方向，敏捷团队可以在正确的道路上全力冲刺，专注于产品功能和需求的开发与实现，高速创造用户价值；

产品的技术价值也会在定期回顾中缓慢提升。

稳定增长期 – Stabilizing Product

随着产品功能日渐齐全，用户价值增长趋于平缓，此时产品开发步入成熟期。

敏捷团队也要原地休整，养精蓄锐。研发团队着手修补技术债、优化系统架构、升级基础设施，提升技术价值；产品负责人则根据最新的市场动态和变化，探索新的价值增长机会，等待再次「全力出兵」和爆破式增长。

在不断地迭代实践与复盘中，敏捷团队得以持续提升技术价值，创造用户价值，并打造出稳定的产品价值增长引擎。

LigaAI 总结

无论是产品管理，还是研发管理，最终都要为企业业务增长服务，而验证 PMF 是其中至关重要的战略转折点。

敏捷团队不仅要积极拥抱市场和外部的变化，及时调整或修正产品方向，还应当结合产品生命周期，客观地对产品价值、技术价值和用户价值展开管理，并打造以结果导向为核心的组织成长内核。

>> LigaAI 往期精彩阅读 <<

对话 ChatGPT：现象级 AI 应用，将如何阐释「研发效能管理」？

「钞能力养成指北」前传：开年变富，如何迈出第一步？

「「钞能力养成指北」：开年变富第一步，从科学记账开始

Hackathon特别策划 | 72小时灵感冲刺，创意就该这么玩

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。

高层管理者总觉得自己很了解应该做什么，并希望产品经理服从他们的命令。所以在现实场景里，产品专家们只能根据指令完成「废话管理 Bullshit Management」，而不是产品管理。

没有决策权，产品经理就无法茁壮成长。

可要小心了！有些公司「说的」和「做的」总是截然相反。说是扁平化管理，但你可能会发现公司内部有层层决策链，最终还会因此陷入分析瘫痪；

你可能会被授予一定的决策自主权，但绝不会超出特定范围。比如你可以敲定如何更好地实施解决方案，但却无法决定先解决哪个问题。

凭借主观想法和管理层级推动业务，是让人震惊的。我特想知道，领导层聘请产品经理究竟是为了执行废话，还是管理产品。

下面我将举例说明什么是「废话管理」，以及产品经理们可以如何避免这些可怕的陷阱。

一、一直被误解，从未被实践的产品管理

随着公司的发展，内部政治化会逐渐加强，而敏捷性则越来越弱。有些时候，最重要事成了取悦内部的关键干系人，而不是弄清楚哪些终端用户的问题值得解决。

此时，你可能就会从「产品经理」降级为「待办所有者 Backlog Owner」或「故事写手 Story Writer」。这种情况下，取悦利益相关者比改善用户体验更有利于职业发展。

我时不时会看看招聘广告，了解企业如何看待「产品经理」一职。遗憾的是，我在其中看到了许多岗位误解，下面是我在最近发现的一些奇怪的要

您将会与组织中的利益相关者合作，获取他们的支持并满足他们的需求。

我以为产品经理必须要满足的是用户的需求，而不是内部利益相关者的需求

您需要在全球/区域基础上，制定商业计划和产品推广计划。

认真的吗？大多数商业计划本质都是瀑布式思维；创建一个计划、做几个漂亮的 PPT 和在线表格。那只能用来骗自己，计划越多，失败越大。

好的产品管理要有明确的愿景，能用很少的资金测试各种想法，并在得到客观的佐证后，逐步提升它们。目标服务于愿景，但也要拥抱试验才能发现隐藏的机会。

制定用于提高开发效率的工具和流程。

这点让我很困惑。我从没想过产品经理需要负责制定流程，提高开发效率。这是典型的产出导向（Output-oriented）的要求，而不是结果导向（Outcome-oriented）。

您需要为您的产品小组规划活动和资源，并与工程、市场、质量或销售等跨职能团队进行协调。

产品经理不计划具体的活动，而应该设定目标，并授权团队做出决策。这要求听着更像项目管理，而不是产品管理。

同「Context, Not Control」一般，优秀的产品经理主张情景管理，绝非控制管理。

使用全面的验收标准，定义史诗和用户故事。

将产品经理视作需求工程师是一个常见的陷阱。一些公司希望产品经理可以架起业务端和技术端的沟通桥梁。瀑布开发就是这样，但我们都知道它的效果并不好。

卓越的产品经理应该打造一个可以滋养伟大想法的环境和氛围，而不是设定实施要求。

您将确保整个公司展开强有力的协作和沟通，并就产品路线图达成共识。

追求共识除了会让团队速度变得超级慢之外，还会让大家趋于平庸。产品经理争取的从来不是共识，而是承诺。大家同不同意都没关系，经验和客观证据永远比主观想法和职位更有说服力。

我在阅读以上这些产品经理的岗位描述时，我知道我们还有很多机会，可以帮助公司实践良好的产品管理。尽管这极具挑战，但回报很可观。

其中的关键就在于了解预期的可能结果并调整方法，帮助企业取得产品管理方面的进步。过程可能会挑起一些争吵，但这听起来就很刺激。

二、什么是「废话管理」？

花时间做与产品管理无关的事情，我都称之为「废话管理」。展开详细解释之前，我想先分享一下「什么造就优秀的产品经理」。

通过确定要解决的重大问题，发现未开发的潜在机会，领导团队为终端用户和业务创造价值。

在我看来，一个优秀的产品经理善于鼓舞人心。TA 会舞动大家行动起来，有些事情甚至连行为人都不知道自己能做成；TA 还会设定振奋人心的目标，授权团队决定如何实现目标；TA 不是老板，而是团队追随的领导者。

如果你的日常工作与上面提到的有关，我相信你在做产品管理；但如果不相关，那大概率就在进行「废话管理」，就像这些常见情况一样：

• 收集和解决干系人的需求，而不与他们建立关系，满足终端用户的需求。
• 保留大量的产品待办列表，只为了告诉干系人「需求已登记」，却不删除与当前目标无关的待办事项。
• 频繁地为管理层准备绩效报告，却不评估交付物的效果。
• 努力地追求共识，取悦所有干系人，却不为产品找一个最优选择。
• 签署团队交付的所有项目，以确保他们符合你的质量控制标准，而不授权他们实现目标。
• 参加会议只是为了避免激怒干系人。
• 害怕拒绝无意义需求，因为你的老板可能因此收到「问候」。
• 承担业务干系人和开发人员之间的沟通，而不是成为促进协作的催化剂。
• 不了解终端用户的意见，基于主观想法就完成需求的优先级排序。
• 专注于功能模块的交付，却不追求价值最大化。
• 花时间为计划失败找原因，从不分享从失败中学到的经验和教训。

每当看到任何一个「伪产品管理」的迹象，产品经理都应该站出来，帮助团队扭转功能失调的管理，向可靠和稳固靠拢。别向错误模式低头，莽它！

三、如何避免陷入「废话管理」？

前面列举了一些常见的产品管理的错误模式，下面将提供一些纠正错误的实践技巧。

01 改掉主观想法，追求客观证据

干系人可能会步步紧逼，要求产品经理实现他们想要的功能。在做出任何决定前，你可以向他们提出以下问题：

• 这个功能与我们的目标有什么关系？
• 哪些证据能说明此功能解决了用户问题？
• 您想用这个功能解决哪个问题？
• 如果实现了这个功能，该怎么评估它的效果？
• 如果不做这个需求，会发生什么？

这些问题的答案可能会让你和干系人都大吃一惊。也许他们会撤回之前的请求；如果在缺乏有力证据的情况下他们仍旧坚持，那么坚持客观证据就是你的职责。主观想法不应该成为产品团队的驱动力。

产品经理要带领团队为终端用户提供解决方案。通过打造产品和服务，让用户的生活更美好。想要获得成功，就要从「取悦利益相关者」，转变为「帮用户获得进步」。

02 避免成为「传话筒」，鼓励直接交流

将产品经理视为业务团队和技术团队的桥梁，是一个常见的错误。更好的方法是为技术团队提供正确的上下文信息，授权他们自主决策，并鼓励他们在需要时，与业务利益相关者直接沟通。

你可能认为，让开发人员与干系人直接交流有点危险，他们可能尝试将干系人的需求劫持到冲刺中。

这确实有可能发生，但相比敢于解决问题的伙伴，循规蹈矩的团队更为危险。如果干系人试图劫持某些东西，请及时给予反馈，鼓励开发伙伴将此类讨论重定向给你，因为他们可能也不愿意处理它。

03 聚焦用户学习，摆脱无效计划

每个人都喜欢安全感，没有什么比为面前的一切制定一个按部就班的计划更好了。干系人会要求你制定规范性计划，并对截止日期做出承诺。

不要掉入这个陷阱！

没有任何计划能在与用户接触后还继续存在。与其费劲做计划，不如拟定一个假设清单，将想法实现必须要完成事情都列出来。再找一条能快速验证假设的捷径，你越快地了解清楚用户，就能越早迎来产品成功。

可靠的产品管理与计划无关。不要沉迷计划；把你的精力放在确定着陆点，和迈向它的第一步上。

除此之外，你的项目启动无需任何东西。之后根据你了解到的内容，调整具体行动。下面是聚焦用户学习，摆脱无效计划的几点标志：

• 产品待办列表很精简，工作量不超过几个月。
• 删除了待办列表中与学习成果无关的事项。
• 叫停了某些功能和需求，因为证据表明它们不会创造任何或令人满意的价值。

# 写在最后

产品经理的竞争比以往任何时候都要激烈，许多公司都在向优秀的专业人才抛出橄榄枝。如果你想加入，没有比现在更好的机会。

但是，准备好应对许多「伪产品管理」和实践挫折。尽管公司会招致优秀的产品专家，但这不意味着他们会提供一个良好的发展环境；你必须与错误模式对抗，帮助他们克服功能障碍。

伟大的产品经理永远不会向错误模式低头。他们将始终保持战斗状态，以确保能够为用户带来改善和提升。

原文作者：David Pereira

文章出处：Medium

>> LigaAI 往期精彩阅读 <<

半个月上线一个新产品，猴子无限是怎么做的？

如何基于GitHub Pages+Hexo，搭建个人博客？

多测试环境的动态伸缩实践

被忽悠入坑后，我如何让产品「起死回生」？

了解更多敏捷开发、项目管理、行业动态等消息，关注我们的团队博客或点击 LigaAI-智能研发协作平台，在线申请体验我们的产品。