我正向一位产品经理朋友解释为什么即使是看似“小”的功能，在大公司中构建这些功能所需的时间更长，通常在小公司中构建起来要快得多。比如：

想象你想要把用户的地址加到你团队管理的所有用户界面组件上。听起来很简单，对吧？这会怎样进行呢？

1. 你向后台团队提出了这个功能请求，却发现要花超过3周的时间才能实现这个改动。为什么？ 😕
2. 提供地址数据的地址服务由一个位于澳大利亚的团队所有。这个由8名工程师组成的团队已经无暇回复每个单独的Slack消息 😰，每天要处理10多个紧急任务，还有100多个待办事项积压，以及来自公司其他工程师的诸多请求。他们无暇回复每个单独的Slack消息。
3. 为了管理需求，他们每周举办一次新客户入职会议。他们正在推出一个新的GraphQL API 🚀 来替换旧的基础设施，因此他们仔细评估每个新用例以规划逐步增加的流量。
4. 你的一个工程师参加了他们的办公时间，得知地址数据包含个人身份信息 PII 🔒 。在数据通过服务传输之前，需要进行安全审查。
5. API集成花费的时间稍长，因为需要你的服务来解密PII数据。你的工程师撰写了一份安全文档，并匆忙寻求认证者的审批。幸运的是，因为更改本身很小 🥲，所以审批通过了。
6. 尽管如此，这还需要几天时间来推出。你的服务是一个一级服务，这意味着任何新依赖项都必须谨慎 🐢 引入，以避免多区域故障。
7. 在推出后，你的团队发现对地址服务的调用次数与你API接收到的请求次数并不一致。原来，集成在其中一个代码路径中被遗忘了 💔
8. 推出了修复，之后功能才得以成功推出 🎉

看起来简单的那个功能，最终却花了好几周时间来完成，因为涉及到操作上的瓶颈、跨团队的依赖、组织内部的政策，以及对高可靠性的要求。

这并不意味着大型科技公司的功能开发速度本身就很慢。然而，工程师偶尔可能会遇到一个看似“小”的任务，每个季度一次，但由于它的连锁反应，可能会推迟更重要的项目交付。

你应该如何应对这种情况

1. 作为一名工程师，任务无论大小，在交付给客户之前都同等重要。将相同的底层逻辑思考应用到你所做的每项工作中。对于每一个变化，都要问基本的问题。识别项目的关键执行路径，并且像构建一个延迟敏感的API一样，提前主动启动所需的线程。
2. 作为一名工程经理，当你的工程师提供了一个为期3周的小改动的估计时，不要责怪传信人，而是要理解其中的组织低效问题并进行改进。做出艰难的决定（比如放弃项目），因为工程师可能不会轻易提出这些决定。
3. 作为一名产品经理，不要忽视那些看似‘小’的功能请求，然后又去追逐大目标。在站会中区分噪音和信号，并专注于真正重要的事情，这将帮助你提供解决方案。建立个人与工程师之间的联系，这将帮助建立一个桥梁，让他们可以非正式地向你求助，而不必等到下一次会议。