技术对业务的抱怨常有：

• 需求不明确，都搞不清楚他们想要什么；

• 业务做不好怪技术，技术是背黑锅的；

• 什么功能都想要，没有优先级；

• 我们加班加点开发出来了，他们最后不用。

同样，业务对技术的抱怨常有：

• 我们明天就想要，技术却说要开发2个月；

• 问题这么多，系统真垃圾；

• 功能这么少，别人有的我们没有；

• 速度那么慢，竞争对手那么快。

我相信这不仅存在于我所在的公司，同样也存于你的公司，而其它的跨部门沟通如人事、财务、法务，或多或少都会存在诸如此类的问题。

业务是什么？市场不是业务，运营不是业务，技术也不是业务，那业务到底是什么？维基百科的解释是“企业运用科学方法和生产工艺生产出可交付用户使用的产品与服务，并以此为企业带来利益的行为”。所以，业务应该是属于公司的，而不是属于某个部门的，运营和市场是业务方，而不是业务。

我们在一起，是为了一个共同的理想、共同的业务目标，我们叫同事。运营、市场、技术三者互相依赖，缺一不可，不可分割，如果任何一环出现问题，就会影响整体业务目标的实现，也会引起互相的抱怨。

每一个人眼中的对方是不一样的，在市场眼里技术是网吧，在产品眼里技术是工人，但在技术眼里自己是科研工作者。换个角度看，在市场眼里自己是超人，在产品眼里市场会吹水，在技术眼里却是美腿。可是，他们在竞争对手的眼中，也许都是“一坨屎”。每一个人都有自己的优点，研发逻辑性强，市场灵活，懂公关，运营则更加接近用户，做事也比较细。 我们彼此都需要放下傲慢与偏见，然后了解和沟通才能更好的分工合作，分工就是每一个人做好自己的本质工作，然后跨进半步就是合作。

理解源于彼此的了解，我们要遵循事物的发展规律，要了解业务的发展规律，要了解技术的发展规律，以及彼此对对方的要求。

以下是业务的自身的发展规律，分为4个阶段：

1. 起步阶段：这个阶段要快速验证商业逻辑、商业idea；

2. 发展阶段：这个阶段需要快速地开拓市场，需要资本的注入，需要大量的钱来做推广；

3. 成熟阶段：精细化运营，提高效率节约成本，还有风险控制；

4. 衰退阶段：需要转型，需要创新，需要快速的退出。

以下是技术的特征与发展规律：

• 提前布局：“业务说我明天就想要，研发说要开发2个月”；

• 反馈修正：”刚上线就有这么多问题”，刚上线才那么多问题；

• 系统观：“我的建议很好却没被采纳”，多方调研与评估；

• 批量化：万一呢？技术擅长于批量化，“万一”的研发成本很高。

以业界为例，微软的产品一般到了V3.0才能用，1.0版、2.0版都不好用，但微软还是要发布。iPhone在2010年之前不好用，Android在2012年时也不好用，但是它们现在都很好用。同样Apple Watch 2现在不好用，我相信以后还是会好用的。整个行业都是这样，如果业务不认识到这一点，不了解技术的特征，不了解技术的工作流程，那自然就会对技术有误解，说不配合他们的工作。

业务规律对技术的要求。在起步阶段要新、要快，只开发核心功能MVP，然后快速迭代，快速验证商业逻辑；在发展阶段要有营销功能、粗放式运营功能，一定要有订单量，做技术才有价值；在成熟阶段要精细化运营、要大数据和分析功能、以及自动化功能。有了数据然后才需要分析，以自动化来节约成本和提高效率；在衰退阶段要转型、需要功能创新，减少系统维护。以上总结为四个字：销量、服务、管控、沉淀。即先以销量功能为主，然后做服务功能，接下来是管控功能，最后沉淀为基础业务服务，如以机+X的形式存在，机票作为基础业务，X作为创新点。

扩展开来，业务规律对其它方面及部门的要求。在人才方面，早期需要创业开拓型，中后期需要管理运营型，不同的阶段不同的情景需要不同的人才；在财务方面，早期宽、灵活，后期要标准化、管控，如果早期就有各种复杂的报销流程，会阻碍公司快速的发展；在法务方面，也是如此；在管理方面，创业阶段要多折腾，要多破多立，当发展到一定阶段乱了才需要管理，如果你一开始就管得过于严厉，可能把它管死了；在流程方面，创业是找路，流程是修路，现在有不少组织提倡去KPI、去流程、去级别，原因就是要创造，先找到路然后才修路。

有时候不是技术不响应，也不是业务提的功能需求不对，而是所处阶段不对。您不能要求一个成年人做小孩子的事情，也不能要求一个小孩子做成年人的事情。一个阶段要做一个阶段的事情，不清晰或产生矛盾，可能是因为没有定好位。

仅仅了解彼此是不够的，技术与业务需要去匹配和融合。那什么是匹配？又如何匹配？匹配是阶段性的匹配，是以时间为轴。先有商业逻辑，然后有产品逻辑，最后才有程序逻辑。如果没有商业逻辑，或没有表达好，研发自然是不知道如何下手。技术与业务步调要一致，把大公司的系统拿过来直接就能用吗？系统是大脑，市场是手，运营是脚，如果只有灵魂，没有手和脚，业务也应该很难运作起来。我们先需要确定一个阶段性业务目标，然后提前布局进行技术研发，最后快速反馈和改进产品，这样才是正确的路径。

先匹配再融合，融合是阶段内的融合，先把大方向确定了，然后在阶段内进行细节的融合。技术与业务该如何去融合呢？方法很多，以下是我们尝试过的4个。第一个是互训，各部门互训，你了解我的工作流程，我了解你的工作流程，互相了解各部门的输入输出；第二个是轮岗，去别的部门轮岗，执岗。做其它部门做的事，做几遍才能真正的了解；第三个是活动，如打羽毛球、户外爬山，业务与技术人员交朋友，鼓励多一些非正式的沟通。第四个是思想突破和自我要求，这是最重要的一点，是思考的提升和自律。

思想突破，改变传统观念，我们借助5个问题来引发不同的思想。

第一个是业务人员要懂技术吗？财务懂金蝶，人事懂打卡系统，研发也不懂这两个系统，所以业务人员也需要懂技术。

第二个是研发与技术的区别？技术是第一生产力，研发中心是技术的重要部分，但不是全部。在互联网时代，技术如同电，这个能用那个也能用，每个人都需要了解技术。

第三个是研发是职能部门吗？什么是职能部门？财务和人事在电子商务公司是职能部门，但在财务公司和猎头公司呢？ IT部门在IT公司是业务部门，但在传统公司一定是职能部门，那电子商务公司呢？

第四个是业务和技术的矛盾能否彻底解决？一山容不得二虎，你家里是谁来做主？简单的调和不能真正的解决问题。轮流执政也是有好处的，特朗普的胜利是工人阶级的胜利，希拉里的失败是精英的失败。良性的矛盾，不同的视角能够促进公司的发展！

第五个是领导说各部门要多配合，那多配合就好吗？配合=匹配+融合，配合有配合不足、配合过渡，配合恰当之分，过多的配合会导致职责不清，交互频率高，效率变低，会产生3个和尚没水喝的情况。过少配合的会有缝隙，恰当的配合则是每人做好自己的，再向前半步。

对他人的抱怨转化为对自己的反思，对他人的要求转化为对自己的要求，业务和技术都应该有一些自我要求，以下是业务方应有的自我要求：

• 在电子商务公司，业务人员也要懂技术，但可以不会写代码。业务经理也需要了解研发的基本流程，梳理并表达好自己的业务逻辑。

• 懂得如何向研发中心提需求和反馈问题，懂得如何借助技术，来提高市场的推广效果和运营管理。

• 业务经理及其以上级别应该每月到研发中心走动一次，至少每季度需要一次。

研发中心应有的自我要求：

• 树立只有业务发展了，研发才能发展的理念。“淘宝”为什么做得那么牛，是因为他们有那么大的体量和业务场景。

• 以服务为导向，强调技术价值的输出，产品没有人用就没有用，因为不生产价值。研发人员应该主动了解公司业务，学习公司业务。鼓励研发的帅哥“泡”运营的妹妹，鼓励跨部门组织活动如羽毛球活动、户外爬山活动，这些非正式的沟通有利于彼此的了解。

• 产品经理是媒婆，在研发部门要说业务的好，业务的难，在业务部门要说研发的好，研发苦，只有当好了这个媒婆，才能做一个合格的产品经理。产品经理每周要到业务部门至少跑3次，呆4个小时以上，到业务部门执岗、轮岗，跑市场，搞运营。

没有配套的市场推广和运营计划，产品基本没戏。没有技术支持的市场推广和运营管理，那是劳动力，不是生产力。所以，只有技术和业务的匹配与融合，公司才有大的发展，科技才能转化为生产力。

谈了这么多，我们再次回到最初的问题，到底是什么在驱动公司的发展？3种不同的看法，3种不同的境界。第1种是老子天下第一，我来驱动，这是我最怕的一种，很难沟通，无知者无畏。第2种是不同阶段不同做法，早期产品，中期市场，后期运营。第3种是投资人的要求，是竞争对手，是行业，是社会需求。竞争对手是友商，竞争对手与你一起前行，逼着你改进。社会需求是企业存在根本, 创业就是要解决别人的一个问题，社会共同的问题，问题越大越好。另外，关于市场、运营、技术哪一个驱动好的问题，这个要看行业，要看业务自身的规律，老板的出身和喜欢，各方力量的博弈。每一种做法都很多成功的案例，以BAT为例，百度应该算是技术驱动，阿里是运营驱动，腾讯是产品驱动，它们都有各自成功的理由。没有标准答案，存在即合理，有利于公司和社会的发展就好。

另外，关于市场、运营、技术哪一个驱动好的问题，这个要看行业，要看业务自身的规律，老板的出身和喜欢，各方力量的均衡。每一种做法都很多成功的案例，以BAT为例，百度应该算是技术驱动，阿里是运营驱动，腾讯是产品驱动，它们都有各自成功的理由。没有标准答案，存在即合理，有利于公司和社会的发展就好。