作者：玉缜

作为一名前端同学，由于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，从业务中发现问题，用技术手段来解决。