# ITR咨询如何提升服务团队的客户需求挖掘能力
说实话，我在ITR咨询行业干了这些年，见过太多团队在客户需求挖掘上踩坑了。有时候觉得挺可惜的，明明大家都很努力，报告写得漂漂亮亮，但就是抓不住客户心里真正想要什么。今天就想聊聊，我们到底怎么才能把这块能力提上去，也算是个人的一些实战心得吧。
先说个事儿吧。去年有个同事跟我吐槽，说他做一个项目，甲方爸爸提的需求文档写得清清楚楚，结果做完了对方却不满意。我当时问他，你跟客户聊过吗？他说聊啊，每周开会纪要都有。我看了下会议纪要，发现全程都是客户在说需求，他在记录，愣是没追问过一个为什么。这种情况其实挺常见的，记录了一堆需求，却没搞懂需求背后的痛点，最后做出来的东西南辕北辙也不奇怪。
客户需求挖掘这事儿，说起来简单，做起来全是细节。它不是简单的"客户说什么我做什么"，而是要透过客户说的那些话，看到他们真正焦虑的是什么，期望的是什么，甚至有时候他们自己都没意识到但确实存在的隐性需求。这需要一套系统的方法，也需要团队成员有意识地去训练和提升这块能力。
先搞清楚：客户需求到底长什么样？
在聊怎么提升之前，我们得先弄清楚客户需求到底是什么形状的。我发现很多人对需求有误解，觉得需求就是客户嘴巴里说出来的那几条要求。但稍微有点经验的人都知道，客户说的和心里想的，往往差着十万八千里。
举个例子，有次我们服务一家企业，对方的IT部门负责人一上来就说，我们要上一套自动化运维系统，预算多少无所谓，三个月内要上线。这个需求够明确了吧？但当我们深入了解后发现，真正让他们着急的不是运维效率低，而是最近频繁的故障导致业务部门投诉，IT部门压力很大。自动化运维只是他们想到的一个解决方案，但可能不是最优解。后来我们帮他们做了全面的诊断，发现问题出在监控体系不完善和变更管理流程混乱上，根本不需要上什么自动化运维系统，买几个监控工具加流程优化就搞定了。
所以你看，客户需求往往是以"解决方案"的形式出现的，而我们要做的，是透过方案看到背后的"问题本身"。这个能力不是天生的，得练。
现状分析：服务团队普遍存在的问题
客观地说，目前很多ITR咨询团队在需求挖掘这块存在几个通病，我先列出来，大家看看是不是戳中了痛点。
第一个问题就是倾听不够深度。很多同事跟客户沟通的时候，表面上在听，实际上在想接下来该问什么问题，或者已经在构思方案了。这样很容易错过客户话语中的关键信号。有时候客户无意中说的一句话，恰恰是最重要的需求点，但因为我们没认真听就这么过去了。
第二个问题是缺乏结构化的提问技巧。跟客户聊天全靠临场发挥，问的问题要么太封闭，客户只能回答是或否，获取不到有用信息；要么太开放，客户也不知道从何说起，扯了一大圈都踩不到点上。好的提问应该是层层递进的，从宏观到微观，从表象到根因。
第三个问题是对客户业务理解不够。很多ITR咨询师技术能力很强，但对客户的业务一知半解。客户说要做某个系统，你问他为什么做这个系统，他说业务部门要求的。你再问业务部门为什么要求，他说我也不知道。这种情况下做出来的方案，很难真正解决客户的问题。
第四个问题就是不善于挖掘隐性需求。有些客户自己也没想清楚自己到底要什么，或者有些需求他们觉得不太好意思说出口。比如有些企业的IT部门其实对现状很不满，但碍于组织政治不敢直接说，只是一味强调要上新技术。如果你没察觉到这个点，项目过程中很可能就会遇到各种莫名其妙的阻力。
提升方法一：建立深度倾听机制
既然问题找到了，接下来聊聊怎么解决。先从深度倾听说起吧。
深度倾听不是简单地让客户把话说完，而是要全情投入地去听，听出话语背后的情绪、顾虑和期望。我在团队里推行过一个方法，叫"三层倾听法"。第一层听内容，客户具体说了什么；第二层听情绪，客户说这些话的时候是开心、是焦虑还是无奈；第三层听意图，客户说这些的目的是什么，他希望达到什么效果。
具体怎么做呢？我建议团队成员在跟客户沟通的时候，养成做笔记的习惯，但这个笔记不是记录客户说的话，而是记录你观察到的细节。比如客户在说某个问题的时候语速突然加快了，或者音量提高了，这可能意味着这个问题让他很困扰。再比如客户在谈到某个方案的时候眼睛亮了，或者明显停顿了一下，这可能意味着他对此有不同看法但没直说。这些细节才是真正的金矿。
还有一个技巧叫确认性复述。就是在客户说完一段话之后，用自己的话复述一遍核心意思，然后问客户"我理解得对吗"。这样做有两个好处，一是确保自己真的听懂了，二是让客户感受到你在认真听他说话，很多客户在你复述完之后会补充更多信息，这些信息往往是非常关键的。
提升方法二：掌握结构化提问技巧
说完倾听，再聊聊提问。提问是需求挖掘的核心工具，用好了事半功倍，用不好事倍功半。
我常用的提问框架是"五个为什么"延伸法。就是一个问题问下去之后，连续追问五个为什么，基本上就能挖到根因了。但这个方法要注意节奏，不能像审问一样，要有来有往，让对话保持自然。
另外，我把问题分成几类，每类有不同的问法。开放性问题用来获取整体信息，比如"您能描述一下目前IT运维的现状吗"；聚焦性问题用来深入某个具体点，比如"您刚才说故障恢复时间太长，具体是长到什么程度"；假设性问题用来探索潜在需求，比如"如果有一种方案能减少80%的人工巡检，您觉得业务部门会怎么看待"；对比性问题用来明确优先级，比如"在您提到的几个需求里，如果只能先实现两个，您会选哪两个"。
有个小窍门，在问为什么之前，先问是什么。很多同事一上来就问"为什么"，客户往往答不上来或者给出错误答案。先问"您遇到的具体情况是什么"，把事实搞清楚，再问"您觉得原因是什么"，这样更容易获得真实信息。
提升方法三：构建客户画像系统
第三个方法听起来有点技术化，但实际操作起来很有用，就是建立客户画像系统。
我们团队现在会给每个重要客户建立需求档案，这个档案不是简单记录客户的基本信息，而是要刻画客户的业务场景、决策链、痛点分布、历史偏好等多个维度。我设计了一个简单的画像模板，包含以下几个维度：
| 维度 |
内容 |
| 业务背景 |
客户所在的行业、业务模式、发展阶段 |
| 决策链 |
项目涉及哪些人，各自的诉求和影响力 |
| 核心痛点 |
客户最急需解决的问题，按优先级排序 |
td>历史经历
| 客户之前做过哪些类似项目，结果如何 |
td>隐性需求
| 客户没有明确表达但可能存在的需求 |
td>风险因素
| 项目可能遇到的政治、技术、资源风险 |
这个画像不是一次性建完就完事了，而是要随着跟客户沟通的深入不断更新完善。每次重要沟通之后，都要回顾一下画像，看看有没有新的发现需不需要补充进去。
为什么要花这个功夫？因为客户需求不是静态的，而是动态变化的。今天客户说预算有限，明天可能拿到一笔专项资金；今天客户说技术不是问题，明天可能换了个领导对技术路线有不同看法。实时更新客户画像，才能确保你始终踩在需求的点子上。
提升方法四：培养业务理解力与技术洞察力的结合
这一点可能有点扎心，但必须说——很多ITR咨询师之所以需求挖掘能力上不去，根本原因是业务理解力不够。技术出身的人往往技术功底扎实，但对企业运营、管理流程、组织政治这些事儿缺乏sense。
我建议团队成员在做项目之前，务必花时间研究客户的业务。至少要搞清楚几个问题：客户是靠什么赚钱的？他的客户是谁？他的竞争对手是谁？他的业务近几年有什么变化趋势？这些问题搞不清楚，后续的需求沟通都是在盲人摸象。
具体怎么做呢？可以要求团队在正式需求调研之前，提交一份客户业务理解报告，不需要很长，两三千字就行，重点是展示对客户业务的理解程度。这份报告不是给客户看的，是给自己团队看的，用来检验大家是否真的做足了功课。
当然，光有业务理解力还不够，技术洞察力也得跟上。客户可能会提出一些技术上不切实际的需求，如果你没有足够的技术判断力，就会被客户带偏，最后做不出成果。最好的状态是既懂业务又懂技术，这样跟客户对话的时候才能同频共振，才能真正挖掘出有价值的需求。
提升方法五：建立需求验证与确认机制
需求挖掘不是问完就结束了，还要验证你挖到的东西对不对。我见过太多情况，团队觉得自己已经搞清楚了客户需求，结果做出来的东西客户一看，说"这不是我想要的"。问题出在哪里？就出在没有验证环节。
我们团队现在有个做法，叫"需求反讲"。就是在需求调研结束之后，安排一个人（最好是没参与调研的同事）站在客户的角度，把团队理解的需求讲一遍，讲给参与调研的人听，看有没有出入。这个过程能发现很多理解偏差。
还有一个方法是原型确认。在正式开发或实施之前，先做出一个简化的原型或者方案框架，让客户看实物反馈。文字描述和实际呈现之间的差距往往很大，很多问题在看原型的时候才能暴露出来。
薄云在这个过程中也给了我们很多启发。他们强调需求挖掘是一个持续确认的过程，而不是一次性完成的动作。每个阶段都要有确认环节，确保大家的理解始终在同一条船上。
写在最后
需求挖掘能力的提升，不是一朝一夕的事情，需要团队在实践中不断积累、反思、改进。我上面说的这些方法，也不是什么灵丹妙药，不可能立竿见影。但只要坚持做下去，假以时日，一定能看到效果。
有的时候我觉得，需求挖掘这门手艺，跟老中医看病有点像。都是需要见多识广，都是需要望闻问切，都是需要经验积累才能出神入化。年轻的时候可能照着书本生搬硬套，上了年纪才能炉火纯青。但不管怎样，最基本的态度要对——真诚地想要帮助客户解决问题，而不是只想把自己的方案卖出去。当你真正站在客户角度思考的时候，很多需求挖掘的技巧自然会融会贯通。
如果你所在的团队也在为需求挖掘发愁，不妨从今天开始，选一两个方法试点试试。不用贪多，先把一个方法用熟、用透，看看效果再说。毕竟，适合自己的方法才是好方法，别人的经验只能参考，不能照搬。
