作為項目經理如何和大客戶溝通打交道(2)

　　如果你是雇員，一定要強烈提醒你的老板，不同的條件配置不能混用。

　　如果你是外包方，還是要記住，需求對應費用，不要以為這就是是刪刪改改的數字游戲。

　　狀況4：反復改稿;反復糾纏于細節

　　狀況：產品端人員經常會遇到客戶要求反復改稿，并且十分糾結于細節。

　　比如一個首頁改了4、5稿，做了兩禮拜還沒做好。打翻重做都有2、3回了。 產品A是放在產品B的前面還是后面，產品C是擋住產品B的1/3還是1/2?？蛻籼峁┑奈陌富蛘叻g不停在修動，今天刪行字，明天加行字，每次都得改完文件，導出，請對方審核。明明是對方的失誤，耽誤的確是你的時間，最后你還得為整體項目進度延誤付出代價。

　　應對：這種狀況首先得由項目經理做好預防。文章開頭說過了，調配職責，是調配 時間、資源、需求之間的關系。(資源代表錢和人力)這三者之間是互相鉗制的。需求膨脹，就需要更多的資源或時間;想要縮短時間，就得壓縮需求或者補充資源;想控制成本，就得壓縮需求或同意更長的項目周期。(注意：根據人月定律，人工/單位時間 和 錢是不能絕對換算的。延長開發人員的工作時間也只能讓情況更加惡化，項目經理一定要慎重在這兩者之間的調配。)

　　1。項目經理再和客戶簽訂預算的時候，就應該尊崇這種換算原則下的 付酬及核算方法。(以后我會專門寫blog討論如何制訂預算)以單位人工*時間來計費。這樣由于客戶原因導致的單位人工工作時間增加，可以得到費用上的合理補償

　　2。開發協議附件要附上項目時間線，里面明確標清幾個階段的時間里程碑。比如需求完成的里程碑、界面完成的、前端切圖的、系統架構的、基礎開發的、整合的、內部測試的、bug調試的。如果某個里程碑未按時完成，是由于甲方問題導致的，需要標清責任，并在當時向客戶聲明可能造成整體項目延誤的風險，如果非常嚴重的甚至可以要求甲方賠償(因為乙方外包公司的時間一樣很值錢。)

　　3。開發協議上要聲明甲方對設計稿提出修改意見的輪數，一般是2輪。2輪修改已經意味著最多3稿，什么樣的問題基本都能在3稿中改定，什么樣的分歧也都能在3稿內統一。超過這個改稿數需要追加費用。這樣可以促使甲方全面集中地一批提出修改意見，而不是想到哪說到哪。(我曾經遇到一個客戶，一晚上給我發了20封郵件，每封郵件里提1~2條建議，郵件前后還有反復以及 “以此郵件為準之類”的話。MD，后來發展到只要他想起來什么地方要修改就給我打個電話，在第一階段內測的時候，我曾經在一頓飯中接了他5個電話。)

　　4 。開發協議上要指定幾個關鍵節點的審核確認制。比如首頁和全局風格確定了，需要簽字確認一次，保證這是最終意見。全部UI設計完了，需要簽字確認一次，保證不再修改，不然前端切圖的同事就沒法干了。

　　協議這樣寫：條款*、工程審核及工程驗收

　　1. 收到預付款項之后，乙方設計組完成主要頁面UI demo的設計開發

　　甲方針對DEMO頁面進行審議，提出修改意見。乙方進行DEMO頁面的修改，甲再次審議。提出意見，乙方再次修改。甲方需集中在兩輪內，全面、統一、明確地提出審議意見。由甲方所提供文案、圖片、其它資料變動所帶來的修改，乙方可以免費在兩輪中提供支持。超出兩輪改稿范圍的工作，屬于維護性工作。請參見《項目維護協議》?；?將不予支持)

　　2 確認UI demo達到要求，甲方需對DEMO頁面簽字確認修改。

　　簽字確認后，進入前端切圖環節。甲方如果對頁面有其他變動較大的修改要求(更改頁面標準色、設計風格、頁面布局)，將視為二次設計，乙方可收取二次設計費用。

　　5 。對于甲方提供的文案、圖片、資料所帶來的麻煩，在協議中提取聲明。參見上一段和下一段

　　協議這樣寫：條款*、甲方責任

　　1. 甲方需對網上內容提出具體要求，若在所規定的時間，甲方不能夠及時確認開發設計的內容，所造成的項目進度的延誤，乙方不負任何責任。

　　2. 甲方需要為乙方工作人員了解具體業務提供詳細的文字、圖片等資料。若在所規定的時間，甲方不能夠及時提供相關資料內容，所造成的項目進度的延誤，乙方不承擔責任。

　　有了上述5項預防性措施，你剩下的很多事就好做了。

　　客戶反復改稿，反復糾纏于細節，一般不是惡意，大部分都是工作方法和缺乏大局觀的問題。

　　所以在客戶反復折騰，浪費時間的時候，你得告訴他們得付出什么樣的代價，同時你能提供明確的依據和協議的保護

　　約束客戶的審核行為。審核行為必須成批次，意見統一、明確、全面。

　　幫助客戶建立正確的工作方法。最簡單的做法就是提供一個審核意見的模版，讓客戶按葫蘆畫瓢地填寫。另外一定要教會客戶使用截圖軟件(QQ里的截圖就行)，這樣可以省許多口舌。審核意見模版下載

　　ppt版本下載 (用于產品端，優勢，可放置大面積截圖)

　　excel版本下載(用于產品端及 程序、功能測試反饋。優勢，條理性強，可過濾排序)

　　客戶自己提供的資料變動，一次兩次可以幫忙，多了就是維護性工作，得和開發階段明確分開。

　　還有一個問題，客戶很多時候不知道你需要什么資料，或者資料準備不及時。在項目正式開始之前，要按需要的緊急程度，向客戶提供 所需資料的清單，然后用不同顏色標清需求緊急程度，分別最晚什么時候要求提供。 這一點很重要，很多資料的缺失將直接影響到你設計和客戶需求的匹配。包括logo、標準色、產品圖、客戶要求放置的大圖、客戶品牌歷史使用的裝飾性元素、文案字數等。

　　——————下期預告————————

　　狀況5：由于級別關系，和你的開發人員聯系的甲方代表不是能最終拍板

　　狀況6：看見產品demo后，甲方立刻要求這改點那改點，補充需求膨脹

　　狀況7：客戶公司流程混亂，作風官僚

　　狀況8：你成為了部門斗爭的犧牲品

　　四 17

　　項目如何開始：怎樣和客戶一起搞定需求項目管理

　　Tags: 需求, 項目管理, 控制客戶, 產品文檔

原文轉自：http://www.kjueaiud.com