在需求讨论中，有一句话很多 IT 人一定都听过：
“这个需求不复杂吧？应该很快能做出来。”
业务说得很轻松，
IT听得很沉重。
因为在业务看来，只是“加一个功能”；
但在 IT 看来，背后可能意味着：
流程要重构，
规则要重写，
数据要重整，
系统还可能被牵一发动全身。
于是，双方就很容易进入一种“彼此都不理解”的状态：
业务觉得 IT 反应过度，
IT觉得业务把问题想得太简单。
但真正的问题，并不是谁对谁错，而是：
双方看到的，其实不是同一个问题层次。
为什么同一个需求，业务觉得简单，IT却觉得复杂？
最核心的原因是：
业务和 IT 看到的是不同的东西。
业务通常关注的是：
我想要什么结果。
这个功能能不能帮我解决问题。
操作上能不能更方便。
而 IT 关注的是：
这个需求要怎么落地。
会影响哪些流程和逻辑。
系统结构是否还能承载。
也就是说：
业务看到的是“表面动作”，
IT看到的是“背后结构”。
举个很常见的例子：
业务说：
“这个工单状态切换的时候，顺便自动带出一条采购申请，不就行了吗？”
听起来像是一个小功能。
但对 IT 来说，背后可能涉及：
· 工单流程和采购流程的衔接
· ERP接口调用
· 角色权限控制
· 数据一致性处理
· 异常场景回退机制
所以，业务看到的是“一个动作”，
IT看到的是“一整条链路”。
在项目中，有些需求之所以被误认为简单，不是因为真的简单，而是因为：
它被表达得太简单了。
比如业务常说：
· “这里加个校验就行”
· “这里自动带一下数据”
· “这里多一个状态就好”
这些话听起来都很轻。
但有经验的 BA 会知道：
越是这种“看起来简单”的需求，越要多问几步。
因为它背后可能牵扯的，不只是一个界面动作，而是：
· 数据从哪来
· 谁维护
· 规则是什么
· 出错怎么办
· 会不会影响其他流程
很多需求真正的复杂，不在“功能表面”，而在：
它所连接的上下游关系。
在业务和 IT 之间，BA 有一个非常重要但经常被低估的价值：
把“业务觉得简单的事”，翻译成 IT 能准确判断复杂度的结构。
这其实是一种很核心的能力：
不是简单地转述需求，
而是把需求背后的影响面说清楚。
例如，当业务说：
“我们想自动生成采购申请。”
一个有经验的 BA 不会只记下这句话，而是会继续拆：
· 触发条件是什么？
· 所有工单都触发，还是特定类型才触发？
· 采购申请由谁审批？
· 如果 ERP 返回失败怎么办？
· 是否需要回写状态？
当这些问题被展开后，业务和 IT 才真正开始看到：
这不是一个按钮，而是一套规则。
因为双方都在用自己的视角说话。
业务说的是：
“我只是想解决一个现场问题。”
IT说的是：
“这个逻辑做进去，系统结构会变复杂。”
两边都没有错，
但如果中间没有人去做“层次转换”，沟通就会越来越僵。
所以很多需求会卡住，不是因为谁不配合，而是因为：
问题没有被放到同一个层次上讨论。
业务在讲结果，
IT在讲结构，
但会议却以为大家在讨论同一件事。
这里可以用一个很实用的方法：
看这个需求，是否会影响下面三个层次：
只影响界面吗？
如果只是展示方式、输入方式变化，通常复杂度较低。
如果涉及判断逻辑、角色权限、流程流转，复杂度会明显上升。
会影响上下游吗？
如果涉及跨系统、跨流程、跨角色协作，复杂度通常不会低。
很多业务觉得“简单”的需求，往往卡在第三层。
因为表面上只是一个动作，
背后却连接着多个系统和流程。
很多 BA 容易陷入一个误区：
一边觉得业务不懂技术，
一边觉得 IT 不懂现场。
但做多了之后你会慢慢发现：
需求分析真正重要的，不是替哪一方说话，而是：
帮助双方看到同一件事。
业务要看到：
为什么看似简单的事，落地并不简单。
IT也要看到：
为什么这个需求对业务来说，是一个真实且重要的问题。
当双方开始看到同一个问题结构时，沟通就会顺很多。
很多需求之所以难推进，并不是因为业务和 IT 不配合，而是因为：
他们看到的，本来就不是同一个层次的问题。
业务看到的是结果，
IT看到的是结构。
而 BA 的价值，就在于站在中间，帮助双方把“看起来简单的需求”，还原成真正的业务逻辑与系统影响。
这其实不是在“写需求”，而是在：
做认知翻译。
而这，也是一个 BA 从“执行型”走向“成熟型”的重要分水岭。
转载自公众号-业务需求分析&架构
