“不見天日”的後台產品——組織效率的基礎設施

社區裏很多後台系統的文章，此篇文章從組織效率的角度闡述後台系統的設計原則，希望可以給你帶來耳目一新的體驗。

後台系統與組織效率的關係：

企業之所以存在，因為其產生了某種價值；且通過模式設計，平衡用户價值與企業價值並從中獲利，企業中的所有人都是為了這個價值的傳遞而存在。（可參考《俯視職場迷宮-做好你的職場定位》）

因此在：產品價值、商業模式、組織生產力確定時，組織生產效率則是價值傳遞的最大變量，此時決定企業生產效率核心變量就是組織的生產關係。

與生產關係相關的因素：

• 個人因素——個人管理。
• 組織因素——組織管理。
• 組織協同工具——“後台系統”。

不管效率是來自科學分工，還是協同管理，其落實到實際操作層面都需要相應生產工具來支撐；因此“後台工具”是組織生產關係的載體，是組織效率的基礎設施。

舉個例子：村子裏有最好吃的大米種子，且市場對此大米供不應求，村民都是種地能手；But！鐮刀錘子收割機不好使，你説這事咋弄呢。

那麼後台系統是如何影響組織生產關係的呢？

舉幾個例子：

例1：嚴重缺失的後台系統，讓團隊協作效率極低。

無財務系統，財務管理全靠EXCEL，從銷售，到運營，到財務，到領導，全部靠人工傳遞，Execl記錄；這樣不僅會讓各個環節的溝通協作效率低下，甚至會直接導致“財務誤差”“財務造假”等有損組織利益的後果。

當然是否需要完善支撐系統，還得考慮組織發展的階段，例如：在產品初期或者創業型公司或者比較邊緣的部門，由於優先級和資源有限，只能靠人力線下協同。

比如我經常聽到的一些話：“你的產品能不能活過今年都不知道呢，做什麼財務系統，先人工搞吧”，“要不先隨便整個小工具臨時用着吧”。 當然不存在對與錯，核心在“權衡”。

例2：繁雜的後台工具，讓部門溝通成本陡增。

或許你有這種經歷：做一件工作需跨越多個系統，使用多套賬號，和多人溝通。——獨立工作被系統切割成多個片段。

例3：沒有經過高度抽象的後台系統，靈活度低，嚴重拖累業務發展效率。

年終規劃，BOSS：明年的商品組合套餐A+B+C，銷售策略X，Y，Z，獎金提成方案Z，為了支撐明年的年度規劃，必須在年前完成後台系統的升級支撐。

產研團隊加班加點，過年都差點沒回家，終於完成了。

3個月之後，商品組合策略，銷售策略，提成管理方案全變了；此時小則迭代功能，大則需要改版重構，嚴重拖累業務發展效率。

市場和管理的變化是無法避免的，而聰明的產品經理需要識別影響變化的最底層因素，然後層層抽象產品設計，為研發提供靈活的架構設計；可以做到隨着業務的變化靈活配置，高效迭代。

例4：分散的後台工具，嚴重損傷用户體驗。

• 客户：我要開通xx模塊權限。
• 銷售：好的，我們可以隨時支持不同的模塊配置。
• 銷售：運營小姐姐你好，麻煩幫忙開通xx模塊權限。
• 需求到了公司內部：內部繼續傳遞（運營部門，產品組，中台，用户中心…）

每個部門都有自己重要緊急的工作，這項工作只是各自邊緣支撐工作，響應效率必然低下；郵件，微信半天后才回復，甚至完全被遺漏。

於是半天過去，一天過去了…

• 客户：為什麼要沒有開通？我們要用啊！
• 銷售：我TM就想開通一個模塊權限，怎麼這麼難呢？不是你們説可以隨時支持開通的嗎？

因此從這個角度，“後台系統”絕不僅僅是為了“支撐業務”，而是整個組織效率的核心保障。

精心設計的後台體系——讓組織協同效率1+1>2，沒有經過深度思考的後台體系——讓組織效率1+1<2。

如何規劃建設後台體系，才能儘量避免上面的4個例子？下面為筆者的簡單總結，如有不足，歡迎讀者指教探討。

• 全局觀意識——產品經理進階必須要有的意識。
• 業務調研——扎入與業務相關的所有團隊。
• 業務抽象——把組織複雜的工作關係高度抽象：流程化，模塊化。
• 實體關係抽象——結構化，對象化架構建設：面向實施。
• 原型設計——效率第一，行為層體驗>視覺層>情感層。

一、全局觀意識

產品經理崗位，從初級到高級的過程，某種意義上也是“產品視角”迭代的過程。

1）功能視角

產品實習生/助理：接到某個任務，完成某個功能點的設計。

2）單產品視角

某個產品模塊，或者某個產品的負責人：整體規劃產品的不同模塊的迭代計劃。

3）多業務視角

高階產品經理：不僅僅關注產品本身，與產品相關的：運營，市場，銷售要全局關注。站在“整個業務的視角看產品”

4）多產品多業務視角

產品主管/總監：負責多個產品多條業務，權衡企業戰略，顧及多個部門。全局規劃管理“企業產品矩陣”。

雖然會隨着經驗，關注的層面不同。但是作為產品經理，哪怕你目前只對一個單點功能負責，如果可以，也一定站在全局的視角思考問題。

產品僅僅是解決某個現實問題而產生某種“價值”，但是實現這個價值需要：識別定義價值（產品）、實現價值（技術/生產部門）、傳遞價值（市場/運營部門）、交換價值（運營/銷售部門）。

而這個從價值定義到完成價值交換的過程，是企業內部不同屬性的生產力，通過不同方式的生產關係，使用不同的生產工具協同進行。

因此當產品經理在設計組織“生產工具”時，首先需要有“全局觀”的認知高度；哪怕最終交付的成果是受限於優先級和資源瓶頸，而不得不做的取捨，那也是從“組織效率”全局考慮後的取捨。

二、業務調研1. 找誰調研？

所謂業務調研，就是徹底搞清楚你所做的系統涉及到公司所有相關部門/相關人/相關係統，以及他們的工作內容，工作目的。

比如，如果你做的是一個財務系統，涉及到的系統：商品管理系統、訂單管理系統，甚至還有運營/ 銷售人員的績效管理系統、供應鏈、人力資源等等。

同時涉及到的部門可能有：財務部、商品訂單管理部、運營部、HR部、銷售部、BOSS團等。

2. 如何調研？——一定要透徹！

還拿財務系統舉例：財務最核心的就是“營收”和“成本”，這裏只從“營收”端舉例。

你可能需要搞清楚幾個問題：

• 營收的錢來自哪裏？——銷售產品/服務，當然也有可能來自投資。
• 銷售是如何售賣產品的？如何回款的？

不同的商業模式，決定不同的銷售模式。這裏我們用ToB的商業模式舉例，因為要比toC的模式更復雜。

銷售：拜訪客户，介紹產品，拿下客户後應該會有下面幾步：

【試用】——>【定金】——>【預付款】——>【部分回款】——>【回尾款】

再深入調研你會發現，很多不在主流程之內的操作，比如：【賒銷】【墊付】【拖欠尾款】【代理商提成】【代理商壓錢】【客户返利】【銷售人員為了業績故意分批迴款】，甚至還有“避税”的操作。

回款後資金如何在各個系統和團隊之間流動的？各團隊的工作目標是什麼？這裏就不詳細舉例了。

做過電商後台和財務系統的人都知道，“錢”的事情，1毛錢對不上都可能是個大隱患；這些業務場景你不吃透，那迎接你的不僅僅是各種零散的需求迭代，還有可能是“算不清賬的財務危機”

所以：理清楚你的後台工具所有相關方，一定要扎入到業務深處，搞清楚每個相關方的工作內容和目的，這樣你的輸出才是最“底層”的需求。

值得注意的是：即使你弄明白這些，你也不能從傳統的“迎合用户需求”的角度來解決問題。因為你讓“銷售人員”爽了，其他人可能就“不爽”了。

3. 調研輸出

最基礎的應該是“泳道圖”了。

比如上面舉的例子輸出的泳道圖（例子是虛擬的，泳道圖只是粗狂的示意，讀者勿深究哈）。

各方同步結論： 由於涉及團隊和人員較多，最終輸出流程需和大家確定；若某些流程與相關方的利益衝突，需要從組織目標和效率去權衡。

4. 注意事項——業務調研肯定會遇到的問題，劃重點

全局觀思考各個組織的利益屬性和組織的終極目標。

各方利益不一致，例如銷售要方便，要靈活多變。管理者要規範，要統籌管理。

一個簡單的例子：“不回款就不給發貨”。這聽起來是理所應當的管理手段。

但是深入銷售場景後你會發現：

• “客户要求必須先發貨後打款，你發不發？”，
• “代理商壓着錢，但是客户已經付了錢，你發不發貨？”，
• “客户下禮拜100%回款，但是這禮拜不得不用你們的產品，你發不發？”等等。

此時作為工具的設計者，可不能傻乎乎的去“滿足需求”。 還得結合多方需求，用全局視角輸出方案。當然聰明的產品經理有辦法通過設計兼得“魚與熊掌”。

所有業務相關者不是你的同事，而是你的用户。

我經常會後台系統產品經理和提需求的業務方爭論爭吵。甚至吵到領導那去決策。

個人理解，出現這樣情況的根本原因：產品經理沒有把同事視為“用户”。用户調研，我們都知道“不要聽用户説什麼，而是探究其背後的根本訴求”。

作為內部需求方，我們的同事也和所有用户一樣：不會説出其根本訴求，直接給你他們理解的“解決方案”，説不清具體需求等等；於是你很無奈，讓他去想起楚，他不理解，於是帶來的就是爭論而不是討論。

試着把同事當成用户，他們本來就是你的用户，那你就需要用户調研的思維主動挖掘其背後的根本訴求；此時你需要去溝通，去理解，並且幫助他整理、歸納、總結、輸出； 這樣的結果應該是“哇，太棒了，你説的有道理，是這樣的，我自己都沒想到，這樣也可以啊”。

別指望用户和你在一個頻道上，而是主動理解別人的話語體系+思維模式。

這是多麼痛的領悟，筆者曾需要和銷售，運營，財務，教研，HR等多個團隊溝通對接；最大的感觸就是“每個人的思維模式都不同”“每個人/每個組織的話語體系都不同”，如果不站在別人的思維模式，不站在別人的話語體系去理解溝通；那溝通效率低都是小事，甚至最終得出的結論雙方都覺得沒問題，實際卻南轅北轍。

相信這樣的領悟，你們也有很多。

調研要深入到具體的執行人，而不是組長/主觀等部門領導。

這點非常重要，很多產品經理都喜歡找組長、主管，但是組長，主管可能是最不瞭解細節的人；他們只能説過大概過程，不知具體的操作細節；甚至為了體現他們的“專業”會憑直覺給你介紹操作細節。

一定要深入到具體的執行人，操作人，除非你是在給領導做工具。

你需要主動去學習相關的領域知識；比如上面舉例財務系統的例子，最基礎的財務知識你需要去了解，“企業三張表”“會計學基礎知識”等。

如果是給HR或者管理層做工具，最基礎的管理學知識你需要去了解，“OKR“KPI”等。

如果是給教研做工具，那教育教學的領域知識你需要去了解，“新高考評價體系”“新教材大綱”“學科學習路徑”等。

產品經理——必須是π型人才；博學廣知的基礎上，深入1~2個領域成為領域專家，這也是筆者當前正在突破的瓶頸。

5. 總結

如果這一層調研沒有做好做透，那你的系統給組織效率帶來的收益要麼就是0收益，要麼就是負收益。

試想一下：

你理解的問題是A，設計的流程是B； 實際的問題是A+，流程是B+， 那上線後要麼很難用，要麼不能用；影響的不僅僅是產研測團隊再次改版迭代，更是所有相關部門相關人的組織效率。

而你就是“罪惡的源頭”。

深入業務調研，只是第一步，接下來需要把你調研來的“知識”進行分類抽象，指導落地實施。

三、業務抽象1. 業務流程模塊化抽象。

把上面已經被你理解透徹的業務知識層層抽象。

簡單舉例説明：

例1：最常見的電商後台，模塊化抽象後的結果。

如下圖（百度下載的），看到這個完善的抽象結果，你應該意識到這是在整個電商業務所有相關組織相關人的工作流程、細節等都已經吃透之後的輸出。

舉例2：K12資源後台管理系統。

沒有這層抽象，團隊連精細化分工可能都很困難，當然這一層抽象也是是研發架構的基礎。

更重要的是理清楚：

• 每個模塊的用户（負責人）是誰？
• 該用户上下游協同者是誰？
• 模塊之間的邊界清晰嗎？對應的職責清晰嗎？
• 如何為他們的工作目標提供高效的協同工具？

如果這一層沒有抽象好，研發架構靈活性低，重抽成本高這些顯性問題都是小代價；而給各個部門帶來的隱形協同成本才是更嚴重的，比如，幹一件簡單的事情需要登陸多個系統，一件單點工作被拆在多個流程中完成，數據孤島等。

更嚴重的是這些隱型成本是很難被組織注意到的，它們藏在組織最底層最隱蔽的角落，“被害者”往往是組織“最底層”執行者；他們從抱怨到習以為常，甚至覺得這是“打工人”理所應當承擔的日常瑣事。其實都是“產品經理”的問題。

2. 業務抽象參與者

這個環節參與者包含：產品經理、研發經理、業務代表。

業務抽象是業務和研發的橋樑，很多公司要麼研發經理等着產品經理自己梳理好；要麼產品經理梳理完上一個業務流程後就直接進入產品細節設計，把業務抽象建模的工作拋給了研發團隊，這樣的結果就是——架構建模脱離了業務領域知識，那設計出來的領域模型固然會和業務有代溝。

業務代表在這個環節參與可能性就更小了，因為：

• 業務人員覺得這不是他的工作，他沒理由參與。
• 各方都很忙，能不參與就不參與。
• 產品經理覺得業務調研已經搞定，無需業務過多的參與。

如果產品經理有自信，此時自己的業務知識就完全能代表業務方了，那固然完美；如果不能還是把業務代表拉着一起比較好。

這裏要規避的：

• 話語體系一致性，比如模塊的命名，保障所有人都是一個理解頻道。
• 模塊對應的工作職責是否界定明確。
• 管理上的多變性帶來的可能影響等等

四、實體關係建模

經歷過業務調研、業務建模、輸出業務流程圖、業務模型圖。

下一步絕大多數產品經理都開始進入產品設計階段了，而在這之前還有重要的一項工作：實體關係建模；當然這一層也需要根據情況而定，可能大多時候的“實體關係”都很明確，就無需產品經理再抽象了。

到底什麼是“實體關係建模”，可以解決什麼問題呢？ 相信學過軟件工程的同學已經知道我要説什麼了。

舉幾個例子：

例1：承接上文還是拿電商系統舉例，最簡單的例子：商品（SPU）與最小庫存單位（SKU）兩個“實體對象”之間的關係：

例2：對象與對象之間還會存在關係，關係也會存在屬性：

此為筆者遇到的一個真實案例：系統中一份高考試卷的總分和高考的真實總分不同，從而給用户帶來不好的體驗，如何解決呢？

這個問題如果從產品設計/分數計算規則的思考邏輯是很難解決的，如果有“面向對象”的設計思維，其實就很容易理解並解決。

原因是：高考試卷中有2道選做題，總分只算1題的；但由於系統設計時未考慮到試題和試卷的關係屬性，丟了選做題這個關係屬性，自然試卷的總分算了2題選做題的，考慮到這裏問題也就迎刃而解了。

以上兩個例子，不管你在做什麼產品設計都比比皆是；例如權限管理，就是要理清楚：角色與權限的實體關係。

如果這一層關係沒理清楚，那整個權限體系會極大的降低組織效率，例如：

• 想開個系統權限不知道找誰，諮詢了半天耽誤了重要工作。
• n個部門，n²個人需要開各種權限都找產品或者運營，嚴重分散工作精力。
• 申請個簡單的權限需要層層審批。
• 換部門，離職後權限管控不及時甚至混亂。

此處對於權限體系的抽象設計不打開講了，屬於任何系統的基本配置，基本功了。

對於“實體關係抽象”的思維，不僅工作，生活和學習中都非常實用，它更是一中結構化思維的“工具”； 也是我在“數據結構”“C++”這些計算機基礎課程中學習到最實用的“思維方式”。

1. 總結

如果沒有做好這一層抽象，組織效率被拉低可能會體現在這幾個方面：

• 很多看似很簡單的問題，解決成本卻異常的高。比如我上圖説的試題與試卷的關係抽象。
• 面對內部流程，管理，人員的多變性你的後台系統支撐效率嚴重滯後。
• 產品與研發不在一個頻道上溝通。

這一層的參與角色毋庸置疑：產品經理+研發團隊。且大多時候需要研發主導，只是在很多業務相關性很強的實體抽象上產品經理務必參與。

好了，終於可以進入產品設計（畫原型）階段了。

等等! 別高興的太早。

嚴謹的設計還有一個很重要的環節“數據流”設計，但是由於本人比較懶，也比較粗（我説的粗是指性格的粗獷），所以這一層具體工作大多都移交給研發了；不過不做不代表不重要，重要的是你應該具備“數據意識”；你需要清晰的知道“你要哪些數據”、“未來可能需要哪些數據”、“哪些數據需要埋點，哪些需要日誌或者業務庫記錄”，這樣研發在做設計的時候才能有目的的設計數據流。

五、原型設計1. 這裏主要説一個原則：效率第一

在説明這個原則之前，先用《設計心理學》書裏的觀念把設計分類三個層次：本能層、行為層、反思層。

這三層我從自己的角度給個比較膚淺的解釋：好看、好用、好爽。

如果還不好理解，我再用男人女人來解釋：一見鍾情（好看-本能層面），相互協助（好用-行為層面），志同道合（好爽-精神層面）。

好了，你應該理解了；只是需要注意的是並不是一個產品要兼具所有層面，不同產品不同定位，切入點就完全不同。

比如很多“網紅產品”核心就是本能層（顏值高），工具類產品核心定位就是行為層（好用第一）；還有一些產品需要從反思層切入，比如很多禮品、奢侈品，用户購買圖的並不是好看好用，而是精神層面的需要。

從這個角度理解，後台系統的交互設計原則就很清晰明確了——行為層，好用！效率第一！ 這也是提高組織效率的最核心因素。

2. 那麼好用的原則是什麼呢？

交互設計就不班門弄斧了，或許還可從下面幾個維度拆解：

可以嘗試給自己下個指標：不需要系統説明文檔，不需要培訓，上線後各個部門小夥伴可以直接使用。

3. 沒有做好設計的badcase

• 內部溝通成本高：培訓、諮詢等等
• 內部幹活效率低。
• 人員變動後沒人知道怎麼用了。

六、總結

本文從組織效率的角度梳理了後台系統從0到1的搭建過程，這個過程都是基礎的方法論，只是提供一個全局觀和協同效率的意識；有了這個意識，工作中很多的難題甚至苦惱之處或許都能迎刃而解。

或許本質上：管理思想是管理軟件的靈魂，管理軟件是管理思想的呈現。

因此如果你是做公司的最後端，做着“不見天日”的後台工具；從這個角度，恭喜你，有機會接觸不同崗位，思考跨組織的協同管理，企業效率等管理意識；後台系統需要學習的“領域知識”就是“管理知識”。

一個組織的後台系統有多亂就説明組織集體的“管理意識”“協同意識”有多低。

組織效率必然低，根本原因不是低在工具，而是組織的意識和認知。

以上僅為筆者個人觀點，歡迎指教，探討。

本文由 @樂樂（教育產品經理） 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議