利用持续发现构建更优平台

当缺乏发现过程时，平台工作会偏离其真正目的——即赋能工程师更快、更自信地部署可运行软件。

每个平台团队都有这样的惨痛经历：花费数月构建的工具最终被低效使用、误解或弃用。这不是因为工程实现差，而是因为工具不符合产品开发者的工作方式，或者解决了根本不存在的伪需求。

这种情况屡见不鲜。问题不在于恶意或技术严谨性不足，而在于跳过了发现环节。发现意味着在构建解决方案前，先理解工程师的实际工作方式——他们的工作流程、痛点以及真正拖慢进度的实际问题。没有这个过程，平台团队最终解决的是看似重要但与日常开发现实脱节的问题。

这正是Stack Overflow平台工程团队引入产品管理领域的"持续发现"实践的原因。

什么是持续发现？

这个术语来自产品领袖Teresa Torres，她将其定义为每周与客户接触的习惯，用于验证想法、测试假设并降低产品决策风险。这是一种结构化的方法，让你始终贴近构建对象，而不是凭空猜测。其核心是让发现过程本身更加敏捷和响应迅速，而不是依赖沉重且不频繁的研究阶段。

在产品团队中，这已是第二天性。但在平台工作中？却较为罕见。平台团队通常默认基于先前经验和启发法进行解决方案思考，而不是从用户问题出发。我们通过构建可靠基础设施、自动化流程和交付DevOps工具来实现扩展，但并不总是验证这些工具是否解决了真实问题。这会导致解决方案无人使用、积累技术债务，最终因为缺乏真正采用而腐烂。

平台团队为何应该拥抱持续发现

平台团队服务内部开发者，这使我们既是构建者又是赋能者。但内部开发者仍然是客户，因此我们学会将平台视为产品。在创新不断、 disruption 常见的快速移动组织中，开发者需求同样快速演变。新架构、优先级变化和新兴工具都在改变"优秀"的定义。持续发现帮助我们跟上步伐，让我们能够：

避免构建错误的东西
发现嘈杂请求背后隐藏的真实问题
用有限的时间和资源做出更明智的决策
通过创建贴合需求的工具提高采用率

Stack Overflow如何应用持续发现

1. 将工程师视为客户

我们将内部团队视为客户，而不仅仅是利益相关者。在编写代码前，我们花时间理解他们的背景。在季度规划时，我们专注于成果并早期接触合作伙伴团队，从他们面临的问题开始，而不仅仅是他们要求的解决方案——正如Teresa Torres所说，关注机会而不是直接跳转到解决方案。从中，我们探索多种解决问题的方式，在承诺前权衡利弊。这帮助我们避免锁定第一个想法，并给我们空间去发现最有影响力的方案，而不仅仅是最多被请求的。

2. 轻量级发现循环

我们定期与合作伙伴团队检查假设，而不是孤立构建——Torres称之为假设映射和测试。在整个过程中与合作伙伴团队有大量协作；他们不仅仅在事后被告知。透明文化使得早期暴露不确定性、挑战假设并在问题成为现实前发现缺口变得更容易。这也建立了信任，因此当我们做出权衡时，团队理解原因，而不仅仅是内容。这种持续的可见性也使得在构建过程中收集反馈更容易，因此如果我们需要转向，我们可以有信心和背景地完成。

3. 衡量重要指标

采用率是关键指标，但摩擦也是——那些表明工具不太适合开发者工作流程的困惑时刻、额外步骤或变通方法。我们寻找以下迹象：

人们是否需要求助才能使用基本功能？
他们是否构建变通方法而不是直接使用我们的工具？
我们的解决方案需要多少上下文切换？
用户是提出新想法还是只是抱怨？

如果我们的平台以最佳方式隐形（释放时间并减少苦工），我们就知道做对了。好的平台感觉像基础设施——开发者无需思考就能使用，它在幕后处理复杂性，并使开发者现有工作流程更快，而不是要求他们学习新的。另一方面，未优化的平台通过持续摩擦让自己被感知：开发者必须记住特殊命令、绕过限制或花时间弄清楚如何使其适应需求。

高采用率低摩擦表明我们构建了真正改善开发者体验的东西，而高采用率高摩擦可能只意味着人们被迫使用不太适合他们的工具。

为了清晰了解我们的有效性，我们收集数据；数据让我们理解世界。我们跟踪寻求帮助的开发者的数量（针对我们以为已解决的问题）和代码变更的前置时间——这些在摩擦成为更大采用问题之前告诉我们。我们监控使用模式，看看工具是成为日常工作流程的一部分还是只是偶尔的必要品。我们还关注我们没有衡量的东西——持续的开发者访谈帮助我们理解纯使用指标可能遗漏的定性方面。当这些信号一致时——低摩擦指标、高有机使用率和积极开发者反馈——我们知道我们命中了目标。当不一致时，那就是我们深入挖掘和迭代的提示。

我们学到的经验

发现不是一劳永逸的。团队在演变，我们对他们需求的理解也应该如此。六个月前对团队有效的方法可能不再适合他们当前的优先级。定期检查帮助我们与团队开发实践和痛点的变化保持同步。

反馈≠需求。有时人们要求的并不是他们需要的。深入挖掘。我们不仅接受功能请求的表面价值，还要求开发者讲述他们上次遇到希望我们解决的问题的故事——Torres称之为基于故事的访谈。这揭示了请求背后的实际背景，通常显示真实需求与最初要求不同。

快速交付很好。正确交付更好。发现帮助我们两者兼得。

困难之处

平台团队通常以稳定性而非创造力来评判。平衡发现与正常运行时间和可靠性需要努力。摆脱"工单和交付"循环以探索上游问题也是如此。但那些成功管理的团队？他们构建的是人们想要使用而不仅仅是必须使用的平台。首先在冲刺规划中为发现预留时间，衡量采用率和摩擦指标，最重要的是定期与用户交谈，而不是等待他们带着问题来找你。

这样的文化转变需要时间，因为你不仅在改变过程；还在改变人们认为可接受或期望的东西。这种变化不仅仅因为领导层说应该发生，或者经理在规划会议中添加新议程而发生。当个人贡献者感到有灵感和安全足以以不同方式工作，并且经理以支持和一致性支持时，它才会坚持。有时C级倡导者有助于设定基调，但日常是中层经理和高级个人贡献者进行缓慢、稳定的工作，使新行为正常化。你需要反复证明暂停并询问原因、探索、承认不确定性是可以的。没有这种心理安全，人们只会回到他们知道的：可交付成果和截止日期。文化不会因为有人说应该改变而改变；当足够多人开始相信不同的工作方式不仅被允许而且被重视时，它才会改变。

如何开始

当我们首次倾向于持续发现时，这不是一个正式倡议——它始于对我们支持的内部团队进行一些重点访谈。我们已经知道我们的目标：帮助他们更快、更可靠地交付。但我们需要澄清如何实现。因此，我们不是假设内部团队需要什么，而是询问。我们想确保我们解决的是他们实际存在的问题，而不仅仅是我们认为他们有的问题。

我们保持简单——对话，而不是调查。我们询问摩擦、阻碍和变通方法。我们倾听那些使他们的工作比必要更困难的时刻。这些访谈帮助我们深入表面请求之外，理解塑造他们体验的实际约束。我们记录所学并用于塑造我们的路线图。不是作为愿望清单，而是作为团队实际挣扎的反映。

在完全投资任何解决方案之前，我们与一些团队测试想法。有时这意味着构建原型。其他时候，只是走过提议的变更并收集反馈。那个轻量级循环（倾听、测试、调整）给了我们前进的信心，并给了我们的合作伙伴团队信心，我们与他们一起构建，而不仅仅是为他们构建。

最终思考

归根结底，平台工程是关于成果，而不是输出。最好的平台是开发者几乎注意不到的平台，因为它们有效、贴合并与用户一起演变。持续发现通过解决非代码瓶颈为我们提供了一条到达那里的途径。这是一个我兴奋地与团队一起深化的实践，一次一次对话。