Java微服務一份征服上司的需求文檔(直接下載下傳)

Java微服務一份征服上司的需求文檔(直接下載下傳)

上個月，群裡面有一位朋友在報喜。說他按照我建議的方法編寫産品需求文檔和方案文檔，結果上司非常滿意。最讓他高興的并不是上司的表揚，而是他第一次擁有了“獨立掌控項目”的感覺。

我常說，優秀的産品經理一定可以寫出優秀的産品文檔。原因在于，産品文檔是産品思路的展現，同時，也反映了一個産品經理的職業态度。

那麼，優秀産品文檔的标準是什麼呢？今天我們就以産品需求文檔為例做一個簡要的講解。

01 需求文檔要點

一份優秀的需求文檔，必須符合3個要點，分别是：

• 結構清晰
• 深入業務
• 聚焦重點

1）結構清晰

結構清晰主要展現在三個方面，具體包括：

• 由總到分

優秀的需求文檔，不會一來就講具體的業務。而是首先從全局出發，先對企業業務進行概覽性的介紹。

比如，首先介紹企業的組織架構、業務模式等，這可以幫助我們對客戶需求的背景有更深刻的認知。

• 由高到低

和C端産品不同，B端産品的使用者往往是一個結構化的群體，包括了決策層、管理層和執行層等，而這些角色面臨的問題、對産品的訴求都存在較大差異。

優秀的需求文檔，會全面調研相關幹系人：從了解決策層的需求開始，逐漸下沉到執行層。

• 由内及外

在移動網際網路時代以前，大企業已經基本完成資訊化系統的建設。當他們采購SaaS産品以後，就必然要求将SaaS産品與現有系統整合，進而提高全局效率。

是以，産品需求文檔在梳理産品涉及業務流程的同時，也必須考慮到可能需要內建的其他系統。

2）深入業務

深入業務主要展現在兩個方面：

• 究竟精神

對于大部分使用者來說，他們畢竟不是專業的IT人士。是以，他們往往善于提出自己的期望，但并不善于結構化的梳理和表述需求。是以，如果産品經理簡單的對需求全盤接收，往往隻能看到需求的表面，而看不到需求的本質。

比如，采購員抱怨工廠中的房間生産計劃變動太頻繁，導緻采購計劃不得不臨時調整，增加了與供應商協同的難度。他們可能認為工廠中的房間生産計劃就應該在一定期間内強制當機。但實際上，生産計劃的不穩定可能有多種原因，比如，銷售公司臨時調整訂單等等。這種情況下，工廠中的房間根本就不可能當機生産計劃。

• 不止于需求

一般來說，SaaS産品主要負責對企業業務進行支撐。

比如，快消品企業希望管理銷售人員的外勤拜訪任務，SaaS産品就可以提供拜訪計劃、拜訪任務等功能。

但是，對于企業來說，産品隻是一種輔助手段，要實作“解決業務問題”的目的，往往還需要在管理、流程、政策等方面進行優化。

為了從根本上解決客戶問題， SaaS産品經理不僅僅要熟悉産品設計，也要了解相關的管理知識和案例。

而這些知識和案例，在需求調研階段就需要開始收集和梳理。

3）聚焦重點

什麼是SaaS産品成功的标志呢？

從财務名額來看，是續費率和增購率；從産品名額來看，是核心功能的使用率。但是，從本質上來說，他們都隻是結果名額。真正決定SaaS産品成功的，其實是“是否滿足了客戶的期望”。而客戶期望又包括三個方面：

• 業務重難點

即客戶購買SaaS産品，主要是為了解決什麼問題。為了解決這些問題，又需要實作哪些關鍵功能，或者克服哪些關鍵障礙。

• 決策人期望

SaaS産品往往有具體的購買決策人，他們既然決定購買産品，必然是有其迫切想解決的問題。搞清楚這些問題，才有可能實作客戶成功。

• 核心使用者期望

決策層的訴求往往高屋建瓴、目光長遠，但也是以缺乏對執行細節的關注。而SaaS産品畢竟需要落實到具體的操作層，是以産品經理也需要梳理和滿足核心使用者的合理期望，這樣才能實作“上下同欲”，克服SaaS産品應用的障礙。

以上三個方面，都是需求調研的重點，需要在需求文檔中進行闡述。

02 業務概述

優秀的SaaS産品經理，同時也是一個優秀的解決方案專家。是以，他在梳理需求時，并不會一開始就陷入需求細節，而會首先從整體上對客戶組織架構、業務模式、整體流程進行梳理，進而確定産品方案的高度和整體性。

具體來說，業務概述又分為3個部分，分别是：

• 組織架構與崗位職責
• 整體業務簡述
• 整體流程圖

1）組織架構與崗位職責

梳理企業的組織架構與崗位職責，主要有兩方面目的。

第一個目的是了解企業業務的分工與協作。

産品架構的本質，就是分工與協作。比如，為什麼采購管理和銷售管理往往是兩個相對獨立的子產品？其實本質上是因為，采購和銷售是兩個高度專業的工種，是以企業往往會建立兩個相對獨立的專業部門。

我們一直說，産品架構要“高内聚、低耦合”，其實它也是反映了企業分工與協作的特點。

是以，了解組織架構與崗位職責，有利于正确的梳理産品架構。

第二個目的是調研功能與資料權限的管理需求。

分工往往就意味着功能與資料權限的隔離。比如，采購經理崗位和銷售經理崗位，往往會配置設定不同的功能頁面；而不同僚業部的負責人，也隻會配置設定對應事業部的資料權限。

當然，在實際業務中，功能與資料權限的隔離往往不會如此簡單清晰。比如，某進階副總裁，可能會分管集團的HR部門，同時又分管一個獨立的事業部。如果有類似複雜的權限管理場景，就必須有專門的多組織架構權限管理方案。

2）整體業務簡述

雖然SaaS産品主要是對具體業務和管理的支援，但是決定這些業務和管理的，卻是更深層次的業務模式、商業政策等問題。

SaaS産品經理要想對客戶的業務和管理有更深入的認識，或者要想對客戶更大的影響力，就必須了解企業的業務模式和商業政策。具體包括以下幾個方面：

• 商業模式：客戶如何實作盈利
• 産品種類：客戶提供的産品與服務
• 行業地位：典型客戶屬于領先企業？還是追随企業？
• 銷售網絡：如何觸達消費者以實作銷售？
• 營銷政策：如何促進收入增長？
• 銷售規模：企業年銷售數量、銷售金額？
• 業務峰值：業務處理的高峰期

等等。

3）整體流程圖

通過一個整體流程圖對業務做一個概要的梳理，是非常有必要的。

一方面，通過梳理整體流程圖，我們可以確定詳細流程圖不會遺漏；另一方面，整體流程圖也便于内外部的溝通。不管是向高層彙報，還是和研發同僚溝通，整體流程圖都可以起到很大的幫助。

梳理整體流程圖，還可以提高我們的大局觀和整體感，并提高與高層溝通的能力。

03 業務詳情

業務詳情是産品需求文檔的主體内容。

業務詳情首先要與整體流程圖對應，以確定沒有錯漏。比如，項目管理類SaaS産品的整體流程圖，一般包括從立項到項目關閉的完整流程。那麼，在業務詳情部分，就需要分别對立項、項目計劃、項目進度管理、項目關閉等各個主要環節進行詳細闡述。

業務詳情又主要分為三個部分：

1）業務規則

主要對業務管理規則和機制等進行文字闡述，比如銷售價格核定邏輯、信用管控規則等等。

2）業務流程圖

通過流程圖對各崗位職責、協同關系進行闡述，也包括流程中産生的紙質單據，以及各流程之間的銜接等。

3）業務重難點

闡述各業務環節的重點和難點。這些重難點的解決，将在很大程度上左右客戶使用SaaS的成敗。

04 管理報表和系統內建

管理報表是決策層和管理層用于監控、分析業務的主要手段，是以必須在需求調研階段進行明确。

同時，盡早梳理管理報表還有一個好處，就是提前檢測SaaS産品的業務資料能否支援相關報表的出具。如果不能支援——考慮到決策層和管理層需求的重要性——則需要對産品功能及時進行調整。

除了管理報表，與第三方系統的內建也必須盡早進行調研。

05 使用者期望

這是需求文檔的最後一個章節，也是最重要的一個章節。

即便産品能夠較好的支撐起相關業務，并且在穩定性、易用性方面無可挑剔，使用者對産品的評價，可能仍然隻有60分。

這裡面的關鍵在于，“對業務正常支援”隻能避免“客戶不滿意”；而隻有滿足了核心使用者特别是決策層的期望，才有可能得到更高的評價，進而赢得客戶的忠誠。

在調研使用者期望時，越是牽扯面廣的系統，越要注意不能遺漏。比如，對于業财一體化系統，我們既要了解财務部門使用者的期望，也要了解業務部門使用者的期望。因為他們任何一方對系統的态度，都能很大程度上左右企業使用系統的成敗。

06 結語

我常說，SaaS産品經理要有結構化思維。那麼，如何培養結構化思維呢？

以需求調研為例，如果你能按照本文的結構進行調研和文檔編寫，以及檢查需求調研是否滿足結構清晰、深入業務和聚焦重點等要求，那麼就可以有效培養結構化思維。

最後需要說明的是，需求文檔是方案文檔的基礎。

實際上，需求文檔的結構和方案文檔的結構，整體上應該是一一對應的。這樣做的好處，就是讓整個産品文檔的思路非常清晰，這也是文章開始那位星友，為什麼能得到上司認可的原因之一。