2.7日有机会现场参加了QCon大会，收获不少，记录一下。

参加的是研发效能专场，上午场主要是围绕云端编码相关，偏工具使用方面，所以只听了下午四场研发效能活动相关的内容。

相通之处

目的都是在面临着公司规模不断扩大，研发效能必然下降的背景下，如何做好管理，达到保持现有效率，甚至提高的目标。流程也大致类似，从过去小团队各自为政，各出各的工具、流程、实践转为公司统一化，通过最佳实践、流程、工具、度量指标四个方向一起下手，最终形成自己的体系，并解决掉各自面临的问题。这其中，第一步也是最重要的一步，成立研发效能专家组，像敏捷团队一样，这个小组应该是懂整个研发过程全流程的全职能小组，包括但不限于需求、开发、测试、交付的管理，以及敏捷、DevOps、精益、度量等方面，同时有一定权力的领导参与其中，从某种意义上讲，这个小组和公司级研发效能的成败息息相关。

上述内容，和很多公司的开展出发点、方式差不多，接下来分别记录各自的不同点。

金山办公：超大规模 C++ 项目研发效能管理

问题

金山这次面临的问题是，作为大规模C++交付团队来说，想做到同样的好的交付效果，比同规模的Java项目，要考虑的更多。首当其冲的就是编译时间过长，其次是产品常见的兼容性问题，比如Windows、Mac、个人版、企业版，可能在某个版本下好用的文件发给另外一个人，就不好用了。另外就是给一个如此旧的产品开发团队，找到一个适合当下的管理模式。最后，该改革领导是空投的，打破团队原本的舒适圈所面临的困难可想而知。

解决思路

分阶段开展工作。

第一阶段：技术平台的优化。优化编译构建，大幅度缩短时间，这个对开发人员来说感受很深，直接获得收获。其次搭建出一站式DevOps平台，这个也是见效最快，最早开始做的方法。通过这个阶段工作的开展，让效能先提升一大块，同时获取了团队的信任，这个很重要。

第二阶段: 管理模式的优化。包括分支模式转为主干开发，解决多版本，交付测试跟不上及兼容性问题。其次结合第一阶段引入的工具，开展流程优化。最后，建立专业的PMO团队做好流程管理。基于第一阶段获取的一线人员的信任，团队对该阶段带来的额外开销的容忍度很高，配合力度高。

第三阶段：组织结构的优化，包括人员管理和技术管理的分开。主要目的是，让专业的人干专业的事儿。在别的公司里，高层常常本就不是技术出身，在金山这里比较特殊，高层领导包括CEO都是从金山程序员干起来的。由于作领导后，碰代码少了，技术必然慢慢跟不上最新的时代发展，为了避免他的水平成为业务线的天花板，就不再让他参与技术相关的工作，比如让专职技术的大牛组成公司级技术创新团队。

总结

金山的转型还是有打法有套路的，先解决一线开发人员问题，而不是先解决领导拍脑袋定的目标。其次在过程中，不断发展核心工程师的参与，降低阻力。最后也是最重要的，研发效能的提升是持续开展的，不是今年一锤子买卖搞定了的。至于工具先行，这也是我很认可的，一句反敏捷宣言 “工具高于流程和互动”，是最容易拿到转型一血的，然后再做后面的。

德邦快递：IT 效能提升的建设路径与实践经验

问题和解决

管理和流程精益化不足方面。一是公司主要是项目制，导致公司很难从每个项目做好制品和经验的传承，交付成本较高。为此，改革方向为尽量多转为产品制。当然了，不可避免地还是会有一些项目，这都是基于特定原因而开展的。二是流程节点冗余，比如一个流程下去，要多个领导审批，而往往只有其中一个领导是进去看具体内容给审批结果，其他人都是看到了就点同意，这就形成了浪费。解决思路是减少不必要的审批点。同时，流程本身可能就是浪费，指定的流程一定要有价值，考量的方式就是多少人真正使用这个流程，可以的话，也去收集反馈和推算收益。此处我们也应该有个思考，研发效能提升的各项活动，是否真的有收益，还是本身就是个浪费？我们度量了别人，是否要度量好自己？

平台能力不足方面。一般就是两条路线，自己做，或者从外部采购。德邦是综合考虑后，选择了某个云厂商（为了避免广告嫌疑，不给具体名字了）。这也是这次分享的四家中，唯一的一个直接从外部采购的案例。直接采购的成本要比自研低，但是也面临个问题，个性化不够强。当时举了个例子，工具的需求管理层级是Epic-Feature-Story三级，而公司本身业务只分两级需求，那么改工具还是改自身，如何花最小的改动代价完成一致性？类似的点比比皆是。这里不是说外购工具不好，而是这条路也要有人一点一点的趟平。

研发效能度量不完善方面。转型初期这个一般都是不健全的，而通过上述已经外购了一站式平台，里面自带一些度量指标。经过研究发现，这些度量指标不能直接使用，这是因为各公司的情况不一样，观察的角度和面临的问题不一样，要关注的指标项目就不一样，同时，不同公司对指标的理解也不一样。所以，最终方案是采用外购平台提供的基础数据采集功能，然后自行做二次开发，基于公司需求，展示需要的指标结果。这一点也是可以理解的。

其他

度量指标的使用：总部提出公司级的底线要求，比如指标A/B/C达到XXX，这是最基本的，其他方面各业务线自己决定如何使用，同时将这些指标的展示开放给各业务线，公司不做统一要求。

指标的生成：对于北极星指标，由专家一起打分选出。

效能提升工作如何持续优化：多看业界/看领导需求（理解为每年领导基于上一年的结果提出新一年的要求，效能提升因此而有变化）/看如何更好的服务产品线

效能度量要做到：1.反应当前瓶颈。2.预测未来。这一条很重要，个人理解，研发效能的度量做不到这一点，就是失败。

华泰证券：研发效能提升的探索和思考

没有针对性的问题需要解决，整个转型过程如“相通之处”所讲，这里只提演讲人的几个有意思的观点。

研发效能提升应该自上而下，整体做规划

因为各个部门的人都无法考虑全局，只能看到自己面临的最大困难。比如测试部门觉得开发人员提测很晚，必然导致测试质量跟不上。而业务部门人员往往觉得需求很简单，IT部门应该做到尽早提交，并且可以随时做修改。就像几个人摸一头大象，都无法知道整个大象什么样。

同时，由于每个人的绩效所在，当别的部门来寻求支持帮助的时候，你帮助了他们，你的绩效并不会因此而提升。这就需要上层领导有统一规划。

经验VS数据

首先是泰勒的铁锹试验，简单说一下，就是工厂里工人需要用铁锹铲煤炭，泰勒通过记录不同工人每一下铲煤量的不同，关联其与最终一天总铲量的关系，得出每一铲应该铲多少，会使得最终铲量达到最高值。最终效果是，达到同样的总铲量，工厂用工人数减少了XXX，每个工人的工资也有了一定的提升。这里可以看出数据对决策的作用。

然后，演讲者提了个现象，当某次改革发生前，做了第一次的数据采集，教练和团队leader讲了通过数据发现团队有XXX问题，leader的反馈是，不用你说我都知道有这些问题，你分析数据有什么意义？（这个也是我们做教练进行辅导时，最初始常遇到的现象）即便如此，这次改革也没停下来，而是继续通过数据观察，过了几个月，数据较多了，通过分析数据变化的趋势和关联性等，发现了通过经验发现不了的问题，最终帮助团队提升。

这个例子也给了一个观点，数据不够或者数据期较短的时候，经验可能直接就能帮助团队，但是从长远看，数据能做到的上限是经验远远跟不上的。

分析归纳

华泰的效能提升团队人数是个位数的，使得没有办法进入每个团队去辅导。所以提出要分析常见问题，归纳总结，从个体问题中发现共性问题和解决方案，便于快速复制和推广。这一点也是我们应该参考的，无论多大的公司，做效能提升的人都不可能是富裕的，所以尽量通过类似的方式。而一些做得好的公司，效能度量平台自动出初步的分析报告，帮助一线人员快速发现可以改进的点，是一样的目的。

研发效能的最终态是可以干掉效能团队

原文是说，研发效能提升不能只靠这个牵引团队去做事儿，要培养公司的文化，慢慢的变成，每个业务线，每个产品团队，自己注意提升自己的交付效能，当然了，牵引团队要提供可配置的度量数据平台，最理想的情况下，最后砍掉这个牵引团队，不影响公司的效能提升。这个类似于我们常说的最成熟的敏捷团队可以没有Scrum Master类似。类似的例子，前阵子敏捷圈儿火了几天的CaptailOne公司裁掉敏捷职能团队，就是个例子，虽然做的极端了点。

京东：京东研发效能白皮书在 JD 各体系的落地实践

如题所示，这次京东的分享主要是围绕白皮书的内容讲的，方向也和相通之处里讲的差不多。过程中，由于京东动手能力强，每个部门之前就有自己的工具和优秀实践、度量体系，为了实现公司统一化，他们先统一了一切，包括工具、指标定义等等。然后从公司级统一推广效能提升。

比较有意思的两点是，一，度量指标平台展示的数据，对不同的角色，展示的不一样，比如领导看到的和一线员工看到的就不一样，前者更看重结论性的内容，找到部门继续改进的点，后者更关注自己需要做啥。这个和蚂蚁集团的三种视图的出发点很像。我理解的理想的视图也是，领导、一线人员、领域专家三个视图。

第二个有意思的点是，详细的讲了无感化度量，包括全流程无人员手动更新状态，获取所有的时间节点的数据。联想到现实中，我们的度量数据或多或少的需要一线人员做些工作才能获得。如果是这样的话，面临着数据不准、一线人员增加负担、数据很难实现T+0等问题，所以理想的效能度量一定是做好了这一点。

写在最后

虽然这次收获不少，不过比较遗憾的是，这次大会依旧没有谈到我感兴趣的核心点，即通过什么数据分析，发现了什么问题，怎么解决，最后数据变成什么样，又因此发现了另外的什么问题。感觉没说到这个点的话，都是没碰触到研发效能的核心。希望下次有演讲涉及到这个话题吧。