Escanear código QR Carregar código QR
Loja de dominios
Selecione o tipo de plataforma anti-bloqueio para evitar interceptação de links
Selecionar tipos de plataforma permitidos para acesso

复盘分享:后台产品工作的难点与收获

几年前以实习生身份加入这家公司时,我没想到第一个大项目会撞上疫情。春节后返京时间一推再推,远程办公就这么开始了。不用通勤确实省了不少时间,效率却没怎么提高——家里没有工位,开会要抢网络,沟通全靠打字,很多事情推进起来都比想象中慢半拍。



那段时间我主要负责三件事:产品主页的后台模块设计、内容配置,以及老后台的功能优化。现在回头看,这项工作做得并不算好,但恰恰是这些磕磕绊绊,让我对后台产品有了更深的理解,也第一次真正接触到推荐算法在业务中的落地方式。复盘这件事,是为了不白摔跟头,下面认真聊聊这段经历。

当时APP正经历一次大规模结构调整,"图书馆"和"发现"两个页面被赋予了不同定位。产品层面希望借此改善用户体验,把过去靠人工配置的内容运营方式,逐步转向算法推荐和规则匹配,为后续用户转化打基础。与此同时,老后台的功能需要迁移到新后台,实现统一管理。

目标很清晰:完成图书馆主页的后台模块配置、内容管理设计,以及老后台的功能优化。

具体执行上,我先把老后台的逻辑摸了一遍,又梳理了需要优化的需求。不同团队对文档的要求不一样,这也花了我一些时间去适应。新主页的需求和功能设计是重点,其中单本上传的交互设计、后台配置模块的构思都从零开始。算法和规则的原理是现学的,边读文章边跟团队讨论,慢慢才摸到门道。内容管理模块设计完后,就是跟进开发、沟通修改、准备测试,直到上线后持续观察数据。

结果怎么说呢——版本最终上线了,但比预期晚了不少。需求变来变去是主要原因,但我自己也犯了不少低级错误:需求稿写得不够清楚,跟进功能不够及时,该决策的时候犹豫了一下。这个版本基本实现了功能设计,一些小的优化点只能留到第二阶段,届时会重点改善用户体验和转化效率。

规则和算法模块

这是我第一次接触推荐算法和规则定义的功能设计,完全是个盲区。为了搞清楚客户端和后台该怎么配合,我查了不少资料,也拉着团队反复讨论,才算慢慢上了轨道。

推荐和规则是两个东西。推荐靠数据和算法模型,根据用户行为自动推送内容,人工干预不了;规则则是人为划定范围,按条件展示内容。一个推荐后台通常包含三块:

客户端效果设置,配置推荐模块在客户端的展位属性,比如权重、状态。UI效果要根据内容和场景来定,这块交给专业设计师。

算法管理,包括客户端结果预览和算法策略调整,有的还支持A/B测试。结果预览能在后台看到线上推荐效果,可以查某个用户的推荐结果,初步判断算法准不准;策略调整则是通过修改算法指标来优化推荐目标和准确性。

数据分析,关键是模块指标和性能表现。北极星指标最重要,比如会员续费率、日活、GMV,用来衡量推荐是否有效。性能则涉及更新频率、时间段、响应时间,这些直接影响开发成本,需要和技术详细对。

老版本兼容

迁移老后台时遇到几个很实际的问题。新设计的字段会不会影响旧版本功能?每个端都要排查,有影响的得讨论方案。去掉的字段是不是所有端都没用了?同样要各端确认。新字段的数据怎么导入?技术能直接导的还好,否则就得人工录入,这种纯体力活要提前估时间,不能耽误上线。新旧版本怎么并行?一般得同时运行一段时间,等老用户更新得差不多了再停掉旧版,通常90%更新率是个坎。



写交互文档:以开发和测试为用户



这个项目复杂在菜单层级多、页面多,每个页面的功能和逻辑都要写清楚。老后台迁移时更麻烦,因为时间太久,很多开发同事对原始逻辑也不太熟悉,不是简单复制粘贴就能解决的。

几点体会:用结构化语言讲功能,别啰嗦;更新原型时标注时间、页面和功能,新功能用不同线框区分;菜单结构要清晰,入口在哪、有没有独立菜单都要说明;按钮尽量做出交互效果,开发和测试理解起来更直观。

后台功能设计的核心

后台和客户端产品差别很大。后台面向运营和内部团队,目的是提效、数据分析和内容管理;客户端面向用户,要的是体验、交互和视觉。抖音单列沉浸、快手双列选择的例子就很典型——交互设计直接影响产品走向。

后台功能设计我总结了几条。核心就是增删查改,但要把状态、操作按钮、提示信息、查询布局、排序规则、二次确认这些细节抠到位。能选的不传,能模糊搜索的别让人精确输入,界面干净比花哨重要。必须解决业务问题,方案落不了地,原型再好看也没用。流程要清晰,耦合要少,逻辑要自洽。多问自己:这个功能真解决了需求吗?有没有更好的办法?异常场景要考虑全,不然就是埋雷。新字段提前想数据配置,需要多久、怎么导入,别临上线才发现来不及。需求访谈的结论要客观看待,有些需求不必做,得看到本质再综合判断。交付开发前,自己从头到尾跑一遍,把自己当用户。

项目跟进:快决策



和技术沟通先听懂对方的意思,再判断要不要优化方案。讨论功能时尽快定结论、定负责人。需求变更要同步所有人。后期哪怕在测试阶段,也要能快速分析问题、给出方案、跟进变化。

这次很幸运的是跟了一个很强的团队,leader让我看到了优秀产品经理的样子——他们花更多时间在定义问题上,而不是急着解决。定义问题、找到根源、看透本质,这往往比画原型耗时间,也更重要。

接下来我会继续强化几件事:工作中多思考本质、上层建筑和重点,用《幕后产品》里的框架锻炼自己;坚持产品拆解和记录,继续写文章、读书、参与讨论,接触不同观点。目前在读《失控》《博弈与社会》《穷查理宝典》《决胜B端》,也在super的产品拆解组里学习。

作者:苏Eddie,微信公众号:苏Eddies