以产品为导向的研究：一份面向研发负责人的实用指南【完整版书籍】

例如，分析工具可能会告诉您，70%的时间都被用于数据库查询，而20%的时间则浪费在网络延迟上——这些信息是使用其他狭义的方法无法获得的。

因此，答案很明显：分析工具在三个标准上都是最优的选择。这是您应该首先尝试的方法。

更新您的决策树：

这并不是说其他方法不好，也不是说分析工具就一定是最好的选择。只是考虑到您目前所掌握的信息，分析工具才是最佳的起点。

如果首选方法不起作用怎么办？

假设您尝试使用分析工具，但却遇到了问题：由于安全限制，该工具无法在生产环境中正常使用。

这是一个非常重要的信息。请将“分析工具”标记为“失败”，然后转向下一个最佳选项：

现在您可以尝试使用记录日志功能了。但请注意：您并没有在生产环境中花费大量时间去测试分析工具，而是及时转向了记录日志这个更可行的方法。这种决策树结构确实帮助您迅速做出了调整。

当各种方法看起来都差不多时该如何选择？

有时候，多种方法看起来似乎同样有效。分析工具和数据库分析工具可能都具有快速、低成本且覆盖范围广的特点。那么该如何做出选择呢？

选一个然后开始使用吧。不要花一小时去分析哪种方法更适合您，其实这个决策过程本身所花费的时间就不应该超过实际尝试这些方法所需的时间。

当各种方法看起来都差不多的时候，问问自己：“我对哪一种方法更熟悉？”或者“团队中谁有使用过哪种方法的经验？”根据自己的判断做出选择，然后立即开始学习如何使用所选的方法。

最糟糕的决定就是根本不做出任何决定。

一般来说，这种做法可能会让人觉得有些过分。在真正采取行动之前，真的有必要先绘制出各种分析框架并比较各个选项吗？

令人惊讶的是，虽然几乎每次这样做都会让人觉得有些多余，但实际上每一次都是值得的。试几次你就会明白这一点的。

启发式方法可以结合起来使用

有时候，你并不一定非得只选择一种方法。你可以同时运行“性能分析”功能并启用“数据库查询日志记录”功能。如果这两种方法不会产生冲突，并且你有足够的时间，那么并行进行这些分析会带来非常显著的成效。

但需要注意的是：不要试图一次性完成所有事情。先从最适合你的方法开始尝试；如果这种方法无法完全解答你的疑问，然后再添加其他方法。

答案如何引发新的问题

在将“性能分析”标记为红色之后，你接着进行了“日志记录”相关工作。你添加了一些具有提示作用的日志信息，然后让系统运行了一整天。最终你发现：70%的响应时间实际上都是由数据库查询所消耗的。

这个发现使得你不再需要使用其他分析方法了——因为你已经找到了答案。但更重要的是，这个发现也引出了新的问题：

看到这个分析框架是如何发展的吗？一个得到解答的问题会引发两个新的问题，而针对每一个新问题，又需要采取不同的方法来寻找答案。

在决定先回答哪个问题时，你也可以运用同样的逻辑：哪个方法能最快得到反馈？哪个方法的成本最低？哪个方法能解决最多的问题？

让我们进一步分析“哪些查询的运行速度最慢？”这个问题：

同样，你需要评估：哪种方法能最快得到反馈？启用“慢速查询日志记录”功能很可能就是最快的选择，因为只需要修改一下配置设置，然后等待几分钟就可以了。

你决定启用这个功能。经过进一步分析后，你发现：用户信息查询的运行速度最慢：它们需要执行15次独立的数据库查询操作（这就是所谓的“N+1问题”）。

（在这里，“N+1问题”指的是什么？当获取用户信息时，代码首先会查询用户列表（1次查询），然后针对每个用户再分别进行多次数据查询（N次查询）。如果共有15位用户，那么总共就需要执行16次查询操作。这种设计效率很低，会导致响应时间大大延长。）

这个答案引出了一个新的问题：

现在你有三种解决方法。再次评估一下这些方法：

• 使用JOIN语句重写查询：实现速度快，是一种经过验证的有效方法。

• 采用“快速加载”机制：具体效果取决于你使用的ORM框架，可能也会比较快。

• 使用DataLoader模式：需要学习新的技术方法，实施起来可能会花费更多时间。

如果你的团队对SQL非常熟悉，那么使用JOIN语句重写查询很可能会带来最快的解决效果。

整体情况分析

让我们看看经过几天的研究后，这个问题分析框架的整体结构是怎样的：

（注：对于“每个请求会产生多少条查询语句？”这个节点，为了简洁起见，我没有列出相关的解决方法。）

如何解读这个问题分析框架：

1. 我们首先从“瓶颈在哪里”这个问题开始，选择了性能分析这种方法，因为它能最快地提供反馈。

2. 我们发现由于安全限制，性能分析工具无法在生产环境中使用，因此转而采用了日志记录方法。

3. 通过日志记录，我们发现70%的响应时间都消耗在了数据库查询上。

4. 这个发现引出了两个关于具体查询语句的新问题。

5. 对于“哪些查询语句的执行速度最慢？”这个问题，我们选择了慢速查询日志记录功能，因为启用这个功能所需的时间最短。

6. 回答这个问题的过程又引出了另一个关于如何解决N+1问题的疑问。

7. 对于“我们该如何解决N+1问题？”这个问题，我们评估了各种解决方法，最终选择了“使用JOIN语句重写查询语句”这种方法，因为团队对SQL非常熟悉，实施起来也会很快。

8. 同时，“我们能否减少查询语句的数量？”这个问题仍然没有得到解答，还需要进一步进行研究。

颜色编码标识状态

在创建问题分析框架时，你需要用特定的颜色来标记各种问题和解决方法的状态。当然，以下这些具体的颜色建议仅供参考——最重要的是要保持一致性，这样你就能一眼看出各个问题的当前状态。

对于问题的状态：

• 未解决：还没有得到答案。

• 已解决：已经得到了答案。

• 必须先解决：在继续采取任何行动之前，必须先回答这个问题。

对于解决方法的状态：

• 可行：这种方法是可以尝试的。

• 需进一步研究：目前还不确定是否可行，需要进一步调查。

• 不可行：这种方法行不通，没有实际意义。

在上面的例子中：

• “使用连接操作进行重构”这一方案被标记为“绿色”，因为我们已经确定它能够有效解决特定的N+1问题，而且团队也有信心成功实施这一方案。

• “重新设计API”这一方案被标记为“红色”，因为实施这个项目需要花费太长的时间。

• 其他方案则被标记为“棕色”，因为我们还没有对这些方案进行深入研究。

额外提示

保持决策树的简洁清晰非常重要，过度纠结于其外观或细节反而会偏离重点。不过，有些读者可能会发现，在决策树中添加一些额外的细节会带来好处，具体如下：

1. 顺序记录：在处理某个分支时，在其旁边标注相应的编号，这样就能清楚地了解自己最初尝试了哪个方向、接着又选择了哪一个方案等等。

2. 原因说明：如果决定从某个分支转向另一个分支，请写明原因。这在日后修改决策或与团队讨论时会非常有用（具体内容见本章后面的部分）。

• 笔和纸（说真的，这个方法非常有效。）

• 白板（适用于团队会议。）

• Miro、Mural或其他类似的数字白板。

• 思维导图软件（如XMind、MindNode等）。

• 甚至是一个带有缩进格式的简单文本文件也完全可以使用。

工具本身并不重要，关键是要确保这个研究框架的存在、可见性以及及时更新。

专业建议

从最重要的问题开始

不要一开始就试图列出所有可能的问题。先从那个如果得到答案就能帮助你明确下一步行动方向的问题入手。回答这个问题之后，再看看会引发哪些新的问题。关于如何确定应该从哪个问题开始讨论，请参阅第7章。

要弄清楚答案是如何引出新问题的

当你解决了某个问题后，马上思考：“这个问题的答案会引发哪些新的问题？”把这些新问题作为分支添加到原来的框架中。

每周更新一次问题列表在每周的总结会议上，请明确地讨论以下几点：哪些问题已经得到了解决？我们从中获得了什么经验？又出现了哪些新的问题？哪些问题正在阻碍我们的进展？当环境发生变化时，需要重新评估

如果你学习了新的知识，而这些新知识改变了原有的评估结果（比如你原本认为某个工具运行速度很快，但实际上却很慢），那么你就需要重新审视自己的方法。这个“研究框架”是一个动态变化的工具——你需要及时更新它。

总结——研究框架

研究框架是一个动态的可视化工具，它的作用包括：

• 帮助你明确为实现目标需要解决哪些问题。

• 为解答每个问题提供相应的方法路径。

• 协助你选择解决每个问题的最佳起点。

• 防止你不假思索地采纳第一个出现的想法，而忽略其他可能性。

• 清晰地展示答案如何引发新的问题。

• 跟踪各个问题以及相应方法的进展状态（如是否已解决、当前处于哪个阶段）。

• 记录整个研究过程，让团队能够理解各项决策的依据。

• 随着你的学习不断深入，这个框架也会随之发展——一些问题会得到解答，同时新的问题也会出现。

核心结构：

• 目标 → 需要解决的问题 → 解决问题的方法 → 答案 → 新出现的问题

选择方法的决策依据：

1. 哪种方法能最快得到反馈结果？

2. 哪种方法的成本最低？

3. 哪种方法能解决最多的问题？

在下一章中，你将学习如何通过设置时间限制和决策节点来管理研究进程，从而确保研究工作能够顺利推进而不陷入停滞。

第5章——基于时间限制的研究方法

在上一章中，你了解了研究框架这一强大的工具。它能够帮助你系统地探索不同的解决方案，并随时跟踪尚未解决的问题。同时，它也能帮助你决定先尝试哪条路径。

但是，一旦你选择了某一条路径，应该持续探究多久之后才需要重新考虑其他方案呢？

问题：没有时间限制的研究

有一位研究人员试图验证某种机器学习模型是否能够预测代码的复杂度。第一天进展顺利，第二天却发现需要添加更多的特征，第三天又认为另一种架构可能更合适，于是他们改变了方向；到了第四天，新的架构却又需要不同的预处理步骤。

两周过去了，他们仍然停留在这条路径上。当被问及是否应该尝试其他方法时，他们却回答：“我快成功了，再坚持几天就行。”

三周后，他们终于承认这种方法是不可行的。而与此同时，在研究框架中，还有另一种更简单的方法始终未被尝试过。

如果没有明确的时间节点作为参考，就很难判断“根据目前所掌握的信息，这条路径是否仍然是最佳选择”。人们往往会陷入“沉没成本谬误”——因为已经投入了时间，所以继续坚持这种方法，而不是基于它是否真的是最好的解决方案来做出决定。这种情况在研究人员中尤为常见，因为他们通常是那些非常专注、才华横溢的人，一旦开始研究某个问题，就会全身心地投入到其中。

时间箱法：确定决策节点

我们必须面对这样一个事实：估算一项研究任务需要多长时间是件非常困难的事情，甚至几乎是不可能的。但即便如此，你仍然应该根据自己愿意投入的时间来设定截止期限。

时间箱法能够强制你在特定的时刻做出决策。

需要注意的是，我们这里讨论的不是最后期限，而是决策节点。这些节点就是你需要停下来重新评估自己的时刻：我学到了什么？这条路径仍然是最有前景的吗？

一般来说，对于任何持续时间超过一天的任务，都应该设定一个时间限制。例如：“我会花三天的时间来研究是否可以根据文件的I/O操作将它们分类到不同的文件夹中。”

可能会出现以下三种情况：

1. 提前完成任务：研究者可能在几小时内就解决了问题。既然提前完成了，就可以接着去探讨下一个问题。

2. 遇到早期障碍：一小时后，他们可能会发现自己无法获取某些文件的名称。这时他们就需要立即重新考虑：“如果没有这些文件名称，这个计划还能继续执行吗？”

3. 时间箱期限到期：三天过去了，但只完成了一部分工作。此时，就必须做出决定了。



决策节点

当时间箱期限到期时，就立即停止当前的工作。拿出你的研究框架图（没错，你肯定已经很喜欢这个工具了），然后问自己三个问题：

1. 你当初选择这个方向进行研究，目的是什么？
你究竟想解决什么问题？为什么会选择这种方法而不是其他方案呢？

2>你学到了什么？
把你的发现记录下来，即使这些发现还不完整：

• “这种方法确实有效，但需要使用比我们原本设想的更复杂的算法。”

• “我们需要一些目前还没有的数据。”

• “这个任务的难度超出了预期，至少还需要两周时间才能完成。”

• “我们已经完成了70%的工作，只需要处理一些边缘情况就可以了。”

3>根据你目前所掌握的信息，这条路径仍然是最有前景的吗？
再看看你的研究框架图。你是否还有其他可行的方向？考虑到你现在所了解的情况，继续沿着这条路径前进是否还是最合理的选择呢？



你有三个选择：

你可以设定一个新的时间箱来继续这项工作：“我已经解决了核心问题，还需要再花一天时间来处理边缘情况。”重新设定时间限制。关键在于：你是基于自己所学到的知识才决定继续前进的，而不是出于惯性。

你可以转变思考方向：“这还需要再花两周时间，而且我并不确定这种方法是否有效。在我的思维框架中还有更简单的解决方案。”把这一分支标记为红色，然后转向另一个分支继续思考。

或者你也可以重新审视这个问题：“这个代码库中的文件并没有明确的输入/输出处理模式。或许应该尝试根据函数之间的依赖关系来进行分类分析。”回到你的思维框架中，找出另一个需要探讨的问题。

示例：识别“上帝对象”

你正在通过静态分析来识别那些功能过于复杂的“上帝对象”。你的思维框架中列出了三种分析方法：复杂度指标、方法命名规则，或者基于抽象语法树特征的机器学习分析。

你选择了复杂度指标这种方法（因为反馈最快，成本也最低），并为这个分析过程设置了2天的时间限制。

第1-2天：你实施了循环复杂度和代码行数这两种评估指标。测试结果显示：准确率为65%，但误报率达到了40%。

决策点：你决定暂时停止这项工作。仔细思考后，你觉得方法命名规则可能会提供一些补充信息，于是决定再花1天时间探讨将这两种方法结合使用是否能够提高准确率。

第3天：将两种方法结合起来进行测试，最终得到的准确率为78%，误报率为25%。这个结果相当令人满意。

新的决策：你决定再为这项工作设置3天的时间限制，以便在更大的代码库上进一步进行测试和完善。

需要注意的是：正是由于设置了2天的时间限制，你才不得不在第一次方法未能取得理想效果之前就对其进行评估。通过这次尝试，你认识到将多种方法结合起来使用会取得更好的效果。如果没有时间限制，你可能会花费整整一周的时间来完善其中的一种分析方法。

如何设置时间限制

在选择思维框架中的某个分支进行深入研究时，先问问自己：这个任务需要不到一天的时间来完成吗？还是需要几天的时间？又或者需要超过一周的时间呢？

如果所需时间少于一天：那就直接开始行动吧。对于这样短期的任务，没有必要过度纠结于时间限制的设置。

如果所需时间为2到7天：建议将时间限制设定为2到5天。我通常会把实际需要的时间稍微缩短一些来设置时间限制——比如如果我认为需要4天的时间，就会实际设定3天。这样就能迫使自己在完成任务的过程中不断反思和总结经验，而不是盲目地坚持到底。

如果所需时间超过一周：最多将时间限制设定为1周。即使你正在取得进展，一周的时间也足够让你停下来重新审视整个计划，看看是否有需要调整的地方。



不要过度纠结于时间限制的具体时长。关键是要设置一些自然的停顿点，而不是规定一个必须完成的固定时间。

重要提示：设定时间限制的目的并不是为了制造压力。如果时间到了而问题仍未解决，这并不意味着你失败了——在研究过程中，这种情况是很常见的。时间限制的作用在于迫使你在关键时刻停下来反思，从而避免在错误的道路上浪费数周的时间。

与团队一起使用时间箱法

在管理研究人员时，应在规划阶段共同确定时间框。要确保他们明白这是一个决策节点，而不是截止日期，并且要明确安排审查会议。

在审查会议上，大家一起审视研究框架，提出三个关键问题，然后共同做出决定。这样能防止研究人员在遇到困难时不敢寻求帮助，同时也能让调整方向被视为一种积极的决策，而非失败的表现。

与研究框架的结合

时间箱法与研究框架能够自然地结合起来：第4章中提到，每个研究方向都会被分配一个时间框，当这个时间框结束时，研究框架会显示出可供选择的方案。

时间箱法为人们提供了这样的机会：“根据我目前所掌握的信息，接下来应该做什么？”而研究框架则有助于帮助你回答这个问题。

总结

对于持续时间超过一天的任务，应设定明确的时间限制（中等难度任务一般为2到5天，最长不超过1周）。当时间到期时，要停下来利用研究框架进行评估：我的目标是什么？我学到了什么？这仍然是最优的选择吗？

时间箱法承认研究过程中的估算往往具有不确定性，它能避免人们陷入“沉没成本谬误”或无休止的探索中。它的目的不是为了施加压力或确保任务“按时完成”，而是为了促使人们进行反思，而不是盲目地继续原有计划。

将时间箱法与研究框架结合起来，就能在尊重研究本身不确定性的同时，让你更好地掌控研究的进展过程。

第2部分总结

高效的研究工作需要结构化的方法，而不仅仅是技术能力：

• 研究框架有助于清晰地展示解决方案的路径、未解决的问题以及已经解决的问题。

• 时间箱法能防止无休止的探索，同时保持研究的灵活性。

• 系统的评估过程能帮助你选择最合适的发展方向。

在第2章中，我指出作为研究负责人，你的职责是：

1. 确保研究工作能够对产品产生实际影响。

2. 确保研究工作得以高效完成。



这一部分主要讨论了作为研究负责人的第二项职责：如何确保研究工作的高效进行。

具体来说，你的职责包括：

1. 确保团队始终遵循这些方法进行研究。

2. 帮助判断何时应该调整方向，何时应该坚持原有计划，以及哪些问题才是真正重要的。

这些工具能够帮助你避免一些常见的错误：比如盲目接受第一个出现的想法、陷入狭隘的思维模式、学习效率低下，或者浪费时间去解答无关紧要的问题。

第三部分介绍了如何将研究工作与产品实际效果联系起来。

第三部分：确保产品效果

第二章中，我指出作为研究负责人，你的职责在于：

1. 确保研究工作能够对产品产生实际影响。

2. 确保研究工作得以有效开展。

第二部分已经讨论了上述第二个要点——如何确保研究工作有效进行，并且这些方法适用于任何类型的研究环境。而这一部分则提供了解决第一个要点的完整方案，即如何确保研究工作与产品效果紧密相连：

• 首先，选择那些真正有意义的研究课题（第六章）。

• 然后，从产品所具有的价值出发，反向思考研究方向（第七章）。

• 通过循环迭代的过程，不断验证研究方向的正确性（第八章）。

第六章——如何选择研究课题

要确保你的研究工作能够对产品产生实际影响，第一步就是选择合适的研究方向。同样重要的是，要避免那些无法对产品产生任何作用的研究项目。

研究课题可以从两个不同的角度出发来确立：

1. 从产品当前面临的问题入手。

2. 从现有的技术机遇出发。



1. 从具体问题入手

要想找到那些能对产品产生重大影响的研究课题，最有效的方法就是从产品当前面临的具体问题出发。

Swimm项目中，我们允许用户为他们的代码编写文档，但不可避免地，随着代码的更新，这些文档也会变得过时。这样一来，编写文档就完全失去了意义。我们需要找到一种方法，让文档能够自动保持最新状态，同时还能提供良好的用户体验。这就是我们面临的一个明确问题，而且我们当时还不确定是否有可能解决它。

再举一个例子：某家医疗公司希望仅通过分析少量血液样本来诊断疾病。目前他们虽然已经开发出相应的算法，但其准确性并不高，尤其是假阳性结果太多。他们需要找到一种方法来提高预测的准确性。这同样是一个产品所面临的具体问题，而且目前还没有明确的技术解决方案。

在这两种情况下，问题都很明确，它们对产品或公司的影响也显而易见。然而，相应的解决方案却并不清楚，而且也不能确定这样的解决方案在技术上是否可行。

2. 从技术机遇入手

当生成式人工智能开始流行时，许多公司都开始探索如何利用这项技术来改进自己的产品。这就是一个例子：新兴技术能够为产品带来新的功能。

同样的情况也可能发生在一些规模较小、针对性更强的技术上，并不一定非得是全新的技术——有时候，相关团队只是刚刚熟悉了某些现有的技术而已。例如，如果一位研究人员读到了一篇关于某种新代码解析方法的论文，他或许就会想到可以利用这项技术来开发新的产品功能。

虽然许多好的想法都是源于技术机遇，但我们需要记住：研究的真正意义取决于最终产生的产品，而不是所使用的技术本身。追逐一个技术机遇往往比解决一个具体的问题风险更大。如果你决定基于某个技术机遇开展研究，那么你的责任就是确保：如果这项技术得以成功应用，它确实能够对产品产生重大影响。

问题驱动与机遇驱动：对比分析

方面	问题驱动型研究	机遇驱动型研究
出发点	客户的痛点或产品的局限性	出现了新的技术或方法
产品影响的确定性	很高——你清楚地知道自己在解决什么问题	较低到中等——你在探索这项技术能够解决哪些问题
风险等级	较低——如果成功了，肯定会有市场需求	较高——解决方案可能无法解决任何重要的问题
验证过程	问题已经通过用户反馈得到了验证	需要验证该解决方案是否对用户有用
典型例子	Swimm的自动更新文档功能；减少医疗诊断中的误报现象	“我们如何在产品中运用大语言模型？”;“这种新的代码解析技术或许能实现……”
成功标准	我们是否解决了问题？	我们是否找到了有价值的应用场景，并且确实解决了问题？

问题驱动型研究始于已经得到验证的市场需求——你明确知道这个目标值得去追求。而机遇驱动型研究则更像是在“用锤子找钉子”：有时候你会找到有用的东西，但这种做法的风险也更大。



你是否应该开展一项研究计划？

假设你有一个研究计划——一个你想深入研究的想法。要判断是否应该继续推进这个计划，你需要能够回答以下几个简单的问题：

1. 产品影响——如果这项研究取得成功，它会对产品产生多大的影响？

这是最关键的问题。

对于那些由具体问题驱动的研究项目来说，这个问题的答案通常很明确：“如果我们解决了自动文档更新的问题，那么目前因为文档过时而流失的40%的客户就会重新回到我们的产品中。”

而对于那些基于市场机会开展的研究项目，则需要进一步深入分析：“如果我们将大语言模型应用于代码分析，就可以实现某项新功能，从而帮助某些用户每周节省大量时间，进而为公司带来额外的收入。”

如果你不确定这项研究成功后会对产品产生多大的影响，那么目前可能还不值得继续推进这个计划（直到你确信它会产生巨大的影响为止）。所谓“巨大的影响”，指的是：

• 解决客户最关心的三大问题之一，或者

• 推出一项能够显著扩大产品市场范围的新功能，或者

• 有效降低某种主要的成本或风险因素

如果效果达不到这些标准，那么把你的资源用于那些能带来更明确投资回报的开发工作会更为明智。



2. 产生效果所需的时间——我们需要等待多久才能看到研究成果对产品产生的实际影响？

在软件开发领域，时间估算向来是一件困难的事情。对于开发任务来说如此，而对于研究项目而言更是如此。在第5章中，你已经学会了如何在研究过程中应对这种不确定性，但即便在目前这个研究计划尚未正式开始的阶段，你也应该考虑整个时间安排。

你可以问自己以下两个相关的问题：

• 这项研究本身需要多长时间？

• 从研究成功到看到实际产品效果，还需要再等待多久？

整体时间安排非常重要，因为：

• 如果一项研究需要6个月的时间，但能立即为产品带来价值，那么这项研究可能是值得进行的。

• 如果一项研究只需要2个月的时间，但却需要再花费8个月才能完成开发工作，而你的产品规划又无法容纳这样的时间安排，那么这项研究可能就不值得继续进行了。

• 如果一项研究需要1年的时间，而且其结果也存在不确定性，那么除非它有可能带来革命性的影响，否则这项研究很可能不值得推进。

当然，实际所需的时间长度会因具体情境而有所不同（尤其是会受到你所在公司的具体要求的影响）。

你还需要考虑是否能够通过这项研究获得逐步积累的价值。即使最终的解决方案需要9个月才能完成，但如果你能在3个月内看到一些初步的效果，那么这项研究的风险就会大大降低。



3. 资源：你是否具备开展研究所需的条件？

进行研究不仅需要“开发时间”，还需要特定的资源：

知识：你的团队中是否有熟悉以下领域的成员：

• 技术领域（例如自然语言处理、编译器设计、分布式系统）？

• 业务领域（例如医疗诊断、金融法规）？

• 是否解决过类似问题？

如果没有，你是否能在合理的时间内获取这些知识？（花一周时间阅读相关文献是可行的，但获得博士学位则不现实。）

人力投入：你能否在预期的研究期间专门安排一个人或几个人来从事这项工作？研究需要持续的专注力——如果让某人10%的时间用于研究，90%的时间用于处理紧急的产品开发任务，那么这种安排很少能取得成功。

外部依赖：你是否需要以下条件：

• 访问特定的数据或系统？

• 其他团队的协作？

• 外部专家的支持或咨询服务？

• 用于购买工具、云服务或数据集的预算？

如果关键资源无法获得，或者获取成本过高，那么这个项目可能就无法继续进行。



前期研究检查

对于上述三个问题，你可能还没有明确的答案。在这种情况下，在真正开始进行研究之前，花时间去解答这些问题是很有必要的。这个阶段的时间应该控制在有限的范围内——理想情况下是几天，最多一两周。

在这个阶段，你可以采取以下措施：

1. 与客户和业务相关方进行访谈，以了解解决这个问题所能带来的实际效果。

2. 查阅相关技术资料，以及该领域以往的研究成果，从而评估项目的可行性和时间安排。

3. 咨询那些曾经面临过类似挑战的人，比如内部专家、学术界人士或你的人脉中的实践者。

4. 进行简单的可行性测试——不必进行全面的研究，只需验证一些基本问题，例如“我们能否获取所需的数据？”或者“我们的开发语言中有这个库吗？”

完成前期研究检查后，你应该能得出一个明确的结论：“是的，我们应该继续推进这个项目，因为它带来的影响是X，预计完成时间为Y，并且我们已经具备了所需的资源。”

如果你对项目所能产生的实际效果没有信心，就不要开始进行研究。这听起来可能有些苛刻，但实际上非常重要：如果研究方向不明确，或者与产品需求无关，那么就会浪费你最宝贵的资源——那些才华横溢的工程师的时间和精力。在第7章中，介绍了一种提高你对项目效果把握度的方法。

接下来的章节假定你已经了解了成功的研发成果会对产品产生的影响，这些内容将帮助你尽快实现这一目标。

如何选择研发项目——总结

研发项目通常可以从以下两个方面入手：

• 问题驱动型：明确的产品需求（这是首选方式）

• 机会驱动型：新兴技术带来的发展机遇（风险较高）



在开始研发工作之前，请先回答以下三个问题：

1. 产品影响：成功实施后是否能为产品带来巨大价值？

2. 见效时间：需要多长时间才能看到实际成果？

3. 资源准备：我们是否具备所需的知识、能力和相关资源？



如果对这些问题的答案还不清楚，请尽快进行前期调研（几天内完成，而非几周）。

只有当你确信研发项目能对产品产生实质性影响时，才应该真正投入精力去实施它。

下一章将介绍如何在整个研发过程中始终保持这种与产品的紧密联系。

第7章——逆向思考

既然你已经选择了合适的研发项目，并且也是按照第6章中的方法来选择的，那么接下来该如何开始着手这项工作呢？

大多数团队通常会先从解决技术难题入手：分析COBOL代码、构建调用关系图、实现各种算法。但实际上，有一种更有效的方法能够确保你的研发工作真正对产品产生作用：从最终目标出发，逆向思考。

这种从目标倒推的思维方式，是解决问题时最有效的策略之一。让我通过一个简单的游戏来向你说明这一点。

螺旋游戏

让我们来看这个游戏：



游戏规则很简单：

• 棋子初始位于第41格。

• 每轮游戏中，玩家可以将棋子向后移动1到6格。也就是说，如果棋子在第41格，那么它可以移动到第35到第40格之间的任意位置。

• 最终将棋子移动到第1格的玩家获胜。

请稍作思考：如果你先走，该如何下棋才能确保获胜呢？

（我真心建议你们花点时间自己试一试。）

大多数人会从当前的位置开始思考，然后尝试推演后续的走法：“如果我移动3格，对方可以移动2格，那么我就可以再移动4格……”但这样很快就会让人感到无从下手——有太多可能的走法需要考虑。

然而，如果你逆向思考，答案就会变得清晰起来：

从终点位置开始分析：

• 要想获胜，你在自己的回合时必须让棋子位于位置1。

• 由于对手刚刚移动过，所以他们的棋子现在可能位于位置2到7之间（因为他们是从原来的位置向后移动了1到6格）。

• 无论对手的棋子当前位于位置2到7中的哪个位置，你都可以直接将自己的棋子移到位置1。

• 结论：如果在你的回合开始时，对方的棋子位于位置2到7之间，那么你就一定能获胜。



继续逆向思考（从位置2到7开始）：

• 你希望对手的棋子落在位置2到7之间。

• 无论对手从位置8开始如何移动，他们的棋子最终都会落在位置2到7之间。

• 结论：如果你能让自己的棋子移到位置8，那么你就一定能获胜。



继续从位置8逆向思考：

你会发现，此时你已经构建了一个“新的”游戏规则：你不再需要让棋子先移到位置1才能获胜，只要将棋子移到位置8就可以了——因为从那个位置开始，无论对手如何行动，你都能确保胜利。

那么，如何才能确保自己的棋子能够移到位置8呢？

• 位置9到14都可以让棋子移动到位置8。

• 因此，如果对手在他们的回合开始时让棋子位于位置9到14中的某个位置，你就可以迫使他们的棋子移到位置8。

• 这意味着你不应该让棋子落在位置9到14之间，而应该让棋子移到位置15——因为这样就能迫使对手的棋子落在位置9到14中的某个位置。



同样，你此时又构建了一个“新的”游戏规则：你的目标现在是让棋子移到位置15。从那个位置开始，你就已经知道如何获胜了。

你可以继续这样逆向思考下去——你会希望自己的棋子落在位置16吗？或者位置17呢？直到最终……

规律就会显现出来：

• 对你来说安全的落子位置有：1、8、15、22、29、36。

• 无论你从这些位置中的哪一个开始下棋，对手都无法避免再给你提供一个安全的落子位置。

• 这些位置都可以用公式1 + 7n来表示。



获胜策略：

• 从位置41开始，向后移动5个位置，即可到达位置36（这个位置是“安全位置”）。

• 无论对手采取什么行动，你都可以始终移动到下一个“安全位置”。

• 最终，你会到达位置1并获胜。

请注意：通过从目标位置反向推导，你找到了这个系统的解决方案。如果从起始位置向前推进，就会困难得多。

实际上，你还运用了另一种非常有效的启发式方法：先考虑一些特定的情况（如1、8、15、22、29、36），然后将其归纳为通用规律（即1+7n）。这种启发式方法在研究中也很常见，不过在那些旨在确保产品效果的研究中并不常用。

如何将反向推导的方法应用于以产品为导向的研究中

让我们把这种方法应用到以产品为导向的研究中。当你面临一个复杂的研究课题时，应该问的不是“我应该先解决哪个技术问题？”，而应该是：

“如果这项研究取得了成功，最终会得到什么样的结果？”

这种思考方式会迫使你：

1. 关注产品效果：你必须设想出能够创造价值的最终结果。

2. 系统地进行分析：就像那个螺旋游戏一样，你需要反向梳理各种相互依赖的关系。

3. 验证假设的正确性：在解决各个子问题之前，必须确保它们能够帮助你实现最终目标。

让我为大家介绍一下这种方法在Swimm公司是如何实际应用的。

案例研究：从COBOL代码中提取业务规则

在Swimm公司，我们希望能够自动从COBOL代码库中提取出所有的业务规则，并将这些规则生成成文档。

关于业务规则的简要说明：业务规则是指那些嵌入在软件中的约束条件、行动方案等元素，它们反映了企业的具体政策。例如，在资金转账的过程中，就有以下这些业务规则：

• 客户的转账金额不能超过其账户余额（即使有透支限额也不行）。

• 高额转账需要经过额外的验证流程。

• 跨货币转账必须使用当前的汇率进行计算。

有些资料将业务规则定义为包含三个要素的结构：事件、条件、行动方案：

ON <Event>
IF <Condition>
THEN <Action>
ELSE <Action>

我们的目标是从COBOL代码库中提取出所有的业务规则。虽然在任何代码库中实现这一目标都不容易，但在处理那些老旧的COBOL代码时，这个问题会更加突出。（如果你对技术细节感兴趣，可以阅读这篇文章。）对于这本书来说，只需要知道在过去的几十年里，许多研究工作者都尝试过不同的方法来应对这一挑战就可以了。

应该从哪里开始呢？

面对这个问题，你可能会想到：

• 第6章）

每一条建议可能都需要单独进行研究。那么，到底应该从哪里开始呢？



逆向思考：从最终结果开始

通过逆向思考，我们提出了这样一个问题：

当初提出这个问题的时候，我们并不清楚答案。虽然我们知道客户希望提取出业务规则，但并不知道“理想的”输出结果应该是什么样的。



因此，我们决定在开始解决任何技术问题之前，先手动编写一些文档，将这些样本程序中的业务规则提取出来并记录下来。这个过程完全是手工完成的：没有使用任何解析工具或算法，只是通过自己理解COBOL代码来编写文档。

我们对不同类型的应用程序以及来自不同代码库的样本进行了这样的操作，从而得出了以下结论：

• 并没有一种固定的、正确的方法来编写这类文档。

• 不同程序的输出结构是有所差异的。

• 在业务逻辑中，某些模式会反复出现。

通过这种手动编写文档的方式，我们形成了一个假设：

但这个假设真的正确吗？

验证假设

一旦我们手动完成了文档的编写，就可以开始验证这个假设了。有了具体的输出结果，我们可以：

1. 在团队内部进行讨论——向那些既了解COBOL语言又熟悉我们产品的工程师征求意见。

2. 与客户取得联系——向他们展示实际的输出结果，并询问：“这样的结果能解决你们的问题吗？”

在明确目标之前，我们刻意避免去解决那些复杂的技术难题。



通过子问题逆向推进工作

这些手册还为我们提供了至关重要的东西：一些可供我们逆向分析的具体案例。

例如，我们发现这些文档中列出了许多条件。这让我们意识到，我们很可能需要：

1. 在代码中找出这些条件。

2. 筛选出与业务相关的条件

3. 区分技术条件与业务条件。

4. 在文档中解释这些条件的含义。

这就是逆向分析之所以如此有效的原因：我们先解决了第（3）步，然后再解决第（2）步，最后才处理第（1）步。

为什么呢？因为要实现我们的目标——编写出有实际意义的文档，就必须先完成第（3）步。

这意味着我们可以暂时忽略前两步，假设我们已经掌握了查找条件以及筛选业务相关条件的方法。这样，我们就可以先列出所有与业务相关的条件，然后专注于在输出文档中清晰地解释这些条件。

这种做法可以避免我们花费数周时间去完成第（1）步和第（2）步，结果却发现第（3）步的方法根本行不通。如果我们在假设第（1）步和第（2）步已经解决的情况下仍然无法完成第（3）步，那么整个方法可能就不适合我们了，我们需要重新考虑其他方案。

逻辑很清楚：虽然解决第（3）步最终需要完成第（1）步和第（2）步，但如果即使完成了前两步，第（3）步仍然无法成功，那么继续进行第（1）步和第（2）步可能根本就不值得。

在实践中，“模拟依赖关系”具体指的是什么？在我们的案例中，模拟第（1）步和第（2）步意味着我们要亲自从COBOL代码中找出一些与业务相关的条件，而不是使用自动化系统来查找它们。我们手动编制了一份清单，列出了那些我们知道与业务相关且存在于样本程序中的条件，然后利用这份清单来测试我们在第（3）步中的解释方法。

为什么逆向分析如此有效

从游戏示例和COBOL案例研究中都可以清楚地看到逆向分析的优势：

1. 强迫人们将技术实现与产品实际效果联系起来

就像在螺旋游戏中从第1点开始逆向推进一样，先思考“成功的输出结果应该是什么样的？”这种思维方式会让你始终关注最终用户的需求。如果没有明确的目标，就无法进行逆向分析。这样就能避免那些虽然技术在上很先进，但实际对产品没有帮助的研究项目。

2. 为工作进程提供清晰的方向

当研究看起来像是一项庞大而令人望而生畏的任务，且存在无数种选择时，采用逆向思考的方法就能提供一种系统化的解决途径。正如在那个螺旋游戏中，一旦你逆向分析出安全位置（1、8、15、22……），整个游戏就会变得简单起来一样，在进行研究时，如果你从期望的结果出发，逆向分析各种依赖关系，研究工作也会变得更加容易应对。

3. 在投入大量精力之前验证每一步骤

采用逆向思考的方法，你可以确保在投入大量精力之前，每一个子问题确实都能为你的目标做出贡献。以COBOL为例，在花费数周时间去寻找和筛选各种条件（即步骤1和步骤2）之前，我们可以先验证我们的分析方法是否有效。

实际应用：你的研究框架

逆向思考的方法与第4章中介绍的研究框架能够自然地结合在一起。在构建研究框架时：

从结果出发开始：

• 框架的起点：“制定具有实际影响力的业务规则文档”。

• 第一个问题：“成功的成果应该具备什么特征？”

• 解决方法：创建具体的示例。

然后逆向分析：

• 一旦得到了预期结果，再问自己：“要实现这个结果，我们需要解决哪些问题？”

• 这样就能找出真正的子问题及其相互依赖关系。

• 每个分支都代表一个需要解决的先决条件。

在深入研究之前进行验证：

• 在深入探讨任何一个分支之前，先问自己：“解决这个问题后，我真的会更接近目标吗？”

• 可以通过模拟依赖关系来低成本地测试各种方法。

• 利用时间限制机制（来自第5章），来控制对任何分支的探索范围。

总结：逆向思考的方法

逆向思考是一种从期望的最终结果出发，逐步回溯到当前阶段的系统化思考方法。

在以产品为导向的研究中，逆向思考意味着：

1. 首先明确成功的成果应该是什么样的（通常需要通过手动或半手动的方式来确定）。

2. 在进行技术性工作之前，先与相关方一起验证这些成果是否合理。

3. 然后逆向分析各种依赖关系，并按相反的顺序逐一解决这些问题。

4. 在投入大量资源之前，确保每一步骤都能为最终目标做出贡献。

这种思考方式能确保研究工作与产品的实际效果紧密相连，因为你是从产品目标出发来进行研究的。即使面对看似复杂的问题，这种方法也能帮助你有条不紊地推进工作，并在投入大量资源之前对每一步骤进行验证。

与其他工具的结合：

• 结合“研究框架”（详见第4章）来分析各部分之间的依赖关系。

• 运用时间箱管理方法（详见第5章），以限制对每个研究方向的探索范围。

• 将这种方法与事前的可行性评估相结合（详见第6章），从而验证所提出方案的实际效果。

在下一章中，你将了解到逆向思考方法存在的两个局限性，以及如何通过持续的端到端迭代来克服这些局限性。

第8章 – 端到端迭代

你最重要的职责就是确保研究工作能够对产品产生实际影响。然而存在一个重大风险：可能会花费数周时间去研究那些看似至关重要的问题，结果却发现它们实际上并不会对产品产生影响。

在第7章中，我提倡采用逆向思考的方法——从产品的最终目标出发，再回溯到研究问题本身。这种方法确实非常有效，因为它能迫使你专注于最终结果，并通过用户的反馈来验证这些想法的可行性。

但是，仅依靠逆向思考方法也存在局限性。此时会出现两个风险：

风险1：在实践中无法实现 你手动构建的“理想输出”可能在技术上不可行，或者其生成成本会高得难以承受。只有当你尝试去实现它时，才会发现这些问题。

风险2：缺乏实际验证 由于你没有完成整个端到端的过程，因此很可能没有在真实的数据环境中测试过你的解决方案（假设在手动设计阶段你无法获取这些数据）。以我们在前一章中提到的COBOL例子来说，那些在精心挑选的示例上可行的方法，在真实的代码库中可能会失败。

正是由于这两个风险，我才提倡采用持续的端到端迭代方法。

逆向思考 + 端到端迭代：一种结合性的方法

这两种方法并不是相互竞争的，而是相辅相成的：

方法名称	用途	能为你带来什么	优势	局限性
逆向思考（第7章）	明确目标与实现路径	1. 确定最终输出结果；2. 构建达到该目标的步骤链；3. 明确各步骤之间的依赖关系。	能确保开发工作始终围绕产品目标进行；有助于确定需要构建的内容。	提出的假设可能不正确；且无法在实际数据中验证其可行性。
端到端迭代（本章内容）	通过实际测试逐步验证并完善方案	1. 确认整个步骤链是否可行；2>从真实数据中获取反馈；3>优先处理那些能产生实际效果的改进措施。	能有效验证方案的可行性；帮助找出真正有效的方法。	如果没有明确的目标和步骤链，就很容易迷失方向。



推荐的流程如下：

1. 首先使用逆向思考方法来：

   • 明确最终目标输出结果（通过手动创建示例，并让用户进行验证）。

   • 确定实现该目标所需的中间步骤及其顺序。

   • 理清各步骤之间的依赖关系。

2. 然后转为端到端迭代方法来：

   • 测试你假设的步骤链是否真的可行。

   • 在真实数据中验证这些方案的有效性（而不仅仅是基于手动创建的示例）。

   • 逐步朝着目标推进开发工作。

3. 在整个迭代过程中，始终以最初确定的目标和步骤链作为指导原则。

通过逆向分析，你就可以勾勒出整个端到端流程（如下所述的第1条原则）。端到端的迭代过程会逐步验证并完善这一流程，从而了解哪些方法有效，哪些无效。

端到端迭代的五大原则

端到端的方法依赖于以下五条原则：

1. 首先勾勒出整个端到端流程。

2. 通过简化步骤来实现端到端的流程。

3. 尽快将成果交付出去。

4. 逐步替换现有的处理步骤。

5. 定期获取关于成果的反馈意见。

让我用第7章中提到的COBOL业务规则示例来解释这些原则。由于这本书并非专门讨论COBOL语言，因此我的解释会简短一些，重点介绍这种方法论本身。



原则1：勾勒出端到端流程

首先，从输入到输出，完整地勾勒出整个流程。更准确地说，你应该勾勒出这个假设的端到端流程——因为在实际测试用户之前，你无法确定这一流程的具体细节。

如果你按照第7章中介绍的逆向分析方法来操作，那么你已经得出了这个端到端流程框架。逆向分析自然会形成这样的链条：你从最终结果开始思考，接着追问“要实现这个结果需要什么？”，再进一步追问“实现那个需求又需要什么？”，如此不断倒推，最终就能得到整个流程的框架。

以COBOL业务规则为例：我们通过逆向分析发现，文档中需要添加专门解释业务规则的章节；而要编写这些解释内容，就必须先判断各种条件是否符合业务要求；要判断条件是否满足需求，就需要解析COBOL代码。经过这样的逆向推理，我们得出了以下流程步骤：

1. 从COBOL程序开始分析。

2. 将COBOL程序解析成抽象语法树。

3. 遍历抽象语法树以找出所有条件。

4. 筛选出与业务相关的条件，排除技术性条件。

5. 针对每一条业务规则，编写相应的文档章节来解释相关条件。

6. 根据各业务规则之间的依赖关系，对文档章节进行排序。

这就是你的初稿——通过逆向分析得出的这个假设性流程框架。



如何制定大纲：

• 在白板上画出相应的框框。

• 如果流程具有非线性特征，可以使用流程图来表示。

• 在整个研究过程中，都要确保这个大纲清晰可见。

• 随着研究的进展，及时更新这个大纲。

这个大纲就像你的路线图——它能告诉你目前处于什么阶段，以及你最终的目标是什么。

原则2：通过简化实现端到端的流程

你的目标就是让整个流程能够顺利地从开始一直进行到最后。从输入数据开始（比如一个COBOL程序），经过中间环节，最终得到输出结果（一份包含业务规则的文档）。

这听起来似乎要求太高了……难道不是必须完成整个研究过程才能达到这个目标吗？

绝对不是这样。关键在于找到最简单的途径来实现端到端的流程——可以采取一些捷径，也可以做出一些在正式生产环境中并不适用但暂时可行的假设。你需要抑制内心那个总是想要“把事情做到完美”的工程师本能。你的目标应该是让整个流程能够正常运转起来，因为这种快速推进的方法远比一步一个脚印地完善某个细节更有价值。

这意味着有些步骤可以手动完成，或者使用非常简单的实现方式来处理——当然这些方法在正式生产环境中是行不通的。请记住，现在这只是中间阶段的一个里程碑，并不是最终产品。

以我们的COBOL示例来说：

• 从现有的一个已知的COBOL程序开始。

• 跳过解析步骤——直接手动编写出下一阶段需要使用的条件列表即可。

• 过滤函数会在数据符合业务规则时返回true，否则返回false。

  • 最初的实现方式是：在已知的输入条件与是否应该返回true或false之间建立简单的对应关系。

  • 另一种选择是始终返回true——虽然这样会得到一些无关的规则，但这个问题可以稍后再解决。

  在最初阶段，文档生成也可能需要手动完成。



最终结果：一份看起来还很粗糙的文档，它是通过手动操作和针对单一程序编写的代码共同生成的。这份文档目前还远未达到可以正式使用的标准，但它对于确保研究成果能够真正影响到产品的开发过程来说，却是一个极其重要的里程碑。

你可能会认为这样做有些过分了——既然最终还是需要自动化这些步骤，为什么现在要浪费时间在手动操作上呢？但根据我的经验，很多研究人员和工程师都是这么想的。

以我自己的经历来说，我深刻地认识到：先建立起一个能够正常运行的端到端流程，确实会带来许多好处。具体来说：

• 可以验证整个流程是否真的有效。

• 能够及早发现那些可能造成瓶颈或阻碍进展的问题。

• 最终会得到一些具体的成果，从而获得他人的反馈。

• 还能避免在某个不必要的环节上耗费数月的时间。

原则3：尽快完成交付

在完成了原则2的相关工作后，你应该已经为某个具体案例建立了一个可运行的端到端流程。不过目前你肯定还不能立即将其交付给客户——因为这个流程仅适用于某一个特定的程序，而绝对不能用于客户的实际项目。

下一个目标：让这个系统具备可交付的条件。

那么，“可交付”到底意味着什么？是不是指这个系统能够在任何程序上正常运行呢？那样的话难度会太大，耗时也会太长。你需要一些捷径。

这时创造力就显得非常重要了。以我们的COBOL为例：

信息收集：

• 如果要在客户的程序上运行这个系统，那就尽可能多地收集相关信息。

• 可以假设该系统的代码行数少于1,000行。

• 也许你知道客户使用的是哪种COBOL方言，因此无需支持其他方言（有趣的事实是：COBOL实际上有超过300种方言）。不过这对你来说可能很方便，但对那些需要维护这些多种方言的系统的人来说却非常麻烦）。

算法上的捷径：

• 使用正则表达式来匹配条件，而无需使用复杂的解析器。

• 当然，这样做会遗漏一些条件，但这个问题可以以后再解决。

用户体验方面的捷径：

• 跳过文档生成步骤，直接将规则打印到控制台即可。

• 通过命令行来运行程序，无需使用图形用户界面。

• 使用手动配置文件而非用户界面来进行设置。

你的目标非常明确：尽快完成交付。

这个系统不需要做到完美无缺，只要它能够让你从这次迭代中学习到东西就可以了。如果你不尝试进行交付，那就只能依靠直觉来学习，而这是非常不可取的。

与原则2不同，在这里你不能部分地手动生成输出结果——你需要的是一个能够在真实数据上运行的可用的软件系统。

“可交付”到底意味着什么：

• 能够在客户的实际数据上正常运行（即使存在一些缺陷）。

• 能够产生可供你获取实时反馈的输出结果。

• 每次运行时都不需要你进行手动干预。

“可交付”并不意味着什么：

• 绝对精确无误。

• 能够处理所有边缘情况。

• 代码质量达到生产标准。

• 拥有美观的用户界面。

不过，你也不能随便“交付”什么东西。以我们的例子来说，如果你只开发出了一个能够在你自己创建的测试程序上运行的解决方案，那么为客户生成一份无关紧要的文档只会浪费时间，而且对你没有任何帮助。

如果不进行实际交付，你就无法从迭代过程中学习到任何东西；而如果没有一个可运行的端到端流程，你也根本无法完成交付。虽然这一点听起来很显而易见，但实际上很多团队在实践中都会忽略这一点——他们总是沉迷于先“正确地”解决某一个步骤，却不去验证整个流程是否顺畅。

原则4：逐步替换各个环节，同时仔细确定优先级

现在，你已经拥有一个可以正常运行的端到端流程。你可以开始用更好的实现方式来替换其中的各个步骤：

• 用自动化步骤替代手工操作。

• 去掉那些简化的处理方式，采用更可靠的实现方法。

• 提高准确性和覆盖范围。

在产品发布后，你会发现有很多地方需要立即进行修改。但请记住：我们的目标是将研究结果真正应用到产品中，因此必须慎重安排修改的优先级。

优先级评估框架

根据以下三个标准来确定修改的优先级：

1. 必要性 你是否发现当前实现方式中存在某些问题，而这些问题必须得到解决才能使产品正常运行？

示例：“正则表达式无法处理嵌套条件，而客户60%的业务规则都包含嵌套条件。因此我们必须使用专门的解析器。”

2>学习价值 对当前实现方式进行修改，是否有助于你在下一次迭代中更好地了解产品的影响范围？

示例：“如果我们将过滤准确率从40%提高到80%，我们就能知道当文档内容大部分正确时，这种格式是否真的有用。”

3>所需时间 这项修改需要花费多少时间来完成？

示例：“开发一个完整的解析器需要3周时间；而改进正则表达式以处理嵌套条件只需要2天。后者只需付出10%的努力，却能带来80%的收益。”

继续以COBOL为例，在第一次迭代之后，你可以根据这些标准来安排后续的修改工作：

第一次迭代后的修改计划：

- 修改解析器以处理嵌套条件 [必要性：极高，所需时间：2天] → 立即执行
- 添加用于生成文档的用户界面 [可选功能，所需时间：1周] → 延后处理
- 提高过滤准确率 [学习价值：极高，所需时间：3天] → 在下次迭代中完成
- 支持更多的COBOL方言 [目前没有必要进行验证，但开发周期较长...] → 延后处理
- 优化文档格式 [客户提出要求，所需时间：1周] → 首先需要确认内容是否正确

要快速迭代：进行某些修改后立即发布产品，然后收集反馈。不要试图解决所有发现的问题，甚至包括客户提到的问题。要问自己：“在下次迭代中，最需要改进的是什么，这样才能让我们学到新的东西？”

原则5：定期获取关于结果的反馈

关键在于要在每次迭代中尽可能多地收集反馈。

在每次迭代时：

1. 获取最终成果的反馈

   • 向用户展示实际的输出结果。

   • 如果可能的话，不要只问“这个功能能不能用？”——还要观察用户实际使用它的过程。

   • 明确哪些方法有效，哪些无效，以及还缺少什么功能。

2. 思考接下来需要解答的问题

   • 你从这次迭代中了解了产品的哪些方面？

   • 哪些假设得到了验证或被推翻？

   • 又出现了哪些新的问题？

3. 据此规划下一次迭代

   • 使用上述优先级评估框架。

   • 重点放在学习上，而不仅仅是开发功能。

4. 进行必要的最小范围修改来解决问题

   • 不要试图修复所有问题。

   • 只进行那些能解决下一个最重要问题的最小规模修改。

   • 保持迭代周期的快速性（几天到几周，而不是几个月）。

示例迭代周期：

第1次迭代：
- 发布内容：基于正则表达式的条件检测工具、始终为真的过滤规则以及控制台输出功能。
- 收获的教训：文档结构是可行的，但存在过多的误报情况。
- 提出的问题：过滤精度是否是影响该工具实用性的关键因素？
- 下一步计划：将过滤精度提高到80%，然后再次发布该工具。

第2次迭代：
- 发布内容：使用相同的正则表达式检测工具，但改进了过滤机制（准确度达到80%），同时保留控制台输出功能。
- 收获的教训：由于过滤效果得到了提升，用户认为该工具非常有用！
- 提出的问题：是否需要引入解析器，还是正则表达式已经足够满足需求？
- 下一步计划：在更大的程序上测试该工具，看看正则表达式在哪些情况下会失效。

第3次迭代：
- 发布内容：使用相同的处理流程，在10个实际项目中对该工具进行了测试。
- 收获的教训：在4个项目中，正则表达式检测机制出现了问题（尤其是遇到嵌套条件时）。
- 提出的问题：现在投资开发解析器是否值得？
- 下一步计划：为嵌套条件专门开发解析器，然后再次发布该工具。

需要注意的是，每个迭代周期都进展迅速，且专注于解决一个具体问题，并基于实际测试结果进行优化。

在现实生活中，每次迭代时你可能会想要同时探讨多个问题。但如果其中两个问题已经得到明确解答，那么在再次发布产品之前先解决这些问题，这样你才能获得有价值的反馈，而不会一直听到同样的抱怨。

另外，在与真实客户合作时，他们可能不太愿意接受多次尝试新方法的做法——因此你也需要考虑到这一点。无论如何，关键原则始终不变：保持迭代周期的短暂性，并将每次迭代都用于学习新知识。

与其他工具的集成

当与其他研究管理工具结合使用时，端到端的迭代流程会发挥出最佳效果：

研究树（第4章）：

• 你所制定的流程会在研究树中对应为一个分支。

• 每次迭代都会在这些分支上测试不同的方法。

• 失败的迭代会将该分支标记为红色，成功的迭代则将其标记为绿色。

时间盒法（第5章）：

• 为每次迭代设定固定的时间限制。

• 如果无法在规定的时间内完成迭代，那就说明你开发的内容太多了。

逆向设计法（第7章）：

• 逆向设计法能帮助你明确两个目标：

  • 最终想要实现的目标结果。

  • 为达到这一目标所需的一系列中间步骤。

• 端到端的迭代过程会验证这些中间步骤在真实数据中是否有效。

• 逆向设计过程中确定的最终目标，会在整个迭代过程中作为指导原则。

• 每次迭代都会对逆向设计过程中确定的步骤进行验证或优化。

• 将这两种方法结合起来使用：逆向设计法能帮助你确定需要开发哪些内容，而端到端的迭代过程则能证明这些内容的可行性，并让你能够逐步对其进行测试。

总结：端到端迭代流程

端到端迭代通过持续验证可行性并利用真实数据来确保研究成果能够真正影响产品的发展。

五大原则：

1. 明确整体流程：首先需要理清从输入到输出的整个链条。

2. ：利用捷径和手动操作步骤来确保整个流程能够顺利运行。

3. ：真实数据能带来理论无法提供的启示。

4. ：运用以下三个标准进行判断：

   • 必要性（该研究是否真正有必要？）

   • 学习价值（通过这项研究你能学到什么？）

   • 实施难度（完成这项研究需要多少时间？）

5. ：通过快速循环（几天到几周的时间跨度）来不断优化流程。

第三部分总结

在第二章中，你了解到作为研究负责人，你的职责是：

1. 确保研究工作能够对产品产生实际影响。

2. 保证研究工作的高效开展。



第二部分主要讲述了如何保证研究工作的高效进行。

第三部分则重点介绍了如何确保研究成果能够对产品产生实际影响——这也是你最重要的职责。这一部分提供了一种完整的方法论，通过三个相互补充的阶段来确保研究工作能够为产品发展做出贡献：

产品导向研究的三个阶段

第一阶段：选择有意义的研究课题（第六章）

在开始任何研究之前，首先需要回答三个关键问题：

1. 产品影响：这项研究能否带来巨大的价值？

2. 见效时间

   ：我们需要多久才能看到研究成果？

3. 资源投入

   ：我们是否具备所需的知识、能力和资源？



你已经学会了区分两种类型的研究：问题驱动型研究（从已确认的客户痛点出发进行研究，这是最理想的选择）和机会驱动型研究（基于新技术的发展方向来开展研究）。

进行有针对性的前期研究，以解答这些疑问。只有当确信某项研究会对产品产生实质性影响时，才应继续推进这项研究。

第二阶段：从产品价值出发，逆向思考（第7章）

一旦确定了研究方向，这种逆向思考的方法就能确保你从正确的起点开始。不要急于解决技术难题，而应该先从最终结果出发：

1. 手动创建预期的最终成果：成功的研发应该产生什么样的结果？在解决任何技术问题之前，先亲手创造这个预期成果。

2. 让相关方或用户进行验证：向他们展示这个成果，确认它确实能解决他们的问题。

3. 逆向分析各个依赖环节：根据已经验证的最终成果，依次确定实现这一成果所需的各种要素，从而找到研究的起点。

4. 按相反顺序解决问题：先解决最后的步骤（可以先搭建出初步的框架），确认每个步骤都能为达成目标做出贡献，然后再投入精力去处理早期的技术问题。



“螺旋游戏”的例子说明了为什么这种逆向思考的方法有效：从目标出发进行逆向分析，能够揭示那些按常规思路难以发现的系统性解决方案。

逆向思考强制要求我们将研究方向与产品的实际功能联系起来，因为这种方法是从最终成果开始展开的。它与研发流程框架相辅相成：第4章＞：逆向思考有助于确定哪些问题才是真正重要的，而研发流程框架则能帮助我们探索解决这些问题的方法。

第三阶段：迭代验证并持续改进（第8章）



单纯的逆向思考方法存在两个局限性：

• 你手动创建的“理想成果”在技术上可能根本无法实现。

• 你还没有在实际用户数据的基础上进行验证。

端到端迭代方法能够弥补这两个缺陷。这两种方法并不是相互竞争的，而是相辅相成的：

三个阶段是如何协同发挥作用的

这些章节共同构成了以产品为导向的研发流程体系：

确定研究方向 → 从最终结果出发 → 通过迭代进行验证

• 第6章会帮助你选择那些可能产生巨大影响的研究方向（这属于战略决策层面）。

• 第7章会确保你从产品的实际价值出发，通过逆向规划来制定研发方案。

• 第8章会强调你需要不断与真实用户进行互动，以验证你的研发方向是否正确。

每个阶段都能避免那些虽然常见但却令人遗憾的结果：

• 第6章能防止人们去开展那些对产品毫无实际影响的研究（即使这些研究最终取得了成功）。

• 第7章能避免人们开发出技术上虽然正确，但却无法为产品创造价值的解决方案。

• 第8章能防止人们构建出不可行的解决方案，或者那些在真实数据测试中会失败的方案。

现在，你已经得到了关于“如何确保研究工作能够对产品产生实际影响”这个问题的完整答案：

1. 明智地选择：只去开展那些能对产品产生重大影响的研发项目。

2. 从产品价值出发：在开始技术实施之前，先手动创建并验证你期望得到的结果。

3. 逆向思考：从最终目标出发，逐步分析实现这些目标所需的所有步骤和依赖关系。

4. 快速构建端到端的解决方案

   ：利用捷径和手动操作，尽快让整个研发流程能够正常运转。

5. 在实际用户中测试：不要只用示例数据来验证方案的有效性，而要使用真实用户的数据进行测试。

6. 根据反馈不断迭代改进：逐步优化整个研发流程，优先选择那些能让你学到最多东西的改进方向。

这种方法论在研究的每一个阶段——从选择研究方向、制定计划到执行方案——都始终将产品价值作为核心考虑因素。它能够有效避免最昂贵也是最令人遗憾的失败类型：那些“成功”了但却对产品毫无帮助的研究工作。

书籍总结

你选择阅读这本书，是因为你知道管理研究工作与管理开发工作是不同的——你需要一些具体的工具来应对这种差异。

你从这本书中学到了什么

在第1章中，你了解到：研究的本质并不在于其难度或技术复杂性，而在于解决方法的不确定性——也就是说，研究就是面对那些你不知道是否存在解决方案的问题，那些可能有多种解决方法但你无法确定哪种方法更有效的问题，以及那些通往成功的路径并不清晰的问题。

你还了解了Alan Schoenfeld提出的问题解决框架，该框架将研究过程分解为四个组成部分：

• 知识基础——你所掌握的信息和知识。

• 启发式方法——用于解决问题的各种策略。

• 控制机制——用来监控并调整你的研究方法。

• 思维模式——你面对问题时所持有的态度和观念。



好消息是：只要采用正确的管理方法和手段，这四个方面都是可以得到改善的。
在第二章中，你更深入地了解了研究与开发之间的区别。你也明白了，作为研究负责人，你的职责其实包含两个方面：

1. 确保研究工作能够真正对产品产生实际影响：那些无法对产品发展产生任何作用的“成功”研究，实际上就是失败的项目。在以产品为导向的公司中，这一点尤为重要。

2. 确保研究工作得以高效开展：即便是最出色的研究人员，也能从规范的研究方法中受益。



这个由两部分构成的框架，为后续的内容提供了清晰的逻辑结构。

如何高效开展研究工作

第二部分为你提供了具体可行的方法，帮助你有效地开展研究工作——这些方法适用于任何类型的研究环境，无论该研究是采用以产品为导向的模式还是其他方式。
在第三章中，我分享了一个真实的案例：那些具备高超技术能力的学生，正是因为缺乏规范的研究方法，才错过了显而易见的解决方案（比如查看帮助菜单）。这个例子清楚地说明，问题并不在于个人的能力不足，而往往在于研究方法的不当。这也进一步说明了为什么你需要以下这些方法。

第四章介绍了研究树这种方法——这是一种可视化的工具，能帮助你系统地探索各种解决方案。通过学习这一方法，你将了解到：

• 如何明确需要解答的问题，以及采取哪些方法来解决问题。

• 在选择先尝试哪种方法时，可以使用什么样的决策框架：最快获得反馈、成本最低、覆盖范围最广……

• 如何利用“研究树”来避免常见的错误做法：比如贸然采纳第一个出现的想法、陷入思维定势、学习效率低下、回答那些其实并不重要的问题，或者失去对整体研究方向的把握。

“研究树”能帮助你落实Schoenfeld提出的“控制”原则——让你能够系统地监控并调整自己的研究方向，而不是盲目地尝试各种方法。对于研究人员来说，这一工具非常有用；而对于作为研究负责人的你而言，它更能帮助你有效地指导团队开展工作。
在第五章中，你学会了如何在保证创新性的同时，对研究工作进行有效的管理。由于研究工作的难度本身就很大，因此设定时间限制是一种非常有用的方法——它能为具体的研究方向提供明确的框架。在规定的时间内完成研究后，你需要停下来重新思考：自己学到了什么？这个研究方向是否仍然是最值得继续探索的？这种方法既承认了研究的不确定性，又能够防止无休止的探索，或者让研究陷入那些对实现产品目标并无帮助的歧途之中。

如何确保产品能够产生实际效果

第三部分重点讨论了您最重要的职责：确保研究工作真正创造出产品价值。

第六章向您介绍了如何确定研究的方向——更重要的是，哪些方向不应该被选择。您学习了以下两种研究方式的区别：

• 问题驱动型研究——从客户的实际需求出发（这种方式更受青睐，风险也较低）。

• 机会驱动型研究——基于新兴技术展开研究（风险较高，需要先验证其可行性）。

在开展任何研究工作之前，您都需要回答三个问题：

1. 产品价值：这项研究能否带来巨大的商业价值？

2. 见效时间：需要多久才能看到实际成果？

3. 资源投入: 您和您的团队是否具备完成这项研究所需的知识、能力和资源？

您已经了解了如何通过预先进行相关评估来回答这些问题。

第七章介绍了一种非常有效的方法，可以帮助确保研究工作与产品目标保持一致：从最终结果出发，逆向推导整个过程。通过螺旋游戏这个例子，您明白了为什么逆向思考能帮助我们找到那些正向推理时容易忽略的解决方案。

在COBOL业务规则案例研究中，您看到了这种方法的实际应用：

1. 首先手动生成预期的最终结果（在解决任何技术问题之前）。

2. 与相关方一起验证这个结果是否正确。

3. 然后逆向分析各个环节，按相反的顺序逐一解决问题。

4. 在进行大规模投资之前，确保每个步骤都能为最终目标做出贡献。

采用逆向思考的方法，就能确保研究工作始终与产品目标保持一致，因为您必须从产品的最终目标出发来制定整个计划。

第八章告诉您如何通过持续的端到端迭代过程来克服逆向思考方法所存在的两个局限性。有时，您手动生成的“理想结果”可能根本无法实现，也没有在实际数据中得到验证；而端到端迭代正好可以解决这两个问题。

您学习了五个开展有效端到端迭代的关键原则：

1. 明确整个端到端流程：逆向思考本身就能帮助您理清这个流程。

2. 通过简化步骤来实现端到端流程：利用快捷方式或手动操作，让整个流程能够顺利运行。

3. 尽快推出测试版本：实际应用经验才是检验理论有效性的最佳标准。

4. 逐步替换原有的步骤

   :根据实际需求、学习潜力以及所需投入的成本，来确定哪些步骤应该优先被替换。

5. 及时获取反馈：通过快速的迭代周期，不断收集反馈意见。

逆向思考能够帮助我们明确需要构建什么以及应按照何种顺序进行构建，而端到端的迭代过程则能验证这些方案的可行性，并让我们逐步完成各项任务。

你的研究管理工具包

现在你已经拥有了一套完整的工具包：

来自第二部分的内容（适用于任何类型的研究）：

• 研究框架图——有助于梳理解决方案的脉络，帮助系统地选择研究方法。

• 时间盒管理法——使探索过程更具条理性。

来自第三部分的内容（专门针对产品影响方面的研究）：

• 框架选择机制——帮助确定哪些研究方向值得投入精力。

• 逆向思考方法——从一开始就确保各项研究内容能与产品目标紧密相连。

• 端到端的迭代流程——有助于验证方案的可行性，并从实际用户的使用体验中获取反馈。

这些方法相互配合，共同发挥作用：逆向思考能帮助我们明确研究目标及相应的实施步骤；研究框架图能为每一步提供具体的操作方向；时间盒管理法能防止我们在某些环节陷入僵局，从而让我们根据已获得的经验及时调整研究方向；而端到端的迭代流程则能确保各项工作的逐步推进与最终成果的有效性。

给你的建议

研究本质上是一项充满不确定性的工作。如果采用传统的开发管理方法，就会遇到问题，因为这些方法假设存在已知的解决方案、可预测的时间表以及稳定的进展速度。

但实际上，研究并不一定非得充满神秘感或具有随机性。只要运用正确的框架和方法，我们就可以系统地开展研究工作，同时始终把重点放在创造产品价值这一核心目标上。你已经学会了如何确保研究的有效性（第二部分），也了解了如何将研究成果与产品实际效果联系起来（第三部分）。现在你拥有了具体的工具、实际的案例以及完善的框架来应对这两项任务。

现在，就让我们把团队中那些充满不确定性的研究工作，转化为能够带来可衡量产品效果的系统性进展吧。我相信你一定能够带领研究团队取得成功，我也非常期待听到你运用这些方法所取得的经验。

如果你喜欢这本书，请帮忙将它分享给更多人。

致谢

能有这么优秀的人们在我从事这项工作的过程中给予支持，我感到无比幸运。

Abbey Rennemeyer是一位非常出色的编辑。在过去几年里，她免费为freeCodeCamp平台编辑了我的文章，同时也为我之前的著作《Gitting Things Done》提供了帮助，因此我知道她也非常适合负责这本书的编辑工作。她在内容选择和写作风格方面提出的建议，极大地提升了这本书的质量。

Quincy Larson创立了freeCodeCamp这个出色的社区。我感谢他创建了这个令人惊叹的平台，也感谢他一直以来的支持以及我们的友谊。

Estefania Cassingena Navone为这本书设计了封面。她专业的设计能力，以及对我那些苛刻的要求所表现出的耐心，让我对她心存感激。

那些抽出时间阅读这本书的未完成版本，为它的完善贡献了自己力量的测试读者们，正是你们帮助我让这本书达到了现在的形态。特别需要感谢Jason S. Shapiro和Omer Gull所提供的宝贵意见。

在特拉维夫大学求学期间，David Ginat博士让我第一次了解了Alan Schoenfeld关于问题解决的研究成果。他的教学启发了我将这些理念应用到实际工作中，包括研究管理领域。

这些年来，我有幸与许多杰出的研究人员和工程领域的领导者合作过，他们的数量太多，这里无法一一列举。

对于那些阅读过我之前出版的书籍《Gitting Things Done》并慷慨地给予我反馈和支持的读者们，你们真是太棒了！收到你们的来信和评论，让我觉得继续写作确实有着重要的意义。

**如果您愿意支持这本书……**
如果您想支持这本书，欢迎购买电子书版本、平装书或精装书，或者直接通过链接“buy me a coffee”为我买杯咖啡。谢谢您的支持！

**联系我**
如果您对这本书的某些内容感到满意，或者认为书中还有哪些地方可以改进，请随时通过以下邮箱与我联系：`gitting.things@gmail.com`。

感谢您愿意学习，并允许我成为您学习旅程中的一份子。

——Omer Rosenbaum

**关于作者**
Omer Rosenbaum是一位经验丰富的技术专家和作家。他拥有自己的YouTube频道，同时也撰写了《Gitting Things Done》以及用希伯来语编写的《计算机网络》等书籍。此外，他还是网络安全培训领域的专家，并创立了Checkpoint Security Academy这一机构。