一、定義與同時配合的工作流程

1. 了解互聯(lián)網(wǎng)公司需求迭代的流程2. 明確自己需要做以上流程中的哪些事

根據(jù)自己公司的情況細化，明確自己需要做以上流程中的哪些事，比如我司就需要產(chǎn)品做需求調(diào)研、產(chǎn)品設計、研發(fā)過程跟進、收集反饋這幾類事情。

3. 確定以上的事情需要哪些人（WHO）對接，以及如何(HOW)和他們對接——此處略重點哦~

（1）需求調(diào)研

需求調(diào)研根據(jù)需求來源一般分為兩種：

一種是內(nèi)部需求，一種是外部需求。

內(nèi)部需求對接人包括BOSS、項目經(jīng)理、運營、市場、產(chǎn)研團隊，這些需求調(diào)研的工作和他們約好時間，反復溝通直到雙方都沒有異議就可以了；外部需求一般對接人是客戶，要復雜一點，懂得隨機應變，不要當場答應實現(xiàn)需求，只要做好訪談記錄，回來可以和決策人講清楚大概需求，至于要不要做，怎么做，什么時間做，這些問題留給決策人。

（2）產(chǎn)品設計

產(chǎn)品設計一般情況下是初級產(chǎn)品經(jīng)理最重要的工作，設計過程中的對接人主要是需求方，有時也要需要技術參與討論方案可行性，最重要的是和需求方反復確認以保證最終的方案過關，這一點會在定義自己工作的SOP中詳細討論。

（3）研發(fā)過程跟進

研發(fā)過程中可能會出現(xiàn)各種各樣的情況，對接人一般是開發(fā)和測試。比如：

開發(fā)、測試不理解需求，你要解釋；開發(fā)、測試發(fā)現(xiàn)需求有些情況沒有考慮到或者有規(guī)則不清晰的，你要補充需求；甚至，前后端聯(lián)調(diào)出現(xiàn)問題，需要你定義接口。

總之，就是在開發(fā)過程中一切的問題你需要負責解釋。

（4）收集反饋

收集反饋一般對接人是運營或者用戶，這里主要是記錄上線后出現(xiàn)的問題，為后續(xù)產(chǎn)品迭代提供依據(jù)。

二、定義自己的工作流程

最重要的就是產(chǎn)品設計SOP的定義，這個過程需要自己反復思考總結，每一階段都有相應的輸出物，并且在平常工作中不斷實踐才有效果，產(chǎn)品設計SOP為例：

需求調(diào)研→業(yè)務模型搭建→流程圖→產(chǎn)品功能架構→原型圖→PRD文檔

1. 需求調(diào)研

這一步需要盡可能多的收集需求的信息點，包括需求的目的，參與的角色，上線時間，很多細節(jié)的想法等等。

如果只是需求方只是一個人，那么他會提關于很多需求的描述，盡可能記下來；如果是頭腦風暴式的需求，那么有不同的人提出不同的需求描述。

以PCG(Professionally-generated Content)的課程APP為例

A可能說課程要能定義屬性（視頻/文檔），包括價格，名稱等，B可能說課程要能下架，下架后前臺就看不到了，C說用戶要能夠選課程，購買課程，D說要有購物車，

只要是會上沒有發(fā)現(xiàn)有明顯問題的信息，統(tǒng)統(tǒng)記下來；一般用onenote分點記，很多人喜歡用思維導圖。

2. 業(yè)務模型搭建

根據(jù)需求調(diào)研記錄的信息點搭建業(yè)務模型，最重要的是梳理主流程，聽起來好像很難，但實際操作比較簡單，在草稿本上列兩點：參與角色、每個角色涉及的操作。

同樣以上述課程APP為例，涉及到的角色：包括平臺運營人員、用戶，涉及到的操作：平臺運營人員上架課程，用戶選擇并購買商品；

注意，這里涉及的操作不是要列系統(tǒng)中詳細的操作，而是業(yè)務過程中完整的閉環(huán)操作（包括線上、線下）。PCG的內(nèi)容是自己生產(chǎn)的，所以線下還包括制作流程，那么完整的業(yè)務模型應該是：

運營人員制作課程→運營人員上架課程→用戶選擇并購買商品

推薦工具：草稿紙，筆

3. 流程圖

一般畫三種業(yè)務流程圖，功能流程圖，任務流程圖。

業(yè)務流程圖一般用泳道圖（如有并行則用UML），主要是根據(jù)搭建的業(yè)務模型，在相應的泳道里按照順序畫出每個角色的操作。功能流程圖：主要是為了實現(xiàn)某種具體的功能，比如支付功能的驗證流程，需要給出不同情況下的結果說明，包括支付成功的流程，支付失敗的各種異常流程。任務流程圖：是為了實現(xiàn)某種任務的整個流程，只會在關鍵節(jié)點做判斷，主要是為了讓開發(fā)和測試知曉用戶的核心使用路徑。

4. 產(chǎn)品功能架構

產(chǎn)品功能架構是就是用思維導圖呈現(xiàn)，該產(chǎn)品需求包含哪些模塊，這些模塊包含哪些功能；

5. 原型圖

用界面化的方式展現(xiàn)元素，一般分角色，把對應的模塊列在相應角色的文件夾下，先把框架搭起來，再從數(shù)據(jù)流的角度一個一個頁面去畫，我一般會把頁面跳轉(zhuǎn)和一些動態(tài)面板的交互畫出來，比只畫靜態(tài)頁面要直觀很多。

過程中會有很多創(chuàng)意和想法，記錄下來，畫完自己按照流程跑一遍，看下有沒有流程上的障礙，如果有的話，記錄下優(yōu)化的點，逐個優(yōu)化。

原型圖需要保留版本，每更新一個版本同步更新給團隊成員。

6. PRD文檔

PRD文檔每個人寫法不同，不必按照別人的模板生搬硬套，現(xiàn)在很多團隊敏捷開發(fā)直接在原型旁邊標注，看起來很方便。

文檔需要做一個目錄，方便后期定位，還有每次更改的記錄，最好在相應的位置標上最新更改的時間并顯紅，內(nèi)容主要包括流程圖、功能架構圖、功能描述、原型圖。

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

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

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。