一句話的需求往往會讓需求對接的人員一臉懵逼，不知道從何入手。對于這樣的問題作者分享了自己的一些解決思路，希望你也能夠受用。

對于許多剛剛踏進產品經理崗位的人，可能都會對這個崗位有點陌生，不知道具體應該從何做起。我剛開始的時候也是一樣，也以為產品經理就是個畫原型的，所以根據需求大致歸納了一份需求說明書之后就開始畫原型，搭界面了。

但是做到后面會慢慢發現，很多頁面由于自己開始考慮的不周全而在實際開發中會出現許多問題，比如頁面跳轉的邏輯問題，頁面展示的內容缺少了一些內容等等許多問題。那么，究竟應該怎么去做呢？

說實話，我也不是很清楚，畢竟產品經理這個崗位并沒有形成一類系統性的科學方法論，很多人都只是按照自己的習慣或者公司之前項目養成的習慣在做著這份工作。我想你去問別人，估計也會問出幾千個哈姆雷特，說穿了，適合你們團隊的就是好的方法論。

那么我今天來拋磚引玉，說一說自己團隊的一個流程方法。具體內容由于涉及一些東西，不太好說，但是我會舉個例子方便大家理解。那么，我就說說大家最最熟悉的購物吧。

從一句話需求開始

很多人剛開始做需求分析的時候，面對的基本都是上面的一句話，“XXX，我們的APP中需要加一個購物功能，就是直銷功能，就和XXX一樣，你按照我們APP的特點調整修改一下，很簡單吧?！蔽蚁肼犚娺@句話的你一定是一臉懵逼，不知道說什么。

那么，面對這樣的問題，我們應該怎么處理呢？我個人的建議是從業務流程出發，將其逐步拆分，完善成一個具體到可以落地的內容。而拆分的過程就是先總結整個APP業務流程，然后將業務流程降低維度，拆分成多個功能模塊，每個功能流程再降維，拆分到頁面邏輯，落實到每個頁面中。

我想上面這個流程肯定很多人也看到過了，那么具體我們應該如何完成這個過程，并且在這個過程中要注意些什么呢，別急，往下看。

如何整理產品的業務流程

九層高臺起于壘土，合抱之木生于毫末。首先我們要完成業務流程，我個人喜歡用的就是業務3W法則來描述業務事件，即“who+what+who”，首先我們需要確定的是整個業務的操作主體，也就是我們所說的角色，第一個who。角色在前期我們要盡量考慮周全，避免之后出現問題，在這個例子中，由于是直銷，可能的存在的角色就是平臺，用戶，不存在商家的概念了。

另外，我們還需要確定行為目標物，也就是第二個who，這邊可能存在的行為目標物就是錢和貨物。what則是兩者之間的聯系行為（行為本身可能會包含目標物），是什么行為將兩者串聯在一起的，給大家30秒鐘時間考慮一下，自己羅列業務事件。

好的，那我來總結一下：

1. 平臺上架商品
2. 買家挑選商品
3. 買家購買商品
4. 平臺收到貨款
5. 平臺發送商品
6. 買家收到商品
7. 買家確認商品
8. 平臺結束訂單

好的，我們將這些業務事件串起來看一下，看看能不能形成一條完整的業務流程，如果可以，OK，接著往下，如果不行，繼續完善。在業務流程這邊不建議大家先開始思考各種分支情況或者異常情況。例如，要是買家收到貨，不確認商品，要退貨怎么辦？那么后面平臺也就收不到錢了。

這其實是買家收到商品后的一個行為，有確認，拒收，退貨，這都是買家行為，是下面功能流程中的分支。那么如何判斷你的業務事件中是否混入的一些異物呢？有個比較簡單的方法，就是你把業務流程想成瀑布或者樓梯，每個事件都是有層序關系的，不存在并列關系，如果這邊存在并列關系了，那么你的業務流程可能就出現問題了。

那么有了一個大概的業務流程之后，如何來降低業務流程維度，將其轉化為功能流程呢？

功能流程的前奏-功能結構圖

有了業務流程之后，我們如何梳理出功能流程呢，相信許多小伙伴依然一臉懵逼，不知該如何繼續往下。這時候，上面的第一個who就起作用了，作為發起者，我們可以將屬于它的流程都整理出來，那讓我們舉買家這個發起者為例，給大家演示一下。

首先我們整理所有發起者為買家的業務流程。

買家挑選商品->買家購買商品->買家收到商品->買家確認商品

我們可以把他理解為只包含一個角色的部分業務流程圖。

然后是將買家這個主體去掉，變成：

挑選商品->購買商品->收到商品->確認商品

這樣我們得到了4個功能模塊，但是這些功能模塊是由多個功能點組成，所以我們需要繼續拆分。我們這邊就以購買商品這個功能模塊為例，舉個例子。

首先我們需要確定購買商品是用戶已經完成了挑選商品這個步驟，到了付款的階段了。

那么接下來我們需要怎么做呢？接下來就是需要用到哲學終極三大問題了：“我是誰，我從哪里來，要到哪里去”，是不是聽著很玄，不知道我在說什么。請聽我慢慢解釋。

首先我們需要確定這塊功能涉及到的主體和客體。購買的主要客體其實就是錢和貨物。我們將兩個客體帶入上面三個問題，首先將貨物代入其中。

• 我是誰：需要的就是認清自己，即貨物包含的具體內容是哪些？即貨物的型號，顏色，也就是我們說的SKU描述，以及數量。然后我們根據需求去篩選需要的信息。大部分APP展現的就是商品的部分信息以及數量。
• 我從哪里來：貨物是從平臺那邊來。這邊由于主體是平臺，所以我從哪里來不用考慮。打個×。
• 要到哪里去：要到買家那里去。這邊主體是買家，所以保留，打個√。然后開始思考這個問題，衍生出了一系列的問題
• 買家在哪里，我要怎么去。這就是大部分APP訂單界面的用戶地址和郵寄方式這兩塊內容。

然后把錢代入這三個問題:

• 我是誰：也就是一共多少錢。也就是訂單頁面的總價格。
• 我從哪里來：錢是從買家那邊來。所以需要用戶填寫支付方式。
• 要到哪里去：要到平臺那里去。打個×。

是不是感覺差不多了，來我們整理一下。購買商品是一個功能模塊。

其中還有一些子功能點，即訂單貨物詳情確認，訂單貨物價格確認，訂單郵寄方式選擇，填寫收貨地址，選擇支付方式。

也就是說購買商品這個功能模塊中包含了以下幾個功能點。

看到這邊，有小伙伴可能會問了，你說的我都懂，但是這是啥？其實這就是一個功能模塊的功能結構圖。然后有人就會問，那說好的功能流程圖？

其實，你如果把上面4個功能模塊全部分解成功能結構圖，嘿，角色是買家的功能流程圖好像出來了。然后另外兩個角色的功能流程圖也采用一樣的方法，你會發現，嘿，整個功能流程圖都出來。

由于篇幅問題，今天就先談到如何做功能結構圖，下次再仔細聊一下如何做功能流程以及下一步的頁面流程。

相關閱讀

如何去完善一句話需求？（下）

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

題圖來自PEXELS，基于CC0協議