如何從0到1打造一個完美的業務系統？

文章以一個web新聞站點為例，演示如何打造完美的業務邏輯。

小夥伴們有沒有這樣的經歷？領導讓你負責從0開始做一個業務系統，你木有相關項目經驗、也沒有競品可以借鑒，不知道從何下手？抑或是自己寫的PRD，在評審階段總是暴漏出各種問題，這裡沒考慮清楚，那裡也沒考慮清楚？項目歷經千辛萬苦上線了，業務方/需求方各種吐槽，不滿足需求？恭喜你，你將在本文找到上述問題的解決之道。本文以一個web新聞站點為例，演示如何打造完美的業務邏輯。本文重在方法論的演示，請勿在意案例細節。

1.分析用戶角色：業務系統的用戶有幾種角色？各自的需求是什麼？

角色分析

角色分析比較容易做，但每個角色的需求很難一次梳理到位、沒有遺漏。怎麼辦？

角色需求分析

例如你花了5分鐘的時間整理出了上圖中的需求點，有很多遺漏的需求點，例如作者提交后的二次編輯、編輯查詢站點的PV/UV/閱讀量等。山人以為，從0開始做一個業務系統並一次滿足所有角色的全部需求是不現實的、不現實的、不經濟的。需要進行取捨，建議採用MVP原則，把有限的精力和資源投入到關鍵功能、關鍵業務流程上，次要的功能後續逐步迭代實現。

但是，如何避免遺漏關鍵需求那？以下方法可供借鑒：

• 內部需求收集： 向編輯、審核人員、管理層等內部用戶收集需求；
• 同類/類似產品分析： 雖然可能沒有完全一樣的業務系統競品可以借鑒，但單個功能模塊還是應該能找到類似的產品的。例如：作者在線寫文章模塊可以參考下QQ空間的寫日誌；審核可以參考今日頭條的審核，自己提交提交一個文章走一遍審核通過、審核不通過的流程，然後推測出業務流程。

2.解構功能模塊：理清每個功能的前置條件、輸入、處理、輸出、異常。

根據第一步角色需求分析的結果，梳理每個功能的前置條件、輸入、輸出、異常。以作者提交文章為例：前置條件是登錄；輸入是已填寫標題、正文；處理的動作是點擊提交、後台往表中插入數據；輸出是文章存儲成功並且狀態變成待審核；異常包括：網路異常、包含非法字元等。作為老司機，需要提醒下小夥伴們，有時候需要非常大膽地逆向思維才能發現一些關鍵的異常，比如這裡的前置條件登錄就存在異常–未登錄。未登錄時不顯示寫文章等模塊的入口？還是顯示入口並引導登錄？

3.設計業務流程：先確定主角色和主流程，理清楚其它角色、其它流程與主流程的關係。

基於功能模塊解構分析的結果，識別出關鍵角色、關鍵業務流程，並投入的較多的精力進行產品設計和review。對這個案例而言，作者提交文章；審核人員的審核；以及編輯發布是最重要的功能和業務流程，需要重點關照。針對這一關鍵業務流程，可通過繪製流程圖的方式理清業務流程及異常處理流程並形成閉環。

關鍵業務流程：提交–審核–發布

主流程確定了，其它的業務流程一般很容易搞定。有時候在梳理一般業務流程的時候也會發現主流程有遺漏分支流程或者異常狀態的情況。

如果關鍵業務流程涉及多個部門的協同及分工，建議在流程確定后及時與相關部門的干係人（leader、執行崗）溝通確認，避免在開發階段或者上線后出現相關部門挑戰流程、質疑分工的問題。古語說的好——小心使得萬年船~~~

作為老司機還有提醒下小夥伴們，涉及業務支撐響應周期的問題，例如本案例中的審核周期，一定一定一定要讓業務部門書面確認，然後PM們才能把相關信息在前端頁面展示出來。

4.設計系統架構：系統架構要充分考慮功能的相關性及許可權管理的便利性。

設計系統架構時需要充分考慮功能的相關性及許可權管理的便利性，建議把同一角色需要使用到的功能放到一個一級菜單下，把操作對象相同的功能放在一個頁面。比如：用戶名、密碼都是與用戶ID關聯的，這兩個功能可以放在一個頁面。審核和刪除的操作對象是文章，有相關性，需要放在同一個一級菜單下。

5.儘早驗證並完善：

上述4步完成後，就到了小夥伴們最喜歡也很擅長的環節了–畫原型、寫PRD。有了第2步的基礎，寫PRD時基本上就是碼字。有了第4步的基礎，畫原型就是擺控制項、調對齊，基本不用動腦了。只強調一點，原型完成後可以小範圍與關鍵執行崗位進行溝通。

這步完成後接下來才是需求評審。相信經過了前面2輪的溝通和確認，需要評審環節一定會很順利，大家問的問題你都胸有成竹、對答如流。這樣完美的需求評審，有利於提升PM在團隊中的威信、樹立專業的形象、增強PM自信。

上述方法論適用於從0到1的打造業務系統，也適用於分析一個業務系統。

最後，安利一句話，與小夥伴們共勉：你必須非常努力，才能看起來毫不費力。