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

1 評論 4754 瀏覽 11 收藏 28 分鐘

編輯導語:企業都會有后臺系統,后臺管理系統是內容管理系統,后臺系統記錄著各種信息,功能強大,一個好的后臺系統可以幫助我們提高工作效率;本文作者從組織效率的角度闡述后臺系統的設計原則,我們一起來看一下。

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

后臺系統與組織效率的關系:

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

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

與生產關系相關的因素:

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

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

舉個例子:村子里有最好吃的大米種子,且市場對此大米供不應求,村民都是種地能手;But!鐮刀錘子收割機不好使,你說這事咋弄呢。

那么后臺系統是如何影響組織生產關系的呢?

舉幾個例子:

例1:嚴重缺失的后臺系統,讓團隊協作效率極低。

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

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

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

例2:繁雜的后臺工具,讓部門溝通成本陡增。

或許你有這種經歷:做一件工作需跨越多個系統,使用多套賬號,和多人溝通?!毩⒐ぷ鞅幌到y切割成多個片段。

例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個部門,n2個人需要開各種權限都找產品或者運營,嚴重分散工作精力。
  • 申請個簡單的權限需要層層審批。
  • 換部門,離職后權限管控不及時甚至混亂。

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

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

1. 總結

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

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

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

好了,終于可以進入產品設計(畫原型)階段了。

等等! 別高興的太早。

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

五、原型設計

1. 這里主要說一個原則:效率第一

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

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

如果還不好理解,我再用男人女人來解釋:一見鐘情(好看-本能層面),相互協助(好用-行為層面),志同道合(好爽-精神層面)。

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

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

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

2. 那么好用的原則是什么呢?

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

  • 邏輯清晰。
  • 反饋明確。
  • 異常監控。

可以嘗試給自己下個指標:不需要系統說明文檔,不需要培訓,上線后各個部門小伙伴可以直接使用。

3. 沒有做好設計的badcase

  • 內部溝通成本高:培訓、咨詢等等
  • 內部干活效率低。
  • 人員變動后沒人知道怎么用了。

六、總結

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

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

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

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

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

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

 

本文由 @樂樂(教育產品經理) 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫得好棒!

    回復