通过持续发现构建更优平台
当缺乏发现过程时，平台工作就会偏离其真正目的：赋能工程师更快、更自信地部署可运行软件。
图片来源：Alexandra Francis
每个平台团队都有一个关于他们花费数月构建的工具最终被使用不足、误解或废弃的战争故事。这不是因为工程实现不佳，而是因为它没有自然地融入产品开发人员的工作方式，或者它解决了一个没有人真正遇到的问题。
这种情况我见过不止一次。这不是因为意图不良或缺乏技术严谨性。而是因为跳过了发现过程。发现意味着在构建解决方案之前，了解工程师实际的工作方式——他们的工作流程、痛点以及真正拖慢他们进度的问题。没有这个过程，平台团队最终会解决那些从外部看似乎重要但与日常开发工作现实不符的问题。当缺乏发现时，平台工作开始偏离其真正目的，即赋能工程师更快、更自信地部署可运行软件。
这就是为什么我对Stack Overflow平台工程团队一直在做的事情感到兴奋：一种从产品管理借鉴来的实践，称为持续发现。
什么是持续发现？
这个术语来自产品领导者Teresa Torres，她将其定义为每周与客户接触以验证想法、测试假设并降低产品决策风险的习惯。这是一种结构化的方式，让你与你为之构建的人保持紧密联系，从而避免猜测。其理念是让发现过程本身更加敏捷和响应迅速，而不是依赖繁重、不频繁的研究阶段。
在产品团队中，这是第二天性。但在平台工作中？这并不常见。平台团队通常默认使用先前经验和启发式方法进行解决方案思考，而不是用户问题。我们通过构建可靠的基础设施、自动化流程和交付DevOps工具来扩展。但我们并不总是验证这些工具是否解决了真正的问题。这可能导致解决方案未被使用、积累技术债务，并最终腐烂，因为它们从未找到真正的采用。这就是为什么持续发现对我们来说成为一个有用的框架。
为什么平台团队应该拥抱持续发现
平台团队服务于内部开发人员，这使我们既是构建者又是赋能者。但内部开发人员仍然是客户，因此我们学会了将平台视为产品。在创新不断、中断常见的快速移动组织中，开发人员的需求同样快速演变。新架构、不断变化的优先级和新兴工具都改变了“好”的定义。持续发现帮助我们跟上步伐。它使我们能够：
- 避免构建错误的东西。
- 发现隐藏在嘈杂请求背后的真实问题。
- 用有限的时间和资源做出更明智的赌注。
- 通过创建适合的工具来提高采用率。
Stack Overflow如何应用持续发现
以下是Stack Overflow平台工程团队在实践中应用这一概念的方式：
1. 工程师即客户
我们将内部团队视为客户，而不仅仅是利益相关者。我们在编写代码之前花时间了解他们的背景。在季度规划时，我们专注于结果，并尽早与合作伙伴团队接触，从他们面临的问题开始，而不仅仅是他们要求的解决方案——Teresa Torres称之为专注于机会而不是直接跳转到解决方案。从那里，我们探索多种解决问题的方法，在承诺之前权衡取舍。这帮助我们避免锁定第一个想法，并给我们空间去发现什么最有影响力，而不仅仅是最被要求的。
2. 轻量级发现循环
我们定期与合作伙伴团队检查我们的假设，而不是孤立地构建——Torres称之为假设映射和测试。在整个过程中，与合作伙伴团队有很多协作；他们不仅仅是在事后被告知。透明文化使得早期暴露不确定性、挑战假设并在问题成为真正问题之前发现差距变得更容易。这也建立了信任，因此当我们做出权衡时，团队理解为什么，而不仅仅是什么。这种持续的可见性也使得在构建过程中收集反馈更容易，因此如果我们需要转向，我们可以有信心和背景地做到。
3. 衡量重要指标
采用率是关键指标，但摩擦也是——那些表示工具不太适合开发人员工作流程的困惑时刻、额外步骤或变通方法。我们寻找诸如：人们是否需要寻求帮助来使用基本功能？他们是否在构建变通方法而不是直接使用我们的工具？我们的解决方案需要多少上下文切换？用户是提出新想法还是只是抱怨？
如果我们的平台以最好的方式隐形（节省时间并减少苦工），我们知道我们做对了。一个好的平台感觉像基础设施——开发人员使用它而不必思考，它在幕后处理复杂性，并使开发人员现有的工作流程更快，而不是要求他们学习新的。另一方面，一个未优化的平台通过持续的摩擦让自己被知道：开发人员必须记住特殊命令、绕过限制或花时间弄清楚如何使其适应他们的需求。高采用率和低摩擦信号表明我们构建了一些真正改善开发人员体验的东西，而高采用率高摩擦可能只是意味着人们被迫使用一个不太适合他们的工具。
为了清晰了解我们的有效性，我们收集数据；数据让我们理解世界。我们跟踪寻求帮助的开发人员数量（针对我们假设已解决的问题）和代码更改的前置时间——这些在摩擦成为更大的采用问题之前告诉我们。我们监控使用模式，看看工具是否成为日常工作流程的一部分或只是偶尔的必要。我们还关注我们没有衡量的东西——持续的开发人员访谈帮助我们理解纯使用指标可能遗漏的定性方面。当这些信号一致时——低摩擦指标、高有机使用率和积极的开发人员反馈——我们知道我们达到了目标。当它们不一致时，那就是我们深入挖掘和迭代的提示。
我们学到的教训
发现不是一劳永逸的。团队在演变。我们对他们需求的理解也应该如此。六个月前对一个团队有效的东西可能不适合他们当前的优先级。定期检查帮助我们与团队开发实践和痛点的变化保持一致。
反馈 ≠ 需求。有时人们要求的并不是他们需要的。深入挖掘。我们不只是接受表面价值的特性请求，而是要求开发人员告诉我们一个关于他们最后一次遇到他们希望我们解决的问题的故事——Torres称之为基于故事的访谈。这揭示了请求背后的实际背景，通常显示真实需求与最初要求不同。
快速交付很好。正确交付更好。发现帮助我们两者都做到。
什么使这变得困难
平台团队通常以稳定性而非创造力来评判。平衡发现与正常运行时间和可靠性需要努力。摆脱“票证和交付”循环以探索上游问题也是如此。但那些管理它的团队？他们构建人们想要使用而不仅仅是必须使用的平台。首先，在冲刺计划中为发现预留时间，衡量采用率和摩擦指标，最重要的是，定期与用户交谈，而不是等待他们带着问题来找你。
像这样的文化转变需要时间，因为你不仅在改变过程；你还在改变人们认为可接受或期望的东西。这种变化不会仅仅因为领导层说它应该发生，或者经理在规划会议中添加了新议程而发生。当个人贡献者感到有灵感和安全到可以以不同方式工作，并且经理以支持和一致性支持时，它才会坚持。有时，C级倡导者有助于设定基调，但日常工作中，是中层经理和高级个人贡献者做着缓慢、稳定的工作，使新行为正常化。你需要反复证明暂停并问为什么、探索、承认不确定性是可以的。没有这种心理安全，人们只会回到他们知道的东西：可交付成果和截止日期。文化不会因为有人说它应该而转变；当足够多的人开始相信不同的工作方式不仅被允许，而且被重视时，它才会转变。
如何开始
当我们第一次开始倾向于持续发现时，它不是一个正式的倡议——它始于对我们支持的内部团队进行一些重点访谈。我们已经知道我们的目标：帮助他们更快、更可靠地交付。但我们需要澄清如何实现。因此，我们没有假设内部团队需要什么，而是询问。我们想确保我们解决的是他们实际存在的问题，而不仅仅是我们认为他们有的问题。
我们保持简单——对话，而不是调查。我们询问摩擦、障碍和变通方法。我们倾听那些使他们的工作比必要更困难的时刻。这些访谈帮助我们深入挖掘表面级别的请求，理解塑造他们体验的真实约束。我们记录了我们学到的东西，并用它来塑造我们的路线图。不是作为愿望清单，而是作为团队实际挣扎的反映。
在完全投资任何解决方案之前，我们与一些团队测试想法。有时这意味着构建原型。其他时候，只是走过一个提议的更改并收集反馈。那个轻量级循环（倾听、测试、调整）给了我们前进的信心，并给了我们的合作伙伴团队信心，我们是在与他们一起构建，而不仅仅是为他们构建。
最后思考
归根结底，平台工程是关于结果，而不是输出。最好的平台是开发人员几乎注意不到的平台，因为它们工作、适合并与用户一起演变。持续发现通过解决非代码瓶颈，为我们提供了一种到达那里的方式。这是一种我兴奋地与我的团队一起深化的实践，一次一次对话。
作者：Adora Nwodo
平台工程经理
员工
平台
平台工程