产品开发者的崛起 - 第二部分，批判性思考

在“产品开发者崛起”系列的第一部分中，我们探讨了产品开发者如何专注于领域和用户问题来构建产品。这次的主题是开发者带来的真正价值在于他们对构建内容的批判性思考。这从来都是开发工作的本质，但随着AI生成代码的能力不断提高，这一点现在比以往任何时候都更为明确。由于这种思维方式，产品开发者将产品待办事项称为“假说”。

质疑为什么要做

在一个产品待办事项梳理工作坊中，产品开发者和产品经理之间展开了对话：

产品经理：“我们需要加一个分页功能。”
产品开发者：“我们试图解决什么问题？”
产品经理：“页面加载太慢，我认为我们因此损失了一些用户。”

质疑为什么要这样做

产品开发者1：“我可以统计一下有多少人什么都没做就离开页面了。”
产品开发者2：“我们能不能通过仅显示最近的事件来简化页面内容？”

如果他们决定调查第一个想法，他们将需要在产品中内建可观察性。可观察性已越来越成为一个高优先级的特性，它包括了诸多方面，如instrumentation（允许监视和测量行为的产品特性）和testability（确保设计对有效测试友好）。高可观察性使产品开发者有能力准确评估产品的价值和功能。随着系列的继续，我们将会看到他们还依赖于可观察性来保存知识。

共享需求发现的职责 - 一起批判性地思考

需求的发现并非某一个特定角色的职责。产品开发者在这个过程中扮演了一个重要的角色。

产品经理：“你说的对。但一个用户说，如果我们实现分页，他们会付一百万美元。”
产品开发者：“为此增加复杂性值得吗？能不能问一下只显示最近的事件是不是也可以满足他们？”

质疑为什么是现在做

产品开发者：（对产品负责人说）“为什么我们现在就花这么多工夫调整UI？我们还没有很多用户。”
产品负责人：“确保这个用户满意是吸引更多用户的关键。”

质疑功能（The WHAT）

产品经理：“也许只显示最近的事件就可以了。”
产品开发者：“你能给我们一个例子吗？”
用户(一直都在工作坊中)：“我来举个例子吧。例如，如果有很多事件，只显示最近的5个事件。”
产品开发者：“像这样？”

场景：当过去的事件太多时，只显示最近的事件
  假设三天前有3个事件
  并且两天前有3个事件
  并且一天前有3个事件
  那么我应该在过去的事件列表中只看到过去2天内的5个最近的事件

用户：“是的，看起来不错。”

使用像Specification by Example这样的技术，产品开发者和用户之间的沟通差距变得更小。它还帮助他们批判性地定义工作的范围。

质疑解决方案（The HOW）

产品开发者1：“我们应该泛化这个功能，因为可能会出现更多的列表需求。”
产品开发者2：“YAGNI，我们现在保持简单。”
产品开发者3：“我们怎么知道我们做完了？”
产品开发者1：“我们先写测试。测试通过不就是做完了吗？”
产品开发者2：“我们之后也要测试，以发现意外的副作用和错误。” （也就是批判地看待自己的开发成果）

批判性地考虑维护性

当世界对AI通过图灵测试的能力感到惊奇时，产品开发者清楚它对于产品维护时保持回归测试通过所带来的挑战。

在传统的组织中，一个动议的价值通常是事前通过逻辑推理来证明的，并且通常也不需要去质疑，“做!”就完了。然而，产品开发者们知道，考虑到可行性、对现有产品的影响以及实际结果的变数，即使是逻辑上合理的想法，也需要被视为假说。

结论

产品开发者的角色不仅限于实现和维护，而且还承担了批判性评估和验证假设以及保存关键知识的责任。他们贡献的一个重要部分是通过他们的批判性思维技能不断完善他们的流程。然而，这种持续优化流程的特质并不仅仅是他们独有的，这也是为什么在示例中没有特别强调这一点。

通过在组织内促进明智的决策，产品开发者在确保他们开发的产品成功中发挥了关键作用。在实践中，验证和知识保存往往是密不可分的。在这个系列的下一部分，我们将深入探讨产品开发者的另一个关键责任：学习与保存。