都说研发效能拖垮了团队，该怎么破局？
本文不涉及研发效能中的具体实现和技术细节，主要讨论研发效能中的思想和经验，欢迎一起交流讨论。
这里讲的研发效能是广义的研发效能，不是只针对研发同学，而是说整个产品研发的生命周期，可能从产品立项、需求、管理、研发、到上线运维整个周期。
效能提升的核心
效能提升的核心思想是统一流程和制定规范。
秦始皇统一六国之后，统一书体提升政令推行和文化交流的效率；统一车轨提升诸侯往来和交通通行的效率；统一度量衡提升货物交换的效率。
1913年福特汽车引入流水线，通过流水线统一汽车的制造流程和标准化每个生产步骤，将汽车的生产时间从12个小时缩短到93分钟。
在公司内部，各个团队之间就像秦始皇统一六国之前，各立山头，各自为政。每个团队都有自己的技术栈，工作方式，度量指标等等，使得团队之间的交流和合作很难开展，造成很大的资源浪费。
所以要想提升研发效能，就是要使各团队之间的流程和规范相互统一，制定统一的流程和规范。
效能提升的成本
抛开投入成本空谈效能提升，就是耍流氓。在去推进业务方效能提升时，也要考虑业务方的投入成本，如果投入成本和提升效果不能成正比，那效能提升的工作也很难推进。所以有的时候，自己觉得工具这么好用，简单高效，业务方为啥不用呢？可以考虑下投入的成本：
学习成本
任何的工具使用起来都是需要学习的，可能工具提供方觉得已经很简单了呀，但是对于业务方来说都是未知的。业务方还需要评估你的工具是否能满足业务上的所有需求，如果不能满足的，工具方应该怎么支撑。
你这个工具是不是KPI项目，如果我使用起来之后，你不维护了怎么办。
我应该怎么学习使用你的工具，有没有完善的使用文档。
如果出了问题，我要怎么解决。
举个例子，很多公司都会基于Spring Boot封装公司内部的Boot框架，对于SpringBoot官方提供了完善的文档，网上也有很多的教程，对于Java后端程序员来说，也会主动学习相关知识，如果遇到问题，社区也会有很多的问答。但是如果内部的Boot框架，封装的时候改动了哪些内容，或者默认配置了什么，如何正确的去使用，出现问题的时候怎么排查找谁解决，都需要公司内部进行知识库建设。
管理成本
引入效能平台之后，直接面临的问题就是会引入项目管理，应用管理，人员管理，权限管理等一系列管理的工作。有可能有的同学没有管理能力或者管理意识，就会觉得反而更加繁琐了，还需要跟更多的人配合和对接。
举个例子，比如权限管理，对于平台来说不能没有，但是有了权限管理又觉得使用起来特别麻烦。尤其权限管理搞起来还可以很复杂，一般使用RBAC模型，基于角色进行权限管理，这个模型也分几个层级，角色的继承，角色之间的互斥，约束等等，设计的越复杂，使用起来的成本越高，而且很多时候使用方都搞不清楚这个权限该怎么管理。
迁移成本
对于新开发的平台，怎么从以前的模式中迁移到新的平台。是不是要提供专门的迁移工具进行数据迁移，新平台跟以前的数据能不能兼容，尤其是数据之间还有ID依赖关系的数据很难处理，这些可能是在平台设计之初就要考虑的。
举个例子，比如接口自动化平台的数据，测试用例里面的接口数据之间还存在相互依赖，一个接口的请求参数可能需要上个接口的返回值参数。这种还包含业务数据的关联关系迁移起来也很复杂。
效能提升的度量
度量是经常被忽略的一个功能，一般在做效能提升工具时，首先规划的时需要有什么功能，对功能进行重点实现。
但是，当你推荐别人使用效能工具时，经常被问的问题时，提升了多少效能。
业务方在使用效能工具进行工作汇报时，领导一般也不会关心你使用了 什么功能，而是问你减少了多少人力，缩短了多少时间，故障率减少了多少，效能提升体现在哪。
所以对于效能的度量在平台设计之初就应该去考虑，丰富的数据统计和度量指标去展示效能提升的效果更有说服力。
但是，效能度量的指标不应该与个人的绩效挂钩，因为与绩效挂钩可能就会出现对应的投机行为。效能度量的指标应该是展示当前研发流程的数字化状态，帮助发现研发流程中存在的问题。数字化分析人力都花费在哪里，哪些流程比较耗时。如果你不能度量它，就无法改进它。
效能提升的支撑
效能平台研发完成后，怎么让业务方正确的使用起来，发挥出平台的作用，只有使用文档是不行的，更需要实战文档指导业务方按照什么样的流程使用，而不是在平台进行功能探索。
平台使用文档
平台的使用说明书，详细介绍平台的功能点和具体的使用实例。
当你推广的时候没人会看使用文档的，不要要求或者很难要求别人都去看使用文档。
但是使用文档又是必须的：
- 没有文档别人说你连个文档都没有。
- 每个人每天重复问题一个问题的时候你可以发文档过去至少沟通上高效一些。
- 写文档的时候自己可以系统的梳理下平台的功能，知道自己在做什么。
使用自己的平台
很多时候自己开发的效能平台可能自己都没有 用过 ，自己都没有使用过又怎么帮助业务方去提高效能呢？很多问题 自己在使用过程中就可以发现，如果等到业务方提出了，只会慢慢降低业务方对平台的信任感。
实战经验
仅仅有使用文档是不够的，研发效能需要告诉 业务方使用平台的整个流程是怎样的，业务方应该按照怎样的步骤去使用，什么场景或者什么阶段下使用对应的功能。而不能是让业务方按照使用文档去摸索，就是要明确的告诉业务方具体的使用流程来发挥效能提升的作用。
效能提升的更多
沟通是最大的成本
团队和团队之间的沟通成本还是比较 大的，涉及到团队间的合作相应的工时都会增加，而且还存在不确定因素。
跨团队沟通时要先统一语境，概念名词之间拉齐，最好不要使用代号、缩略词。不要假设对方懂什么，要假设对方啥都不懂。清楚描述什么环境下经过什么过程，产生了错误的结果，而不是直接问为啥要这样的错误。
效能提升要结合公司的情况
每个公司可能有自己公司的研发流程和管理方式，可以借鉴其他公司的经验，但照搬硬套可能不行。
业界讨论的 Devops平台应该开发做还是运维做，可能不同的公司归属的部门不同，根据公司的实际情况没必要过多争论吧。
工具引入，二次开发
很多时候我们可能是直接引进开源的平台进行使用，引入平台时不要直接给业务方使用，需要根据公司内部的流程规范输出最佳实践文档，让业务方按照规范来使用，重要的不是功能，而是规范。
对于开源平台免不了需要二次开发，对于实现的技术栈也是一个重要的考虑点，而且还可能有人员变动，如果技术栈与公司现有技术栈差别比较大，后期迭代维护是个问题。
以上是在做研发效能工作时的一些感悟，有什么不对的地方，欢迎指正交流。