中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

當一個產品經理接到一個復雜且自己完全陌生的需求時，要怎么將一個復雜的業務，從頭拆解轉化成產品需求？本文主要講解該如何拆解，一起來看看~

業務導向型產品，每個功能背后都隱藏著復雜的業務邏輯，作為此類產品的產品經理，當接到一個復雜且自己完全陌生的需求時，如何一步步拆解搞清楚它里面隱藏的邏輯和細節規則，并成功轉化成產品功能和輸出清晰的產品文檔？

本文復盤一下自己的實施步驟和過程，為以后處理類似復雜需求積淀思路和方法論。

一、理解名詞

每個業務領域都有專有的業務名詞，理解需求首先要搞清楚它涉及的專業術語。理解了相關術語，對這個需求相關的是一件什么樣的事情，就有了一個初步的概念和認知。

其中，了解的方法有兩種：

（1）向需求提出方詢問：“XXX是什么意思？”

一般情況，業務人員會從這項業務是干嘛的來展開介紹，在這個介紹里，你可以得到的信息包括但不限于：

1. 這個需求涉及的業務干系人（用戶來源）；
2. 這個需求的關鍵操作（功能拆分來源）；
3. 這個需求的操作流程（流程來源）。

（2）借助網絡查詢詞語最通俗的釋義

業務方的介紹可能是從他們專業的業務操作上進行的，這對一個新手來說，有可能還是過于晦澀和專業，為此你需要自己通過網絡理解名詞背后最通俗的含義，有可能會有多重解釋，但你能辨別出哪一種解釋是跟你相關的。這一節點應該輸出“名詞解釋”列表。

有了上面的理解，就大致知道了需求是干嘛的，那實際的業務中，是如何操作的呢？經過了什么樣的流程節點呢？

二、整理流程圖

這個過程會經歷兩個階段：

（1）流程圖草稿：把理解到的都用流程圖的方式表達出來，不分泳道、不糾結流程節點命名、也不用在意這個節點該不該畫出來，畫出最粗又是最細的流程圖。粗是因為不分泳道很多節點也不合理，細是因為把聽到的理解的都作為節點畫出來。

這時候不要畫泳道圖，因為對業務還模糊不清，抽象不出合理的泳道，如果一開始就設計泳道圖，反而會花費較多時間和精力，但效果并不理想。

（2）細化流程圖：經過對業務的不斷調研，草稿圖越來越完善越貼近真實業務，可以說對業務的整個流程有了宏觀上全面的認識，那么就可以抽象泳道精細化節點來細化流程了。

這時候輸出的流程必須是泳道劃分合理，流程節點粗細適宜，節點命名合乎業務的。但是這時候的流程有一點還是會有欠缺，異常流程和判斷節點往往會缺失。但不要緊，后面的一步會幫助我們把這些細節都考慮清楚和全面。

這一節點應該輸出：

• 一是流程圖草稿（只給自己最初理解業務用）；
• 二是業務流程圖（用于向其他團隊成員講解和幫助他們理解業務）。

三、整理狀態遷移圖

業務型產品在研發實現上很重要的一點是狀態，狀態控制著整個業務的流轉和什么時候什么人該干什么事，不合理的狀態劃分使得代碼的難度和體量呈指數增長（因為每多一個狀態，程序在做任何一個判斷的時候，都要去判斷一遍它），因此狀態的劃分要足夠合理和精細。

（1）抽象對象：顧名思義，狀態用于標注一個東西在不同條件下的情況，那么整理狀態遷移前提是先要有對象。

在業務導向型的產品中，這個對象往往是業務操作過程中產生的各種單據。如：訂單、退貨單、收款單等。

抽象對象的方法是：如果一件事情的完成需要不同的人在不同的節點做不同的操作才能完成，那么這個事情開始的時候就要生一條單據，后面的操作人都是對這條單據的操作。

（2）抽象狀態：處理對象的各個流程節點就是狀態，但是在梳理流程圖時，有些流程節點是輔助性的，它不影響整個業務的流轉，這樣的節點，不應該被抽象成狀態。

比如：在小明吃飯的業務中，評價是一個很重要的流程，顧客是否有做評價也是我們會統計和關注的點，但評價狀態并不屬于核心業務流，顧客有沒有評價跟就餐是否完成一點都不影響，因此評價的狀態并不適合抽象成主狀態。是否有評價給單據打個標記，能夠方便查詢和統計就OK了。

在梳理狀態遷移的時候，會發現流程里面沒有考慮到各種不同的情況，從而反過來指導完善了流程圖的設計。

這一節點應該輸出：各個對象的狀態遷移圖。

四、整理場景和規則

有了流程圖和狀態圖，就可以抽象出不同的業務場景。再根據場景逐個細化調研，從而獲得業務規則，其中，業務規則細化到每個細節的長度、類型等等信息，是真正走到業務里面了。

（1）抽象場景：對場景的抽象有兩步，一是把流程圖中的大節點抽象成一個場景，二是對大場景的不同情況進行細分，劃分出小場景。

這樣做的好處是：總的場景不至于那么多，理解查看和維護都方便，但又不會落下細節和特殊情況，保證產品設計的完整性。

（2）細化規則：有了場景，有了場景下的不同情境，就可以針對各個情境下的業務限制規則進行梳理和調研了。

這一節點應輸出：業務場景劃分列表、業務細節規則列表，應該注意規則列表是對業務場景的細化和深入。

五、需求輸出

有了上面的流程、狀態、場景、規則，對業務的理解已熟透到心，該著手設計原型、編寫文檔了。

這里對文檔的結構，我想應該包含這幾部分：

1. 名詞解釋：第一步已經準備了，整理下放進去
2. 流程圖：包括業務流程和狀態圖，第二、三步已經準備了，整理下放進去
3. 按場景劃分的章節安排：根據第四步的場景劃分，每個場景作為一個章節，場景中不同情境作為小節，具體包含的內容大概有：

（1）單據字段

（2）單據狀態

（3）單據搜索

至此，一個業務就被一步步拆分和轉換成了功能。

不難發現：拆分過程中輸出的文檔，最后就是需求文檔的每個組成部分，所以，拆分的過程也就是寫文檔的過程，拆分完了，PRD也就寫完了。

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

題圖來自Unsplash，基于CC0協議