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

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

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

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

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

從一句話需求開始

很多人剛開始做需求分析的時候，面對的基本都是上面的一句話，“XXX，我們的APP中需要加一個購物功能，就是直銷功能，就和XXX一樣，你按照我們APP的特點調(diào)整修改一下，很簡單吧。”我想聽見這句話的你一定是一臉懵逼，不知道說什么。

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

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

如何整理產(chǎn)品的業(yè)務(wù)流程

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

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

好的，那我來總結(jié)一下：

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

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

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

那么有了一個大概的業(yè)務(wù)流程之后，如何來降低業(yè)務(wù)流程維度，將其轉(zhuǎn)化為功能流程呢？

功能流程的前奏-功能結(jié)構(gòu)圖

有了業(yè)務(wù)流程之后，我們?nèi)绾问崂沓龉δ芰鞒棠?，相信許多小伙伴依然一臉懵逼，不知該如何繼續(xù)往下。這時候，上面的第一個who就起作用了，作為發(fā)起者，我們可以將屬于它的流程都整理出來，那讓我們舉買家這個發(fā)起者為例，給大家演示一下。

首先我們整理所有發(fā)起者為買家的業(yè)務(wù)流程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相關(guān)閱讀

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

本文由 @Chris 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議