本周连续作了两场演讲，基本思想都是从技术团队的工程师文化入手，谈谈如何提升效率与度量价值。下文是我对演讲内容的总结，限于篇幅，还有许多未尽之意，期待能和朋友们有更多的交流。
写在前面
差不多在10天前，我受邀在极客时间部落发起了一个讨论。
谈到工程师文化，有的人说自由、有的人说协作、有的人说沟通，有的人说好的职业素养，有的人说是追求精益求精。其实这些都对，那么什么是工程师文化呢？
参考文章：如何打造高效团队？
在理解这个问题之前，我们先看看时代的变迁，以及行业的发展。在过去的200多年间，人类经历了三次工业革命，如今正迈向第四次工业革命。
第一次工业革命，我们有了蒸汽机，开创了以机器代替手工劳动的时代；第二次工业革命，福特把流水线做出来了，有了流水线之后，人类正式进入了工业社会。中国在第三次工业革命（信息技术革命）中的表现是非常突出的。举个金融科技的例子，现在大家出门都不带现金。如果钱包被偷了没关系，手机被偷了就很麻烦。
前几次工业革命的意义在于极大地提高了生产力水平，从而改变了文化，经济与生活。第四次工业革命则提供了无限可能：全新的思维方式；全新的生产力、生产方式；全新的生产者和全新的知识获取途径。 数字化会是这个时代的重要特征。
我们再来看看行业的发展。
这个世界上有三种商业公司：
销售驱动型的公司。这类公司以运营和营销见长。技术对于他们来说，更多的是为了支持大规模的营销活动，以及成本上的控制。
产品驱动型的公司。这类公司以创造能提升用户生活体验的产品见长。技术对于他们来说，除了支持大规模的在线用户之外，他们会更多地去寻找那些为了增强用户体验，提高整个业务流程效率的技术创新。
技术驱动型的公司。这类公司希望通过强大的工程技术来创造有颠覆性的东西，用各种自动化的技术取代体力劳动。比如：近代的蒸汽机技术取代了大量的人工，数字技术让线下走向了线上。
这三种公司都需要强大的技术支撑。我们今天的生活相当地依赖程序员，没有程序员，我们恐怕都不知道如何生活了。
所以时至今日，每个从事软件行业的技术人员都应该感到幸运。我们不但选对了行业，也生活在了正确的时代，可以感受到前所未有的刺激和变化。所以，我们只需要思考的一个问题：我是否待在了正确的地方用正确的方式做事？在这个背景下，我们再来理解工程师文化，也许可以快速达成共识：工程师文化不是一个问题，而是一个常识。
简单说来，我把工程师文化归纳为两个方面：“效率” 和 “价值”。
效率：建设团队空间，提升团队效率
Martin Fowler在他的博客（Team Room）中介绍了对敏捷开发团队所应采用的“团队空间”的观点。在物理上，我们通过可视化的设备、Always On这样的工具、以及大量的白板为高效协作提供支持。设备和工具的推广和使用，这是“术”的层面。
除此之外，团队契约的建立也很重要，比如PIPELINE的提交纪律。
利用团队空间，鼓励团队更多地学习和分享也是提升效率行之有效的方式。下面举两个具体的例子:
Session墙：团队初期，要求团队成员频繁地做session，在团队内部逐步形成学习和分享的氛围。一段时间后，不仅有人愿意分享，而且有人主动喊出想要知道某方面的知识。于是为了将知识分享的供需可视化，可以建立一个session墙，分成两部分，一边由团队成员写出来想要了解的技术知识，相当于是session的需求方；另一边写着根据需求而安排的session，相当于是session的提供方，这样清楚明了，便于跟踪。在项目不同的阶段session的内容会有明显差别，比如早期的session主要是关于项目中用到的技术，目的是为了快速学习和掌握必要的技术以便顺利进行开发。
成熟的学习型团队还会通过“有意注入错误的方式”来有意识的进行组织学习。比如奈飞会注入“数据库不可用或者云环境不稳定等错误”到生产环境， 让团队从错误中学习。
技术能力雷达墙：可以利用“技术能力雷达墙”来标明项目相关的各种技术，评价当前的团队技术能力状态，并且设定每个里程碑的能力成长目标，到了一定阶段再来评价团队技术能力是否达到了目标。
参考阅读：《团队空间：敏捷团队的办公室设计》
建立团队契约，利用Session墙和技术能力雷达墙来促进学习和分享，这是“法”的层面。
工程师天生是追求效率的。有人认为程序员花大量的时间做自动化的工具，还不如人肉的效率高。比如，写自动化的脚本花6个小时，而重复做这件事200次只花3个小时。有这样理解的人根本不理解工程。因为一方面，这个工具可以共享重用，更多的人得以从中受益：这次我花6个小时开发这个工具，下次只用1小时修改一下就可以用在别的地方，这是着眼于未来而不是眼下的成本。
更为重要的是，这是一种提升效率的文化，它会鼓励和激发更多类似的事情发生。如果因为一位程序员花大量的时间开发自动化的工具，而认为这个程序员没有效率，对之批评甚至惩罚，那么我们就扼杀了提升效率的文化。塑造提升效率的工程师文化，这是“道”的层面。
价值：关注研发效能，保持技术精进
研发效能的本质是持续的价值流。在软件开发中，价值流的直接体现是从想法和假设到软件功能上线并产生客户价值的过程。
从左到右的流水线这一理念来自于制造业，为了让流水线尽可能快，生产周期可预测，制造企业通常会聚焦在如何让流水线更平滑，因此一些显而易见的手法经常被使用：比如减少在制品（WIP)；尽可能早地发现次品，从而阻止对下游生产步骤的影响。很多理念和实践在软件行业也是通用的，然而一个巨大的区别是：制造业流水线是物理可见的，软件开发活动则要抽象得多。软件开发活动本质上是复杂的系统工程，复杂系统中的事务都是相互交织在一起的，带来的问题是一个异常发生后很难界定其影响范围并快速分析根因。
人类应对复杂系统最有效的手段是探索和反馈，因此，从左到右流水线的每一步反馈就尤为重要：也就是说，我们不仅需要从左到右的流水线，还需要在这个流水线上构建从右到左的反馈，而每个环节的指标收集是从右到左反馈的基础。
管理学之父德鲁克曾经说过：“如果你无法度量它，就无法改进它。” 4 Key Metrics是行业内接受度很高的度量能效的指标：通过这样的度量指标，使得从左到右流水线的每一步都能得到评价和预测。
部署频率
对于您正研发的主要应用程序或服务, 您部署代码的频率如何？
交付前置时间
对于您正研发的主要应用程序或服务, 您的交付前置时间如何（即从代码提交到代码成功在生产环境中运行需要多长时间）？
平均恢复时间
对于您正研发的主要应用程序或服务, 在发生线上事故后（例如，计划外宕机、服务受损）通常需要多长时间才能恢复服务？
变更失败率
对于您正研发的主要应用程序或服务, 多大比例的变更会导致服务降级或变更后需要采取补救措施（例如，导致服务受损、服务中断、需要部署修补程序、需要回滚变更）？
在DevOps横空出世之前，开发团队和运维团队是对立的，其KPI也是对立的，这点在《凤凰项目》中有很多生动的故事。对开发团队来说，快是其KPI；对运维团队来说，稳是其KPI。快和稳看起来是对立的，比如运维团队为了服务稳定，希望发布的频次尽可能低。因此4 Key Metrics给我们的第一个启发是：打破研发和运维的“墙”，快和稳得以通盘考虑。
第二个启发：4 Key Metrics能够让团队的技术治理更有方向性，如果某项技术治理对于快和稳没有帮助，那么说明团队投入的工作量没有给客户带来价值。这样的技术治理很有可能就是自嗨。
关注度量指标的变化，分析其变化的原因，我们得以持续不断地设置更高的目标，以此来牵引团队研发效能的提升。这是4 Key Metrics给我们的第三个启发。
写在后面：刻意练习
《一万小时天才理论》一书中针对“刻意练习”讲到了三个观点：精深、激情、伯乐。第一，要想在某一方面有所成绩，需要有精深的练习。这里说的不是普通的练习，而是有效率的刻意练习；第二，有对这件事情持之以恒的激情，无论外界如何变化，激情一直都在；第三，要有赏识我们的教练给予指导，给予及时、精准的反馈，这样可以让练习更加高效。个人认为，无论是提升团队效率的“道、法、术”，还是以“4 Key Metrics”为纲的效能度量，唯有坚持刻意练习，方能持续产生价值。
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
