研发效能工具的破局：产品化与场景化
The following article is from VCEC Author VCEC
腾讯平台与内容事业群工程效能平台部研发流程协作平台中心负责人张力柯带来了《研发效能工具的产品化设计与重构》的精彩演讲，他分别从自动化测试、Devops流水线、项目管理三个领域来探讨如何以产品思维看待互联网研发效能工具，以及如何将现代软件架构思想用于对应工具的重构开发，从根本上解决对应领域中的一些常见痛点，如自动化测试中的持续稳定，流水线的人工介入，及项目需求定义扩展性和实施跟进。
1
国内工具平台的困惑
中台这个词也引起了一阵热烈地讨论。当时说到国内的一个现状，每个团队员工都有很多工具（烟囱式的工具），如果一个像腾讯级别的公司要去梳理的话，可能会高达数百个，然后出现说要做中台，这些都交给中台处理。
1、研发平台：硅谷VS国内
国外对于数据的监控是一个很平滑很深入式的过渡，并没有人对其中有什么争议，包括说怎么去做。但是国内对这个比较纠结。但是在具体的落地场景中，发现有些问题可能是用户习惯、公司习惯的问题。国内一些做事的方法跟国外有比较大的差别，也许是这些原因造成了我们在国内的一些困惑。因为国外比较很细分而且比较专注，要用什么工具，中间不会需要对接很多，但是国内不一样。
对国内的现状，不说优劣，确实效率非常高，在一些大事情的时候，有时候可能会说国内的一些问题比如说现场监控不完善，但是真正去看，不管是腾讯还是阿里，监控是非常完善的。
实际上我们真正要面对的是针对这种情况我们怎么去做自动化测试，怎么去Demo以及怎么去做研发项目管理。
2、破局：技术产品思维
其实以上的情况在国外也不是没有过，美国硅谷技术的发展也不是一蹴而就的。以亚马逊这个工程为例，他们一开始说所有社会继续使用API，东西多了之后，各个服务全部API提供一堆，出现完全混乱的局面。后来几年，最大程度减少耦合，最大程度去减少接入成本，最大程度去避免实现的细节，这是它的设计理念。
放到一个产品的层面去说，用户希望最快完成工作，而且用户一旦形成习惯，这个习惯难以改变。至于技术层面怎么去处理这些异常，怎么去扩展，怎么去提供稳定性，就是后面要去做的事情。这个概念其实是老生常谈的，但是实际上做工具的时候，工具品牌思路未必能真正扭转过来。
Kafka的设计理念
最大程度减少耦合 最大程度减少接入 最大程度避免细节
用户：最快完成工作 用户习惯一旦建立，不可改变
异常处理（用户能够处理或清楚问题在哪里） 扩展性：容易扩张，功能通过插件来实现 稳定性（底层实现对用户透明）
有多少测试脚本？ 多少测试流程？ 每个脚本谁在负责？ 每个脚本的成功率有多少？
定义测试案例(TM) != 设计测试流程（SDET）!= 执行测试流程(QA) “谁开发谁负责”Feature Owner => “谁测试谁负责”(Test Owner) 自动化(执行自动化) != 测试 (发现问题)
测试脚本是case by case，无法复用 在测试之外的领域？
没有100%稳定可靠的自动化 未定义弹框？ 识别失败？ 游戏更新？ 处理时间的统计与优化？
便于维护 便于修正（结构化数据） 图灵完备，可完成复杂逻辑
后端执行，便于维护升级 便于调试
只负责执行后端指令 简化逻辑，提高稳定性
混合方案的图像识别服务 自动探索AI
面向大规模自动化服务(云游戏) 针对多业务的自动化中台
基于场景更简单、更适用、更灵活
解决流程问题就需要靠标注来自定义流程
脚本开发工作量大，重复性高，最终交由外包开发 外包开发沟通不畅，代码抛弃率高，最终多种“魔改” 测试开发缺乏脚本执行的实时反馈和信息 无法根据大规模应用下的问题进行迭代改进 结果=>测试开发本地一切美好，一旦推广则失败
解决——
抛弃脚本，外包只负责标注 标注是业务熟悉问题，自动化实现是开发设计问题 交付自动化引擎，而非业务内容 Design Automation as A Product
开源 很方便安装 扩展性强 UI陈旧 流水线定义文件需要特定语言 扩展性强，但耦合紧密 本地构建，构建环境维护成本高 需要专业人员规划执行 提供基本能力（小米加步枪） 对人的要求高（高水平队伍）
很好的技术工具 不算出色的技术产品 如何规范？如何一目了然？
现代风格UI YAML风格定义 托管服务，直接对接代码仓库 CI过程统计/可视化 较好的使用体验（现代化装备） 对使用者要求略有降低（了解yaml规范）
如何进一步降低学习成本？ 仅仅是CI？
完善的引导教程 更丰富的自定义操作 更具引导性的流程设计
体验的易用性 功能的丰富性
项目规划形式 需求开发节奏 版本规划方案 引入迭代周期概念
使用CI工具如Jenkins 主要是自动构建验证 不一定引入单测保障 发布环节主要靠手动
从需求创建到上线全流程覆盖 各环节多角色参与 需求从提出到上线全链路多角色跟进 需求完成=需求上线稳定运行 研发数据可视化
基于图模型的数据关联
以代码为核心 代码合入则任务完成 需求-代码完美关联 基本的需求迭代管理
未尽全功的项目管理 未尽全功的扩展框架 过时的UI设计 过时的单体结构
互联网开发团队 较好的二次开发能力 需要跨团队需求协作 需要一站式工作平台 需要内建的执行规范
毕业于美国德克萨斯大学圣安东尼奥分校并获得计算机科学博士学位，曾先后在美国微软、BCG、Uber及硅谷多家创业公司担任过研发工程师、产品主管及公司创始人等多个角色。
2017年归国后在腾讯创立 Turing Lab，推进人工智能在游戏AI自动化、图像分析及RPA方面的落地。当前负责腾讯PCG工程效能平台部社交产品效能中心，致力于面向多产品多团队的大规模研发协作平台设计与实施。
如何最大化软件测试效能？（附分享的PPT） QECon全球软件质量效能大会开幕致辞：大道至简、质效合一 （附PPT） 灵魂拷问二：敏捷是研发效能提升的银弹吗？ 灵魂拷问五：研发效能的提升一定是有技术驱动的吗？ 大规模信息流推荐系统 研发效能提升之优秀实践 演讲实录：从灵魂拷问到研发效能提升的正确姿势 困在系统里的“研发效能度量” 该如何自救？ 许多研发管理者并不想提升研发效能，这才是最大的问题！