編輯導語：很多產(chǎn)品經(jīng)理都參與過后臺系統(tǒng)的搭建過程，搭建系統(tǒng)是一個很復雜的任務(wù)，系統(tǒng)搭建的好壞與產(chǎn)品經(jīng)理的整體架構(gòu)和產(chǎn)品思維分不開。作為產(chǎn)品經(jīng)理，應該不斷的去探索如何搭建一個合理的系統(tǒng)。接下來，本文作者結(jié)合自己的實際經(jīng)驗，為我們總結(jié)了后臺產(chǎn)品經(jīng)理應該如何設(shè)計系統(tǒng)。

筆者作為B端產(chǎn)品經(jīng)理，在工作中，接觸和搭建過不少后臺系統(tǒng)。

也因此越來越感受到，系統(tǒng)的設(shè)計結(jié)構(gòu)很能體現(xiàn)出一個產(chǎn)品經(jīng)理的設(shè)計思路及產(chǎn)品思維為了不斷探索如何設(shè)計出一個合理的、可持續(xù)的、優(yōu)雅的系統(tǒng)，筆者將個人的系統(tǒng)認知經(jīng)驗整理成文字，愿與大家分享，希望帶給大家啟發(fā)。

首先，筆者自己寫了一個系統(tǒng)公式：

系統(tǒng) ≠ 功能點的簡單相加

此解釋為：

1. 系統(tǒng)的存在應是整體的，且整體大于局部之和，超出的那部分體現(xiàn)在系統(tǒng)的可持續(xù)性和可擴展性；
2. 系統(tǒng)中各項功能的存在不應當毫無關(guān)聯(lián)，只有邏輯性的流程、結(jié)構(gòu)化的模塊、關(guān)聯(lián)性的功能之間，產(chǎn)生有效銜接才能稱之為系統(tǒng)，否則充其量只是一堆功能點的堆砌。

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

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

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

一、系統(tǒng)整體性缺失的體現(xiàn)

1. 瘋狂堆功能，卻無關(guān)聯(lián)

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

這種堆砌不是這樣的↓

而是這樣的↓↓

這一個個（功能）點，看似很多很有聯(lián)系，實則缺乏整體的結(jié)構(gòu)性、流程的邏輯性以及面向過去和未來的關(guān)聯(lián)性這樣設(shè)計出的系統(tǒng)雖然短期內(nèi)或許也能支持業(yè)務(wù)現(xiàn)階段運行，但是長期這般下去，整個系統(tǒng)就像是一盤散沙。

做后臺系統(tǒng)的同學應該知道，功能設(shè)計的表象是一個個交互頁面，但體現(xiàn)在開發(fā)代碼邏輯里實際上是一張張數(shù)據(jù)關(guān)系表。

正是這些數(shù)據(jù)關(guān)系表，維護著系統(tǒng)的正常運行。

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

2. 僅面向當下設(shè)計

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

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

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

3. 系統(tǒng)缺失整體框架和規(guī)劃

這一點體現(xiàn)在：產(chǎn)品經(jīng)理在搭建產(chǎn)品之初，在未做產(chǎn)品架構(gòu)如何設(shè)計、功能模塊如何分類、產(chǎn)品路徑如何演進情況下，上來就開始寫細化到功能實現(xiàn)的需求。

由于缺失足夠的框架思考和適用于未來場景的擴展性，做的都是臨時想到的或者業(yè)務(wù)基于當時場景提出的；功能模塊也未區(qū)分出優(yōu)先級，不考慮完成順序的合理性。開發(fā)在進行數(shù)據(jù)結(jié)構(gòu)表設(shè)計時，也只能憑著個人的（踩坑）經(jīng)驗……于是乎就很容易出現(xiàn)下面的場景：

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

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

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

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

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

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

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

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

二、如何落地系統(tǒng)的整體性

1. 訓練結(jié)構(gòu)化思維習慣

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

并非是產(chǎn)品經(jīng)理不想把系統(tǒng)做好，而是在當時的情景下缺乏串聯(lián)系統(tǒng)結(jié)構(gòu)的主觀或客觀環(huán)境?？陀^環(huán)境改變不易，這里我們還是聊聊如何改變一些主觀性（即我們自己）。

我們知道，不同的產(chǎn)品經(jīng)理思維模式不同，設(shè)計出的系統(tǒng)也千差萬異。

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

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

用一張圖來表示就是：

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

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

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

2. 面對過去溯源，面向未來設(shè)計

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

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

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

3. 培養(yǎng)產(chǎn)品架構(gòu)與規(guī)劃能力

與開發(fā)打交道的過程中，經(jīng)常會聽到他們說起“技術(shù)架構(gòu)”。

我理解技術(shù)架構(gòu)的作用在于通過前期梳理出一系列結(jié)構(gòu)完整、邏輯清晰的技術(shù)模型，為系統(tǒng)構(gòu)建一套適配產(chǎn)品邏輯且數(shù)據(jù)關(guān)系合理的技術(shù)體系方案，進而為系統(tǒng)后續(xù)的開發(fā)及未來的維護奠定底層基礎(chǔ)。

那么作為PM的我們，在正式開始進行系統(tǒng)的細化設(shè)計之前，我想，也是應該先構(gòu)建出產(chǎn)品整體架構(gòu)的，產(chǎn)品架構(gòu)設(shè)計也能夠體現(xiàn)出一個產(chǎn)品經(jīng)理思考問題的全面性、邏輯性和結(jié)構(gòu)性。

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

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

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

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

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

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

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

那么，現(xiàn)在的我具體是如何做的呢？

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

隨后，如果是新設(shè)計一個系統(tǒng)或一組功能模塊，我會接著進行產(chǎn)品架構(gòu)圖的設(shè)計，這張圖是用于表示系統(tǒng)的模塊結(jié)構(gòu)、功能集成及整體產(chǎn)品布局，同時確定哪些模塊是需要一期實現(xiàn)的，哪些模塊可以放至后期迭代。

接著，我會對需求涉及重要數(shù)據(jù)流的部分給出一張實體關(guān)系圖（E-R圖），這是為幫助開發(fā)同學建立數(shù)據(jù)結(jié)構(gòu)關(guān)系，同時通過梳理我也強制自己盡可能想清各實體之間的關(guān)聯(lián)關(guān)系，以達到系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的合理性。

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

經(jīng)過這一系列流程，我就完成了一項中型及以上復雜程度需求的產(chǎn)品架構(gòu)梳理、整體規(guī)劃以及具體到功能實現(xiàn)的說明。

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

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

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

1. 訓練結(jié)構(gòu)化思維習慣；
2. 面對過去溯源，面向未來設(shè)計；
3. 培養(yǎng)產(chǎn)品架構(gòu)與規(guī)劃能力。

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

最后，愿天下所有懷著真摯產(chǎn)品之心的同學，做出的系統(tǒng)都合理，設(shè)計的功能都有意義。

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

本文由 @Han 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。