核心问题

工程师为什么会对某些看似简单的需求犹豫？

真实场景

PM 想加一个“超级管理员可代用户操作”的功能。页面只要一个按钮，但工程师非常谨慎。

因为这不是按钮问题，而是权限、安全、审计和责任边界问题。

常见误区

坏判断是：

工程师不愿意做，是因为嫌麻烦。

很多“麻烦”其实是系统复杂度的信号。

工程视角

复杂度可能来自：

  • 概念变多。
  • 状态变多。
  • 分支变多。
  • 例外变多。
  • 数据迁移。
  • 权限边界。
  • 回滚困难。
  • 监控和审计要求。

复杂度不是代码行数，而是未来理解和修改的成本。

PM 可以怎么做

PM 可以请工程师把复杂度翻译出来：

  • 哪个模型会被破坏？
  • 哪些边界会变模糊？
  • 哪些旧功能会受影响？
  • 哪些风险需要额外保护？

Atlas Action

当工程师说“这个复杂”时，不要追问“为什么不能简单点”，先问：

复杂度主要来自数据、状态、权限、兼容，还是发布风险？

小结

复杂度是工程系统里的长期成本。

PM 能理解复杂度，就能更准确地判断需求是否值得。