【建立技术世界观】03 | BA为什么总被开发“怼”？问题不在沟通，在翻译（附：需求五问）

周三下午我又被开发“怼”了周三下午你又一次被开发“怼”了。场景是这样的你在群里问开发“这个订单状态同步的需求什么时候能上线”开发回了一句“你先把接口文档确认清楚再问。”你觉得莫名其妙。你不是确认过了吗怎么又变成你的问题了你不死心又问了一句“我确认过了啊就是按之前说的那个逻辑。”开发秒回“之前说的你需求里写的是‘同步订单状态’但没写同步哪个字段、什么时候同步、同步失败怎么办。我按我的理解做了你说不对。现在要返工你问我什么时候上线”群里安静了。你看着屏幕脸发烫。你想反驳但你知道他说的是事实。你确实没写清楚。但你不服气。你明明开会的时候都说过了也发过会议纪要开发怎么就不认真看呢你委屈地想沟通怎么就这么难90%的沟通问题本质是“认知错位”停。问题不在沟通。90%的“沟通问题”本质都是“认知错位”——你以为你在说“做什么”开发听成了“怎么做”。你开会时说“这个订单状态要同步到ERP。”你的意思是业务上需要这个功能你听懂了吗开发听到的是你要我实现一个功能具体怎么实现我自己决定。你讲的是“业务目标”开发听的是“技术任务”。你们用的是同一个语言中文但大脑里跑的是两套逻辑。这不是沟通技巧的问题。你就算把话说得再漂亮、会议纪要写得再详细如果你们对“需求”的认知不在一个维度该错还是错。真正的沟通不是“把话说清楚”而是“让双方对‘问题’和‘解法’达成共识”。而达成共识的前提是你知道开发大脑里的“翻译器”即“需求建模““需求 → 技术实现”的映射过程是怎么工作的。你知道他们听到你的话之后会自动补全哪些东西、会默认忽略哪些东西。当你理解了这套“翻译机制”你就能在一开始就把话说对。而不是等开发做完了才发现“他理解错了”。在软件工程里这一步叫“需求规格化”Specification。开发大脑里的“翻译器”是怎么工作的我用一个类比把开发大脑里的“翻译器”讲清楚。你找了一个装修队要装修你的房子。你对工头说“我要一个现代简约风格的客厅。”在你的脑子里这句话的意思是暖色调、无主灯设计、有电视背景墙、沙发要舒服、要有足够的收纳空间。但在工头的脑子里这句话被翻译成了“现代简约” 不做复杂的吊顶、墙面刷白、地面用灰色瓷砖“风格” 我按行业标准做你没说的 不需要做然后他按自己的理解开工了。你去看的时候发现客厅是白色的墙、灰色的地什么都没有。你觉得这不是你要的“现代简约”。你责怪工头“我不是说清楚了吗”工头说“你说清楚了现代简约我就是按这个做的。你要的那些东西你没说啊。”这就是开发大脑里的“翻译器”你说的话开发听到的翻译后“同步订单状态”“做一个接口A系统调B系统”“提前一周”“时间点7天”“发短信”“渠道短信”“内容你写一下”“内容默认模板”你看你说的是“业务目标”开发翻译成“技术动作”。你说的是“大概方向”开发翻译成“默认值”。问题出在哪你说了“风格”业务目标但没给“清单”具体需求。工头按“行业标准理解”去执行了但你的“标准”和他不一样。开发不是故意跟你作对。他们的大脑被训练成了“按输入执行按默认值补全”的模式——你给什么他做什么。你没给的他就用默认值。而默认值往往和你的业务期望不一样。两个致命错误把“说明”当“沟通”把“问题”当“态度”BA最常见的错误不是“说不清楚”而是把“沟通”当成“说明”。我见过一个真实案例。一个BA要开发一个“用户积分过期提醒”功能。她在会上说“用户积分快过期的时候系统要给用户发个提醒。”开发问“什么时候发提前几天”BA说“提前一周吧。”开发又问“发什么内容发短信还是App推送”BA说“发短信吧内容你写一下大概就是积分快过期了。”开发没再问了。功能上线后业务方炸了短信内容写的是“您的积分即将过期请及时使用”但没有写具体有多少积分、什么时候过期。用户收到短信后一头雾水客服电话被打爆。BA去找开发“你怎么不写清楚积分数量和过期时间”开发说“你没说啊。你说‘大概就是积分快过期了’我就按这个写的。”你看问题出在哪BA以为“沟通”就是“把需求说出来”。她觉得开发会“理解”她的意思会“补全”她没有说的细节。但开发不会。开发的工作模式是“需求驱动”——你说什么他做什么。你没说的就是没有。开发一定会补全你没说的部分——问题不在于“会不会补全”而在于“补全的是否符合你的业务预期”。沟通不是“说明”是“定义”。你要定义清楚发什么内容、什么时候发、发给谁、怎么发、发了之后怎么追踪、用户回复了怎么办……如果你只是“说明”你就把“定义权”交给了开发。而开发的定义往往和你的期望不一样。另一个常见错误是把“沟通问题”当成“态度问题”。当开发说“你没写清楚”的时候很多BA的第一反应是“他在推卸责任”或“他态度不好”。然后他们开始“加强沟通”开更多的会、发更长的邮件、写更细的会议纪要。但问题没有解决。因为问题不在沟通频率而在沟通质量。你开10次会每次都说“大概是这样”不如开1次会把“具体是什么”说清楚。开发要的不是“更多的沟通”是“更精确的定义”。记住这句话“你以为你在沟通其实你只是在说明。开发要的不是说明是定义。”需求五问把业务语言翻译成开发能执行的代码我送你一个模型叫“需求五问”。以后你写任何需求、开任何评审会之前先用这五个问题把需求“翻译”成开发能听懂的语言第一问触发条件什么时候执行这个功能用户点按钮定时任务系统自动触发触发的前置条件是什么用户必须登录订单必须已支付第二问输入数据这个功能需要什么数据用户ID订单号商品信息数据从哪里来用户输入数据库查另一个接口第三问处理逻辑拿到数据后要做什么计算校验转换存库有没有分支逻辑如果是A就做X如果是B就做Y第四问输出结果处理完后输出什么成功提示返回数据触发另一个系统输出到哪里页面展示存数据库调接口第五问异常处理如果中间出错了怎么办重试跳过人工介入用户会看到什么错误提示还是什么都不显示你把这五问的答案写清楚开发就不会“猜”了。你不写开发就会按自己的“默认值”去做而默认值往往是错的。当然好的开发也会主动追问、澄清需求。但在现实中你不能把“理解责任”完全交给对方。你定义得越清楚系统出错的概率越低。值得一提的是这五问解决的是“功能能不能做对”但在真实项目中还需要考虑权限、性能、数据一致性等问题。这些后面我们会慢慢介绍。如果你发现这五问和你之前学的“存-传-算-显”模型很像恭喜你你已经打通了。第一篇文章讲的“技术四步法”——存储、传递、计算、呈现——是理解系统怎么运转的底层框架。这五问就是把业务需求“翻译”成那四步的具体操作触发条件 → 决定“什么时候开始传递”输入数据 → 决定“传递什么”处理逻辑 → 决定“怎么计算”输出结果 → 决定“呈现什么、存储什么”异常处理 → 决定“计算出错怎么办”当你把这两套模型放在一起你就同时拥有了“理解系统”和“定义需求”的能力。三个问题检验你的需求是否“可执行”下次你和开发沟通需求时用这三个问题自检问题1我说的这句话开发会怎么“翻译”如果我说“同步订单状态”开发会理解成什么他会默认哪些细节那些默认细节和我想要的一致吗如果你答不上来说明你还没进入开发的“翻译器”。问题2我是在“说明”还是在“定义”“说明”是描述大概意思“定义”是写清楚边界条件如果你的需求里有“大概”“一般”“尽量”这类词说明你还在“说明”阶段。问题3如果开发一个字不差地按我说的做结果会是我想要的吗这是一个检验标准。如果你不确定说明你的需求还不够精确。如果你确定那你已经是一个合格的“需求定义者”了。 BA避坑指南开发最怕听到的5句话你说的话开发听到的你应该说的“大概就是这样”“我不确定你猜吧”明确边界或说“这个我确认后补充”“你看着办吧”“出问题我背锅”给出方向或明确授权范围“和上次那个差不多”“你去翻历史记录”明确指出“和上次的区别”“业务方说要这个”“我也不知道为什么要做”解释业务背景和价值“你先做着后面再改”“反正要返工”明确MVP范围和迭代计划回头看你已经走了多远第一篇文章我们解决了“为什么需要懂技术”——因为不懂你就没法判断AI的对错。第二篇文章我们解决了“怎么用对的方式理解技术”——用类比、问问题、一句话讲清。第三篇文章我们解决了“为什么开发总怼你”——因为你的“说明”需要翻译成“定义”。下一篇文章我们来回答一个更根本的问题从0开始技术世界到底在解决什么问题你会发现所有复杂系统的背后都只是在做一件极其简单的事情。开发不是你的敌人也不是你的下属。他们是你的“翻译对象”。你的工作不是让他们“听你的话”而是把你的业务语言翻译成他们能执行的技术语言。当你理解了这套“翻译机制”你会发现那些曾经让你委屈的“怼”其实都是开发在告诉你——你的翻译还不够精确。今日行动选一个你最近被开发“怼”过的需求用“需求五问”重新梳理一遍。梳理完之后对比一下你原来的需求里这五个问题分别回答了哪些哪些是缺失的评论区发出来我会选出3个典型需求在下一篇文章中专门分析。PS如果你也曾经被开发“怼”到委屈把这篇文章转给那个和你一样困惑的BA朋友。【知识卡片】认知错位公式你说“业务目标” 开发听成“技术任务” 需求返工需求五问触发条件 → 输入数据 → 处理逻辑 → 输出结果 → 异常处理BA避坑口诀不说“大概”说“具体” 不说“你看着办”说“这样办” 不说“和上次一样”说“这次不同”