編輯導讀：產品經理屬於新興職業，沒有太多職場老鳥能帶人，除了少數大廠擁有完備的產品體系，大部分產品人都是摸著石頭過河，也就是所謂的「野路子」。那麼，作為一個小公司產品經理，該如何改善野路子習慣，構建自己的方法論呢？本文作者依據自身產品實踐中的所思所想，結合案例對上述問題展開了分析探究，與大家分享。
所謂「野路子」，即沒有規範的工作方式，做事情沒有依據，想到哪做哪，做到哪算哪，經常會陷入自己不知道幹嘛的境地，這樣的工作狀態會極大的降低工作效率，長期以往甚至會影響自己的工作情緒。
如何改善「野路子」，即流程化、標準化做事，最佳的方法就是定義Standard Operating Procedure(標準作業程序），以下簡稱SOP，讓自己在遇到問題時有所依據。
下面我將結合個人經驗，詳細闡述產品工作中如何通過定義SOP，改善野路子，形成自己的產品方法論。
一、定義與同事配合的工作流程
1. 了解網際網路公司需求迭代的流程
如圖：
2. 明確自己需要做以上流程中的哪些事
根據自己公司的情況細化，明確自己需要做以上流程中的哪些事，比如我司就需要產品做需求調研、產品設計、產品方案宣講、研發過程跟進、收集反饋這幾類事情。
3. 確定以上的事情需要哪些人（WHO）對接，以及如何(HOW)和他們對接
（1）需求調研
需求調研根據需求來源一般分為兩種：
一種是內部需求，一種是外部需求。內部需求對接人包括BOSS、研發、測試、運營、市場，這些需求調研的工作和他們約好時間，反覆溝通直到雙方都沒有異議就可以了；
外部需求一般對接人是客戶，要複雜一點，懂得隨機應變，不要當場答應實現需求，只要做好訪談記錄，回來可以和決策人（一般小公司是boss，有些是產品總監或者技術總監）講清楚大概需求，至於要不要做，怎麼做，什麼時間做（需求優先級的問題），這些問題留給決策人。
（2）產品設計
產品設計一般情況下是初級產品經理最重要的工作，設計過程中的對接人主要是需求方，有時也要需要技術參與討論方案可行性，最重要的是和需求方反覆確認以保證最終的方案過關，這一點會在定義自己工作的SOP中詳細討論。
（3）產品方案宣講（評審會）
產品方案宣講，一般對接人包括UI/研發/測試，有時需求方也會參與。這時候要提前預約時間，準備好產品方案的產出物，比如流程圖、功能架構圖、原型圖、PRD文檔，如果涉及項目管理，要在禪道等團隊協作的工具中建好需求號，便於開發人員領任務。
宣講的順序一般是先業務流程圖，再功能架構，然後根據業務流講一遍原型圖，至於文檔就不用講了。記得講完一定要同步，如果團隊有同步的軟體，比如svn,git，也可以用郵箱，我們公司用的git，然後在群裡發一句，「**原型圖V1.0.0,PRDV1.0.0已經更新至git，請有需要的小夥伴自取」。
【PS：請在每次需求變更後，及時更新為原型圖和PRD文檔，並同步給相關同事，必要時重新開會強調變更，這一點尤為重要】
（4）研發過程跟進
研發過程中可能會出現各種各樣的情況，對接人一般是開發和測試。比如開發、測試不理解需求，你要解釋；開發、測試發現需求有些情況沒有考慮到或者有規則不清晰的，你要補充需求（這種情況雖不能完全避免，但越少越好）；甚至，前後端聯調出現問題，需要你定義接口。總之，就是在開發過程中一切的問題你需要負責解釋。
（5）收集反饋
收集反饋一般對接人是運營或者用戶，這裡主要是記錄上線後出現的問題，為後續產品迭代提供依據。
以上的5點是僅為個人總結的內容，不同公司的情況可能略有不同。
二、定義自己的工作流程
最重要的就是產品設計SOP的定義，這個過程需要自己反覆思考總結，每一階段都有相應的輸出物，並且在平常工作中不斷實踐才有效果，以我總結的產品設計SOP為例：
需求調研→業務模型搭建→流程圖→產品功能架構→原型圖→PRD文檔
1. 需求調研
這一步需要儘可能多的收集需求的信息點，包括需求的目的，參與的角色，上線時間，很多細節的想法等等。如果只是需求方只是一個人，那麼他會提關於很多需求的描述，儘可能記下來；如果是頭腦風暴式的需求，那麼有不同的人提出不同的需求描述。
以PCG(Professionally-generated Content)的課程APP為例，A可能說課程要能定義屬性（視頻/文檔），包括價格，名稱等，B可能說課程要能下架，下架後前臺就看不到了，C說用戶要能夠選課程，購買課程，D說要有購物車，只要是會上沒有發現有明顯問題的信息，統統記下來；我一般用onenote分點記，很多人喜歡用思維導圖。
示例：
推薦工具：onenote
2. 業務模型搭建
根據需求調研記錄的信息點搭建業務模型，最重要的是梳理主流程，聽起來好像很難，但實際操作比較簡單，在草稿本上列兩點：參與角色、每個角色涉及的操作。
同樣以上述課程APP為例，涉及到的角色：包括平臺運營人員、用戶，涉及到的操作：平臺運營人員上架課程，用戶選擇併購買商品；注意，這裡涉及的操作不是要列系統中詳細的操作，而是業務過程中完整的閉環操作（包括線上、線下）。PCG的內容是自己生產的，所以線下還包括製作流程，那麼完整的業務模型應該是：
運營人員製作課程→運營人員上架課程→用戶選擇併購買商品
注意：業務模型的搭建一定要閉環，所謂的閉環就是實現最終的效果，比如C端的產品一定是要通過用戶直接購買/廣告/增值服務賺錢的，B端產品一定是要解決閉環解決問題的，一定要考慮系統層面做到哪一步，作為需求的邊界。
我一般只會粗略的列，因為這個時候列得太細反而會干擾自己的思考。
推薦工具：草稿紙，筆
3. 流程圖
一般畫三種業務流程圖，功能流程圖，任務流程圖。
業務流程圖一般用泳道圖（如有並行則用UML），主要是根據搭建的業務模型，在相應的泳道裡按照順序畫出每個角色的操作。切記，不要想一步把所有流程畫在一個業務流程圖中，只需要把整個過程中最關鍵的一條/多條業務流畫出來即可，否則適得其反。
示例：
功能流程圖：主要是為了實現某種具體的功能，比如支付功能的驗證流程，需要給出不同情況下的結果說明，包括支付成功的流程，支付失敗的各種異常流程，開發很有可能拿著你的流程圖去寫邏輯判斷的，測試可以直接拿著流程圖寫測試用例；
示例：
任務流程圖：是為了實現某種任務的整個流程，只會在關鍵節點做判斷，主要是為了讓開發和測試知曉用戶的核心使用路徑。
示例：
推薦工具：ProcessOn
3. 產品功能架構
產品功能架構是就是用思維導圖呈現，該產品需求包含哪些模塊，這些模塊包含哪些功能；
示例：
推薦工具：X-mind
4. 原型圖
用界面化的方式展現元素，一般分角色，把對應的模塊列在相應角色的文件夾下，先把框架搭起來，再從數據流的角度一個一個頁面去畫，我一般會把頁面跳轉和一些動態面板的交互畫出來，比只畫靜態頁面要直觀很多。
過程中會有很多創意和想法，記錄下來，畫完自己按照流程跑一遍，看下有沒有流程上的障礙，如果有的話，記錄下優化的點，逐個優化。
原型圖需要保留版本，每更新一個版本同步更新給團隊成員。
示例：
推薦工具：axure
5. PRD文檔
PRD文檔每個人寫法不同，不必按照別人的模板生搬硬套，現在很多團隊敏捷開發直接在原型旁邊標註，看起來很方便。我一般是在原型旁邊註明重要的邏輯，另外再寫一份Word文檔。文檔需要做一個目錄，方便後期定位，還有每次更改的記錄，最好在相應的位置標上最新更改的時間並顯紅，內容主要包括流程圖、功能架構圖、功能描述、原型圖。
（1）流程圖
把業務流程圖貼在PRD文檔的總述裡，記得axure第一頁也貼一份，功能流程圖、任務流程圖貼在相應的功能描述下。
（2）功能架構圖
功能架構圖在PRD文檔綜述裡貼一份。
（3）功能描述
功能描述需要分角色、分模塊，分頁面，一般是一個頁面一段描述，彈窗放在同一段描述，但也不絕對，也可以用功能點劃分，比如列表、增、刪、改、查，規則就是用MECE（互相獨立，完全窮盡）的原則分清楚，具體描述主要包括三個方面：
數據的呈現，這個頁面呈現的數據是哪裡來的；每個原型每個元素的描述，按照原型的頁面，從左到右，從上到下擼一遍，每個UI/欄位代表什麼意義，有哪些規則，每個操作相應的頁面變化是什麼，數據變化是什麼，想清楚，寫出來；描述異常情況，每種異常情況對應的頁面是怎麼樣的，提示是什麼。功能描述就是窮盡所有你能想到的注意點，如果你自己都覺得哪些規則好像不對勁，那一定是哪裡沒想清楚，一定要靜下心來好好理理，否則開發和測試後面會找你的。（4）原型圖
在每段功能描述下貼上相應的原型圖。
PRD需要記錄版本，每一版本記錄修改的地方、時間等，而且每次變更及時修改並同步給團隊成員。
示例：
在小公司沒人指導一定要勤於總結經驗並運用在以後的工作中，不斷調整，最終形成自己的方法論，這樣一方面可以提高自己工作的效率，另一方面不論是轉行或是跳槽都能很快的適應，為以後的工作打下堅實的基礎。
以上。
本文由 @娃哈哈 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。