工程專案的需求調研階段的工作非常重要，但很多專案經理卻沒有引起足夠的重視，需求調研階段的很多風險沒有很好的防範，導致專案在中後期需求變 更頻繁，結果是專案延期和客戶滿意度的下降。其實這些風險是可以在需求調研階段進行很好的防範的，本文從需求調研的各個工作環節進行分解和分析，提出了需 求調研階段的風險防範方法供專案經理和專案實施人員參考…
很多軟體工程專案的專案經理總是這樣抱怨：現在的使用者水平太低了，根本不懂什麼是軟體、什麼是gis！使用者的需求總是在不停的變化，我們累死 了，專案怎麼能按時完成？我們再來聽聽客戶的抱怨：我為什麼要懂軟體，我只需要在業務上做到最棒就可以了，我已經把我的想法和專案組說了，專案組的人對業 務太陌生了，我得到的系統不是我想要的！
專案經理的抱怨從表面上看是完全正確的，但認真分析一下，站在專案經理要為用 戶提供專業服務這個角度來講，出現這種狀況，專案經理有著不可推卸責任，客戶是無辜的！這裡我借用影響力集團董事長易發久先生的《成功的21個信念》中的 信念之二：「我是一切的根源」來分析一下這個問題。首先我們自問一下：我做的夠好嗎？表面上是客戶讓專案組很難過關，其實專案中的風險是專案經理沒有把握 好最終變成了問題，是自己將自己置於高風險的境地！有的人可能不同意我的觀點，但是我問大家乙個問題：難道讓客戶來為專案經理防範專案中的風險嗎？專案組 提供的服務不好難道客戶就要違心的接受嗎？
其實我們在中國從事gis軟體工程專案，其大環境是已經確定的，比如使用者it基礎 比較差、具有計算機專業水平的人的人員很少、使用者業務忙、使用者不願意簽字等等。特別是我們承接了乙個專案後，客戶能提供的條件和人員素質就更加確定，現實 情況是非常不容樂觀的。那公司既然簽定了合同並且確定要做，那專案組的職責是完成這個專案，完成公司交給我們的任務。要改變這個現狀，我認為首先要停止抱 怨，然後從專案經理和專案團隊自身來分析問題。
我們來梳理一下軟體工程專案需求調研的過程。之所以選擇專案前期的需求調研階段，是因為專案開頭很重要，如果專案需求階段情況就很好，後邊專案開發工作也就比較容易一些，這也是印證一句古話——萬事開頭難。
我訪問過很多專案經理，問需求調研該怎麼做？大部分的專案經理的回答可以總結為「搞個調研計畫，和客戶確認一下，然後去訪談，最後寫需求分析報告和需求規格說明書」。這個過程確實沒有錯，但是往下繼續問還要注意什麼，很多專案經理談不出來更多的細節。
其實我發現「細節決定成敗」在需求調研階段體現的最為淋漓盡致，因為很多細節部分隱藏著巨大的風險。我們考慮一下在需求調研階段還需要注意什麼問題，大致如下：
(1) 我們去調研的人的專業素質和溝通能力是否能勝任調研工作，是否對專案組成員進行了必要的培訓？
(2) 被調研的人是否在溝通之後選擇了最佳的被調研人員？
(3) 是否有正規的調研記錄並要求客戶簽字？
(4) 是否有切實有效的方法來啟發使用者能夠準確的表達出他們的需求？
(5) 是否對客戶進行足夠的宣傳，讓所有的系統使用者物件都能夠有機會準備並把自己的想法表達出來？
(6) ……
為了更好的規避需求調研階段給專案帶來的風險，需求調研應該重點做好以下幾點：
(1) 按照規範的需求調研流程開展工作
前面已經提到了需求調研的流程框架，大致為「調研計畫——調研訪談 ——需求報告和需求規格說明書的編寫」。但是在實際的工作的時，需要將這每乙個過程細化，比如需求調研計畫必須考慮：雙方合適的調研計畫、幫助使用者選擇合 適的訪談人員、專案組的人員分工、專案組的人員培訓、對調研專案的深度研討、準備合適的案例或相關的介紹資料等工作。形式不是最重要的，你可以制定乙個詳 細的流程並畫出圖來，也可以在這個環節考慮這些問題都可以了？。但是如果把需求調研的計畫僅僅理解為做乙個時間計畫表，那這個步驟的工作風險就變大了。訪 談和需求分析報告及需求規格說明書的編寫也可以用同樣的方法，將這個工作在專案組中討論並將流程細化，這樣就可以最大限度的避免需求調研的風險。
(2) 專案組成員要了解客戶的業務
我們很多專案組的成員只是在計算機方面比較內行，但具體到業務，可以說 是非常之陌生。這可能也就是很多專案做不好的真正原因。這個專案對客戶有什麼幫助？某一項功能客戶是否需要？這些問題都回答不了，真正的原因就是對業務不 了解。所以在專案的開始階段就要重點讓專案組的人員了解業務，只有了解了業務我們和客戶才會有共同語言，否則客戶說什麼我們也不清楚，倘若那樣我們的需求 調研質量就不會太高。
(3) 對客戶的it及相關知識的普及
現實情況是很多專案經理遇到的情況是使用者it水平確實很差，不能準確地表達出自己的需求，那麼我們必須對客戶作很多的知識普及工作以啟發需求。
需要做哪些普及工作需要根據客戶的情況來定，但這需要我們做大量的了解和分析工作。了解的目的是知道客戶是什麼水平，分析的目的是解決該對客戶做哪些培訓。
從一般的情況來講，專案組要更加注重與專案相關的知識培訓，比如我們從事gis工程，我們就需要將gis的相關的知識多一點講給客戶，並且根據需要可以稍微多講一些，只有客戶了解什麼是gis，並對此產生了興趣，專案組工作就會更加好做。
除了知識，我們可以將以前成功案例中相似的功能拿來給客戶看，這都是啟發需求的過程。
(4) 對客戶需求的深層次的挖掘
這是對客戶的需求進行提公升的乙個關鍵活動。
我了解過很多客戶，他們把專案交給我們公司，就是認為我們在這方面是專家，希望我們以專家的角度給他們提供資訊和實施專案。但是很多專案組都沒有做到他們希望的那樣！
我 們很多專案都是有成功案例的，而在之前的專案中，已經有了很多經驗和教訓，但很少有專案組注意這些寶貴的財富，導致我們只是在乙個低階水平上重複，甚至在 專案中犯同樣的錯誤！這是由於沒有人去總結專案經驗，我們做了很多專案沒有什麼沉澱，與乙個新進入此行業的公司相比沒有什麼競爭優勢。
還有就 是我們沒有對客戶的需求進行「分析」，客戶說什麼就是什麼，沒有從「專家」的角度給客戶任何建議，反正客戶說要這個功能，我們就去實現吧。其實客戶的需求 是需要引導的。在客戶對專案理解還不透徹、不準確的情況，客戶提出的很多想法都不是很成熟，可能客戶隨著對專案的理解的深入，就覺得這些功能不需要了，所 以這種需求的變化可以在專案前期加以正確引導的。
(5) 換位思考
最後我們還要進行換位思考，我們真正能給客戶帶來什麼好處？我們這個專案對客戶的業務和管 理到底有什麼樣的提公升？很多專案的實施是為了做專案而做專案，但其實在做專案的同時還是可以兼顧「客戶的真正的需要」的。只有進行了換位思考，我們才會從 客戶的切身利益出發，為客戶篩選出真正的需求。
所以，要更好的防範需求階段的風險，我們必須更好的按照流程做事、了解客戶業務、培訓和不斷的學習，只有考慮到了方方面面的因素，把容易出問題的環節都把握好了，做好風險的識別和防範，同時站在客戶的角度多考慮問題，專案就會更加順利，以後的需求變更就會更少。
曾濱源先生談專案風險管理
7月29日，pmi廣州志願者團隊邀請到愛立信的曾濱源先生，跟大家聊專案風險管理的相關話題。由於是訪談式的節目，所以沒有完整的ppt。還好我拿到了當時的錄音，把錄音整理成思維導圖。雖然知識點比較離散，但是交談的過程中不乏很多經驗匯集之談，我用紅色標註起來，希望讀者細細體會。1 風險識別 1.1 忌諱漫...
以部落格為例談幾點關於部落格SEO的看法
在站長站，看了那麼多關於收錄和優化的文章，大家眾說紛紜，各有所長。至於何為真理，那只有了，我們要做的就是無限接近真理。今天我也以部落格為例談幾點自己的看法。關於偽原創。偽原創的方法很多，比如改標題法，段落調換程式設計客棧法，同義詞替換法，文章 註明法，文章摘要法等等，各有妙處。本文標題說了，我部落格...
需求分析和概念原型 以火車售票系統為例
本文主要在學習高階軟體工程課的基礎上，對工程實踐的題目進行分析，將課本上的知識運用到實際的工程專案中。我的工程實踐題目是 設計乙個類似12306售票系統 首先我要對我的題目進行需求分析。需求就是使用者期望的軟體行為的表述，需求分析就是在獲取需求的基礎上進一步對軟體設計的物件或試題的狀態 特徵和行為進...