幾個月前，公司委派我負責一個難啃的骨頭式軟件開發(fā)項目。公司把我從一線開發(fā)設計組調到項目需求組，主要負責客戶需求調研、確認和溝通的管理工作。對于此項工作我原來認為壓力并不大，因為對于軟件開發(fā)的需求調研我可謂輕車熟路，加之自己有一線開發(fā)和設計的經驗，工作起來應該會是一帆風順的。但沒有想到的是才過了一個月左右，我卻發(fā)現自己陷入了溝通管理的困境之中。

　　在我的多年開發(fā)經驗中，我深知道溝通不當不僅會造成需求失真，而且還會給項目帶來嚴重的成本損害，甚至會導致項目失敗。例如，如果需求在一開始不明確，項目將會無可避免的面臨不斷的變更，從而導致工期滯后和成本倍增，并終可能導致項目失敗。而且任何一個需求分析上的錯誤，都將會在以后的項目工作中要付出50-100倍的代價來補償。因此，在項目的開始階段時，我先在項目需求組內召開了2次頭腦風暴會議，然后帶著問題到該客戶各部門進行實地調研需求。在經過艱苦的實地考察和了解后，總結出一份詳細的需求調查報告。但是在開發(fā)組進行開發(fā)的一個月后，客戶方又提出了對需求的重大更改。由于客戶堅持更改，開發(fā)組只好調整了開發(fā)計劃。在之后的6個月里，由于客戶新的變更還是會不斷的提出，頻繁的需求變更終使該軟件開發(fā)項目不得不以宣布項目失敗而收尾。

　　在總結和反思項目失敗的原因時，我意識到自己在處理需求溝通管理時犯了一個很大的錯誤。按照一般的軟件開發(fā)項目規(guī)律，客戶方應該有一個項目統(tǒng)一的接口人，開發(fā)方的需求調研組只需要與該客戶接口人交接和溝通行。這樣不但可以避免與客戶方的多頭溝通，而且可以保證開發(fā)方的根本利益。但是本項目的客戶方根本沒有一個統(tǒng)一的項目接口人，使到我們項目需求組在涉及到需求確認或變更時，都需要和客戶方的多個部門進行不斷的溝通和確認。慘的是這種多頭溝通不但沒有獲得客戶高層領導的認可，而且多頭溝通的結果往往是相互重復或相互矛盾的。在我意識到是自己陷入了與客戶溝通管理的泥潭之中時，但卻已經回天無力了。

　　一. 什么是開發(fā)項目的溝通管理泥潭?

　　軟件開發(fā)項目的失敗有很多是由于需求混亂和溝通不良造成的。簡單的說，是溝通對于軟件開發(fā)項目來說有著特殊意義。在成功的項目中人們可能感受不到溝通所起的重要作用，但在失敗的項目反思中卻往往提到溝通不暢的危害，而且也往往把溝通不良作為是項目成功路上的大攔路虎。因此，在軟件開發(fā)項目的需求調研中，有效的溝通管理顯得尤為重要。這是因為項目需求混亂和多頭溝通的原因也許有很多，但是這些問題往往是由于溝通管理不當所造成的。

　　(1)溝通接口管理不清晰，需求易呈現多樣性

　　在這個失敗的項目中，給我大的經驗教訓是：如果項目的溝通接口管理不清晰，會形成多頭溝通和多頭意見，導致許多該提出的需求反而未能得到有效提出，或提出了許多相互矛盾的需求。這里所說的溝通接口管理包括雙方的溝通接口人員的責任管理，也包括雙方不同層面接觸時的溝通接口計劃的管理。

　　對于需求簡單的軟件開發(fā)項目來說，相對的與項目需求有關的部門和人員也只有幾個，直接溝通很容易弄清楚真實需求。而對于相對復雜的開發(fā)項目來說，各部門和人員的需求也相對的復雜和繁多，而且可能都是緊密聯系的，在流程上一環(huán)扣一環(huán)。當任何一個環(huán)節(jié)出現問題時都將影響到其它子項目需求的實現，也可能導致整個項目的失敗。而且，子項目需求越多，需求的相互影響越復雜。

　　(2)溝通傳遞層次太多，是深陷溝通泥潭的主因

　　在這個項目的需求調研中，客戶方的組織結構對溝通效果影響之大也是我之前所沒有想到的，這也是陷入需求溝通泥潭的重要原因
之一。由于客戶的組織機構過于龐大，中間層次太多，使到需求信息從高決策層下達到下屬部門時不僅容易產生信息失真，而且還會浪費大量時間。同時，自下而上的信息上傳時由于中間層次過多，同樣也容易產生失真和影響效率。

　　曾有學者統(tǒng)計，如果一個信息在高層管理者那里的正確性是，到了信息的終接受者手里可能只剩下20%的正確性。這是因為在進行信息溝通時，各級主管部門都會把接受到的信息先自己進行甄別，一層一層的過濾，然后有可能斷章取義的將信息上報或下傳。此外，在甄選過程中還會摻雜了大量的主觀因素，尤其是當信息涉及到傳遞者本身利益時，往往會由于心理原因造成信息失真。因此，當組織機構臃腫時，特別容易形成多頭溝通泥潭，而且會嚴重的影響著有效溝通的進行。這種信息傳遞失真在項目宣布失敗前的需求變更時，和在尋找需求傳遞失真責任時特別明顯，這是我在這個項目中得到的寶貴經驗之一。

　　(3)缺乏文字形式的溝通會成為紛爭的根源

　　利用口語面對面的進行溝通是需求調研時常用的形式，但調研人員必須要把信息以書面的形式進行保留，如以報告、備忘錄、信函等文字形式把口語進行記錄。因為我現在明白到，這是避免項目需求頻繁變更的關鍵一個步驟和動作。