前言

做交付的人都有一个共识：项目延期和返工，八成是因为需求没搞对。剩下的两成，才是技术问题。

需求调研看起来就是去客户那儿聊聊天、做做记录，但做好和做砸的差距，直接决定项目的生死。这篇文章不讲方法论概念，只讲实际场景里管用的做法。

一、调研前：不做准备就是准备失败

1.1 把合同和 SOW 嚼碎了再出发

去客户现场之前，至少把这三份东西通读两遍：

  • 招标文件（看客户当初怎么描述这个项目）
  • 合同/SOW（看双方约定的交付边界）
  • 客户的组织架构（知道谁是谁、谁说了算）

读完之后，列一个”待确认清单”——合同中写得模糊的地方、你认为有矛盾的地方、需要客户决策的选项。这份清单就是调研访谈的核心提纲。

1.2 确定”对的访谈对象”

一个项目最少要访谈这三类人：

角色 关注什么 怎么聊
决策者（部门领导） 项目目标、业务价值、与其他系统的关系 问”为什么做这个项目”以及”什么样算做成了”
业务骨干（实际使用者） 日常工作流程、痛点、效率瓶颈 观察他们的实际操作，而不仅仅是听他们描述
IT 接口人（技术对接） 现有系统架构、接口标准、部署环境限制 带好你的技术经理一起去，当场确认技术细节

注意：有时候这三类人给你的信息是矛盾的。决策者说要做 A，业务骨干说其实需要 B，IT 说技术上只能支持 C。这种情况是正常的——你需要做的是记录下来，标注冲突，推动对齐会议，而不是自己在那猜该听谁的。

1.3 最少两人一组去调研

一个人负责问，另一个人负责记。一个人主导访谈，另一个人观察客户的微表情和语气变化（说到哪个需求时客户犹豫了？说到哪个痛点时眼睛放光了？）。

回来之后两个人对一遍记录——你会发现，两个人听到的东西经常不一样。

二、调研中：问对问题比什么都重要

2.1 避免”你们需要什么功能”这种开放式问题

这种问题一出口，客户要么说”我也没想好”，要么列出一个天文数字的需求清单。

更好的问法：

不要这样问 换成这样问
“你们需要什么功能？” “你每天来上班，第一个打开的系统是什么？在里面做什么？”
“这个流程有什么问题？” “上个月有没有因为这个问题导致加班/投诉/数据出错？”
“你希望系统做成什么样？” “如果有一件事，换成新系统后能让你每天省 20 分钟，那会是什么？”

2.2 追问”为什么”至少三次

客户说的往往是”解决方案”，而不是”需求本身”。

1
2
3
4
5
6
7
8
9
客户: "我要一个导出 Excel 的功能"
你: "导出来做什么用？"
客户: "我要发邮件给财务"
你: "财务拿这个表做什么？"
客户: "他们要根据数据做月度结算"
你: "这个流程能不能直接对接财务系统，不需要人工导出？"
客户: "……那更好"

结论：客户需要的不是一个"导出 Excel"按钮，而是"把业务数据同步到财务系统"。

客户告诉你的第一层需求，通常是他们已经在自己脑子里”设计过一遍”的解决方案——但这个方案可能不是最优解。深挖背后的业务流程，才可能做出比客户预期更好的东西。

2.3 让客户演一遍

当你觉得已经把流程搞清楚了，让客户拿真实数据走一遍。

1
2
3
4
5
6
你: "能打开你们现在用的系统，给我演示一下你今天上午完成的第一件事吗？"

客户操作过程中你会发现：
- 有些步骤客户以为"你懂的"就跳过了
- 有些步骤客户自己都忘了提
- 有些坑只有实际运行时才会暴露（"对了，这个地方经常报错……"）

三、识别伪需求与隐性需求

3.1 伪需求的三种典型特征

第一类：把竞品功能当需求

“我看 XX 公司有这个功能，我们也得有”——问他”这个功能解决你的什么问题”，如果答不上来，大概率是伪需求。

第二类：为了”万一以后要用”提的需求

“先做上吧，没准以后需要”——没准以后 = 现在用不上。记下来但不做，如果真的是必须的，客户后续会再次提起。

第三类：领导拍脑袋的

调研会上突然有客户领导加一句”顺便也做一下 XX 吧”，然后所有人点头。这种情况处理要小心——下来后找对接人单独确认优先级，很可能对方领导就是随口一说。

3.2 隐性需求藏在哪里

  • 客户抱怨的语气词：”这个倒也没啥，就是有点麻烦”——“有点麻烦”背后往往是真实痛点
  • 客户自己的”野路子”操作：比如把系统当 Excel 用、用 QQ 传文件绕开审批。这些”补丁操作”暴露了现有系统的缺陷
  • 不同部门之间的交接环节：数据从 A 部门传到 B 部门的那个”接口”，往往是最容易出问题的

四、需求确认：口头说的不算数

4.1 当场复述确认

每聊完一个模块，按这个模板复述一遍：

“我理解你的需求是这样的——场景是 XXX，你需要在 XXX 情况下做 XXX 操作，预期结果是 XXX。我理解得对吗？”

这 30 秒的确认，能省掉后面 30 小时的对齐会议。

4.2 用原型代替长篇 PRD

给客户看 500 字的文字描述，不如给他看一张界面草图。用 Axure、Figma 甚至纸笔画都可以。

“点这里可以看到这个页面，输入手机号，点击提交，系统会发一条短信过来”——客户看原型的时候，眼睛是亮的，因为你终于把他们脑子里想的东西呈现出来了。

4.3 签字确认的艺术

需求文档写好了，客户不肯签怎么办？

“这个签字不是说以后就不能改了，只是帮我们把现阶段的共识固定下来。后续如果有调整，走变更流程就行。”

这样可以降低客户签字的心理负担。重点不是”不能改”，而是”改了要走流程”——让客户知道变更是有成本的，不是在玩。

五、需求文档怎么写

一份能干活的需求说明，至少包含：

  1. 场景描述：谁、在什么情况下、想做什么
  2. 前置条件：执行这个操作前，系统必须处于什么状态
  3. 操作步骤：1、2、3……每一步的输入和预期反馈
  4. 异常处理：如果输入错误、网络断开、数据为空，系统怎么反馈
  5. 验收标准：怎么算”做完了”（可量化优先）
  6. 界面原型截图（有就放，没有就画）

模板不用复杂，重在覆盖全面。很多需求说不清楚，就是因为缺了第 4 条”异常处理”——正常流程谁都能想明白，异常情况才是 bug 产出的主力。

需求调研这件事，说到底是把客户的脑子里的想法，完整、准确地装进开发团队的脑子里的过程。这个过程中流失的信息越少，交付就越顺。多花一天调研，后面少走一周弯路。