需求沟通的 5W 标准

需求沟通不是把客户说的话记下来，而是把「谁、何时、何地、为什么、要什么结果」问清楚。五个维度都确认了，需求才有机会被正确实现；缺一个，后面就可能反复返工。

一、Who：谁使用、谁输入、谁关心

需要确认的不只是「哪个部门提的需求」，而是围绕这个功能或数据的全部角色：

• 谁使用这个功能？
• 谁输入数据？
• 谁查看和使用结果？
• 谁对结果负责？

如果多个角色都有需求，还要判断：

判断项	要问清的问题
角色清单	涉及哪些岗位、哪些部门
需求冲突	不同角色的诉求是否矛盾
优先级	冲突时先满足谁
操作权限	谁可以看、谁可以改、谁只能查

例如门店订货，店长关心订多少、总部关心总仓能否满足、财务关心订货金额是否超预算。三个角色的目标不同，功能设计不能只按其中一方来。

二、When：什么时候用、多久用一次

时间维度决定需求的价值和实现方式：

• 新数据什么时候产生、什么时候输入？
• 输入频率是每天、每周还是每月？
• 输出结果什么时候要？
• 客户期望什么时候上线？

判断需求价值时，可以问三个问题：

1. 这是一次性使用，还是反复使用？一次性需求的价值通常较低；
2. 数据获取和加工成本有多高？客户是否愿意承担？
3. 客户是否准备好了相应的人力？新功能上线后谁负责维护？

有些需求只是临时想法，例如某种促销玩法。软件开发和培训成本很高，顾问要帮助客户判断「值不值得做」，而不是有求必应。

三、Where：在什么场合使用

使用场景不同，功能形态也不同：

场景	典型使用者	设计侧重
部门内部分析	员工自己	查询灵活、导出方便
业务伙伴协作	会员、供应商、客户	界面简单、权限清晰
平级部门开会	多个部门	口径统一、可对比
向上汇报	管理层、总部	汇总准确、趋势清晰
对外发布	公众、媒体	可读性、合规性

同一个数据，在门店手机上显示和在总部大屏上显示，要求完全不同。场景没问清，做出来的功能往往「有但不好用」。

四、Why：为什么需要

「为什么」是需求沟通里最关键、也最容易被跳过的一步。常见目的有：

目的	要追问的问题
做新业务	业务细节、预算、投入是否准备好
做监控	业务是否已上线、监控指标是什么
找原因	是否有假设、假设是什么
做优化	现状是什么、目标是什么、行业通常怎么做
做预测	预测依据是什么、准确度要求多高

还要判断：这个问题是否必须通过软件解决？有些问题改流程、改制度就能解决，上系统反而增加复杂度。

顾问的经验在这里很重要。客户说不清时，可以用同行做法、行业惯例来引导，但不能替客户做决定。

五、What：目标是什么样子

前四个维度确认后，最后要把需求细化到可以评估成本的程度。

如果是数据需求

要素	要确认的内容
取数对象	哪些用户、商品、渠道、门店
取数时间段	从哪天到哪天，按日、周、月还是季度
数据指标	指标名称、计算公式、过滤条件
分类维度	按品类、门店、时段、渠道等
对比方式	同比、环比、目标对比
输出形式	报表、看板、导出文件

指标如果在系统数据字典里已有定义，直接引用；如果是客户自己定义的，必须写清计算公式和过滤条件。例如「线上订单」是否包含外卖平台订单，不同理解会算出不同结果。

如果是功能需求

要素	要确认的内容
使用端	前台、后台、小程序还是移动端
操作流程	从进入到完成的每一步
易用性	使用者是专职还是兼职、熟练程度如何
参照物	是否有同行或现有功能可参考
审批	是否需要审批、审批人是谁
冲突处理	与新功能冲突时按什么原则处理
异常处理	数据缺失、重复提交、权限不足时怎么办
权限控制	哪些角色可用、哪些角色只能查看

六、5W 速查表

维度	一句话	没问清的后果
Who	谁用、谁输、谁看	功能做给了错误的人
When	何时用、多久用一次	做了低频或无价值的功能
Where	在什么场景用	界面和流程不匹配
Why	解决什么问题	用软件掩盖了流程问题
What	具体要什么结果	开发反复返工、验收无标准

七、落地检查表

动作	系统里对应的功能
确认报表口径与维度	BI 报表分析
确认会员与储值规则	会员
确认促销与券规则	促销管理
确认门店与收银流程	连锁管理
确认权限与审批	权限与授权

八、常见问题

客户说不清需求，怎么办？ 用场景引导，而不是追问功能。先问「你现在怎么做这件事」「哪一步最费时间」「做完之后想看到什么」，再回到 5W。

客户坚持要做，但明显不合理，怎么办？ 先确认目的，再给出替代方案和成本对比。如果仍然要做，把假设、风险和验收标准写进需求确认单。

需求确认后客户又改，怎么办？ 区分「补充说明」和「范围变更」。前者可以吸收，后者要重新评估工期和成本，并留下书面确认。

5W 要问到多细？ 细到可以评估开发成本和验收标准为止。数据需求要能写出计算公式，功能需求要能画出操作流程。