谈谈不同技术团队的协作

互联网公司或者软件公司一般都会有多个团队，产品，开发，测试，运维和运营，软件系统的持续完善必须是建立在团队协作的基础上的，团队协作越顺畅，协作效率越高，则公司的市场反应能力越快，客户满意度越高，公司的竞争力也越强。现实情况下，团队协作一直是一个老大难问题，所以才有太多的互联网行业故事，产品和开发吵架甚至动刀子，国外还甚至发生了资深程序员不满初级程序员不遵守注释规范，枪杀同事的事件。

下图是团队协作当中常发生的事情，被人画成了漫画，也怪搞笑的。

首先讲一个著名的心理效应理论，邓宁-克鲁格效应，也叫”达克效应”。

多数新入行的人都会经历巨婴阶段，在这个阶段，自己不知道自己不知道，在软件行业，其实很多即使工作多年的人会一直处于这个状态，经验不一定和时间成正比，聪明的人会在短时间内快速跨越绝望之谷，不思进取的人会始终在愚昧山峰。

团队协作不顺畅的根源就是认知问题

很多时候，我们只知道自己领域的知识，但是不知道协作方领域的知识，导致双方沟通常常出现错位沟通，协作成了牛头不对马嘴，讨论沟通会成了抬杠会议，时间白白浪费，问题没有得到任何解决。五环连接怎么能够牢固呢？必须有贯穿和一定重叠，如果只是把圆环的边轻轻接触，怎么可能牢固呢，团队协作是一样的道理。

为啥产品总觉得开发简单呢？因为产品总是思考当前的提出的单一功能，他不会考虑在编码环节是需要和之前的模块进行协同衔接的，而且他只是考虑了主流程，但实际上最烧脑子的最费时间的是太多的异常流程，而对这些异常流程系统化处理才决定了产品的稳定性和可靠性。开发为啥爱说”在我这里明明好的”，因为开发不会站到测试角度思考问题，不会站到客户使用场景考虑问题，因为他根本不了解运营同学那边的痛。我一直提倡开发需要具备产品和测试思维，具体分析请您参看”程序员要有产品和测试思维”，”测试是对思维严密性的考验”，”为什么讲国内软件开发有90%以上浪费”。

团队协作案例说明

因为研发部门是为业务服务的，所以常常是站在一个被动和弱势的位置，常常容易被业务部门指挥的团团转，而且需要无条件服从，产品然后又把这种随意和混乱传递给开发，开发的计划常常被打破，搞得开发无所适从。这些协作混乱问题，最后导致开发积极性不高，喜欢互相推卸责任，甚至产生了自我保护意识，事情能躲就躲，免得承担责任。之前看到论坛上，一个程序员讲，自己发现问题也不讲，讲了大家觉得多管闲事，老板不领情，等最后发生问题了，挺身而出解决问题，反而得到老板的嘉奖。这就是人们常说的，告诉你预防疾病的医生，人们不觉得是好医生，到后面得了重病，散尽家财治好了病，却认为是最好的医生。在一个昏头技术领导下面做事，这种事情天天发生也不奇怪。

软件开发不是简单重复性劳动，和工厂工人管理，建筑工地管理完全不同，我遇到过一些老板希望能把团队的开发工作量化，比如这个功能2个小时，那个功能6个小时，简直太不懂这个行业了。一些公司还制定了KPI考核，晕，他们殊不知这种僵化的KPI正在杀死团队的创造力，详细分析，请您参看”KPI和过多分工正在杀死开发团队”。

运营团队和开发团队协作可以分4个等级。第一级，拖延交付型，技术团队对业务认知不足，自己能力认知不足，导致时间预估误差很大；第二级，按时交付，质量一般，完全是外包公司的水准，后续测试发现成堆问题，发现一个修改一个，典型的敲一下走一步；第三级，按时交付，按要求交付，质量优秀，你要求做5分，做到了4分或者5分，后续测试没有发现愚蠢类型缺陷，但会有偶发的难发现BUG；第四级，不但完成了要求，而且主动发现产品的设计缺陷，提升了研发效率，而且提出己方的建设性意见，产品超预期完成。

什么是超预期完成呢？比如，运营提出了一个需求，希望使用EXCEL表格导入数据，然后给你一个样式数据。第三级的开发，理解沟通了一下需求，按照要求完成了需求。什么是第四级的做法呢？了解需求以后，开发会根据自己的经验，问运营，你平时导入的数据多吗？运营想了想说，有时候还是蛮多的，比如几千行吧。开发会说，要不我给你做个数据导入校验吧，如果导入的数据有错误的行，自动分离出来，把好的数据导入，把错误的返回给你，并且指出错误的原因，这样你就可以快速发现数据问题了。这就是四级开发的回答，会更多的为对方考虑，利用自己的专业知识，主动解决潜在的问题，因为运营不懂编程，很多时候不知道，很多事情是程序可以自动完成的。

再讲讲开发和测试协同的例子，现在自动化测试非常流行，但真正能够做到位的少之又少，尤其是UI自动化，大家都觉得很难实现，即使勉强实现了，维护成本太高。其实，大家觉得难，不代表不能高效低成本实现，实现的障碍就在于软件的整体结构设计和团队协同作战能力，具体的UI自动化测试案例，请您参看”APP的UI自动化测试”。网上经常有人问我，他们能不能实现自动化UI测试，我想说的是，不行，因为不具备条件。这个案例需要开发端的组件化，测试端的组件化，还有统一的规范的UI命名标准，这些条件绝大多数公司都是不具备的。

开发和运维怎么实现紧密配合呢？大家知道，自动化运维是非常流行的，还有DevOps，现在很多公司一般只能做到初级的自动化运维，就是说，自己开发的系统没有真正的实现自动化运维。所以，要实现这个目标，开发软件设计阶段就需要考虑到运维的需求，而且为了开发效率，节约成本，还需要考虑和现有成熟的运维工具的融合，实现对开源工具的二次开发。

所以，团队之间协作是一个全局概念，需要有非常强的全局把控能力，同时各个团队也需要很强的执行能力，真正做到，不容易，需要持续优化磨练。即使在开发团队内部也存在协作问题，前端和后台协作，APP前端和H5前端的协作，具体这些分析，请您参看”程序员要有产品和测试思维”和”敏捷开发怎么真正实现落地”。

提升团队协作的手段

下面讲讲提升团队协作的一些手段，这些手段要持续使用，不能指望一口吃个大胖子，毕竟肌肉不是几天练成的。

1. 定期的代码review和技术交流会

很多老板非常吝惜这个交流时间，认为这个太浪费时间，确实，这种讨论会常常要消耗一天的时间。磨刀不费砍柴功，刀子过于锋利，会更容易折断，单向追求工作时间，只会带来相反的结果。很多项目前期强调快快快，然后逐渐陷入发展泥潭，后期花费的时间远远大于前期的计划时间，具体的论述，请您参看”评“[高质量软件生产成本更低]”。而且，能力越高的团队，效率越高，发现错误速度越快，越有能力把问题消灭在萌芽状态。但能力的提升不是CTO讲几句话就能实现的，特种部队是单纯听课实现的吗？代码review和技术交流会是对过去的总结，有总结才有积累，否则就成了狗熊掰玉米。而且，交流会让团队之间更加了解对方，让后续的团队沟通更加顺畅，是沟通的润滑剂。

2. 培养文档流程图能力

团队沟通要有统一的语言，就和特种部队需要手势语一样，统一语言需要简洁易懂，协作的统一语言就是文档，流程图，类图和数据库表图。很多开发觉得自己很牛逼，比产品厉害，总是拿自己的专业对比对方的非专业，但真正超一流的开发是懂得怎么和产品测试团队交流，能够通过简洁的文档和图表表达出自己的思路，捋清楚自己的思路。关于这个方面能力的培养，请您参看”为啥开发的文档能力是核心竞争力之一”。文档和图表的目标不只是给自己和开发看的，需要让测试，产品甚至运维都能看懂。

3. 提倡全栈能力，但不是全干

全栈确实比较难达到，但不代表不能，不是每个士兵都能当元帅，但拿破仑也讲了，不愿意当元帅的士兵不是好士兵。全栈对于不同岗位的人含义也不同，全栈是希望去尽量了解自己的队友，逐步具备全局观。全栈不是全干，不是否定功能划分。之前有些老板希望能让后台代替运维，让开发代替测试，这也有些走极端。有些后台可能是懂些LINUX命令，但毕竟不是专业选手，我也很懂LINUX，尤其是底层原理部分，但运维的事情，真干不了，那么一大堆的命令，怎么可能做到熟练，解决一个问题花几个小时学习操作手册吗？这就和我们去餐厅吃饭，餐厅老板说需要去买麦子，然后磨粉，然后再做面似的。我不能做运维的工作，但很多时候，可以给运维做指导，因为我更懂原理，更懂开发，更懂全局分析。就拿运维来讲，现在自动化运维流行起来，运维也必须具备开发的能力，所以，综合能力才是一个团队的最大最可怕的竞争力。

总之，团队协作是一个全局工程，当然协作的总教练是非常关键的，就像超级一流球队需要一个好教练一样，关于CTO的论述，请您参看”技术领头人需要全才而不是专才”。

希望看到更多的团队关注协作，关注效率，有同感，请您关注和帮我转发。