編輯導(dǎo)語：有效的需求調(diào)研可以讓產(chǎn)品經(jīng)理更好地了解用戶需求，提高開發(fā)效率，降低無效成本。而不同于C端，G端需求調(diào)研還需要考慮決策者需求。本篇文章里，作者結(jié)合實際經(jīng)驗，總結(jié)、分享了G端需求調(diào)研時可能遇到的問題與解決方案，一起來看一下。

前言導(dǎo)讀

• 你是否遇到過需求頻繁變更的甲方，導(dǎo)致項目需求蔓延嚴重？
• 你是否遇到過“我不要你覺得，我要我覺得”的甲方？
• 你是否遇到過上線后客戶說“和我們想要的不一樣”？

作為G端產(chǎn)品，沒遇到此類情節(jié)是一種幸運，遇到才知有多坑，本文初心是希望能幫忙提前識別和避免。

此處G端產(chǎn)品的需求調(diào)研避坑指南，各項目所遇問題不同，經(jīng)驗總結(jié)僅供借鑒，也希望和踩過同樣坑的產(chǎn)品，一同交流。

大家攜手，讓坑少一點，路順一點。

預(yù)計閱讀時長：15min。

一、首先，你調(diào)研到全部需求了嗎？

舉個例子，產(chǎn)品接到臨時又緊急的需求，但被告知沒時間做深入調(diào)研，只了解以下信息。

• 老板說：這個客戶很核心，可以不賺錢，但客戶要搞定。
• 客戶說：我需要一整套住房，一家五口人住，三世同堂，需要滿足所有日常使用功能，配套設(shè)施要齊全，但我預(yù)算有限。

產(chǎn)品一聽，也不是不能做。為滿足客戶需求，同時獲得肯定，還要控制成本，決定利用公司資源，獲取一套周邊設(shè)施完善的經(jīng)濟適用商品房，但客戶一家人一直在國外度假，沒空確認。眼看工期將至，產(chǎn)品趕緊帶團隊沒日沒夜加班裝修，將客戶所提功能全部滿足，準備交房驗收。

客戶回國一看卻大失所望，覺得和自己的理想住房完全不同。

再次溝通才發(fā)現(xiàn)，只掌握了需求的冰山一角，且實際財政權(quán)在爺爺手里，不在一直溝通需求的男主人這。而爺爺?shù)膶嶋H期望，是泳池大別墅，拒絕驗收。但能怎樣呢，客戶哪有錯呢，錯的只有背鍋俠產(chǎn)品。

這是按真實案例抽象改編的故事，屬于客戶期望與實際落地差距存在一條鴻溝，核心原因是：

1. 前期需求調(diào)研不穩(wěn)，后期實施落地不準。
2. 未掌握全部關(guān)鍵相關(guān)方的客戶需求。
3. 埋頭干活，未階段性地驗收交付。

因此，為避免需求落地的巨大偏差，縮小這種偏差，需明晰各階段需調(diào)研的信息，才能保障方案產(chǎn)出的質(zhì)量。

二、各階段調(diào)研的內(nèi)容和產(chǎn)出

ToG需求調(diào)研可分為三大階段，前期背景調(diào)研、啟動階段的整體業(yè)務(wù)調(diào)研、交付階段的需求調(diào)研和設(shè)計確認。

信息來源不限，可來自市場、售前、項目經(jīng)理、客戶、用戶、客戶官網(wǎng)、招投標等各類渠道。

1. 前期階段：背景調(diào)研

大坑之一：不重視前期調(diào)研，將增加客戶期望與實際功能偏差的可能性。

在項目啟動前期與客戶溝通中，產(chǎn)品經(jīng)理需要充分了解項目背景、客戶訴求、使用單位環(huán)境情況、業(yè)務(wù)數(shù)據(jù)情況，避免在后期調(diào)研時存在信息差。

在該階段，需了解項目背景、客戶、使用單位環(huán)境、業(yè)務(wù)數(shù)據(jù)源信息，詳情如下。

1）了解項目背景

首先，要對項目產(chǎn)品所服務(wù)的業(yè)務(wù)領(lǐng)域有一個概括性的了解。

其次，在項目開始前，一定要明確項目終極不可更改的目標是什么，要跟所有相關(guān)性方、特別是和大領(lǐng)導(dǎo)要對齊目標。明確為什么做該項目？該項目的長期愿景是什么？短期目標有什么？

• 項目做什么：清楚項目核心解決的問題，可通過招投標信息、市場和售前人員介紹、網(wǎng)上相關(guān)資料搜集了解建設(shè)方的訴求，掌握希望達成的目標；
• 項目是什么：掌握項目現(xiàn)狀，是從0-1的新建，或已有版本的迭代，或已有版本的推翻重做，目前現(xiàn)狀存在什么問題；
• 項目怎么做：了解項目預(yù)算、項目建設(shè)周期、相關(guān)政策指導(dǎo)方針、制度要求、行業(yè)標準、行業(yè)規(guī)范。

2）了解客戶

了解客戶想要什么的過程，需貫穿G端項目的始末。

需求變更、需求反復(fù)、需求蔓延在G端項目中難以避免，究其核心是讓產(chǎn)品與客戶心理期望的“藍圖”實現(xiàn)一致，怎樣實現(xiàn)客戶“藍圖”甚至超越客戶想象，得到較高客戶滿意度，前期調(diào)研明確客戶“藍圖”顯得尤為重要。

• 項目客戶的組織結(jié)構(gòu)：確認項目的用戶機構(gòu)是哪些，以便后期掌握不同角色對系統(tǒng)的訴求；
• 客戶期望：ToG項目的特殊性造成了使用者和決策者不是同一批人，為此，需要區(qū)分掌握決策者、干系人、使用者這幾類角色的不同期望，尤其是高層級客戶需求；
• 客戶性格：便于更好的溝通。

3）了解使用單位環(huán)境

調(diào)研使用單位環(huán)境主要為掌握使用單位機房情況。政府項目大多為涉密數(shù)據(jù)，用內(nèi)網(wǎng)較多，存在外網(wǎng)和內(nèi)網(wǎng)數(shù)據(jù)如何打通等問題，需要提前了解系統(tǒng)運行環(huán)境。

• 網(wǎng)絡(luò)環(huán)境：掌握系統(tǒng)運行部署的網(wǎng)絡(luò)環(huán)境，是內(nèi)網(wǎng)還是互聯(lián)網(wǎng)？對數(shù)據(jù)傳輸和功能實現(xiàn)可能有較大影響。
• 部署服務(wù)器配置：所需內(nèi)存？cup配置是否滿足需求？G端軟件項目中，項目經(jīng)理參與程度不一，產(chǎn)品常承擔部分項目經(jīng)理工作，為避免硬件不符合要求，延誤需求上線，需提前掌握該部分信息，及時申請或采購。
• 用戶：用戶量多少？并發(fā)量多少？

4）了解業(yè)務(wù)數(shù)據(jù)源

數(shù)據(jù)獲取程度由數(shù)據(jù)基礎(chǔ)決定，需逐步明確數(shù)據(jù)情況，在足夠了解數(shù)據(jù)基礎(chǔ)后進行系統(tǒng)設(shè)計與產(chǎn)品方案設(shè)計。

• 有什么：該階段的數(shù)據(jù)調(diào)研，掌握需要什么業(yè)務(wù)數(shù)據(jù)；
• 為什么：為什么要有該類數(shù)據(jù)，核心解決了什么問題；
• 怎么做：怎么獲取該部分數(shù)據(jù)，以明確數(shù)據(jù)對接方式、網(wǎng)絡(luò)環(huán)境。

2.?啟動階段：整體業(yè)務(wù)調(diào)研

在項目啟動簽訂合同前后，會對整體的業(yè)務(wù)進行調(diào)研，需預(yù)留準備時間，做充足的調(diào)研準備。

在該階段，需關(guān)注用戶角色、業(yè)務(wù)流程、業(yè)務(wù)數(shù)據(jù)、功能架構(gòu)信息，詳情如下。

1）角色調(diào)研大坑之二：未掌握高層客戶底層需求。

各層級都有各自角色形成的期望，掌握各層級期望，有助于方案設(shè)計和成果匯報更加順利。

• 需求分析：站在用戶角度分析高層決策者、干系人、使用者各角色的需求，分別存在的痛點，以及是更關(guān)注盡早上線、功能完善程度還是界面美觀程度；
• 用戶習(xí)慣：通過提前了解用戶已有系統(tǒng)，掌握用戶的整體風格與交互習(xí)慣，了解用戶對已有系統(tǒng)的不滿，及時規(guī)避不足；掌握上層平臺，提前規(guī)劃數(shù)據(jù)對接及應(yīng)用對接方案。

2）業(yè)務(wù)流程梳理大坑之三：業(yè)務(wù)調(diào)研深度廣度不夠。

客戶不是每個流程和業(yè)務(wù)都知道，需要留時間給客戶去了解和調(diào)研，引導(dǎo)客戶深度參與。

若是以部門為單位的集中式調(diào)研，調(diào)研清單要設(shè)計合理，給客戶足夠的考慮時間，最好提供相應(yīng)的建議和案例，讓相關(guān)部門提前思考和準備，能提前拉群溝通和提前獲取業(yè)務(wù)相關(guān)資料更好。

在業(yè)務(wù)調(diào)研環(huán)節(jié)，主要調(diào)研和輸出業(yè)務(wù)流程、場景、核心需解決的問題、業(yè)務(wù)流程中的輸入輸出。

• 繪制業(yè)務(wù)流程圖：了解業(yè)務(wù)場景，梳理每個流程節(jié)點內(nèi)容與負責人；業(yè)務(wù)涉及使用角色說明；業(yè)務(wù)流程中的表格、報告，最好都有真實樣例數(shù)據(jù)；
• 業(yè)務(wù)數(shù)據(jù)源：涉及到哪些數(shù)據(jù)源；數(shù)據(jù)來源網(wǎng)絡(luò)環(huán)境；數(shù)據(jù)更新時間；數(shù)據(jù)量多大；字段標準等；業(yè)務(wù)流程中的表格、報告，最好都有真實樣例數(shù)據(jù)；
• 業(yè)務(wù)流程優(yōu)化建議：存在什么痛點，有什么建議與想法。

3）業(yè)務(wù)數(shù)據(jù)源

該階段明確業(yè)務(wù)數(shù)據(jù)源的來源和內(nèi)容，掌握需對接的第三方平臺及單位，確認需要協(xié)調(diào)的資源，避免不確定的風險，為方案選擇和實施能帶來較大便利。并能保證項目開發(fā)進度，比如由于數(shù)據(jù)無法如期對接、推送延遲、數(shù)據(jù)質(zhì)量較差等原因，將影響我方項目交付。

• 系統(tǒng)對接類：提前明確和什么系統(tǒng)對接；網(wǎng)絡(luò)環(huán)境及數(shù)據(jù)傳輸方式如何；接口規(guī)范如何，需明確輸入輸出，最好提前獲取對接文檔，梳理數(shù)據(jù)流圖；明確系統(tǒng)對接人單位、姓名、聯(lián)系號碼、崗位，和研發(fā)人員建群提前溝通；明確接口提供時間，是否影響項目進度；
• 數(shù)據(jù)填報類：需掌握填報內(nèi)容和填報業(yè)務(wù)流程，如填報角色是誰，是否需要審批，更新要求是什么；
• 數(shù)據(jù)情況：獲取樣例數(shù)據(jù)、數(shù)據(jù)更新時間、數(shù)據(jù)量、字段標準。

4）功能框架確認

在整體業(yè)務(wù)調(diào)研基本完成時，需同時梳理整體功能框架，并進行確認。在確認階段，盡可能避免在溝通中出現(xiàn)理解偏差。最可怕的是，雙方都認為對方理解了彼此的意思。

面對信息化建設(shè)經(jīng)驗較少的甲方，建議準備首頁、能體現(xiàn)平臺架構(gòu)的主頁面的視覺稿，確認架構(gòu)和整體風格，更能被理解；面對決策層級較多的甲方，并需要針對不同客戶角色關(guān)注點，準備不同顆粒度的方案。

• 項目整體框架：項目的整體模塊功能層級，確定子系統(tǒng)和功能模塊；梳理模塊功能清單；梳理各個模塊之間的關(guān)聯(lián)；確認和上級系統(tǒng)的關(guān)聯(lián)；
• 確定階段目標：確認業(yè)務(wù)功能優(yōu)先級；制定階段性功能目標；梳理里程碑目標。

3. 交付階段：階段性調(diào)研確認

交付階段遇到技術(shù)明確，需求不明確階段，增量交付方式返工概率大。產(chǎn)品原型設(shè)計需預(yù)留足夠時間進行多次確認，設(shè)計采用敏捷方式多溝通確認，開發(fā)使用瀑布流方式，確認需求并驗證方案后再開發(fā)，去降低推翻重來的風險。

在該階段，需關(guān)注需求列表、整體功能架構(gòu)、業(yè)務(wù)數(shù)據(jù)、系統(tǒng)設(shè)計信息，詳情如下。

1）需求維護

大坑之四：從不了解業(yè)務(wù)/沒有決定權(quán)的角色獲取需求，九成返工。有時方案確認像闖關(guān)，層層規(guī)則不一樣。明明因為方案未確認而無產(chǎn)出，但甲方只覺得你沒干活。

需針對不同層級領(lǐng)導(dǎo)溝通實現(xiàn)想法，了解真實期望，和項目經(jīng)理一同分析領(lǐng)導(dǎo)信息化認知階段和關(guān)注點，準備不同材料，客戶是想早點上線？還是更關(guān)注界面美觀？還是功能完善？還是成本控制？

其實人生有捷徑。重要決策可想辦法，通過商務(wù)、項目側(cè)各方面拿到?jīng)Q策方、拍板人的意見。

• 可建立需求初步篩查規(guī)則，在需求首次被提及時，需求獲取人可對需求進行初篩和答復(fù)客戶；
• 和甲方針對各需求獲取渠道建立統(tǒng)一需求對接人，將承接的需求匯總；
• 建立共享需求反饋池，根據(jù)需求類型及迭代狀態(tài)進行分類管理，讓需求采集及時記錄，需求規(guī)劃及進度一目了然；
• 對已上線的需求、已提測的需求、掛起的需求、當前迭代已確認的需求，單獨建表管理；
• 需求變更很常見，也需長期和甲方“博弈”，需分析客戶關(guān)注哪個需求，聚焦于核心需求，在變更時及時調(diào)整優(yōu)先級，和甲方溝通確認；
• 分析客戶關(guān)注哪個層級信息。

2）維護整體功能框架

• 項目整體框架：交付階段及時維護子系統(tǒng)和功能模塊；維護功能清單；維護各模塊功能關(guān)系；
• 跟進階段性目標：根據(jù)項目變化，及時調(diào)整需求優(yōu)先級，階段性驗證功能目標的完成情況。

3）業(yè)務(wù)數(shù)據(jù)源

該階段需在項目經(jīng)理和技術(shù)人員協(xié)助下獲取信息。

• 了解和第三方系統(tǒng)對接處于什么階段；
• 已對接的數(shù)據(jù)進行數(shù)據(jù)驗證，判斷是否滿足系統(tǒng)設(shè)計要求；
• 短期無法對接、對接后有數(shù)據(jù)問題的模塊準備預(yù)備方案。

4）確認系統(tǒng)設(shè)計大坑之五：忽視決策高層與使用者需求之間存在的差異。

有決策權(quán)的高層需求與系統(tǒng)用戶的使用需求，同等重要。宏觀到整體架構(gòu)，微觀到字段，需分層明確。

項目有計劃，研發(fā)有流程。再確認環(huán)節(jié)為不影響項目整體進度，需想盡辦法拿到?jīng)Q策方、拍板人的意見，向客戶闡述現(xiàn)狀及利弊，必要時通過市場、項目側(cè)推動，否則因需求反復(fù)造成的返工情況，會嚴重影響工期和團隊積極性。

• 客戶需求：區(qū)分業(yè)務(wù)使用者和高層的關(guān)注點；決策干系人關(guān)注業(yè)務(wù)場景；使用者關(guān)注是否能滿足日常使用；
• 業(yè)務(wù)流程：調(diào)研現(xiàn)有的業(yè)務(wù)；規(guī)劃系統(tǒng)使用之后的業(yè)務(wù)流程；確認通過系統(tǒng)完成的流程優(yōu)化；
• 產(chǎn)品頁面設(shè)計：需對系統(tǒng)輸入輸出、頁面布局、涉及字段進行細節(jié)確認。

在這設(shè)計逐步確認過程中，甲方才能逐步明確自身想法，偶爾也需要一些溝通“技巧”。

三、G端與C端的調(diào)研異同

比較G端與C端調(diào)研的差異，兩者都需要通過調(diào)研構(gòu)建用戶畫像，也同樣說的不等于想要的，但也有很多不同點。

對用戶而言，G端產(chǎn)品的替換成本大于C端，因此需關(guān)注用戶已形成的習(xí)慣和認知。另外需對已有系統(tǒng)和環(huán)境的調(diào)研更為重要，如硬件設(shè)備的分辨率情況，將嚴重影響設(shè)計方案。

在業(yè)務(wù)需求調(diào)研方面，C端屬于用戶就是客戶，使用者至上；G端的使用者和決策者往往是兩批人，需求提出方和建設(shè)方也往往是兩批人，更多的是決策者至上。

四、總結(jié)

總之，需求調(diào)研是需求分析的前提，需求分析是產(chǎn)品方案決策的依據(jù)，需求確認是對需求調(diào)研準確性的驗證。

只有足夠的輸入才有好的輸出，所以明晰各階段需求調(diào)研所需內(nèi)容，做好需求調(diào)研，才能保障方案的產(chǎn)出質(zhì)量，從而為客戶帶來價值，獲得客戶對我們服務(wù)的認可。

望共勉之。

本文由 @wenda 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。