核心问题

PM 如何从“我要这个功能”转向“这个功能的实现代价是什么”？

真实场景

PM 说：“给订单加一个状态就行。”工程师沉默了，因为订单状态影响支付、发货、退款、报表、客服后台和消息通知。

需求在页面上是一行，在系统里可能是一张网。

常见误区

坏判断是：

UI 上只是多一个字段，所以开发也应该很简单。

工程复杂度通常不由页面大小决定，而由系统影响面决定。

工程视角

实现代价来自：

  • 数据模型是否要变。
  • 状态机是否要变。
  • 接口是否兼容。
  • 历史数据是否迁移。
  • 下游系统是否依赖。
  • 测试范围是否扩大。
  • 发布是否需要灰度。

PM 可以怎么做

提出需求时同步提供工程需要的上下文：

  • 为什么要做。
  • 使用频率多高。
  • 哪些用户受影响。
  • 是否必须兼容历史数据。
  • 是否可以分阶段上线。

Atlas Action

每个需求评审前，补一栏：

可能影响的系统对象：数据、状态、权限、接口、报表、通知、历史记录。

小结

PM 的成熟，不是少提需求，而是提需求时能意识到系统代价。

需求越清楚，工程越能做出好判断。