作者：玉缜
作為一名前端同學，由于TL是服務端同學，團隊組成包含多種技術棧，過去一年對于業務思考有了較大提升，而在前端技術的探索上也會與其他技術域有更多交叉，是以我的 2020 為非典型前端的一年。這篇總結分為兩部分：
- 業務：我是如何做閑魚内容創作者這塊業務的
- 技術：我在前端技術上做了哪些建設與沉澱
業務
去年年中閑魚開始重新投入社群内容這塊業務，我擔任社群創作者線的技術PM，帶領小組的技術同學與業務同學一起為業務目标努力。我在整個過程中做的事情可以概括為3個詞：建團隊、定目标、做判斷。
建團隊
在這裡，建團隊的意思是将相關的技術同學與業務同學組成一個“團隊”，統一大家之間的認識，互相之間建立信任，這是一件極其困難的事情。對于研發同學，你要站在他的角度思考在過程中能夠給他提供什麼樣的成長，成長可能是業務了解，可能是技術沉澱等等。對于業務同學，在吸收了他們的輸入之後，你要站在業務的角度去思考目前問題到底是啥，可以通過什麼手段去解決，手段可以是技術的也可以是非技術的。建立信任是有路徑可循的，但是更多地是在平時的日常工作中逐漸去建立的。
定目标
目标指引我們的工作不偏離想要拿到的業務結果以及創造的使用者價值。在業務發展過程中會存在各種階段性目标，但是階段性目标都是為了最終目标服務的，在這裡需要和業務同學反複對焦。但是業務也經常會有一些變化，甚至産品和營運的目标也不會完全一緻，是以我認為更加重要還是自己深入思考目标是什麼。目标是自上而下的，是以可以先思考怎麼樣做閑魚内容社群這個業務，這裡推薦用亞馬遜的增長飛輪來思考。
從增長飛輪來看創作(者)->内容->消費(者)->創作(者)是整個閉環，而在目前0-1階段，優質内容數量才是驅動增長的關鍵。但是為什麼我們會講要做創作者，而不是說做優質内容數量呢。因為業務是通過營運人（創作者）進行内容創作來提升優質内容數量，并且創作者數量多更能反應業務的健康度。是以對于創作者這條線的核心目标就是創作者規模，本質來講就是創作者的增長問題。
一開始我按照App DAU的邏輯進行拆分，日創作者數 = 今日新增 + 昨日留存 + 曆史召回。跑了一段時間之後發現這樣拆分無法對應到業務上的Action。思考下來有幾個因素：
- 内容釋出是一個使用者參與成本很高的行為。不像App的通路行為，參與成本非常低，每天都可以産生這樣的行為。此外内容釋出相對來講是非常低頻的行為，在一周内使用者釋出的天數有限，平台提供的獨特價值在于使用者有内容釋出訴求的時候選擇來目前平台釋出。
- 在目前業務0-1階段，更偏向追求每日新增内容釋出總量（即讓更多人來釋出），而精細化營運人群的留存情況關注相對較少。
是以後來我建立了每日（周）新增（優質）内容量（人）的看闆，并且建立每個釋出管道的效率。這樣拆分資料看到的問題/現狀是可以和業務政策對應的。例如日創作内容數增加了，但是優質内容數變化不大，說明通過一些政策促進了使用者來釋出内容，但是優質率卻是降低的，可能是引入的使用者不具備創作能力或者政策沒有很好地引導使用者釋出優質内容。
業務資料是技術同學了解業務最簡單的方式，也是能和業務同學建立連接配接一個便捷的通道。業務同學看着你建的資料報表，可能過幾天就給你提一個需求，幫忙增加某一個名額，這樣你就能更加了解業務的打法。這裡推薦各位做業務的同學，有條件一定要親自實作下關鍵業務名額和其拆分名額的産出邏輯（SQL），這樣能讓你更加了解業務目标的構成與背後邏輯。
做判斷
做判斷是指基于業務了解以及目标拆解對業務需求進行判斷，集中兵力投入ROI高的事情上。回到内容創作者這個業務，在0-1的這個階段我們應該重點做啥呢。可以先從創作者的轉化路徑來看，使用者首次創作内容變成創作者，具備釋出優質内容并且持續釋出變成核心創作者。
在業務上打法是降低創作門檻，讓更多使用者能夠首次釋出内容。增加使用者激勵，讓更多使用者有動力持續在閑魚上釋出内容。此外創作者基礎産品基本為零，急需建設。是以主要圍繞着這三個方面建設：
基礎産品建設：
- 前台産品：創作者中心（使用者教育/活動引導）+我的文章（内容管理/資料看闆）。
- 管理背景：提供創作者入駐、管理、管控等能力。
降低門檻：
- 閑魚寶貝轉内容：閑魚有大量隻秀不賣的寶貝，不具備交易屬性，本質上就是内容。我們建構了一個使用者快速将内容型商品轉化成内容的鍊路，減少使用者的創作成本，整個思路和閑魚一開始做一鍵轉賣（将淘寶已買到商品轉成閑魚商品）非常類似。
使用者激勵：
- 創作者成長體系：由于産品還在初期，内在激勵（内容供需）尚還不能有效激勵使用者創作。是以通過創作者成長體系（積分/等級/權益）建構外在激勵，拉動使用者創作内容，增加大盤供給。
擔任業務線技術PM讓我有一種CTO的視角去看待内容創作者這個業務，在以往的工作中我并不會以這樣全面的方式去思考業務，讓我有很大的成長。回到前端在業務中的作用，目前前端在創作者業務推進過程中更多是業務支撐，并沒有産出和業務強相關的技術沉澱。這是前端同學的一個特點，善于解通用性問題，從定義問題到解決問題都具有普适性。這一塊希望在新的一年有所突破，看得到業務中的問題，并且能通過技術手段有效解決。
技術
過去一年在前端相關技術上主要做了以下4個方向的事情，如前面所說，和其他技術域有一些交叉，但是本質上都是通過技術手段解決業務問題。将其他技術域的思想引入到前端中，可以拓寬思維，用不同的思路來解決問題。
前端CEP
前端實作了一套對使用者複雜行為比對的規則引擎，主要應用于使用者增長場景，在使用者産生特定行為之後對使用者進行觸達幹預。将業務流程拆解為三部分，分别是使用者實時行為采集、對實時行為按照規則複雜計算、以前端UI元件進行使用者觸達，對應三個核心子產品：事件采集、複雜計算和使用者觸達。針對上述設計目标，為了實作觸達實時，将對行為的複雜計算放到前端去執行；為了實作政策動态，設計了一個服務端營運平台管理所有政策，采集行為資訊、複雜計算規則、觸達元件資訊都從服務端擷取；為了實作多容器，将實時行為采集和UI元件觸達進行标準設計，分不同容器環境實作。此外由于政策會存在跨頁面的場景，底層會有資料同步子產品同步行為資料和計算狀态。整體架構如下圖所示。
Flutter能力拓展
2020年閑魚社群前端開始嘗試用Flutter進行業務開發，由于Flutter UI程式設計模型和現代前端比較接近，前端同學要上手Flutter進行UI程式設計成本沒有那麼高，甚至我認為前端同學對于UI的還原以及敏感度整體來講是要比用戶端同學更強的。除了Flutter UI程式設計之外，了解用戶端研發模式有一些學習成本，Flutter研發體系和前端研發體系有很大差别，屬于完全割裂。而從研發效率上來講，前端研發相比還是要快非常多的。目前來看，我們是多了一個Flutter這樣的錘子，可以解決一些相關的業務需求，但是未來如何将Flutter和目前前端研發體系結合需要更多思考。
中背景基礎建設
去年閑魚開始做重新内容，需要配合建設大量的營運背景（内容稽核、内容管理、創作者管理、流量政策等），而閑魚以往因為主要是C2C交易，中背景建設這一塊是比較缺失的，是以發起了社群中背景前端基礎建設這個項目。除了基礎工程化建設以及一些集團能力引入，我們嘗試建構了一套資料模型+标準化協定+一體化搭建的快速生産通用型頁面的方案，大概流程：指定服務端資料模型 -> 指定頁面模版 -> 搭建修改UI -> 生成頁面。
端容器建設
閑魚經過多年發展，技術體系百花齊放，前端同學開發使用過Webview、Weex、小程式等多種容器。一方面前端同學不清楚各個容器能力與邊界，容器能力靠老司機相傳，在面對複雜業務需求時無法做出準确判斷；另一方面多個端容器架構，用戶端同學研發與維護成本較高，并且存在多個團隊維護與更改的情況，容器能力對于用戶端同學來說也是黑盒。是以在FY21S2開始推進閑魚端容器能力梳理與體系建設。過去一年在容器選型上達成了共識，後續前端動态化場景的業務開發會逐漸收斂到Webview，以及對目前閑魚Webview能力以及現狀做了一輪梳理。FY22會更加聚焦提升Webview極緻性能與體驗，希望能提升整體閑魚App的使用者體驗。
未來
過去一年個人對于業務思考提升了很多，也取得了不錯的業務結果，但是業務到技術的推導還不夠。新的一年希望能夠與團隊一起躬身入局，提升業務Sense，從業務中發現問題，用技術手段來解決。