为什么问题陈述还不够

# 为什么问题陈述远远不够 在之前的三篇文章中，我们探讨了尽管工作出色，职业生涯却可能停滞不前的原因：影响力有限（[链接](https://letters.unchartedpathbreakthroughs.com/posts/why-your-career-feels-stuck)）、执行陷阱（[链接](https://letters.unchartedpathbreakthroughs.com/posts/why-doing-more-keeps-you-stuck)），以及工作听起来比实际更渺小（当缺乏背景信息时）（[链接](https://letters.unchartedpathbreakthroughs.com/posts/why-your-work-sounds-small)）。 这些模式共同指向一个更深层次的问题： **那么，究竟什么才能真正帮助你的工作获得更广泛的信任、采纳和重视？** 其中一些能力显而易见：深厚的技术功底、强大的执行力以及可靠性。但另一些则容易被忽视。 其中最重要的一项能力是 **背景范围**（contextual range）：理解你工作所处的技术、组织和业务背景的能力。 从上一篇文章中我们了解到，背景会改变你工作的感知价值。本文将进一步深入探讨： **战略背景通常存在于何处？** 大多数情况下，它分散在人员、团队、系统、激励机制和优先级之中。你需要去发掘它。 ## **战略背景的三种类型** 大多数组织拥有三种战略背景： 1. 技术背景 2. 团队或组织背景 3. 业务背景 **技术背景** 是软件工程师通常最熟悉的那部分。它包括代码库、系统架构、工具、基础设施、技术约束以及技术愿景和战略。 **团队与组织背景** 是指工作如何在人员和团队之间流动。它包括团队目标和动态、跨职能依赖关系、协作模式、所有权边界、跨部门交付成果以及与公司优先级的对齐情况。 **业务背景** 关乎业务本身。它包括客户需求、产品方向、收入目标、市场竞争、盈利能力、董事会或股东期望，以及公司试图管理或利用的风险或机遇。 每种背景回答一个不同的问题： **技术背景告诉你，在你实际拥有的系统中，什么可以运作。** **团队与组织背景告诉你，什么能够成为现实。** **业务背景告诉你，什么值得去追求。** 下面是一种表示这些背景的方式： （此处有三个三角形示意图，展示了工程师、经理和领导者在技术背景、团队或组织背景以及业务背景上的常见关注点。工程师的关注点偏向技术，经理偏向团队和组织，领导者偏向业务。） 工程师、经理和领导者通常关注同一战略背景的不同部分。 不用说，这些是默认的起点，而非僵化的界限。优秀的工程师、经理和领导者都能跨越所有三种背景运作。 但不同的职能角色往往通过不同的默认关注点进入同一个问题。 工程师可能从系统设计、代码正确性、可靠性和可维护性入手。经理可能从团队容量、所有权、协调和采纳开始。领导者则可能从业务风险、投资、机会成本和长期杠杆效应出发。 这也是为什么在软件工程中，“视情况而定”是如此常见的回答。在其最佳状态下，“视情况而定”表明答案取决于背景，而非普遍真理。 更成熟的思路是问：**我们缺少哪些背景信息？** 随着你负责的范围扩大，这个问题变得愈发重要。 ## **问题陈述是工作的起点** 在我作为Staff工程师加入一个新组织（平台团队）几个月后，我收到了一个经典的一行问题陈述： **为公司构建一个Pub/Sub系统。** 表面上看，这听起来像是一个技术基础设施项目：选择正确的消息传递模式、评估合适的技术、设计系统、构建它、让团队使用它。 但这行问题陈述仅仅是个开始。 当时，该组织大约有200名工程师，主要是一个Ruby技术栈，同时有一些新项目开始采用Golang，数据部门则有限度地使用Python。 不同的团队已经找到了各自特定的方式来解决他们异步服务间通信的需求。 有些团队已经将Sidekiq改造为*事实上的*Pub/Sub系统。另一些团队则以更接近内部事件分发的方式使用了Twilio Segment（一个客户数据平台系统）。 这些选择在局部范围内是有意义的。团队有问题要解决，他们使用了手头可用的工具。 但在整个公司范围内，缺乏一条黄金路径导致了碎片化、重复劳动和架构债务。反模式正在蔓延。新功能上线耗时更长，生产环境调试也变得更加困难。领导层担心，将专门用途的工具拉伸到超出其设计范围，会限制我们干净地支持未来用例的能力。 因此，更深层次的问题变成了： **这家公司能够采用、运营、信任并在此基础上发展的共享通信层是什么样的？** 这个问题需要所有三种背景信息。 ## **技术背景：这里什么能运作？** 技术问题很容易演变成一场技术辩论。 一些工程师想要Kafka，因为它低延迟、高吞吐量。这种偏好是可以理解的。Kafka在事件流处理方面功能强大且被广泛使用。 但在当时，Kafka的Ruby绑定很弱。公司内部也缺乏运营Kafka的专门经验，而且领导层对于自行承担运行Kafka集群的责任犹豫不决。 我们还评估了Amazon Kinesis。它也有自己的约束，包括更弱的Ruby绑定，以及围绕管理和扩展分片的持续运营复杂性。 技术背景使决策标准更加清晰： - 在Ruby占主导的环境中，什么能很好地工作？ - 团队能安全地集成什么？ - 公司能自信地运营什么？ - 在不造成不必要运营拖累的前提下，什么能支持广泛的异步通信用例？ 这种清晰性很重要，因为一个技术上令人印象深刻但公司无法有效运营、支持或集成的解决方案，终将成为一个未来的负担。 技术背景帮助你理解，在你实际拥有的系统中，什么可以运作。 ## **团队与组织背景：什么能成为现实？** 组织问题同样重要。 一些团队已经在考虑构建自己的Pub/Sub系统。少数团队愿意为整个公司托管某些系统。在某些情况下，他们的管理层表示支持。在其他情况下，对齐程度则不那么明确。 这带来了第二层问题： - 谁最需要这个系统？ - 哪些团队愿意早期采用？ - MVP必须支持哪些用例？ - 如何让团队在生产环境中信任这个系统？ - 他们需要什么样的迁移支持？ 公司需要一个共享的黄金路径，但只有当团队真正走上这条路时，黄金路径才有意义。 当一个平台的系统能够被团队采用、在生产中信任，并且团队不再自行解决相同问题时，它才真正变得切实可行。 团队与组织背景帮助你理解，为了让系统成为现实，需要改变什么。 ## **业务背景：什么值得追求？** 业务背景赋予了这项工作更广泛的意义。 成本不仅仅是碎片化的基础设施。更是碎片化的工程产能。 当每个团队都以自己的方式解决异步通信问题时，工程时间被投入到重建相同的基础上，而不是在此之上构建产品能力。每一种定制化的路径也使得公司更难以运营、调试和扩展。 一个共享Pub/Sub系统的价值在于，它将一个重复的工程问题转化为公共基础设施，这样团队就可以将更多时间花在差异化的产品工作上。 考虑到技术约束、组织采纳需求和业务优先级，我们最终选择了SNS加SQS。 一些工程师感到失望，因为这并不是一个炫酷的解决方案。但它符合公司的技术现实，得到了技术和业务领导层的支持，并为团队提供了一个他们实际上可以采用并为之构建的共享基础。我们还与AWS技术专家一起审查了设计方案和预计的事件量，他们确认该方法是可行的。 这个解决方案的简单性得到了回报。与Kafka或Kinesis不同，它几乎不需要我们的团队进行持续的运营维护。我们看到的唯一重大运营问题来自AWS的故障，而不是我们自己需要管理集群、分片或专门基础设施。 到我3.5年后离开这家公司时，工程组织已经发展到400多名工程师，我们的团队构建的这个系统已成为整个公司异步服务间通信的骨干，支持Ruby、Golang和Python。它每天处理7.4亿条消息。 该系统的一些关键部分还产生了一项专利，我是主要发明人。 这项专利对我很重要，因为它证明了技术深度是真实的。扩展到组织和业务背景，使得这项技术工作比在真空中更有价值。 这三种背景共同决定了你的工作是停留在一个团队的局部范围内，还是成为一项公司级的投资，创造更广泛的技术杠杆效应。 ## **Staff\+ 的运作范围** 回顾起来，这个Pub/Sub项目始于一个明确的公司需求：服务之间需要一种可靠的异步通信方式。 但问题陈述只是阐明了需求。它并没有定义成功解决该问题所需的全部判断力。 实际的工作同时处于三种背景的交汇处。*这*正是许多工程师在思考Staff\+级别工作时所忽略的部分。 而这正是Staff\+的运作范围。 （一个三角形示意图，标记为技术背景、团队或组织背景、业务背景，显示重叠的关注区域。中央的重叠区域标记为Staff+ Operating Range，代表做出能够兼顾组织现实和业务价值的技术决策的能力。） Staff\+工程师通过将技术判断力应用于技术、组织和业务背景，来扩展他们的运作范围，而不必在每个维度上都做到极致。 要在Staff\+级别成功运作，你的目标是扩展你的运作范围，以便你的技术判断能够考虑到组织现实和业务价值，而不必在每个维度上都做到极致。 当你的工作仅仅局限于技术背景时，它可能很强大，但也可能过于狭隘。 但当它连接了技术、组织和业务背景时，其他人就更容易理解它为什么重要，更容易支持它，并在此基础上进行构建。 这就是强大的技术工作开始转化为组织真正价值的方式。 并非每个Staff级别的项目都必须是公司范围的。较小的项目仍然可以创造巨大的价值，而且这些项目通常是工程师开始发展背景范围的地方，他们可以在未来更大范围的工作中以此为基础。