需求調研

[#1]

概述

任何項目瞭解清楚客戶需求都對項目順利交付起到決定性作用。以下為一些經驗分享，用以提升項目前期需求調研的準確性，項目合作的長期成功率，降低重大變更風險。 長期成功指的是甲方付出合理的價格，採購到合適的產品服務，並不是短期的，如甲方白嫖乙方，或乙方給出不切實際的承諾，最後拿一筆首付款跑路，或是前期免費超低價，後期挖坑回本，或出現災難性問題。

篩選有效客戶/供應商

項目成功的必要條件，雙方誠實互信；認可現代管理理念，在精細化工作/研發過程中分工協作比威權審批更能有效提升生產力。

甲方：

• 面對啥都答應啥都能做要謹慎。

• 高中低價格都詢一遍，不要選最低價。

• 如果沒有需求，彆強行生造。

• 彆強行畫餅，讓別人提前做沒有合同覆蓋的事情。

乙方：

• 收完預付款再做諮詢，如果甲方沒有意願交幾萬塊諮詢費，意味著沒有合作意向。（互聯網快速增長期的C端免費玩法，讓大量中國大陸地區B端客戶也有了同樣的白嫖思維習慣。）

• 不要抱著卷死同行的心態搶項目，因為卷意味著惡性循環。

• 不輕易承諾，事先告知清楚能做事情的範圍以及風險，一旦承諾，一定完成。

付費界限

付費是合作的大前提，但也要掌握好度。

客戶有很多類型，有些是專門為了騙方案，找各家服務商以選型為名義做 POC。有些則是不清楚界限在哪裡，有付費意願，解釋清楚就好。

一般來說，無需付出時間重新配置的標準演示（Demo），如從需求，開發，測試，到發佈，售後，研發到客戶服務全生命週期管理。

如果有定製需求，如客戶風格的服務檯，自動化規則，個性化的里程碑節點。則建議按人天進行收費。售前並不僅僅是證明功能可實現性，即使沒有達成合作，已實現的方案可作為後續項目交付的樣板房。

節奏控制

公司老大叫 CEO，首席執行官，而不是首席規劃官，充分證明，幹活比畫餅重要。

但這並不說明規劃不重要。保持一個合理配比；計劃一週，玩命執行一年，顯然不合理，車已經開到溝裡了。典型的戰術努力，代替戰略懶惰。

通常研發場景下，硬件週期長，軟件週期短。規劃時間過短，可能會忽略重要風險，比如重大缺陷，早期設計不當導致後期變更困難，規劃時間過長，可能失去市場機會。

如果以規劃時間長短來說，最短的是初創企業，最長的是官僚型外企。

經驗來說，正式執行前，最少留出20%來做規劃，不僅是一個簡單的 excel 任務分解，project 甘特圖，而是需要一套可以從頭到底跑通的系統，如條件允許，可以是系統，時間倉促，也可以是 Axure 做的仿真原型。

分里程碑交付，而不是一下子做大而全，每個階段都給予幾個明確，數據可見的驗收指標。越是目標模糊越是要把目標拆下，船小好調頭。

比如第一階段，工具統一100%，流程線上化70%。第二階段 研發工具鏈打通 50-80%，第三階段運營，研發效能報表可視化 90%。 數據比感受重要，有準確的收益評估。

用戶故事 vs 系統字典

多數客戶都會覺得調研需求很容易，很快就能做完，這時候需要依賴外部顧問或甲方項目負責人為內部調整預期，絕多數情況下，調研需要的時間會比甲方預期長很多。

人與人之間有認知差，客戶日常熟悉自己的業務，顧問熟悉 Atlassian 產品，世界上最遠的距離不是隔海相望，而是你以為別人懂，實際完全不懂；除非你有 X 教授讀心術超能力，或甲方對接人本身有極強的A廠產品項目經驗，否則請默認客戶理解的東西和你完全不同。

往往客戶腦子裡只有一個大概，看得見摸得著的樣子貨，用文字和PPT描述往往過於抽象，一個有實體的演示才可以最大程度的降低不確定性，因為後期變更往往意味著高成本以及項目失敗風險。

兩邊互相雞同鴨講，要是臉皮厚，發現問題及時修正還好，最怕就是假裝懂了，成本下去了，做出來的東西不是客戶要的，項目黃了。

每個企業都有不同的企業文化，由於這些年互聯網造富神話，導致黑話四起，本來民營踏實的工程師和管理人員也或多或少開始不講人話，程度有高有低。不要嘗試去改變企業文化，要設法融入之。

要調研清楚功能，切忌不要從技術和系統層面去問用戶，而是要在用戶角度換位思考，如果時間緊張，調研完之後，畫出流程圖，用自己的話表達一遍整體的流程，如果客戶認可無誤，才進入實際的設計工作。

如果時間寬裕，最好能花幾天和用戶一起工作，所謂一起吃喝拉撒。豐田精益生產很多人經常提，Just In Time，0 庫存。但很多人學這個是希望有類似銀彈管理法，多快好省提升生產效率。 實際任何的優化改進都是漫長，痛苦的，無痛無癢，一針就好大都是騙子。 豐田和蘋果對供應鏈的把控不僅僅是居高臨下，把標準的管理方法一說，結果隨緣，而是派人到工廠，改進每個環節，保證品質和成本。正所謂紙上得來終覺淺，絕知此事要躬行。

調研類型

調研模式主要分兩種，與瀑布和敏捷對應，如按大家都能理解的兩種經濟類型，瀑布對應計劃經濟，敏捷對應市場經濟。

幫企業往好的方向漸進式優化，而不是一味強調瀑布/敏捷的某一種好壞。

瀑布：

• 外企流程長，規章制度健全，做事情以瀑布模式為主，接受甲方的需求，按部就班的執行當然無可厚非，如果顧問經驗豐富，且甲方對接人有心改進工作，此時可以在不違反全球管理合規要求前提下，適當融入一些敏捷的元素，縮短無效流程，合併重複職能。

• 工業軟件，硬件，對品質穩定要求高，發版頻率低，此時的重點在於如何把日常工作的前後置關係，在收集完信息後整合到同一個甘特圖，讓各方可有統一視圖。

敏捷：

• 民營企業追求快，甚至於踩香蕉皮，滑到哪裡是哪裡，此時務必要注意踩剎車，多提醒欲速則不達。當人數變多，版本到後期，標準的流程和自動化工具才是提效降本，提升質量的關鍵，一味強調快，截止日期，加班，只會適得其反。

參考文檔

關於調研方法，也可參考場景下的相關文檔。

場景