作為一名IT行業從業者，多年周旋在需求提出方（客戶）與需求實現方（程序員）之間，如何能夠確保程序實現的就是客戶想要的？最首要的就是要知道客戶究竟想要什么。

有一個網絡上流傳的段子：客戶去飯店，坐下來，對服務員：“服務員，給我來份宮保雞??！”，服務員爽快的答道：“好嘞”。接下來服務員跟大廚說：“做份宮保雞丁”，大廚趕緊開做，做了一半客戶又叫服務員“服務員，宮保雞丁不要放肉”，服務員驚詫的問“不放肉怎么做?。俊保蛻粽f“不放肉就行了，其他按正常程序做不就行了，難么？”

這個段子后續還有好幾集，上面引述的只是一個開始，在大廚做的過程中，不斷的增加、減少各種材料，導致一道菜總也做不出來，客戶就又開始催服務員，就這樣一個惡性循環開始了，好不容易做出了一道菜，客戶說不是想要的味道，這時大廚從廚房拿著一把刀出來了。程序員最怕的是什么？問君能有幾多愁，調完代碼改需求。

段子當然比較夸張，但也來源于事實。究竟逼瘋大廚的是什么？如果服務員能在大廚開始之前和客戶確認好到底客戶口中說的宮保雞丁是什么，也許大廚就不會在這一道菜上一直反復，浪費時間，客戶也可以得到滿意的菜品。所以在開始實施一個產品之前，確認好客戶需求至關重要。如何能讓客戶滿意，大廚不瘋呢？

聆聽

我們都曾以為聽對方說話是一件最容易的事情，但是卻會犯很多錯誤，比如以下幾個：

1、耳朵在聽，大腦在思考其他問題

雖然在聽著，但是大腦卻在想著其他問題，有時候是因為外界環境的打擾，比如突然有個即時消息需要回復，有時候是因為大腦自己無法集中注意力，比如談論當前需求的時候，還在想著上一個需求要怎么實現。不要相信自己的大腦是多核處理器，可以同時處理多項任務，關注當下，把耳朵輸入的信息放入大腦去思考。

2、以為自己理解了，急于下定論

這也是經常會犯的錯誤，有時候我們會高估自己的理解能力，以為自己理解了對方的意思，便打斷了對方，給出了自己的結論，這時候我們理解的也許只是表層的需求，便把表層的需求當成了真正的需求，真正的深層需求對方卻還沒有表述出來。

3、忽視對方的非語言信息

聽語言信息還不夠，有時候非語言信息反而更重要，比如語氣、態度、表情、手勢等等，這些可以表達出語言無法表達或者沒有表達出的信息，通過這些信息有時候可以判斷出需求的緊急或者重要程度。

因此，聆聽需要專注于當下，不僅專注于聽客戶所說的話，還要觀察其他非語言信息，并給予對方充分的表達空間，以達到真正理解的目的。

提問

提問就像考試出題者，基本上有三種題型，簡答題、選擇題、判斷題，在考場身經百戰的我們都有過考試的經歷，從答題難度上來排序，簡答題>選擇題>判斷題，而且對于判卷的人來說難度排序也是如此。比如拿確認一個會議或者約會時間來舉例：

簡答題：你什么時候有空？

選擇題：你明天上午或者今天下午什么時間方便？

判斷題：今天晚上你有空么？

簡答題屬于開放式問題，判斷提屬于封閉式問題，選擇題介于二者之間，如果答案在選項內容就是封閉式問題，如果答案不在選項內容，就會有出現一個新的開放式問題。

三類問題的提問順序也是循序漸進的，如果一上來就問判斷題，如果對方回答是，那可能會導致信息收集不全面，而導致遺漏重要信息，如果對方回答否，那可能要問很多個問題才能明確具體內容，而導致浪費時間。提問的問題類型順序會根據需求的逐漸清晰而越來越封閉，適當的時機選擇適當的問題類型去提問，直到最終找到對方想要的答案。

而開放式問題，雖然可以讓對方暢所欲言，讓我們得到更多的信息，討論的氛圍也更為輕松，但是容易在討論的過程中偏離主題，無邊蔓延，因此確認主題和范圍是是前提，在討論的過程中引導討論方向不偏離目標。

確認

理解了客戶的需求，還沒有結束，還需要做最后一步的確認。確認不僅僅是討論過程中的口頭確認，還要做好書面紀要，作為討論的交付物之一進行最后的確認，確認的過程需要留有一定時間，讓客戶再進行一次思考，以免出現未經充分考慮而確認的結論。

好的開始，是成功的一半。讓大廚安心做飯，讓客戶滿意吃飯，是每一位服務員的終極目標。