题图来自于NextDay
今天话题还是要从IT业界古老的「业务与技术的矛盾」说起。
业务部门迫切需要提升业绩或者开拓新业务，加派人手、简化流程、创意营销、客户关怀，都是方法，但这些似乎都需要时间，很少能立竿见影。
有一种方法，在业务人员看来，属于能即刻见效的，就是「开发或改造系统」，让系统更智能，提升工作效率，琐碎的活儿最好都由系统完成，只有疑难杂症才需要人工介入。这样的想法也合理，到现阶段为止，机器的角色一直是作为人类的辅助工具，不犯错，不犯困，不情绪化、7Ｘ24，当然是系统健壮稳定的前提下。虽然这只是机器的初级阶段。
既然寄希望于系统，希望立竿见影，那么，留给技术部门的时间就变得很仓促，再加上，并不希望机器「宣兵夺主」，于是系统的设计必须按照现有的工作流程严格执行，系统的角色设定为将人类从繁琐的事项中解放出来，比如原来需要人输入的，改成自动填充；原来需要人工打开某个页面点一下的，改成系统自动打开并点击；原来需要人工统计的数字，改成由系统自动核算。
类似这样的需求，请注意，当这些需求实现之后，原本的1-2-3-4-5步还是1-2-3-4-5步，只不过其中有几步从人工操作切换成了系统操作，从业务流程来讲，并没有进行简化。没有简化的流程，也会让业务部门认为这些都是非常小的改动，「就是加几个按钮嘛」「就是把数据抽取出来嘛」，很简单啊，为什么需要那么长时间？
而在技术部门，眼里是一张张的各个系统的架构图、流程图、数据结构图，如果最初的架构没有规划好，即具备灵活的可扩展性，加上各个系统之间不可避免的或多或少的交互，即便只是「一个按钮」，也可能引发牵一发动全身的轩然大波。于是，对技术部门来说，「不动系统」或者「少动系统」才是最稳妥的，当然，这只是埋在心里的小心愿而已，现实并不会允许。
于是，矛盾就产生了，业务期望「快系统」来提升效率进而提升业绩，而技术则以保障系统稳健运行以及投入产出比为考量，很多时候会认为「杀鸡焉用牛刀」，有与没有系统并没有数量级区别的，何必兴师动众？
看着像是由各自为政引起的矛盾，其本质原因还是在于双方专业背景不同引发的「理所当然」，业务不懂技术，技术不了解业务，而又站在保护各自领地的角度上，互不相让。于是，「产品经理」「项目经理」「业务分析师」应运而生，尽管职责不尽相同，但本质是一样的，即，作为业务和技术的沟通桥梁，面对技术，将业务的诉求转化成可行的技术方案，面对业务，将技术的高深莫测转化成通俗能懂的业务语言。理论上来说，如果这个角色对于两个领域都相当熟悉，确实可以化解其中的矛盾，然而现实也同样残酷，这个角色在很多公司沦为了一个「夹心饼」，更惨一点「传话筒」，排除个人能力问题，公司的授权和体制也是很关键的因素。
为什么会这样，根本的原因在于耳熟能详并没有什么用，只有脚踏实地，亲手去尝试过，才有可能搭起这座桥梁。其实，在我看来，最直接的方式，不是在这两者之间再塞一个沟通的角色，而是应该直接让这两者互换角色，任何事情，道听途说永远都不会有切肤之痛，只有当你身处其中，才真正有机会感同身受。现在也有公司正在这么做了，让技术部门去业务部门轮岗，实际去体验业务工作，简直堪比「做苦力」😂，不过让业务去技术部轮岗的倒还没听说过，我想应该更加「苦」吧 —— 迷之自信😄
说了这么多，我是站哪边的？作为技术，早些年深受业务需求之苦，当然站在技术这边咯，业务提的需求有的时候真的让人无力吐槽啊。但有些需求，在我们看起来无足轻重甚至难以理解，实际去看一看业务发生的环境和场景，竟有种说不出的「同情」，而此时你会发现，他们所提的需求远不止所承受的压力，换句话说，由于并不了解技术能做到什么程度，所以提的需求其实并不能真正去解决他们实际遇到的问题，而每每这种时刻，我都会觉得技术是多么美好的东西，能够将这些「无助又无能为力」变为「多助又各显神通」。
回到开头提出的千古难题「业务与技术的矛盾」，抛开政治经济权力纷争等因素，「彼此不了解」是最关键的原因。不了解就会凭想象去猜测，不了解就会被固化思维所限制，不了解就很容易激化矛盾放弃沟通。但老话怎么说，要去改变别人是很难的一件事，那么就从自己开始拥抱变化吧，作为技术，不再闭门造车，而是真真切切地融入到业务中去，利用技术这把双刃剑，披荆斩棘，杀出一条阳光大道来，如果得以实现，一定成就感十足。（关于工作的成就感，看这里《工作的意义》《工作的意义 续篇》）
让技术融入业务，浪费时间？未必。研发的小朋友们自从跟着商务去了一趟客户的业务现场之后，回来以后竟是满满的同情，开始积极主动地修改产品中不那么人性化的操作了。
有时候，很简单，抛开自己的职位、身份，只是设身处地地去想一下，答案就很明了了。比如，一个很简单的例子，APP上要做一个选择控件，大概有4-5个选项，iOS上原生的做法是：点击->进入列表->选择->返回（见下图上半部分），当我坚持原生体验和做法时，客户让我看了他们实际的工作负荷，最后修改成了下图下半部分，实测效果很好，这个有十几个选择的页面，业务人员熟悉之后几乎在十几秒内就可以完成，成功地将瓶颈又前端转到了后台😂（这就是我在《工作的意义》中提到的瓶颈问题）
从图上来看，右侧图似乎更容易实现，工作量更小是吗？切记不要想当然，以及 不要「闭门造车」（终于点题啦），只有当我们对这个领域足够熟悉的时候，才有资格去评价。
旧文参考：
发送给作者