作为一名IT行业从业者，多年周旋在需求提出方（客户）与需求实现方（程序员）之间，如何能够确保程序实现的就是客户想要的？最首要的就是要知道客户究竟想要什么。
有一个网络上流传的段子：客户去饭店，坐下来，对服务员：“服务员，给我来份宫保鸡丁！”，服务员爽快的答道：“好嘞”。接下来服务员跟大厨说：“做份宫保鸡丁”，大厨赶紧开做，做了一半客户又叫服务员“服务员，宫保鸡丁不要放肉”，服务员惊诧的问“不放肉怎么做啊？”，客户说“不放肉就行了，其他按正常程序做不就行了，难么？”
这个段子后续还有好几集，上面引述的只是一个开始，在大厨做的过程中，不断的增加、减少各种材料，导致一道菜总也做不出来，客户就又开始催服务员，就这样一个恶性循环开始了，好不容易做出了一道菜，客户说不是想要的味道，这时大厨从厨房拿着一把刀出来了。程序员最怕的是什么？问君能有几多愁，调完代码改需求。
段子当然比较夸张，但也来源于事实。究竟逼疯大厨的是什么？如果服务员能在大厨开始之前和客户确认好到底客户口中说的宫保鸡丁是什么，也许大厨就不会在这一道菜上一直反复，浪费时间，客户也可以得到满意的菜品。所以在开始实施一个产品之前，确认好客户需求至关重要。如何能让客户满意，大厨不疯呢？
聆听
我们都曾以为听对方说话是一件最容易的事情，但是却会犯很多错误，比如以下几个：
1、耳朵在听，大脑在思考其他问题
虽然在听着，但是大脑却在想着其他问题，有时候是因为外界环境的打扰，比如突然有个即时消息需要回复，有时候是因为大脑自己无法集中注意力，比如谈论当前需求的时候，还在想着上一个需求要怎么实现。不要相信自己的大脑是多核处理器，可以同时处理多项任务，关注当下，把耳朵输入的信息放入大脑去思考。
2、以为自己理解了，急于下定论
这也是经常会犯的错误，有时候我们会高估自己的理解能力，以为自己理解了对方的意思，便打断了对方，给出了自己的结论，这时候我们理解的也许只是表层的需求，便把表层的需求当成了真正的需求，真正的深层需求对方却还没有表述出来。
3、忽视对方的非语言信息
听语言信息还不够，有时候非语言信息反而更重要，比如语气、态度、表情、手势等等，这些可以表达出语言无法表达或者没有表达出的信息，通过这些信息有时候可以判断出需求的紧急或者重要程度。
因此，聆听需要专注于当下，不仅专注于听客户所说的话，还要观察其他非语言信息，并给予对方充分的表达空间，以达到真正理解的目的。
提问
提问就像考试出题者，基本上有三种题型，简答题、选择题、判断题，在考场身经百战的我们都有过考试的经历，从答题难度上来排序，简答题>选择题>判断题，而且对于判卷的人来说难度排序也是如此。比如拿确认一个会议或者约会时间来举例：
简答题：你什么时候有空？
选择题：你明天上午或者今天下午什么时间方便？
判断题：今天晚上你有空么？
简答题属于开放式问题，判断提属于封闭式问题，选择题介于二者之间，如果答案在选项内容就是封闭式问题，如果答案不在选项内容，就会有出现一个新的开放式问题。
三类问题的提问顺序也是循序渐进的，如果一上来就问判断题，如果对方回答是，那可能会导致信息收集不全面，而导致遗漏重要信息，如果对方回答否，那可能要问很多个问题才能明确具体内容，而导致浪费时间。提问的问题类型顺序会根据需求的逐渐清晰而越来越封闭，适当的时机选择适当的问题类型去提问，直到最终找到对方想要的答案。
而开放式问题，虽然可以让对方畅所欲言，让我们得到更多的信息，讨论的氛围也更为轻松，但是容易在讨论的过程中偏离主题，无边蔓延，因此确认主题和范围是是前提，在讨论的过程中引导讨论方向不偏离目标。
确认
理解了客户的需求，还没有结束，还需要做最后一步的确认。确认不仅仅是讨论过程中的口头确认，还要做好书面纪要，作为讨论的交付物之一进行最后的确认，确认的过程需要留有一定时间，让客户再进行一次思考，以免出现未经充分考虑而确认的结论。
好的开始，是成功的一半。让大厨安心做饭，让客户满意吃饭，是每一位服务员的终极目标。
