研发和业务：是加法，还是乘法

好久没有写文章了，我要开始了。文字这东西，停下来就想一直停下来。但还是应该继续写，把一些思考写出来，把一些心得写出来，如果能有一些共鸣，也算是很开心的事情。

我之前写过一篇文章《》。是那个时候工作的一些心得总结。这一篇，我想继续说这个点。产品和业务，理想的状况是乘法，这是各个老板，各个团队的追求，然而往往事与愿违。我认为公司高速的发展，就是找到这个“乘法引擎”。

用技术，或者人工智能赋能业务，让业务的发展装上火箭引擎、装上翅膀，一直是各位老板的梦想，也就是我标题中乘法的关系。然而，这是一件远比技术革新要难的事情。往往都是看上去很美，然后几年过后，一地鸡毛。

导致这一个现象的原因有很多，是各方面的。我觉得最重要的是老板要反省自身。老板就是公司最大的产品经理。从战略角度，最精通商业模式的人。那么，老板就要从战略的角度想清楚业务和技术的作用。很多人喜欢技术驱动，但并不能为了技术驱动而技术。技术驱动和业务驱动并不是两种对立的模式，而是相辅相成，我们在发展中往往看到的是一个公司在不同的阶段，核心的增长引擎是不一样的。大多数互联网+，都要经历一个从业务驱动到产品技术驱动的过程，但其实大多数的公司都到不了产品技术驱动的阶段。O2O我觉得不是合适的叫法，在实践中，我们慢慢意识到O AND O才是更有利的发展模式。

在业务驱动的时候，往往是要完成业务的闭环，验证模式的有效性。这时候业务快速发展，业务模式变化迅速，此时的研发就处于一个支持、辅助的位置，研发做的好不好，评估的标准就是对业务的帮助有多大。但这个时候，往往是很痛苦的，业务模式的频繁变化，给研发带来了巨大的压力。这个时候，作为老板要懂克制，并不是我们有研发团队，就什么都要上系统。什么都要做的全面。很多事情可以业务线下尝试，最多辅助以研发提供一些小工具。

这是一种观念上的差异，比较难以改变。有些人，尤其有些“老板”就是喜欢大而全，万一有一些“唯上”的风气，就会造成不好的后果。这里的关键词是：“克制”。

业务闭环之后，研发在闭环的基础之上，要寻找可以提高效率、放大规模的点。业务闭环中形成的有效的业务管理模式、业务模式，都可以固化在系统中，让系统支持业务高效扩张。这时候对系统的功能有较高的要求，对迭代的速度也有较高的要求。

这个环节，研发要把业务当做用户，做到用户认为好用。一般来讲，要摒弃对业务的偏见，要尊重业务，融入到业务的工作场景中，才能把我业务的需求，让业务真正提效。这里要注意一点，谁在用我们的系统。是业务人员，不是老板。那么问题来了，业务有自己的需求，老板有自己的宏大想法。研发怎么办？这里先妄自下一个结论：大概率是要听从业务自己的需求。老板的想法，首先我们要认可的是战略，如果战略没有认可，这件事情就完全无法推进。然后，老板对于业务的工作场景、以及如何工作的想法，在系统的体现上也要克制。总的来说是克制控制的欲望，距离炮火越远，越无法体会战场的艰难。所以，让最接近炮火的人做决策，在总的战略框架下，产品技术梳理业务的需求，系统化为他们实现得心应手的武器。

最后我想说最重要的一点：业务该如何看待系统。其实可以有一个这样的共识，就是系统好用的前提，一定是业务转的很溜了。是不是理解起来有点矛盾？我们实际当中，有很多这样的例子，业务做得好的，系统问题就少；业务做得不好的，系统的问题一堆一堆。当然这里有人性的原因。但更多的是我前面讲的共识——这个很重要。那业务赚得很溜了，是不是还需要系统呢？这是一定的，溜意味着什么——标准化，标准化也是系统可以发威的核心所在。系统做好了，接下来要攻克的一个难关就是一定要用起来。C端的产品我们讲究用户体验，讲究不要特殊的说明，用户就可以使用。B端的产品比较难，因为背后是一套业务流程、业务逻辑。所以，B端的产品培训、宣导一定要做好。业务的老大一定强力推广使用。不用发现不了问题，不用更是无法提高。最后这一点，往往最容易忽略。一句轻飘飘的不好用，带来的固步自封、甚至退步，都是很大的。切记。

不写文字快一年了，有些生涩。希望和大家一起讨论，在陈老师的知识星球，期待和大家一起深入交流技术和业务如何双飞。知识星球目前优惠中，时间有限。