一次To B 項目的需求分析總結
最近巧合之下需要整理之前ToB項目的資料,所以今天也順帶和大家分享一些的自己之前在做ToB項目過程當中關于需求分析總結或經驗。
首先,什么是需求分析?
可能有人認為需求分析其實就是和客戶問一些問題,了解一下情況,然后就可以開始設計產品方案了。額,這樣理解也對,但可能并不全面。這里要拋出我這邊文章的第一個核心點:需求分析和產品設計是兩個相互獨立的部分。
需求分析要解答的問題是:
- 哪些地方要做?哪些地方不需要做?
- 這個問題到底值不值得做?
- 怎樣去衡量做得成不成功?
而在個人的經歷中,有過在需求調研階段發現需求不值得投入而被斃掉的情況。因此,產品設計,則是在確定在上述三個問題后再去構思該用何種方式去達到上述的成功標準。這個是考驗產品經理的能力的體現。
第二個問題:誰去做需求分析?
對產品經理而言,需求分析只是最基礎的一項技能。但在某一些提供技術解決方案的公司,會由項目經理承擔這樣的工作,在某些細化的領域,則會有專門的需求分析師負責,例如數據需求分析師,算法需求分析師,安全需求分析師等等。
另外補充個題外話,商業需求分析師也是有專門的考試的(有興趣的童鞋可以百度一下PMI-PMB)。
第三個問題是,需求分析怎么做?
其實不同的公司也會有不同的做法,在這里我會分享一下之前我經歷過的一個項目里面的需求分析經過。這個項目的背景是一個跨國銀行的項目,我負責該銀行某個地區的轉賬流程優化,不過由于保密原因,我不會在這里透露過多的項目信息,同時由于這個項目的范圍和復雜程度較高。
所以在這個需求調研過程其實是由兩個團隊負責,我整合了兩邊的資料,希望能夠盡量地給大家呈現出一個需求調研的完整過程,歡迎有其他想法的小伙伴一起交流。
第一步:在初步獲得需求信息后,先了解背后的故事
在獲取到初步的需求信息后,了解一下對方的組織架構和動態,這樣你可以知道這個需求到底怎么來的,他們對實現這個需求的動力和動機是什么?是否強烈?需求是由誰來拍板?你最終要匯報的由是誰?會不會涉及到其他部門等等的組織內部關系?
在開始正式進場之前,先把關系理清楚。畢竟需求分析,說白了也是和人在打交道。
第二步:為需求確定一個大概范圍
在理清好組織內部關系后,我們就開始著手處理需求了,我們要為這個需求劃定一個“大概”的范圍,其中包括幾點:
- 這個需求涉及到的業務范圍有哪些?
- 這個需求涉及到的部門和相關人員有哪些?
在我個人的經歷當中,作為乙方,很多的需求是來源于甲方的商務人員,有時候甚至是直接面對著公司的COO或者是CTO,他們會更偏向于業務的角度或者公司全局的角度去思考,但是對于需求的落地或許有些偏差。因此,去尋找更合適的人去了解資訊會更能提高效率。
第三步:把需求翻譯成數據指標
在對需求的目的有了一個初步的了解后,我們需要根據這個目的去進行量化,一般企業的內部優化項目會集中體現在效率的提高以及成本的降低。在我們這個項目的背景中,我們使用人力成本的降低作為我們的數據標準,其公式為:
人力成本=各職能人員單位時間成本*用在該流程的總時間數
在這里稍微展開一下說明,有的客戶他們未必會愿意給你透露如此敏感的數據,但對于產品團隊內部一定要有一個量化的意識。
把需求目的量化有幾個好處:
- 量化了目標可以讓你知道有哪些維度是需要注意;
- 當你給用戶提供不同的產品方案時,可以通過計算不同產品的Payback time來看這個方案到底值不值得做(Payback time的會在后面解釋,當然,如果你只有一種產品方案那當我沒說);
- 在確定產品方案后,通過量化你可以觀察是否達到預期效果。
另外筆者在之前的經歷中看到一個有趣的現象,那就是要不要告訴客戶我們所用的數據指標是什么?
個人認為,當你的產品體系已經成熟時,其實可以考慮給客戶進行一個潛移默化的教育,讓彼此都有一個共同的評判標準之下,不容易被客戶把方向帶偏。而如果是你的產品還沒有成熟時,那最好先在內部進行打磨和驗證,不然就可能自己砸自己了。
第四步:制定一個需求調研的時間表
需求調研時間表其實是一個相當重要的工具,經過了第二步的對需求范圍的大概了解后,我們需要明確到每一天和哪一個人去見面?見面的方式是怎樣?希望能夠達到的效果是怎樣?整體的時間安排是怎樣?并且對時間進度進行每日的盤點和總結。
在需求調研執行過程中的溝通成本往往很大且容易被忽略,因此,我們會事先做出一個調研時間表和客戶那邊進行溝通,并且在內部進行一個時間監控機制,不斷總結經驗提升效率。
第五步:需求拆解,從了解現狀開始
無論是新業務的產生還是就業務的優化,都是依靠現有的流程為基礎,新功能的出現,對于ToB而言,往往會伴隨著職能甚至是組織的變化。如果說第二步只是了解需求范圍的大概,那么到了這里,就是到了真正開始落地的地方。
首先我們要了解這個需求涉及到的具體業務是什么?
每個具體業務里面又包含了哪些細分的種類,通常我會要求客戶提供一下他們關于這些種類的資料。如果客戶對這些資訊有所顧忌不愿提供,或者根據我們自身的行業知識和理解,對業務類型進行劃分并給到客戶確認,并對每個業務中的各個流程進行窮盡記錄和描述。
然后,把這些眾多的種類的業務中挑選出核心業務,這時候還有一個很重要的工作,就是知道有哪些需求我們不做?以及有一些地方我們一定不能做?
最后,把核心業務的流程圖描繪出來(我通常會用泳道圖),包括中間涉及到的部門人員,每一個步驟的操作詳細,權限和角色設置等等。完成這些之后,就可以開始構思解決方案的切入點了。
第六步:盡可能地提出多種解決方案
在了解完現狀和切入點之后,我們開始進行一個解決方案的設計,如果你的團隊在之前并沒有一個成熟的產品,基本上從0開始的話,那么我會比較建議你去構思的設計至少三套以上的產品方案,這樣會讓你對這個業務有更快地了解,而且最好發動你的團隊和你一起構思,這樣大家能夠一起學習,并且提高學習速度。
在找出集中解決方法后要找出他們的優劣點,并且嘗試計算出他們的Payback time,Payback time即回本時間,在我之前的項目是這樣計算的:
Payback time=開發成本/(現階段人力成本-系統運行后人力成本+維持系統運行的額外成本)
通過計算這個時間長度,我們也可以用于評估哪個方案更值得去做。
如果你的團隊有一個成熟產品,但可能只會提供一種產品的解決方案,那么你和你的團隊需要清晰現有的這個產品它的產品邊界和代價是什么?任何的產品都會有邊界和代價,要留意現在的產品是不是說真的符合客戶需求的動機。
復盤
無論是項目成功與否,在一個階段之后一定要在團隊內部進行一次復盤,同時復盤所希望能夠達到的目的一定要心理有數,而且有理有據,能夠用數據說話。注意復盤不是問責,而是團隊之間直接溝通和學習的過程,在我經歷過的項目復盤中,我們會圍繞以下幾個目的去進行復盤:
(1)檢查內部的效率
我們也會為我們的內部工作流程分解幾個步驟,然后記錄每個步驟的所用的時間,在復盤的時候會觀察哪個環節用時最多,加班最多,然后分析原因和優化的方法
(2)檢查產出的質量
這個主要是從最后的結果數據效果和期望之間的差距有多大,主要是檢查在當初設計產品時候是否有遺漏,推導產品結論所用的模型是否還未完善。
(3)知識分享
我們會分享一些關于競品或者是同行的資訊研究,也有一些同行的會把翻盤中間加上一些讀書會的分享,但無論如何,其目的也是為了提醒團隊不能僅僅顧著眼前事情,也要留意外界的事物。
最后,不要忘了把每次項目的文檔進行檢查和歸類,作為團隊的知識庫進行儲存,這也是提升團隊效率的重要工具之一。
在文章的最后,我們重溫一下這篇文章的幾個重點:
- 需求分析和產品設計是兩個相互獨立的部分,需要在需求調研階段去判斷這個產品是否值得去做;
- 在接觸需求后先了解背后的故事和動機;
- 為需求確定大概的范圍,找到合適的人去了解正確的信息;
- 量化你的需求目的以及評判標準;
- 制定需求調研階段的時間表,把準備工作做好,工欲善其事必先利其器;
- 需求拆分,了解需求中包含的每一個具體業務和流程,找出核心點,并且文檔化,同時要明確哪些不做,哪些禁止做;
- 嘗試尋找多種解決方案,并通過計算Payback time評估哪種方案更合適,對于某些已經成熟的產品則需要分析產品界限,以檢查是否滿足需要背后的動機;
- 每隔一段時間進行內部復盤,不斷提升效率同時做好內部的知識管理。
作者:Leo,一個喜歡研究的產品汪,一個新晉的貓奴,在創業公司待過,也在500強的外資咨詢公司待過,我相信人的一生應該是為了做成某一件事而活,希望可以結識更多同樣喜歡產品這條路的朋友。
本文由 @Leo 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
是不是打錯字了???PMI-PBA吧
對
寫的還是不錯的,但感覺沒有實例支撐還是比較空洞 ??
謝謝你的意見,其實我在寫的時候,都有一種隔靴止癢的感覺,但是如果真的把內容寫得太細的話,或多或少都有泄漏一些客戶信息 ?? 或許之后可以再改進下