抽象需求的陷阱

最近手头压了很多项目，又正好赶上 codex 送重置，
所以这个仗打得相当的富裕。
也正因为此，铺张浪费也很严重。
干货没有，碎碎念倒是有……
一个合作的公司遇到一个问题-“研发做不出来”。
但实际上是没有人把需求定义清楚，也没有人真正为产品决策负责。
最后就变成了一种特别低效的模式：
你先做一个给我看看。
做出来以后，对方说不是这样。
你问哪里不对，他又说不清楚。
那就只能重新猜、重新做。
做完还是不对，再继续猜。
如此反复，看起来是研发效率低、产品能力不行，实际上大家一直在玩“猜需求”的游戏。
这类项目最可怕的地方，就是需求方只有否决权，没有定义能力。
我把这类统一称为抽象派的需求，
抽象需求最大的危害，不是让研发做不出来，而是让所有人一直在做，却永远没有“做完”的那一天。
但有趣的是，这两个橘色身份一换，
需求方自己上手，初版往往很快就出来了。
因为这时候他突然拥有了完整的决策权——自己说了算，自己承担结果。
之前那种“我只要否决，不用负责定义”的舒适区消失了，抽象立刻变成了具体。
解释了为啥很多人自己用 AI 搞 vibe coding 的时候，觉得自己做的东西都很牛逼一个道理。
这就跟我以前上班的时候，如果产品是产品，研发是研发，就各种事儿，
一旦我把产品跟研发合并了，他们又一片和气了，甚至一致对外的角色变成了运营。
所以本质不是“研发能力问题”，
也不是“产品能力问题”，而是责任归属和决策权不匹配。