核心问题

需求评审中，PM 如何同时站在业务和工程两边思考？

真实场景

一个需求进入评审，业务方很急，工程方很谨慎。双方都对，但讨论常常卡在“要不要做”。

双视角清单能把问题拆开。

常见误区

坏判断是：

PM 只负责价值，工程师只负责成本。

真正好的决策，是价值和成本一起被看见。

工程视角

技术共情不是讨好工程师，而是理解系统代价：

  • 复杂度。
  • 维护性。
  • 兼容性。
  • 可测试性。
  • 可回滚性。
  • 长期演化。

PM 可以怎么做

评审时使用这张清单：

业务视角：
1. 这个需求解决什么问题？
2. 影响哪些用户或收入？
3. 不做的代价是什么？
4. 是否可以分阶段交付？
5. 是否值得做成通用能力？

工程视角：
1. 是否改数据模型？
2. 是否改状态机或权限？
3. 是否影响老版本和下游？
4. 是否需要迁移、灰度、回滚？
5. 是否会增加长期复杂度？

Atlas Action

每次评审结束前，用一句话总结：

我们接受哪些工程代价，换取哪些业务收益？

小结

技术共情不是降低要求，而是提高决策质量。

PM 能同时看见价值和代价，就会成为团队里最稳定的判断者。