編輯導語：很多產品經理都參與過后臺系統的搭建過程，搭建系統是一個很復雜的任務，系統搭建的好壞與產品經理的整體架構和產品思維分不開。作為產品經理，應該不斷的去探索如何搭建一個合理的系統。接下來，本文作者結合自己的實際經驗，為我們總結了后臺產品經理應該如何設計系統。

筆者作為B端產品經理，在工作中，接觸和搭建過不少后臺系統。

也因此越來越感受到，系統的設計結構很能體現出一個產品經理的設計思路及產品思維為了不斷探索如何設計出一個合理的、可持續的、優雅的系統，筆者將個人的系統認知經驗整理成文字，愿與大家分享，希望帶給大家啟發。

首先，筆者自己寫了一個系統公式：

系統 ≠ 功能點的簡單相加

此解釋為：

1. 系統的存在應是整體的，且整體大于局部之和，超出的那部分體現在系統的可持續性和可擴展性；
2. 系統中各項功能的存在不應當毫無關聯，只有邏輯性的流程、結構化的模塊、關聯性的功能之間，產生有效銜接才能稱之為系統，否則充其量只是一堆功能點的堆砌。

我們應該有過這樣的體驗：有的系統模塊布局及功能結構一目了然，即使使用者沒有受過專門培訓，也能摸索出使用方式。

但有些系統結構混亂，看起來功能好像很多很全，卻無法分清主次，無法串起一條邏輯主線，令后續的維護成本越來越大，接手者越來越難以下手。

為什么會有這樣的差異呢？就我目前的總結分析后，它們都有一項共性問題——就是整體性的缺失,讓我們來看看這些缺乏整體性的系統都有哪些共性特征：

一、系統整體性缺失的體現

1. 瘋狂堆功能，卻無關聯

僅就我個人體會而言，產品新手在沒有人帶的情況下，如果交由其進行系統設計，很難一開始就能站在整體系統層面上進行思考和設計，因此容易做成一項項功能點的堆。

這種堆砌不是這樣的↓

而是這樣的↓↓

這一個個（功能）點，看似很多很有聯系，實則缺乏整體的結構性、流程的邏輯性以及面向過去和未來的關聯性這樣設計出的系統雖然短期內或許也能支持業務現階段運行，但是長期這般下去，整個系統就像是一盤散沙。

做后臺系統的同學應該知道，功能設計的表象是一個個交互頁面，但體現在開發代碼邏輯里實際上是一張張數據關系表。

正是這些數據關系表，維護著系統的正常運行。

如果在設計之初不考慮功能之間的關聯性以及整體結構是否合理，那么在后期就會演變成：產品瘋狂堆功能，開發瘋狂建表，關聯關系越發不明確，各模塊和功能之間就像一個邏輯黑洞，越往后越令接手者苦不堪言。

2. 僅面向當下設計

我把這種只考慮解決眼前問題、不考慮未來擴展性的功能設計稱為“僅面向當下設計”它的特征體現在：一次性、應付性、偷懶性。

• 一次性：因為這種設計仿佛就是為了解決一次需求而存在的，于是來一個需求加一個功能，功能菜單越積越多，看起來功能很豐富很全，實則使用率讓加班寫代碼的開發哥哥當場流淚；
• 應付性：只為應付完成當前的需求任務，至于未來會怎么樣那就到時候再說吧。反正只要能完成當前的需求任務，難題都是留給未來產品的；
• 偷懶性：思考功能與過去歷史邏輯、未來發展空間的關系是需要費腦力的，如果偷懶只考慮當前怎么做能解決問題就怎么做，自然簡單多啦。

由于這種“僅面向當下”設計的存在，系統的冗余模塊和重復功能越積越多，運營維護成本日趨上升，這對維持系統的可持續性和傳承性（由于人員變動產生的系統交接）簡直就是一場災難。

3. 系統缺失整體框架和規劃

這一點體現在：產品經理在搭建產品之初，在未做產品架構如何設計、功能模塊如何分類、產品路徑如何演進情況下，上來就開始寫細化到功能實現的需求。

由于缺失足夠的框架思考和適用于未來場景的擴展性，做的都是臨時想到的或者業務基于當時場景提出的；功能模塊也未區分出優先級，不考慮完成順序的合理性。開發在進行數據結構表設計時，也只能憑著個人的（踩坑）經驗……于是乎就很容易出現下面的場景：

系統上線前夕，產品同學悄悄出現在開發身后，這時，開發同學的靈異第六感告訴他來者不善——果然回頭發現是產品經理—— 一時間連表情管理干脆都放棄了，尚未來得及做最后的掙扎，就看到產品同學（佯裝）可藹可親地說：

“小X啊，咱們這個球員管理系統，不是規定一個球員只能歸到一個球隊里么，現在我發現除了國家隊，他還能有自己的俱樂部隊，所以還是把他改成可以歸屬于多個隊伍吧。

這改起來還是很簡單吧，我覺得你在原基礎上多寫兩行代碼就能實現了，就跟著咱們今晚一塊上線，怎么樣？……小X，我跟你說話呢，你哐哐哐地翻抽屜干啥？……小，小X，有話好好說，你先把刀放下！”

這個故事是為了告訴我們：系統的底層結構決定上層建筑大家在一開始設計時就要多想想其合理性和擴展性，否則越到后來改動成本會像滾雪球一樣成倍擴大，還容易有人身安全風險（誤）。

當然，筆者在此也不否認有那種事先不進行規劃，每次僅靠感覺行事還能做對PMF（Product/Market Fit，產品與市場契合）決策的產品經理存在。

但這種選手簡直就是靠上天賞賜的產品天賦吃飯的，咱作為普通人還是老老實實多想前想后吧。

To be honest，前期的我都犯下過這些錯誤，雖然現在還不敢說自己做的完全不再有這些錯誤，但相比曾經的自己，算是有不錯的進步。

接下來，我會用自己身上的真實案例，和大家一起去聊一聊如何盡可能少犯這些問題，或者說如何用實踐方法將系統的整體性落地。

二、如何落地系統的整體性

1. 訓練結構化思維習慣

前文我們已經介紹，如果只是單純的設計功能，而不考慮各功能之間關聯性，那么做的越多，也只是功能的堆砌，即使這些功能組合在一起，也不能稱之為系統但有時候。

并非是產品經理不想把系統做好，而是在當時的情景下缺乏串聯系統結構的主觀或客觀環境?？陀^環境改變不易，這里我們還是聊聊如何改變一些主觀性（即我們自己）。

我們知道，不同的產品經理思維模式不同，設計出的系統也千差萬異。

但是，通過我們自身的努力，是可以不斷鍛煉自己的結構化思維模式的。這里我想引兩個計算機領域里的名詞來描述這個思維模式，分別是自底向上設計和自頂向下設。

• 自底向上設計：是指從系統最基礎的部分著手，逐層向上構造，由簡單到復雜，直到最后得到所要的軟件系統。
• 自頂向下設計：是指按照從整體到局部的順序，將系統分割成各個子系統和子模塊，從上到下逐級進行細化設計。

用一張圖來表示就是：

這兩種設計方式非常有意思，因為它們令我想到這兩種方式是如何可以應用于我們的思考和做事，進而去提高我們設計整體性系統的能力。我將其總結為“自底向上思考”和“自頂向下做事。

• 自底向上思考：從具體到抽象，從具體的事例著手，逐漸抽象出一個概覽全局的整體。這令我們看待問題、思考問題的時候不再片面，而是能夠向上思考、縱觀全局，給出解決方案時不再是解決一個問題，而是能夠順藤摸瓜解決掉一類問題。
• 自頂向下做事：從抽象到具體，講究一個“拆”，將抽象的整體逐漸拆解為一個個清晰可見的模塊，將看似模糊的概念落實為一項項可行的行動。

說白了，就是著大處想，著小處做。我相信通過這樣有意識的鍛煉，加上項目經驗的加成，我們設計的系統一定越來越趨于整體性和合理性。

2. 面對過去溯源，面向未來設計

這句話是說，我們要追尋問題產生的源頭，并給出能夠適用于未來的解決方案，因此在設計時我們要理清功能與歷史邏輯的關聯性、與未來操作的對接關系。

• 面對過去溯源：當我們接到一個需求，要按捺住我們大腦中系統1（概念來源于書籍《思考，快與慢》，指的是我們在遇到問題時，常常下意識動用直覺型的“系統1”迅速做出判斷，而它依賴于我們的情感、記憶和經驗）的直覺沖動。而是要想想這個問題的產生與過去有哪些聯系？是由于過去的哪些缺陷衍生而來？雖然我們無法改變過去，但是通過這種思考，我們積累了經驗，進而減少未來可能犯下的錯誤。
• 面向未來設計：我們要為未來設計留下接口。此處的“接口”并非單指技術名詞API，而是說我們設計的軟件系統要盡可能持久耐用，適應未來可能發生的各種變化，而做到這一點都是一開始就以這種“面向未來”的路線進行設計。

這要求我們在設計解決一個問題的方案時，不要局限于一隅，而是多多思考其他擴展的可能性，多替后來者想想后路（因為系統往往不止歷經一任產品經理）。

3. 培養產品架構與規劃能力

與開發打交道的過程中，經常會聽到他們說起“技術架構”。

我理解技術架構的作用在于通過前期梳理出一系列結構完整、邏輯清晰的技術模型，為系統構建一套適配產品邏輯且數據關系合理的技術體系方案，進而為系統后續的開發及未來的維護奠定底層基礎。

那么作為PM的我們，在正式開始進行系統的細化設計之前，我想，也是應該先構建出產品整體架構的，產品架構設計也能夠體現出一個產品經理思考問題的全面性、邏輯性和結構性。

我在讀馬克思的《資本論》第一卷的時候，有句話令我印象尤為深刻。

原文是：“蜜蜂建筑蜂房的本領使人間許多建筑師感到慚愧，但是，最蹩腳的建筑師從一開始就比最靈巧的蜜蜂高明的地方，是他在用蜂蠟建筑蜂房以前，已經在自己的頭腦中把它建成了。”

這塊的話題比較寬泛，我決定不再用理論文字進行闡述，因為道理大家都懂。下面我將引入自己的真實案例進行說明。

初期的我在做產品設計時，沒有先“架構產品”的習慣，喜歡邊干邊想，總是在梳理之初就直接開始寫具體到實現的功能點和繪制原型。

但往往進行到中間，發現前后關聯點越來越多，不是這里缺了就是那里漏想了，有時候甚至快寫完了才發現方向錯了。于是，我經常性地需要返工重改，那時畫改原型的時間甚至占到了整個方案產出時間的70%、80%。

后來，也是在受到前輩的指導，并在自己的刻意訓練后，現在終于養成了在動手畫原型之前，先把需求的整體框架、數據流結構以及所有的要點邏梳理的習慣，畫原型最終只需占用20%的時間。

效率提升的同時，文檔質量也逐步提高。

那么，現在的我具體是如何做的呢？

首先，在接到需求后，我會在明確業務場景和使用場景后，梳理出一張業務流程圖，這張圖用于表示產品的整體流程，包含涉及本次需求的各部門以及各系統的交互。通常是用Visio（或在線軟件Process On）的跨職能流程圖（管道圖）來做的。需求評審時，在正式講述需求具體如何實現之前，我會先跟全體同學過一遍這張圖，幫助大家建立對需求整體流程如何實現的印象。

隨后，如果是新設計一個系統或一組功能模塊，我會接著進行產品架構圖的設計，這張圖是用于表示系統的模塊結構、功能集成及整體產品布局，同時確定哪些模塊是需要一期實現的，哪些模塊可以放至后期迭代。

接著，我會對需求涉及重要數據流的部分給出一張實體關系圖（E-R圖），這是為幫助開發同學建立數據結構關系，同時通過梳理我也強制自己盡可能想清各實體之間的關聯關系，以達到系統數據結構的合理性。

最后，我會將需求拆分為各組功能，按照大的流程走向，分別進行具體到頁面交互流程的設計，這部分就是頁面流程圖，也是最終的產品原型。但是在上手設計頁面形態之前，我會將頁面的數據來源、列字段與篩選項邏輯、操作功能邏輯等先用文字闡述好，最后再根據所寫的邏輯上手畫圖。

經過這一系列流程，我就完成了一項中型及以上復雜程度需求的產品架構梳理、整體規劃以及具體到功能實現的說明。

跟之前上來就畫圖的操作相比，我發現自己對于需求設計的把控度提高了，也收到了一些來自合作過的開發、測試伙伴們的正向反饋。

當然，即使看到了自身進步的成果，我也不敢在此妄言我現在的方法就是最好的，但是我想通過這一實例來告訴和鼓勵大家：這些能力都是可以通過后期訓練來提高的。

到這里本篇文章差不多就要結束了，這次，我們聊了下系統整體性缺失的體現以及帶來的問題，再結合筆者個人的經驗總結談了下如何讓系統做到不再只是功能堆砌，而是具有整體性。這些實踐點分別就是：

1. 訓練結構化思維習慣；
2. 面對過去溯源，面向未來設計；
3. 培養產品架構與規劃能力。

通過這些實踐，我相信我們設計的系統會越來越趨于整體大于局部之和的效果。目前我也正在朝著這個方向努力，關于系統的思考也還在繼續。

最后，愿天下所有懷著真摯產品之心的同學，做出的系統都合理，設計的功能都有意義。

作者：Han，個人公眾號：涵的數字花園。

本文由 @Han 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。