敏捷開發的引爆點——過度溝通！

本文約2100字，建議閱讀5分鐘。

為什麼外企或國企的職業經理人空降創業公司多數都會折戟沉沙？十有八九是因為他們不懂「過度溝通」。在敏捷化的企業或團隊里更是如此，應對瞬息萬變的市場和業務需求，消除悶騷程序員和技術「小白」客戶間的鴻溝，力求產品做到最優，可以說唯一的方法就是時時地溝通，不斷地溝通，反覆地溝通，過度地溝通！

就像大話西遊里唐僧的經典台詞：

「你想要啊？悟空，你要是想要的話你就說嘛，你不說我怎麼知道你想要呢，雖然你很有誠意地看著我，可是你還是要跟我說你想要的。你真的想要嗎？那你就拿去吧！你不是真的想要吧？難道你真的想要嗎？……」

這段貌似搞笑的「廢話」，在敏捷開發中，卻是一條真理——溝通務必明確、透徹，窮盡所有疑問！寧可矯枉過正，不可閉門造車！

溝通！溝通！溝通！

敏捷開發多採用短迭代，要求儘快交付可以工作的軟體，所以項目的需求文檔就很難像原來的瀑布開發模式一樣面面俱到。這就要求我們多進行溝通以確保雙方的理解一致。根據以往很多項目的經驗來看，失敗的項目大多都是缺乏溝通，成功的項目必然是溝通做的比較好的。

敏捷開發中常見的溝通問題

你以為的不一定是你以為的

01

很多人做項目，拿到客戶需求以後，自己簡單看了看，然後就開始做了，等到做完一個迭代拿給客戶看時，完全不是客戶要的東西。這就像女朋友說喜歡吃水果，你不由分說就買了十斤香蕉送過去，因為你喜歡吃香蕉。結果被罵了，女朋友喜歡蘋果櫻桃火龍果……就是不喜歡香蕉。這都是對需求的理解比較片面，又不提前溝通，自以為是的後果。

不懂不好意思問

02

還有的人，尤其是新入團隊的人，客戶寫的東西或者說的需求，他沒有完全理解，但不敢問，總覺得客戶已經說過了，已經寫過了，再去問是不是不妥？顯得不專業，沒面子……如果按自己的理解或者猜測萬一對了呢？於是就碰運氣。事實上我們主觀的猜測常常都是錯誤的，尤其是在我們對項目沒有全面了解的情況下。想想你被女朋友罵過多少次？「女孩兒的心思你別猜」，對客戶也是一樣的。

拖延症

03

還有一種情況，就是我們自己發現了問題，需求上的，或者客戶的流程上的，但是我們總是想等到明天再溝通，明日復明日，其實內心希望這個問題自動消失，但最終的結果往往是滾雪球一樣，越來越嚴重。回憶一下分手的前女友，有沒有恍然大明白的感覺？問題是不可能自動消失的，發現問題要主！動！溝！通！

不敢對客戶說「no「

04

很多時候，我們都不敢對客戶說「no」。比如我們覺得客戶的需求太碎片化，UI改來改去，業務細節不夠明確，希望客戶能提供一個比較接近Final Design的設計，但是總覺得給客戶提意見不好，顯得對客戶不夠尊重，會影響滿意度和結賬「效率」。實際上我們提出問題和自己的想法才是對客戶最大的尊重，因為在項目中雙方利益是一致的，就是把結果做到最好。女朋友需要的是值得依靠的男友，而不是言聽計從的奴才，一味的順從換不來愛情！

溝通方法單一

05

我們很多人習慣了一種溝通方式，不管什麼問題都這一招，所有的問題都寫郵件或者所有的問題都用語音，這也是缺乏溝通效率的方式。約會、情書、電話粥、語言留言、啪啪啪……十八般武藝輪番用，絕對比你只會聊QQ好使。

敏捷開發的正確溝通方式

平等溝通的意識

首先，要樹立平等的意識，統一立場，統一戰線。敏捷項目里的溝通，不管是與客戶還是與團隊成員，大家都是平等的，溝通項目相關的問題都是平等的，應該把客戶當作自己團隊中的一員。客戶花了錢，目的只有一個——希望項目做好，雙方的目標利益是一致的。在此前提下，溝通應該知無不言，言無不盡，即便爭執都是溝通方式之一，所有不以把項目做到最優而藏著掖著「打死不說」的行為都是可恥的。

多種溝通方式結合

小平同志說： 「白貓黑貓，抓住老鼠就是好貓」，溝通也一樣。下面是常見的幾種溝通方式：

面聊

視頻

語音

IM文字溝通

郵件溝通

這幾種溝通方式的效率一般是由上到下遞減的。當我們與對方面對面的時候，根據對方的表情就可以看出他是否真的理解了我們的意圖。

在實踐中我們需要多種溝通方式的有效結合，比如離岸團隊面聊的機會比較少，可以用視頻和語音，但是視頻語音由於強調及時性，需要大家的時間都合適才行。而且視頻語音也有缺點，就是內容很難搜索，也較難在組內傳播。而IM文字溝通在這兩方面就體現出了優勢，有歷史記錄，可多人分享等。

郵件溝通的優勢是不需要客戶立即回復，而且可以圖文並茂加附件，給客戶更多的時間思考，格式化的文檔也更容易把一件事情描述清楚。

所以，我們在溝通的時候，要結合具體情況選擇最適合、最有效的方式，多快好省地把問題溝通清楚。

一圖勝千言

很多時候，圖形化的溝通非常重要，對項目的設計、架構如果開發人員難以達成統一的認識，就是缺乏圖形、設計圖或者架構圖。我們都知道，人對圖形的理解和記憶力要好於文字。

系統之間的交互，軟體如何部署，項目的架構封層等，這些用圖形來表示往往一頁紙就可以，而且大家都能一目了然。而只有別人對你的想法理解了，才能夠發現你的問題，才能給出建議。我覺得軟體項目，非常重要的兩張圖，一個是 Architecture Diagram, 一個是Use Case Diagram, 這兩張圖可以大大節省項目開發的溝通時間。

原型或者草圖

敏捷項目流行邊做邊改，我個人對此不太認可，因為客戶付錢是讓我們把事情做對，而不是把事情改對。那麼如何避免不斷修改？那就是先做一個原型，我說的原型是不需要花太多時間的，如果花太多時間就得不償失了，比如UI我們可以在開發之前先畫出Wireframe, 如果需要交互，我們可以先做交互的Prototype。現在有很多工具比如說Invision都可以建立靜態圖形之間的交互，這樣可以大大減少返工的可能性。

提出問題時盡量給出方案

很多人只問問題，導致客戶回復的很慢，因為客戶需要思考。然而有時候客戶思考後給我們的方案仍不適合，一來二去浪費了很多時間。

我們上學的時候都喜歡做判斷題，其次是選擇題，再次是填空題，最不想做的就是問答題。那麼將心比心，我們要想得到客戶的快速反饋，是不是也應該儘可能給客戶出比較容易做的題呢？

所以好的方法是，我們給客戶提問之前，先想想我們是不是有其他可行方案？或者我們有多個方案，只是不能確定用哪一個？很多時候，其實我們是有可選項的。

實踐證明，凡是我們提的方案被客戶採納的，自己做起來也更順手，也就更有效率。

敏捷之美∣這裡只有乾貨

感覺有用敬請關注，交流投稿後台留言。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！