产品和研发的一点反思：断裂与分歧、连接与共识、闭环与共享
本文主要是作者反思了他所在团中产品和研发的工作模式与关系，来谈谈产品与研发中的断裂与分歧、连接与共识、闭环与共享。
最近，读了二爷邱岳的《产品手记》专栏，相比较而言梁宁的《产品思维》主要讲「道」，而二爷的则主要讲「术」。
其中有两篇讲到产品和研发如何打交道，谈到了产品和研发不知怎么就形成了一种矛盾与对立的关系，让我反思了下我所在团队中产品和研发的工作模式与关系。
断裂与分歧
一反思我们团队中产品和研发的关系，幸运的是整体还是比较和谐的，但其中并非不存在问题。
先说一个产品和研发打交道最多的场景 —— 需求评审。在需求评审中，虽然大家并不是针锋相对、剑拨弩张，搞得像谈判一样，但却有点像菜市场一般就某个需求点进行讨价还价。一旦进入「讨价还价」模式，就意味着双方站在了各自独立的立场，而非共同的价值和利益出发点了。
产品站在价值方，研发站在成本方。产品代表业务与用户，对产品功能进行价值判断并转化为研发需求。而研发中的个体，也就是程序员会习惯从自身开发成本（好恶、难易）去评估需求，而感觉自身开发成本高（麻烦）时，就容易进入和产品的「讨价还价」模式。
这里面的问题就在于——研发没有习惯优先从需求的价值出发去考虑；而产品的问题在于——绝大部分产品并没有程序开发背景和经历，所以有时很难评估清楚，甚至理解完成一个功能需求的研发成本。
产品价值的评估相对主观，产品有时也可能面临无法很好评估某个（些）需求的价值，甚至根本就不是从价值点出发，而是对标市场竞品，达到别人有的，所以我们也要有的效果。
研发的成本则相对客观，但研发在评估需求时过于注重个人开发实现的方便性，路径依赖性，对不确定的技术实施成本有抵触。
结果，就在这里产生了一个断裂带，进而分歧滋生。在这种情况下，如果沟通不当，坏的结果就是：双方变得对立；而好的结果也不过是各让一步，妥协折中，变得中庸。
连接与共识
面对这样的断裂带，有没有可能重建连接与共识？
对于这个问题，套用梁宁《产品思维》中提出的一个用户体验 5 层次模型框架来分析下，这个 5 个层次包括：
- 感知层
- 框架层
- 资源层
- 能力层
- 存在层
其中产品的日常工作，大多发生在「感知层」和「框架层」。产品逻辑，交互结构，信息架构等都属于框架层的工作内容，感知层是产品的展现形态，和五感直接相关，而互联网产品最重要的感知是视觉。
而研发的日常工作，则大多发生在「资源层」和「能力层」。研发不断的积累资源、拓展提升能力。具体到研发个体上，资源可以是个人的技能，能力则是解决问题，开发功能的效率和品质。
产品和研发的共同连接点在于「存在层」。存在层研究每一个功能需求的价值与意义，换言之，它确定正确的事。
那何谓正确？
我的答案是做的这件事要有经济效率，经济效率即价值大于成本。
按如上正确标准，我们在分析竞品的对标功能点时，就需要仔细研究其存在的意义与价值，再来对比我们实现它的成本。有时，完成同样的功能需求，对于不同的公司、不同的团队、在不同的阶段，其价值和成本都是变化的。
我们只在其具备经济效率时才去完成它，正所谓：用正确的方式，做正确的事。
但评估是否正确其实是一件极具挑战的工作，产品经常抱怨的一件事是研发估算工期从来没准过，基本总延期超时。这体现在对成本的估算上是不准确的，有时搞不好估算和实际的时间能差一倍。
如果用程序算法的时间复杂度来说，一两倍的时间误差，基本还算在一个量级的准确度内，不算夸张。
但对业务和产品价值的评估，一开始是非常主观的，估算误差搞不好就是量级的差距。比如说吧：业务方有时估计业务上线后，能有百万日活跃，但最后上线了仅有几万日活，这种数量级的估算误差带来的研发一次性投入成本浪费也是蛮大的。
对于创新业务，模糊的价值评估，最好的研发投入方式也许可以参考风投的思路。刚开始总是从一个切入点进入，少量资源完成一个最小集的产品形态，上线验证业务发展情况。
每过一个阶段，业务如果发展超预期，第二次迭代就加倍投入；每一轮迭代，只要业务发展超预期，都继续加重投入比例，最后的结果将是最多的资源，进入发展最快且前景最好的业务上。
所以，进入高阶的研发人员（架构师、技术负责人）对成本的估计会更客观和准确，这时，就需要更多去看那些模糊的价值，考虑研发实施的经济效率问题。
闭环与共享
有时，某些需求价值和时间有关，要么随时间衰减，要么在某个时间点前有价值，之后可能就没价值了。
这样的需求价值变化，通常和创新业务与市场竞争格局变化有关。面对这类需求，研发去应对的经济效率问题冲突会更明显。
在这个过程中，研发形成了两种协作模式： 闭环与共享 。
- 闭环： 就是和业务需求方绑定，专门做此类变化快的需求开发，其他的都不做；而共享则相反，将研发资源共享成一个池，所有的业务需求也汇总在一个或多个优先级队列里，排队开发。
- 共享： 有利于充分利用研发资源，规模化、专业化，提升吞吐，但可能也降低了平均响应时间，更适合于进入成熟期，稳定渐进发展的业务。闭环，优先考虑专属业务需要的响应，但也失去了规模与专业化效应，更适合快速发展期的创新业务，而过了业务高速期，专属的研发就会形成资源浪费，对个体的成长也有不利因素。
而在一个大的组织中，很可能就同时存在闭环与共享两种模式。在这两种研发模式下，产品和研发该如何做，才能符合经济效率原则？
先说一个不好的例子：
面对共享模式，大量的业务方因为经常产生需求开发排期冲突。所以，业务为了更多的占住研发资源，会自然产生一种驱动因素——先不管那么多尽量多提需求，而需求本身的意义和价值反而放在了次要位置。
当研发被永远开发不完的需求队列压住，就会本能的拒绝需求，进入「讨价还价」模式。而业务熟悉了这套模式后，就会开更高的价等你来还。产品居于其中，需要筛选出符合经济效率的正确事情，难度则进一步加大。
闭环和共享，没有绝对的好坏之分，都是相对阶段的选择。如果业务必然走向成熟，那么闭环就会走向共享。共享，依然是能力和资源层的建设，组织的标准化研发输出能力的形成。
无论研发的组织形态如何变化，我们都要警惕进入「讨价还价」模式，它太容易带来负反馈循环，而负反馈的循环一旦积累成型，要破解它就变成了一个很复杂的系统性问题。
需求似乎永远开发不完，我们只能努力提升完成的需求中「正确」的比例。
作者：mindwind
关键字：团队协同, 研发, 闭环, 产品
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
