提问
精华 算法是不是产品经理该考虑的?
发布于 1 年前 作者 PMskill小助手 587 次浏览 最后一次编辑是 10 个月前 来自 产品

知乎上有个问题如下: 经常被研发同事问倒,这个功能应该怎么做呢?算法问题应该是实现层面的问题了,不知道各位在实际过程中的经验是怎么样的。其实职能本来没有一个特别清晰的界定,但是一定有最效率的方式。

这么说太虚了,举个例子,比如,产品需要根据用户添加“喜欢”的内容向用户推送用户喜欢的内容,就是一个“猜”的功能,那么这个猜出来的内容是怎么算出来的,这个算法。

我的回答是

去年在点我达,我接手了调度模块的设计,有几个月时间一直在搭建产品框架和协作流程。在此之前,调度的产品、算法以及除了开发的方方面面,都只由一个同事负责。 与此同时,公司成立了算法研究院,请来了机器学习相关的博士,负责以调度为主的各项算法的设计。 于是原本从接受需求、设计功能,到研究算法、跟进实施的步骤,拆分成了两块:我带的调度产品组负责调度产品,而研究员团队负责调度算法。 现在的协作流程大概是这样的:

1. 需求方提出需求

例如,运营的同事认为,鲜花订单的派单形式要有新的产品和算法支撑。这里讲一下背景。我们的即时物流平台会有外卖、商超、快递、鲜花等一系列类型的订单,其中外卖订单是比较核心的,我们做的也比较久,因此很多产品模块包括调度的设计,都是适应外卖场景的。当时鲜花则是相对新的业务。

2. 产品经理承接需求,并抽象

我们小组的同事小 C 接到了这个需求,于是跟运营的同事多次沟通讨论需求背景,以及跟相关的其他同事(比如销售、商务的同事,以及骑手)确认实际场景。最终,抽象出算法问题。

比如,以下就是典型的算法问题描述: 在时效要求不高(以天为单位,而外卖是 1 小时内送达)、起点集聚终点分散(外卖的起点终点都是分散的)、每个骑手可携带鲜花订单数量为 n (外卖的上限 m < n)的前提下,应该如何基于外卖调度逻辑来设计鲜花调度逻辑。

3. 算法研究员承接算法需求,解决算法课题。 算法研究员常博接受了算法需求,于是会把产品经理的描述再抽象一层,变成约束条件下的最优派单策略。以这些可量化的指标,就可以搭建起算法模型,依据已有的历史数据,来跑出最合理的算法策略以及相关的参数设置。当然,在此过程中,不免会与小 C 和运营的同事持续沟通,有许多策略涉及的因素,比如在产品逻辑中的耦合性、比如在具体业务场景中的合理性,都要做大量探讨。

像下图就是典型的算法描述(是我们已弃用的一个算法):

4. 产品经理整合算法模型成为产品功能 此后,小 C 会考虑模型的细节,然后就跟把引擎装入发动机一样,设计出模型相关的配套产品功能。真正的需求文档会是算法文档长度的几倍甚至十几倍。后续就会跟技术协作,跟进研发。过程中也是会跟常博经常沟通,但在此阶段负责人始终是小 C。

这种协作模式可以算是一种可参考的模板。我们运行了半年多,一直没有问题,而且双方的协作极少有模糊地带。 那么回到题主的问题。可能现在没有专职的算法研究员,那么产品和研发直接协作该怎么办

就推送喜欢的内容这个需求来说,首先,需求的目的、背景是产品经理要搞清楚的。推荐这些内容,是为了什么?浅显的目的是为了让用户点击,那背后相关的需求是什么?是现在用户活跃度比较低、是用户发掘优质内容的路径过长,还是并不清楚老板说好像大家都有那就做吧

其次,最关键的,需求的实现方式是产品经理要搞清楚的。需求和算法是两个层面的事情,作为产品经理不能丢给研发说「做个推荐」就行了。显然,推荐不是一种具体的算法课题。就好像告诉研发说「做个个人中心页面」一样不具体,这个页面应该有什么、要达到什么效果,跟其他功能的逻辑关系…都是产品经理要考虑的。

就推荐来说,是基于什么数据做推荐呢?用户的历史浏览、用户的已有关注、用户的资料画像,还是用户的社交关系?即使作为产品经理,你不清楚基于规则、基于内容和协同过滤都是什么概念,你也要知道推荐不是凭空做的,是要根据具体的数据做分析的。

一个合理的梳理结果就像前文提到的,应该是类似于:「基于用户已有关注对象的类型和这些对象发布内容的特征,来推荐更多同类的关注」或者「基于用户目前的社交关系和相关的互动情况,推荐更多他可能喜欢的用户」。

再之后,是跟研发搞清楚,所给出数据的意义(比如相关因素的权重),以及沟通逻辑上的合理性。比如,拿基于社交关系的推荐来说,用户 A 给用户 B 经常点赞意味着什么?用户 A 跟用户 C 每周有 15 次互动意味着什么?用户 A 拉黑了用户 D 意味着什么?这些不是算法课题!这些是产品经理应该以自己对用户或主观或客观的感知,得出的功能判断。

然后是建模。在这里确实有一个模糊地带,如果是非常懒的研发,不愿意自己研究算法课题、自己建模,是有点尴尬。在职责划分上,坦率地说有计算机背景的研发做建模和算法研究会更合理一些。但如果是我,我会很开心有往前多走一步的机会。如果把这件事做好,就相当于多了一项不错的核心竞争力(可以想象未来懂算法、懂机器学习的产品经理会越来越吃香),也许会大大有利于你在公司甚至未来市场上的竞争力。

即使是你并不想有这项核心竞争力,在争执不下的场景中,我也建议你暂时把这个任务做起来。毕竟产品经理是要为产品的方方面面负(tian)责(keng)的,产品因为任何问题没有如期完成,产品经理都跑不了。

接下来就是根据建模的结果,梳理功能了。推荐当然不是简单的建模而已,具体什么时间节点收集用户信息?在什么功能模块下推送给用户?推送的数量有没有限制?展示交互和界面都是怎样的?这也都是产品经理要整理好的。

最后,具体用什么样的代码、什么样的系统框架来实现,那就是研发的事情了。 大致来看,就是这样的: 从题主的描述看,其实有点像省掉了「需求抽象」和「功能设计」的步骤,认为这纯粹是个算法课题,需求来了就硬生生扔给研发,等待产品出炉了。我觉得这是不太合理的。 前文提到了,在点我达初期,实际上所有实现之前的步骤,都是由我一位同事完成的。这也是我推荐的方式。 歇歇。

封面图依据 CC0 协议授权。

文章来源于公众号:liufeinotes

2 回复

产品经理应该要做的是「需求抽象」和「功能设计」,不能认为这纯粹是个算法课题,需求来了就硬生生扔给研发,等待产品出炉了。

最近刚好在搞一个机器人,里面也有很多算法的工作,产品经理可以不用给出算法实现细节,但是得把算法需求背景讲清楚

登录 后发表看法
回到顶部