2025年如何衡量AI开发者的生产力 | Nicole Forsgren

所以这里的倾听之旅主要是你想帮助团队更快行动、更快乐，特别是边缘团队。

So the listening tour here most is you want to help your teams move faster, be happier, edge teams.

你的建议就是：在采取任何行动之前，先去问问他们什么在困扰着他们。

Your advice is just before you do anything, just like go ask them what is bothering you.

去问问他们。

Go ask them.

是啊。

Yeah.

相信我，大多数开发者都会非常乐意告诉你哪些地方有问题、哪些地方很糟糕。

And trust me, like most developers are gonna be more than happy to tell you what's broken and what's bad.

我要说的是，我曾与一家公司合作过。

And I'll say there was one company that I had worked with.

我记得他们有一个流程非常复杂，运行在旧的大型机系统上，他们不得不重新设计整个系统。

I remember they had a process that was really difficult and it was on an old mainframe system and they were going have to replat the whole thing.

所以他们从未着手解决或讨论过这个问题。

So they never went to work on it or talk about it.

所有人都讨厌这个流程，因为它造成了巨大的延误。

Everyone hated it because it was this huge delay.

他们只需要改变一个流程。

All they had to do was change a process.

有时候你只需要改变一个流程——他们调整后，我记得原本需要有人打印出来，走下三四层楼去审批，然后再有人走上来送回。

Sometimes all you have to do is change a process and they changed it so that instead of I think it was someone had to like print it out and walk it down three or four flights and then get approval and then someone else had to like walk it back up.

所以这只是个过渡方案。

And so it was just that interim.

他们没有重新设计任何东西。

They didn't replet anything.

没有对主要部分进行任何重构。

They didn't redesign anything major.

他们只需要发一封邮件。

They just had to send an email.

让我追问一下。

Let me push on that.

我很好奇，人们最常做的事情是什么？

And I'm curious just what are the most common things people do?

比如刚开始时，我们需要重点关注工程经验。

Like, if you're just starting on, okay, we need to focus on engineering experience.

你觉得最常见的两三个需要公司改进的地方是什么？

What do you find are the most like, I don't know, two or three most common improvements companies need to make?

我想说，我会某种程度上呼应那个流程。

I will say, I'll kind of echo that process.

几乎总有一个可以改进的流程，而且不需要大量工程投入或增加工程人员就能优化。

There's almost always a process that can be improved and that can be improved without a lot of engineering lift or a lot of engineering headcount.

对吧？

Right?

尤其是大多数大公司，都存在某些需要多步操作的流程。

Most large companies in particular have something that is several, several steps.

它之所以这样是因为历来如此，但现状已经不同了。

It's the way it is because it's the way it is, but that's no longer the way it is.

对吧？

Right?

即便是小公司，有时也太过'活在当下'，你搞不清状况，只能追着大家跑。

And even small companies, sometimes it's just a little too YOLO and you don't know what it is and you're kind of chasing everyone around.

所以如果能建立非常轻量化的流程，也会很有帮助。

So if you can create a very lightweight process, that can also be helpful.

这可能是最好的切入点之一，特别是当你对整个组织其他部分了解有限时。

That can be one of the best places to start, especially if you have limited exposure to the whole rest of the org.

对吧？

Right?

有时候仅团队内部流程优化就能见效。

Sometimes just a team process can help.

从企业领导者的角度来看，我认为你能做的主要是为这次组织变革提供架构支持。

I will say from a business leader standpoint, a lot of what you can do is provide structure and support for this organizational change.

要传达你们正在做什么，传达优先事项是什么，传达这件事的重要性，并庆祝取得的胜利。

Communicate what you're doing, communicate what the priorities are, communicate why this is important, celebrate wins.

因为如果人们只是把它当作一个孤立的一次性项目来做，就很难形成良好势头，也很难让大家真正关心并持续参与其中。

Because if folks try to do this just like a one off side fully isolated project, it's really challenging to get some good momentum and get people to care and to get them stay involved.

对吧？

Right?

因为这感觉就像是另一个临时的内部项目，既无关紧要又得不到认可，但它其实能为企业带来巨大的潜在回报。

Because it feels like just another interim internal project that isn't gonna matter or that isn't gonna get celebrated, but it has these huge upside potential returns for the business.

有趣的是，我在这里听到的内容完全没有涉及工具或技术。

It's interesting what I'm hearing here is nothing about tools or technologies.

不是说'迁移到这个云平台'。

It's not like move to this cloud.

也不是说'安装这个新部署系统'。

It's not like install this new deployment system.

而是关于流程、人员和团队士气。

It's processes and people and Oregon morale.

是的。

Yeah.

当然其中也会涉及非常重要的技术环节，对吧？

Now there will be technical pieces that are very important, right?

特别是现在有了人工智能，对吧？

Especially now with AI, right?

我们正在重新思考构建和测试系统的运作方式。

We're rethinking how build and test systems work.

我们正在重新设计用户反馈机制，使其在内容分享和时机选择上都能做到高度定制化。

We're rethinking feedback to users so that it's very, very customized in terms of what is shared and when it is shared.

涉及许多技术环节，但这并非全部。

There are a lot of technical pieces that are involved, but that's not the only thing.

这是必要的，但还不够充分。

It's necessary, but not sufficient.

而且那不一定是你必须开始的地方。

And that doesn't have to be the place that you start.

我要问你一个问题。

I'm gonna ask you.

我有个棘手的问题想问你，这是听你讲话时想到的。

I have a hard question I wanna ask you that I thought of as you were talking.

我觉得这是大多数创始人和负责人都会思考的问题。

I feel like this is the question that most founders and heads think about.

问题就是：我如何判断我的核心团队是否在以足够快的速度推进？他们能否更快？还是说他们本可以表现得更好？

And the question is just like, how do I know if my edge team is moving fast enough if they can move faster, if they're just not performing as well as they can?

有哪些迹象能表明团队应该加速，而不是认为现状就是正常速度？

What are just maybe smells, signs that tell you, yeah, my team should be moving faster versus like, this is just the way it works.

这就是他们能达到的最快速度了。

This is as fast as they can move.

大多数团队都可以更快。

Most teams can move faster.

而且

And also

根据我们对

given what we know about

认知负荷的了解，并非所有速度提升都一定是好事。

cognitive load, not all speed gains are necessarily good.

或者说收益可能会比较有限。

Or the upside is gonna be kind of limited.

对吧？

Right?

一旦达到某个临界点，大多数人甚至都还没接近那个点。

Once you hit kind of a certain point, most people are not even near that point.

老实说，我连一个这样的团队都不认识。

I don't know a single team, frankly.

但你怎么知道呢？

But how do you know?

如果你总是听到构建失败、测试不稳定、流程冗长这些问题。

You know if you're always hearing about bills breaking, flaky tests, over long processes.

如果你需要申请新系统或配置新环境，或者切换任务/项目极其困难。

If you have to request a new system or if you need to provision a new environment, or if it's really, really hard to switch tasks or switch projects.

所以如果有人有机会调去其他部门却因不明原因（非政治因素）不去，且任何人提到系统问题，这通常是个明显信号——系统存在摩擦点。因为当你终于熟悉系统能顺利工作时，转换到其他地方的切换成本往往高得惊人。

So if someone has an opportunity to go work another part of an org and they don't for reasons that are unclear and not political and anyone says anything about the system, that's usually a pretty good smell, that there's friction somewhere because once you finally figure out your system and you're able to get work done, you don't the switching costs can often be really, really high to go anywhere else.

确实有人会这么做，但我合作过的公司里，内部调岗基本要和新员工缴纳同样的'适应税'，因为各系统差异巨大且充满摩擦，做任何事都困难重重。

And so sometimes people do that, but I've worked with companies where switching orgs within the company, you had to basically pay the same tax as a new hire because the systems were so different and they were so full of friction and it was so difficult to do so many things.

我特别喜欢你回答的前半部分——永远可以更快。

I love the first part of your answer especially, which is you can always move faster.

我觉得每位创始人都会爱听这句话。

I think every founder is gonna love hearing that.

关于你提到的边际效益递减这点。

To your point that there's diminishing returns over time.

是啊。

Yeah.

而且你也不清楚质量如何，对吧？

And you don't know about the quality, right?

所以我觉得另一面是：你确实总能更快，但'更快'是为了什么？

So like, I think that's the other side is that you can always move faster, but faster for what?

我们是否在做正确的商业决策？

Are we making the right business decisions?

我认为这正是产品经理发挥作用的地方。

And I think that's especially where PMs come in.

我们可以每天更快地推出垃圾产品。

We can ship trash faster every single day.

我们需要战略和真正明智的决策来确定发布内容、实验方向、功能优先级和推广计划。

We need strategy and really smart decisions to know what to ship, what to experiment with, what features we want to do in what order and what rollout.

战略是核心部分。

The strategy is the core piece.

然后再考虑如何加速这个过程。

And then think about speeding that up.

如果其他环节没准备好，那就是垃圾进垃圾出。

We don't have the other pieces in place, I mean, garbage in, garbage out.

我想顺着这个话题继续。

I want to follow that thread.

但在那之前，先复述下你分享的内容。

But before I do that, just to mirror back what you shared.

所以迹象表明你的团队有很多容易改进的地方，团队生产力低下，构建总是出问题。

So signs that your team there's a lot of low hanging fruit to improve this, the productivity of your team is builds are always breaking.

存在大量不稳定的测试用例，经常出现误报。

There's flaky tests that are constantly incorrect, false positives.

在不同项目间切换上下文很困难，整个系统——你听大家讨论时就能感觉到——真的很难用。

It's hard to context switch between different projects, the system, you just hear people talking about the system, it's just really hard to work with.

大致是这样吗？

Is that roughly right?

是的。

Yeah.

酷。

Cool.

好的，回到你刚才提到的观点，有种感觉是AI让团队效率大幅提升，因为它能自动编写大量代码。

Okay, so going back to the point you just made, there's a sense that AI is making teams so much faster because it's writing all this code for them.

你将拥有所有这些异步工作的智能代理和工程师为你服务。

You're gonna have all these asynchronous agents, engineers working for you.

感觉你观点的核心在于这只是工程工作的一部分。

It feels like a core part of your message is that's just one part of engineering work.

还有更多内容，包括确定要构建什么以及内部协调。

There's so much more, including figuring out what to build and alignment internally.

或许可以说，虽然提升工程绩效和生产力的机会很多，但还有大量其他要素是AI无法改善的。

Maybe just speak to just like, there is a lot of opportunity to improve engineering's performance productivity, but there's so many other elements that are not improved through AI.

是的。

Yes.

或者说未来有可能实现，对吧？

Or could be in the future, right?

我认为有很多方法可以引入AI工具来帮助我们优化策略、完善信息、思考实验方法或目标，或是分析我们的总可寻址市场。

Like, I think there are a lot of ways that we can pull in AI tools to help us refine our strategy, refine our message, think about the experimentation methods or targets of experimentation, or think about our total addressable market.

但我们需要让战略和计划保持高度一致，对吧？

But we need to have that strategy and plan fairly well aligned, right?

或者至少准备两三种备选方案来测试，因为现在工程实施——尤其是原型开发——可以快得多。

Or at least have like two or three alternatives that you wanna test because now the engineering can go, or at least the prototyping especially can go much, much faster.

我们可以快速推出原型，运行面向客户的AB测试和实验——前提是我们已具备相应基础设施，这让我们能比过去更快地学习进步。

We can throw out prototypes, we can run AB tests and experiments that are customer facing, assuming that we have the infrastructure in place, which allows us to learn and progress much faster before.

过去在某些地方，要完成生产部署、进行AB测试并获得反馈需要数月时间。

Some places it used to take months to get something through production, to do AB testing and get feedback.

现在我们一两天就能完成。

We can do this in a day or two.

绝对在一周之内。

Definitely under a week.

但我们想确保我们正在构建和测试正确的东西。

But we want to make sure that we're building and testing the right things.

我们是否与代表合作？

Are we partnering with the rep?

我们是否拥有所需的数据？

Do we have the data that we need?

我要说的是，如果你能与AI进行良好的对话，并咨询你的专家，AI实际上可以成为一个相当不错的合作伙伴。

And I will say AI can actually be a pretty good partner there if you have a good conversation with it and then also check with your experts.

我应该查看什么类型的数据？

What type of data should I be looking at?

我需要什么类型的仪器？

What type of instrumentation do I need?

我可以进行什么类型的分析？

What type of analysis can I do?

因为这样你也可以去找你的数据科学团队，告诉他们，我计划做这个。

Because then you can also go to your data science team and say, I'm planning on doing this.

我想这样做，因为我们不能只是随意进行AB测试，对吧？

I'd like to because let's not just YOLO AB tests, right?

因为那样可能会很遗憾，进行大规模测试却最终打扰用户或客户，或破坏隐私或安全协议，还得到无法使用的数据，对吧？

Because that can be, it's a shame to do a large test and end up disrupting users or disrupting customers or breaking privacy or security protocols and also end up with data that's unusable, right?

因为你可能无法获得你想要的信号。

Because you just can't get the signal that you're looking for.

但现在我也看到人们将这个过程从几周加速到了几天。

But now I'm also seeing people kind of accelerate that into a few days versus a few weeks.

因此他们可以从一个更加了解、更加充实的状态开始那些关键利益相关者的讨论。

And so they can kind of start those key stakeholder discussions from, much more informed kind of filled out space.

本期节目由Coda赞助播出。

Today's episode is brought to you by Coda.

我个人每天都在使用Coda来管理我的播客和社区。

I personally use Coda every single day to manage my podcast and also to manage my community.

我会把所有计划采访嘉宾的问题都放在这里。

It's where I put the questions that I plan to ask every guest that's coming on the podcast.

我的社区资源也都存放在这里。

It's where I put my community resources.

我的工作流程也是通过它来管理。

It's how I manage my workflows.

以下是Coda能如何帮助您。

Here's how Coda can help you.

想象一下开始一个工作项目时，您思路清晰，明确知道每个人的分工和所需数据的来源。

Imagine starting a project at work, and your vision is clear, you know exactly who's doing what and where to find the data that you need to do your part.

事实上您无需浪费时间搜寻任何资料，因为从项目追踪器、OKR到文档和电子表格，团队所需的一切都集中在一个标签页中——全在Coda里。

In fact, you don't have to waste time searching for anything, because everything your team needs from project trackers and OKRs to documents and spreadsheets lives in one tab, all in Coda.

通过Coda一体化协作工作区，您能同时获得电子表格的灵活结构、应用程序的强大功能和AI的智能辅助，所有内容都能轻松整理在一个标签页中。

With Coda's collaborative all in one workspace, you get the flexibility structure of spreadsheets, the power of applications, and the intelligence of AI, all in one easy to organize tab.

正如我之前提到的，我每天都在使用Coda，超过50,000个团队信赖Coda来保持更高效的协同和专注。

Like I mentioned earlier, I use Coda every single day, and more than 50,000 teams trust Coda to keep them more aligned and focused.

如果您是初创团队希望提升协作效率和敏捷性，Coda能帮助您以创纪录的速度从规划阶段进入执行阶段。

If you're a startup team looking to increase alignment and agility, Coda can help you move from planning to execution in record time.

立即访问coda.i0/lenny即可免费试用，初创团队可享六个月团队版免费使用。

To try it for yourself, go to coda.i0/lenny today and get six months free of the team plan for startups.

请访问c0da.i0/lenny免费开通，即可获得六个月团队版使用权。

That's c0da.i0/lenny to get started for free and get six months of the team plan.

Coda.i0/lenny。

Coda.i0/lenny.

我很欣赏你能与众多不同类型的公司和企业合作。

I love that you work with a bunch of different companies and a bunch of different types of businesses.

我认为很少有人能深入了解这么多不同的地方。

I think very few people get to see inside a lot of different places.

就AI带来的生产力提升而言，你观察到了哪些方面的收益？

What kind of gains are you just seeing in terms of increased productivity with AI?

具体有多真实，收益幅度有多大？

Like how real, like how big of a gain have you seen?

我认为是真实的。

I'd say it's real.

同时我也要说，我们目前还没有完善的衡量标准。

And I would also say we don't have great measures yet.

我们仍在尝试确定应该测量什么以及如何呈现这些数据。

We're still trying to figure out what to measure and what that looks like.

其中最好的指标之一就是开发速度，对吧？

One of the best is going to be velocity, right?

贯穿整个系统的速度。

All the way through the system.

你能多快将一个功能、产品或任何东西推进系统，以便后续进行实验和测试。

How quickly can you get, a feature or a product or something through the system so that you can then experiment and test.

无论是从想法到最终成品，还是某个功能模块通过系统进行测试。

Either from idea to final end or even kind of a feature and a piece through the system so we can test.

这确实很棒。

That's really good.

不过这也很难直接归因于某个开发人员使用的特定AI工具。

Now that's also hard to tie back directly to a particular AI tool in the hands of a particular developer.

但还有一些其他方面我们可以观察和评估。

But there are some other things that we can look at and we can see.

我所见到的，还是这种快速原型设计。

That I've seen is, again, this kind of rapid prototyping.

我讨厌代码行，但我还是要用代码行。

I hate lines of code, but I'm gonna use lines of code.

我们确实看到，我知道曾与一些人共事，他们关注了一整套公司，发现AI为经常使用它的人生成了明显更多的代码。

We do see, I know I worked with some folks who had kind of a whole set of companies they were looking at and they found that AI was generating like significantly more code for the people who were using it regularly.

但他们也发现，对于经常使用AI编程环境、AI IDE工具的人来说，工具会给他们更多代码，而工程师自身的代码量增长是AI助手提供的两倍。

But then they also found that for folks who were regular users of AI coding environments, AI IDEs, the tool kind of gave them more code and then the engineers themselves, the increase was double what the coding agent given them.

所以第一点，我想说这可能是个次要或连带效应，或者说是个警示信号——它能帮你突破瓶颈。

And so one, I'd say probably it's kind of a secondary or knock on or just a smell is it can unblock you.

它能加速你本就要做的工作。

It can speed up the work that you would already do.

对吧？

Right?

我知道有时候工作就像前几分钟很难开始，但一旦进入状态就停不下来。

I know sometimes when I work, it's like the first few minutes, it's hard for me to start, but once I get started, I'm there.

所以它们非常擅长突破和释放这种状态。

And so they're really good at unblocking and unlocking that.

我在推特上看到人们分享说OpenAI Codex特别擅长发现棘手的bug。

Something I've seen people on Twitter sharing is how good OpenAI Codex, especially, is at finding really gnarly bugs.

我记得是Karpathy分享说他当时被一个bug困住，所有AI工具都解决不了。

And I think it was Karpathy that shared he was, like, so stuck in a bug and no AI tool could figure it out.

然后最新版的Codex。

And then the latest version of Codex.

花了大约一小时左右排查，最终帮他找到了问题。

Spent like an hour or something looking into it and found it for him.

是啊，我听到过很多这类不可思议的事。

Yeah, I'm hearing incredible things like that.

嗯，甚至还包括编写单元测试、启动单元测试、创建文档和清理文档，因为我知道现在人们会说，哦，我们有AI代理了。

Well, and even also writing unit tests and spinning up unit tests and creating documentation and cleaning up documentation because I know now people are like, Oh, well we have agents.

我不需要看文档，因为代码就在那里。

I don't need to read the docs because there's the code there.

结果发现AI代理依赖于优质数据，对吧？

Turns out agents rely on good data, right?

因为这完全取决于它们是如何被训练或如何被接地的，更好的数据会带来更好的结果。

Because it's all about how they've been trained or how they've been grounded and better data gives you better outcomes.

其中一些数据就包括文档和注释。

And some of that data includes documentation and comments.

你的文档和注释质量越高，从AI工具中获得的性能就越好。

And the better documentation, the better comments you have, the better performance you're gonna get out of your AI tools.

而AI可以帮助你编写那些文档。

And AI can help you write that documentation.

我最近和Devin合作过一些，它在这方面真的很擅长。

I've been working with Devin a little bit and it's really good at that stuff.

是的。

Yeah.

好的。

Okay.

我们来聊聊这个框架，这本书。

Let's talk about this framework, this book.

所以你正在出版一本名为《无摩擦》的书，听起来像是个梦想。

So you're publishing a book called Frictionless, which sounds like a dream.

如何创建一个无摩擦的开发团队？

How do you create a dev team that's frictionless?

这本书的全称是《在AI时代消除障碍、释放价值并超越竞争对手的七个步骤》。

It's called Seven Steps to Move Barriers, Unlock Value, and Outpace Your Competition in the Age of AI.

这个过程分为七个步骤。

There's a seven step process to this.

带我们走一遍这个流程。

Walk us through this.

也许先给我们介绍一下这本书的背景，它的创作目的，解决了什么问题，然后再讲这七个步骤。

Maybe give us just context on this book, what it was meant for, what problem it solves, and then the seven steps.

我要说的是，这本书是我和Abhi Noda合著的，他在开发者体验领域有着惊人的丰富经验，对吧？

So I will say, I also wrote this with Abhi Noda, who has just, of DX, he has incredible experience in the space, right?

他与数百家公司合作过。

He's worked with hundreds of companies.

所以和他交流想法非常愉快。

And so it was kind of nice bouncing ideas off of him.

还要感谢所有与我们交流过的工程主管、开发运动员、CTO和工程师们，他们帮助我们确认了这些'味道'是否正确。

And also thanks to all of the engineering leads and dev athletes and CTOs and engineers that we talked to, to kind of make sure that our smells were right.

那么这本书的目标读者是谁呢？

And so who is this book for?

既然你提到了Abi和DX，我们不妨先聊聊这个话题。

Let actually take tangent on Abi and DX since you mentioned him.

这非常有趣，而且我认为与本次对话直接相关。

This is super interesting and I think it connects so directly with this conversation.

Abi创办了这家名为DX的公司，这个名字对一家专注于开发者体验的公司来说简直太棒了。

So Abi started this company called DX, which is such a great name for a company around developer experience.

他们刚以十亿美元的价格把公司卖给了Atlassian。

They just sold the company for a billion dollars to Atlassian.

这个估值相对于他们的年度经常性收入来说非常高。

It's a very high multiple on their ARR.

在我看来，这恰恰证明了我们这次对话的价值所在——企业正在多么重视改善开发者体验。

It to me shows exactly why this conversation is so valuable, just how much value companies are putting into improving developer experience.

Atlassian愿意为此投入十亿美元，这就像是一家早期阶段的初创公司。

Atlassian would spend a billion dollars on this, it's like an early stage ish startup.

它原本发展得很好，但人们离开了，尽管它还处于早期阶段，却已价值十亿美元。

It was doing really well and people left it, but it was like early stage ish, a billion dollars.

现在的情况是，所有这些公司都在使用Jira及其产品，他们都在试图解决如何衡量生产力的问题，这对他们来说价值连城。

And now, and the idea is they have all these companies working using Jira and all their products, they're all trying to figure out how do we measure productivity, it's worth a lot of money to them.

我知道你也是他们的早期顾问之一，这正说明了这件事的重要性。

And I know you were an early advisor to them too, so it just shows us how important this is.

是的。

Yeah.

嗯，我认为这也展示了你能从中获取的巨大价值。

Well, and I think it also shows us how much value you can get out of this.

有太多唾手可得的成果，太多未被开发的潜力，很多时候即使是在拥有众多专家和顶尖人才的大公司里，也很难知道从何入手。

There's so much low hanging fruit, there's so much unlocked potential and it's hard to know where to start a lot of times, even in been at large companies that have a lot of expertise and a lot of really, really smart people.

但如果你没有涉足这个领域或这样思考过，就很难知道从哪里开始，或者容易犯一些前期错误，导致之后可能需要重新来过。

But if you haven't kind of been in this space and thinking about it this way, it's hard to know where to start or it's easy to make simple mistakes upfront that mean you kind of need to start over later.

所以我想这又把我们带回到一个问题：这本书是为谁写的？

So I guess which kind of also brings us back to who is this book for?

它是为所有关心开发者体验（DevEx）的人准备的，对吧？

It's for anyone that cares about DevEx, right?

技术领导者肯定包括在内，任何试图启动DevEx项目或正在改进DevEx项目的人都适用，尤其与产品经理相关——如果你负责涉及软件开发的产品，提升DevEx只会让你的团队受益。

So definitely technology leaders, anyone who's trying to kick off a DevEx program or is working on a DevEx improvement program, think is particularly relevant for PMs because if you're PMing something that involves software, building and creating software, improving DevEx will only help your team.

而且，你拥有的关键技能、洞察力和直觉对DevEx至关重要，很多时候我注意到工程团队恰恰会忽略这些。

And also, you have key skills and insights and instincts that are so important to DevEx that many times, I will say I've seen engineering teams just miss.

好的。

Okay.

框架是什么？

What's the framework?

有哪些步骤？

What are the steps?

人们从哪里开始？

Where do people start?

这本书介绍了一个七步流程，最后还提供了一些关键原则。

So the book goes through a seven step process and then also kind of provide some key kind of principles at the end.

第一步是开启旅程，对吧？

Step one is to start the journey, right?

假设你正要开始，你可以开启这段旅程。

So assuming you're kicking off, you can start the journey.

这包括我们已经讨论过的内容，对吧？

And this involves what we have already talked about, right?

去与人交谈，进行倾听之旅，综合所学，可视化工作流程和工具。

Go talk to people, have a listening tour, synthesize what you learn, visualize the workflow and tools.

掌握当前状态的大致情况。

Get a handle on kind of what the current state is.

第二步是快速取得一个小胜利。

Step two is to get a quick win.

从小处着手，快速取得小胜利，选择合适的项目，分享你的成果。

So start small, get a quick win, pick the right projects, share out what you've done.

第三步是利用数据优化工作。

Step three is using data to optimize the work.

对吧？

Right?

建立一些数据基础，找到现有数据，开始收集新数据，使用调查获取快速洞察，可能包括示例调查。

So kind of establish some of your data foundation, find the data that's there, start collecting new data, use some surveys for some really fast insights and may include example surveys.

第四步是决定策略和优先级。

Step four then is to decide strategy and priority.

当你掌握了一些数据后，你需要了解所有可能出问题的环节，并且已经快速解决了剩余问题，接下来我该怎么做？

Once you have some data, then you need to know of all the things that are potentially broken and you've already gotten your quick win of all the things that are left, what should I do next?

因此我们在此讨论了一些评估框架。

And so we walk through some evaluation frameworks there.

第五步是推销你的策略。

Step five is to sell your strategy.

一旦做出决定，现在你需要说服其他人。

Once you've decided, now you have to kind of convince everyone else.

所以现在你想要获得反馈。

So now you want to get feedback.

你需要分享为什么这是当前最合适的策略。

You want to share why this is the right strategy right now.

第六步是根据你的规模推动变革。

Step six is to drive change at your scale.

这里我们针对的是具有局部控制权的人员，对吧？

So here we address folks that have local scope of control, right?

如果你刚开始只是一个开发团队，你想通过自下而上的方式自己实施，还是拥有全局控制权？

If you're starting on just a dev team, you wanna do it yourself kind of grassroots effort or global scope of control, right?

如果你是开发者体验副总裁之类的职位，你可以利用某些资源进行自上而下的推动。

If you're, the VP of developer experience or something, there are some things that you can leverage for a top down.

那么当你处于中间位置时，如何推动变革呢？

And then how do you drive change when you're kind of somewhere in the middle?

因为你可以同时利用这两种策略。

Because you can leverage both types of strategies.

第七步是评估进展、展示价值，然后重新循环这个过程。

And then step seven is to evaluate your progress and show value and then loop back around.

需要说明的是，我们这样设计是为了让你可以从任何步骤切入，无论你现在处于哪个阶段。

And I will say that we wrote this so that you could jump into any step wherever you are right now.

如果你要启动一个团队或项目，可能需要从第一步开始。

If you're kicking off a team or an initiative, you'll probably want to start at step one.

你绝对应该从第一步开始。

You should definitely start at step one.

如果你要加入现有项目，可以直接进入选择优先级或实施变更的环节。

If you're joining an existing initiative, you could jump into picking the priority or implementing the changes.

所以共有七个步骤。

So are seven steps.

我们还有一些推荐的实践方法。

There are a few practices that we also recommend.

比如考虑资源配置、变革管理、确保技术可持续性，以及用产品经理的视角来看待问题。

So thinking about resourcing it, change management, making technology sustainable, and then also bringing a PM lens to this.

对吧？

Right?

我们如何将开发者体验视为产品？又如何将现有指标当作产品来思考？

How can we think about developer experience as a product, and how do we think about the metrics that we have as a product?

太棒了。

Awesome.

好的。

Okay.

我有问题要问。

I have questions.

快速告诉大家书名。

Point people to the book real quick.

网址是什么？

What, what's the URL?

他们怎么获取？

How do they get it?

它什么时候发布？

When does it come out?

是的。

Yeah.

Developerexperiencebook.com（开发者体验手册官网）。

Developerexperiencebook.com.

现在你可以先订阅邮件列表。

So right now you can sign up for the mailing list.

我们会通知你预售时间，并分享工作手册的部分内容。

We'll we'll let you know when it's out on Preorder, and we'll also be sharing pieces of the workbook.

我们准备了近100页的配套工作手册，预计年底前会正式发布。

So we've got almost a 100 page workbook that goes along with the book, and then it should be out by end of year.

好的。

Okay.

这里有个关键点在于'开发者体验'这个术语非常精准，它不同于开发者生产力或开发者工作。

So one piece of this is just this term developer experience feels very intentional in that it's not developer productivity, developer work.

它关注的是如何让开发者在公司获得更好的体验，既包括效率提升，也包括幸福感等方面。

It's how do we make developer experiences better at our company, which includes they get more done, but also they're happier, things like that.

所以我认为这是很重要的一环，对吧？

So I think that's an important element of this, right?

对。

Yeah.

没错，完全正确。

Yeah, absolutely.

因为这不仅仅是关于生产力的问题，对吧？

Because again, it's not just about productivity, right?

我们之前讨论过，要从构建正确事物的角度出发——你既要追求效率，也要兼顾思考。这正是工程师们特别擅长的领域。

We talked about this from kind of the frame and the lens of we need to be building the right thing and you wanna be productive, but you also wanna be thinking about, and this is what engineers are also just really incredibly good at.

给他们一个问题，但不要告诉他们如何解决。

Give them a problem and don't tell them how to solve it.

这样他们反而能解决得更好。

And then they can solve it better.

他们拥有自由、创新和创造力，因此能够解决这个问题。

They have the freedom, they have the innovation, they have the creativity so that they can solve this problem.

如果只关注生产力，那就只是代码行数或PR数量之类的指标，对吧？

If it's only about productivity, then it's just like lines of code or a number of PRs or whatever, right?

但我们真正想讨论的是价值，以及如何释放价值和更快获取价值？

But we really wanna talk about value and how do we unlock value and how do we get value faster?

这确实包括提高他们的生产力并消除摩擦，从而让他们进入心流状态，减少认知负荷，这些我们之前都讨论过。

And that involves, yes, making them more productive and removing friction because then they have the flow and the cognitive load and the things that we kinda talked about.

太棒了。

Awesome.

好的。

Okay.

那么假设有人想组建这个团队。

And then say someone wants to start this team.

通常是什么样的情况？

What does it usually look like?

在Airbnb时，我记得这个团队刚成立时，就是一两个工程师主动牵头开始的。

At Airbnb, I remember this team forming, and it was just like an engineer or two getting it started and taking charge.

你建议先导团队应该是什么样的？

What do you recommend as the pilot team?

随着团队发展会变成什么样？

And then what does it look like as it grows?

有几种方法可以做到这一点。

So there are a few ways to do this.

对吧？

Right?

所以如果你要自己动手

So if you're doing

它

it

你可以用几个工程师，也许再加一个项目经理或项目群经理或技术项目经理来协助沟通，因为沟通计划在这里真的非常重要。

yourself, you could do it with a couple engineers, maybe a PM or a PGM or a TPM to kind of help communicate because really comms plans are just so important here.

在小规模范围内，对吧？

On a small scale, right?

我们想要做的是寻找那些快速见效的机会，寻找可以小规模实施的事情。

What we wanna do is look for those quick wins, look for things that you can do at small scale.

有些人称之为类似'纸张划伤'的小问题。

Some folks call them things like paper cuts.

有没有一些小事情可以让人们看到价值并亲身体验到好处？

Are there small things that you can do to help people see the value and feel the benefit themselves?

如何让开发者的工作变得更好？

How can a developer's work get better?

如何改善他们的日常工作？

How can their day to day work get better?

从那里开始积累势头。

Kind of build momentum from there.

如果你采用自上而下的工作结构并且有授权，你仍然需要一些快速见效的成果，但这些成果可以更具全局性，因为你拥有基础设施或支持来进行不同类型的改变，而不仅仅是局部调整。

If you're working from a top down structure and you have the remit, you still want some quick wins but those quick wins can look a little more global in scale because you have the infrastructure or the backing to make different types of changes that aren't only local.

举个局部小改动的例子，比如清理测试套件中的测试用例，对吧？

So an example of a small local change could be just cleaning up your tests in your test suites, right?

任何团队都能做到这一点。

Any team could do that.

任何团队都能做到这一点。

Any team could do that.

全球规模的扩展可能会改变整个组织的流程，这些流程过于繁琐，或者需要投入资源来清理配置环境。

More global scale might be changing organization wide process that is just overly cumbersome or throwing some resourcing into cleaning up the provisioning environment.

你观察到这类团队对他们公司工程团队产生了什么样的影响？

What kind of impact have you seen from teams like this forming on the engineering teams at their companies?

我我得说影响非常巨大。

I I'll say I've seen a huge impact.

对吧？

Right?

对小公司来说是数十万美元，对大公司则是数十亿美元。

For for smaller companies, hundreds of thousands of dollars for large companies in the billions.

削减得好，但我们还需要学会如何传达这一点，对吧？

Cut well, also we need to learn how to communicate that, right?

比如，具体数据是怎样的？

Like, what does the math look like?

很多时候我们可以着眼于节省时间。

Many times we can look at saving time.

我们可以着眼于降低成本。

We can look at saving costs.

我们可以关注很多不同方面。

We can look at a lot of different things.

我们可以关注价值实现速度和产品上市速度。

We can look at speed to value and speed to market.

我们可以关注风险降低，但收益确实存在。

We can look at risk reduction, but the gains really are there.

我要提到的是，这种趋势往往遵循类似J型曲线的发展规律。

I will mention that it tends to follow something like J curve.

一开始你会取得几个快速胜利，看起来像是重大成就，但随后就会遇到一个小低谷——那些显而易见的项目、容易摘取的果实都已被处理完毕。

So you'll have a couple of quick wins and it'll look like a big win, and then you'll hit a little divot where suddenly the really obvious projects, the low hanging fruit are handled.

所以现在我们需要做些实际工作了，对吧？

So now we need to do a little bit of work, right?

我们可能需要搭建更多的基础设施。

We might need to build out a little bit more infrastructure.

我们可能需要部署更多遥测系统，以便捕获我们想要的数据。

We might need to build out a little more telemetry so that we can capture the things we wanna capture.

等这些完成后，我们就能看到这些效益真正开始产生复合效应。

And then once we get that done, then we start to see those benefits really compound.

回到那个测量指标的问题，你有什么建议？

So going back to that measurement number, what do you recommend?

人们是怎么找到这些数据的？

How do people find these numbers?

因为我认为这件事的强大之处就在于——我们通过这个节省了一百万美元。

Because I think that's so much of the power of this is like, we saved a million dollars doing this.

你们是通过哪些指标得出这个结论的？

What do you look at to figure that out?

我认为有几点需要注意。

I think there are a few different things to keep in mind.

我们的核心受众是谁？

Who is our key audience?

通常我们会有几类核心受众。

And we usually have a few key audiences.

我们特别需要能与开发者对话，因为他们才是系统的实际使用者。

We really want to be able to speak to developers because they're the ones that are going to be using the systems.

他们会与你们合作共建系统，或至少为你们的工作提供反馈。

They'll be partnering with you on either building them or at least providing feedback about what you're doing.

因此对他们而言，我们常需用他们关心的事项来阐述这些。

And so for them, we often want to frame this in terms of things they care about.

比如时间节省，对吧？

So time savings, right?

如果流程加速，他们就能节省时间。

If something gets faster, they can save time.

不再需要时，他们就不必花费时间进行设置。

They don't spend time doing setup when they don't need to anymore.

与此相关的是减少繁琐劳动，对吗？

Related to that is reduced toil, right?

合规性和安全性至关重要。

So compliance and security are super important.

而且很多时候需要多个手动步骤，我并非说这些步骤没有价值。

Also many times it requires several manual steps that I don't say they're not value add.

从个人视角看，它们确实不创造价值。

They are not value add from an individual human perspective.

对吧？

Right?

若能尽可能实现自动化，那就太好了。

If we can automate as much as possible, that's great.

提升专注时间。

Improved focus time.

这是从你们开发者角度出发的。

So that's from the developer side of you.

领导层通常也关心这些方面，对吧？

Leadership often cares about they care about those things, right?

但他们总是更关注其他事项。

But they always care more about other things.

那么我们通常可以讨论成本和美元，对吧？

So we could talk about usually costs and dollars, right?

那么我们能否加速收入增长？

So can we accelerate revenue?

我们的价值实现周期是怎样的？

What does our time to value look like?

我们的推进速度如何？

What is our velocity?

我们能多快获得客户反馈？

How quickly can we get feedback from customers?

对于那些处于高度竞争环境中的个人和组织来说，这一点极具吸引力，因为速度就是一切。

And for folks and organizations that are in really competitive environments, that can be really compelling because it's all about speed.

我们可以讨论节省资金。

We could talk about saving money.

这里我们可以考虑量化节省的金额。

Here we can look at maybe quantifying savings.

一个例子是测试和构建环节。

One example is test and build.

如果我们能优化测试和构建套件。

If we can clean up a test and build suite.

对开发者来说，他们真正想听到的是节省时间和系统更可靠。

To a developer, they really want to hear about time saved and more reliable systems.

减少了重复劳动，因为他们不必反复运行测试或清理测试套件。

There's less toil because they don't have to keep rerunning tests or kind of go clean up test suites.

从业务角度来看，优化构建套件中的测试可以节省云成本，因为所有这些测试都在云端某处运行。

From the business perspective, cleaning up a test in a build suite can be cloud cost savings because all of those tests are running somewhere on a cloud.

如果这些测试总是失败或者只是浪费开支，那么优化就很有价值。

If they always fail or if it's just kind of a waste of spend, that can be useful.

恢复部分产能。

Recovering some capacity.

我们随时可以讨论时间和效率提升的问题。

We can always talk about time and productivity gains.

那么我们究竟在非增值事务上浪费了多少等效开发时间？

So how much equivalent developer time are we losing on things that are not necessarily value add?

有时我们可以将其与业务成果相关联——虽然通常只能做到相关性分析，但在加速价值实现和提升市场份额等方面，确实能发现一些极具说服力的关联案例。

Then sometimes we can correlate to business outcomes and correlate is usually the best we can do here, but there can be some pretty compelling correlations in terms of speeding up time to value and increase market share, for example.

让我先完善右侧内容，稍后再回到这个话题。

So let me fill that to the right and come back to this.

我认为当前人们对AI与生产力的最大疑问是——虽然尚无定论，但我想听听你的见解：人们当下究竟该采取什么行动？

What I think is the biggest question people have right now with AI and productivity, I think anyone has the answer yet, but I'm curious to get your take of just what should people do today?

要理解AI工具对生产力的影响，最佳方法是什么？

What's the best approach to understanding what impact AI tools are having on their productivity?

毕竟他们投入了大量资金，但我实在不确定——我们真能从中获得回报吗？

Because they're spending all this money on there, like I don't know, are we getting out of this?

虽然感觉事物发展在加速，但我仍难以判断。

And I guess things are moving faster, but I don't know.

如果有人需要明确指导说'好吧，这些是我应该尝试的方向'...

So if someone had to just like, okay, here's what I should probably try to do.

对于衡量AI工具对生产力的影响，你最重要的建议是什么？

What would be your best advice here for measuring the impact of AI tools on productivity?

我认为这要视情况而定。

I would say it depends.

部分取决于你的领导层真正关心什么指标。

And in part, it depends on what your leadership chain really cares about.

我们通常很擅长识别开发者关注的核心价值，并能有效传达这些信息。

We're usually pretty good at figuring out what matters to developers and we could communicate that to them.

如果我们试图只确定两三个关键数据点来重点关注，因为刚开始接触数据时可能会遇到挑战。

If we're trying to just identify two or three data points to really focus on, because when we're first starting with data, sometimes it can be challenging.

他们在乎什么？

What do they care about?

回想一下你听到的信息。

Think about the messaging you've been hearing.

他们是不是一直在讨论市场份额？

Have they been talking about market share, right?

市场份额流失或在市场中的竞争力下降。

Losing market share or competitiveness in the marketplace.

如果是这样，就聚焦速度指标。

If that's it, focus on speed.

思考如何从功能开发到投产、交付客户、实验验证等环节捕捉速度指标，并观察反馈循环的效果。

Think about ways that you can capture metrics for speed from feature to production or feature to customer or feature to experiment and what that feedback loop looks like.

如果他们总在谈论利润率。

If they're talking about profit margin all the time.

我们总是要讨论资金问题，毕竟这是商业。

Now we always talk about money because this is business.

但如果这已成为核心议题，就要寻找节省成本的途径，并将其转化为可回收的人力成本。

But if that seems to be an overarching narrative, look for ways that you can save money and then translate that into recovered and recouped headcount cost.

有时通过流程再造或改进，可能就不再需要那么多供应商。

Or sometimes you'll kind of reinvent, change a process, and then you no longer need as many vendors.

因此减少供应商支出也能见效。

So reductions in vendor spend can also help there.

不过我要说这得看情况，因为有时他们只是随口一提。

And I say also it depends because sometimes something will They'll say something, right?

比如领导层可能会提出某个观点，然后逐渐成为主题。

Like leadership will say something and it kind of comes up as a theme.

如果你能解决他们面临的问题，或是他们关注的重点，哪怕只是稍微重新表述这个问题。

If you can solve a problem that they have, or it's like something that they're focused on, if you can slightly reframe it even.

比如他们把一切都称为开发者生产力，那你就直接称之为生产力。

Like if they're calling everything developer productivity, go ahead and call it productivity.

如果他们称之为速度且速度对他们至关重要，就思考如何从速度的角度来阐述。

If they're calling it velocity and velocity is what matters to them, think about how to frame this in terms of velocity.

如果他们谈论转型或颠覆，那么这如何助力颠覆性变革？

If they're talking about transformation or disruption, how does this help with the disruption?

因为这样会引发他们的共鸣。

Because then it will resonate with them.

我们不想让他们费劲理解我们在做什么以及我们提供的价值。

We don't want to make them work to understand what it is that we're doing and the value that we provide.

这建议真是太棒了。

That is such good advice.

总结一下，这里的建议是：如果公司想评估AI工具的影响，首先要明确公司最关心什么？

So just to reflect back, the advice here is if your company is trying to figure out what sort of impact our AI tools are having on our company, first is just like, does the company care about most?

领导者最关心什么？

What do leaders care about most?

可能是市场份额，可能是利润率，也可能是速度。

Could be market share, could be profit margin, could be velocity.

我们需要更快速度，或者我们需要转型，彻底变革。

We need higher velocity, Or we need to transform, transformation.

所以你的建议是：根据听到的词汇和短语来明确重点，然后设计衡量方式——比如衡量市场份额增长或利润率提升。

So your advice there is like, figure that out based on words and phrases you're hearing, then figure out ways to measure that, ways to measure market share growing, profit margin increasing.

比如这些例子就很棒：从功能构想到投产或实验的周期，可以开始追踪这个指标。

So it could be, I love these examples, like time from feature idea to production or to experiment, so maybe start tracking that.

如果是利润率，可以计算因测试失败减少而节省的费用，或无需支付给某些供应商的款项。

If it's margin, it's like money saved by fewer tests failing or some vendor you don't have to pay for things like that.

然后是速度。

And then velocity.

关于速度，我认为这正是像Dora这样的指标发挥作用的地方——比如工程交付速度，你对速度指标有什么看法？

At velocity, I imagine that's where things like Dora come in of just like speed of engineering shipping, or what would you think about their for velocity?

我会说这实际上是我会选择尽可能广泛覆盖的领域之一。

I would say it's actually one of those I would pick as broad a swath as you can.

所以如果你能从想法到客户或想法到实验，这需要多长时间？

So if you can go from idea to customer or idea to experiment, how long does that take?

通常需要多长时间？最长可能需要多久？

How long does it typically take and how long can it take?

现在随着AI工具的改进和摩擦的减少，需要多久？

And does it take now with improved use of AI tooling and reduction in friction?

这就是我要说的，我们在书中稍微讨论过这个问题：如何处理归因挑战？

And that's where I will say, we talk about this a little bit in the book, how do we deal with attribution challenges?

那么是什么因素导致的？

So what was responsible for this?

是开发体验（DevEx）还是AI？

Was it the DevEx or was it AI?

直接公开说明就好，对吧？

Go ahead and disclose that, right?

比如：是的，我们推出了AI工具。

Say, yes, we rolled out AI tools.

我们同时在开发体验（DevX）方面也做了努力。

We also had this effort in DevX.

他们非常紧密地合作。

They partnered very closely together.

两者可能都对此有所贡献，对吧？

Both of them probably contributed to this, right?

假如我们只有AI工具而没有开发者体验改进，可能会有一些进步，但远不及现在这么多，对吧？

Like if we had AI tools without the DevX improvements, we probably would have had some improvements, but not nearly as much, right?

如果人们今天才开始做这件事，比如说他们决定要开始衡量开发者体验。

If people were starting to do this today, say they're just like, I wanna start measuring developer experience.

有没有两三个基本指标是每个人都需要的，应该尽快开始测量的？

Are there like a two or three metrics everybody basically needs that you should just start measuring ASAP?

如果你今天刚起步且一无所有，显然要先和人们沟通。

If you're just starting today and if you have nothing at all, talk to people obviously.

之后我会做问卷调查，因为问卷能让你快速获得整体概况，从而了解主要挑战在哪里。

After that, I would do surveys, because surveys can give you a nice kind of overall view of the landscape quickly so that you know where the the big kind of challenges are.

我这么说是因为刚开始时，你的系统可能还没有配备完整的指标测量工具。

And I say that because if if you're just starting, you you might not have instrumentation through your system, all the metrics.

即使已有测量工具，它们可能也不符合你的预期需求。

And if you do already, it might not be what you think you want.

对吧？

Right?

那些无明确目的设计的指标，其价值值得怀疑。

Metrics that were designed without purpose, questionable.

为其他目的设计的指标，可能符合你的需求，也可能不符合。

Metrics that were designed for another purpose, they might work for what you want, but they might not.

所以我们不能想当然地认为已经拥有所需指标。

So we can't just assume we have them.

这就是我喜欢问卷调查的原因之一，我们在书中也提供了示例。

So that's one reason I like surveys and we include an example in the book.

你只需要问几个问题就行，对吧？

You can just ask a few questions, right?

你对当前体验的满意度如何？

How satisfied are you?

影响你工作效率的最大障碍是什么？或者说，完成工作的最大挑战有哪些？

What are the biggest barriers to your productivity or what are the biggest challenges to getting work done?

让他们从一系列工具或流程中选择，然后说让他们选三个，就三个。

And let them pick either from a set of tools or maybe like a set of processes and then say let them pick three, just three.

在这三个中，这种情况多久会影响你一次？

Of those three, how often does this affect you?

对吧？

Right?

是每小时一次吗？

Is this hourly?

是每天一次吗？

Is this daily?

是每周一次吗？

Is this weekly?

是每季度一次吗？

Is this quarterly?

对吧？

Right?

因为有时它每天都困扰着你，而且

Because sometimes it hits you every single day and

你简直

you're just

为此抓狂。

mad about it.

有时它每季度才出现一次，因为是季度末，但特别繁琐。

Sometimes it only hits you once a quarter because it's end of quarter, but it's so onerous.

对吧？

Right?

然后是一种开放式的文本。

And then kind of open text.

还有什么我们需要了解的吗？

Is there anything else we should know?

这能提供惊人的信号——通过让人们优先处理前三件事，如果允许全选，数据就会变得极其混乱。

That can give you incredible signal because by making folks prioritize the top three things, if you let them pick everything, it makes the data super, super messy.

但三个事项及其频率，你可以直接计算得分或加权分数（如果需要），然后深入挖掘这些数据应该放在哪里。

But three things and how often, you can just come up with a score or a weighted score if you want, and then go kind of dig into where should that data be?

我们需要哪些数据？

What data do we need?

不过至少你还能获得某种基准线。

But also then you've got at least some kind of baseline.

虽然是主观基准，但你现在能明确最大的挑战是什么。

It'll be a subjective baseline, but now you'll know what the biggest challenges are.

我特别喜欢这一切最终都回归到从与人交谈开始——询问这些问题，这和产品管理的本质非常相似。打造优秀产品的核心就是：你和客户聊过吗？

I love how all this just comes back to starting by talking to people and asking them these things, which is very similar to product management and just building great products is have you talked to your customers?

每个人都以为自己做到了，但大多数人做得远远不够。

And everyone thinks they're doing this, but most people are not doing this enough.

是的。

Yeah.

我想说的是，当你开始考虑收集数据时，有个挑战点。

And I will say, like, one thing that's challenging when you're start when you think about getting data.

对吧？

Right?

访谈本身就是数据，这很重要。

So interviews are data, and that's important.

调查则更具量化性。

Surveys are a little more quantified.

对吧？

Right?

因为我们可以转化为统计数据。

Because we can we can turn into counts.

但这也正是我们需要谨慎的地方。

But that's where we also wanna be careful.

对吧？

Right?

很多人设计调查问卷时会问这样的问题：过去一周构建和测试系统是否缓慢或复杂？

A lot of folks go to write a survey question and they'll say something like, were the build and test system slow or complicated in the last week?

你这里其实问了四个不同的问题。

You're asking four different questions there.

如果有人回答是，是指构建系统吗？

If someone answers yes, was it the build?

还是测试系统？

Was it the test?

是指速度慢吗？

Was it slow?

还是指不稳定、复杂或其他问题？

Or was it flaky or complicated or something?

对吧？

Right?

因此要理清你实际获得的信号可能非常困难。

So it can be really difficult to untangle what the signal is you're actually getting there.

所以值得花时间与熟悉调查设计的人交流，或者与Claude、Gemini、ChatGPT讨论：这些是调查问题，你能提出建议吗？

And so it is worth time chatting with someone who's familiar with survey design, having a conversation with Claude or Gemini or ChatGPT around here are the survey questions or can you propose them?

然后确保进行多轮测试。

And then make sure you take a couple rounds.

这是个好的调查问题吗？

Is this a good survey question?

我能从获得的数据中回答哪些问题？

Questions can I answer from the data that I get?

我能解决哪些问题？

What problems could I solve?

如果你无法用数据回答问题，就别收集它。

If you can't answer a question with data, don't get it.

你的书里有示例问卷吗？方便那些想直接复制粘贴而不想...

And you have example surveys in your book for folks that wanna just copy and paste and not have

关于问卷设计的示例，有很多问题范例。

Example to think about surveys, a lot of example questions.

我们甚至会推荐格式、流程应该怎样呈现、合适的长度以及不应超过的长度。

We even recommend like what the format, like, how what the flow should look like, how long it should be, how long it should not be.

我读到一点，你不太喜欢专门询问工程师幸福感的调查问卷。

One thing that I was reading is that you don't love happiness survey specifically asking engineers how happy they are.

是这样吗？

Is that true?

如果是的话，为什么？

If so, why

是的，我不喜欢。

is I don't.

不，我要说我不喜欢幸福度调查，因为影响幸福的因素太多了。

No, I will say I don't love a happiness survey because there are too many things that contribute to happiness.

幸福很复杂，对吧？

Happiness is a lot, right?

所以幸福也是工作的一部分。

So happiness is work.

幸福就是家庭。

Happiness is family.

幸福就是爱好。

Happiness is hobbies.

幸福就是周末。

Happiness is weekends.

幸福有太多因素可以构成。

Happiness there are so many things that contribute to happiness.

这并不意味着我不在乎幸福。

Now that doesn't mean I don't care about happiness.

我认为幸福调查在这里并不特别有用。

I think happiness surveys are not particularly useful here.

真正有用的是满意度。

What can be helpful is satisfaction.

人们会问，什么是相同的命运？

And people are like, What's the same fate?

不是这样的。

It's not.

因为你可以问，你对这个工具满意吗？

Because you can ask, Are you satisfied with this tool?

然后问一些后续问题。

And then ask some follow-up questions.

这两者是相关的，因为你对工作、工具、任务和团队的满意度越高，就越能促进幸福感。

Now those two are related because the more satisfied you are with your job and your tools and the work and your team, it contributes to happiness.

我以前常开玩笑，记得高尔夫广告说的快乐奶牛产快乐奶酪吗？

And I used to joke, remember the golf commercials like happy cows make happy cheese?

如何设置Calibri字体？

How to Calibri?

那是最棒的。

That was the best.

快乐的开发者写出快乐的代码。

Happy devs make happy code.