我做了五年招聘的业务，从C端的产品有鱼开始，做过两套猎头系统，深入过猎头公司的运营管理，到现在正在做猎头平台的产品，对招聘这个业务有了比较深刻的理解。从开始单纯的以互联网的方式切入这个行业，到现在的业务运营驱动。这里填了很多坑，有很多的思考，其中最简单最重要的一点就是：要懂业务。
四个字很简单，但实际上懂业务很难。懂业务涉及的方面很广，我曾经一段时间内觉得懂业务很简单，足够聪明，很快就能够进入业务。但实践中不断的打脸，对于业务要做到“懂”这是一个系统性的工程。要经历一系列的本质上的转变。
从心里尊重业务
如果心里一直是瞧不上业务，就无法站在业务的角度去看待问题、理解问题。这个是研发最常见的、最本质的问题。常见的研发的一些偏见：
-
业务系统需求不统一
-
个性化严重
-
没有一个统一的人负责需求
-
变化快
-
体力活多
-
没有成长
这些是一些偏见，缺乏正确的认识和正确的处理方式造成的。但也不能说是错误的。
另外一个点，研发往往会希望自己能够主导，变成产品、或者是技术的驱动。这样，有足够的话语权、足够的自由去做自己想做的事情。这种心情可以理解，但不得不说在大多数情况下都是错误的。从本质上，我们要明白业务是核心，产品是要解决业务的问题，帮助业务达到指数级的增长。简单一点理解，问问自己这个模式下，最小的闭环最不可或缺的是哪些环节？一定是业务上的画圆，然后产品技术一定程度帮助业务规模的增长有机会呈现指数级。
杜绝三个错误
在做业务系统的时候，有三个错误很可怕，不容易发现，但过后对整体的影响又是巨大的。
-
脱离业务设计产品
-
沉溺于业务的某个细节
-
用严密的逻辑完善业务
这是三个错误在发生的时候，比较难以被发现——在发生的时候，看起来挺好的，并没有什么不合适。那到底该如何发现、如何评判的呢？
根据我的经验，为何会脱离业务设计产品呢？是否要做这个功能，做了这个功能能达到什么效果没有围绕着业务进行。这里深层次是一个功能点优先级的问题，到底先设计开发什么样的功能点，依据应该是业务上的优先级（但是这个优先级，也并不是业务单方面决定的）。在解决了业务问题的基础之上，再鼓励一些创新性的发挥，是极好的。这个可以在管理上
适度权衡
。因为业务的问题恐怕很难全部解决。
沉溺于业务的某个细节是第二个错误。通常研发在开始了解业务的时候，了解了某些业务的工作场景可能就认为自己了解了业务的全面，专门为这个场景设计各种功能提高效率。这本质上不能说不好，但是做多了团队会疲劳，大家会觉得没有实现自己的价值。这个问题的本质也是了解业务没有了解全面，分不清重要的程度。
最后一个错误是一个深坑。我在之前的文章里也有说明，当一个不懂业务逻辑的聪明人接手业务，梳理业务的时候，只能从逻辑的正确与否，是否完备的角度评判，会将业务搞的复杂无比，不光业务怨声载道、产品开发也是如此。结果就是浪费了时间，却没有解决问题，而且看起来还找不到问题所在，因为所有的逻辑就是“正确”的啊。这里深层次要考虑的是，”正确“的依据是什么呢？放在业务整个系统性的工程里，到底处于什么样的位置呢？我举一个经历过的例子，我们之前猎头的KPI有七八百项，可以想象么？但实际业务中，有经验的业务管理只会用到几项。不能说那七八百项不对，但是在业务场景下需要考虑么？不需要。无论是业务管理，做业务系统产品，真的要记住这个深坑。
系统性理解业务的标志
写到这里，我想对之前的讨论做一个总结。到底什么是懂业务？什么是对业务的系统性理解.
熟悉业务的各种流程、各种场景，并且能够对细节进行整体的优先级排序。
更重要的是整体的优先级排序，无论业务提到了什么问题、产品技术设计的过程中遇到了什么问题，都要将这个点放到整体的逻辑中考虑，这个点处于排序的什么位置，对于用户的影响是什么样的。长此以往，无论是自己的感觉，还是业务的评价都会是：“懂业务”。
如何做到懂业务
说起来容易，做起来很难。在招聘这个行业也是填坑填了五年。总的来讲有两点：
-
明确业务运营驱动的本质
-
产品和技术的负责人都要成为业务专家
产品技术驱动看上去很美，但我们还是要面对现实。业务运营上的闭环是第一个要完成，围绕这个闭环转的越来越顺是第二个要完成的。这两个阶段，产品技术大多是提速的作用。这个正确的认识，是必须要建立起来的。
不知道大家是否遇到过这样的一些问题：
-
为什么业务这边没有一个特别懂的人
-
为什么业务的需求都不一样，有矛盾
-
为什么业务的需求就不能统一
-
为什么业务这边没有统一的对接人
-
为什么业务不能内部讨论，统一输出
类似这样的问题很多，但为什么这些不是我们产品和技术去搞清楚呢？
有的团队确实有业务很强的人，业务能力非常精通。但如果要求他具备产品的思路，具备很强的系统性思维，能够把业务逻辑梳理得很好是不现实的。这样的人万里挑一，每一个人都是各个公司追逐的对象。
但并不是没有这样的人就不能解决问题。所以，产品技术要冲到业务当中去，到群众中去，去了解、整理、系统化。产品可能有很多事情做，PRD、交互、协调推动等。但我觉得在业务驱动的产品中，产品更应该再往前置，甚至和业务一起工作充分保证产品的逻辑和业务的逻辑能够契合。
结语
针对业务和研发的关系，家家有本难念的经。我已经听过很多个版本，结合我自己的经历。做了以上的总结，欢迎交流。
不过，业务和产品技术的关系是不断变化的，业务到一定的规模真正的引擎就会换成产品技术，这时候产品体验、技术实力将会是关键。这个话题我们后面聊。
