從真實案例出發：如何在協作開發中避免誤解！

　　本文作者Dmitriy Kharchenko是一家烏克蘭軟體開發公司Acceptic Ltd的CEO。該公司的核心運營專案包括建立複雜的客戶端App，專注於為開發者團隊提供專業服務。在本文中，主要講述在軟體開發專案裡，專案經理--開發者--測試者--客戶之間的微妙而又重要的關係。產品的質量需要開發團隊和客戶雙方協作才能完成。（以下是編譯內容）

　　經常遇到在軟體開發裡各種各樣的誤解所導致的奇怪事情。不過說來也很費解：對於這樣不正常的待遇，盡然很少有人提出質疑，也沒有人問開發者是什麼導致了誤解和交流上的障礙。可能大部分人都覺得問這樣的問題為時已晚或者沒人關心這樣的問題。所以，跟蹤調查軟體開發裡開發者之間引起誤解的來龍去脈是一件很有趣的事情。

　　因此，下面就圍繞對開發者和專案經理的採訪來探討在開發專案裡導致誤解的普遍性原因所在。根據這些經驗豐富的IT技術人員所說的，一起來學習並避免這樣的事情出現在自己的開發團隊裡。

　　和客戶端：交流沒有最多，只有更多。

　　文件和記錄

　　能夠說客戶的語言並理解客戶的意思其實是特別重要的，理解不一致難免會出現問題。比如：因為語言不一致，導致雙方的程式設計師在技術層面上無法完全理解使用說明規範。

　　有的時候客戶拒絕編寫任何文件也會引起開發者的誤解。因為我們的開發團隊要對產品的功能性進行多個測試、評估，還要不斷地多次重寫功能程式碼，團隊裡每個人對產品功能都有自己的見解，因此，花費在迷茫上的時間不在少數。其次，沒有功能說明書的前提下測試人員也很束手無策，根本不瞭解這些功能是怎樣執行的，也沒有文件可參考。這些都難免會引起誤解。

　　另一個產生誤解的源頭是資訊不完全。例如：客戶和開發團隊的成員交流產品細節，客戶希望開發人員將資料分類，而不是在Skype上進行群組交流。有經驗的人都會知道，客戶在和開發者之間的誤解肯定會涉及到工作完成的標準與否。這也就是為什麼有人覺得定價的服務專案對雙方都不利。因為它是不可能將所有可能的產品描述寫入產品驗證的。對於這類問題，解決辦法總是有的。

　　信任、開放的態度

　　當客戶不信任開發團隊的時候，採取閉門會議、給出一小部分資訊的話，那障礙就會出現，最終的結果只能是重寫程式碼，重設架構。在一個團隊裡，如果沒有信心，即使是正常的開放式交流也對高效率和創新性毫無裨益。沒有一個團隊會把於己無關的專案放在心上。有的時候，客戶只給出模糊不清的需求，任何人都可以想象得到，開發團隊為了獲得更詳細的資訊多多少少都會和客戶產生一點小分歧乃至是小衝突，直至造成更大的誤解。

　　目標清晰、詳細闡述

　　當交流程式失敗了，只能面對下面的情形：

• 客戶會給出一個評估任務並找到一個實現方法，但團隊開始開發而不是僅僅傳送一個報告而已。
• 開發團隊在實現階段也要和客戶進行協作，可能會出現的情況是客戶根本不選擇你所提供的解決方案。
• 有的時候開發者開始處理一個指定的bug，即使嚴重的功能改變可以保證效能的提升，但是客戶還是不同意你的做法。

　　個人認為，誤解的出現主要是對問題沒有做充分的討論，懶惰、時間緊、外語障礙都是阻止尋求建議的主要因素。所以，解決誤解的關鍵就是不管什麼事都要和你的團隊、專案經理、客戶進行討論。

　　及時反饋資訊

　　有時候客戶不重視使用者評論，或者是忘記將這些使用者評論傳遞給開發團隊，這也就導致開發者沒辦法即使關注產品的反饋資訊。誤解就這樣產生了——因為在專案結束之後，客戶需要重新開發/調整專案，是的雙方都不是很滿意。

　　不同的加班理念

　　也許客戶和開發團隊在加班這件事上會存在理念上的不同，客戶需要開發團隊在沒有真正必要性的事情上加班，例如：

• 客戶：在產品釋出之前，我們每週都會加班一次，所以希望開發團隊也儘可能的抓緊時間按時完成任務。
• 開發：長時間的加班會打擊團隊的積極性，降低工作效率。

　　對於加班這樣的誤解，最簡單實效的辦法就是雙方之間做出真誠的協商，給對方吃一顆定心丸：絕不會延緩程式、影響產品質量。

　　小結

　　交流，交流，再交流，而且是雙向交流！客戶儘可能多的列舉細節，開發團隊得到的完整而清晰的資訊有助於更好的理解專案的目標，對專案的圓滿完成不無益處。通常情況下，為開發團隊提供全面的反饋資訊，也不濫用不必要的加班時間，有利於雙方創造一個和睦的工作氛圍。

　　團隊VS.專案經理

　　在有的開發團隊裡專案經理根本不會就客戶的需求去和團隊進行有效的溝通。例如，有可能會出現這樣的情形：專案經理在和客戶主導一個討論會議，而團隊裡的主要人員卻在蠻幹，這就是為什麼資訊最終不能被團隊全面接收的原因。

　　首先呢，交流誤解出現在專案經理和他的團隊之間，這的確是一個讓人失望的案例，因為專案的日程安排、截止日期、和客戶的資訊傳遞都是由專案經理定義的，目前這樣的問題帶有個人原因，所以解決方法就是專案經理需要更多的自我反思，尋求出路。

　　小結

　　努力遵循敏捷開發的方法，千萬不要忽略常識和人性特點。

　　開發者VS.測試員

　　世上沒有相同的兩個東西，所以出現在開發團隊和測試團隊之間的誤解，大部分是原因是需求過於模糊。為了克服這樣的難點，建議兩個團隊需要加強更加緊密的協作：

• 在文件開發過程裡
• 在架構/資料庫工程裡使用QA環節
• 在測試案例開發中邀請開發人員加入

　　通常情況下，在開發專案裡任何形式的誤解都是一個大麻煩。它可能是缺乏良好的管理、缺乏團隊建設、失效的軟體開發方法、未定義標準等等。每個交流誤解案例都應該仔細分析，並單獨處理。

　　小結

　　在開發者和測試者之間的誤解代價是最高的，所以避免這樣的誤解需要雙方之間透明工作細節以及有規律的重新整理文件，或者是雙方之間更親密、永久性的交流溝通。尤其是在專案計劃的後期。除此之外，開發團隊必須清晰地意識到QA環節的重要性，還要考慮到和測試者是一個整體團隊，對產品負有共同的責任。

　　溝通工具：語音聊天工具（Skype）VS. E-mail

　　考慮到敏捷開發方法裡所追求的速度與效率，E-mail的特點是有較高的延遲性，所以不可取。所以對於集思廣益的討論需要向Skype或其他的多媒體工具。但是，我建議專案經理能夠鼓勵開發者多寫郵件，這樣可以鍛鍊他們用一個乾淨和簡潔的方式表達自己的想法，所以很多事情通過他們的郵件就可以解決了。不過在開始Skype會議之前最好是通過E-mail將要討論的話題發給大家，包括客戶。

　　毫無疑問Skype能夠確保即時溝通緊急情況/議題，而E-mail是儲存歷史記錄的最好工具。這兩個溝通工具各有利弊，只需要遵循合理的使用，減少團隊誤解機率是毋庸置疑的。

　　總結

　　在軟體開發專案裡，對於交流標準需要強調五條規則：

• 每個環節都要溝通：業務計劃、專案目標、財務問題、交付模型等等。每一個技術效能都要徹底的討論。如果你想呈現什麼樣的想法，那就通過E-mail文件的方式來證明它。
• 個性化你的工作。和團隊成員交流的時候儘量鼓勵大家表現出自己真實的一面，這樣有助於激發隊員的創造力，做出更出色完美的結果。
• 持續提供反饋。反饋資訊就相當於一面鏡子，時刻反映工作成果的好壞。作為專案經理，一定要避免一個現象，那就是責怪隊員，因為所有的人都只有一個目標——好產品。
• 在問題變質之前解決它。突出強調你很想知道擺在面前的所有狹窄的地帶。鼓勵大家提出疑問！
• 使用E-mail解決真正重要的問題，這樣有助於避免在無關緊要會議上浪費開發者和自己的時間。

　　作為一名工作經驗豐富的管理者，希望以上的內容對IT工作者有用。

　　原文：Acceptic