午夜夢迴，我總是想不明白——
為什麼業務總是說不清需求？
為什麼做好的需求也沒人用？
直到我回溯了跟業務溝通的一幕幕....
1、【埋頭苦幹型】
IT：我要悄悄做系統，驚豔所有人
業務：我寧願用Excel
——缺少需求調研環節，或需求調研不充分，導致新功能對業務產生新的負擔，員工逐漸產生牴觸情緒
2、【相看兩生厭型】
業務：你做的東西不符合實際業務！
IT：可調研的時候你又說不出需求！
——前期需求調研不清，過程中需求一變再變，上線後才發現不能滿足實際業務場景
3、【唯唯諾諾型】
業務：誒我看XX的新功能蠻好的，明天給我們加一下吧
IT：好的好的（管他合不合理，先加上）
——缺少明確的需求調研起止點，專案過程中盲目承接需求，導致專案週期過長，開發計劃混亂
4、【顧影自憐型】
業務：我們能不能實現一個XX功能
IT：我不行，我做不到
——只評估了使用者提出的方案可行性，沒有深度挖掘方案背後的使用場景，找到實際使用場景也許會有更好的解決方案
原來，從需求調研的階段，就埋下了風險的種子。
需求調研作為整個專案的地基，影響著專案是否成功，那麼應該如何科學的進行需求調研，才能充分挖掘業務需求呢？
一、明確調研目的與調研形式
調研開始之前，我們首先要明確本次調研的主要目標是什麼。通常的調研目標有以下幾個：
1. 找全關鍵使用者
2. 獲取關鍵使用者的需求，明確需求場景，以及是否為業務痛點
3. 初步驗證我們預想的解決方案思路，能否解決實際問題
4. 儘可能多的提前識別風險
接下來需要確定調研的形式，如：問卷調查、直接溝通等。其他的需求挖掘的方式，比如資料分析、觀察法等，由於對資料質量、時間投入有一定要求，此次我們將基於最常用的問卷+直接溝通的調研方式展開。
為了保證調研的質量，能夠進行充分的挖掘，我們接下來要對已知的資訊進行梳理，並提前準備一些道具，推動此次調研進展更加順利。
二、準備進行一場深度溝通
1、提前梳理已知資訊，初步判斷專案風險
透過梳理專案關鍵資訊，可以判斷自己對專案的價值是否瞭解。可以將關鍵資訊梳理成一份專案自檢表，如果在專案啟動前，可以獨立的填寫80%以上的資訊，說明該專案的價值比較明確，解決思路較為清晰，後續規劃以及實施的動作也會更加明確，減少踩坑的可能性。
這裡我們提供一份專案自檢表，以供參考，可以根據自己的業務情況酌情調整。
1）專案自檢表表樣：
2）欄位說明
2、準備解決方案思路，解除溝通誤區
調研的時候，往往會發現——使用者並不知道自己想要什麼，所以對需求進行引導是非常關鍵的一步。由於領導/業務人員與我們的專業背景和知識結構不同，為了更好的傳達自己的想法，可以透過demo、案例，甚至手繪草圖等形式簡潔直觀的展現效果，讓對方能夠跨越專業詞彙，快速理解最終效果。
在這個階段為了更加快速的呈現效果，可以充分利用帆軟提供的已有資料：
① 豐富的demo庫（點擊進入）
② 各行各業的客戶案例（點擊進入）
3、分層準備結構化的調研問題，有針對性的獲取有效資訊
不同角色的調研物件，對業務的瞭解深淺、以及視角都有所不同，所以分層調研可以幫助我們更準確的獲取關鍵資訊。而提前準備結構化的調研內容，可以避免在調研過程中被業務提出的想法牽著走，業務主導的調研，就會很容易收穫五花八門的“解決方案”，卻沒有挖掘到真正的痛點業務場景。
一般來說，調研物件可以分為：戰略層、業務管理層、業務執行層。（文末附不同角色的調研模板）
1）戰略層：老闆、高管
如果需求來自戰略層，我們與之溝通可以瞭解到一些宏觀資訊：
1.專案需求是誰提出的，便於進一步識別專案干係人，推進專案的順利落地
2.是基於什麼原因提出的專案需求，以便對需求有全域性性的瞭解，在設計規劃階段有一定的靈活性，能最大程度契合未來業務規劃
3.整個系統需要實現什麼樣的效果，達成何種預期。對使用者期望進行全面瞭解，拉通不同關鍵人之間的預期。
4.是否有已知的同類系統存在，他們在公司或行業內處境如何
2）業務管理層：財務、人事等業務負責人
這一層級的人員，能夠清楚業務運作情況，同時能從業務全域性協助梳理需求，並識別專案風險。我們從該層級人員的訪談中，需要了解以下內容：
1.業務部門的組織結構如何，是否存在頻繁變動的可能
2.當前業務中有什麼困境，哪些需要此次專案優先解決
3.業務中可能存在哪些風險
4.業務中有哪些關鍵角色
5.業務平時是如何運作的，每個業務節點，是由哪個崗位角色負責的
6.業務的流轉是否需要審批，審批人員是誰
7.是否已經在使用其他的替代產品，在解決當前的業務問題中有什麼問題？有什麼可取之處？
8.崗位人員變動之後的業務流程、許可權、資料等如何處理
說明：往往正向的業務流程梳理相對容易，專案風險通常隱藏在異常業務之中，所以需要重點關注業務管理層提出的一些問題，對後期劃分需求的優先順序比較有幫助。
3）業務執行層
該層級的人員最為熟悉業務運作細節，但同時對於業務全域性缺乏完整認知，所以容易陷入對個性化需求的闡述。我們的需求調研中，針對這類人員需要增加訪談的樣本量，避免被影響需求優先順序的評估。我們從該層級人員的訪談中，需要了解以下內容：
1.確認執行層崗位的具體人數，合理規劃調研的樣本量，避免因樣本量過少而調研內容有失客觀性
2.每個角色在業務中的具體工作內容是什麼
3.業務環節開始、流轉、完結的標誌節點是什麼
4.業務處理的發生頻次如何
5.執行中業務的難點或者處理起來最麻煩的地方是什麼，為什麼很難處理
6.過往是否出現過事故，事故原因是什麼，後續是如何處理和規避的
7.瞭解執行人員希望本次專案能解決的實際問題點
8.是否已經在使用其他的替代產品，在解決當前的業務問題中有什麼問題？有什麼可取之處？
說明：哪怕是一樣的問題，如果角色不同，我們可以獲取的資訊也會不一樣，所以需要我們資訊收集上來之後做合理的整體性評估。有條件的情況下，可以多參與、觀察實際業務場景下各個角色的工作流程。
調研模板表樣：
三、一些需求調研的技巧，讓溝通更加順暢
1）認真仔細傾聽，及時記錄。可以使用錄音幫助記錄。
2）儘量跟業務使用一套語言系統，避免過於技術的專業詞彙，適時拿出demo案例或者畫草圖。
3）根據使用者型別應對。以下是部分型別，僅提供一些個人應對建議。
①強勢型：強勢型業務方經常會提一些比較難實現的需求，可以先進行調研收集，後續規劃階段透過整體評估，以及行業案例、過往資料等客觀事實等作為佐證
②隨和型：隨和型業務方比較好溝通，但可能主動性較差，需要關注挖掘到的需求是否為實際業務痛點訴求
③技術小白型：該類業務大機率很難闡述清楚自己的訴求，可以儘量引導還原業務場景，提供原型等方式輔助溝通
④業務專家型：該類業務會很明確提出自己的想法，甚至是系統實現方式。不能止步於他們提出的功能，要挖掘到原始業務場景，有利於後期給出整體實現方案。
注意：警惕使用者直接給出的方案，要還原原始業務場景。多考慮：想要什麼？要這幹什麼用？他為什麼這麼想？會不會有別的想法？
4）宏觀需求很重要，但細節需求也很重要，會影響使用者是否願意使用系統。
① 宏觀需求
◆功能大塊：明確使用者要透過系統做哪幾件事；
◆ 業務場景：每個功能模組都有哪些業務場景；
② 細節需求
◆ 使用習慣
◆ 樣式
5）警惕模糊性詞彙，比如：我覺得，我估計。這類意見可能成為風險因素，難以明確的可以先進行標註，積累一定樣本量後整體性評估。
6）注意需求調研的覆蓋面，防止需求不具代表性。
7）明確業務側關鍵對接人，在精不在多，通常確定1-2人，便於需求調研後解決疑問或遺漏問題。
8）沒有需求如何引導？
① 首先，明確業務部門是不是真的沒有需求？往往業務表現出沒有需求，都是假象。大機率沒有需求是因為：
◆不瞭解系統可以實現什麼樣的效果，不清楚哪裡還可以最佳化
◆ 不知道新系統學習成本是不是很高，是不是會增加我的工作難度
② 如何引導？
◆ 已經做過的業務場景講解，各個部門之前有共同之處可以遷移
◆ 其他外部行業標杆案例宣導，可以複用成功的經驗
◆ 產品知識掃盲，減少業務對使用成本增加的擔憂
◆提供官方的demo讓業務使用者去體驗，直接感受產品使用
四、明確調研起止點，避免“反覆無常”
需求調研結束後，一定要及時總結整理已經完成的調研內容，發給受訪人員進行確認。如果有更改或放棄的需求也需要進行標註，並留存歷史版本，以便覆盤以及產生爭議時回顧。
另外如果出現對接人眾多，可能也會導致過程中需求頻繁變更的問題，針對這類問題我們可以有以下應對措施：
1、 為什麼會導致這類問題？
大機率是由於：
◆ 對組織架構不熟悉，找不到關鍵對接人，最後拉群拉了大幾十人；
◆對接人本身不具備統籌權，頻繁因為執行層或上級建議變更需求；
◆關鍵對接人轉崗或離職。
2、如何解決？
◆ 首先需要保證自己對公司組織架構清晰，至少能夠準確找到部門決策人。當對接人模糊時，可以及時和負責人溝通落實；
◆其次要保證關鍵對接人是否有確認需求的職能和權力，如果需求彙總並不是當前對接人的主要工作時，需要增加業務執行層的調研樣本，以避免調研不夠客觀；
◆最後如果判斷對接人的在崗狀態不穩定時（比如只是上級臨時安插），此時對於對接人提出的需求，優先順序可做適當程度降低。當對接人無法達到對接要求時（不溝通、執行不到位），需要尋找合適時機，和部門負責人進行確認。
使用工具FineReport：
超連結
