研发人员的产品观

说起来都是老生常谈，不过温故而知新，很多内容我自己都找不到哪篇旧文写过，更不用说有很多新读者。

我一直强调研发人员要具有产品观，那么偶尔在朋友圈看到一些创业团队分享的经验，也不断地佐证这个观点。

为什么不断提这个话题，研发人员为什么需要有产品观，因为很多情况下，研发效率低，并不是研发人员不够努力，也并不是研发人员水平太低，而是他们在理解需求的时候出现了偏差，容易过度设计，或者无法做到抓大放小，在低价值的诉求上浪费了太多时间和精力。

对于创业公司而言，这样的情况，往往是致命的，因为创业团队并不具备高度冗余的技术资源，如果无法实现高效率低成本的研发，那么面对巨头围剿，胜算极低。

那有人会说，我就是一个研发，产品经理给我需求我就完成，如果存在需求不明，存在主次不分，难道不是产品经理的责任么？

这就是我旧文不断强调的另一个话题，所谓职场的容错性，产品经理固然要强化自己对需求的精确描述能力和主次的区分能力，但如果研发也具有足够的产品观，沟通成本会更低，而且可以更好的对产品人员容错，坦白说，对于大部分创业公司而言，一个具有非常成熟研发管理能力和经验的产品经理几乎是不太可能出现的（其实巨头里，能把研发管理做到位的产品经理也是凤毛麟角的），大部分产品经理仅仅能从功能角度描述需求，而这，其实是远远不够的。

那么，研发人员如何才算拥有产品观，或者说，我认为一个优秀的研发人员应该有怎样的产品素质。

1、对业务好奇。

好奇心是驱动一切的基础。

你做出的产品，在业务上表现是怎样的，公司的产品，业务的逻辑是怎样的。

能够理解代码逻辑，没理由理解不了业务逻辑。

好奇之后才是探索，通过搜索引擎，通过财经网站，查阅行业内领军企业的财报，业务构成。主要竞品公司的业务数据，对比自己公司的业务数据，分析其中异同，寻找业务关键要素。

2、信息交叉。

这是一个很简单的逻辑，你看到很多不同口径，不同统计的数据，其实组合计算，会得到很多有意思的数据。

比如说，最简单的逻辑，知道了收入，知道了活跃用户数，就应该算出来单位用户的价值对不对，如果你知道A产品的收入和活跃用户数，B产品的收入和活跃用户数，那么是否有意识对比一下二者的活跃用户价值呢？

很多有价值的数据是通过不同数据的交叉计算得出来的，不要什么都等着别人喂给你，自己要有敏感度，不断养成自己校验计算的习惯。

网上很多第三方的数据一看就是错的，因为很多数据禁不起交叉计算，算出来的结果很离谱。但很多人为什么深信不疑，因为他们没有这方面的意识。

信息交叉可以更好的认识业务的不同层面和不同表现，可以在互联网上大量碎片信息的情况下，自行补全很多关键业务信息。

3、了解需求背景和目标。

这点非常重要，需求不只是功能的罗列，这个需求提出的背景是什么，要解决的目标是什么。

理解这些才能和更好的理解需求，并做出合适的处理，比如哪些是重要的，哪些是次要的，哪些是需要高精度高可靠性的，哪些是容错空间比较大的，这个设计复杂度也会差很多。

4、了解需求边界。

这个其实旧文也多次提到，什么是需求边界，产品人员说，我需要什么什么的数据，那么有时候他们不会说，甩尾信息是没意义的，什么是甩尾信息，就是很多长尾数据没有进一步分析的价值。比如一个游戏产品单页昨天的访问量是5次，今天是10次，增加了一倍，但我需要关心么，我不关心，这是长尾信息。但如果昨天是5000次，今天是6000次，只增加了20%，我可能依然要关心，因为这个可能是比较重要的游戏产品。但很多时候，研发人员接到需求的时候，没有意识到长尾信息是可以丢弃的，甚至是干扰正常分析的。

功能也有边界，搜索翻页的例子说的都想吐了，用户需要搜索翻页，但并不需要翻超过100页。

其实这是3的延伸，当你更好的理解需求的目标和背景的时候，可以和产品人员进一步明确需求边界，哪些是可以舍弃的，哪些是不需要过度细化的，这样产品设计的复杂度，存储的开销，以及各种计算开销，都可以指数级下降。

是的，当年我写cnzz的时候，技术水平有限，但是我能用有限的技术实现足够高的负载和应用表现，其实需求边界的控制可以说是我擅长的领域。这就是跨界的优势。

5、了解需求收益，并能正确评估实现成本。

当你确定一个需求，并准备实现方案的时候，问自己两个问题，第一，你是不是很清楚这个需求对项目，对公司的收益预期是什么；第二，你是不是很清楚这个需求的实现成本是什么。

如果实现成本低而收益预期高，这是一个特别容易出成绩，特别容易展现效果的工作。当然要尽快实现。但如果实现成本很高，而预期收益很低，那么就要评估一下，这个需求是否值得，或者是否有简化的方案。

比如说，产品人员只是临时性的测试某种奇怪的想法，而技术人员却制定了兼容性，扩展性都非常深度考虑的复杂方案，这就是常见的过度设计。最可怕的是，产品人员还没意识到这里存在沟通的偏差，不知道研发开销，从而导致一些关键需求被压制，被拖累。

6、了解你的产品经理，或者说需求提供者。

这也很重要，职场很多是人与人的沟通，有的产品经理思路明确，逻辑清晰；有的产品经理可能就欠缺一些。

有的产品经理有技术背景，沟通起来会容易一些，有的产品经理因为缺乏相关技术背景，很容易低估或高估技术实现成本。

有的产品经理的目标感很清晰，懂得抓大放小，懂得优先级顺序；有的产品经理可能急于证明自己，容易过度加戏，用大量的需求文档证明自己的努力和想法的丰富度，导致研发疲于应付。

有些时候，一些创业公司甚至根本就没有所谓产品经理，业务人员直接提需求，更容易出现混乱的情况，甚至同一个基本需求，不同的业务人员会有不同的提法和诉求，随着人员流动，需求也会随之大幅度的变更，这种情况下，如果研发一昧的被动接受，更容易疲于应付，难以发挥真实的产品价值。

你面对的需求提供者是怎样的人，他提供需求的时候，他自己的诉求是什么，他的表达和描述是否是足够准确的，作为研发人员，如果你能更好的去理解需求方，作为个体的诉求，（理论上，需求方的诉求就是业务上诉求，但在实际场合中，也会夹杂很多个人的诉求），那么沟通过程可能会有不同的指向，在设计原则上也可能会有很多不同的处理思路。

很多时候，甚至可以说是大部分情况下，研发人员自以为已经了解了需求，但没有深究一步，没有更多思考这个需求定义背后的逻辑，那么在实现过程中，就容易出现，依赖脑补，过度设计，或者放错重心，甚至可能被一些含糊不清，模棱两可的信息所误导。

大部分研发的时间浪费在了不必要的事情上，是的，根据我的观察，这是很多公司的常态，而这种不必要，第一来自于沟通的不充分；第二也来自于研发对业务诉求的误判。

那么拥有足够的产品观又如何，有人会说，你最后不还是要听产品经理的？或者还会有人疑惑，研发有产品观，还要产品经理干什么？

1、产品经理要提出正确的问题，找到正确的方向。这个要求是很高的，而研发的产品观主要目标在于正确的理解需求。所以不用过于担心懂了业务就会去抢产品经理的饭碗，当然如果你说有个例，研发成长为产品大牛，我不敢说我是，但我必须说这个路线是有的。

2、研发的产品认知与产品经理产生冲突的时候，在很多时候，是可以通过进一步协商处理的。实际上，一个公司有产品意识的老研发，比新来的产品经理更懂公司业务，是很合理的，新产品经理如果提出一些不靠谱的诉求，被老研发怼回去，并不是什么坏事。

3、产品经理如何获得研发的信任，如何让研发更好的听从自己的安排，这是另一个话题，本文不讨论，不过有兴趣的可以看看这篇 -> 明明有本事，为什么难升职？ 关于信任基础，其实说的几乎是一回事。