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