与产品经理对齐需求：把要个按钮翻译成方案
格子衫与bug
4 min read
产品经理说"加个按钮"，常常不是在描述界面，而是在描述一个还没想清楚的诉求。直接照做，多半会在上线后被追问"为什么不是弹窗""为什么不能撤回"。你的价值不是更快地写按钮，而是把这句模糊的话翻成可落地的方案，以及该补问的那几个问题。
直接做为什么会翻车
假设对方要一个"导出报表"的按钮。你做完了，结果发现用户点完没有任何反馈，以为没生效又点了三次，后台生成了三份。这不是你代码写错，是需求里"点完之后呢"这一段从没被讨论。
我见过更典型的：一个"筛选"按钮，产品要的是"按状态筛"，开发理解的"筛选"包含了时间范围，上线后产品在演示时点了时间筛选，界面空了，当场尴尬。差异不在能力，在双方脑子里的"筛选"不是同一个东西。对齐省下的，是返工和信任损耗。
翻译的四层追问
拿到一个诉求，按这个顺序问，通常能挖出真正的需求：
第一层，目标。这个按钮要解决谁的什么问题？如果对方答"就是用户想要"，继续问到具体场景。没有场景的诉求，先做最小验证，别直接排期。
第二层，边界。成功长什么样，失败长什么样？点了没反应算成功还是 bug？数据为空时显示什么？把这些写进需求，而不是靠你猜。
第三层，例外。并发点会怎样？权限不够的人点了怎样？旧数据怎么处理？例外不提前说，就会变成上线后的紧急工单。
第四层，度量。怎么知道这个按钮做对了？是点击率、完成率还是客诉下降？没有度量的功能，做完也难以判断是否该保留。
用验证代替争论
很多对齐卡在"我觉得用户要的是 A""我觉得是 B"。别争，做个不能更便宜的验证：画个草图发群里、拉两个人试用、或者先上隐藏开关只放给内部。经验上，一个下午能做出来的纸面原型，比三天的需求评审会更接近真相。
把选项摆出来比抛问题更有效。不要只问"你要什么"，而是说"我理解有两种做法，A 简单但少了撤回，B 多两天但更稳，你选哪个"。这把模糊的问责变成了清晰的取舍，产品也更容易给决定。
反例与边界
反例一是全盘接受。产品说什么你记什么，从不追问，锅终归还是你的——因为"你作为技术方没指出风险"。反例二是过度对抗，每个点都质疑，产品不敢再来找你，绕开你直接找别人改，反而更失控。
边界在于：你负责的是可行性与风险，不替产品做业务决策。该问的问到位，该提醒的提醒到，决定权交给对方，但留痕。对齐不是说服谁，是让方案在动手前就少几个坑。
把对齐结果留痕
口头对齐会蒸发。重要的需求结论，用三五句话发回确认："按刚才聊的，按钮点击后弹确认、成功后 toast、失败保留表单。如有出入今天内告诉我。"这封消息不是形式，是上线扯皮时的依据。经验上，花两分钟留痕，能省掉未来两小时的复盘会。
一份可用的对齐清单
把上面四层追问固化成一张小清单，每次需求评审前过一遍：
- 目标用户与场景：谁会用，在什么情况下用？
- 成功与失败的判定：做完怎么算好，出错了长什么样？
- 例外与边界：并发、权限、空数据、旧版本怎么处理？
- 验证方式：怎么证明它做对了，有无可观测指标？
评审时把这张单子抛出来，比开放式"你还有什么要问的吗"高效。对方答不上来的点，就是排期前必须补的坑。经验上，每张单子至少能挖出两三个原本会被忽略的例外。
把这张单子当成你和产品的共同文档，而不是你的私货。评审结论记在文档里，后续扯皮时有据可查。这比口头"你当时说过的"强太多，也让你在需求变更时，有底气说"这不在当初对齐的范围内"。
很多返工，省下的不只是代码量，更是信任损耗——需求一旦扯皮，产品对你的专业判断也会悄悄打折扣。对齐做在前头，是技术方最便宜的信誉投资。
1 view
0 likes
0 comments