前話

Kano模型里（kano模型是狩野紀昭教授發明的對用戶需求分類和優先排序的一種工具）將人們對某物的需求定義成了五個層次，包含：基本需求，期望需求，興奮需求，無差異需求，反向需求。感興趣的可以看下這篇文章作者對于Kano模型的應用解讀：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 枯葉作者對Kano模型的解讀

我們以基礎需求為原點，向正面挖掘，以期望需求或者興奮需求為目標來要求自己，并且盡量規避反向需求，無差異需求的誤區。

以上是產品團隊中該秉承的要求，而我們的項目是偏toB的業務系統類型，需求的側重于功能的可用性，從實現成本和客戶的需求角度出發，我們作為乙方是不能允許自己想太多，盡量避免興奮需求 。老練的程序員經常對我耳提面令：千萬別多想，客戶沒有提出來不要增加難度。這話第一次聽可能想反駁：這樣會不會導致太過于平庸，對于一個產品人的成長不會有助益。但是有道理的，因為對于一個新人，沒有項目的實踐經驗，如果給他太多的話語權，會造成帶節奏，自以為提出的需求是方便用戶，實際上實現成本會非常高。所以，作為我跟的第一個項目實施全過程，非常珍惜這來之不易的機會，總結出此次項目跟進中的經驗，分享出來。

一.如何正確梳理客戶需求

客戶提出的需求往往是零散的、模糊的，作為項目的首要步驟就是梳理客戶需求，常見的流程是和客戶開會，確認他們的需求，整理成需求文檔，或是以原型的形式呈現出來，將需求具像的描述給客戶確認。但往往我們開完會后回頭來整理這些需求的時候還是一團零散的點，怎樣具像需求呢？

1.業務流程梳理

畫出健全的業務流程，其中包括子流程、關鍵節點，盡量做到詳盡全面概括，再根據流程劃分頁面，構建頁面結構。

2.內容結構的規劃

可以使用卡片的形式或是思維導圖，列出頁面內容，每個頁面需要什么模塊，展示哪些內容，實現哪些功能，按照流程排列起來，然后就是詳細的畫出原型框架，方便程序員設計師理解需求。

這里就不多講了，我知道的也不多，看我拙劣的文檔就知道了，推薦看“談談頁面流程圖（附案例）|人人都是產品經理”：http://www.woshipm.com/pmd/27239.html

3.不要過多解讀客戶的需求

過多的解讀客戶需求，是做無用功，應該避免掉入反向需求坑。

案例：客戶說希望做一個每日情況匯總推送給用戶，我們內部討論流程時發生分歧，產品認為客戶是想要一個數據匯總的模塊，在數據匯總表格上再添加一個信息推送功能，這樣既可以一目了然的了解到當天的銷售情況，又可以滿足客戶推送消息給用戶；程序員認為客戶沒有提出后臺數據匯總模塊，他們的需求只是信息推送；經過和客戶的溝通，確定客戶滿足于實現信息推送功能，產品提出的需求超出了客戶的期望需求，屬于興奮需求，純屬給自己加戲。

4.需要仔細辨別分析需求，不是非黑即白

很多時候客戶描述他們的需求，可能會出現反復，規則更改，要仔細辨別。

案例：后臺設置中標流程，根據客戶的描述，同一批采購物品，會挑選幾家公司中標，起初為他們設計了對物品進行選取中標公司，為平臺方留有了非常大的空間和權限，但是操作起來繁瑣；使用過一段時間后客戶反映操作不夠方便，客戶的某位對接人說希望有一種一鍵設置的功能，但是前提是這樣中標的只能是某一家，這與原先商議的規則不同，我們表示這樣邏輯相互矛盾，做出了修改，后來客戶再一次說不能設置2家公司中標，才明白客戶的真正需求是既要有只有一家公司中標的情況，也要有可以同時設置多家公司中標。

這是一個非常典型的需求辨別不清的，我們在聽取客戶描述時，不能只浮于表面，要深究客戶提出這樣的要求背后其真正的訴求，其實例如上面的案例，客戶的線上采購只是一個線下采購的輔助報價篩選工具，最終可能會選中其中幾家合適的供應商廠家， 再做溝通選擇。

5.試圖分析客戶描述背后的真實需求，如何更高效的解決問題

有些需求聽上去很奇怪，但背后往往是隱藏著客戶的真實需求，例如要求將界面顏色調整得很鮮亮，這背后代表著客戶對于本品牌優勢的突出的需求，以及提高銷量轉化的需求。這些可以建議客戶在營銷方面多做些工作，帶來的轉化可能會更高。

6.面對不合理的需求，如何和客戶講道理

說實話，我不會。每次都是丟給我老大幫我善后，是我當時的能力不足以應對客戶的強勢。需要讓客戶理解實施的難度，以及涉及的成本，不合理的原因，都需要有理有據。

二.處理客戶需求變更方面的經驗小結

做項目的經常會遇到客戶的需求變更，更可怕的是做了一半了，全部推倒重來，這時候不管是甲方還是乙方都是一萬個不愿意，如何處理呢？

1.當面交流、收集一手資料

很多項目的溝通是業務員和項目經理前往洽談業務，傳遞的信息有一定的誤差，為避免這樣的情況帶來的錯誤預估，建議項目溝通時帶上產品，或者做好前期的需求表收集記錄；之后的項目溝通盡量以當面交流，收集的一手資料為準。

2.與項目成員溝通解釋清楚，需求變更的理由和必要性

為什么要重新設計采購微信頁面？

需求變動的原因：前期交流的信息差導致規劃方向錯誤，必須向參與成員道歉。

需求變動的必要性：原先的功能不能滿足客戶的需求

原來獲取的信息是客戶需求是微信端的公司行政產品的采購，實際上客戶的采購業務分為：配件采購、大型器械采購、辦公用品采購、鋼材類采購等，辦公用品只占據很小的比例，對于業務上的采購要求非常高，微信端的應用不能有很好的客戶體驗；

調整后：需要整合這幾種不同種類的采購，并新提出了采購招標PC端需求，并且重新設計微信頁面，給配件供應商在手機端查看采購相關信息，推送采購信息，結合PC端操作報價。

3.需求再次確認，發郵件文檔記錄變更

需求做出大的修改的情況下，需要制作新的需求表文檔，發送給客戶對接人進行確認，并保留好文檔記錄，防止未來的扯皮推諉。

4.需求修改，先緩一緩再著手，預留再次變更的空間

有些需求實施起來難度大，修改周期長，這甚至具有很大的不確定性，需要做好辨別，適當延期放入需求池，做好后續關注即可。

三.項目實施與甲方用戶參與的經驗

前期客戶需求比較模糊，起到引導的功能；

中期他們有意識的參與，需要幫助客戶進行篩選甄別；

后期不斷增加的小需求，層出不窮，考量實現成本，如何規避反向需求；

項目驗收階段，客戶提出的哭笑不得的優化意見，給我們的反思，有些所謂的常識并不適用；

與甲方用戶周旋的小tips：

及時與延后處理并行；

找到合適的相關人溝通更高效；

電話溝通更方便；

站在用戶的角度體驗產品；

將修改意見通過文檔進行確認，并在修改后給出反饋文檔，完成度以及未完成原因解釋，工作交接落實到文檔雖然麻煩但是更舒心。

（這篇小總結寫于2017.6月，遺忘在云筆記里了，更新上來，僅僅是個人項目經驗）