<p><strong>前言</strong>：作為后端產品經理，刻意練習系統架構設計的能力和對業務充分了解的能力，個人覺得，顯得尤為重要。此文我只關注這兩點，至于原型那些表現層的內容，不在此文范圍。</p><p><br /></p><p><span >PS：考慮到文中涉及到很多公司內部數據。打上馬賽克重新編輯后，卻依然阻止不了此文的傳播力量，但是在我自己公眾號里原文已全部刪除，連個原創聲明都沒，故而重發。原創不易，喜歡請轉發，謝謝。</span></p><p><span ><br /></span></p><p><strong><span >再說我泄密，麻煩拿著此文直接舉報我，我不care~</span></strong></p><p><strong><span >我本善良，做事坦蕩，問心無愧~</span></strong></p><p><strong><span >不過，謝謝提醒我的技術同事，愛你喲~</span></strong></p><p><br /></p><p><span ><strong>歷史已有成就：</strong></span></p><p ><img class="rich_pages" data-ratio="0.35157894736842105" data-s="300,640" src="https://upload-images.jianshu.io/upload_images/6034320-b6b136e30be3d6e2" data-type="png" data-w="475" /></p><p ><br /></p><p>?</p><p>文中我將通過<p><strong>M V C技術架構（我的思維模型）</strong></p>去思考如何打造一款從0到1的后臺系統。商務咨詢系統，是我負責的一個業務不算特別復雜的系統，以此為例，咱們層層剝離，探尋萬事萬物的本質。</p><p>?</p><p><img class="aligncenter" data-ratio="0.7170236753100339" src="https://upload-images.jianshu.io/upload_images/6034320-939eadb06f568d42" data-type="png" data-w="887" height="636" width="887" /></p><h2><strong>目錄：</strong></h2><p><strong>（1）需求背景</strong></p><p><strong>（2）系統價值</strong></p><p><strong>（3）系統設計</strong></p><p><strong>第一步：用例圖</strong></p><p><strong>第二步：系統流程圖</strong></p><p><strong>第三步：系統功能清單</strong></p><p><strong>第四步：系統架構設計</strong></p><p><strong>第五步：數據庫表結構（對象）</strong></p><p><strong>第六步：表之間的關聯關系（ER圖）</strong></p><p><strong><br /></strong></p><p><strong><br /></strong></p><p><br /></p><h2 ><strong>C：業務邏輯層</strong></h2><p>?</p><p><strong>（1）需求背景</strong></p><p>某公司全國各分公司的商務同事剛來公司沒多久，對很多業務以及同事都不是很熟悉，出去談業務的時候，經常會遇到很多比較棘手的問題，也會提出很多無規則你根本想不到的問題。打開釘釘，龐大的組織架構，一堆又一堆的釘釘群，根本不知道找哪些專業人士解答疑惑。將自己的問題，丟到幾百人的后臺服務支持群，結果很快被其他人的問題給淹沒，不知道找誰提問，不知道在哪里提問，好不容易找到個熱心的同事，結果答非所問，浪費時間。不知道該在哪里提問？不知道找誰問？沒有人回復？找不到之前的問題解答記錄？公司系統的各種問題，沒地方提出改進建議？</p><p>?</p><p><strong>（2）系統價值</strong></p><p><strong><br /></strong></p><ul class=" list-paddingleft-2" ><li><p><strong>快速解決商務同事日常業務問題</strong></p></li><li><p><strong>提升后臺支持人員處理問題效率</strong></p></li><li><p><strong>統一提問入口</strong></p></li><li><p><strong>隨時查看問題進度</strong></p></li></ul><p><br /></p><p><strong><br /></strong></p><p><strong>（3）系統設計</strong></p><p><strong>第一步：用例圖</strong><br /></p><p>說明：設計任何一個系統，首先必須搞清楚有哪些參與者，這些參與者都能在系統里做什么，都有什么功能。</p><p><img class="aligncenter" data-ratio="1.0911300121506682" src="https://upload-images.jianshu.io/upload_images/6034320-857bf61582507031" data-type="jpeg" data-w="823" height="898" width="823" /></p><p><br /></p><p><br /></p><p><br /></p><p><strong>第二步：系統流程圖</strong></p><p>說明：其次，必須搞清楚這些參與者在系統中是如何操作的，先后順序是怎樣的，有什么判斷情況，有哪些逆向流程等等。而且，畫流程圖，建議千萬別一口吃成一個胖子，要循序漸進。</p><p><br /></p><p>建議按照：</p><p><span ><strong>業務流程圖- -頁面流程圖- -功能流程圖 - -數據流程圖</strong><strong>等步驟，一點一點從簡入手。</strong></span></p><p>?</p><p><strong>2.1、業務流程圖</strong></p><p>說明：凡事，先從簡入手，先把當前系統的流程枝干搭建起來，主要流程確定下來，清晰明了的告知所有人，你這個系統在干嘛，要干嘛。其他的枝枝葉葉，先全部去掉，不要影響你的思維，不要打擾你的思路。</p><p><img class="aligncenter" data-ratio="2.893081761006289" src="https://upload-images.jianshu.io/upload_images/6034320-2d348dbda1d65fc9" data-type="png" data-w="159" height="460" width="159" /></p><p><br /></p><p><strong>2.2、頁面流程圖</strong></p><p>說明：主干就像房子的地基，搭好地基之后，就要開始建房子了。具體有哪些頁面，頁面之間如何調整，就要開始想清楚啦。此時，先過濾掉所有判斷條件，所有逆向流程，先跑通所有頁面，先跑通正向流程。</p><p>?</p><p><img class="aligncenter" data-ratio="3.227979274611399" src="https://upload-images.jianshu.io/upload_images/6034320-56fc784239d2f0c0" data-type="png" data-w="193" height="623" width="193" /></p><p>?</p><p><strong>2.3、功能流程圖：</strong></p><p>說明：地基建好了，毛坯房也建好了，具體房子怎么設計，得開始啦。此時，每往下走一步，盡量多問自己幾個為什么。為什么要這樣做？不這樣做可不可以？</p><p>?</p><p><img class="aligncenter" data-ratio="2.7184" src="https://upload-images.jianshu.io/upload_images/6034320-7c11e1f5c35caa8a" data-type="png" data-w="625" height="1699" width="625" /></p><p><br /></p><p><br /></p><p><strong>附件1：問題狀態流轉圖</strong></p><p>說明：此系統，問題的狀態流轉，比較關鍵，所以用流程圖清晰的表明出來是很有必要的，當前最小MVP做的好不好，關鍵在于問題狀態的流轉，以及問題狀態改變后所有影響情況的考慮。</p><p>?</p><p><img class="aligncenter" data-ratio="0.5909090909090909" src="https://upload-images.jianshu.io/upload_images/6034320-b0aa464aa8e548fc" data-type="png" data-w="1188" height="702" width="1188" /></p><p>?</p><p><strong>附件2：問題時效規則設置</strong></p><p>說明：問題被人提出來了，什么時候通知給處理人，處理人多久沒處理問題會超時再次提醒，處理人回答完問題，發問人多久不給出評價后，問題自動結束狀態改為已處理等等。問題的時效控制，也是增強系統體驗的一個重要信息，主要用于消息提醒的觸發和問題狀態的改變。</p><p><img class="aligncenter" data-ratio="0.5224719101123596" src="https://upload-images.jianshu.io/upload_images/6034320-6bc340f43f7c9804" data-type="png" data-w="1068" height="558" width="1068" /></p><p><br /></p><p>?</p><p><strong>第三步：系統功能清單</strong></p><p>說明：當前系統當前版本，總共要做哪些功能，要列出來，告知項目組所有成員，并排好優先級。</p><p><img class="aligncenter" data-ratio="0.8972243060765192" src="https://upload-images.jianshu.io/upload_images/6034320-9b9396126a6e2c17" data-type="png" data-w="1333" height="1196" width="1333" /></p><p>?</p><p><strong>第四步：系統架構設計</strong></p><p>說明：首先，要想清楚，系統是否要劃分前后臺。一般后臺系統是不需要前臺頁面，直接PC端訪問即可。但是，此系統是針對商務設計的，那么必須考慮其在外辦公的便利性，部分重要解決其問題的功能，做成wap網頁嵌套在釘釘中或者單獨開發小程序、APP原生頁面就很有必要。載體不重要，重要的是商務使用順暢，簡單方便易操作。</p><p>?</p><p><strong>4.1、前臺架構</strong></p><p>說明：當前系統，牽涉的外部系統不多，所以架構不復雜</p><p><img class="aligncenter" data-ratio="0.4354561101549053" src="https://upload-images.jianshu.io/upload_images/6034320-d94a20beb67bc66d" data-type="png" data-w="581" height="253" width="581" /></p><p><strong>4.2、后臺架構</strong></p><p>說明：從角色權限分配可以看出，當前系統會調用人員組織系統的外部接口，來獲取公司的所有人員以及所屬部門。</p><p><img class="aligncenter" data-ratio="1.5937984496124031" src="https://upload-images.jianshu.io/upload_images/6034320-20ca98ae6d503c5f" data-type="png" data-w="645" height="1028" width="645" /></p><p><br /></p><h2 ><strong>M：數據結構層</strong></h2><p>?</p><p><strong>第五步：數據庫表結構概念設計</strong></p><p>說明：依稀記得《java編程思想》中有段話，<strong>萬物皆對象</strong>。世間萬事萬物，皆為對象，很強大，也很有道理。數據庫表結構，就是對象在程序語言的體現。咱們做系統設計，追蹤到數據底層，就是一個又一個對象，以及對象之間的關系（ER圖）。</p><p><br /></p><p>其實，將功能拆解為對象并將之表象為數據庫，并不復雜，沒那么玄乎，是有根可循的。舉個例子，咱們通篇都在講發起問題，處理問題。那問題，很明顯就是一個對象啊，發起和處理，只是他的動作（技術語言叫方法，這里我說的大白話一點），并不能稱之為一個對象。以此類推，數據表結構也就揭開迷霧啦。</p><p><br /></p><p><strong>PS：數據庫表，對于產品經理，不是必備技能，個人認為會畫的產品，并且時間充裕那就畫一下（畫出來，可以讓你思路更加清晰明了，OMG，原來我的系統就是這幾張表在發揮作用，太牛逼了，技術大哥們），不會并不影響你系統架構的設計。這些是編程小哥哥小姐姐們的看家本領，咱們做產品的了解就好，不強求。我畫出來，是因為，突然心血來潮，就隨便畫了一下。</strong></p><p><strong><br /></strong></p><p><img class="aligncenter" data-ratio="1.6408839779005524" src="https://upload-images.jianshu.io/upload_images/6034320-c607b5396bcde222" data-type="png" data-w="543" height="891" width="543" /></p><p>?</p><p><strong>第六步：表之間的關聯關系（ER圖）</strong></p><p>說明：表之間的關聯關系有什么用？可以有一個連帶關系，舉個例子，一個用戶表，一個信息表，一個用戶對應多條信息，當你刪除用戶的時候是不是這個用戶的信息也要被刪除，如果沒有關聯關系的話，你就要在刪除用戶前手工寫條sql語句去刪除信息表里的對應信息，如果有關聯的話，就不用了，級聯刪除就可以了，只要刪除用戶，這個用戶下面的信息也就沒了。</p><p><br /></p><p>表之間的關系有四種【一對一、一對多、多對一、多對多】，那么是如何判斷的呢？這里，我只講方法，不講細節。6張表，兩兩相關聯作比較。比如：一個問題對應一個問題分類，一個問題分類對應多個問題，表明問題表與問題分類表是1對多的關聯關系；一個問題對應多個問題狀態，一個問題狀態對應多個問題，表明問題表與問題狀態表是多對多的關聯關系。</p><p><br /></p><p>再復雜再龐大的業務系統，只要功夫深，經過咱們層層剝離，無非就是一個又一個光禿禿的數據表結構，是不是很好玩，是不是很有趣，不妨使用我本文提到的方法順序，去剝離一個系統試試，你會有驚喜的喲！</p><p>?</p><h2 ><strong>V：表現層</strong></h2><p>表現層，也就是咱們做產品的基本功，將構思好的系統用圖形化的界面表象出來，給項目組所有成員評審，這點不是此文的重點，我不過多闡述。</p><p>總結：當前系統，只實現了最小可行性MVP，解決當下核心問題。未來的規劃，是想將本系統打造成商務智能咨詢系統。<strong>實現系統能通過問題庫，自動解決80%商務日常提出的問題，20%人工介入。各位看官，對系統規劃，有更好的見解，歡迎留言交流，謝謝！</strong></p><p>?</p><p>?</p><p>作者：會飛的豬能上樹</p><p>個人公眾號：kylxpm520 刻意練習產品經理</p><p><br /></p>