項目需求需要把握項目整體的方向和宏觀的需求，本文作者從自己的實戰經驗出發，結合實際案例，對項目需求進行分析梳理，并記錄了自己的相關思考，與大家分享。

項目從立項開始，需求定義就是把握項目整體的方向，宏觀的需求。換句話說，就是業務的需求，明確項目的目標和范圍。

那么在需求立項階段，如何進行需求定義，根據筆者的經驗需要結從下面三個方面來進行考慮和設計：

1. 需求定義的策略
2. 需求定義的理念
3. 需求定義的范圍

一、需求定義的策略

在項目的立項階段，都會輸出一些立項項目書之類的產物，但是大多都比較空洞和混雜。從筆者的項目經歷來說，從兩個方面總結比較清晰：

1. 內部需求

B端的產品的職責是提高企業的內部運轉效率，并為組織提供高效的協同管理，在市場上為企業經營創造機會。

大型企業中，當一個項目目標比較空的時候，找到項目的發起人，可能是部門領導，也可能是高管，進行深入溝通，了解戰略規劃上的第一步。

2. 外部工作

另外就是想做一個項目來實現業務需求或著商業盈利，當下又沒有方向，那可以從外部參照物，包括實地考察，競品分析等等

二、需求定義的理念

項目在立項階段總結起來無非就四個字：問題、機會。

• 問題：當前項目要解決一個什么問題，為企業解決一個什么癥結，難題；
• 機會：抓住一個什么機會，實現怎么樣的商業價值；

三、需求定義的范圍

需求范圍的定義是一個很重要的工作，范圍定義不清楚，容易做很多無用功與重復性操作，對需求的管理也會雜亂無章，新設計一個系統，怎么進行需求范圍的梳理和定義，下面結合一個筆者做過的項目進行復盤。

四、案例說明

1. 背景說明

共享充電寶項目現在已在大街小巷普及，共享業務已經越來越普及到生活，包括共享單車，共享座椅，共享男友……

2. 需求定義策略

共享充電線項目，依托于掃碼支付與單片機硬件技術，在網吧，酒店房間等場景直接鋪設。

用戶在上網，或者賓館，茶樓，手機沒有電時，可以直接掃碼支付后充電，省去至前臺掃碼獲取充電寶動作。

與移動充電寶相比，充電線不需要充電箱為充電寶充電，用戶也不用到處找歸還的場地。在酒店，網吧等場景，充電線的鋪設與使用，比充電寶靈活，并且可獲得大量C端用戶數據進行會員運營

3. 需求范圍定義

經過第一輪的調查，整理出其各部門總結：

• 用戶：掃碼支付，獲得密碼，在充電線單片機客戶端輸入密碼，開機充電；
• 商家：網吧，酒店等業主，鋪設設配，消費者掃碼支付獲得相應的分潤；
• 代理商：拓展渠道，發展下級代理商及商家，管理設備，并獲得分潤；
• 平臺：1）管理設備 2）管理代理及商家 3）定價 4）管理分潤；
• 廠家：生產設備，進行發貨。

這里首先給出一個定義：主題域

當面臨一個新的系統的時候，可以將這個系統看成一個黑盒子，將其劃分成不同的主題域，再通過一張構件圖找到各主題域之間的關系。

什么是主題域？不就是子模塊菜單嗎？下面來做個對比

在筆者采用主體域劃分系統前，是這樣劃分的

我想大部分產品經理都是這樣劃分的，這種傳統的劃分方式，按照邏輯，把這個系統按照不同的部門，劃分成不同的模塊。再對單獨不同部門進行調研。

但是這樣劃分了以后發現，只是邏輯劃分，并沒有把業務流程串聯起來，在分析的時候，會漏掉業務。為什么產生這樣的結果？

傳統的方法都是按照“業務名稱+管理”來命名，業務名稱實際就是業務實體，也就是“物”的線索。試想，我在設計商家管理，我就會想：商家要做什么事呢？設計庫存管理，會想庫存要怎么計劃和顯示？設計發貨管理，會想發貨要怎么走？

現在看來，這并不是最佳的方式，因為業務系統，會大量的業務流程的聚合，以及充斥著千絲萬縷的層級關系。若單獨去考慮商家和代理管理，是不是就把這兩個業務實體割裂了？而這兩個“物”其實是有關聯關系的。

五、采用主題域劃分

1. 節點梳理

但是，當我換了一種方式，以“事”為線索，順著事務流程，業務脈絡，劃分成不同的節點。再把這些業務節點下梳理出的邏輯設計與功能設計聚合放入對應的應用端，形成主題域（類似于子系統），系統的一下就變得清晰起來。

我們按照業務流程，劃分出三個節點：掃碼，支付，獲取密碼

1）節點1：掃碼

• 用戶進行掃碼，我們自然想到，這個碼從哪里來，再倒推出生碼，賦碼管理
• 掃碼以后，進行設備查詢，那么就涉及到二維碼和設備如何關聯，設備的激活，禁用，上下架，倒推出需要進行設備管理

2）節點2：支付

• 接下來進行支付，在掃碼查出設備以后，需要查詢當前設備的價格，不同的設備肯定有不同的計費規則，并且滿足調價需求，那么就需要一套靈活的計費配置來管理，可以把這個功能放入結算管理中
• 用戶掃碼可能會多個掃碼入口，微信，支付寶，聚合支付，外置瀏覽器，這個時候需要對支付流程進行設計

3）節點3：獲取密碼

• 用戶獲取密碼的方式，頁面還是短信？若獲取密碼結果通過短信，則需要對接短信服務商，且需要用戶填寫手機號，拿到手機號又可以進行進行會員管理，進而推出會員管理。
• 密碼規則：硬件如何記錄使用過的密碼？

以上從業務角色1（用戶）的業務流，找到了三個節點，并沿著業務脈絡梳理出了業務功能及設計邏輯。

現在再從業務角色2（代理商）的業務流梳理

4）節點4

分潤規則：代理商，平臺，商家的分潤規則，分潤是按照代理商層級來？還是地區來？還是設備來？再往上梳理，那代理商層級是怎么設計，代理商怎么授權商家？

進而進行代理商和商家的層級體系設計，授權流程設計。最后分潤規則的靈活配置放在結算管理進行管理，代理商層級配置放在后臺代理商管理進行管理。

5）節點5

現金提現：商家提現，代理商提現的限制，審核流等，屬于結算的內容

2. 析出主題域

通過以上的梳理，以一個業務流程為基礎，沿著節點梳理，每個節點會涉及到不同業務流程，再把這些業務分配到不同的應用范圍里面，形成主題域，這樣就理清了系統的脈絡，給需求規格說明書提供了一最初的結構目錄

3. 使用構件圖

什么是構件圖？為什么要畫構建圖？

構件圖就是劃分主體域之后，對梳理出來的脈絡進行進一步整理，找到各主題域之間的接口關系之后的關系圖。

如果單獨采用之前的層次結構，只是體現了分解結構，就會隔離各個業務，忽略了各個主題域之間的關系。構件圖就是為了明確各主題域之間的關系，明確主題域之間接口關系的另外一個作用也是作為需求變更的防火墻。創建構建圖后，如下：

當然，接口的定義很廣泛，有技術上各個類之間的接口，構件之間的接口，對于需求而言，這里是從業務的角度來說，各個主題域之間的接口。

關于主題域的思考

在以上案例，由于項目案例的業務很簡單，按照一兩個業務流程就能確定主題域，并且只通過一級就確定了主題域。

我們的目的在于如何通過主題域的設計思想，來為需求范圍定義提供系統建設的分類參考，而對于B端復雜的業務系統，業務流程眾多，怎么樣能理清主題域？還有幾種方法：

1. 以組織結構為線索：在組織復雜聚合的情況下，組織部門的邊界可能就是主題域的邊界；
2. 以分管領導為線索：按照領導權力邊界劃分；
3. 以典型的業務職責區分：例如很多企業/組織都有自己的產品生產，銷售，供應等環節。

結語

以上便是筆者根據實戰項目，對項目需求定義的一些思考，作為個人的復盤和記錄，希望對你有幫助，歡迎指正和評論。

本文由 @謝君翊 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議