产品和研发,断裂与连接

Posted mindwind

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了产品和研发,断裂与连接相关的知识,希望对你有一定的参考价值。

技术分享图片

最近,读了二爷邱岳的《产品手记》专栏,相比较而言梁宁的《产品思维》主要讲「道」,而二爷的则主要讲「术」。

其中有两篇讲到产品和研发如何打交道,谈到了产品和研发不知怎么就形成了一种矛盾与对立的关系,让我反思了下我所在团队中产品和研发的工作模式与关系。

断裂与分歧

一反思我们团队中产品和研发的关系,幸运的是整体还是比较和谐的,但其中并非不存在问题。

先说一个产品和研发打交道最多的场景 —— 需求评审。在需求评审中,虽然大家并不是针锋相对、剑拨弩张,搞得像谈判一样,但却有点像菜市场一般就某个需求点进行讨价还价。一旦进入「讨价还价」模式,就意味着双方站在了各自独立的立场,而非共同的价值和利益出发点了。

产品站在价值方,研发站在成本方。

产品代表业务与用户,对产品功能进行价值判断并转化为研发需求。而研发中的个体,也就是程序员会习惯从自身开发成本(好恶、难易)去评估需求,而感觉自身开发成本高(麻烦)时,就容易进入和产品的「讨价还价」模式。

这里面的问题就在于,研发没有习惯优先从需求的价值出发去考虑;而产品的问题在于,绝大部分产品并没有程序开发背景和经历,所以有时很难评估清楚,甚至理解完成一个功能需求的研发成本。

产品价值的评估相对主观,产品有时也可能面临无法很好评估某个(些)需求的价值,甚至根本就不是从价值点出发,而是对标市场竞品,达到别人有的,所以我们也要有的效果。

研发的成本则相对客观,但研发在评估需求时过于注重个人开发实现的方便性,路径依赖性,对不确定的技术实施成本有抵触。

结果,就在这里产生了一个断裂带,进而分歧滋生。在这种情况下,如果沟通不当,坏的结果就是,双方变得对立;而好的结果,也不过是各让一步,妥协折中,变得中庸。

连接与共识

面对这样的断裂带,有没有可能重建连接与共识?

对于这个问题,套用梁宁《产品思维》中提出的一个用户体验 5 层次模型框架来分析下,这个 5 个层次包括:

  • 感知层
  • 框架层
  • 资源层
  • 能力层
  • 存在层

其中产品的日常工作,大多发生在「感知层」和「框架层」。产品逻辑,交互结构,信息架构等都属于框架层的工作内容,感知层是产品的展现形态,和五感直接相关,而互联网产品最重要的感知是视觉。

而研发的日常工作,则大多发生在「资源层」和「能力层」。研发不断的积累资源、拓展提升能力。具体到研发个体上,资源可以是个人的技能,能力则是解决问题,开发功能的效率和品质。

产品和研发的共同连接点在于「存在层」。存在层研究每一个功能需求的价值与意义,换言之,它确定正确的事。那何谓正确?我的答案是做的这件事要有经济效率;经济效率即价值大于成本。

按如上正确标准,我们在分析竞品的对标功能点时,就需要仔细研究其存在的意义与价值,再来对比我们实现它的成本。有时,完成同样的功能需求,对于不同的公司、不同的团队、在不同的阶段,其价值和成本都是变化的。

我们只在其具备经济效率时才去完成它,正所谓:用正确的方式,做正确的事。

但评估是否正确其实是一件极具挑战的工作。产品经常抱怨的一件事是研发估算工期从来没准过,基本总延期超时。这体现在对成本的估算上是不准确的,有时搞不好估算和实际的时间能差一倍。如果用程序算法的时间复杂度来说,一两倍的时间误差,基本还算在一个量级的准确度内,不算夸张。

但对业务和产品价值的评估,一开始是非常主观的,估算误差搞不好就是量级的差距。比如说吧,业务方有时估计业务上线后,能有百万日活跃,但最后上线了仅有几万日活。这种数量级的估算误差带来的研发一次性投入成本浪费也是蛮大的。

对于创新业务,模糊的价值评估,最好的研发投入方式也许可以参考风投的思路。刚开始总是从一个切入点进入,少量资源完成一个最小集的产品形态,上线验证业务发展情况。每过一个阶段,业务如果发展超预期,第二次迭代就加倍投入;每一轮迭代,只要业务发展超预期,都继续加重投入比例,最后的结果将是最多的资源,进入发展最快且前景最好的业务上。

所以,进入高阶的研发人员(架构师、技术负责人)对成本的估计会更客观和准确,这时,就需要更多去看那些模糊的价值,考虑研发实施的经济效率问题。

闭环与共享

有时,某些需求价值和时间有关;要么随时间衰减,要么在某个时间点前有价值,之后可能就没价值了。

这样的需求价值变化,通常和创新业务与市场竞争格局变化有关。面对这类需求,研发去应对的经济效率问题冲突会更明显。在这个过程中,研发形成了两种协作模式:闭环与共享。

闭环,就是和业务需求方绑定,专门做此类变化快的需求开发,其他的都不做;而共享则相反,将研发资源共享成一个池,所有的业务需求也汇总在一个或多个优先级队列里,排队开发。

共享,有利于充分利用研发资源,规模化、专业化,提升吞吐,但可能也降低了平均响应时间,更适合于进入成熟期,稳定渐进发展的业务。闭环,优先考虑专属业务需要的响应,但也失去了规模与专业化效应,更适合快速发展期的创新业务,而过了业务高速期,专属的研发就会形成资源浪费,对个体的成长也有不利因素。

而在一个大的组织中,很可能就同时存在闭环与共享两种模式。在这两种研发模式下,产品和研发该如何做,才能符合经济效率原则?先说一个不好的例子。

面对共享模式,大量的业务方因为经常产生需求开发排期冲突。所以,业务为了更多的占住研发资源,会自然产生一种驱动因素:先不管那么多尽量多提需求。而需求本身的意义和价值反而放在了次要位置。

当研发被永远开发不完的需求队列压住,就会本能的拒绝需求,进入「讨价还价」模式;而业务熟悉了这套模式后,就会开更高的价等你来还。产品居于其中,需要筛选出符合经济效率的正确事情,难度则进一步加大。

闭环和共享,没有绝对的好坏之分,都是相对阶段的选择。如果业务必然走向成熟,那么闭环就会走向共享。共享,依然是能力和资源层的建设,组织的标准化研发输出能力的形成。

无论研发的组织形态如何变化,我们都要警惕进入「讨价还价」模式,它太容易带来负反馈循环,而负反馈的循环一旦积累成型,要破解它就变成了一个很复杂的系统性问题。

...

需求似乎永远开发不完,我们只能努力提升完成的需求中「正确」的比例。


写点文字,画点画儿,记录成长瞬间。
微信公众号「瞬息之间」,既然遇见,不如同行。
技术分享图片



以上是关于产品和研发,断裂与连接的主要内容,如果未能解决你的问题,请参考以下文章

Arm 虚拟硬件与新解决方案或将颠覆物联网产品研发

深圳市共创力咨询推出“慧眼”综合性研发管理知识服务平台!

Android 产品研发--> APP 研发梳理

研发部的日常工作

微软中国的相关研发团队 交流平台

机器学习/服务端开发/DevOps 深圳研发职位