在整個研發過程中，需求方（通常是產品經理）與研發團隊之間的需求溝通是非常重要的一環，溝通效率的高低和溝通質量的好壞對交付結果有很大的影響。需求溝通的最重要目標是讓各方對需求形成一致的認識，然而這一目標并不容易達到。
據個人在所接觸的團隊中進行的非正式統計，由于需求溝通問題導致的線上缺陷占比從5% ~ 30%不等，由此造成的損失還是非常可觀的。而且低效的需求溝通對團隊士氣也有不小的影響。團隊非常容易陷入一些需求溝通的誤區，這直接導致了種種問題的發生。
常見誤區
●追求大而全的文檔
很多團隊需求溝通過程主要是基于需求文檔。如果產品、開發和測試各方對需求理解出現不一致，原因常常被歸結于文檔寫的不夠好，進而花更多的時間試圖讓文檔內容更詳盡，盡可能包含所有的細節，準備需求文檔的時間因而大大增加了。
然而據筆者觀察，這樣做通常并沒有產生明顯改觀。需求溝通的主要目標是各方對需求形成明確共識，雖然我們希望能夠有完美的文檔來解決溝通中的問題，但是僅僅靠文檔很難達到。完美的文檔對溝通來說并不“完美”，充分的面對面溝通是必須的。
另外，大而全的文檔很容易讓大家覺得既然文檔很全面照著做就好了，不再需要面對面的溝通，這樣會讓大家更加依賴文檔而輕視直接的溝通。往往讓情況變得更糟。
●不重視說清楚“為什么做”以及“為誰做”
在需求溝通過程中，需求背后的目的常常沒有傳達給開發和測試人員。需求方常常覺得只要告訴團隊做什么就夠了，至于為什么做大家知道了也沒有什么用。
但實際上，了解了“為什么做”對團隊的幫助是非常大的，只有真正理解了需求背后的目的才能準確把握需求。而且，只有真正清楚要往哪里去，團隊才能主動思考達到目的的最佳方式并付諸于行動。這在不清楚“為什么做”的團隊里是不會發生的。
另外，只有真正理解了目標用戶。也就是“為誰做”，才能做出用戶真正需要的產品。
●為減少時間浪費，盡可能減少參與溝通人數
在很多團隊眼里需求溝通是不產生價值的活動，參與的人數太多會浪費大家時間，所以通常在需求溝通活動中開發和測試只派代表參加，會后再由參加會議的人將需求轉述給真正做開發的人。
這個過程看似節省了部分人的時間，但是拉長了溝通鏈條，使得溝通過程中更容易產生各種信息丟失和扭曲，從而加劇了需求溝通的各種問題。
重新理解需求溝通
●文檔不代表共識
需求溝通的核心目標是各方形成一致的理解。然而文檔本身無論寫的多么的完善都不代表各方已經對需求形成了共識。并且主要依靠文檔來溝通也并不容易做到讓各方形成一致的理解。因為人類語言的復雜性，這個過程中有不少“坑”在等著我們：
●文字容易產生歧義
文字并非我們想象的那樣精確，請看下面兩個例子：
例一：新汽車牌照
可以解釋成“新汽車的牌照”，也可以解釋成“新的汽車牌照”
例二：他走了一個小時
可以解釋成“他離開了一個小時”，也可以解釋成“他走路走了一個小時”
●文字丟失了部分信息
下面這句話讀著沒什么特別：
我沒說過他寫了這段代碼
但如果說出來時，重音放在不同的部分則會表達出不同的信息。
我沒說過他寫了這段代碼
我沒說過他寫了這段代碼
我沒說過他寫了這段代碼
我沒說過他寫了這段代碼
我沒說過他寫了這段代碼
但是以文字的形式輸出這些文字時，這樣的信息就丟失了。
●“知識的詛咒”讓事情變得更糟
“知識的詛咒”，簡單說就是人們在溝通一件事時，會不自覺的假設別人對這件事和自己有一樣的了解，進而在解釋給別人的時候，因為信息不對等，很可能會無意識的遺漏一些重要信息，從而造成溝通的困難。當在陌生的地方問路時，就很容易體會到“知識的詛咒”。
●對“常識”理解的不一致也會帶來困擾
說到“小”瓶的可樂時你的腦海里浮現出的是哪一種？350毫升還是500毫升？對于“小瓶”這個常識，不同的人可能有不同的認識。
所以文檔其實很難做到對需求精確、全面、完整的描述，如果讀文檔的人理解出現偏差，那么各方對需求的理解就會出現不一致。也就是說文檔是無法保證各方理解一致，形成共識的。
如果追求大而全的文檔，花了大量時間卻達不到期望的溝通效果，而且容易使得需求文檔中充滿細節的堆砌，難以快速理解和分割。所以停止對完美文檔的追求是明智的做法。
需求溝通過程中主要靠文檔是不現實的，面對面密切的溝通在需求溝通中扮演的角色可能更加重要。
●文檔不能代替面對面溝通
前面講了這么多文檔在需求溝通過程中的局限性該如何解決呢？密切的對話溝通（最好是面對面）其實是應對這些問題的最有效手段。有效的對話可以不斷的讓需求涌現出來，確保盡可能的不遺漏。
下面模擬了團隊在電商書籍類促銷活動需求討論的對話過程：
對話過程可以讓參與者有機會通過復述和追問的方式反復從不同角度驗證自己的理解并不斷修正，大多數的需求理解差異在這一過程中可以得到消除。
另外，可視化的方式呈現需求也對需求理解和溝通有很大幫助。
●要有明確達成一致的驗收條件
在需求溝通過程中，要對需求理解達成一致需要有具體的可驗證的驗收條件，需求溝通完成的標志是各方對驗收條件達成一致。如果使用實例化需求這一實踐方法，形成驗收條件就比較容易了。
●需求要包含明確的目標和愿景
不了解需求背后目標的團隊相當于不知道前進的方向，只有了解了做一件事背后的目的，才能真正知道怎樣才算做好了。即使開始發生了偏差，也可以基于原本的目的，做出正確的判斷并進行修正，否則只能被動地按照需求本身的描述來實現，很難自主的、具有創造性的完成任務，這樣的團隊工作積極性通常也不會太高。
●知道為誰做很重要
需求到底是針對什么樣的用戶的？有時候這個問題的答案并不是那么顯而易見。不同的用戶需求很可能會有很大不同，這就需要需求方考慮清楚并清晰的傳達給團隊。
●溝通環節越多，失真越大
在需求溝通環節比較多的團隊中，通常溝通效率都不會太高，而且因為信息傳遞環節太多，有相當比例的問題源自于溝通過程中的信息丟失或扭曲。縮短溝通鏈條肯定是努力的方向。
一些有效實踐
●用戶故事
采用用戶故事來描述需求并以此為基礎進行需求溝通是敏捷開發中的一種做法。它的核心理念可以通過3C來描述：
卡片（Card）： 一般在小卡片上寫著故事的簡短描述，工作量估算等。
交談（Conversation）：背后的細節來源于和客戶或者產品負責人的交流溝通。
確認（Confirmation）：通過驗收測試確認用戶故事被正確完成。
其意在于通過簡化需求描述來鼓勵面對面直接交流，并對驗收條件達成一致的方式來實現更有效地需求溝通。
用戶故事的形式“作為……，我可以……，以便……”包含了我們剛才提到的需求的兩個重要方面：用戶和目的。
●追求快速反饋
即使需求溝通過程非常有效，還是會存在個別漏網之魚，這時“實現快速反饋”就成了補救的下一道重要防線，我們可以通過盡早實現可運行的功能，在進入測試和驗收環節中及時地反饋并修正錯誤。反饋越早，修正的代價越小。
●需求實例化
顧名思義就是用實例來說明需求。也就是從用戶場景出發，用操作實例來澄清需求。基于具體的實例非常有助于保證各方對需求理解的一致性。其基本形式是“在什么情形下什么操作會得到什么結果”。我們還是以電商書籍類促銷活動為例，下面用實例來描述“清華出版社購書免郵費優惠活動”這一需求：
可以看到，通過實例化讓需求的描述更加具體明確，更容易理解。再結合Cucumber、RobotFramework等工具就可以實現驗收測試的自動化了。
結語
需求溝通需要緊緊圍繞目標，即讓所有人對需求形成一致的認識。我們有各類溝通的手段：文檔、郵件、即時消息工具、電話或面對面交談等。這些手段各有各的優點，但要想達到需求溝通的目的，我們應該使用電話或面對面交談作為核心的溝通方式，其它方式也需要，但應該作為輔助手段。再結合本文提到的其它一些實踐方法，需求溝通便不再是一件痛苦的事！
本文作者
