面對評論功能組件化，一位中臺產(chǎn)品經(jīng)理會怎么做？本文作者作為業(yè)務(wù)向轉(zhuǎn)型中臺產(chǎn)品經(jīng)理的親歷者，將自己的實操經(jīng)驗與大家一同分享。其中涵蓋：確定核心問題，如何抽象產(chǎn)品組件，串聯(lián)概念設(shè)計轉(zhuǎn)變?yōu)榱鞒淘O(shè)計等關(guān)鍵步驟，是一篇不可多得的組件化方法論。推薦小伙伴們交流學(xué)習(xí)～

很長時間以來，我的工作都是一名偏向業(yè)務(wù)的產(chǎn)品經(jīng)理。我的職責(zé)是幫助對接的業(yè)務(wù)實現(xiàn)更好的業(yè)務(wù)增長，這里的增長不僅包括收入的增長，也包括成本的降低。

但我很少有機(jī)會去做一名中臺產(chǎn)品經(jīng)理，以更抽象的視角去規(guī)劃各個業(yè)務(wù)都會用到的核心功能。

雖然我一直都明白中臺產(chǎn)品經(jīng)理的職責(zé)是什么，但沒有什么機(jī)會去實踐。而我相信，一件事情做過還是沒有做過，認(rèn)識是完全不一樣的。

所以去年年底的時候，老板說讓我去負(fù)責(zé)「評論組件化」這個項目，我意識到這是一次實現(xiàn)自我突破的好機(jī)會。因為這對我來說是一次巨大的挑戰(zhàn)，我之前從未負(fù)責(zé)過類似的產(chǎn)品。

現(xiàn)在，三周過去了，我也從最初毫無邏輯，到完成了整個方案的評審，一路走來感慨頗多。即驕傲于自己在三周內(nèi)完成了方案的輸出和評審，也謙卑于對于未知的世界，站在里面和站在外面，看到的東西有多么的不一樣。

于是決定將這三周的實操經(jīng)驗分享出來，供更多從業(yè)務(wù)走向中臺的產(chǎn)品經(jīng)理參考。

一、確認(rèn)動機(jī)

對我來說，當(dāng)我知道一件事情將要花去我很多的精力時，我一定要搞清楚兩件事：

1. 這件事為什么要做
2. 這件事為什么現(xiàn)在就要做

在解釋為什么要做「評論組件化」這件事之前，我首先想跟大家解釋一下這個項目是什么。

大家如果玩過積木就知道，當(dāng)我們想要一個成型的具體的玩具時，我們可以用積木去拼出來。對于積木來說，它的生產(chǎn)過程就只有每一個碎片，當(dāng)它出廠之后，就不再有生產(chǎn)成本了。購買的人想要什么東西，就自己拼就好。

對于一個功能也是這樣，它是像積木一樣由已有的模塊拼起來的，還是說是在工廠里從0到1生產(chǎn)出來的，背后的成本是完全不一樣的。

因為一些歷史原因，很長時間以來，我們公司的各個業(yè)務(wù)都是并行發(fā)展的，即便是一些相同的功能，也因為各個業(yè)務(wù)訴求不一樣，最終是由各業(yè)務(wù)的產(chǎn)品經(jīng)理獨(dú)立設(shè)計。

評論功能就是這樣。

雖然我們的app主要是一個聽書產(chǎn)品，但我們還是有多個獨(dú)立的業(yè)務(wù)，并且在當(dāng)前階段都有獨(dú)立的產(chǎn)品模塊。評論功能就是這些業(yè)務(wù)都具備的一個功能，但長期以來都是獨(dú)立開發(fā)的。

于是這就導(dǎo)致幾個很嚴(yán)重的問題：

1. 開發(fā)資源的重復(fù)投入

一個業(yè)務(wù)的評論功能，并不能立刻在另一個業(yè)務(wù)上復(fù)用，每做一個新業(yè)務(wù)，都需要從頭開發(fā)。有產(chǎn)品經(jīng)理可能會問，這有什么難的，你照著其他業(yè)務(wù)的代碼再寫一份不就可以了么？

但你要知道，再簡單的評論功能也包括底層數(shù)據(jù)、客戶端樣式和管理后臺，即使有代碼可以抄，那開發(fā)和測試的邊際成本也是非常高的，更不用說各個業(yè)務(wù)是否能100%復(fù)制還不一定。

2. 用戶體驗不一致

因為是獨(dú)立開發(fā)，每個產(chǎn)品經(jīng)理都有自己的想法，且一條業(yè)務(wù)的產(chǎn)品經(jīng)理很多時候還是流動的，因此最終呈現(xiàn)出來的功能有很多細(xì)節(jié)處的細(xì)小差異。

但用戶訪問的是同一個app，有時候這些細(xì)節(jié)上的差異，會帶來體驗不一致性，而這個，有時候會導(dǎo)致非常糟糕的用戶體驗。

3. 信息差導(dǎo)致好的方案不能共享

實際情況下，很少有業(yè)務(wù)方會去研究其他業(yè)務(wù)方現(xiàn)在用的比較好的功能有哪些，甚至一個業(yè)務(wù)方覺得很稀松平常的功能，在另一個業(yè)務(wù)方眼里就是特別好的功能。

因此這樣普遍存在的信息差，會導(dǎo)致即使局部最優(yōu)無法實現(xiàn)整體最優(yōu)，功能本身積累的勢能無法最大程度的釋放出來。

那為什么要現(xiàn)在做呢？

「功能組件化」這件事是有時間窗口的，做早了或者做晚了，都不合適。

從樂高的比喻比喻中你可以想象，如果我要的是一個「超人」，你給我一堆碎片，讓我自己拼。那么這一定是浪費(fèi)效率的，可能不如給我一個「超人」來得快。

所以如果「功能組件化」這件事做早了，那么對業(yè)務(wù)來說就是「殺雞用了牛刀」，性價比劃不來。

但另一方面，如果這件事做晚了會如何？

從系統(tǒng)角度來說，就會嚴(yán)重增加后續(xù)組件化的成本。因為每一個業(yè)務(wù)都在自己的系統(tǒng)里將同一個功能做了不同方向的演化，所以后續(xù)要統(tǒng)一管理時，改造難度很大。

就好像城市改造，如果當(dāng)初都是各個小區(qū)各自規(guī)劃，后續(xù)要拆遷翻新，統(tǒng)一治理時，成本是非常大的。

因此，從時機(jī)上，組件化這件事是要做的，而且是值得現(xiàn)在就投入精力去做的。

二、核心問題是什么

認(rèn)識到這個問題，我就在想，最核心的問題到底是什么。

我們前面說到，任何一個業(yè)務(wù)的評論功能，基本都具備底層數(shù)據(jù)管理、客戶端樣式和內(nèi)容管理后臺，那最核心的問題到底是什么呢。

為此，我去體驗了我手機(jī)上所有app的評論功能，無論是寫，還是評論，還是刪除，我發(fā)現(xiàn)在五花八門的外表之下，只有一個點(diǎn)具備了驚人的一致性。

那就是「對象-評論-回復(fù)」這三個角色。

對象，是指對什么內(nèi)容所做的評論；

回復(fù)，是指對其他人貢獻(xiàn)的內(nèi)容所做的回復(fù)。

圍繞評論，我們一定能抽象出對象和回復(fù)這兩個概念，并且這三個概念在幾乎所有帶評論功能的產(chǎn)品里都能找到。

所以，我把最核心的問題定義為：找到我們自己app里的「對象-評論-回復(fù)」分別是什么。

在這個基礎(chǔ)上，我可以再去定義底層的數(shù)據(jù)結(jié)構(gòu)了，他們呈現(xiàn)出如下的樹狀結(jié)構(gòu)

這時候大家就會發(fā)現(xiàn)，如果我把對象去掉了，那所有的評論其實也就沒有了，同理，如果我把某個評論刪除了，它下面的回復(fù)也就沒有了。

但另一方面，我如果刪除了回復(fù)一，其實不影響回復(fù)二和其他的回復(fù)。

這個規(guī)律準(zhǔn)么？大家可以試試發(fā)一條朋友圈，然后評論，然后刪除；或者發(fā)一條微博，然后評論、回復(fù)、刪除，你就能發(fā)現(xiàn)規(guī)律了。

順便說一句，朋友圈的結(jié)構(gòu)比這個更簡單，對象下面的評論和回復(fù)都在一級，刪除評論，對應(yīng)的回復(fù)也還在?？吹竭@里的時候，我感嘆張小龍設(shè)計結(jié)構(gòu)時的簡約。

三、抽象組件

數(shù)據(jù)結(jié)構(gòu)定義好了，接下來就該去抽象組件了。

在這一步上，我特別感想研發(fā)同學(xué)對我的幫助。因為組件是一個技術(shù)語言，只是因為要做這件事，所以用在了產(chǎn)品上。

但從技術(shù)的角度來說，組件又包括功能組件和業(yè)務(wù)組件。他們兩者是完全不同的。

對于功能組件來說，它聚焦于跟功能綁定。

比如文本輸入是一個功能組件，無論是評論功能，還是UGC創(chuàng)作，甚至是社交軟件的聊天功能，凡是需要用戶自己產(chǎn)生內(nèi)容的地方，都會用到文本輸入。這就是一個典型的功能組件。

但業(yè)務(wù)組件是跟著業(yè)務(wù)走的，比如下面這張圖。

從抽象的角度來說，這張圖代表著展示一個用戶在什么時間寫了什么內(nèi)容，并且針對這個內(nèi)容還打標(biāo)了，還能進(jìn)行一系列操作。

但是，這個組件設(shè)計成這樣，它就基本只適合用在評論功能里，它可以用在不同業(yè)務(wù)的評論功能里，但你不會直接用它來展示一個社交軟件里用戶曾經(jīng)寫過的話，不會的。

所以，跟著特定業(yè)務(wù)場景走的組件，叫做業(yè)務(wù)組件。

搞清楚了這個概念，接下來我就可以得到有哪些組件了。

四、流程設(shè)計

到這里，我們只是完成了概念設(shè)計。

就像拼積木一樣，我們把積木的碎片設(shè)計好了，但是要怎么搭建，需要用一步步的操作把積木串聯(lián)起來。因此，在項目方案設(shè)計中，接下來最重要的是流程設(shè)計。

流程設(shè)計只解決一個問題：一個業(yè)務(wù)要用你的組件，它該怎么做。

再回到我們的比喻，我們當(dāng)然希望，如果我們需要一個「超人」，那你給我碎片就好，我手動搭建起來。

但事實上，如果要實現(xiàn)100%的無代碼接入，也就是只需要配置配置就好，完全沒有任何開發(fā)成本，那這樣的設(shè)計對于系統(tǒng)本身的開發(fā)復(fù)雜度要求非常高。

所以從成本和適用性的角度考慮，低代碼量級的接入是一個更合適的選擇。以前需要一周完成的事情，我現(xiàn)在可能只需要4個小時，那這就是成本的極大節(jié)約。

而對業(yè)務(wù)接入做管理設(shè)計，則需要做抽象。抽象什么呢？

管理要素。

我們的社會之所以可以正常運(yùn)轉(zhuǎn)，是因為在復(fù)雜的社會生態(tài)下，有不同的管理單元在運(yùn)行著。比如廳、局、科；比如校、班、組。

合理地劃分管理單元，并分而治之，便是對業(yè)務(wù)接入做管理設(shè)計的核心。

我們的評論功能可以拆分為三個管理層次：業(yè)務(wù)、應(yīng)用和內(nèi)容。

業(yè)務(wù)：所有需要用到評論功能的業(yè)務(wù)方，可以看作一個獨(dú)立的業(yè)務(wù)單元。它可能是跟著組織架構(gòu)走的，也可能是跟著產(chǎn)品模塊走的，甚至是一個活動虛擬組織。

只要你覺得，這個業(yè)務(wù)后續(xù)需要有一套獨(dú)立的管理權(quán)限和配套設(shè)施（也就是我們的配置能力），那它就可以獨(dú)立成為一個業(yè)務(wù)。

業(yè)務(wù)是提前定義好的，這就要求產(chǎn)品經(jīng)理在設(shè)計時做好溝通，知道現(xiàn)在以及將來，已經(jīng)有并可能有哪些業(yè)務(wù)會用到你的系統(tǒng)。

應(yīng)用：一個業(yè)務(wù)使用某個組件，我叫做一個應(yīng)用。

比如當(dāng)我接入一個新業(yè)務(wù)時，我就默認(rèn)給這個業(yè)務(wù)創(chuàng)建了6個組件應(yīng)用，每個組件應(yīng)用可以單獨(dú)配置，他們組合起來，就是這個業(yè)務(wù)最終在評論功能上所有的功能特性了。

內(nèi)容：對評論組件來說，最終的管理顆粒度是要細(xì)化到每條評論，包括：增、改（改不是改內(nèi)容，而是改屬性，比如打標(biāo)）、刪、查、審、導(dǎo)出等。

只有精細(xì)到每一條評論的管理粒度，才能最大程度上滿足業(yè)務(wù)的訴求。

做完業(yè)務(wù)管理，基本所有結(jié)構(gòu)層面的方案設(shè)計，就全部結(jié)束了。接下來就是更細(xì)化的展示和體驗，這個就靠跟UI的溝通和配合了。

五、總結(jié)

總體來說，雖然「評論組件化」對我來說是一個完全陌生的項目，而且面臨著時間緊、任務(wù)重的巨大挑戰(zhàn)，但我還是覺得有一些方法和新的可以分享給大家，無論是之后做組件化，還是突然面臨一個復(fù)雜的系統(tǒng)任務(wù)，我覺得都可以參考：

1）了解why和why now。復(fù)雜的事情，如果需要消耗你巨大的精力，一定要去理解，為什么要做，為什么要現(xiàn)在做，驅(qū)動力的問題，怎么想都不過分。

2）通過大量的觀察和體驗，找到復(fù)雜多元的外表下，那些核心的不變的要素。跟著那些要素再回過頭去看產(chǎn)品，如果你可以建立一個模型，當(dāng)你做任意輸入時，都能預(yù)料到輸出，代表你就徹底掌握了。比如刪除評論，回復(fù)還在不在。在沒有研究這個問題時，我很少會注意到這個規(guī)律。

3）找到最原始的概念。我們可能會用到很多抽象的概念，以及基于這些概念衍生出來的二級概念，如果我們一開始理解的不是最原始的意思，很可能就容易走歪。其實我一開始并沒有很好的理解功能組件和業(yè)務(wù)組件，直到技術(shù)leader跟我講了一晚上，我才逐漸理解。特別感謝他。

4）確定管理顆粒度。系統(tǒng)一定是有管控單位的，比如課程管控的是節(jié)目，講書管控的是書籍，公司管控的是員工，學(xué)校管控的是學(xué)生。找到你的系統(tǒng)的管理粒度，會讓你在系統(tǒng)設(shè)計上，跟核心要素產(chǎn)生更好的連接。

#專欄作家#

大力哥呀，微信公眾號：大力哥，人人都是產(chǎn)品經(jīng)理專欄作家。一個90后產(chǎn)品經(jīng)理，已經(jīng)寫了6年的公眾號，通過輸出獲得了許多意料外的成長。

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

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