Engineering Culture Podcast：David Hussman与您探讨有效产品发现和Dude公式-优快云博客

本期播客探讨了如何确保构建正确的产品而非更多产品，介绍了Dude公式（价值=为什么这么做/如何来做），并讨论了如何通过最小化复杂度和使用最精简的可行学习来提高产品开发效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

这里是Engineering Culture Podcast，由InfoQ.com以及QCon大会共同呈现。\

在这期播客中，InfoQ Culture \u0026amp; Methods的主编Shane Hastie对话DevJam及CardBoard It!（一款故事映射工具）的创始人David Hussman。\

关键内容

把价值放在首位：这不是为了创造更多的产品，而是为了保证我们可以因人而异建立正确的产品 \
Dude公式：价值 = 为什么这么做/如何来做 \
评估产品对于人的生活产生的影响 \
使用最简单的方式和“最精简的可行学习”来最小化复杂度 \
完成有意的发现：使用交付节奏来加快学习周期，紧密耦合地设计和交付sprints \
仅仅“完成”是不够的，当物品经由真实客户的验证之后才能提供价值 \
验证可能会在发现和交付的时候发生

这里是原文中的音频链接\

笔记

1分09秒重点从构建产品转移到构建正确的产品\
1分41秒介绍“Dude公式”：价值 = 为什么这么做/如何来做\
3分02秒考虑产品开发的意图，而不是过程\
3分17秒专注于产品，而非过程。考虑开发产品的意图，确定产品将产生的影响\
3分30秒大的“转变”往往是永无止境的，而且不会非常成功；成功的产品可以影响到一个人，可以让他过得更幸福\
4分00秒宣布一本正在筹划中的新书，书名叫《产品\u0026gt;过程》\
4分28秒我们正在努力，拒绝“敏捷”的过度使用\
4分40秒一个有价值的产品总能找到团队、产品及技术之间的正确映射\
5分00秒 “一个团队、一种技术、一个产品”的简单观点在当今复杂的世界中并不现实\
5分27秒外推到一个产品多个团队时面临的最大挑战是，基于大型“系统”的组织的产品不清晰可见\
6分02秒意外复杂性（引用自Fred Brooks）或“偶然的复杂性”\
6分35秒克服复杂性的技术，如MVP和小的产品分割。将客户旅程视为“最精简的可行学习”\
6分43秒复杂的问题是可以解决的，但是复杂性是不能解决的\
7分08秒探索最精简的可行学习的想法：消除不确定性\
7分37秒人们经常过度复杂化MVP，却不把它当做一种技术来学习\
7分55秒即使尚未投入生产，使用故事映射等技术可以最小化进行真实人物验证的\
8分35秒学习于生产之外，但不要重复九十年代的错误，把原型开发当成“交付不成熟的代码，并在此基础上叠加”\
8分50秒现在我们使用的工具都是高质量的，并且发展迅速，可以帮助实现有意的发现-交付周期\
9分09秒通过实时原型、A-B测试、客户访谈等技术缩小交付之外的不确定性\
9分25秒更多的软件开发人员需要转变为产品开发人员，了解人们的需求，并在代码之外验证其中的一些需求\
9分54秒解决误解的方法是提前进行大设计\
10分00秒不同之处在于用于设计和发现上的时间比\
10分08秒以设计sprints为标准，规划交付sprints，降低设计sprint中的不确定性，确定交付sprints中学习到的内容，将新的不确定性反馈给设计sprints，尽量使用潮水式方法处理事件，避免使用序列化方式处理事件\
11分08秒 “完成”和“已验证”之间的区别\
11分25秒从使用验证过的想法转向测试驱动产品\
11分40秒 “产品影响驱动开发”的观点：在开始构建之前先确认衡量它的影响的方法\
11分55秒在发现阶段的早期进行验证，或是在交付阶段验证产品\
12分07秒产品已完成通常代表着“我已经做完了这个产品”，但并没有评估交付的价值；产品管理应该从验证开始，而不仅仅是单纯地构建产品\
12分50秒期望产生的影响很大，但是积压的项目太多需要处理难以达到期望的影响\
13分10秒有少数小型的团队已经在采用这种方法，但是大多数的组织仍然在学习这些概念（例如Netflix）\
13分35秒 Netflix之所以可以用数据来左右产品设计，是因为其有坚实的技术基础\
14分10秒从一个团队，一个技术栈的组织发展到多个团队同时在更大、更复杂的环境上搭建一个产品，有很长的路要走\
14分35秒找到让团队获得更大成功的起始点\
15分15秒只要不受一些不必要的限制，找出起始点并不是很复杂的事情，但是它可以取得的成果是非凡的\
15分30秒我们需要向交付团队之外的人展示工作方式的价值\
16分30秒在复杂的组织中，“产品”的想法并不明显，所以我们需要帮助IT从业人员从项目的思维中转型到产品的思维\
17分44秒在许多大型组织中搭建环境的复杂技术栈导致了技术和团队之间的分离\
18分13秒通过确定验证过的服务或产品的重要性来了解端到端的价值\
18分40秒在开发产品的同时对不同组件进行存根，我们并没有很好地使用到技术栈\
19分00秒通过细化交付、多次验证我们可以处理好技术栈的复杂性\
19分30秒使用发现方法尽早验证学习，避免构建出错误的产品\
19分40秒研究如何在数字空间中应用实验设计，清楚地了解正在使用的参数后再开始实验