淺談IT行業與客戶溝通的技巧

二十一世紀是信息社會的世紀，而IT行業作為信息社會的代表性行業，更是充當著排頭兵與先鋒隊的角色代表作用。在IT行業，我從業13年，期間曾擔任過需求調研員、軟件開發員、系統分析員等職務。下邊我就結合自己的實際經驗，談一下IT企業軟件開發過程中需求調研階段與客戶進行各種溝通的技巧。

我們知道成功的軟件產品是建立在成功的需求基礎之上的，而高質量的需求則來源于用戶與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開始幫助用戶解決這個問題的時候，溝通就開始了。而需求獲取階段可能是軟件開發中最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要把相關問題問到，了解到什么樣的軟件能滿足用戶的需要就可以了，但是實際上需求獲取并不是想象的這樣簡單。

正確的需求調研之路我認為應首先要定義獲取問題的范圍，即準確定位用戶需要什么，用戶要通過我們的軟件，我們的系統實現什么，最終通過輸入輸出獲取什么樣的結果，有什么樣的界線。系統的邊界往往是很難明確的，而用戶往往又不了解或者不愿意了解我們具體技術實現的細節，這樣如果我們的調研人員自身再忽略相關界限問題，就很容易造成系統目標的混淆，從而導致最后我們的軟件開發出來之后和用戶想象的差別很大。

其次是對問題的理解，目前國內很多非計算機專業用戶對計算機系統的能力和限制可以說還是缺乏了解的，很多用戶只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎么樣工作效率更好，也不太清楚哪些工作可以交給軟件完成，他們不清楚需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認為是“很明顯”的信息。最終對我們的軟件開發出來的成果造成致命性的打擊和傷害。

最后是需求的確認，因為需求的不穩定性，往往隨著時間的推移用戶會不斷產生新的變動和新的需求，使之難以確認。在軟件開發的后期，甚至實施階段，隨著信息化項目的應用及開展，對用戶實際業務操作產生的影響越來越深入，用戶必將不斷有新的業務需求提出。開發人員常常有應接不暇的感覺。為避免此類問題的發生，必須有組織地執行需求的獲取及確認活動。

針對上述問題，我們與客戶溝通應掌握如下技巧：

1.在與客戶完全溝通前，做好充分相關準備

軟件系統的需求包括四個不同的層次：業務需求、用戶需求和功能需求、非功能性需求。業務需求說明了提供給用戶新系統的最初利益，反映了組織機構或用戶對系統、產品最基本的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。非功能性需求是用戶對系統良好運作提出的期望，包括了易用性、反應速度、容錯性、健壯性等質量屬性。需求獲取就是根據系統業務需求去獲得系統用戶需求，然后通過需求分析得到系統的功能需求和非功能需求。我們在與客戶進行溝通前，應圍繞系統的業務需求及用戶需求準備相關詳細的項目視圖、范圍文檔及方案腳本。在初步的溝通中，為用戶提供明確的軟件功能界限、項目功能規劃。

2.站在用戶的角度設計問題、理解問題

通常用戶和開發人員不自覺地都有一種“我們和他們”的想法，產生一種對立關系，把彼此放在對立面，每一方都定義自己的“邊界”，只想自己的利益而忽略對方的想法。他們通過對話、談判來溝通，而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這樣的方法是不正確的，不會給雙方帶來一點益處，良好的溝通關系沒有建立，會導致誤解和忽略重要的信息。只有當雙方參與者都明白要成功自己需要什么，同時也知道要成功對方需要什么時，才能建立起一種合作關系。

為了建立合作關系通常采取一種組隊的方式來獲取需求，建立一個由用戶代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以采用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意以下原則：小組會議用戶和開發人員都要參加；交流預先要確定準備和參與的規則；議題要明確并覆蓋所有關鍵點，但信息來源應該自由；交流目標要明確，并告知所有的成員。記得我在一家公司時，單位主要從事縣級供電局營銷及生產信息管理系統（Mis）的開發，項目調研開始階段，因為沒有對調研內容、溝通方式等進行充分準備，項目調研人員到達現場后，一直存在著與客戶的對立局面。客戶因長期從事基層手工用電營銷工作，已習慣手工計算、存儲及信息交流方式，對于計算機信息系統不太認可也不相信。部分業務操作人員甚至存在消極抵觸情緒。在充分認識到溝通的必要性后，我方現場調研人員主動深入一線與相關用戶接觸，并通過windows使用技巧介紹、office操作培訓等方式與用戶建立了較為良好的溝通互動關系，通過操作系統、常用辦公系統軟件的培訓、介紹和推廣，讓用戶充分認識到了借助于計算機信息系統取代以往手工方式的方便性和安全性，完全站在用戶的角度最終讓用戶接受了該套營銷管理軟件的管理方式，順利完成了項目的調研工作。

3.需求的檢查、確認及重用

在軟件開發的過程中，常常存在著這樣的問題：隨著信息化系統的逐步普及，以及客戶在系統試運行及正式運行過程中，對電腦應用知識、操作水平的提高，必然會對原始提出的需求，有新增或者是反復要求。還是以上面縣級供電企業營銷管理Mis軟件為例，現場調研結束后，我們的團隊轉入開發，當時分了三個比較大的模塊，因開發力量有限，三個模塊沒有并行開始，而是采用先后開發的順序完成。這樣在第一個模塊開發及內部測試完成后，第二個模塊轉入開發過程中，第一個模塊已經開始交付客戶試運行。當時想著沒有太大問題，項目組的主要核心力量也都集中在公司本部進行第二模塊的開發工作，只安排了幾個人員去用戶現場實施。但很快，整個情況就發生了較大的逆轉：現場實施人員除了有少量系統BUG修改外，不斷有大量的用戶新需求及二次開發任務反饋，造成項目后期，項目組的大部分人員都在疲于解決第一模塊的更新替代工作，項目的后續模塊工期嚴重滯后，給整個項目的實施與完成帶來了較大的損失。

之后我們進行了分析，最終得出問題的關鍵所在，還是需求調研中與客戶的溝通問題。項目初步啟動時，用戶方受環境、業務操作習慣等客觀因素影響，對整個信息化乃至計算機處于啟蒙階段。對于希望能夠借助于計算機信息系統實現的功能目標、完成狀況，由于受到對整個電腦、網絡知識欠缺的制約，需求的提出和實際的需求存在著較大的差距，而現場調研人員未充分認識到這一情況，在將用戶的調研情況轉變為信息系統的需求時存在著嚴重的縮水。開發出來的東西，經過一段時間的試用及熟悉后，用戶勢必會提出來更多更新的要求，這些要求對于用戶而言是無可厚非，但最終造成了上述問題，后期開發所有項目組人員都在疲于奔命解決這些問題，嚴重影響了工期。

認識到上述問題后，在第二階段的需求調研過程中，我們著重要求了現場調研人員對上述問題的重視。在與客戶的溝通中，著力加強了需求信息的統計、歸總及檢查確認工作。其中確認工作必須有紙質文件及調研雙方人員簽字認可。有效的界定了項目開發的范圍，對后期的變動進行了有效的控制。同時在項目開發、內部測試及試運行準備過程中，仍不斷與客戶溝通，隨時獲取最新的變化動態與資料。保證開發始終是在一條有利于雙方的正軌上進行。按照上述方法，項目第二階段的幾大模塊均順利得到了實施，按時保質地完成了任務。

最后，談一下需求信息的重用，這個重用，不僅僅是對客戶要求、軟件實現功能的重用。更為重要的，則是現場調研人員與各階層客戶、相關業務操作者、利益管理者等進行有效溝通的實踐經驗的重用。

參考文獻：

[1]百度百科

[2]蟲師.軟件的需求分析如何做？http://www.ltesting.net，2012-1-20

[3]如何能夠讀懂需求？http://www.ltesting.net，2012-2-23

[4]Ivar Jacobson，James Rumbaugh，Grady Boochu著.《統一軟件開發過程》.周伯生譯.機械工業出版社，2002.1