[[397155]]

去年年中通過了晉升之后，工作內容上發生了一些變化，同時由于TL是服務端同學，團隊組成包含多種技術棧，FY21對于業務思考有了較大提升，而在前端技術的探索上也會與其他技術域有更多交叉，所以我的FY21為非典型前端的一年。這篇總結分為兩部分：

• 業務：FY21我是如何做閑魚內容創作者這塊業務的
• 技術：FY21我在前端技術上做了哪些建設與沉淀

一 業務

FY21年中閑魚開始重新投入社區內容這塊業務，我擔任社區創作者線的技術PM，帶領小組的技術同學與業務同學一起為業務目標努力。我在整個過程中做的事情可以概括為3個詞：建團隊、定目標、做判斷。

建團隊

在這里，建團隊的意思是將相關的技術同學與業務同學組成一個“團隊”，統一大家之間的認識，相互之間建立信任，這是一件極其困難的事情。對于研發同學，你要站在他的角度思考在過程中能夠給他提供什么樣的成長，成長可能是業務理解，可能是技術沉淀等等。對于業務同學，在吸收了他們的輸入之后，你要站在業務的角度去思考當前問題到底是啥，可以通過什么手段去解決，手段可以是技術的也可以是非技術的。建立信任是有路徑可循的，但是更多地是在平時的日常工作中逐步去建立的。

定目標

目標指引我們的工作不偏離想要拿到的業務結果以及創造的用戶價值。在業務發展過程中會存在各種階段性目標，但是階段性目標都是為了最終目標服務的，在這里需要和業務同學反復對焦。但是業務也經常會有一些變化，甚至產品和運營的目標也不會完全一致，所以我認為更加重要還是自己深入思考目標是什么。目標是自上而下的，因此可以先思考怎么樣做閑魚內容社區這個業務，這里推薦用亞馬遜的增長飛輪來思考。

從增長飛輪來看創作(者)->內容->消費(者)->創作(者)是整個閉環，而在當前0-1階段，優質內容數量才是驅動增長的關鍵。但是為什么我們會講要做創作者，而不是說做優質內容數量呢。因為業務是通過運營人(創作者)進行內容創作來提升優質內容數量，并且創作者數量多更能反應業務的健康度。因此對于創作者這條線的核心目標就是創作者規模，本質來講就是創作者的增長問題。

一開始我按照App DAU的邏輯進行拆分，日創作者數 = 今日新增 + 昨日留存 + 歷史召回。跑了一段時間之后發現這樣拆分無法對應到業務上的Action。思考下來有幾個因素：

• 內容發布是一個用戶參與成本很高的行為。不像App的訪問行為，參與成本非常低，每天都可以產生這樣的行為。此外內容發布相對來講是非常低頻的行為，在一周內用戶發布的天數有限，平臺提供的獨特價值在于用戶有內容發布訴求的時候選擇來當前平臺發布。
• 在當前業務0-1階段，更偏向追求每日新增內容發布總量(即讓更多人來發布)，而精細化運營人群的留存情況關注相對較少。

因此后來我建立了每日(周)新增(優質)內容量(人)的看板，并且建立每個發布渠道的效率。這樣拆分數據看到的問題/現狀是可以和業務策略對應的。例如日創作內容數增加了，但是優質內容數變化不大，說明通過一些策略促進了用戶來發布內容，但是優質率卻是降低的，可能是引入的用戶不具備創作能力或者策略沒有很好地引導用戶發布優質內容。

業務數據是技術同學了解業務最簡單的方式，也是能和業務同學建立連接一個便捷的通道。業務同學看著你建的數據報表，可能過幾天就給你提一個需求，幫忙增加某一個指標，這樣你就能更加了解業務的打法。這里推薦各位做業務的同學，有條件一定要親自實現下關鍵業務指標和其拆分指標的產出邏輯(SQL)，這樣能讓你更加了解業務目標的構成與背后邏輯。

做判斷

做判斷是指基于業務理解以及目標拆解對業務需求進行判斷，集中兵力投入ROI高的事情上。回到內容創作者這個業務，在0-1的這個階段我們應該重點做啥呢。可以先從創作者的轉化路徑來看，用戶首次創作內容變成創作者，具備發布優質內容并且持續發布變成核心創作者。

在業務上打法是降低創作門檻，讓更多用戶能夠首次發布內容。增加用戶激勵，讓更多用戶有動力持續在閑魚上發布內容。此外創作者基礎產品基本為零，急需建設。因此在FY21主要圍繞著這三個方面建設：

基礎產品建設：

• 前臺產品：創作者中心(用戶教育/活動引導)+我的帖子(內容管理/數據看板)。
• 管理后臺：提供創作者入駐、管理、管控等能力。

降低門檻：

• 閑魚寶貝轉內容：閑魚有大量只秀不賣的寶貝，不具備交易屬性，本質上就是內容。我們構建了一個用戶快速將內容型商品轉化成內容的鏈路，減少用戶的創作成本，整個思路和閑魚一開始做一鍵轉賣(將淘寶已買到商品轉成閑魚商品)非常類似。

用戶激勵：

• 創作者成長體系：由于產品還在初期，內在激勵(內容供需)尚還不能有效激勵用戶創作。因此通過創作者成長體系(積分/等級/權益)構建外在激勵，拉動用戶創作內容，增加大盤供給。

擔任業務線技術PM讓我有一種CTO的視角去看待內容創作者這個業務，在以往的工作中我并不會以這樣全面的方式去思考業務，讓我有很大的成長。回到前端在業務中的作用，當前前端在創作者業務推進過程中更多是業務支撐，并沒有產出和業務強相關的技術沉淀。這是前端同學的一個特點，善于解通用性問題，從定義問題到解決問題都具有普適性。這一塊希望在FY22有所突破，看得到業務中的問題，并且能通過技術手段有效解決。

二 技術

FY21在前端相關技術上主要做了以下4個方向的事情，如前面所說，和其他技術域有一些交叉，但是本質上都是通過技術手段解決業務問題。將其他技術域的思想引入到前端中，可以拓寬思維，用不同的思路來解決問題。

前端CEP

FY21在前端實現了一套對用戶復雜行為匹配的規則引擎，主要應用于用戶增長場景，在用戶產生特定行為之后對用戶進行觸達干預。將業務流程拆解為三部分，分別是用戶實時行為采集、對實時行為按照規則復雜計算、以前端UI組件進行用戶觸達，對應三個核心模塊：事件采集、復雜計算和用戶觸達。針對上述設計目標，為了實現觸達實時，將對行為的復雜計算放到前端去執行;為了實現策略動態，設計了一個服務端運營平臺管理所有策略，采集行為信息、復雜計算規則、觸達組件信息都從服務端獲取;為了實現多容器，將實時行為采集和UI組件觸達進行標準設計，分不同容器環境實現。此外由于策略會存在跨頁面的場景，底層會有數據同步模塊同步行為數據和計算狀態。整體架構如下圖所示。

Flutter能力拓展

FY21閑魚社區前端開始嘗試用Flutter進行業務開發，由于Flutter UI編程模型和現代前端比較接近，前端同學要上手Flutter進行UI編程成本沒有那么高，甚至我認為前端同學對于UI的還原以及敏感度整體來講是要比客戶端同學更強的。除了Flutter UI編程之外，了解客戶端研發模式有一些學習成本，Flutter研發體系和前端研發體系有很大差別，屬于完全割裂。而從研發效率上來講，前端研發相比還是要快非常多的。目前來看，我們是多了一個Flutter這樣的錘子，可以解決一些相關的業務需求，但是未來如何將Flutter和當前前端研發體系結合需要更多思考。

中后臺基礎建設

FY21閑魚開始做重新內容，需要配合建設大量的運營后臺(內容審核、內容管理、創作者管理、流量策略等)，而閑魚以往因為主要是C2C交易，中后臺建設這一塊是比較缺失的，因此發起了社區中后臺前端基礎建設這個項目。除了基礎工程化建設以及一些集團能力引入，FY21我們嘗試構建了一套數據模型+標準化協議+一體化搭建的快速生產通用型頁面的方案，大概流程：指定服務端數據模型 -> 指定頁面模版 -> 搭建修改UI -> 生成頁面。

端容器建設

閑魚經過多年發展，技術體系百花齊放，前端同學開發使用過Webview、Weex、小程序等多種容器。一方面前端同學不清楚各個容器能力與邊界，容器能力靠老司機相傳，在面對復雜業務需求時無法做出準確判斷;另一方面多個端容器架構，客戶端同學研發與維護成本較高，并且存在多個團隊維護與更改的情況，容器能力對于客戶端同學來說也是黑盒。因此在FY21S2開始推進閑魚端容器能力梳理與體系建設。FY21在容器選型上達成了共識，后續前端動態化場景的業務開發會逐漸收斂到Webview，以及對目前閑魚Webview能力以及現狀做了一輪梳理。FY22會更加聚焦提升Webview極致性能與體驗，希望能提升整體閑魚App的用戶體驗。

三 未來

FY21個人對于業務思考提升了很多，也取得了不錯的業務結果，但是業務到技術的推導還不夠。FY22希望能夠與團隊一起躬身入局，提升業務Sense，從業務中發現問題，用技術手段來解決。