幾個月前，公司委派我負責乙個難啃的骨頭式軟體開發專案。公司把我從一線開發設計組調到專案需求組，主要負責客戶需求調研、確認和溝通的管理工作。對於此項工作我原來認為壓力並不大，因為對於軟體開發的需求調研我可謂輕車熟路，加之自己有一線開發和設計的經驗，工作起來應該會是一帆風順的。但沒有想到的是才過了乙個月左右，我卻發現自己陷入了溝通管理的困境之中。
在我的多年開發經驗中，我深知道溝通不當不僅會造成需求失真，而且還會給專案帶來嚴重的成本損害，甚至會導致專案失敗。例如，如果需求在一開始就不明確，專案將會無可避免的面臨不斷的變更，從而導致工期滯後和成本倍增，並最終可能導致專案失敗。而且任何乙個需求分析上的錯誤，都將會在以後的專案工作中要付出50-100倍的代價來補償。因此，在專案的開始階段時，我先在專案需求組內召開了2次頭腦風暴會議，然後帶著問題到該客戶各部門進行實地調研需求。在經過艱苦的實地考察和了解後，總結出乙份詳細的需求調查報告。但是在開發組進行開發的乙個月後，客戶方又提出了對需求的重大更改。由於客戶堅持更改，開發組只好調整了開發計畫。在之後的6個月裡，由於客戶新的變更還是會不斷的提出，頻繁的需求變更最終使該軟體開發專案不得不以宣布專案失敗而收尾。
在總結和反思專案失敗的原因時，我意識到自己在處理需求溝通管理時犯了乙個很大的錯誤。按照一般的軟體開發專案規律，客戶方應該有乙個專案統一的介面人，開發方的需求調研組只需要與該客戶介面人交接和溝通就行。這樣不但可以避免與客戶方的多頭溝通，而且可以保證開發方的根本利益。但是本專案的客戶方根本就沒有乙個統一的專案介面人，使到我們專案需求組在涉及到需求確認或變更時，都需要和客戶方的多個部門進行不斷的溝通和確認。最慘的是這種多頭溝通不但沒有獲得客戶高層領導的認可，而且多頭溝通的結果往往是相互重複或相互矛盾的。在我意識到是自己陷入了與客戶溝通管理的泥潭之中時，但卻已經回天無力了。
一、什麼是開發專案的溝通管理泥潭？
軟體開發專案的失敗有很多是由於需求混亂和溝通不良造成的。簡單的說，就是溝通對於軟體開發專案來說有著特殊意義。在成功的專案中人們可能感受不到溝通所起的重要作用，但在失敗的專案反思中卻往往提到溝通不暢的危害，而且也往往把溝通不良作為是專案成功路上的最大攔路虎。因此，在軟體開發專案的需求調研中，有效的溝通管理顯得尤為重要。這是因為專案需求混亂和多頭溝通的原因也許有很多，但是這些問題往往是由於溝通管理不當所造成的。
（1）溝通介面管理不清晰，需求易呈現多樣性
在這個失敗的專案中，給我最大的經驗教訓是：如果專案的溝通介面管理不清晰，就會形成多頭溝通和多頭意見，導致許多該提出的需求反而未能得到有效提出，或提出了許多相互矛盾的需求。這裡所說的溝通介面管理包括雙方的溝通介面人員的責任管理，也包括雙方不同層面接觸時的溝通介面計畫的管理。
對於需求簡單的軟體開發專案來說，相對的與專案需求有關的部門和人員也只有幾個，直接溝通就很容易弄清楚真實需求。而對於相對複雜的開發專案來說，各部門和人員的需求也相對的複雜和繁多，而且可能都是緊密聯絡的，在流程上一環扣一環。當任何乙個環節出現問題時都將影響到其它子專案需求的實現，也可能導致整個專案的失敗。而且，子專案需求越多，需求的相互影響就越複雜。
（2）溝通傳遞層次太多，是深陷溝通泥潭的主因
在這個專案的需求調研中，客戶方的組織結構對溝通效果影響之大也是我之前所沒有想到的，這也是陷入需求溝通泥潭的重要原因之一。由於客戶的組織機構過於龐大，中間層次太多，使到需求資訊從最高決策層下達到下屬部門時不僅容易產生資訊失真，而且還會浪費大量時間。同時，自下而上的資訊上傳時由於中間層次過多，同樣也容易產生失真和影響效率。
曾有學者統計，如果乙個資訊在高層管理者那裡的正確性是100%，到了資訊的最終接受者手裡可能只剩下20%的正確性。這是因為在進行資訊溝通時，各級主管部門都會把接受到的資訊先自己進行甄別，一層一層的過濾，然後有可能斷章取義的將資訊上報或下傳。此外，在甄選過程中還會摻雜了大量的主觀因素，尤其是當資訊涉及到傳遞者本身利益時，往往會由於心理原因造成資訊失真。因此，當組織機構臃腫時，特別容易形成多頭溝通泥潭，而且會嚴重的影響著有效溝通的進行。這種資訊傳遞失真在專案宣布失敗前的需求變更時，和在尋找需求傳遞失真責任時特別明顯，這是我在這個專案中得到的最寶貴經驗之一。
（3）缺乏文字形式的溝通會成為紛爭的根源
利用口語面對面的進行溝通是需求調研時最常用的形式，但調研人員必須要把資訊以書面的形式進行保留，如以報告、備忘錄、信函等文字形式把口語進行記錄。因為我現在明白到，這是避免專案需求頻繁變更的關鍵乙個步驟和動作。
（4）缺乏溝通計畫保障，需求目標容易走樣
需求的真實性固然重要，但我們應該明白需求調研不僅僅只是一種獲得資訊真實性的溝通，而且是一種有計畫、有目標和有方向性的溝通。因此，要想獲得有效的溝通效果必須有計畫和有方向來保證。因此，單純的鼓勵溝通的真實性是不夠的，因為等級和權力的差別肯定會形成溝通阻礙。所以，當專案缺乏一套有效的溝通計畫時，調研需求的方向性就容易得不到保證。因為對於單一需求的開發專案來說，需求的方向性是簡單、直接、明確的；而對於需求複雜的開發專案來說，由於每個獨特的專案都有其不同的目標和不同的需求方向，也就決定了專案需求容易走樣。而也正因為目標需求容易走樣，不但容易導致後期需求頻繁的變更，也會導致需求確認的難度和複雜度都將大大增加。
二、避免陷入溝通管理不良泥潭的策略
所謂溝通，是人與人之間的思想和資訊的交換，是將資訊由乙個人傳達給另乙個人的過程。溝通看似簡單，但溝通管理不良幾乎是每個軟體開發專案都存在的**病。專案需求越是複雜，其溝通越是困難。往往基層的許多需求還未反饋至調研人員手中便已被層層扼殺，或是需求經過層層的傳達後常常無法以原貌展現在需求調研人員面前。因此，如何避免需求溝通不良是軟體開發專案管理的重中之重。
（1）成立乙個需求決策小組
溝通的目的是為了調研和確認需求，因此在溝通管理上不應該本末倒置。在此專案失敗經過反思後，我認為應該要在專案需求調研之前，要召集乙個雙方高層的會議。讓客戶方和開發方高層都參加，在會議中重申專案需求的重要性，並要求成立乙個需求決策小組。這樣當遇到多頭溝通懸而不決的問題時，提交給專案需求決策小組討論並決策。這樣單一清楚的專案決策人或決策小組不但可以實現專案需求的溝通本質，也是成功專案運作的基礎。需求決策小組最好由開發組高層和客戶方領導層組成。這不但是避免需求頻繁變更的關鍵一步，也是我在總結溝通管理時認為最重要的事情之一。
（2）明確客戶方需求溝通介面人員
如果在專案開發合同簽訂時未明確客戶方對本專案的具體溝通負責人，那麼最迫切的就是要先向客戶方領導強調客戶方要馬上組織乙個團隊並指定乙個負責人來管理，這個問題關係到整個專案的成敗與否。對這個團隊的要求是要有將來真正使用系統的業務專家，要有將來真正對這個系統實施管理的人，要有將來真正對這個系統實施維護的人（技術專家）。還要有乙個溝通介面負責人，這個人要可以幫助協調客戶方相關人員並可以代表客戶方確認和簽署該項目的相關文件。否則，當缺乏明確的溝通介面人員時就會埋下很大的風險，陷入溝通管理不良問題也就不可避免了。
（3）制定明確的溝通計畫，提公升溝通效率和責任
一般來說，專案需求階段的工作一般都是自上而下、然後再自下而上的。怎麼理解這個說法呢？這是因為開發專案一般會涉及到企業內部管理流程，這就需要有客戶高層領導牽頭，而且領導對於上這種軟體專案都會有個期望，比如提高部門協作效率、減少流程對接中的失誤等等。因此，需求調研首先要制定明確的溝通計畫，方便與客戶方領導建立聯絡，深入領會客戶方領導的意圖，然後按照領導的意圖去與各個部門溝通；最後把各個部門的需求再整理、再加工，反饋給客戶方領導。這麼做的好處是：第一是借客戶領導的要求和關注可以讓客戶下屬部門很好的配合，提公升溝通的效率；第二是避免客戶方部門間責任的相互推諉，從而造成專案需求重複、邏輯衝突和相互矛盾。
（4）溝通應該是雙向的，且必須保證被正確理解
需求調研的本質在於資訊傳遞，因此要進行有效的溝通管理，必須要在資訊傳遞上下功夫。溝通必須是雙向的，這就要求溝通方式必須要有反饋機制，而且在資訊收到後還必須保證理解是正確的。在許多失敗的開發專案中，我們經常看到的是資訊是傳達到了，但卻被錯誤的理解了，產生了大量的扯皮問題。總結這次的專案需求溝通失敗，我認為在需求調研後接收方需要確認自己理解了的同時還要再去細化或轉敘需求，但不是複述需求。說得直白些，就是要求需求調研人員說明具體明白了哪些，並讓資訊傳送者進行確認。
（5）雙方簽署需求確認檔案
最後，在需求調研後，調研人員應對客戶的需求進行整理和確認，列出詳細的需求清單。並請求客戶方正式的簽字蓋章確認，可將該清單作為合同附件留存。這樣可避免雙方在專案需求上扯皮，不但是避免需求頻繁變更的依據，也是保證軟體開發專案能順利完成的關鍵一步。
軟體開發中的老問題 溝通
軟體開發中的老問題 溝通 在軟體開發中有這樣的乙個法則 brook 法則 向進度落後的專案中增加人手，只會使進度更加落後。我們經常可以聽到 1 1 2 的說法，但從這個法則中可以知道，在軟體開發中 加 1是小於 的，甚至是小於 1的，這是為什麼呢？其中主要的原因就是溝通，專案開發人員之間的相互溝通產...
軟體開發專案管理的3721
1.權力 作為乙個專案經理，你需要獲得授權，否則你很難推行你的計畫。權力主要來自於你上司的信任，從上司那裡獲得管理，評價和獎勵你組員的權力。同時，自身的專長 技能何知識，為人處世的風格，以及你自己的人格魅力都是權力的 2.專案金三角 專案中首先關注的是專案金三角，由三個邊組成，他們是專案的目標 資源...
軟體開發的風險管理 之二
這篇文章準備講講風險管理的一些基本原則和應對方法 首先總結一下我在我們專案中遇到的風險以及應對方法 風險名稱 風險描述 發生概率 影響應對方案 例子其他 人員風險 專案人員的能力與專案的要求之間的差距 專案人員的流動低高 1，對於重要的專案，選用能力強的開發人員 2，引入高階開發人員對設計和 的re...