Zi 字媒體

最近有小夥伴說覺得自己的工作流程比較亂，不知道怎麼梳理工作流，問我有沒有什麼好的方法…說實話我也沒有什麼好的方法，因為個人的工作流程肯定是從屬於組織的流程的，而某些時候我們能做的事情可能真的很有限。最近看到一個觀點，還是比較值得思考一下的，觀點來源於潤米諮詢創始人劉潤的《5分鐘商學院》。大致的觀點是當我們看到不努力工作的人，會傾向於指責這個人，其實這是不對的。人的問題的本質都是組織問題，要從戰略，到組織，最後才是人。說一個人不努力工作，如果他在你那裡不努力工作，到其他公司如狼似虎，就是你的問題了。上面植入的觀點算是對最近所見所聞的一些事情的小小感概吧…文歸正傳，後來我就梳理了下自己的工作流程，把整個過程中可能需要產出的一些東西整理了一下給小夥伴了。大家的工作流程可能都差不太多，基本上都是需求分析→競品分析→流程設計→產品設計→UI設計→開發測試→運營迭代…不同團隊的工作流程可能有些差異，但是核心的流程估計都差不多，所以我就按照這個流程來梳理一下自己在工作中可能會產出的一些圖，希望能夠給大家帶來一些啟發或者幫助。業務流程圖業務流程圖顧名思義就是用來梳理業務流程的圖，多為泳道圖的形式，相當於一個整體的架構。可以利用橫向和縱向兩個維度來繪製，有的時候也可以利用顏色來表明第三個維度，下圖為我之前繪製的現金貸的整體業務流程圖。個人覺得業務流程圖的繪製還是很有必要的，因為通過繪製業務流程圖既能夠加深自己對整個項目的理解，又方便梳理後續的其他流程，而且在向團隊成員講解項目的時候也能夠有的放矢，便於團隊成員快速了解項目。任務流程圖業務流程圖和任務流程圖有點類似總分的關係，業務流程圖主要用來梳理整體的流程，任務流程用來梳理單獨的子流程。任務流程圖一方面是基於用戶的操作，另一方面是基於系統的操作或者判斷，會比業務流程圖更細緻一些，下圖為我之前繪製的一個任務流程圖(未考慮分支流程和異常流程)。大多數情況下，任務流程圖的主要受眾群體是開發人員，所以對異常流程和分支流程的考慮和處理應該要更全面一些，不然在和開發過需求的時候發現邏輯上的漏洞，就會比較尷尬了。那種比較複雜的流程圖開發人員看起來也會很頭大的，所以我一般都會儘可能的將流程圖拆解成一個個獨立的子流程，這樣對方看起來會比較容易理解，自己在講解或者調整的時候也會相對容易一些。繪製流程圖的時候，我一般會先將整體的業務流程和比較核心的主線流程繪製出來，最後才會將一些分支流程和異常流程細化出來。之前寫過一篇關於流程圖的文章，感興趣的可以去看下…產品設計之流程圖功能結構圖功能結構比較接近於我們平時看到的產品結構了，我一般是通過腦圖的形式先對功能做加法，最後再基於需求本身和項目的目標來做一些減法。下圖為之前文章中寫過的一個案例，這是通過產品表現層梳理出來的功能結構圖，注意這個僅僅是結果，是產品經過多次迭代后最終呈現出來的形態，不是在產品設計過程中的過渡產物。在我們自己進行產品設計的時候就相當於是一個逆向操作了，需要在用戶的目標與產品的目標之間找到一個平衡點，然後基於這兩者來合理的組織產品的功能結構，最終再將產品的功能結構轉化到產品的原型上。信息架構圖對於功能結構圖和信息架構圖，我之前一直有點傻傻分不清，後來在網上看過一篇文章說信息架構主要是用來梳理數據欄位的，是開發人員用來參考著建資料庫表結構的，當時覺得說的好像有點道理，就一直這麼相信了…後來看完《信息架構 超越Web設計》這本書之後，就再也不敢有事沒事隨便提信息架構這幾個字了，因為我發現信息架構本身是一門學科，根本不是一本書能夠說清楚的，更不要說一篇文章了…根據《信息架構 超越Web設計》這本書裡面的定義來看，信息架構包括組織系統、標籤系統、導航系統、搜索系統以及敘詞表、受控詞表和元數據等…而以前提到的部分只是信息架構裡面的九牛一毛，僅僅只是元數據裡面的一部分，下圖為一個所謂的「信息架構圖」的樣例，可以看到所有的內容都是以名詞的形式出現的。我在實際工作中用到這個「信息架構圖」的次數很少，而且也確實是在和開發人員確定具體欄位的時候用到的…頁面流程圖頁面流程圖的核心是表現出來不同頁面之間的流轉關係，即用戶從哪裡來，能夠去到哪裡，通過什麼樣的操作能夠實現怎樣的頁面跳轉，通常情況下也可以通過在原型上加跳轉鏈接來說明頁面之間的關係。下圖為整理的摩拜腳踏車的核心頁面流程圖，但是實際工作中這兩個流程的順序應該是相反的，即應該先有頁面流程圖，然後才是原型中的頁面跳轉關係。原型圖這個應該就是我們比較熟悉的東西了，至於是用什麼工具去展現，其實並不是那麼重要，我個人的習慣是先構思一下整體的頁面布局，確定了大致的區域和內容，把草圖先畫出來，最後才是使用工具來繪製原型圖。素材來源於互聯網最後要說的這兩個東西在平時工作中遇到的可能會比較少，但是也是比較重要的東西。在產品形態比較複雜或者角色較多時，可以使用用例圖來幫助梳理產品的主要功能，下圖為在之前案例中繪製的用例圖。用例圖和產品的功能結構圖有些類似，它們兩個應該是同一個環節中的產物，用例圖的核心在於說明用戶能夠通過這個系統做什麼事情。明確這些之後，就可以直接將用例圖轉化為產品功能結構圖，然後指導後續的畫原型工作了。順序圖順序圖在工作中用到的次數最少，我只在產品和另外一個系統進行對接的時候畫過一次。下圖為之前案例中出現過的順序圖，和業務流程圖中的泳道圖有些類似。在一些公司開放出來的API的文檔裡面通常也會有一個時序圖，用來說明系統間是如何進行交互的。之前我寫過一篇文章，是關於UML中常用的一些圖的，感興趣的可以去看下。案例分析 || UML大戰需求分析最後平常工作中可能會遇到的圖差不多就這些，其中流程圖、功能結構圖、原型圖是肯定會遇到的，至於其他的幾個圖需不需要繪製，則需要具體問題具體分析。一方面是基於遇到的問題，看用哪種方式能夠更清楚的表述出來，另一方面則需要結合團隊習慣和個人習慣。個人覺得文檔管理還是比較重要的，一方面是能夠為團隊成員之間的交流提供便利，降低協作成本，提升整體的協作效率，另一方面是能夠將產品本身的迭代歷程記錄下來，在之後查找相關東西的時候能夠有文檔可尋。以上就是本文的主要內容，主要梳理了在整個工作流程中產品需要關注的一些圖，希望能夠對大家有點啟發或者幫助。歡迎斧正、指點、拍磚….產品學習｜交流分享公眾號ID：產品經理從0到1即可關注