編輯導讀：對業務進行拆解能幫助產品經理更好地釐清各個模塊之間的關係，分清主次需求。當一個產品經理接到一個複雜且陌生的業務時，要怎麼將它從頭拆解轉化成產品需求？本文主要講解該如何拆解，一起來看看~
產品的價值取決於用户需求。需求是用户當下遇到的問題，用户為了解決問題會尋求解決方案。
企業與用户的連接點就在於此。企業為用户提供解決方案，而產品則是解決方案的載體。
無論C端還是B端產品，都是為了解決問題而存在。
產品經理的工作其實是給出一個符合當下最優的解決方案，解決方案的載體就是產品。
解決方案制定的過程中會不斷重複這三個步驟：發現問題，解決問題，驗證問題。
梳理解決方案就是弄清楚需要哪些人做哪些事，以及人和事、人和人、事和事之間的聯繫。
這對應着系統的三個組成元素：角色、任務、規則。
角色對應需要哪些人，任務對應需要做哪些事，規則對應人和事、人和人、事和事之間的聯繫。
有了以上的認知，就可以開始拆解業務。
01 定義關鍵角色拆解業務首先要弄清楚哪些人會參與解決問題。
解決一個問題往往需要完成多個任務，每一個任務都會由一個或多個人參與。
找到那些執行相同任務的人，把他們定義為一個角色。
比如餐廳點餐，顧客負責點餐，服務員負責確認菜單，勤雜工負責準備食材，廚師負責做菜。這些角色各自的任務都不相同。
有一點需要特別説明，一個任務的參與人也可能是“系統”。比如服務員確認菜單後，通知廚師和勤雜工可以由系統替代。
02 識別關鍵業務節點解決一個問題需要執行很多任務，但並非所有的任務都是關鍵業務節點。
關鍵任務節點有兩個特徵：一是能夠推進業務往下進行，二是推動業務在不同角色間流轉。
比如廚師在做菜時會執行很多個操作。配菜、炒菜、調味、擺盤……但這些步驟都是“做菜”。雖然廚師做了很多事情，但在餐廳的業務流程裏只有“做菜”是關鍵業務節點。
再比如後台系統常見的錄入用户信息。暱稱、性別、城市的填寫都是需要執行的任務，但完成其中單個信息的填寫並不能推動業務往下進行。在系統層面可以把這些任務抽象為一個關鍵業務節點——填寫用户信息。
不同角色間的流轉，審批流程是很好的例子。比如在釘釘上提交一個採購工單，審批者需要對提交的金額和採購的物品進行核對，但這些不會在系統層面體現，只有“通過”或“拒絕”這類推動業務在不同角色間流轉的任務才會被定義為關鍵業務節點。
03 定義業務規則與業務流程前面我們已經將業務的關鍵角色和關鍵業務節點梳理清楚，但這只是業務梳理的熱身運動。
接着還需要弄清楚人和人、事和事、人和事的聯繫。
“聯繫”體現在兩個方面：一是不同角色執行任務的順序，二是任務執行時需要遵循的規則。
業務梳理的最終產出物就是業務規則與業務流程。
依舊以餐廳點餐為例，做菜時鹽不能放太多、火候不能太過、分量不能太少，這些都是廚師在執行任務時需要遵循的規則。如果不遵循規則，最終的結果是業務停在做菜這個環節無法繼續往下推進。
同時做菜一定是在服務員確認好菜單後才會進行，這是任務執行的順序。假設先做菜後確認菜單，就會導致之前進行的任務變得無效以及任務的重複。
以上兩個例子説明了梳理清楚人與事的重要性，梳理有誤最終導致的結果就是業務的停滯與業務的週期變長。
04 如何拆解複雜業務流程？現實世界的業務往往是極其複雜的。
業務的複雜度往往體現在以下幾個維度：
- 多關鍵角色、多關鍵任務節點
- 多業務分支流程
- 業務流程長
- 業務週期長
- 業務規則複雜
並不是同時具備以上特徵才能算作複雜業務。有時只要具備一個或其中幾個就足以讓業務變得複雜。
拿我正在負責的業務系統為例，系統的角色並不複雜，參與核心業務流程的角色不超過10個。但因為行業的特殊性，用户的成單週期在2~4周，服務用户的週期在2年左右。同時，雖然角色不多，但用户的分支業務流程很多。
因為過長的成單週期和服務週期，讓整個業務週期被拉長，從而讓業務變得複雜。同時每個角色的分支業務流程很多，進一步提升了業務的複雜度。
最後的結果是，我繪製的流程圖裏的節點可以造一艘航空母艦。
那麼面對如此複雜的業務，我們該從何下手呢？
1. 梳理單角色業務流程業務複雜時，我們可以先梳理清楚單角色的業務流程。
比如梳理餐廳出餐業務，我們可以先梳理清楚服務員的業務流程，暫時擱置其它角色的業務流程。
如上圖所示，服務員在通知廚房做菜後，不用關心廚師是如何製作菜品的，只需要弄清楚服務員後面會在哪一個節點再次介入業務。
對於服務員而言，廚師做菜是一個“黑盒”，他只關心菜品什麼時候製作完成，收到菜品製作完成後他就可以進行後續的任務。
同理，其它角色也可以按照這個邏輯進行梳理。當每個角色獨立的業務流程梳理完成後，再將它們串聯起來就組成了完整的業務流程。
2. 梳理單向業務流程一個角色可能會進行多個分支業務流。
這個時候，我們可以先梳理清楚可能存在的業務線，然後對每一條業務線進行單獨的梳理。
比如審批流裏，審批的結果通常有通過和不通過。這時可以先梳理清楚通過後的業務流程，再回過頭去梳理不通過的業務流程。
當兩條業務線梳理清楚後再合併在一起就構成了完整的業務流程。
其背後的思維方式其實和梳理單角色業務流程一致——化繁為簡。
把複雜的業務拆解為單角色、單流程的業務進行梳理，這樣能夠更清晰地把握業務脈絡。
3. 梳理異常業務流程除了主線的業務流程外，還有很多異常的業務流程。
比如餐廳就餐的主線業務流程是用户點餐到用户買單。但不可避免的情況是——退款。
這種獨立於主線業務流程外的業務稱之為異常業務。
針對異常業務，我們可以單獨拎出來進行梳理而不和主線業務流程產生交織。在設計業務時，要儘可能避免降低對主流程的影響。
05 那些需要留意的坑1. 線上業務流程抽離完整線下業務流程梳理後，在進行產品設計時，要從線下業務流程中抽離出完整的線上業務流程。
比如點餐系統。在系統層面，會刪除掉很多線下的環節。廚師做菜是線下的任務，執行時可以不必與系統進行交互，只需要完成做菜後在系統執行操作，通知到服務員取餐即可。
其次是線上業務流程會引入“系統”這一角色，很多原本在線下執行的任務都會有系統的參與。我們需要明確系統在整個業務流程中替代了哪些之前由線下角色執行的任務。
2. 瞭解真實的業務現狀很多公司裏面系統的需求方是業務負責人，而不是一線的業務人員，所以系統的設計是從管理者視角出發的。
這種情況很可能導致系統的設計並不符合真實使用者的需求。為了避免這種情況發生，產品經理在設計系統時一定要找一線業務人員進行調研。
另外一種情況是，系統上線後系統使用者可能並沒有按照設計者的預期使用系統，而是按照自己的理解來使用系統。所以在系統上線後產品經理一定要去看看系統真實的使用情況。
3. 系統的效率並不一定高於線下系統的核心價值在於提升效率。如果引入系統後效率並沒有提升，甚至效率降低，這個時候就值得我們深思了。
比如服務行業裏往往存在總部和線下門店兩個獨立的業務部門。線下門店有時會遇到極其特殊的情況，而這種情況通常需要即時處理，但又無法自己做決策。
如果走系統可能會因為業務流程的停滯導致線下的問題無法即時解決。
最快的方式就是一個電話打到總部，讓總部做出決策後即時處理。
系統只是一種解決方案，但不是唯一的解決方案。
4. 業務問題、系統問題傻傻分不清楚- “你們系統設計的太爛了，根本滿足不了現在的業務需求！”
- “其它競品都有XXX功能，為什麼我們不能加上去？”
- “這個地方經常會誤操作，能不能XXX這樣改進一下啊？”
諸如此類的話語，我相信大部分產品從業者都不陌生。業務方總是能從你不曾想到的角度提出問題。
不知道大家有沒有去探尋過背後深層次的原因？
我思考的結論是，業務人員會對系統形成依賴性。
有的業務人員認為什麼問題都可以靠系統解決，更為誇張地是覺得任何問題都是因為系統不完善導致的。
產品經理的腦子一定要清醒，不要因為業務方的強勢而妥協。
比如運營部常常會説我需要一個XXX營銷功能，如果沒有這個功能，我們這個階段的指標就無法完成。
這樣的需求我聽到過N次，但當問到他們具體的運營目標、預期的ROI是多少時？絕大多數時候運營方都無法回答出來。
這就屬於典型的把業務問題甩給產品來解決。即便產品做了，後續依然會甩鍋到功能做得不夠好。
所以業務方提需求時，一定要先讓他們意識真正的問題是什麼。
寫在最後很多人問過我比較擅長什麼類型的產品，其實我並不覺得一定要侷限在某一類產品。
兩年前我會想在某一個領域深挖，但現在思考更多的是產品背後的方法論。
產品的道是思維，產品的術是方法。不管什麼類型的產品，只要掌握了道與術都應該能夠做好。
那些優秀的人一直在不斷突破自我的邊界並實現自我的價值。
#專欄作家#東東方，微信公眾號：UnknownPM，人人都是產品經理專欄作家。關注互聯網新動態，致力於產品知識體系的構建，不定期分享產品心得。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議