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

　　12 Comments »

　　項目剛剛開始的時期，項目經理做的主要事情是搜集客戶需求，這是一個項目經理非常頭疼的階段，合作的磨合剛剛開始，需求問題上的失誤又會導致無窮的后患。

　　三種客戶類型：

　　1 的確很專業。能提供基本可用的文檔，能給出要求規范，能向你提出有價值的疑問和擔心。能快速回答你的問題

　　2 以為自己很專業。 給的文檔基本沒法用。沒法提供規范和標準，喜歡指指點點和挑毛病。只會向你提傻逼問題?；净卮鸩涣四愕膯栴}。

　　3 啥都不懂。 不給文檔。能給你幾個參考范例(打開數個網站，告訴你我要做成和它們一樣的。)只能等著你來問100個問題。。。

　　四種合作方式：

　　1 創始人直接和你接洽： 交流結果的協商余地很大，需求不易反復，細節不會被過分追究。更容易統一想法，執行力高，你能對項目和產品產生更大的影響。但往往甲方會過于急進。

　　2 項目代表和你接洽： 這是非常理想的狀況了。甲方有一個產品經理或IT經理能作為代表，負責匯總甲方的所有需求和標準和你溝通，他有過與外包方合作的經驗，知道危險的環節所在，能承擔翻譯和橋梁的角色，幫助你阻擋和說服不恰當的需求。能集中地承擔責任，也會積極地和你一起規避項目失敗的風險。非常lucky!

　　3 專業部門和你接洽： IT部門或技術部門的某個高級別工程師負責和你溝通，你們會比較有共同語言，甚至惺惺相惜。技術方面的合作會很順利，但是涉及到產品和需求，他們無法幫你擋住來自市場或內容部門的麻煩。合作開始后，很有可能在技術思路上產生分歧;如果在程序部分耽誤了太多時間，而產品端被忽視，你有可能受到其它部門及上層的質疑。

　　4 市場部門(內容部門)和你接洽： 最好你先去燒燒香，準備好最壞打算。專業和思考模式的差異會導致你們關心的問題完全不一樣。你首要滿足了他們關心的地方后，切記留出不少時間來解決那些他們看不見但實際上非常重要的問題。另外你需要做更多的事，寫更多的文檔，主動和專業部門聯系，力爭和決策層有溝通。

　　如果你面臨了第3和第4種狀況，

　　請先熟悉一下甲方的組織機構。例如一般 內容型、媒體、渠道、宣傳類項目的開發：

　　需求 和 市場部門 溝通

　　功能 和 內容部門 溝通

　　軟硬廣告位或專題 等 和 銷售部門 溝通(如果是改版類，廣告位合同可能提前半年簽訂，一定要和銷售協調好)

　　技術、系統、安全、統計問題等 和IT、網管、數據統計部門 溝通

　　某些問題 需要和 總裁助理、行政 等官僚部門溝通。

　　部分特別的內容 需要和 創意、美工、文案部門 溝通

　　當以后確定需求的時候，如果發現這些部門的人沒有參與，請提前與之溝通。

　　第1和第2種狀況可跳過上述步驟。

　　八步流程:

　　第一步：聽聽客戶想要什么。

　　以及預計工期和預算(這兩件事上一點都不要靦腆，這是關系項目成敗最重要的元素)。

　　第二步：提問。

　　1. 項目的目的是什么。(品牌、渠道、流量、廣告費、用戶數、VC、其它商業模式)

　　2. 甲方的優勢和資源是什么。(錢，內容資源，人力大戰，傳統行業優勢)

　　3. 盡量提供可視的參照及借鑒對象 。(應用上有沒有可解決的。界面上比較喜歡哪個站點的設計。交互上有沒有可參考的對象)

　　4. 其它工程的細節問題。比如(工期上的上下限是什么?是否會需要與現有系統整合、是否需要數據遷移?是否會需要甲方的工程師合作?是否有開發平臺的限制?是否有代碼規范及標準?最終需要哪些開發文檔和源碼 )

　　第三步：取得共識。

　　與甲方取得共識非常重要，保證你所理解的那他們所理解是同一個東西。這一步需要你根據掌握的情況列出提綱，畫出草圖或框架圖。有參考對象的，標注上，哪個部分會比較像某某。 然后請甲方確認， 這個框架是他們想要的。

　　第四步：給出工程時間軸。

　　到了這一環節，就需要你的項目經理組織所有團隊成員坐下來討論，先劃分功能模塊，然后討論每個功能模塊的可行性、難度、花費時間、bug發生率、測試耗時。再討論一頭一尾 系統搭建和系統整合的所需時間。

　　項目經理對工程耗時和可行性完全心里有數后，畫出工程的時間軸。包括并行狀況，里程碑節點、測試期、緩沖期等(如何畫工程時間軸，甘特圖，我以后會專門寫一篇)。

　　時間軸要實事求是，并且預留好充分的緩沖期(工程師估時*2*110%)。

　　第五步：需求做減法。

　　大部分情況下，時間軸表現的狀況都會超出客戶的預期。

　　如果客戶對工期沒有要求，也要提醒客戶考慮 項目可行性風險、市場等候成本、市場或戰略變化導致的浪費。

　　韓磊有一篇《大褂還是內褲》的blog很形象地描述過這個問題。

　　所以要和甲方一起盡量對需求做減法。把整體需求拆成2~3期，落實只開發最基礎和最必要的一期需求。

　　這時簽訂正式開發協議。不要忘了計算 需求文檔和產品方案 的費用。

　　第六步：撰寫詳細的需求文檔。

　　《框架圖》下載西喬的模版?？梢暬憩F產品的框架、布局、細節、部分交互。

　　《流程圖》》下載西喬的模版。理出產品的邏輯關系。

　　《功能需求文檔》》下載西喬的模版。 羅列 功能、應用、交互上細節，分離基礎件，作為開發分工和系統及數據構造的 基礎文檔。

　　第七步：商討需求文檔

　　盡量召集甲方所有相關部門的負責人 一起召開這次會議，商討需求文檔。

　　在閱讀到你的需求文檔之前，可能甲方的大部分人都對產品沒有可視和具象的理解。也從未關注到細節和邏輯關系。所以需要產品經理從全局角度和邏輯線索講解文檔。

　　更可能發生的狀況是，沒有人堅持看完或仔細看過你寫的文檔。

　　所以這次會議是一場耐心和體力的考研。 文檔作者需要 分別向各個部門指出他們需要關注和拍板的地方，聽取他們的建議，將任何變動要求都分類記錄。 安撫情緒。解答困惑?？刂菩枨笞儎?。

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