核心问题

为什么 PM 的文档能力可以变成工程协作优势？

真实场景

技术方案会上，工程师讨论了很多权衡：吞吐、运维、数据一致性、上线风险。会后没人整理，几周后大家只记得结论。

PM 如果能把这些权衡记录下来，就在帮助团队保留判断。

常见误区

坏判断是：

ADR 是技术文档，只能工程师写。

ADR 当然需要工程师确认技术事实，但 PM 可以负责结构、背景、业务约束和决策叙事。

工程视角

很多技术决策其实混合了：

  • 业务目标。
  • 时间窗口。
  • 用户影响。
  • 团队能力。
  • 维护成本。
  • 技术风险。

这些正是 PM 擅长组织的材料。

PM 可以怎么做

PM 可以承担 ADR 的“第一稿”：

  • 写清业务背景。
  • 整理候选方案。
  • 记录工程师提出的风险。
  • 标注最终决策和代价。
  • 请技术负责人 review。

Atlas Action

下次技术方案会后，用 30 分钟写一份 ADR 草稿，然后发给工程师补技术细节。

不要等“有空再写”。决策刚发生时，记忆最便宜。

小结

PM 写 ADR，不是越界，而是在做工程团队最缺但最重要的整理工作。

文档能力如果用对地方，就是系统记忆能力。