項目管理中如何更好的控制客戶的需求？
阿新 • • 發佈：2017-08-24
陌生 處理 16px png 健康 教訓 主要部分 簡化 啟動
做項目管理經常會遇到這樣的場景：公司的銷售人員興沖沖的拿來一份與客戶簽訂的合同交給你，聲稱這項目已經搞定了，但是當你拿過來合同(或者任務委托書)一看，關於需求，項目範圍的說明只有寥寥數行，要麽是一些高舉高打的套話，要麽只說項目都包含什麽樣的模塊，而對具體的業務只是一兩句話就完事兒了，如果是一位身經百戰的管理者並且對於項目的具體業務很熟悉還可以，如果不是那該如何開始這個項目呢？還有一種情況，客戶在項目進程中，不斷對階段交付的系統提出各種修改意見，更令人氣憤的是，有些問題開始提出更改，也有個能進行反復的更改，但是某一天客戶突然就發現情況不對，又要求你給改回來，看起來客戶的需求總是無窮無盡，作為項目的管理者該如何應對這種令人沮喪的局面呢？
一、客戶需求為何過渡蔓延 作為項目的管理著，在規定時間用有限的資源來保質保量的完成項目，讓公司和最終客戶都滿意是項目組的神聖職責。但是為了讓客戶滿意就要滿足客戶所有的需求嗎？因為不斷滿足客戶的需求會不會導致項目失敗怎麽辦呢？為了弄清楚這些原因，首先應該找到這些問題發生的根源。 1.簽訂合同的時候，項目範圍描述不清楚。這是最常見的問題之一，也正是早期的這些問題沒有引起項目組的足夠重視，導致後期項目無窮無盡的修改。 2.客戶和項目組對寫成紙面文件的需求理解不一致。這種情況也較常見，雖然客戶已經確認了項目組提交的項目範圍說明書，項目組也是完全按照這個文件規定的內容做的，但是客戶還要求改，當項目組拿著紙面的文件與客戶對質的時候，才發現客戶也認可這需求，但是同一件事情，客戶的認知和項目組的認知完全不同。舉個簡單的例子：客戶要求系統能夠電子簽名，項目組的成員就模擬了一個，自動產生客戶的簽名在系統中，但是當移交給客戶的時候才發現，客戶要求的電子簽名實際上是想把原來手寫簽名的工作也移植到電子化的系統中，讓領導能夠通過畫圖的方式產生一個手寫的簽名在文檔中應該落簽字的地方！有時候就是當初一點點疏忽，導致項目後期大量修改甚至項目延期。 3.客戶總有在結項之前把每一件事情都做得淋漓盡致的初衷。一般來講，在項目結項之前，客戶都會把所有的想法盡量逼著項目組解決，因為一般的客戶心理都會認為：一旦結項了，再想找項目組成員對業務系統進行修改可就難了，因為IT公司人員流動性強的特點，即便以後能夠找到承包商，當初做項目的項目組成員也不一定在了，或者很多公司因為業務繁忙，已經顧不得原來已經結款的客戶了。 4.項目組人員總是無條件遷就客戶，客戶有求必應。這種做法的出發點是好的，目的是要客戶完全滿意，但是實際上這種做法不一定能達到目的。一般的客戶需求都是無底洞，這樣做對整個項目經常也會帶來很多負面影響。當然，如果過分控制客戶的需求，客戶肯定也不會滿意。
二、解決辦法 
項目初期一定要制定清晰的目標和項目範圍，並且讓項目主要幹系人(最重要的當然是最終客戶了)確認。
不管通過什麽途徑得到的項目，作為項目主管，在項目前期，可以分三步走。
第一個想到的問題應該是“為什麽”，也就是客戶做項目有什麽目的，知道這些以後，才能在以後的工作中更加想客戶之所想，不至於項目方向錯誤，最終爭取達到雙贏得局面。
知道了“為什麽”以後，接下來就要非常清晰的知道“做什麽”，有一個比較好的辦法就是用一兩句非常簡潔的話概括出來整個項目，並且能夠用這種方法概括出項目中的各個子任務，並且能夠讓前臺業務人員和後臺研發人員都能夠心領神會，那麽說明項目主管對項目的內容在大方向上已經有很好的把握了。
最後就要弄明白“怎麽做”了，對於比較陌生的項目來講，這一階段工作量比較大也很重要，在這個階段多花點精力絕對值得，當然，根據具體的情況，也可以在這個需求調研階段簡化一些不必要的工作，這需要項目主管具備平衡那些彼此沖突的項目目標的能力。在實際的工作中，這需要一個過程，值得註意的是，在需求整理完畢形成文檔以後，最好先讓項目組人員把自己總結的需求跟客戶比較詳細的講一遍，在實際的操作中，這種做法不僅能夠把項目人員與客戶在業務層面的歧義問題數量大大降低，還可以很好的發先潛在的問題，並且掌握一些溝通技巧，也會讓客戶更能深刻的感覺到承包商對他們的重視。另外，如果項目前期得需求人員對技術非常不了解，根據實際情況最好在需求每次提交給客戶前與研發人員溝通，以避免不必要的給客戶的承諾，更加準確的界定工作量。總之，有效的計算出項目範圍將會占用一定的時間，但是同樣會節省資源、資金以及解決項目今後令人頭疼的問題，例如：需求(範圍)變更。
另外一個很值得註意的問題是：項目的需求經過幾次確認以後，要讓有權力的客戶明確確認，最好有書面簽字，這個有說服力的文件會在以後客戶發生需求變更的時候起到很好的作用，很顯然，因為客戶已經簽字確認，總是反悔肯定理虧呀，即便因為業務變化不得不對項目進行大的調整以至於項目延期，這種情況下也會是項目組處於有利地位，不至於讓自己的公司非常不滿，甚至可以以此為依據來要求客戶重新考慮項目經費。當然，對於客戶來講，通過這些很好理解的需求的闡述，也會以此作為以後交付產品的依據，做到心裏有數，消除不必要的疑慮，這個對雙方有同等的約束力，很有好處。
2、靈活應變：遇到變更要與客戶溝通 
經常有這種情況，項目都已經執行到最後階段，客戶突然提出了新的要求或者要求對已有需求進行更改，這會讓項目主管非常為難：一方面要盡量滿足客戶的需求，另一方面又不能對系統做太大的改動，影響進度計劃。這種情況發生除了和需求階段有關以外，同時說明在實施過程中沒有與客戶有密切的聯系，缺乏溝通。
從客戶的心理來分析。由於軟件的特殊性，客戶通常非常關註後期的服務，尤其是在國內大家做的軟件絕大多數都是與實際業務緊密相連的。作為項目管理者，非常忌諱的是在做項目的過程中對客戶置之不理，而最後交付的時候才與客戶突然發生大量接觸，本來後期的實施過程出現問題的可能性最大，之前與客戶又比較生疏，很可能會造成非常大的風險。比較穩妥的辦法就是在項目進程中也要讓項目組與客戶保持聯系，相互了解，建立更加融洽和諧的溝通氣氛，為以後關鍵的實施移交階段可能與客戶發生的沖突做好準備。值得一提的是：在項目進程中階段性的給客戶呈現一下項目的進展狀況，讓客戶對項目有一個更加直接可視化的認識，更能及早的發現解決問題免除後患，在不斷的溝通過中，應該讓客戶認識到項目組時時站在客戶角度著想，讓客戶的主要負責人也能深深的感覺到他們是項目組的重要組成部分、榮辱與共，並且項目組能為客戶提供完善持續的後續服務，這樣可以有效的避免客戶絞盡腦汁想把所有的事情在第一次結項之前做完。
即便前期工作做得再好，很多情況下，需求變更是不可避免的。項目主管通過良好的溝通機制隨時掌握變更情況和可能發生的變更，一旦發生了變更，項目組一定要冷靜處理這些問題，一般可以按照產品分析—〉成本/收益分析—〉備選方案—〉專家判斷這四個步驟來首先評估需求變更，並且盡快形成項目範圍變更書面的說明書，它是以後項目決策的基礎，當然比較穩妥地辦法還是讓客戶對明顯發生的變更做出確定(選擇簽字最好)，尤其是在評估了變更可能導致的工作量增加以後，讓客戶認識到過多的變更很顯然會造成項目延期，客戶對此也要負責任。
在客戶提出需求變更的時候，一定要掌握一定的溝通技巧，一定不要總是無條件遷就客戶。一般來講客戶對IT都不太熟悉，他們認為很簡單的事情，可能要花費項目組大量的無謂得多余精力，所以千萬不要認為客戶所說的就一定是他想得到的！大部分客戶都是第一時間突然腦海裏面冒出的火花，所以項目組人員要冷靜的分析一下：客戶到底想要實現什麽目的，抓住問題得本質。一般來講，實現客戶本質的需求有很多種辦法。在與客戶的溝通中，一定避免與客戶正面沖突。在初期認真傾聽客戶意見，多問一些“您還有什麽想法”之類的問題，等客戶把他的想法都表述清楚以後，項目組成員成員最好迅速評估一下客戶的建議，如果實現起來實在太困難，可以給客戶一些更加中肯的提議，多問些“您看這樣行不行？其實可以達到同樣的目的。”之類的問題，最後還有一個重要的過程就是要與客戶確認這次溝通的結論。
項目範圍管理流程：
總之，基本上所有的項目都會遇到項目範圍的問題，項目範圍管理是平衡那些彼此沖突的項目目標的一種能力。看起來簡單，但是實際上很復雜，項目主管在項目進程中要學會如何對常見變更進行控制，控制客戶需求的肆意蔓延，保證項目健康穩定的進行。
1.在項目啟動時，公司會批準一個新的項目階段的開始。
2.在範圍計劃編制的過程中，將制定一份說明書來描述在項目中將做什麽。
3.在範圍定義中，項目的主要部分被分成更小的部分。
4.在範圍審核時，需要驗收項目的範圍。
5.在範圍變更控制中，隨著時間的過去，需要對項目範圍變更進行監督。
在實際項目中遇到需求的問題，你又是怎麽處理的呢？
一、客戶需求為何過渡蔓延 作為項目的管理著，在規定時間用有限的資源來保質保量的完成項目，讓公司和最終客戶都滿意是項目組的神聖職責。但是為了讓客戶滿意就要滿足客戶所有的需求嗎？因為不斷滿足客戶的需求會不會導致項目失敗怎麽辦呢？為了弄清楚這些原因，首先應該找到這些問題發生的根源。 1.簽訂合同的時候，項目範圍描述不清楚。這是最常見的問題之一，也正是早期的這些問題沒有引起項目組的足夠重視，導致後期項目無窮無盡的修改。 2.客戶和項目組對寫成紙面文件的需求理解不一致。這種情況也較常見，雖然客戶已經確認了項目組提交的項目範圍說明書，項目組也是完全按照這個文件規定的內容做的，但是客戶還要求改，當項目組拿著紙面的文件與客戶對質的時候，才發現客戶也認可這需求，但是同一件事情，客戶的認知和項目組的認知完全不同。舉個簡單的例子：客戶要求系統能夠電子簽名，項目組的成員就模擬了一個，自動產生客戶的簽名在系統中，但是當移交給客戶的時候才發現，客戶要求的電子簽名實際上是想把原來手寫簽名的工作也移植到電子化的系統中，讓領導能夠通過畫圖的方式產生一個手寫的簽名在文檔中應該落簽字的地方！有時候就是當初一點點疏忽，導致項目後期大量修改甚至項目延期。 3.客戶總有在結項之前把每一件事情都做得淋漓盡致的初衷。一般來講，在項目結項之前，客戶都會把所有的想法盡量逼著項目組解決，因為一般的客戶心理都會認為：一旦結項了，再想找項目組成員對業務系統進行修改可就難了，因為IT公司人員流動性強的特點，即便以後能夠找到承包商，當初做項目的項目組成員也不一定在了，或者很多公司因為業務繁忙，已經顧不得原來已經結款的客戶了。 4.項目組人員總是無條件遷就客戶，客戶有求必應。這種做法的出發點是好的，目的是要客戶完全滿意，但是實際上這種做法不一定能達到目的。一般的客戶需求都是無底洞，這樣做對整個項目經常也會帶來很多負面影響。當然，如果過分控制客戶的需求，客戶肯定也不會滿意。
二、解決辦法
項目初期一定要制定清晰的目標和項目範圍，並且讓項目主要幹系人(最重要的當然是最終客戶了)確認。
不管通過什麽途徑得到的項目，作為項目主管，在項目前期，可以分三步走。
第一個想到的問題應該是“為什麽”，也就是客戶做項目有什麽目的，知道這些以後，才能在以後的工作中更加想客戶之所想，不至於項目方向錯誤，最終爭取達到雙贏得局面。
知道了“為什麽”以後，接下來就要非常清晰的知道“做什麽”，有一個比較好的辦法就是用一兩句非常簡潔的話概括出來整個項目，並且能夠用這種方法概括出項目中的各個子任務，並且能夠讓前臺業務人員和後臺研發人員都能夠心領神會，那麽說明項目主管對項目的內容在大方向上已經有很好的把握了。
最後就要弄明白“怎麽做”了，對於比較陌生的項目來講，這一階段工作量比較大也很重要，在這個階段多花點精力絕對值得，當然，根據具體的情況，也可以在這個需求調研階段簡化一些不必要的工作，這需要項目主管具備平衡那些彼此沖突的項目目標的能力。在實際的工作中，這需要一個過程，值得註意的是，在需求整理完畢形成文檔以後，最好先讓項目組人員把自己總結的需求跟客戶比較詳細的講一遍，在實際的操作中，這種做法不僅能夠把項目人員與客戶在業務層面的歧義問題數量大大降低，還可以很好的發先潛在的問題，並且掌握一些溝通技巧，也會讓客戶更能深刻的感覺到承包商對他們的重視。另外，如果項目前期得需求人員對技術非常不了解，根據實際情況最好在需求每次提交給客戶前與研發人員溝通，以避免不必要的給客戶的承諾，更加準確的界定工作量。總之，有效的計算出項目範圍將會占用一定的時間，但是同樣會節省資源、資金以及解決項目今後令人頭疼的問題，例如：需求(範圍)變更。
另外一個很值得註意的問題是：項目的需求經過幾次確認以後，要讓有權力的客戶明確確認，最好有書面簽字，這個有說服力的文件會在以後客戶發生需求變更的時候起到很好的作用，很顯然，因為客戶已經簽字確認，總是反悔肯定理虧呀，即便因為業務變化不得不對項目進行大的調整以至於項目延期，這種情況下也會是項目組處於有利地位，不至於讓自己的公司非常不滿，甚至可以以此為依據來要求客戶重新考慮項目經費。當然，對於客戶來講，通過這些很好理解的需求的闡述，也會以此作為以後交付產品的依據，做到心裏有數，消除不必要的疑慮，這個對雙方有同等的約束力，很有好處。
2、靈活應變：遇到變更要與客戶溝通
經常有這種情況，項目都已經執行到最後階段，客戶突然提出了新的要求或者要求對已有需求進行更改，這會讓項目主管非常為難：一方面要盡量滿足客戶的需求，另一方面又不能對系統做太大的改動，影響進度計劃。這種情況發生除了和需求階段有關以外，同時說明在實施過程中沒有與客戶有密切的聯系，缺乏溝通。
從客戶的心理來分析。由於軟件的特殊性，客戶通常非常關註後期的服務，尤其是在國內大家做的軟件絕大多數都是與實際業務緊密相連的。作為項目管理者，非常忌諱的是在做項目的過程中對客戶置之不理，而最後交付的時候才與客戶突然發生大量接觸，本來後期的實施過程出現問題的可能性最大，之前與客戶又比較生疏，很可能會造成非常大的風險。比較穩妥的辦法就是在項目進程中也要讓項目組與客戶保持聯系，相互了解，建立更加融洽和諧的溝通氣氛，為以後關鍵的實施移交階段可能與客戶發生的沖突做好準備。值得一提的是：在項目進程中階段性的給客戶呈現一下項目的進展狀況，讓客戶對項目有一個更加直接可視化的認識，更能及早的發現解決問題免除後患，在不斷的溝通過中，應該讓客戶認識到項目組時時站在客戶角度著想，讓客戶的主要負責人也能深深的感覺到他們是項目組的重要組成部分、榮辱與共，並且項目組能為客戶提供完善持續的後續服務，這樣可以有效的避免客戶絞盡腦汁想把所有的事情在第一次結項之前做完。
即便前期工作做得再好，很多情況下，需求變更是不可避免的。項目主管通過良好的溝通機制隨時掌握變更情況和可能發生的變更，一旦發生了變更，項目組一定要冷靜處理這些問題，一般可以按照產品分析—〉成本/收益分析—〉備選方案—〉專家判斷這四個步驟來首先評估需求變更，並且盡快形成項目範圍變更書面的說明書，它是以後項目決策的基礎，當然比較穩妥地辦法還是讓客戶對明顯發生的變更做出確定(選擇簽字最好)，尤其是在評估了變更可能導致的工作量增加以後，讓客戶認識到過多的變更很顯然會造成項目延期，客戶對此也要負責任。
在客戶提出需求變更的時候，一定要掌握一定的溝通技巧，一定不要總是無條件遷就客戶。一般來講客戶對IT都不太熟悉，他們認為很簡單的事情，可能要花費項目組大量的無謂得多余精力，所以千萬不要認為客戶所說的就一定是他想得到的！大部分客戶都是第一時間突然腦海裏面冒出的火花，所以項目組人員要冷靜的分析一下：客戶到底想要實現什麽目的，抓住問題得本質。一般來講，實現客戶本質的需求有很多種辦法。在與客戶的溝通中，一定避免與客戶正面沖突。在初期認真傾聽客戶意見，多問一些“您還有什麽想法”之類的問題，等客戶把他的想法都表述清楚以後，項目組成員成員最好迅速評估一下客戶的建議，如果實現起來實在太困難，可以給客戶一些更加中肯的提議，多問些“您看這樣行不行？其實可以達到同樣的目的。”之類的問題，最後還有一個重要的過程就是要與客戶確認這次溝通的結論。
項目範圍管理流程：
總之，基本上所有的項目都會遇到項目範圍的問題，項目範圍管理是平衡那些彼此沖突的項目目標的一種能力。看起來簡單，但是實際上很復雜，項目主管在項目進程中要學會如何對常見變更進行控制，控制客戶需求的肆意蔓延，保證項目健康穩定的進行。
1.在項目啟動時，公司會批準一個新的項目階段的開始。
2.在範圍計劃編制的過程中，將制定一份說明書來描述在項目中將做什麽。
3.在範圍定義中，項目的主要部分被分成更小的部分。
4.在範圍審核時，需要驗收項目的範圍。
5.在範圍變更控制中，隨著時間的過去，需要對項目範圍變更進行監督。
在實際項目中遇到需求的問題，你又是怎麽處理的呢？
轉載請註明原文地址：http://www.cnblogs.com/chenliangcl/p/7420321.html
項目管理中如何更好的控制客戶的需求？