起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識“不見天日”的后臺產品——組織效率的基礎設施
編輯導語：企業(yè)都會有后臺系統(tǒng)，后臺管理系統(tǒng)是內容管理系統(tǒng)，后臺系統(tǒng)記錄著各種信息，功能強大，一個好的后臺系統(tǒng)可以幫助我們提高工作效率；本文作者從組織效率的角度闡述后臺系統(tǒng)的設計原則，我們一起來看一下。
社區(qū)里很多后臺系統(tǒng)的文章，此篇文章從組織效率的角度闡述后臺系統(tǒng)的設計原則，希望可以給你帶來耳目一新的體驗。
后臺系統(tǒng)與組織效率的關系：
企業(yè)之所以存在，因為其產生了某種價值；且通過模式設計，平衡用戶價值與企業(yè)價值并從中獲利，企業(yè)中的所有人都是為了這個價值的傳遞而存在。（可參考《俯視職場迷宮-做好你的職場定位》）
因此在：產品價值、商業(yè)模式、組織生產力確定時，組織生產效率則是價值傳遞的最大變量，此時決定企業(yè)生產效率核心變量就是組織的生產關系。
與生產關系相關的因素：
- 個人因素——個人管理。
- 組織因素——組織管理。
- 組織協同工具——“后臺系統(tǒng)”。
不管效率是來自科學分工，還是協同管理，其落實到實際操作層面都需要相應生產工具來支撐；因此“后臺工具”是組織生產關系的載體，是組織效率的基礎設施。
舉個例子：村子里有最好吃的大米種子，且市場對此大米供不應求，村民都是種地能手；But！鐮刀錘子收割機不好使，你說這事咋弄呢。
那么后臺系統(tǒng)是如何影響組織生產關系的呢？
舉幾個例子：
例1：嚴重缺失的后臺系統(tǒng)，讓團隊協作效率極低。
無財務系統(tǒng)，財務管理全靠EXCEL，從銷售，到運營，到財務，到領導，全部靠人工傳遞，Execl記錄；這樣不僅會讓各個環(huán)節(jié)的溝通協作效率低下，甚至會直接導致“財務誤差”“財務造假”等有損組織利益的后果。
當然是否需要完善支撐系統(tǒng)，還得考慮組織發(fā)展的階段，例如：在產品初期或者創(chuàng)業(yè)型公司或者比較邊緣的部門，由于優(yōu)先級和資源有限，只能靠人力線下協同。
比如我經常聽到的一些話：“你的產品能不能活過今年都不知道呢，做什么財務系統(tǒng)，先人工搞吧”，“要不先隨便整個小工具臨時用著吧”。 當然不存在對與錯，核心在“權衡”。
例2：繁雜的后臺工具，讓部門溝通成本陡增。
或許你有這種經歷：做一件工作需跨越多個系統(tǒng)，使用多套賬號，和多人溝通?！毩⒐ぷ鞅幌到y(tǒng)切割成多個片段。
例3：沒有經過高度抽象的后臺系統(tǒng)，靈活度低，嚴重拖累業(yè)務發(fā)展效率。
年終規(guī)劃，BOSS：明年的商品組合套餐A+B+C，銷售策略X，Y，Z，獎金提成方案Z，為了支撐明年的年度規(guī)劃，必須在年前完成后臺系統(tǒng)的升級支撐。
產研團隊加班加點，過年都差點沒回家，終于完成了。
3個月之后，商品組合策略，銷售策略，提成管理方案全變了；此時小則迭代功能，大則需要改版重構，嚴重拖累業(yè)務發(fā)展效率。
市場和管理的變化是無法避免的，而聰明的產品經理需要識別影響變化的最底層因素，然后層層抽象產品設計，為研發(fā)提供靈活的架構設計；可以做到隨著業(yè)務的變化靈活配置，高效迭代。
例4：分散的后臺工具，嚴重損傷用戶體驗。
- 客戶：我要開通xx模塊權限。
- 銷售：好的，我們可以隨時支持不同的模塊配置。
- 銷售：運營小姐姐你好，麻煩幫忙開通xx模塊權限。
- 需求到了公司內部：內部繼續(xù)傳遞（運營部門，產品組，中臺，用戶中心…）
每個部門都有自己重要緊急的工作，這項工作只是各自邊緣支撐工作，響應效率必然低下；郵件，微信半天后才回復，甚至完全被遺漏。
于是半天過去，一天過去了…
- 客戶：為什么要沒有開通？我們要用??！
- 銷售：我TM就想開通一個模塊權限，怎么這么難呢？不是你們說可以隨時支持開通的嗎？
因此從這個角度，“后臺系統(tǒng)”絕不僅僅是為了“支撐業(yè)務”，而是整個組織效率的核心保障。
精心設計的后臺體系——讓組織協同效率1+1>2，沒有經過深度思考的后臺體系——讓組織效率1+1<2。
如何規(guī)劃建設后臺體系，才能盡量避免上面的4個例子？下面為筆者的簡單總結，如有不足，歡迎讀者指教探討。
- 全局觀意識——產品經理進階必須要有的意識。
- 業(yè)務調研——扎入與業(yè)務相關的所有團隊。
- 業(yè)務抽象——把組織復雜的工作關系高度抽象：流程化，模塊化。
- 實體關系抽象——結構化，對象化架構建設：面向實施。
- 原型設計——效率第一，行為層體驗>視覺層>情感層。
一、全局觀意識
產品經理崗位，從初級到高級的過程，某種意義上也是“產品視角”迭代的過程。
1）功能視角
產品實習生/助理：接到某個任務，完成某個功能點的設計。
2）單產品視角
某個產品模塊，或者某個產品的負責人：整體規(guī)劃產品的不同模塊的迭代計劃。
3）多業(yè)務視角
高階產品經理：不僅僅關注產品本身，與產品相關的：運營，市場，銷售要全局關注。站在“整個業(yè)務的視角看產品”
4）多產品多業(yè)務視角
產品主管/總監(jiān)：負責多個產品多條業(yè)務，權衡企業(yè)戰(zhàn)略，顧及多個部門。全局規(guī)劃管理“企業(yè)產品矩陣”。
雖然會隨著經驗，關注的層面不同。但是作為產品經理，哪怕你目前只對一個單點功能負責，如果可以，也一定站在全局的視角思考問題。
產品僅僅是解決某個現實問題而產生某種“價值”，但是實現這個價值需要：識別定義價值（產品）、實現價值（技術/生產部門）、傳遞價值（市場/運營部門）、交換價值（運營/銷售部門）。
而這個從價值定義到完成價值交換的過程，是企業(yè)內部不同屬性的生產力，通過不同方式的生產關系，使用不同的生產工具協同進行。
因此當產品經理在設計組織“生產工具”時，首先需要有“全局觀”的認知高度；哪怕最終交付的成果是受限于優(yōu)先級和資源瓶頸，而不得不做的取舍，那也是從“組織效率”全局考慮后的取舍。
二、業(yè)務調研
1. 找誰調研？
所謂業(yè)務調研，就是徹底搞清楚你所做的系統(tǒng)涉及到公司所有相關部門/相關人/相關系統(tǒng)，以及他們的工作內容，工作目的。
比如，如果你做的是一個財務系統(tǒng)，涉及到的系統(tǒng)：商品管理系統(tǒng)、訂單管理系統(tǒng)，甚至還有運營/ 銷售人員的績效管理系統(tǒng)、供應鏈、人力資源等等。
同時涉及到的部門可能有：財務部、商品訂單管理部、運營部、HR部、銷售部、BOSS團等。
2. 如何調研？——一定要透徹！
還拿財務系統(tǒng)舉例：財務最核心的就是“營收”和“成本”，這里只從“營收”端舉例。
你可能需要搞清楚幾個問題：
- 營收的錢來自哪里？——銷售產品/服務，當然也有可能來自投資。
- 銷售是如何售賣產品的？如何回款的？
不同的商業(yè)模式，決定不同的銷售模式。這里我們用ToB的商業(yè)模式舉例，因為要比toC的模式更復雜。
銷售：拜訪客戶，介紹產品，拿下客戶后應該會有下面幾步：
【試用】——>【定金】——>【預付款】——>【部分回款】——>【回尾款】
再深入調研你會發(fā)現，很多不在主流程之內的操作，比如：【賒銷】【墊付】【拖欠尾款】【代理商提成】【代理商壓錢】【客戶返利】【銷售人員為了業(yè)績故意分批回款】，甚至還有“避稅”的操作。
回款后資金如何在各個系統(tǒng)和團隊之間流動的？各團隊的工作目標是什么？這里就不詳細舉例了。
做過電商后臺和財務系統(tǒng)的人都知道，“錢”的事情，1毛錢對不上都可能是個大隱患；這些業(yè)務場景你不吃透，那迎接你的不僅僅是各種零散的需求迭代，還有可能是“算不清賬的財務危機”
所以：理清楚你的后臺工具所有相關方，一定要扎入到業(yè)務深處，搞清楚每個相關方的工作內容和目的，這樣你的輸出才是最“底層”的需求。
值得注意的是：即使你弄明白這些，你也不能從傳統(tǒng)的“迎合用戶需求”的角度來解決問題。因為你讓“銷售人員”爽了，其他人可能就“不爽”了。
3. 調研輸出
最基礎的應該是“泳道圖”了。
比如上面舉的例子輸出的泳道圖（例子是虛擬的，泳道圖只是粗狂的示意，讀者勿深究哈）。
各方同步結論： 由于涉及團隊和人員較多，最終輸出流程需和大家確定；若某些流程與相關方的利益沖突，需要從組織目標和效率去權衡。
4. 注意事項——業(yè)務調研肯定會遇到的問題，劃重點
全局觀思考各個組織的利益屬性和組織的終極目標。
各方利益不一致，例如銷售要方便，要靈活多變。管理者要規(guī)范，要統(tǒng)籌管理。
一個簡單的例子：“不回款就不給發(fā)貨”。這聽起來是理所應當的管理手段。
但是深入銷售場景后你會發(fā)現：
- “客戶要求必須先發(fā)貨后打款，你發(fā)不發(fā)？”，
- “代理商壓著錢，但是客戶已經付了錢，你發(fā)不發(fā)貨？”，
- “客戶下禮拜100%回款，但是這禮拜不得不用你們的產品，你發(fā)不發(fā)？”等等。
此時作為工具的設計者，可不能傻乎乎的去“滿足需求”。 還得結合多方需求，用全局視角輸出方案。當然聰明的產品經理有辦法通過設計兼得“魚與熊掌”。
所有業(yè)務相關者不是你的同事，而是你的用戶。
我經常會后臺系統(tǒng)產品經理和提需求的業(yè)務方爭論爭吵。甚至吵到領導那去決策。
個人理解，出現這樣情況的根本原因：產品經理沒有把同事視為“用戶”。用戶調研，我們都知道“不要聽用戶說什么，而是探究其背后的根本訴求”。
作為內部需求方，我們的同事也和所有用戶一樣：不會說出其根本訴求，直接給你他們理解的“解決方案”，說不清具體需求等等；于是你很無奈，讓他去想起楚，他不理解，于是帶來的就是爭論而不是討論。
試著把同事當成用戶，他們本來就是你的用戶，那你就需要用戶調研的思維主動挖掘其背后的根本訴求；此時你需要去溝通，去理解，并且?guī)椭?、歸納、總結、輸出； 這樣的結果應該是“哇，太棒了，你說的有道理，是這樣的，我自己都沒想到，這樣也可以啊”。
別指望用戶和你在一個頻道上，而是主動理解別人的話語體系+思維模式。
這是多么痛的領悟，筆者曾需要和銷售，運營，財務，教研，HR等多個團隊溝通對接；最大的感觸就是“每個人的思維模式都不同”“每個人/每個組織的話語體系都不同”，如果不站在別人的思維模式，不站在別人的話語體系去理解溝通；那溝通效率低都是小事，甚至最終得出的結論雙方都覺得沒問題，實際卻南轅北轍。
相信這樣的領悟，你們也有很多。
調研要深入到具體的執(zhí)行人，而不是組長/主觀等部門領導。
這點非常重要，很多產品經理都喜歡找組長、主管，但是組長，主管可能是最不了解細節(jié)的人；他們只能說過大概過程，不知具體的操作細節(jié)；甚至為了體現他們的“專業(yè)”會憑直覺給你介紹操作細節(jié)。
一定要深入到具體的執(zhí)行人，操作人，除非你是在給領導做工具。
你需要主動去學習相關的領域知識；比如上面舉例財務系統(tǒng)的例子，最基礎的財務知識你需要去了解，“企業(yè)三張表”“會計學基礎知識”等。
如果是給HR或者管理層做工具，最基礎的管理學知識你需要去了解，“OKR“KPI”等。
如果是給教研做工具，那教育教學的領域知識你需要去了解，“新高考評價體系”“新教材大綱”“學科學習路徑”等。
產品經理——必須是π型人才；博學廣知的基礎上，深入1~2個領域成為領域專家，這也是筆者當前正在突破的瓶頸。
5. 總結
如果這一層調研沒有做好做透，那你的系統(tǒng)給組織效率帶來的收益要么就是0收益，要么就是負收益。
試想一下：
你理解的問題是A，設計的流程是B； 實際的問題是A+，流程是B+， 那上線后要么很難用，要么不能用；影響的不僅僅是產研測團隊再次改版迭代，更是所有相關部門相關人的組織效率。
而你就是“罪惡的源頭”。
深入業(yè)務調研，只是第一步，接下來需要把你調研來的“知識”進行分類抽象，指導落地實施。
三、業(yè)務抽象
1. 業(yè)務流程模塊化抽象。
把上面已經被你理解透徹的業(yè)務知識層層抽象。
簡單舉例說明：
例1：最常見的電商后臺，模塊化抽象后的結果。
如下圖（百度下載的），看到這個完善的抽象結果，你應該意識到這是在整個電商業(yè)務所有相關組織相關人的工作流程、細節(jié)等都已經吃透之后的輸出。
舉例2：K12資源后臺管理系統(tǒng)。
沒有這層抽象，團隊連精細化分工可能都很困難，當然這一層抽象也是是研發(fā)架構的基礎。
更重要的是理清楚：
- 每個模塊的用戶（負責人）是誰？
- 該用戶上下游協同者是誰？
- 模塊之間的邊界清晰嗎？對應的職責清晰嗎？
- 如何為他們的工作目標提供高效的協同工具？
如果這一層沒有抽象好，研發(fā)架構靈活性低，重抽成本高這些顯性問題都是小代價；而給各個部門帶來的隱形協同成本才是更嚴重的，比如，干一件簡單的事情需要登陸多個系統(tǒng)，一件單點工作被拆在多個流程中完成，數據孤島等。
更嚴重的是這些隱型成本是很難被組織注意到的，它們藏在組織最底層最隱蔽的角落，“被害者”往往是組織“最底層”執(zhí)行者；他們從抱怨到習以為常，甚至覺得這是“打工人”理所應當承擔的日?，嵤隆Ｆ鋵嵍际恰爱a品經理”的問題。
2. 業(yè)務抽象參與者
這個環(huán)節(jié)參與者包含：產品經理、研發(fā)經理、業(yè)務代表。
業(yè)務抽象是業(yè)務和研發(fā)的橋梁，很多公司要么研發(fā)經理等著產品經理自己梳理好；要么產品經理梳理完上一個業(yè)務流程后就直接進入產品細節(jié)設計，把業(yè)務抽象建模的工作拋給了研發(fā)團隊，這樣的結果就是——架構建模脫離了業(yè)務領域知識，那設計出來的領域模型固然會和業(yè)務有代溝。
業(yè)務代表在這個環(huán)節(jié)參與可能性就更小了，因為：
- 業(yè)務人員覺得這不是他的工作，他沒理由參與。
- 各方都很忙，能不參與就不參與。
- 產品經理覺得業(yè)務調研已經搞定，無需業(yè)務過多的參與。
如果產品經理有自信，此時自己的業(yè)務知識就完全能代表業(yè)務方了，那固然完美；如果不能還是把業(yè)務代表拉著一起比較好。
這里要規(guī)避的：
- 話語體系一致性，比如模塊的命名，保障所有人都是一個理解頻道。
- 模塊對應的工作職責是否界定明確。
- 管理上的多變性帶來的可能影響等等
四、實體關系建模
經歷過業(yè)務調研、業(yè)務建模、輸出業(yè)務流程圖、業(yè)務模型圖。
下一步絕大多數產品經理都開始進入產品設計階段了，而在這之前還有重要的一項工作：實體關系建模；當然這一層也需要根據情況而定，可能大多時候的“實體關系”都很明確，就無需產品經理再抽象了。
到底什么是“實體關系建?！?，可以解決什么問題呢？ 相信學過軟件工程的同學已經知道我要說什么了。
舉幾個例子：
例1：承接上文還是拿電商系統(tǒng)舉例，最簡單的例子：商品（SPU）與最小庫存單位（SKU）兩個“實體對象”之間的關系：
例2：對象與對象之間還會存在關系，關系也會存在屬性：
此為筆者遇到的一個真實案例：系統(tǒng)中一份高考試卷的總分和高考的真實總分不同，從而給用戶帶來不好的體驗，如何解決呢？
這個問題如果從產品設計/分數計算規(guī)則的思考邏輯是很難解決的，如果有“面向對象”的設計思維，其實就很容易理解并解決。
原因是：高考試卷中有2道選做題，總分只算1題的；但由于系統(tǒng)設計時未考慮到試題和試卷的關系屬性，丟了選做題這個關系屬性，自然試卷的總分算了2題選做題的，考慮到這里問題也就迎刃而解了。
以上兩個例子，不管你在做什么產品設計都比比皆是；例如權限管理，就是要理清楚：角色與權限的實體關系。
如果這一層關系沒理清楚，那整個權限體系會極大的降低組織效率，例如：
- 想開個系統(tǒng)權限不知道找誰，咨詢了半天耽誤了重要工作。
- n個部門，n2個人需要開各種權限都找產品或者運營，嚴重分散工作精力。
- 申請個簡單的權限需要層層審批。
- 換部門，離職后權限管控不及時甚至混亂。
此處對于權限體系的抽象設計不打開講了，屬于任何系統(tǒng)的基本配置，基本功了。
對于“實體關系抽象”的思維，不僅工作，生活和學習中都非常實用，它更是一中結構化思維的“工具”； 也是我在“數據結構”“C++”這些計算機基礎課程中學習到最實用的“思維方式”。
1. 總結
如果沒有做好這一層抽象，組織效率被拉低可能會體現在這幾個方面：
- 很多看似很簡單的問題，解決成本卻異常的高。比如我上圖說的試題與試卷的關系抽象。
- 面對內部流程，管理，人員的多變性你的后臺系統(tǒng)支撐效率嚴重滯后。
- 產品與研發(fā)不在一個頻道上溝通。
這一層的參與角色毋庸置疑：產品經理+研發(fā)團隊。且大多時候需要研發(fā)主導，只是在很多業(yè)務相關性很強的實體抽象上產品經理務必參與。
好了，終于可以進入產品設計（畫原型）階段了。
等等! 別高興的太早。
嚴謹的設計還有一個很重要的環(huán)節(jié)“數據流”設計，但是由于本人比較懶，也比較粗（我說的粗是指性格的粗獷），所以這一層具體工作大多都移交給研發(fā)了；不過不做不代表不重要，重要的是你應該具備“數據意識”；你需要清晰的知道“你要哪些數據”、“未來可能需要哪些數據”、“哪些數據需要埋點，哪些需要日志或者業(yè)務庫記錄”，這樣研發(fā)在做設計的時候才能有目的的設計數據流。
五、原型設計
1. 這里主要說一個原則：效率第一
在說明這個原則之前，先用《設計心理學》書里的觀念把設計分類三個層次：本能層、行為層、反思層。
這三層我從自己的角度給個比較膚淺的解釋：好看、好用、好爽。
如果還不好理解，我再用男人女人來解釋：一見鐘情（好看-本能層面），相互協助（好用-行為層面），志同道合（好爽-精神層面）。
好了，你應該理解了；只是需要注意的是并不是一個產品要兼具所有層面，不同產品不同定位，切入點就完全不同。
比如很多“網紅產品”核心就是本能層（顏值高），工具類產品核心定位就是行為層（好用第一）；還有一些產品需要從反思層切入，比如很多禮品、奢侈品，用戶購買圖的并不是好看好用，而是精神層面的需要。
從這個角度理解，后臺系統(tǒng)的交互設計原則就很清晰明確了——行為層，好用！效率第一！ 這也是提高組織效率的最核心因素。
2. 那么好用的原則是什么呢？
交互設計就不班門弄斧了，或許還可從下面幾個維度拆解：
- 邏輯清晰。
- 反饋明確。
- 異常監(jiān)控。
可以嘗試給自己下個指標：不需要系統(tǒng)說明文檔，不需要培訓，上線后各個部門小伙伴可以直接使用。
3. 沒有做好設計的badcase
- 內部溝通成本高：培訓、咨詢等等
- 內部干活效率低。
- 人員變動后沒人知道怎么用了。
六、總結
本文從組織效率的角度梳理了后臺系統(tǒng)從0到1的搭建過程，這個過程都是基礎的方法論，只是提供一個全局觀和協同效率的意識；有了這個意識，工作中很多的難題甚至苦惱之處或許都能迎刃而解。
或許本質上：管理思想是管理軟件的靈魂，管理軟件是管理思想的呈現。
因此如果你是做公司的最后端，做著“不見天日”的后臺工具；從這個角度，恭喜你，有機會接觸不同崗位，思考跨組織的協同管理，企業(yè)效率等管理意識；后臺系統(tǒng)需要學習的“領域知識”就是“管理知識”。
一個組織的后臺系統(tǒng)有多亂就說明組織集體的“管理意識”“協同意識”有多低。
組織效率必然低，根本原因不是低在工具，而是組織的意識和認知。
以上僅為筆者個人觀點，歡迎指教，探討。
本文由 @樂樂（教育產品經理） 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
寫得真好，受益匪淺，雖然覺得有點難
寫得好棒！