從需求到實施整流程及相關文檔模板（附一個案例）

1、前言

　　從事IT好幾年工做，經歷C端的設計也深刻作了B端的設計，在不斷學習、實踐中逐漸造成本身的設計方法與工做習慣，藉此分享出來以便吸取更多高手的意見與想法。

 

2、設計的業務流程

2.1涉及理論

　　整個文章或者分析方法都是基於「用戶體驗的五要素」的框架來分析的，因此有興趣能夠直接看那書會更直接的。

　　可是這裏要說一點，產品經理應該「重點分析戰略層」，而不是結構層如下的細節設計。產品核心，產品設計出發點不同，產品細節的設計也會跟着不同，而產品經理的最大做用是帶領這個產品往一個方向前進，而不是陷入在細節設計裏面。

 

2.2個人設計業務流程

 

3、一個案例的分析

3.1背景描述

　　是關於OKR系統的設計，公司有一套線下運行的OKR考覈制度，可是沒有線上化。整個項目持續接近3個季度（OKR是一個季度一次，因此校驗有點麻煩。）

　　從一開始的設計，到V2.0的簡化，到V3.0的產品化設計（小版本就不寫了，這裏寫的是產品形態發生比較重大改變的版本）。前兩個版本因爲是公司內部系統，也適合展示在這裏，因此這裏只展示V3.0我我的對OKR這個系統的設計想法，並從這個案例裏面講解下怎麼分析設計。

　　備註：3.0的設計，其實不少是借鑑worktile的設計（這裏不是廣告，而是競品沒多少，它的設計，相對好點），有興趣能夠直接使用那系統。

 

3.2初步分析

一、分析內容截圖

 

二、使用文檔：腦圖、excel

三、分析內容

　　A、OKR相關知識與競品：這個是設計這個產品的理論基礎，若是連基本的理論都不知道，就很難設計出準確的產品。

　　B、干係人：主要明確誰能夠提供什麼幫助，有問題能夠找誰。不過這個是項目管理的範圍，簡單看看就好。

　　C、產品分析：

　　　　C一、產品原始核心：核心解決什麼問題？一開始不用在意太多，越純粹越有價值。後面再根據公司實際狀況調整「目標產品能作什麼，不能作什麼，主要解決什麼問題」。

　　　　C二、理想的業務流程：最理想狀況下設計的業務流程，由於每家公司的業務流程絕對是有差別，這些差別必然有好有很差，可是通用、客觀的流程都是通用的，總不可能ERP系統不是解決貨物流轉業務？

　　　　C三、競品分析：偏重產品設計核心理念、優點、缺點這些便可。

　　D、設計疑問：若是已經有收集好的原始線下資料，就能夠根據理論與現實或者原始調研資料，分析該流程合理與不合理，並整理出設計疑問以便業務調研或者之後追查記錄用。

四、注意點：

　　A、只作收集資料與積累原始知識就好，不要作判斷。

       B、這階段主要是判斷作不作，投入產出。雖然大部份內部系統，這個決定權都不在本身身上，可是能夠經過資料收集，產品初步建模，判斷能作什麼，不能作什麼！

 

3.2業務調研-明確角色

一、分析內容截圖：

　　A、設計的業務流程

　　B、抽象後的業務流程

　　C、抽象後的角色用例

 D、狀態機

二、使用文檔：流程圖、角色用例（VISIO）

三、分析內容：

　　A、原始業務流程：原始的業務流程必需要忠實記錄原始記錄，不少人習慣在記錄原始記錄的時候，增長本身的優化、想法，結果扭曲了現實。之後別人看那些文檔的時候，無法知道當時的實際狀況，須要從新調研。

　　B、抽象後的業務流程：根據UML建模方法抽象出通用的業務流程。

　　C、抽象後的角色用例：其實這階段，更加關鍵是明確最主要的角色用例，細節能夠不用那麼仔細分析，在頁面設計的時候再去詳細分析頁面的角色用例，會好點。

        D、狀態機：某一事物的狀態變化圖，這個是比較基礎的設計，UML建模裏面的內容，新手常常忽略（我也忽略了~）。

 

3.3架構/框架設計

一、分析內容截圖：

　　A、功能框架

　　B、頁面框架

二、使用文檔：功能框架（VISIO）、頁面框架（AXURE）

三、分析內容：

　　A、功能框架：這個沒什麼好寫的，跟網上這個的做用同樣，主要是比較宏觀點看清楚整個架構而已。

　　B、頁面框架：這裏有個我的習慣，我會將頁面框架跟功能框架比較統一的創建起來，這樣後人或者本身看到這個原型，就能夠根據實際頁面找到對應的原型、細節，省事不少。（其實原型頁面還有一個命名規範，不過好久沒弄，就算了。）

 

3.4頁面細節-需求文檔

一、界面截圖

　　A、原型設計

　　B、需求文檔

二、使用文檔：AXURE、word

三、細節點：

       A、每一個頁面都創建專屬的「頁面目的」、「參與角色」，而後用VISIO畫出這個頁面的專屬角色用例。由於這樣，可讓你的設計更加專一，頁面的目的清晰，核心業務流程清晰，同時也能夠分析角色在這個頁面裏面的全部需求是什麼。

       B、需求說明書其實就是將以前的整合在一塊兒，這裏網上找個模板就好，關鍵是要寫清楚邏輯細節。

       C、原型設計：建議遵照必定的交互設計原則，我是爲了方便隨便畫了下而已。

 

3.5開發實施

　　一、版本及功能明細

　　能夠用來讓開發評估工做量，而後總體去看。不事後來這種表不多用了，緣由是維護不方便，並且從0到1的時候，挺好用。可是1到N的時候就不方便了，改用項目管理工具，按 「需求」或者「任務」來評估就好。

 

　　二、里程碑計劃

　　這個能夠明確這個功能、這個範圍該由哪位負責，若是團隊比較大的時候，這個很是有用，團隊協同起來會比較方便，想知道這個誰負責，看文檔找對應人就行了。

　　項目過程的管理，如今基本都用工具，因此若是系統工具玩得好的時候，後面我也少用這些文檔了。

 

3.6試運行

　　一、需求收集表

　　這個表很是重要，創建這個產品的需求池，有了需求池之後的迭代開發才方便。若是用工具去記錄不是說不行，可是有一些分析很難在上面記錄。

　　並且個人表是優化過的，適用我本身。由於我關注「原始需求描述」、個人「簡要分析」、知足狀況這三點，其餘的對於我來講沒什麼做用，我都刪除了。

 

　　二、問題收集表

　　這個表若是沒有系統的話，仍是有必定價值，用項目管理系統會更簡單。不過關鍵是，從這些問題裏面，發現新的需求，或者對這些的分析，這些就只能在本身的文檔裏面記錄了。

 

4、設計中涉及的文件模板

　　最後說一個我的的小習慣：每次開新的項目、產品線，我都會複製一套這樣的模板。這樣能夠方便本身快速分析，不用每次從新建文檔，更名字，配置好文檔裏面的格式，這個也是這篇文章出來的根源。

 

 

5、結尾與反思

　　寫完這文章以後發現，其實這方法更加偏重企業內部或者B端的產品，針對C端或者市場類產品，須要對市場的分析或者初始階段的分析比較重要。不過通常不多人有機會作那些C端市場分析，大可能是接受到一個需求，而後設計一個需求。

　　一樣，雖然看上去是整個大功能的需求設計，可是其實細節需求也同樣，每個明確需求如「放寬輸入限制」這種明確需求，也是須要分析提這個需求的人所處的角色、他的場景、他的目的，最終纔是決定方案，其實分析的流程也是從戰略到細節，只是中間省略了部分環節而已。

5.1這套方法的優勢

       A、比較系統、框架去設計一個產品，相對會專業、完整一些。

       B、關注產品的核心而且進行深刻分析、記錄，這點比較少人會去作，初級的產品大可能是直接畫圖，不多會去分析產品核心並記錄下來。

5.2這套方法的不足

       A、偏重產品設計，相對運營、冷啓動等方面的產品工做比較少涉及。

       B、缺乏整個產品的進度判斷，roadmap，產品數據，運營狀況的記錄與分析。

       C、缺乏整個產品模式，生態，或者宏觀、總體的設計，偏重個體功能塊。

 

 

       以上是我我的對產品設計的一些看法，純屬我的見解，若有更好的歡迎下面評論一塊兒討論，研究下。

 

　　最後想作個測試檢查本身寫的文章「淨推薦值」（NPS）有多少，想指望看完此文章的讀者麻煩私聊（記得帶上文章標題）或者評論回覆：

　　問題是：願意推薦程度從0（最低）-10（最高）分之間打分，這篇文章你是否願意將這篇文章推薦給你的朋友或同事？

　　須要回覆：願意推薦程度多少分？