2019年10月16日 |  bckbet官方下载

在我们了解了什么样的产品需要研究院,什么样的公司需要配备研究院以后,我们现在就来探讨一下研究院的架构问题。

我们上面提到了研究院在公司内部需要有一定的独立性。

但是,现代高科技公司,毕竟从根本上来说还是追逐利润的企业,如何来确保研究院能够从长期上是符合公司发展的利益呢?

这一点,是研究院生存的根本。

从历史上来说,早期研究院很多都是这么一种运作模式:

研究院的科学家针对某个技术难题(这个技术难题有可能是来自产品工程部门,也有可能是研究院的科学家自己发现)找到了一种解决方案,形成一个研究成果。

根据不同的研究院的情况,科学家可能会选择发表研究成果,形成论文,或者是申请形成专利。

科学家根据这个研究成果做出一个解决方案的原型(Prototype)。

研究院团队根据解决方案的原型,到产品工程部门进行游说。

产品工程部门根据自身的需求和产品周期,决定是否要把目前的原型重新在工程中实现,从而在下一代产品中使用上这个新成果。

产品工程团队和科学家一起把原型在工程代码中重新实现。

这个模式看似有一定道理,但也存在一些非常关键的问题。

首先,第(1)步中就直接存在可能导致第(4)和第(5)没法发生的诱因。

我们假设研究院的科学家拿到的技术难题是来自产品工程部门的。

从现代产品的角度来说,一般的产品工程迭代都非常快。

现在的技术难题可能几个星期后就有了能够解决80%问题的解决方案。

也就是说,研究院拿到的技术难题有可能是有时效性的。

这并不代表这些技术难题随着时间都有可能被解决,而是说,随着时间进程,很多技术难题可以出现多种解决方案。

科学家能够找到的比较完美的解决方案(姑且假设能够100%解决问题)需要(2)-(5)这些步骤进入产品,这必然导致产品部门必须在科学家方案推出之前找到可以运行但很粗犷的方案。

然而这种方案一旦进入产品,就会成为日后科学家的完美方案进驻的强大阻力。

因为产品工程部门会觉得,在产品已经进一步迭代的情况下,是不是有精力和时间去改进一个已经可以运行的方案为更加完美的方案,其实是一个很棘手的问题。

这也就会导致步骤(4)常常非常政治化(Political),成为各个团队扯皮的重要原因。

刚才说的,还只是假设研究院的科学家拿到的技术难题是来自产品部门的,还有很多情况是,科学家或者研究院自身认为某些技术难题需要得到解决。

这样发展出来的研究成果或者产品原型往往就更加难以通过第(4)和第(5)步得到产品化。

因为第(4)和第(5)步的不确定性,很多研究院在发展过程中,往往把第(2)和第(3)步作为绩效评定的重要结果。

这也就导致了很多研究院的成果只能完成第(1)步到第(3)步这个流程。

而第(4)步成为了研究院成果产品化的不可逾越的鸿沟。

那么如何运作研究院能够跨过这个鸿沟呢?

雅虎研究院在过去10年的时间里对这个问题有着不错的实践经验。

这里的核心问题就是如何把研究院的目标和一般产品工程团队的目标统一起来,使得大家对于产品的开发和运作是同步的。

我们这里要提到这么一个概念,那就是“共享目标”。

什么意思呢?

那就是研究院和产品工程团队虽然从行政上隶属不同的部门,但在项目开发上,两个团队必须组成一个“虚拟团队”,有统一的领导和统一的进程管理,并且执行统一的、共享的目标。

研究院和产品工程团队只是在这么一个共享的、统一的目标下分工不一样,责任不同而已。

具体说来,以笔者参与过的雅虎首页推荐系统为例。

产品工程团队每个季度都会和研究院的研究团队一起指定目标。

这个目标是一个综合性目标,有产品的部分(比如提高多少用户访问、提高多少用户点击),有纯工程的部分(比如如何加快代码部署),有研究的部分(比如应该采用什么模型来达到用户访问的提高、比如应该怎么加快模型的训练速度)。

那么,“虚拟团队”就会根据这个综合性的目标来分配资源,确保整个团队的工作量和各个方面的目标达到一个不错的平衡。

目标共享以后,研究院的研究周期得到了明确,也就是每个季度。

同时,研究院的“成果落地”得到了保证,那就是直接和产品对接,每一个季度都需要“上线”。

这种模式下的研究院团队,也不会去做“天马行空”的项目,而是仅仅围绕产品工程,做很多“增量式”的创新工作。

“共享目标”对于雅虎的很多产品决策过程以及运作过程产生了深远的影响。

首先,那就是采用“共享目标”架构的产品全责更加清晰,工程负责什么,研究院负责什么,设计师负责什么,每个季度这几个方面一目了然。

另一个非常显著的改变,那就是这些产品第一次把AI(这也就是研究院往往负责的部分)、工程以及设计三个方面作为一个产品每个季度推进的三个主要方面。

也就是让AI成为了产品的目标的一类公民。

那么,“共享目标”是不是就解决了研究院的运作问题了呢?

答案是,不完全是。

首先,“共享目标”听上去容易,但在实际运作中难度其实还是很大。

这里面最重要的是信任问题。

从公司结构上来说,产品工程团队往往对产品有“所有权”(Ownership),自然希望能够对产品的方方面面有所把握。

然而在“共享目标”的框架下,实质上发生的则是,研究院对于产品的部分方面有了一定的决策权和执行权,这势必需要产品工程团队的领导和人员对于这方面有足够的认识和预期。

实际上,从另外一种角度来说,这种“共享目标”其实就是产品工程部门把部分产品开发方面长期外包给了研究院的团队。

雅虎的产品工程团队能够和研究院针对某些产品这么做,是因为研究院长期以来能够对这些产品持续做出不俗的贡献,赢得了信任。

但并不是所有的产品都能够在这样的框架下运作。

同时,因为和产品工程达成“共享目标”,这势必也就造成了研究院的研究目标和成果相对比较“短视化”,常常迎合了产品周期。

这也就呼应了我们之前提到的,比较适应研究院的一类产品,那就是成熟产品。

实际上,“共享目标”的模式很好的契合了成熟产品的迭代。

对于前沿产品来说,这样的架构显然不太适用。

因为这个时候产品和工程组可能都还不存在。

对于这样的项目来说,最好以研究院的科学家为核心,然后辅以工程师作为支持。

从某种意义上来说,这依然是一种“共享目标”,不过则是之前谈到的相反的结构。