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

　　第八步：定稿需求文檔

　　分職能(部門)類建立表格文檔。將會議協商中所有 分歧性意見和變動意見 都逐條寫下。抄送所有相關負責人。并要求他們糾正分歧和確認變動。

　　所有會議中可能被提出但是未出現在此郵件文檔中的 意見，不會列入需求文檔中。當然允許可以書面反饋補充。

　　根據確認過的反饋回復，修改需求文檔。直到需求文檔定稿。

　　協商討論和文檔修改可能經過2~3輪。所以需要項目經理提前提醒客戶注意，”搜集需求和文檔定稿”的時間線里程碑。如果這個階段耗時過久，會嚴重延誤整個項目進度。要求客戶盡量集中地謹慎地提出建議和修改。

　　三種武器：

　　需求問卷：

　　無論是面對專業還是不專業的客戶，交流中都有很多沒考慮到的遺漏點，這些他們看不到的點往往是最關鍵的點，也有可能是被客戶故意規避掉的點。

　　此時撰寫一份需求問卷非常有效。 問卷里提出重要的全局性的問題，需要客戶逐條書面回答。

　　某些問題可以提供多個選項答案，及補充區域。

　　某些問題 需要確鑿的態度，Yes或NO。

　　不要提出需要客戶寫一大段表述性文字的問題。 需求問卷精簡扼要，有針對性，重要，

　　不要浪費客戶的時間，不要把寫字的工作量丟給客戶。

　　書面確認：

　　書面確認 一方面包括 ：所有討論結果、建議 和變更 都要有書面文字備查。電話和開會上說說的這些口頭表達都沒有效應。這一點一開始你就要聲明，甚至有必要寫在合同里。

　　另一方面包括：你要盡量提供書面的可視化的東西 來讓甲方確認。甲方很難完備或是提供適合工程使用的文檔。所以千萬不要在項目初期的需求文檔上省懶。

　　郵件抄送：

　　郵件抄送一種明確職責的方法。對方可能不看你的郵件，但代表你告之過。盡可能地抄送重要郵件給戰略層，可以能避免一些重大問題的出現。

　　結語：

　　到此看起來，搜集和確定需求真是一件耗時耗力的工程。

　　其實在理想的工程項目時間分配中，1/3的時間用于確定所有需求和開發文檔。 1/2的時間用于測試，解決bug，安全測試、壓力測試等。真正用于開發的只應該占1/6。 當然web項目的開發肯定達不到這個理想狀況。

　　但是也由此可見需求階段的重要性和工作量。這一階段省一分力或有一分遺漏，到了項目后期可能需要十分力來彌補。

　　四 16

　　如何逃離垃圾客戶(下)項目管理

　　Tags: 項目管理, 失敗案例, 控制客戶, 故事

　　20 Comments »

　　《如何逃離垃圾客戶(上)》

　　故事三：朋友介紹的好機會

　　C：高級程序員，5年代碼工作經驗。在職，工作清閑，偶爾接點私活。

　　外地人，在北京漂著，8K月薪稅前，偶爾需要加班，有個職業普通的女朋友，買房甭想，打車掂量掂量。宅男，回家了就看看資料看看美劇，長時間持續的代碼工作，視力一天不如一天，脖子和腰也經常不舒服。

　　C經常想，不知道有多少程序員過著像這樣的生活，不好不壞，無力改變，也沒有理由去改變。

　　好在他性格溫和，人緣很好，經常會有朋友介紹一些私活給他，除了掙點錢，對生活也是一種填充。

　　C一個挺鐵的哥們跳槽到一家傳統行業的公司，公司需要開設電子商務的業務，就找到了C幫忙搭個系統，費用也不低，C欣然承應。

　　客戶公司不大，對互聯網有一定了解，由市場部門和C溝通接洽。 他們并沒有太明確的想法，希望和現行跑的大部分網店差不多就行。C就用開源系統搭個一個，按照客戶的要求建了分類，錄入了一些測試數據。

　　客戶總是不知道自己要的是什么，但是知道什么是自己要的。

　　有了可視的DEMO，客戶也就有了想法。他們提出要根據自己的業務特色增加預訂貨物和預定管理的流程。

　　而此時C還沒有和客戶簽訂正式的合同，只明確了開發費用的總數，也沒有具體寫明任務清單。因為有朋友在這，這家公司做傳統行業也有不少年，信譽上問題不大。所以C也比較放心。先花了一兩周改造了開源程序的流程。

　　客戶提出界面的風格和品牌形象不太匹配。C找了一堆開源皮膚，讓客戶挑一個?？蛻籼袅藥讉€分別換上試試。兩周又過去了。

　　客戶提出商品的縮略圖尺寸不夠大，圖像質量不夠好。C修改了GD庫和圖片壓縮的參數。

　　客戶又提出縮略圖列表頁 圖片有橫版有豎版不夠整齊。C只好又修改了縮略圖截取的程序。

　　此時已經過去了6周，C開始催促朋友，先把預付結了吧。朋友甚至有點驚訝：“還沒把預付給你嗎?我趕緊幫你催催。”

　　客戶持續像擠牙膏一樣地擠出需求。加個水印啦，添加一種排序關系啦，改下分頁啦。 預付還是沒有到位，補簽合同顯然也不太現實，朋友每周都在表示抱歉，表示一定幫忙落實費用，總是有些財務上的預算上的付款期上的理由。

　　C已經意識到自己已經掉進了一個大坑：項目時間持續流失，客戶意見時常反復，需求零敲碎打但都不復雜，總體來看也并沒有脫離當初定好的項目框架：利用現成的開源代碼搭建一個客戶需要的網店系統?？墒堑浆F在為止所耗費的工程時間和工作量已經足夠自己重寫一套了。

　　爆發的臨界點終于到了?？蛻艨戳烁偁帉κ值木W店，發現了很多新功能，所用的開源系統是同一個，只不過使用了最新的3.0版本。 客戶要求也對自己的系統進行升級。

　　C性格再好也忍不住了：“我以前專門提醒過：已經對系統進行了那么多的定制化改造，如果升級，所有定制化需求都得全部重新改一遍。使用開源系統如果要升級就不能做太多改造，如果要定制化就得放棄升級!

　　客戶：“當初也是你建議我們使用開源系統的.”

　　C：“你們又想控制成本，又想節省時間，又不知道自己要什么，需求又總是反復，開源系統是最好的選擇了。“

　　客戶：“但是你看，現在很多我們需要的功能沒有，這個問題總得解決吧……”

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