我的同事王健最近写了一篇文章——《从汽车贴膜看专业团队》。看了之后感触良多，特别是文中提到的现场管理和全功能团队两点。我有一个观点，说到专业性，传统行业比我们IT行业要强得多。从这篇文章可以看出，不管是管理人员的现场管理能力，还是全功能团队中一线人员的全栈能力，传统行业都比我们要强一些。相信有人会有些不服，不管什么现场管理，全功能团队我们也在做呀。说的没有错，但是，在IT行业里还真不容易找到这么专业的一个团队。而在传统行业里，这种水平的一个团队已经越来越常见了。这是为什么呢？按说大家都是人，通常来讲，IT行业的人能力素质不是还高一点吗？在我们这个行业中，专业团队不是应该更常见吗？虽然我们不一定要比你强，但是也不会比你弱得这么明显啊。当然，一方面是由于我们这个行业的工作比较复杂，不容易做到全栈，但我觉得更重要的是，IT行业属于知识工作，知识工作者的现场非常不明显，极难做到现场管理。我们IT行业的管理者，不管是项目经理，产品经理，还是技术领导者，大家也基本都和团队坐在一起。但是坐在一起，并不意味着就能够真的在现场。我们看到在那个贴膜团队里，团队领导只需要看一眼，发现有气泡，就知道质量有问题。也就是说，在传统行业进行现场管理的时候，问题都是非常直观的，非常容易发现。在软件行业想做到一点就难的多，记得几年前我的同事熊节也曾经写过一篇文章，文章的核心洞见就是软件开发的现场在代码里。这个想法在ThoughtWorks有很多拥护者，公司里有很多人提出过类似的观点，于是我们的很多方法就是构建于这些类似的观点之上。然而，如果我们想要追求IT工作者开发效率的极限，这个洞见还不够极致。经过几年的工作，我发现，代码只是软件开发工作的第二现场，软件开发工作的第一现场，在语言里。这里说的语言，不是编程语言，也不是广义的人类语言，比如汉语、英语。指的是我们在从事软件开发工作中所使用的一系列术语和相关的一系列呈现方式和沟通工具。借用一个技术术语，我们所说的语言是一套仅供软件开发所有相关人员使用的、组合的DSL，DSL全称：Domain

不用担心，这不是发生了意外，而是在做“新车去异味”项目。而这个一头扎进充满烟雾车厢的人就是这家店的老板。是的，他还是我上面提到的四名“工人”之一，分别完成了缝方向盘套，新车除味和右侧的贴膜工作。

在方案环节，架构师根据客户的要求和痛点，基于自己的知识储备设计技术解决方案。他是如何分析客户的要求和痛点，他的知识储备是什么，组织里的其他人不一定知道，于是不同架构师提出的解决方案就很可能不一样。

iPhone用户赞赏专用二维码点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。

我们与A记之间的故事是从2010年底开始的，那时候，所有的团队在本地做构建，然后把RPM包发给运维团队，运维团队把RPM包部署到数据中心里去，部署过程基本上是手动完成的，开发团队与运维团队完全分离。

即使没有严格的绩效考核过程，作为管理者你也能够知道谁做得好，谁做得不好，所以作为管理者，在践行敏捷价值观和原则的同时，照样可以适配传统的绩效考核来得到结论。而且，除了基于绩效的薪酬方式PFP（Pay