起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識「評論功能組件化」實踐分享
面對評論功能組件化，一位中臺產品經理會怎么做？本文作者作為業務向轉型中臺產品經理的親歷者，將自己的實操經驗與大家一同分享。其中涵蓋：確定核心問題，如何抽象產品組件，串聯概念設計轉變為流程設計等關鍵步驟，是一篇不可多得的組件化方法論。推薦小伙伴們交流學習～
很長時間以來，我的工作都是一名偏向業務的產品經理。我的職責是幫助對接的業務實現更好的業務增長，這里的增長不僅包括收入的增長，也包括成本的降低。
但我很少有機會去做一名中臺產品經理，以更抽象的視角去規劃各個業務都會用到的核心功能。
雖然我一直都明白中臺產品經理的職責是什么，但沒有什么機會去實踐。而我相信，一件事情做過還是沒有做過，認識是完全不一樣的。
所以去年年底的時候，老板說讓我去負責「評論組件化」這個項目，我意識到這是一次實現自我突破的好機會。因為這對我來說是一次巨大的挑戰，我之前從未負責過類似的產品。
現在，三周過去了，我也從最初毫無邏輯，到完成了整個方案的評審，一路走來感慨頗多。即驕傲于自己在三周內完成了方案的輸出和評審，也謙卑于對于未知的世界，站在里面和站在外面，看到的東西有多么的不一樣。
于是決定將這三周的實操經驗分享出來，供更多從業務走向中臺的產品經理參考。
一、確認動機
對我來說，當我知道一件事情將要花去我很多的精力時，我一定要搞清楚兩件事：
- 這件事為什么要做
- 這件事為什么現在就要做
在解釋為什么要做「評論組件化」這件事之前，我首先想跟大家解釋一下這個項目是什么。
大家如果玩過積木就知道，當我們想要一個成型的具體的玩具時，我們可以用積木去拼出來。對于積木來說，它的生產過程就只有每一個碎片，當它出廠之后，就不再有生產成本了。購買的人想要什么東西，就自己拼就好。
對于一個功能也是這樣，它是像積木一樣由已有的模塊拼起來的，還是說是在工廠里從0到1生產出來的，背后的成本是完全不一樣的。
因為一些歷史原因，很長時間以來，我們公司的各個業務都是并行發展的，即便是一些相同的功能，也因為各個業務訴求不一樣，最終是由各業務的產品經理獨立設計。
評論功能就是這樣。
雖然我們的app主要是一個聽書產品，但我們還是有多個獨立的業務，并且在當前階段都有獨立的產品模塊。評論功能就是這些業務都具備的一個功能，但長期以來都是獨立開發的。
于是這就導致幾個很嚴重的問題：
1. 開發資源的重復投入
一個業務的評論功能，并不能立刻在另一個業務上復用，每做一個新業務，都需要從頭開發。有產品經理可能會問，這有什么難的，你照著其他業務的代碼再寫一份不就可以了么？
但你要知道，再簡單的評論功能也包括底層數據、客戶端樣式和管理后臺，即使有代碼可以抄，那開發和測試的邊際成本也是非常高的，更不用說各個業務是否能100%復制還不一定。
2. 用戶體驗不一致
因為是獨立開發，每個產品經理都有自己的想法，且一條業務的產品經理很多時候還是流動的，因此最終呈現出來的功能有很多細節處的細小差異。
但用戶訪問的是同一個app，有時候這些細節上的差異，會帶來體驗不一致性，而這個，有時候會導致非常糟糕的用戶體驗。
3. 信息差導致好的方案不能共享
實際情況下，很少有業務方會去研究其他業務方現在用的比較好的功能有哪些，甚至一個業務方覺得很稀松平常的功能，在另一個業務方眼里就是特別好的功能。
因此這樣普遍存在的信息差，會導致即使局部最優無法實現整體最優，功能本身積累的勢能無法最大程度的釋放出來。
那為什么要現在做呢？
「功能組件化」這件事是有時間窗口的，做早了或者做晚了，都不合適。
從樂高的比喻比喻中你可以想象，如果我要的是一個「超人」，你給我一堆碎片，讓我自己拼。那么這一定是浪費效率的，可能不如給我一個「超人」來得快。
所以如果「功能組件化」這件事做早了，那么對業務來說就是「殺雞用了牛刀」，性價比劃不來。
但另一方面，如果這件事做晚了會如何？
從系統角度來說，就會嚴重增加后續組件化的成本。因為每一個業務都在自己的系統里將同一個功能做了不同方向的演化，所以后續要統一管理時，改造難度很大。
就好像城市改造，如果當初都是各個小區各自規劃，后續要拆遷翻新，統一治理時，成本是非常大的。
因此，從時機上，組件化這件事是要做的，而且是值得現在就投入精力去做的。
二、核心問題是什么
認識到這個問題，我就在想，最核心的問題到底是什么。
我們前面說到，任何一個業務的評論功能，基本都具備底層數據管理、客戶端樣式和內容管理后臺，那最核心的問題到底是什么呢。
為此，我去體驗了我手機上所有app的評論功能，無論是寫，還是評論，還是刪除，我發現在五花八門的外表之下，只有一個點具備了驚人的一致性。
那就是「對象-評論-回復」這三個角色。
對象，是指對什么內容所做的評論；
回復，是指對其他人貢獻的內容所做的回復。
圍繞評論，我們一定能抽象出對象和回復這兩個概念，并且這三個概念在幾乎所有帶評論功能的產品里都能找到。
所以，我把最核心的問題定義為：找到我們自己app里的「對象-評論-回復」分別是什么。
在這個基礎上，我可以再去定義底層的數據結構了，他們呈現出如下的樹狀結構
這時候大家就會發現，如果我把對象去掉了，那所有的評論其實也就沒有了，同理，如果我把某個評論刪除了，它下面的回復也就沒有了。
但另一方面，我如果刪除了回復一，其實不影響回復二和其他的回復。
這個規律準么？大家可以試試發一條朋友圈，然后評論，然后刪除；或者發一條微博，然后評論、回復、刪除，你就能發現規律了。
順便說一句，朋友圈的結構比這個更簡單，對象下面的評論和回復都在一級，刪除評論，對應的回復也還在?？吹竭@里的時候，我感嘆張小龍設計結構時的簡約。
三、抽象組件
數據結構定義好了，接下來就該去抽象組件了。
在這一步上，我特別感想研發同學對我的幫助。因為組件是一個技術語言，只是因為要做這件事，所以用在了產品上。
但從技術的角度來說，組件又包括功能組件和業務組件。他們兩者是完全不同的。
對于功能組件來說，它聚焦于跟功能綁定。
比如文本輸入是一個功能組件，無論是評論功能，還是UGC創作，甚至是社交軟件的聊天功能，凡是需要用戶自己產生內容的地方，都會用到文本輸入。這就是一個典型的功能組件。
但業務組件是跟著業務走的，比如下面這張圖。
從抽象的角度來說，這張圖代表著展示一個用戶在什么時間寫了什么內容，并且針對這個內容還打標了，還能進行一系列操作。
但是，這個組件設計成這樣，它就基本只適合用在評論功能里，它可以用在不同業務的評論功能里，但你不會直接用它來展示一個社交軟件里用戶曾經寫過的話，不會的。
所以，跟著特定業務場景走的組件，叫做業務組件。
搞清楚了這個概念，接下來我就可以得到有哪些組件了。
四、流程設計
到這里，我們只是完成了概念設計。
就像拼積木一樣，我們把積木的碎片設計好了，但是要怎么搭建，需要用一步步的操作把積木串聯起來。因此，在項目方案設計中，接下來最重要的是流程設計。
流程設計只解決一個問題：一個業務要用你的組件，它該怎么做。
再回到我們的比喻，我們當然希望，如果我們需要一個「超人」，那你給我碎片就好，我手動搭建起來。
但事實上，如果要實現100%的無代碼接入，也就是只需要配置配置就好，完全沒有任何開發成本，那這樣的設計對于系統本身的開發復雜度要求非常高。
所以從成本和適用性的角度考慮，低代碼量級的接入是一個更合適的選擇。以前需要一周完成的事情，我現在可能只需要4個小時，那這就是成本的極大節約。
而對業務接入做管理設計，則需要做抽象。抽象什么呢？
管理要素。
我們的社會之所以可以正常運轉，是因為在復雜的社會生態下，有不同的管理單元在運行著。比如廳、局、科；比如校、班、組。
合理地劃分管理單元，并分而治之，便是對業務接入做管理設計的核心。
我們的評論功能可以拆分為三個管理層次：業務、應用和內容。
業務：所有需要用到評論功能的業務方，可以看作一個獨立的業務單元。它可能是跟著組織架構走的，也可能是跟著產品模塊走的，甚至是一個活動虛擬組織。
只要你覺得，這個業務后續需要有一套獨立的管理權限和配套設施（也就是我們的配置能力），那它就可以獨立成為一個業務。
業務是提前定義好的，這就要求產品經理在設計時做好溝通，知道現在以及將來，已經有并可能有哪些業務會用到你的系統。
應用：一個業務使用某個組件，我叫做一個應用。
比如當我接入一個新業務時，我就默認給這個業務創建了6個組件應用，每個組件應用可以單獨配置，他們組合起來，就是這個業務最終在評論功能上所有的功能特性了。
內容：對評論組件來說，最終的管理顆粒度是要細化到每條評論，包括：增、改（改不是改內容，而是改屬性，比如打標）、刪、查、審、導出等。
只有精細到每一條評論的管理粒度，才能最大程度上滿足業務的訴求。
做完業務管理，基本所有結構層面的方案設計，就全部結束了。接下來就是更細化的展示和體驗，這個就靠跟UI的溝通和配合了。
五、總結
總體來說，雖然「評論組件化」對我來說是一個完全陌生的項目，而且面臨著時間緊、任務重的巨大挑戰，但我還是覺得有一些方法和新的可以分享給大家，無論是之后做組件化，還是突然面臨一個復雜的系統任務，我覺得都可以參考：
1）了解why和why now。復雜的事情，如果需要消耗你巨大的精力，一定要去理解，為什么要做，為什么要現在做，驅動力的問題，怎么想都不過分。
2）通過大量的觀察和體驗，找到復雜多元的外表下，那些核心的不變的要素。跟著那些要素再回過頭去看產品，如果你可以建立一個模型，當你做任意輸入時，都能預料到輸出，代表你就徹底掌握了。比如刪除評論，回復還在不在。在沒有研究這個問題時，我很少會注意到這個規律。
3）找到最原始的概念。我們可能會用到很多抽象的概念，以及基于這些概念衍生出來的二級概念，如果我們一開始理解的不是最原始的意思，很可能就容易走歪。其實我一開始并沒有很好的理解功能組件和業務組件，直到技術leader跟我講了一晚上，我才逐漸理解。特別感謝他。
4）確定管理顆粒度。系統一定是有管控單位的，比如課程管控的是節目，講書管控的是書籍，公司管控的是員工，學校管控的是學生。找到你的系統的管理粒度，會讓你在系統設計上，跟核心要素產生更好的連接。
#專欄作家#
大力哥呀，微信公眾號：大力哥，人人都是產品經理專欄作家。一個90后產品經理，已經寫了6年的公眾號，通過輸出獲得了許多意料外的成長。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
學習了，作者思路太清晰了
謝謝，文章組織清晰，很有啟發，有些疑問想交流下：
? 業務組件的劃分顆粒度是什么？評論列表、詳情、分享，寫成各個業務組件是否有必要——開發可以按照應用的業務差異需求寫成可擴展，例如帶不帶評論分享，點贊等功能。
? 動機第3點沒有理解（局部優勢最大化），是否是具有業務通用性才有價值？
? 業務組件不宜早，不宜晚-什么時候做比較合理呢，能細講下么。
看著dp的觸達體系，突然發現熟悉的名字，哇哈哈哈～
學習了。
講的很棒