核心问题

PM 如何把这门课的七个模块变成日常判断动作？

真实场景

一个新需求来了。它看起来有价值，也看起来不难。但你现在知道，真正的问题不是“写不写”，而是要判断：

  • 值不值得做？
  • 会引入什么复杂度？
  • 用什么技术承载？
  • 出问题怎么查？
  • 旧系统为什么这样？
  • 决策如何留给未来？
  • AI 能帮哪里？
  • 自己还要补什么能力？

常见误区

坏判断是：

PM 只负责把需求讲清楚，剩下交给工程。

需求清楚只是起点。好的 PM 会参与价值、代价、风险和演化路径的判断。

工程视角

这门课可以压缩成一张地图：

需求出现
  ↓
它真的值得做吗？        -> Business / ROI
  ↓
它会引入什么复杂度？    -> Technical Empathy
  ↓
该用什么技术承载？      -> Boring Technology
  ↓
出问题如何定位？        -> Debugging
  ↓
旧系统为什么这样？      -> Code Archaeology
  ↓
决策如何留给未来？      -> ADR
  ↓
AI 能帮哪一段？         -> AI Co-pilot
  ↓
我长期该补什么能力？    -> T-shaped Learning

PM 可以怎么做

把地图变成评审动作：

价值：这个需求解决什么业务问题？
代价：它改变哪些数据、状态、权限、接口？
技术：是否需要新技术，还是无聊技术足够？
排障：如果出问题，如何复现和定位？
历史：旧系统里有没有围栏不能乱拆？
记录：这次关键决策是否需要 ADR？
AI：哪些低风险任务可以交给 AI 草拟？
学习：这次项目暴露了我哪个技术短板？

Atlas Action

下次需求评审，拿这八个问题做会前准备。不要全部问出来，但要全部想一遍。

如果某个问题完全答不上来，它就是本次需求的风险盲区。

小结

PM 学软件工程，不是为了把自己改造成工程师，而是为了成为更好的系统合作者。

好 PM 不是把需求推给工程师，而是能和工程师一起判断：什么值得做，怎么做，代价是什么，未来的人能不能接得住。