读过第21期技术雷达朋友会注意到它的第四个主题叫做“软件开发是一项团队运动”。相信对于很多人来说，这个主题看着有些奇怪。
首先，“软件开发是一项团队运动”并不是一个新鲜概念，现有的绝大多数软件背后都有一个或多个开发团队，几乎每一个人都多多少少懂得团队协作，软件开发管理乃至软件架构的主要关注点之一就是促进协作减少摩擦。为什么要再一次强调软件开发是一项团队运动呢？
其次，十倍工程师一直是开发人员的心之向往，我的前同事郑晔在极客时间上开了专栏，讲“10x程序员工作法”，颇受欢迎，我自己也订阅了跟着学习。那么为什么这里偏偏要说“我们特别不提倡十倍工程师”呢？
技术变迁让软件开发变得更加复杂
先从我们所处的环境说起。
我入行快八年了，这八年IT行业的风口可谓层出不穷，而这也带来了软件开发相关角色的细分。前端技术的成熟带来了前端开发人员、移动平台的流行催生了移动开发、云平台兴起辅助了DevOps运动、大数据的火热引进了数据科学家和数据工程师，而如今物联网也正在预热当中。技术之外，软件应用间的激烈竞争使得我们越来越强调用户体验，专业的用户体验设计师也成了团队的标配。
回想起来，八年前我的团队除了一个PM和一个BA，其余清一色都是开发人员，大家在一个基于SpringMVC的单体上工作，没有前后端之分，每个人都掌握Java和JavaScript，或多或少懂一些CSS；而如今我的团队已经清晰的分出了前端开发、后端开发，引入了设计师，也会有安全专家和DevOps轮转。
软件行业已经越来越复杂，这不仅体现在它的应用面的扩大，所处理问题的复杂性的提高，还体现在它所涉及的知识面的扩大。软件开发早已不再是几个会写代码的工程师就可以搞定的活动了，为了提供更好的服务，软件开发团队常常需要顺应“潮流”引入新的角色。而由于所有的团队合作将最终体现在产品上，新角色加入之后该如何与原有团队协作便显得尤为重要。
引入新的角色实际是在引入新的知识体系和语言
引入新角色的方式有很多，最常见的是成立一个新部门，如设计师团队、DevOps团队。
从运营的角度来说，成立独立的新部门恐怕是最方便快捷的：它有独立的预算、排期、组织结构和KPI，统一对接所有开发团队，对现有团队结构影响最小。但它的缺点也非常显而易见。
当开发团队需求量变大时，效率会变得低下，当产品出现问题时，追责成了部门之间的游戏。在这样的环境里，开发、测试、运维、设计、甚至产品团队都是一个个独立运转的团体，它们互成黑盒，没有人直接对最终产品负责。从另一个角度，这也会带来严重的知识壁垒。
软件开发是一个知识生产和消费的过程（详见八叉说《软件开发管理为什么这么难》）。软件开发过程中所有角色都是在将自己的专业知识与业务知识相结合，产生新的知识，并交由下游去消费（如测试、运维）。因此在这样一个过程中，知识的流动速度（即消费速度）是衡量某一个角色的效率的关键。
这也是为什么被解读成只爱写代码不喜欢与人合作的“十倍工程师”会被放入暂缓环，因为它所带来的知识壁垒会抵消掉暂时的开发效率的提升。
“十倍工程师”虽然是在针对开发人员的效率，它的逻辑可以套用到任何一个角色身上。每当引入一种新的角色，我们实际上都在引入一个新的知识体系和语言，如果不与原有团队的紧密合作，很容易形成知识壁垒。
至此，我们应该就能理解为什么如今已经流行开来的微服务架构背后，强调的是按照领域来组织团队，同时也就理解“Product over Project”为什么强调产品应由全功能团队生产并维护。按照业务划分团队，组建小的全功能团队，构建产品文化，强调团队协作，是现代软件开发的正确打开方式。
软件开发是一项团队运动
一直以来，IT都是被当作一个成本部门，软件被看作是如同办公用品一样可以购买的能力。在互联网的刺激下，管理者们或许已经意识到了IT对于自己业务发展的重要性，逐渐将IT视作企业的核心部门，但由于对软件开发的认知不够，仍然用传统的管理手段来对待这一复杂的知识生产和消费的过程。
技术的发展，能让世界更加简单高效，却也让软件的世界变得越来越复杂。技术变化越快速，我们越要坚持一些简单的原则，比如让软件开发回归到团队协作中，而不是简单的在已有结构上堆砌新的能力。
