Engineering Culture Podcast：David Hussman 与您探讨有效产品发现和 Dude 公式

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

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

关键内容

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

这里是原文中的音频链接

笔记

• 1 分 09 秒 重点从构建产品转移到构建正确的产品
• 1 分 41 秒 介绍“Dude 公式”：价值 = 为什么这么做 / 如何来做
• 3 分 02 秒 考虑产品开发的意图，而不是过程
• 3 分 17 秒 专注于产品，而非过程。考虑开发产品的意图，确定产品将产生的影响
• 3 分 30 秒 大的“转变”往往是永无止境的，而且不会非常成功；成功的产品可以影响到一个人，可以让他过得更幸福
• 4 分 00 秒 宣布一本正在筹划中的新书，书名叫《产品 > 过程》
• 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 秒 研究如何在数字空间中应用实验设计，清楚地了解正在使用的参数后再开始实验

上述提及

• DevJam
• Fredrick Brooks
• 故事映射
• Netflix
• Ted 演说：如何运用数据做出一个爆红的电视节目
• Nassim Taleb “获得成功”

关于我们的播客

你可以通过我们的 RSS feed 获得最新的播客，通过 SoundCloud 和 iTunes 收听我们的播客。在这个页面上，你可以点击笔记旁边的时间快速链接到播客音频的那一部分。

查看英文原文： Engineering Culture Podcast: David Hussman on Effective Product Discovery and Dude’s Law