内容概要
Nicole Forsgren 是 DORA 和 SPACE 框架的创建者，也是《Accelerate》和即将出版的《Frictionless》一书的作者。她与主持人 Lenny 一起，探讨了在 AI 时代衡量开发者生产力 (developer productivity) 的诸多细节。他们深入讨论了为什么传统指标常常具有误导性、如何判断工程团队是否能行动得更快，以及 AI 如何在加速编码的同时，并未如预期般显著提升整体开发速度。对话还涵盖了 AI 对“心流状态” (flow state) 的影响、开发者体验 (DevEx) 的核心要素（心流、认知负荷和反馈循环），以及如何建立和扩展一个专门的 DevEx 团队的框架。
目录
-
Nicole Forsgren 简介
-
开发者体验 (DevEx) 的概念
-
AI 时代的心流状态与认知负荷
-
AI 带来的生产力衡量挑战
-
开发者体验对商业价值的重要性
-
开发者体验中的常见问题与解决方案
-
你的工程团队行动过慢的迹象
-
AI 如何提升生产力
-
生产力提升的真实案例
-
介绍她的新书《Frictionless》
-
如何开始建立 DevEx 团队
-
建立开发者体验团队的影响
-
如何衡量 DevEx 团队的影响力
-
衡量 AI 工具对生产力的影响
-
开发者体验的问卷设计
-
受欢迎的开发者 AI 工具
-
为 DevEx 改进带来产品思维
-
AI 角落
-
闪电问答与最终思考
Nicole Forsgren 简介
Nicole: 很多公司正试图衡量他们团队的生产力。但大多数生产力指标都是骗人的。如果目标是更多的代码行数，我可以提示工具写出史上最长的代码。这个系统太容易被操纵了。
Lenny: 我如何知道我的工程团队是否足够快，他们是否能更快，或者他们只是没有发挥出应有的水平？
Nicole: 大多数团队都可以更快，但“更快”是为了什么？我们可以每天都更快地交付垃圾。我们需要战略和非常明智的决策来确定要交付什么。
我们未来在 AI 方面可能遇到的最大问题之一，是学会如何信任它生成的代码。我们不能只是输入一个命令，得到结果，然后就接受它。我们必须评估它。我们是否看到了幻觉 (hallucinations)？可靠性如何？它是否符合我们通常的编码风格？
现在，大量时间将花在审查代码上，而不是编写代码。这里确实存在一些机会，不仅可以重新思考工作流程，还可以重新思考我们组织一天和工作的方式。
现在，一个 45 分钟的工作时段也能变得有用，因为进入心流状态 (flow) 这件事，至少部分地交给了机器，或者机器可以通过提醒我们上下文、生成系统图表来帮助我们重回心流。
Lenny: 你认为工程团队或产品团队在这周或下周能做的一件能帮助完成更多工作的事是什么？
Nicole: 老实说，我认为你今天能做的最好的事情是……
Lenny: 我的嘉宾是 Nicole Forsgren。随着关于 AI 提高开发者生产力的讨论越来越多，更多人开始问：“我们如何衡量这种生产力提升？这些 AI 工具到底是在帮助我们，还是在损害开发者的工作方式？” Nicole 在这个领域的前沿时间比任何人都长。
她创建了最广泛使用的开发者体验衡量框架 DORA 和 SPACE。她撰写了该领域的基础性著作《Accelerate》，并即将出版她的新书《Frictionless》，这本书指导团队如何在 AI 新时代更快地行动并完成更多工作。
她的核心论点是，AI 确实加速了编码，但开发者的速度并没有像你想象的那么快，因为他们仍然需要处理损坏的构建 (broken builds)、不可靠的工具和流程，以及一系列新出现的瓶颈。
在我们的对话中，我们聊了她目前关于如何衡量 AI 生产力提升的最佳且具体的建议；你的团队可以行动更快的迹象；公司在尝试衡量工程生产力时常犯的错误；AI 工具如何帮助和损害工程师（包括进入心流状态）；她关于在公司建立开发者体验团队的七步流程；如何获得支持并衡量这样一个团队的影响力，等等。
这期节目适合任何希望提升其工程团队绩效的人。如果你喜欢这个播客，请不要忘记在 你喜欢的播客应用或 YouTube 上订阅和关注。这对我帮助极大。另外，如果你成为我 newsletter 的年度订阅者，你将免费获得 15 款优秀产品的一年使用权，包括 Lovable, Replit, Bolt, Nadam, Linear, Superhuman, Descript, Whisper, Flow, Gamma, Perplexity, Warp, Granola, Magic Patterns, Raycast, Chapard 和 Mobin。
请访问 lennisnewsletter.com 并点击 "Product Pass"。下面，我为大家请来 Nicole Forsgren。
本期节目由 Mercury 赞助。我使用 Mercury 银行服务已经很多年了，老实说，我现在无法想象用其他任何方式来处理银行业务。我从 Chase 换过来的，天啊，差别太大了。
电汇、跟踪支出、授权团队成员调动资金，都非常简单。大多数传统银行的网站和应用都笨重难用，而 Mercury 的设计则细致入微，体验直观简洁。
Mercury 将你使用资金的所有方式整合到一个产品中，包括信用卡、发票、账单支付、团队成员报销和融资。
无论你是一家寻求支付承包商并从闲置现金中赚取收益的科技创业公司，还是一家需要向客户开具发票并保持收款的代理机构，或是一个需要掌握现金流和多余资本的电商品牌，Mercury 都可以量身定制，帮助你的业务发挥最高水平。
访问 mercury.com，体验超过 20 万企业家喜爱的 Mercury 服务，10 分钟即可在线申请。Mercury 是一家金融科技公司 (fintech)，而非银行。银行服务由 Mercury 的 FDIC 保险合作伙伴银行提供。
更多详情请查看节目简介。这里有一个谜题：OpenAI, Cursor, Perplexity, Vercel, Plaid 以及数百家其他成功的公司有什么共同点？
答案是，它们都由今天的赞助商 WorkOS 提供支持。如果你正在为企业构建软件，你可能感受过集成单点登录 (SSO)、SCIM、RBAC、审计日志 (audit logs) 以及大客户要求的其他功能时的痛苦。
WorkOS 通过一个专为 B2B SaaS 打造的现代化开发者平台，将这些交易阻碍因素转化为了即插即用的 API。
无论你是一家试图签下第一个企业客户的种子期创业公司，还是一家全球扩张的独角兽，WorkOS 都是实现企业级就绪 (enterprise ready) 和解锁增长的最快途径。
它们本质上就是企业功能领域的 Stripe。访问 workos.com 开始使用，或者直接在他们的 Slack 中提问，那里有真正的工程师超快地回答你的问题。
WorkOS 允许你通过愉悦的 API、全面的文档和流畅的开发者体验，构建出最佳产品。立即访问 workos.com，让你的应用实现企业级就绪。
开发者体验 (DevEx) 的概念
Lenny: Nicole，非常感谢你来到这里，欢迎做客播客。
Nicole: 谢谢。很高兴能来到这里。
Lenny: 很高兴你能再次光临。我刚在看我们两年半前的第一期节目。我惊讶又不那么惊讶地发现，我们几乎没谈到 AI。那期节目的标题是“如何衡量和提高开发者生产力”，我们大概在一个小时后才勉强提到 AI，当时我们只是在想：“嗯，AI 会对生产力产生什么影响呢？” 这是否让你感到震惊？
Nicole: 是啊，因为它当时才刚刚崭露头角，是很多讨论的话题。但同时，很多事情并没有改变，对吧？很多事情仍然很重要，很多事情还是一样。嗯，两年半就这么过去了，这也有点疯狂。时间都去哪儿了？
Lenny: 时间是一个社会建构。是啊，我们当时的对话大多是提问，比如：“这可能会如何影响人们？我们将如何改变构建产品的方式？” 而现在，AI 在当时几乎不成气候，如今却似乎成了人们谈论工程生产力时唯一想谈论的话题。这也是我们今天花很多时间关注的。
我之所以对这次对话感到兴奋，是因为似乎有大量的资金涌入 AI 工具，以期提高生产力。所有增长最快的公司都是这些工程 AI 工具。现在越来越多的人在问：“我们从中获得了什么收益？这到底在多大程度上帮助我们提高了生产力？我们如何才能更有效率？” 你涉足这个领域的时间比任何人都长，你发明了许多人们现在依赖的框架。所以我很高兴你能回来讨论这些。
我想从 "DevEx" 这个术语开始，这个词在整个领域中经常出现。我们在这次对话中也会经常听到这个词。你能解释一下 DevEx 是什么吗？
Nicole: DevEx 是开发者体验 (developer experience) 的缩写。当我们谈论开发者体验时，我们实际上是在谈论开发者日复一日构建软件的真实感受。比如他们面临的阻力 (friction)、他们必须经历的工作流程，以及他们获得的任何支持。
这很重要，因为当 DevEx 很差时，其他任何东西都帮不上忙。最好的流程、最好的工具，无论你有什么法宝，如果 DevEx 很糟糕，一切都会大打折扣。
Lenny: 所以 DevEx 包含了生产力。我认为你和这个领域的其他人一个关键见解是，它不仅关乎生产力，还关乎工程师的幸福感。我们会深入探讨这些，但也许你可以先谈谈，除了生产力，还有哪些更广泛的因素能让工程师在公司取得成功？
Nicole: 是的，我喜欢这一点。首先，生产力本身就很难定义。但如果你只看产出 (output)，你可以通过很多不同的方式实现。但如果你实现产出的方式是高负荷 (high toil) 或高阻力 (high friction) 的，那么开发者总有一天会精疲力竭 (burn out)。
或者，如果认知负荷 (cognitive load) 非常高，如果你甚至很难思考你正在做什么，因为你正全神贯注于某些机制的细节，那么你就没有剩下的大脑空间来提出真正创新的解决方案和问题。
所以我喜欢这种良性循环：你做了更多的工作，你做了更好的工作，这对人们更好，对系统更好，对我们的客户也更好。
AI 时代的心流状态与认知负荷
Lenny: 有个问题我本想稍后再问，但现在我想直接问。关于工程师的“心流状态” (flow state)。我职业生涯早期实际上是一名工程师，我大学学的是计算机科学，做了 10 年工程师。对我来说，这份工作最棒的部分就是你在编码和构建时进入的那种心流状态，一切都感觉非常有趣。
感觉 AI 在很多方面让实现这一点变得更难了，因为现在你要和所有这些代理 (agents) 一起工作，有很多代码是为你生成的。谈谈心流状态对开发者的幸福感、生产力的重要性，以及你观察到 AI 是如何影响这一点的？
Nicole: 讨论 DevEx 有很多不同的方式。其中一种方式是谈论三个关键事物，它们本身包含重要组成部分，也相互促进。心流状态是其中之一，认知负荷是另一个，然后是反馈循环 (feedback loops)。
所以，你提到关于心流状态的问题非常好。我得承认，我们进入这个阶段才几年，我们仍在探索什么是最佳的心流状态，以及人们在这方面的认知需求。
因为正如你所说，我们有时会一直被打断。你不能再像以前那样，轻易进入心流，埋头写下一大堆代码，完成大量的输入工作。相反，你现在更像是在创建一个提示 (prompt)，获取一些代码，然后审查代码，试图整合系统中正在发生的事情。
这确实会打断心流。但同时，它也可以促进心流，如果……我见过一些高级工程师构建了非常棒的工具链，他们找到了保持心流的方法。快速的反馈循环对他们非常有效。他们可以把不同的任务分配给代理。
这帮助他们保持心流，不是在细节和逐行编写上，而是在思考“我的目标是什么？我需要哪些部件来实现它？我能多快完成？” 这样他们就可以退后一步，评估全局，然后再深入进去，修复一些部分。
Lenny: 关于那位找到了很酷工作流的工程师，你还能多分享一些细节吗？
Nicole: 我和他们中的几位聊过，也观察过他们工作。我自己还没搭建过，但在我的计划中。他们能够建立起一套非常棒的工作空间和工作流。现在我们很多人可能只是摆弄工具，输入一个提示，得到几行代码，或者输入一个提示，得到整个程序。
而他们能做的是，很多时候，他们会先设定好框架：“这是我想构建的东西。它需要这些基本的架构组件，需要这样的技术栈，需要遵循这样的大致工作流。帮我理清思路。” 然后工具会为它设计出来。
接着，工具会为每个部分指派一个代理去并行工作。然后它会说：“哦，首先，这些部分需要能够协同工作，确保架构正确，确保我们使用了适当的 API 和规范。”
然后他们就可以让它运行几分钟，自己则去思考其他有趣或他们预计会很棘手的事情。当他们再回来时，得到的东西……怎么说呢，可能比凭感觉写的代码 (vibe-coded) 要好一点。因为他们从一开始就非常有系统性，所以他们得到的东西更接近生产代码 (production code)。
Lenny: 所以我听到的是，花更多时间在前期规划所有这些 AI 工程师要做什么，而不是一头扎进去，边做边看。
AI 带来的生产力衡量挑战
Lenny: 好的，酷。让我回到这个我认为很多人都在思考的核心问题。很多公司正试图衡量他们团队的生产力。这个工具是在提高我们的生产力吗？还是在损害它？我的第一个问题是：目前，当公司试图衡量 AI 带来的生产力提升时，他们最常犯的错误是什么？
Nicole: 我会说，大多数生产力指标都是骗人的。这真的很棘手，因为从历史上看，代码行数 (lines of code) 一直是一个糟糕的指标。但许多人仍然使用代码行数作为产出、生产力或复杂性之类的某种代理指标 (proxy)。
好吧，现在，对于许多他们以前可能只敢小声议论的、使用代码行数的系统来说，这个指标已经彻底失效了。因为，你说的代码行数是什么意思？如果目标是更多的代码行数，我可以提示某个工具为你写出史上最长的代码，并添加大量注释。
我们知道，代理 (agents) 和大型语言模型 (LLMs) 天生就非常冗长。所以，这个系统太容易被操纵了，并且这会给你所有的工作带来复杂性和技术债 (technical debt)。
但我必须说，有些事情我们还是可以观察和关注的。代码行数作为生产力指标虽然不好，甚至很糟糕，但现在它反而变得更有意义了——如果我们能区分哪些代码来自人类，哪些来自 AI。
因为现在我们可以回答下游的问题了：代码的存活率 (survivability rate) 是多少？我们的代码质量如何？我们的代码是否被反馈用于训练系统？那些用于再训练系统的代码，特别是当我们进行微调 (fine-tuning) 和本地调整 (local tuning) 时，有多少是机器生成的？这会产生什么样的循环？它可能会无意中引入什么类型的模式或偏见？
所以，一方面，它作为生产力指标不好，但它可能很有用。我甚至会对 DORA 指标说同样的话。我提出了 DORA 指标，它们是速度指标和稳定性指标。如果你只看这些，那是不够的了。
因为 AI 已经改变了我们对反馈循环 (feedback loops) 的看法。它们现在需要快得多。DORA 本意是用于评估整个交付流程 (pipeline) 的速度和稳定性，这仍然有效。但我们不能再盲目地套用以前的指标，因为我们会错过非常重要的现象和人们工作方式的变化。
Lenny: 有趣。所以，你发明了 DORA，它曾是人们长期用来衡量生产力的主要框架。然后还有 SPACE，还有 Core 4，可能还有其他的。所以我听到的是，在 AI 贡献了大量代码的今天，所有这些都有点过时了。
Nicole: 我会说，如果它是一个规范性指标 (prescriptive metric)，它就必须严格按照其规定来使用。DORA 4 有四个关键指标：两个速度指标——部署频率 (deployment frequency) 和交付周期 (lead time)，即从代码提交到代码部署；两个稳定性指标——平均恢复时间 (MTTR) 和变更失败率 (change fail rate)。
如果这些指标被用来评估交付流程的速度和整体性能，那很好。如果你想用它们来理解……因为其中隐含了反馈循环，对吧？你过去需要通过这个来从客户那里获得反馈。
但是，当我们现在使用 AI 时，我们就不能再盲目地使用它了。因为我们现在更早就有反馈循环，甚至不只是在本地构建和测试阶段。我们全程都有反馈循环，有时甚至在交付流程的中间环节，我们非常希望利用这些以前不那么有用的反馈方式。
我不会说它们以前不可能，只是我们没有真正关注那里。所以，这些是规范性指标。当我们谈论 SPACE 时，SPACE 是一个框架 (framework)，它不告诉你该用什么指标。所以，有时候人们会很沮丧，因为我没有告诉他们具体要衡量什么。
但现在我认为这正是它的力量所在。我们实际上发现 SPACE 在像 AI 这样的新兴环境中应用得相当好。因为我们仍然想关注……SPACE 是个缩写：
我们仍然想关注满意度 (Satisfaction)。我们仍然想关注绩效 (Performance)，即结果。我们仍然想关注活动 (Activity)。是的，在某些方面，代码行数和 PR 数量对某些事情可能有用，或者警报数量之类的。
C 是沟通与协作 (Communication and collaboration)。这也非常重要和有用，因为它关乎我们的系统之间如何沟通，以及我们的人员如何沟通。有多少比例的工作被交给了聊天机器人，而不是与团队中的高级工程师交谈？多不总是更好，少也不总是更好，视情况而定。
E 是效率与心流 (Efficiency and flow)。人们能进入心流吗？做事情需要多少时间？我们的系统流程是怎样的？在这里，我可能还会增加几个维度，比如，我和几位早期作者聊过，关于“信任” (trust)。
不是说信任以前不重要，但现在它变得非常、非常重要。以前，你构建代码，如果编译通过了，你就觉得没问题了。但 LLMs 是非确定性 (nondeterministic) 的。现在我们不能只是输入一个命令，得到结果，然后就接受它。我们必须评估它。
我们是否看到了幻觉？可靠性如何？它是否符合我们通常的编码风格？如果不符合，那可以吗？
所以，这就是我那种“视情况而定” (it depends) 的答案。规范性指标，你必须确保它的使用符合其目的。
开发者体验对商业价值的重要性
Lenny: 我们稍后会谈到你目前关于如何做这件事的最佳想法。你即将出版一本书，解释了如何做好这件事，我们会谈到。但我想强调一件事，在我们上次的聊天中，你强调过，我们在 AI 方面可能遇到的最大问题之一是信任，即理解和学会如何信任它生成的代码。而且，你两年半前就说过，现在如此多的时间将花在审查代码上，而不是编写代码。
Nicole: 这正是我听到的。我认为，看看这将如何影响我们未来的工作结构会很有趣。我们之前谈到了心流状态和认知负荷。现在我们的注意力必须在特定时间集中在某些事情上，这与我们过去的方式不同了。我认为这里确实存在一些机会，不仅可以重新思考工作流程，还可以重新思考我们组织一天和工作的方式。
Lenny: 你能多谈谈吗？你认为会发生什么？事情会如何发展？你看到了哪些有效的方法？
Nicole: 这纯粹是推测。但举个例子，Gloria Mark 在注意力和深度工作 (deep work) 方面做了一些非常好的研究。人类一天大约能进行四个小时的优质深度工作，基本就这么多了。
Lenny: 是的，我深有体会。
Nicole: 而且这在大多数情况下几乎是上限了。我肯定会有人说：“我是超人，我能……”
Lenny: 除非你吃了 20 克肌酸。
Nicole: 对，或者微剂量。是的，没错。所以，在知道我们大约只有四个小时优质深度工作时间的前提下……我相信我们很多人可能都经历过，我们都有状态好的时段，也许是早上，也许是下午。然后你会到了某个点，觉得：“我要去清理我的收件箱，因为这是我现在唯一能做的事了。” 对吧？我可以保持基本运转，但我无法进行最有创新性、最能解决问题、最高质量的编码写作工作。
很多时候，要做到这一点，进入心流，你需要有大块的时间来进行深度工作。通常这需要，我这是在比划，至少两个小时。一个小时可能有点悬，因为你需要时间进入状态。
好吧，我们想想以前，在三、四年半前的“古代”，我们可以空出四个小时，大概能完成两三个小时的高质量工作。因为那时我们很专注，没有干扰，或者干扰很少。
而现在，在系统中编写代码的本质本身就是由中断驱动的，或者至少是充满了中断。因为你开始做某件事，然后它会插进来。
那么我们该如何看待这个问题呢？这是否意味着 4 小时的工作时段仍然有用？也许吧。但这是否也意味着，现在一个 45 分钟的工作时段也变得有用了？因为进入心流这件事，至少部分地交给了机器，或者机器可以通过提醒我们上下文、生成系统图表等方式来帮助我们重回心流。
我认为这是一个非常、非常有趣的领域，充满了问题和机遇。请大家去做这个研究，然后回来告诉我结果，因为这可能不在我的研究列表里，但这是个非常棒的问题。
Lenny: 这太有趣了。基本上，每个工程师都在变成一名工程经理 (EM)，协调所有这些初级 AI 工程师。所以你的观点是，即使你只有 30 分钟的空闲，你无法深入编码，但你可以为所有这些正在执行任务的 AI 工程师扫清障碍。而且，它们还会提醒你：“你上次在这里停下了。好了，你可以直接进入这段代码，也许做些调整。” 非常有趣。
让我把视野拉远一点。在我们深入探讨你关于如何处理开发者体验的框架和你最新的想法之前，我想问问，除了“工程师能做更多事情显然很棒”之外，你认为公司应该真正、真正、真正关注开发者体验的最佳理由是什么？
Nicole: 我不想说投资回报 (ROI)，但这里的商业价值 (business value)……机会是巨大的。总的来说，我们写软件，是为了乐趣和爱好，但我们拥有软件也是因为它满足了业务需求。它帮助我们获得市场份额，帮助我们吸引和留住客户，帮助我们做所有这些事情。
我认为 DevEx 之所以重要，是因为它支撑了所有这些软件的创造，支撑了所有这些问题的解决，它使得我们能够与客户进行超快速的实验。而在以前，你可能需要一段时间才能做出原型 (prototype)，可能还需要更长时间才能在生产系统上进行 A/B 测试。现在，你几个小时内就能做到。
开发者体验中的常见问题与解决方案
Lenny: 也许换个角度，在我们探讨更大的框架之前，来点实际的。你认为工程团队或产品团队在这周或下周能做的一件能帮助改善开发者体验、完成更多工作的事是什么？
Nicole: 老实说，我认为你能做的最好的事情就是去和人们交谈，去倾听。我很高兴这个播客的听众主要是产品经理 (PM)，因为他们通常非常擅长这个。
我想说，从倾听开始，而不是从工具和自动化开始。很多时候，公司会说：“好吧，我就要构建这个工具，或者我要做这个东西。” 通常，你构建的东西要么是你自己遇到过挑战的，要么是容易实现、容易自动化的。
但如果你去和人们聊聊，问问开发者：“想想昨天。你昨天做了什么？带我过一遍。哪些地方让你感到愉悦？哪些地方非常困难？你在哪里感到了沮丧？在哪里被拖慢了速度？阻力在哪里？”
如果你和几个人聊过之后，很多时候你能发现一些相对容易解决 (low lift) 但仍有影响力的事情。或者，你能发现一个不必要地复杂和缓慢的流程。
Lenny: 所以，这里的关键是“倾听之旅” (listening tour)。如果你想帮助你的团队行动更快、更快乐，你的建议是，在做任何事情之前，先去问问他们：“是什么在困扰你？”
Nicole: 去问他们。是的，相信我，大多数开发者会非常乐意告诉你什么是坏的，什么是糟糕的。我记得我曾合作过一家公司，他们有一个流程非常困难，是基于一个老旧的主机 (mainframe) 系统，他们可能得把整个系统重构 (replatform)。
所以他们从不去碰它，也不去谈论它。每个人都讨厌它，因为它造成了巨大的延迟。其实，他们所要做的就是改变一个流程。有时候，你所要做的就是改变一个流程。
他们改变了流程，不再需要……我记得好像是某人必须把它打印出来，走下三四层楼，去获得批准，然后另一个人再把它拿上来。所以只是那个中间环节……他们没有重构任何东西，没有重新设计任何主要的东西，他们只是把它改成了发送一封电子邮件。
Lenny: 让我顺着这个思路追问一下，人们最常做的事情是什么？比如，如果你刚开始着手“好吧，我们需要关注工程体验”，你发现最常见的、需要改进的两三个地方是什么？
Nicole: 我会说，我还是会强调那个“流程”。几乎总是有一个流程可以被改进。而且这种改进通常不需要大量的工程投入或人力。
特别是大型公司，总会有一些包含好几个步骤的事情。它之所以是这样，只是因为它一直是这样，但“一直是这样”并不代表“现在也该是这样”。
即使是小公司，有时也只是因为太“YOLO” (You Only Live Once) 了，你不知道流程是什么，你只能到处追着人问。所以，如果你能创建一个非常轻量级的流程，那也会很有帮助。这可能是最好的起点之一，特别是当你对组织其他部分的了解有限时。
有时候，仅仅一个团队内部的流程改进就能奏效。我想说，从业务领导者的角度来看，你能做的很多事情是为这种组织变革提供结构和支持。
沟通你正在做什么，沟通优先级是什么，沟通为什么这件事很重要，庆祝胜利。
因为如果人们只是把这当作一个一次性的、边缘的、完全独立的项目来做，是很难获得良好势头，很难让人们关心并持续参与的。因为它感觉就像又一个无关紧要、不会被庆祝的内部项目。但它实际上对业务有着巨大的潜在回报。
Lenny: 有趣的是，我听到的这些都与工具或技术无关。不是说要迁移到哪个云，也不是说要安装某个新的部署系统。它关乎的是流程、人和组织士气。
Nicole: 是的。当然，技术部分也会非常重要。特别是现在有了 AI，我们正在重新思考构建 (build) 和测试 (test) 系统的工作方式，我们正在重新思考给用户的反馈，以便在共享内容和共享时机上做到非常、非常定制化。
这其中涉及很多技术部分，但技术不是唯一的部分。它是必要的，但不是充分的。而且它也不必是你的起点。
你的工程团队行动过慢的迹象
Lenny: 我想问你一个我在你说话时想到的难题。我觉得这是大多数创始人和负责人都在思考的问题，那就是：“我如何知道我的工程团队是否足够快？他们是否能更快？或者他们只是没有发挥出应有的水平？”
有哪些迹象或信号能告诉你，“是的，我的团队应该行动得更快”，而不是“事情本该如此，这就是他们能达到的最快速度”？
Nicole: 大多数团队都可以更快。不过，考虑到我们对认知负荷的了解，并非所有的速度提升都是好事。或者说，这种提升的上限是有限的。一旦你达到了某个点……但大多数人甚至还远未接近那个点。
坦白说，我不知道有哪个团队是例外。但你如何知道呢？如果你总是听到构建失败、测试不稳定 (flaky tests)、流程过长；如果你需要申请一个新系统，或者你需要配置一个新环境，或者切换任务、切换项目非常非常困难。
对，如果某人有机会去组织的其他部门工作，但他们因为一些不明确、非政治性的原因而不去，并且有人对现有系统颇有微词，这通常就是一个很好的信号，说明某个地方存在阻力。
因为一旦你最终搞懂了你的系统，并且能够完成工作，你就不想……切换成本 (switching costs) 往往会非常高，高到你不想去任何其他地方。
有时候人们会这么做。但我合作过一些公司，在公司内部切换部门，你基本上需要支付和新员工入职相同的“税”，因为系统差异太大，充满了阻力，做很多事情都非常困难。
Lenny: 我特别喜欢你答案的第一部分，那就是“你总能更快”。我想每个创始人听到这个都会很高兴。当然，正如你所说，到了一定程度回报会递减。
Nicole: 是的，而且你还要考虑质量，对吧？所以，另一面是，你总是可以更快，但“更快”是为了什么？我们是否做出了正确的商业决策？
我认为这正是 PM 发挥作用的地方。我们可以每天都更快地交付垃圾。我们需要战略和非常明智的决策来确定要交付什么，要实验什么，我们想按什么顺序、以什么方式推出什么功能。
战略是核心部分，然后再考虑加快它。如果其他部分没有到位，那么，垃圾进来，垃圾出去。
Lenny: 我想沿着这个思路继续，但在那之前，让我复述一下你分享的：你的团队生产力有很大提升空间的迹象是：构建 (builds) 总是失败；存在不稳定的测试 (flaky tests)，总是误报；在不同项目间切换上下文 (context switch) 很困难；你总能听到人们抱怨系统很难用。大致是这样吗？
Nicole: 没错。
AI 如何提升生产力
Lenny: 好的，回到你刚才的观点。有一种感觉是，AI 正在让团队变得快得多，因为它为他们编写了所有代码，你将拥有所有这些异步的 AI 工程师为你工作。但感觉你的一个核心信息是，这只是工程工作的一部分。还有很多其他工作，包括弄清楚要构建什么、内部协调一致。也许你可以谈谈，虽然在提高工程绩效和生产力方面有很多机会，但还有很多其他因素是无法通过 AI 改进的。
Nicole: 是的。或者说，未来也许可以。我认为有很多方法可以引入 AI 工具来帮助我们完善战略、完善信息、思考实验方法或实验目标，或者思考我们的潜在市场规模 (total addressable market)。
但我们需要有相当一致的战略和计划，或者至少有两三个你想测试的替代方案。因为现在工程（至少是原型设计）的速度可以快得多。我们可以快速做出原型，我们可以运行面向客户的 A/B 测试和实验，前提是我们的基础设施到位。
这使我们能够更快地学习和进步。以前，有些地方可能需要几个月才能让产品通过生产环境，进行 A/B 测试并获得反馈。我们现在可以在一两天内完成，绝对不到一周。
但我们要确保我们正在构建和测试正确的东西。我们是否与正确的伙伴合作？我们是否拥有所需的数据？
我想说，AI 在这方面实际上可以是一个很好的伙伴，前提是你和它保持良好的对话，并且你也咨询了你的专家。比如：“我应该关注什么类型的数据？我需要什么样的埋点 (instrumentation)？我可以做什么样的分析？”
因为这样你就可以去找你的数据科学团队说：“我计划做这个。我想……” 因为我们不能只是盲目地进行 A/B 测试。那可能会……如果你做了一个大型测试，结果却干扰了用户或客户，或者违反了隐私或安全协议，并且最后得到的数据还无法使用，那就太可惜了。
因为你无法从中获得你想要的信号。但现在我也看到人们把这个周期加速到了几天，而不是几周。因此，他们可以从一个信息更充分、更完整的起点开始与关键利益相关者进行讨论。
本期节目由 Coda 赞助。我个人每天都使用 Coda 来管理我的播客和社区。我把计划问嘉宾的问题放在那里，我把社区资源放在那里，我用它来管理我的工作流。
Coda 可以这样帮助你：想象一下，在工作中开始一个项目，你的愿景清晰，你确切地知道谁在做什么，以及在哪里可以找到你需要的数据来完成你的部分。事实上，你不必浪费时间搜索任何东西，因为你团队需要的一切，从项目跟踪器、OKR 到文档和电子表格，都存在于一个标签页中——全都在 Coda 里。
通过 Coda 的协作式一体化工作空间，你可以在一个易于组织的标签页中，同时获得文档的灵活性、电子表格的结构性、应用的力量和 AI 的智能。
如前所述，我每天都在使用 Coda，超过 5 万个团队信任 Coda，帮助他们保持一致和专注。如果你们是一个希望提高一致性和敏捷性的创业团队，Coda 可以帮助你们在创纪录的时间内从规划转向执行。
立即访问 coda.io/lenny 尝试一下，创业公司可以免费获得团队版 6 个月的试用。网址是 coda.io/lenny。免费开始使用，并获得 6 个月的团队版。coda.io/lenny。
生产力提升的真实案例
Lenny: 我很欣赏你和许多不同公司、不同类型的企业合作。我想很少有人能有机会深入了解这么多不同的地方。就 AI 带来的生产力提升而言，你看到了什么样的成果？它有多真实？你见过的最大增益有多大？
Nicole: 我会说这是真实的，但我也会说我们还没有很好的衡量标准。我们仍在努力找出要衡量什么以及它看起来像什么。最好的指标之一将是速度 (velocity)，贯穿整个系统的速度。
你能多快地让一个功能、一个产品或某样东西通过整个系统，以便你进行实验和测试？无论是从创意到最终成品，还是一个功能部件通过系统进行测试。这非常好。
当然，这也难以直接归因于某个特定开发者手中的某个特定 AI 工具。
但我们还是可以观察到其他一些事情。我看到的就是这种快速原型设计。
我讨厌代码行数，但我就要用代码行数了。我们确实看到……我知道我曾和一些人合作，他们观察了一整批公司，他们发现，对于那些经常使用 AI 的人来说，AI 生成的代码要多得多。
但他们也发现，对于那些 AI 编码环境、AI IDE 的常规用户来说，工具给他们提供了更多代码，然后工程师自己产出的增长是 AI 代理给他们的两倍。
所以，我会说，这可能是一种次要的或连锁的效应，或者只是一个迹象：它可以为你扫清障碍 (unblock you)。它可以加速你本就要做的工作。我知道我有时工作时，刚开始的几分钟很难启动，但一旦我开始了，我就进入状态了。而 AI 工具非常擅长打破僵局和释放这种状态。
Lenny: 我在 Twitter 上看到有人分享，OpenAI 的 Codex 在查找非常棘手的 bug 方面表现得多么出色。我记得好像是 Karpathy 分享过，他被一个 bug 卡住了，所有 AI 工具都找不到，然后最新版的 Codex 花了大概一个小时研究，最后帮他找到了。
Nicole: 是的，我听到了很多这样不可思议的事情。还有，你知道，编写单元测试 (unit tests)、启动单元测试、创建文档、清理文档。
因为我知道现在人们会说：“哦，我们有代理了，我不需要读文档了，因为代码就在那里。” 事实证明，代理依赖于好的数据。因为它们的一切都取决于它们是如何被训练或被“锚定” (grounded) 的。
更好的数据会给你带来更好的结果。而这些数据中就包括文档和注释。你拥有的文档和注释越好，你的 AI 工具性能就会越好。而且 AI 还可以帮助你编写那些文档。
Lenny: 我最近试用了 Devin，它在这方面确实很擅长。
介绍她的新书《Frictionless》
Lenny: 好的，让我们来谈谈这个框架，这本书。你即将出版一本叫《Frictionless》（无阻力）的书，这听起来像个梦。你如何创建一个无阻力的开发团队？这本书的全名是《Frictionless: Seven Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the Age of AI》（无阻力：在 AI 时代消除障碍、释放价值并超越竞争对手的七个步骤）。这里有一个七步流程。给我们介绍一下吧。也许先介绍一下这本书的背景，它适合谁，解决了什么问题，然后再介绍这七个步骤。
Nicole: 我要说明一下，这本书是我和 Abby Nota（来自 DX 公司）合著的。他在这个领域有着令人难以置信的经验，他与数百家公司合作过。所以，和他交流想法、碰撞火花非常棒。
当然，也要感谢所有与我们交谈过的工程主管、DevEx 主管、CTO 和工程师们，他们帮助我们验证了我们的直觉是正确的。
Lenny: 在你介绍之前，让我先岔开一下，谈谈 Abby 和 DX。这非常有趣，而且与我们的话题直接相关。Abby 创立了这家叫 DX 的公司，这个名字对于一家关注开发者体验的公司来说太棒了。他们刚以 10 亿美元的价格把公司卖给了 Atlassian。
这是他们 ARR (年度经常性收入) 的一个非常高的倍数。对我来说，这恰恰显示了为什么这次对话如此有价值，显示了公司对改善开发者体验是多么重视。Atlassian 愿意为此花费 10 亿美元。这是一家处于早期阶段、做得非常好、深受人们喜爱的创业公司。
但它还处于早期阶段，就卖了 10 亿美元。现在的想法是，他们有所有这些公司在使用 Jira 和他们的产品，他们都在试图弄清楚如何衡量生产力。这对他们来说价值巨大。我知道你也是他们的早期顾问。所以这显示了这件事有多么重要。
Nicole: 是的，我认为这也向我们展示了你能从中获得多大的价值。这里有太多唾手可得的成果 (low-hanging fruit)，有太多未被释放的潜力。
很多时候，你很难知道从哪里开始。即使我待过的大公司，拥有很多专业知识和非常聪明的人，但如果你没有真正涉足这个领域并以这种方式思考过，你还是很难知道从哪里开始，或者很容易在早期犯一些简单的错误，导致你日后不得不重来。
所以，这又回到了你刚才的问题，这本书是为谁写的？它是为任何关心 DevEx 的人写的。所以，绝对包括技术领导者，任何试图启动 DevEx 项目或正在致力于 DevEx 改进项目的人。
我认为它对 PM 尤其重要，因为如果你正在管理一个涉及软件开发和创造的项目，改善 DevEx 只会对你的团队有好处。而且，你拥有对于 DevEx 来说至关重要的关键技能、洞察力和直觉，而这些是我见过工程团队经常会错过的。
Lenny: 好的，那个框架是什么？有哪些步骤？人们该从哪里开始？
Nicole: 这本书贯穿了一个七步流程，最后还提供了一些关键的原则。
第一步是开启旅程。假设你正要启动，你可以从这里开始。这包括我们已经谈到过的：去和人们交谈，进行一次倾听之旅，综合你学到的东西，将工作流程和工具可视化。总之，先掌握现状。
第二步是获得一个快速胜利 (quick win)。从小处着手，获得一个快速胜利，选择正确的项目，分享你所做的事情。
第三步是用数据来优化工作。建立一些你的数据基础，找到已有的数据，开始收集新的数据，使用一些问卷来获得快速的洞察。书中也包含了示例问卷。
第四步是决定战略和优先级。一旦你有了一些数据，你就需要知道，在所有可能出问题的事情中，在你已经取得了快速胜利之后，在剩下的事情中，你下一步该做什么？这里我们介绍了一些评估框架。
第五步是推销你的战略。一旦你做出了决定，现在你必须说服其他人。你需要获得反馈，你需要分享为什么这是当下正确的战略。
第六步是在你的规模上推动变革。这里我们讨论了拥有“本地控制范围” (local scope of control) 的人（比如你只是在一个开发团队中开始，你想自下而上地推动）和拥有“全局控制范围” (global scope of control) 的人（比如你是开发者体验的副总裁，你可以利用一些资源自上而下地推动）。
以及当你处于两者之间时，你该如何推动变革。因为你可以同时利用这两种策略。
第七步是评估你的进展并展示价值。然后循环往复。
我们编写这本书的方式是，你可以根据你目前所处的阶段，直接跳到任何一步。比如，如果你刚启动一个团队或项目，你可能想从第一步开始，你也绝对应该从第一步开始。如果你是加入一个现有的项目，你可以直接跳到选择优先级或实施变革的步骤。
所以，这就是七个步骤。我们还推荐了一些实践，比如思考如何为其配备资源、如何进行变革管理 (change management)、如何使技术可持续发展，以及如何为这件事带来产品经理 (PM) 的视角。
我们该如何将开发者体验视为一个产品 (product) 来看待？我们该如何将我们拥有的指标 (metrics) 视为一个产品来看待？
Lenny: 太棒了。好的，我有问题。先告诉大家书的地址。网址是什么？怎么买？什么时候出版？
Nicole: 网址是 developerexperiencebook.com。现在你可以注册邮件列表，当它开始预售时我们会通知你。我们也会分享一部分工作手册 (workbook) 的内容。我们有一本近 100 页的工作手册与书配套。这本书应该会在年底前出版。
Lenny: 好的。这里面有一个点，“开发者体验” (developer experience) 这个词感觉是刻意选择的，而不是“开发者生产力”或“开发者工作”。它强调的是“我们如何让我们公司里的开发者体验更好”，这包括了让他们完成更多工作，也包括让他们更快乐，等等。我认为这是很重要的一个元素。
Nicole: 绝对的。因为，这不仅仅是关于生产力。我们从这个框架和视角谈论过，我们需要构建正确的东西。你希望提高生产力，但你也希望去思考……这也是工程师们非常擅长的：
给他们一个问题，不要告诉他们如何解决，然后他们能更好地解决它。他们拥有自由、创新和创造力来解决这个问题。
如果只关乎生产力，那它就变成了代码行数或 PR 数量之类的东西。但我们真正想谈论的是价值 (value)，以及我们如何释放价值，如何更快地获得价值。
这其中，是的，包括了让他们更有生产力，移除阻力，因为这样他们才能拥有我们之前谈到的心流、认知负荷等东西。
如何开始建立 DevEx 团队
Lenny: 好的。那么，假设有人想开始组建这个团队，它通常是什么样子的？我记得在 Airbnb 这个团队刚成立时，就是一两个工程师开始并主导的。你推荐的试点团队 (pilot team) 是怎样的？它在成长过程中又会变成什么样？
Nicole: 有几种方法可以做到这一点。如果你是自己做，你可以和几个工程师一起，也许再加一个 PM、PGM (项目经理) 或 TPM (技术项目经理) 来帮助沟通，因为沟通计划在这里真的非常重要。
在小规模上，我们要做的是寻找那些快速胜利。寻找那些你可以在小范围内做的事情。有没有一些……有些人称之为“小割伤” (paper cuts)？有没有一些小事，你可以做了之后，帮助人们看到价值并亲身感受到好处？
开发者的工作能如何改善？他们日常的工作能如何改善？从那里开始积累势头。
如果你是从一个自上而下 (top-down) 的结构开始，并且你拥有授权 (remit)，你仍然需要一些快速胜利，但这些快速胜利在规模上可以看起来更全局化一些。因为你拥有基础设施或支持，可以做出一些不只是局部的变革。
所以，举个例子，一个小的局部变革可能只是清理你的测试和测试套件 (test suites)。任何团队都可以做到。而更全局的变革可能是改变一个全组织范围内的、过于繁琐的流程，或者投入一些资源来清理配置环境 (provisioning environment)。
建立开发者体验团队的影响
Lenny: 从这类团队的组建中，你看到了它们对公司工程团队产生了什么样的影响？
Nicole: 我会说我看到了巨大的影响。对于小公司来说，是几十万美元；对于大公司来说，是数十亿美元。
因为，我们还需要学会如何传达这一点。比如，这个数学题是怎么算的？我们很多时候可以着眼于节省时间，节省成本。
我们可以看很多不同的东西。我们可以看价值实现速度 (speed to value) 或上市速度 (speed to market)。我们可以看风险降低。
但收益确实存在。我想提一下，它往往遵循一种 J 型曲线 (J-curve)。你会先有几个快速胜利，看起来像是巨大的成功。然后你会遇到一个小低谷，因为那些最明显的、唾手可得的果实已经被摘完了。
所以现在我们需要做一点深入的工作。我们可能需要构建更多的基础设施，我们可能需要构建更多的遥测 (telemetry)，以便我们能捕捉到我们想捕捉的东西。一旦我们完成了这些，我们就会开始看到这些好处真正地复合增长。
如何衡量 DevEx 团队的影响力
Lenny: 回到那个衡量数字上，你有什么建议？人们如何找到这些数字？因为我认为这正是这件事的力量所在，比如“我们这样做节省了一百万美元”。你会看哪些数据来算出这个？
Nicole: 我认为有几件不同的事情要记住：谁是我们的关键受众？我们通常有几个关键受众。
我们非常希望能和开发者对话，因为他们是使用这些系统的人。他们会与你合作，要么是构建系统，要么至少是提供关于你所做事情的反馈。
所以对他们，我们通常希望用他们关心的东西来组织语言。比如，节省时间。如果某件事变快了，他们就能节省时间。他们不再需要花时间在不必要的设置上。
与此相关的是减少苦差事 (toil)。合规 (compliance) 和安全 (security) 非常重要。但很多时候，这需要好几个手动步骤，我不能说它们没有附加值，但从个人角度来看，它们不是高价值活动。如果我们能尽可能地自动化，那就太好了。
还有，提高专注度。这是从开发者的角度来看。
领导层 (leadership) 通常也关心这些事情，但他们往往更关心其他事情。所以我们可以谈论，通常是成本和金钱。
我们能加速收入吗？我们的价值实现时间 (time to value) 是怎样的？我们的速度 (velocity) 如何？我们能多快地从客户那里获得反馈？
对于那些处于竞争激烈环境中的人和组织来说，这可能非常有说服力，因为这一切都关乎速度。
我们也可以谈论省钱。在这里，我们可以看看如何量化节省的成本。举个例子，测试和构建。如果我们能清理一个测试和构建套件，对开发者来说，他们真正想听到的是节省了时间，系统更可靠了。
苦差事减少了，因为他们不必一直重新运行测试或去清理测试套件。
从业务角度来看，清理测试和构建套件可以节省云成本 (cloud cost savings)。因为所有这些测试都在云端的某个地方运行。如果它们总是失败，或者只是在浪费开支，那么节省这笔钱就很有用。
或者，是释放了部分生产力 (recovering some capacity)。我们总能谈论时间和生产力的收益。比如，我们在那些不一定能增加价值的事情上，损失了多少等效的开发者时间？
有时，我们还可以将其与业务成果相关联 (correlate to business outcomes)。“关联”通常是我们能做到的极限，但在加快价值实现时间和增加市场份额方面，可以存在一些非常有说服力的相关性。
衡量 AI 工具对生产力的影响
Lenny: 让我顺着这个思路，回到我认为目前人们对 AI 和生产力最大的疑问上。我想现在还没有人有答案，但我很好奇你的看法：对于“AI 工具对他们的生产力产生了什么影响”这个问题，人们今天应该做什么？什么是最好的方法？
因为他们在这上面花了很多钱，他们会想：“我不知道我们从中得到了什么。我猜事情是变快了，但我不知道。” 所以，如果有人必须得做点什么，你对衡量 AI 工具对生产力影响的最佳建议是什么？
Nicole: 我会说，这视情况而定 (it depends)。部分取决于你的领导层真正关心什么。我们通常很擅长弄清楚什么对开发者重要，我们可以把这些传达给他们。
但是，如果我们试图只找出两三个数据点来真正关注，因为当我们刚开始接触数据时，有时会很有挑战性。他们关心什么？
想想你一直听到的信息。他们是在谈论市场份额吗？比如失去市场份额，或市场上的竞争力？如果是这样，那就关注速度。
想办法捕捉速度指标，比如从功能 (feature) 到生产 (production)，或从功能到客户，或从功能到实验，以及那个反馈循环是怎样的。
如果他们一直在谈论利润率 (profit margin)，现在我们总是在谈钱，因为这是商业，但如果这似乎是一个主旋律，那就寻找可以省钱的方法。
然后将其转化为收回的人力成本 (headcount cost)。或者有时候，你会重塑一个流程，然后你不再需要那么多供应商 (vendors) 了。所以，减少供应商支出也会有帮助。
我之所以说“视情况而定”，还因为有时候他们会说一些话，比如领导层会说一些话，这会成为一个主题。如果你能解决他们遇到的问题，或者这是他们关注的事情，如果你能稍微重新定义一下它，
比如，如果他们把一切都称为“开发者生产力”，那你就叫它生产力。如果他们称之为“速度” (velocity)，并且速度对他们很重要，那就想想如何从速度的角度来阐述这件事。如果他们在谈论“转型” (transformation) 或“颠覆” (disruption)，
那么这件事如何帮助实现颠覆？因为这样才能引起他们的共鸣。我们不想让他们费力去理解我们正在做什么以及我们提供的价值。
Lenny: 这个建议真是太好了。所以，总结一下，这里的建议是，如果你的公司试图弄清楚 AI 工具对公司产生了什么影响，首先要弄清楚：公司最关心什么？领导最关心什么？
可能是市场份额，可能是利润率，可能是速度（我们需要更高的速度），或者我们需要转型。你的建议是，根据你听到的词汇和短语来弄清楚这一点，然后想办法去衡量它。
衡量市场份额增长的方法，衡量利润率提高的方法。所以，可能是，我喜欢这些例子，比如从功能创意到生产或实验的时间。也许可以开始跟踪这个。
如果是利润率，那可能是因为测试失败减少或某个不再需要的供应商而节省了多少钱。
然后是速度……速度，我想这就是 DORA 指标发挥作用的地方，比如工程交付的速度，或者你会怎么看？
Nicole: 我会说，这实际上是……我会选择一个尽可能宽的范围。所以，如果你能衡量从创意到客户，或从创意到实验，这需要多长时间？
通常需要多长时间？现在，在改进了 AI 工具的使用和减少了阻力之后，它又需要多长时间？
在这里，我要说，我们在书中也谈到了一点，我们如何处理归因 (attribution) 挑战？比如，这是谁的功劳？是 DevEx 还是 AI？
那就直接披露。说：“是的，我们推出了 AI 工具。我们也在 DevEx 上做了努力。它们紧密合作。两者可能都对此做出了贡献。”
比如，如果我们有 AI 工具，但没有 DevEx 的改进，我们可能也会有一些改进，但远不会有这么多。
Lenny: 如果人们今天刚开始做这件事，他们会说：“我想开始衡量开发者体验”，是否有一两个或三个几乎每个人都需要、应该立即开始衡量的指标？
Nicole: 如果你刚开始，什么都没有，那显然是先去和人交谈。在那之后，我会做问卷调查。
因为问卷可以让你快速地对整体情况有一个大致的了解，这样你就知道最大的挑战在哪里。
我之所以这么说，是因为如果你刚开始，你可能还没有在你的系统中埋点，没有所有的指标。如果你已经有了，它们也可能不是你想要的。
那些没有目的而设计的指标是有问题的。那些为其他目的而设计的指标，它们可能适用于你的需求，也可能不适用。所以我们不能想当然地认为我们已经有了。
这就是我喜欢问卷的一个原因。我们在书中也提供了一个例子。你可以只问几个问题：
“你有多满意？你生产力最大的障碍是什么？或者完成工作最大的挑战是什么？”
让他们选择，可以是从一系列工具中选，也可以是从一系列流程中选。然后，让他们选三个。
就三个。在这三个中，这件事对你影响的频率是怎样的？是每小时、每天、每周，还是每季度？
因为有时候它每天都影响你，你对此非常恼火。有时候它只在每季度影响你一次，因为是季度末，但它极其繁重。
然后，再加一个开放式问题：“还有其他我们应该知道的吗？”
这能给你带来非常宝贵的信号。因为通过让人们优先选择最重要的三件事……如果你让他们选择所有事情，数据会变得超级混乱。
但三件事，加上频率，你就可以得出一个分数，或者你想要的加权分数。然后你就可以去深入挖掘：“数据应该在哪里？我们需要什么数据？”
而且，这样你至少有了一个基线 (baseline)。它会是一个主观的基线，但现在你知道了最大的挑战是什么。
开发者体验的问卷设计
Lenny: 我喜欢这一切又回到了“从与人交谈和询问开始”，这和产品管理、构建出色产品非常相似——你和你的客户聊过了吗？每个人都认为自己在这么做，但大多数人做得远远不够。
Nicole: 是的。我想说，当你开始获取数据时，有一件很有挑战性的事：访谈是数据，这很重要。问卷则更量化一些，因为我们可以把它转化成计数。
但也正是在这里我们要小心。很多人在写问卷问题时，会问这样的问题：“在过去的一周里，构建和测试系统是缓慢还是复杂？”
你在这里其实问了四个不同的问题。如果有人回答“是”，那到底是指构建 (build) 还是测试 (test)？是指缓慢 (slow) 还是指不稳定 (flaky) 或复杂 (complicated)？
所以，你很难弄清楚你到底得到了什么信号。因此，花点时间与熟悉问卷设计的人聊一聊是值得的。
或者和 Claude、Gemini 或 ChatGPT 聊一聊：“这是我的问卷问题，或者你能帮我提一些吗？”
然后确保你多花几轮来打磨：“这是一个好的问卷问题吗？我从得到的数据中能回答什么问题？我能解决什么问题？”
如果你不能用数据来回答一个问题，那就不要收集它。
Lenny: 你的书里有示例问卷，供那些想直接复制粘贴、不想费脑子的人使用吗？
Nicole: 有示例问卷，有很多示例问题。我们甚至会建议格式应该是什么样的，流程应该是什么样的，应该多长，不应该多长。
Lenny: 我读到一篇文章说，你不太喜欢“幸福感调查” (happiness surveys)，特别是问工程师他们有多“幸福”。这是真的吗？如果是，为什么？
Nicole: 我不喜欢。我要说明一下，我不喜欢幸福感调查，因为有太多因素会影响幸福感。幸福感是一个很大的概念。
幸福感关乎工作，关乎家庭，关乎爱好，关乎周末。有太多的事情构成了幸福感。
这并不是说我不关心幸福感。我只是认为幸福感调查在这里不是特别有用。
有用的是“满意度” (satisfaction)。人们会说：“这不一回事吗？” 不一样。因为你可以问：“你对这个工具满意吗？” 然后再问一些后续问题。
当然，这两者是相关的。因为你对你的工作、你的工具、你的团队越满意，这就会提升你的幸福感。
我过去常开玩笑，记得加州那个“快乐的奶牛产出快乐的奶酪”的旧广告吗？那是最棒的。
快乐的开发者 (Happy devs) 产出快乐的代码 (happy code)。他们编写更好的程序，做更好的工作，他们是更好的团队成员和合作者。
但是，试图去捕捉并直接影响幸福感……这不是我们在这里要做的。这太难了，范围太广了。而满意度可以给我们提供一些信号。
受欢迎的开发者 AI 工具
Lenny: 换个完全不同的话题，在你看到的人们使用的工具中，有没有哪些是你觉得“哦，是的，这个工具对人们来说普遍很棒”，或者“人们发现这个工具非常好用”？比如，除了常见的 Copilot, Cursor 之外，还有什么突出的你想分享的吗？
Nicole: 我认为是这些工具的用法。Copilot, Cursor, Gemini, Claude……
Lenny: Code……是的，Claude Code。
Nicole: 我爱 Claude Code。
Lenny: 我也是。我正准备写一篇关于如何将 Claude Code 用于非工程场景的文章。它太好用了。
Nicole: 非常有趣。
Lenny: 举个例子，用 Claude Code：“帮我找到清理我笔记本电脑存储空间的方法。” 它就会告诉你：“这里有一堆文件……” 它就像一个运行在你电脑上的 ChatGPT，可以为你做各种疯狂的事情，就像一个小小的神。
Nicole: 哇，我马上去试试。这太棒了。
Lenny: 它非常好用。是的，这就是我写这篇文章的原因。我请了 Dan Shipper 来播客，他说 Claude Code 是最被低估的 AI 工具，因为人们没有意识到它的能力。它不仅仅是用来编码的，而这正是我在不断探索的。
为 DevEx 改进带来产品思维
Lenny: 好的，还有没有什么你认为对人们有价值、能帮助他们改善开发者体验、帮助他们适应这个 AI 和工程的新世界，而我们还没有谈到的？
Nicole: 我认为，总的来说，很重要的一点是，要为任何类型的 DevEx 改进，以及我们收集和捕捉的指标，带来一种“产品思维” (product mindset)。
我的意思是，我们要识别问题。确保我们正在为一群用户解决问题。
我们要考虑创建 MVP (最小可行产品) 和实验，并获得快速反馈，进行一些快速迭代。
我们要有战略。我们想知道我们的潜在市场是谁。我们想知道什么是成功。
我们基本上要有一个“推向市场” (go-to-market) 的功能。我们需要有沟通。我们需要从我们的客户（开发者）那里获得持续的反馈。我们想不断改进。
在某个时刻，我们还要考虑“日落” (sunsetting) 某个东西。它是处于维护模式，还是应该被淘汰了？
我认为这在通常情况下很重要，但在现在尤其重要。因为当我们在使用 AI 工具、将 AI 嵌入到我们的产品中时，事情变化得如此之快，
以至于我们很有必要停下来想一想：“好吧，我现在到底想解决什么问题？这个我们已经用了 10 年的指标还重要吗？还是应该让它日落了？”
因为它已经不重要了，它已经不能驱动我需要的决策和行动了。
AI 角落
Lenny: 在我们进入激动人心的闪电问答环节之前，我想带大家进入“AI 角落” (AI Corner)，这是本播客的一个常规环节。你是否在生活或工作中发现了 AI 工具的某种用法，你觉得很有趣，想分享给大家，或者对其他人可能有用？
Nicole: 我最近在做一些家居设计，比如重新装修房间之类的。
我请了一个设计师，因为我知道我喜欢什么，但我不知道如何实现它。我不擅长这个。
但我发现用 ChatGPT 和 Gemini，特别是用它们来帮我渲染 (render) 图片，真的很有趣。我可以给它平面图，给它一张房间的照片，那张照片绝对不是它应该有的样子。然后我再给它几张不同东西的图片。
然后我就可以告诉它：“改变墙壁的颜色”，或者“改变家具布局”，或者其他什么。它就能帮我，而且速度相对较快。
它帮助我把我脑中的东西可视化。还是那句话，我知道我喜欢什么，但我不知道怎么实现，所以我至少知道我喜不喜欢它。这可能是一个非常奇怪的用法，但目前为止还挺好玩的。
Lenny: 我妻子在做完全一样的事情。她不停地发给我：“看这个地毯在我们客厅会是什么样子。看这个水景。”
这太好用了，而且越来越好。它真的能做到：“这分明就是我们的房子，只是换了新地毯。”
你所要做的就是上传这两张照片，然后问：“这个东西在这个房间里看起来怎么样？”
Nicole: 有几次我都被它震惊了。很明显，机器在听我们说话。
它给了我一个房间的模型，然后它在里面扔了一个狗窝，因为我有狗。
我心想：“我可没让你这么做。” 但是，是的，这可能就是我应该在这个房间里放的狗窝的颜色和风格。
Lenny: 说到这个，你试过这个用法吗：问 ChatGPT：“根据你所知道的关于我的一切，生成一张你认为我的房子长什么样的图片”？
Nicole: 还没试过。
Lenny: 因为它有记忆，它记得你谈论过的一切。这超级搞笑，你一定要试试。
Nicole: 好的，这在我的待办事项上了。
闪电问答与最终思考
Lenny: 好了，一个附赠的用法。Nicole，我们到了激动人心的闪电问答 (lightning round) 环节。我有五个问题问你，准备好了吗？
Nicole: 准备好了。开始吧。
Lenny: 你最常向他人推荐的两三本书是什么？
Nicole: Peter Attia 的《Outlive》。非常棒。
另一本可能相关的，我的背受伤了，不太好。Stuart McGill 的《Back Mechanic》（背部修理工）非常不可思议。
所以，向所有下背部受伤的人推荐。它适合非专业人士阅读，弄清楚如何修复下背部问题。这有点冷门。
我还要说，我喜欢《How Big Things Get Done》（大事如何做成）。我发不出那个名字，作者好像是斯堪的纳维亚人。
它剖析了近代历史上一些真正大型的项目，分析了它们在哪里失败了以及为什么失败。
我认为这对我们思考很有意思，尤其是在当下的 AI 时刻，我们基本上所有的软件系统都将发生改变。那么，我们该如何着手这个本质上将是一个非常庞大的项目？
哦，抱歉，我再加一本。Michael Lewis 的《The Undoing Project》（橡皮擦计划）。是 Matt Velos 推荐给我的，非常好看。
Lenny: 是的。我读到最后一句话时倒吸了一口凉气。
Nicole: 哦，那本书……是的，它……
Lenny: 我读过，但我完全不记得最后一句话了。天啊。好吧，下一个问题。你最近看过并喜欢的电影或电视节目是什么？
Nicole: 我会说我看了《Love is Blind》（爱情是盲目的）。如果我一天结束时需要放松一下，《Love is Blind》很有趣。新的一季出来了，很兴奋。
还有《Shrinking》（诚实顾问）。你看过吗？
Lenny: 没有。我好像开始看了……那个关于治疗师的……是的，我试过。
Nicole: 好的，好的。
Lenny: 酷。你最近有没有发现什么你真正喜欢的产品？可以是一个应用 (app)，一个厨房小工具，一件衣服……
Nicole: 嗯，是的，Ninja Creamy。我上次是不是说过了？
Lenny: 我不确定。但肯定有人说过，我到现在还记得。它就像一个……你可以用它做冰淇淋之类的，对吧？
Nicole: 是的，你基本上可以冷冻一杯蛋白奶昔，然后它会把它变成冰淇淋。非常美味。
哦，还有一个是 Jura 咖啡机。我喜欢好咖啡，但我不擅长制作。所以我只要按一下按钮，它就能给我任何我想要的，包括拿铁、卡布奇诺等等。这挺好玩的。
Lenny: 酷。好的。
Nicole: 糖和咖啡因，我需要它们来撑过一天。
Lenny: 这就是工程生产力的 101。天啊。好吧，还有两个问题。你有没有最喜欢的生活座右铭，在工作或生活中经常觉得有用，并以各种方式回归到它？
Nicole: 有一个想法我经常想到，它不是一句逐字逐句的话，更多的是一种感觉：马后炮 (hindsight is 20/20) 谁都会，但它其实很蠢。
我认为，如果我们当时在可获得的信息下尽力做出了最好的决定，那么，事情就是这样了。
如果你因为做了一个糟糕的决定而做出了糟糕的决定，并且你本该知道得更多、你本该有那些信息，那就不太好了。但我认为，我们对自己和他人都没有给予足够的宽容 (grace)，因为我们总是在事后才发现更多的信息。
Lenny: 说得好。最后一个问题。我本来想问你别的，但在我们准备这次访谈时，你分享了你在 Google 有了一个新角色。也许可以谈谈这个，你在那里做什么？为什么加入 Google？有什么大家应该知道的吗？
Nicole: 当然。我是核心开发者 (Core Developer) 部门的开发者智能 (Developer Intelligence) 高级总监。这非常令人兴奋和有趣，因为这正关系到我们一直在谈论的所有事情。
它专注于 Google 及其所有产品和它们的底层基础设施。我们如何能改善开发者体验、开发者生产力、速度，以及我们谈论的所有这些事情？
因为我算是那个负责“数字”的人，所以，我们该如何思考衡量它？衡量方式有何变化？反馈循环有何变化？我们如何能全程改善体验？
然后，如何以一种有意义、有影响力且比以往更快的方式，在整个组织中推动这种变革？
Lenny: Google 挖到 Nicole 真是干得漂亮。大赢。我得马上去买点 Google 股票。
好的，两个后续问题。如果人们想在网上找到你，或者想深入了解你的书，他们可以在哪里找到？以及，听众能为你做些什么？
Nicole: 在线的话，你可以在 developerexperiencebook.com 找到这本书。
我个人在 nicolefv.com 和 LinkedIn 上。我偶尔会刷 LinkedIn，但那里有时挺乱的，我试图在所有噪音中穿行。
至于能为我做什么，请注册以获取关于书和工作手册的信息。工作手册是免费的。我很想得到大家关于哪些内容有效、哪些无效的反馈。我总是喜欢听那样的故事。
Lenny: Nicole，非常感谢你来到这里。
Nicole: 谢谢你的邀请，Lenny。
Lenny: 我的荣幸。再次感谢。再见，各位。
非常感谢你的收听。如果你觉得本期节目有价值，你可以在 Apple Podcasts, Spotify 或你最喜欢的播客应用上订阅。
也请考虑给我们评分或留言，这对其他听众发现这个播客真的很有帮助。
你可以在 lennispodcast.com 上找到所有往期节目或了解更多关于本播客的信息。我们下期节目再见。
