工程能力提升管理之道

在架构设计上不同层次的架构师在架构抽象上总会有不同的见解，和高p架构师讨论架构往往能上升到哲学层次，什么分久必合 合久必分，什么无法 有法，什么道，法，术，器。

在工程能力提升上不同团队也有不同章法，总之那些过分依赖流程，妄图通过复杂流程降低工程问题的做法我个人都是不认可的，因为繁杂冗余的流程离真正的问题核心远得很，根本解决不了问题。

而且想让一堆离一线开发很久不熟悉工程现状的层级管理者通过审批去发现代码，sql，工程上的问题，你觉得靠谱吗？

在工程能力建设上可以围绕人、技、法、数据方面建设。

人

第一部分是人的方面，工程能力提升的根本在于人（工程师）本身的工程素养提升。即使有好的流程、方法和开发工具，如果开发者本身的能力和工程素养不足，工程效率也会非常低。而且很多简单的事情，通过引入流程复杂化就完全不符合我们“复杂问题简单化”的做事原则和做事方法论。

为了提升工程师的工程素养和工程能力，在招聘时，一定招优秀的工程师。新人入职后，为他们提供工程师能力培养和文化建设的工作坊，比如FB就有理论与实操结合的“训练营”，使新人在短时间内了解公司内部工程开发的流程和规范，建立工程规范意识。除此之外，还有很多培养工程师文化的项目，比如 Hackathon等。

技

第二部分是技术，重点是工程工具平台。硅谷大厂注重开发了自己的 DevOps 工具和管理协同工具，并且把它们连接成为一个从需求管理工具到代码管理工具再到持续交付工具的完整研发工具链。使研发过程自动化，提高效率和质量。

这一部分才符合我们的做事方法论“简单问题标准化，标准问题自动化，工具化”。

但工程能力的保持与提升，只依赖于研发工具是不够的，如果每一个产品、每一个平台都要从零开始开发，或者为了服务于自身产品，而建造了许多功能重复的平台，那么公司整体的研发效能会受到很大影响。为了提高整体的工程效能，还需要做平台的建设与治理。

平台建设包括平台复用和源码复用这两方面。

在平台复用方面，可以对几百个平台划分成若干类别，每个类别都成立一个 TOC 组织来负责规划这类平台未来的发展。

目的就是让这类平台可用性加强、复用度提高，让平台本身的能力增强，以便让每个业务方能够更快速地使用平台去搭建自己的业务，提高工程效能。

但平台复用会带来一个问题：

如果多数平台逐渐收敛成少数平台后，许多需求都会涌向这些平台，导致平台研发团队不能按时、高质量完成所有的需求，从而使研发效率下降。

那怎么在平台化的基础上去做更好的工程复用呢？

在平台化治理的过程中，平台是否能够达标，有一个考察点是它能不能实现内部开源。如果一个平台的 API 已经对外开放，并且又做到了内部开源，能够让其他团队贡献代码协作开发，它就是一个优秀的内部平台。

法

第三部分是方法，主要是研发方法和流程的整理及运用。团队使用一致的方法和流程进行开发，并不断地迭代优化，他们的工作效率会越来越高。可以把管理实践和工程实践做了细化。

管理实践部分，有一套“工程方法 +”课程体系，把敏捷软件开发、精益创业思想等先进方法，经过实际产品线和团队的充分实践，提炼出了融合 " 方法 + 工具 + 案例 + 场景 " 的标准化知识体系，并进行了全面落地。

我之前说过我们这边有我比较喜欢的技术leader，两个人有完全不同的做事方法论，一个重工具，一个重流程。但是两者都不是为了工具而工具，也不是为了流程而流程，这是真正的区别。

工程实践部分，可以建立一套完整的从需求到上线的各阶段优秀实践的集合，并对外发布。可以建立《工程能力白皮书》，详细介绍了每个研发阶段可能使用到的工程实践及具体的操作步骤。

研发团队可以按照这样的标准去实践开发，促进优秀工程实践更快速落地。

数据

人通过学习方法来使用工具，这会产生很多的数据。如何更好的使用这些数据帮助工程能力进一步提升呢？

通过统一的研发平台 — 效率云收集大量的研发数据。再将每个团队的工程能力或工程实践达到的程度可视化出来。以便团队看到工程能力的变化，进而自主改进工程实践，提升工程能力。

工程能力分数的换算也可以帮助研发团队更好地确定下个阶段的目标，这个分数包括项目管理能力、质量保证能力和持续部署能力，每个人根据自己的现状去设定工程能力改进的目标。这样整个公司优秀的工程实践的数量和工程能力都得到了很好的提升。