如何摆脱 early-stage mindset 而不制造官僚主义

Source: Dev.to

背景

当我以技术主管的身份加入 Monest 时，技术团队只有 12 人。一年后，我们已经增长到 35 人。这种增长改变了一切：在 12 人时有效的流程在 35 人时根本行不通。问题在于没人会立刻察觉；团队仍然按原来的方式工作，直到某件事崩溃。等你想要改变时，常会听到每个技术主管都熟悉的那句话：“但一直都是这么做的”。

难点不在于识别需要改变的地方，而在于如何在不把公司变成需要数周才能完成一次部署的官僚机器的前提下进行改变。初创公司靠速度生存；过度的流程会扼杀公司走到今天的根本动力。

实施的流程示例

以下是我们引入的四项具体变更，以及它们最初引发的阻力：

1. 强制性的端到端（e2e）测试

   • 之前没有自动化测试，团队要么手动测试，要么根本不测试。
   • 12 个人时，所有人都了解整个系统。
   • 35 个人时，没有人对全局有完整的视野，于是我们把 e2e 测试设为必需。

2. 在 TypeScript 中使用真实的类型

   • 我们的 “TypeScript” 其实是带 .ts 扩展名的 JavaScript，所有地方都使用 any。
   • 当每个人都知道每个函数的预期时，这种做法还能工作。
   • 我们实现了严格类型，并在 6 个月内消除了 4 041 条 TypeScript 错误（详情见文中引用的文章）。

3. 把可观测性作为规则

   • 在所有服务中部署了 New Relic。
   • 之前，生产环境出现问题时，需要一个“侦探”在本地复现错误。
   • 现在我们可以准确知道发生了什么、在哪里以及为什么发生，靠的是数据而不是记忆。

4. 对新功能使用 RFC（Request for Comments）

   • 之前有人有想法，就在走廊里聊聊，然后直接开始编码。
   • 现在，新功能必须先提交一份最小化文档，说明 什么、为什么 和 如何。
   • 文档不需要冗长，但必须存在。

在所有案例中，最初的反应都是一样的：“但以前不需要”。答案不能是“现在需要是因为我说了”。那只会产生怨恨。

结果

实施这些变更一年后，我们的数据如下：

• 支持工单减少 50 %
• Q4 的事后分析（post‑mortems）比 Q1 少 36 %，即使团队规模几乎扩大了 3 倍，且每周仍进行 80+ 次部署

当你能够展示“繁琐”带来了具体成果时，讨论的氛围会随之改变。

如何决定新流程

了解该实施什么同样重要的是知道何时该停下来。我们遵循的几条准则：

• e2e 测试：必须，但不要求 100 % 覆盖率。
• RFC：新功能必须提交，但 bugfix 不需要。
• 类型：保持正确，但采用渐进式迁移。

在创建任何新流程之前，我会自问：

“这会帮助团队交付得更好，还是只会增加工作量？”

如果答案是“只会增加工作量”，我就不会实施。

结论

成长是痛苦的。以前有效的做法不再适用，你必须说服人们去改变他们并不认为是问题的东西。关键在于 创建能够保护公司而不产生阻碍其运转的官僚流程。没有万能公式；只有不断尝试、错误并持续关注结果。