研发效能破局之道.md

研发效能破局之道

研发效能模型

  • 相比工作时长而言, 公司应该更加关注研发效能
    • 硅谷一般都是任务驱动
    • 国内强调时长
      • 长期加班不能保证持续的高效产出
        • 长期来看会导致效率, 质量下降
        • 加班产生的 bug 需要花费更多的精力去修复
  • 研发效能指的是能够 持续 为用户产生 有效价值 的 效率, 包括 3 个维度
    • 有效性 Effectiveness
    • 效率 Efficency
    • 可持续性 Sustainability
  • 硅谷知名公司在研发效能上做得很好, 是研发效能的标杆
    • 公司业务成功的重要因数
      • 2012 年 10 亿月活部署只需要 3 个人员
        • 2017 年又引入持续部署, 作了进一步的优化
    • 注重研发效能使得开发者凝聚在一起, 更容易精进自己的技术
      • 团队容易建立好的氛围, 促进生产效率的提升, 形成良性循环, 持续的高效开发
  • 软件行业的发展, 不断创造新的工具, 流程和方法来适应和提高生产效率
    • 互联网产业爆发以来, 这一趋势更是明显, 新的工具/方法层出不穷
      • 从瀑布到敏捷到精益
      • 从持续集成到持续发布到持续部署
      • 从实体机到虚拟机到 Docker
      • 从本地机器到数据中心到云部署
      • 从单体应用到微服务到无服务
  • 只有深入研发活动的本质, 才能提高效能
    • 微服务的不合理引入是一个典型的案例
      • 自从亚马逊成功大规模应用后, 微服务逐渐形成风潮
      • 很多公司在不清楚适用场景到情况下盲目采用, 结果踩了很多坑
      • 只考虑局部最优而忽略了全局优化
    • 从纷乱的表象和层出不穷的方法中, 看到隐藏的模型, 找到根本原则
      • 从这些原则出发找到合适的方法
        • Facebook 有一条原则 不要阻塞开发
          • 本地构建脚本运行速度要足够快
            • 这个操作非常频繁, 应该想尽办法给这个本地构建加速
            • 把新开发的改动在自己开发机器的沙盒环境中运行起来
          • 开发流程的流畅 是生产优质软件到关键因数
            • 只有这样才能最大程度到释放开发者的 创造力 和 积极性
            • 往往一个好的产品是在一个舒适的环境中创造出来的
      • 越是灵活的东西, 越是需要理解其本质, 这样才能做到随机应变
        • 软件研发越灵活, 在实践中总会遇到各种不同的情况
  • 研发效能的模型
    • 软件开发本质上就是一条超级灵活的 流水线
      • 需求分析-> 设计 -> 开发 -> 构建 -> 测试 -> 发布 -> 部署 -> 运维
    • 软件开发具有 超强的灵活性 ， 体现在 4 个方面
      • 最终 产品目标 的灵活性
        • 互联网中的最终产品形态通常是在不断的迭代中逐步明确, 相当于一个移动的标靶
        • 通过 MVP 来不断验证产品的假设, 不断调整最终形成的产品
      • 流水线中 节点本身 的灵活性
        • 每个生产环节都在不断涌现出新的生产方式/方法
          • 测试驱动开发, Dogfooding , 测试前移, 测试右移 (强调在生产环境中进行测试)
      • 流水线中 节点间关系 的灵活性
        • 流水线上的多个节点互相融合
        • DevOps 模糊了节点之间的边界, 甚至在一些实践中去掉某些环节, 或者融入到其他环节中去
      • 每个节点上的 开发人员 灵活性
        • 对于相同的功能, 可以选择很多不同的方式, 不同的工具来实现
  • 提升研发效能
    • 优化流程
      • 针对产品目标的灵活, 以始为终指导工作, 击中移动的标靶
      • 针对节点之间关系的灵活性, 聚焦流水线的流畅, 保证用户价值的流动受到阻力最小
    • 团队工程实践
      • 每个节点的灵活性进行优化, 聚焦每一个生产环节的工程实践进行提高
    • 个人工程实践
      • 提高个人研发效能, 争取每个开发人员能适当关注业务, 以终为始
      • 同时从方法和工具上提高开发效率
    • 文化和管理
      • 文化是一个团队工作的基本价值观和潜规则
        • 任何流程, 实践的引入和推广, 必须有合理的管理方法来支撑

评论

  • 工具优化需要关注投入产出比
    • 花了太多的时间去作了 不成熟的优化 (premature optimization)
      • 一般 premature optimization 值架构方面的, 在工具使用上也一样
    • 留意平时工作, 在 重复比较多的工作部分, 花一些时间找工具进行优化
  • 是效能低才导致加班, 还是加班导致效能低?
    • 刚开始加班有一些效果, 然后较多的使用加班, 加班导致效能降低, 产品质量下降
      • 为了赶上进度, 提高产出, 又采用加班这个方法
  • 流程工具可以借鉴, 但是工程实践需要 深入理解场景, 精挑细琢去研究各个技术背后的原理
    • 技术本身的一回事, 怎么把技术用好 是另外一回事
  • 一个行业发达, 形成生态链, 包含非常多数量和种类的玩家
    • 提供各种中间件
    • 提供效能等各种加速解决方案
  • 作为管理者, 应该在做业务目标的同时有一些技术目标
    • 提高团队的效能就是技术目标的一种
    • 当然很可能需要说服更上一层的领导, 让他了家并支持技术目标
    • 不一定需要成员有大的创造性, 一开始更重要的可能是主动性
      • 可以通过绩效的方面鼓励并帮团队提高效能的行为
  • 构建加速的方法
    • 并行
    • 缓存和共享 artifact
    • 精准构建, 精准测试
    • 资源扩容, 加硬件
    • 看 profile, 找到最大的瓶颈
  • 推广
    • 了解方法论的本质, 根据不同团队的特点找到不同具体实践
    • 找到共性在全公式推广
  • 阅读清单

研发效能度量

  • 软件行业数据驱动的手段被大量采用
    • 通过使用漏斗和 A/B 测试用来指导产品方向
  • 提高研发效能, 首先解决效能的度量问题
    • 一个事物, 如果你无法度量它, 就无法管理它
    • 如果不能度量一个事物的所有方面, 那就不要去度量它
  • 效能的度量是一个难题
    • 研发效能的度量代表一组可量化的数据和参数
      • 从应用程序开发的生命周期中获取数据
      • 并使用这些数据来衡量软件开发人员的工作效率
        • 提高团队的绩效
        • 提高计划精确度
        • 寻找关键的待改进领域
    • 至今没有哪个公司敢号称找到了效能度量的完美答案
      • 甚至绝大部分公司在使用效度量时, 不但没有起到正向作用, 还上伤害了产品和团队氛围
        • 团队开发环境和度量差异太大, 造数据来满足度量系统的要求
        • 真正应该度量的是产品的稳定性
        • 过分关注了开发过程中的数据, 却没有收集其他步骤的数据去快速试错和寻找产品方向
    • 背后的原因有那些
      • 软件开发是一项创造性很强的知识性工作, 非常复杂且伴随大量不确定性
        • 文档往往是落后的
        • 软件产品的实现方式有很大的不确定性
      • 公司稍不留神把注意力放在了某一两个 silo 上, 进行局部优化, 不是全局优化, 甚至会导致全局恶化
      • 技术产品输出和用户价值输出之间的沟壑难以打通
      • 类似代码审查等相关实践具有滞后性
        • 一开始总体效率会出现短时间下降, 一两个月之后才会逐步展现正面效果
      • 往往越容易收集的数据价值反而不大, 那些难以收集的数据对度量可能才真正有用
        • 比如, 产品对用户的价值怎么去衡量
  • 从全局视角度量指标, 度量产品生产周期中各个阶段的数据
    • 跟踪研发过程中各个环节的耗时, 并在功能发布后复盘
    • 使用度量寻找问题而不是用来作绩效考核, 使用度量校验改进的结果
  • 要真正发挥作用需要找到合适的度量指标
    • 速度
      • 衡量团队研发产品的速率
        • 吞度量
        • 燃尽图
        • 热修复上线时间
    • 准确度
      • 产品是否与计划吻合, 更用户需求吻合, 能够提供较大的用户价值
        • 功能的采纳率, 百分之多少的用户使用了功能 X
    • 质量
      • 包含产品的性能, 功能, 可靠性, 安全等方面
        • CI
        • 测试覆盖率
        • 响应时间
        • 用户发现 bug 占比
    • 个人效能
      • 开发环境生产速度
      • UAT 等环境验证速度
      • 本地构建速度等
  • 效能度量 不要与绩效挂钩, 这个作为效能度量的原则
    • 度量作为参考和工具, 帮助团队提高效能
      • 缺陷密度, 可以让团队了解产品质量的走向
      • 新旧 bug 占比, 一定程度上反映技术债的严重程度
      • Facebook 有超过 4 套数据展示面板
        • 开发人员可以定制面板, 展示对自己有价值的效率度量
        • 上线前高优先级 bug 数, 燃尽图
        • 每个团队主动使用这些面板, 来帮助团队达成业务目标
    • 效率度量的最佳实践
      • 目标驱动, 度量对的事
        • 根据团队情况, 找到能够直接衡量产出有效性的指标
      • 先从全局上找瓶颈, 再深入细节
        • 累计流程图
      • 通过主观评价效能改进的后的使用体验
        • 针对研发环境, 流程, 工具的效能进行评价
        • 满意度让员工工作更积极, 工作积极又能提高满意度
      • 关注日常开发的高频活动, 并自动化和优化这些步骤
        • 个人调测环境构建速度
          • 开发人员在本地做好一个改动, 进行本地调测拿到反馈的时长
    • 虽然推崇数字驱动, 但是在效能的度量上, 不要迷信数字, 适当使用主观反馈效果反而更好

评论

  • OKR 更多是一个目标对齐的工具
    • OKR 的使用, 一个重要的原则是不要把它的度量和绩效强挂钩
  • Google 修改代码的艺术
  • 怎么衡量一个组织的创新程度
  • 在一个环境呆久了, 往往会习惯当下的环境, 觉得常态也是这样, 这个时候能够跳出来
    推荐阅读关于⿊客之道的内容：https://time.geekbang.org/column/article/162869

优化流程

  • 方法论实施好不好, 关键在于有没有用好

    • 研发流程的方法论很多但是实施却不理想
    • Google/Facebook 等高效能公司并不强调 Scrum/ 看板工具

  • 深入理解方法论的目标和基本原则, 根据原则因地制宜的选择自己的实践

    • 选择具体实践时, 需要在已有实践上作修正或适配
      • 逐步优化已有的开发流程和框架
      • 一开始只给出原则, 逐步摸索并找到合适的方法
    • 学习方法论遵黄金圈法则
      • Why, 要解决一个什么问题
      • How, 这个方法论的基本原则, 指导思想
      • What, 这个方法论的具体实现
    • 在使用一个方法论的时候一定要从内向外看
      • 中心的目标一定错不了
      • 原则的通用性就差一点, 在理解的基础上挑选适合自己的
      • 具体的实践就要小心谨慎, 切忌生搬硬套

  • 优化流程的目标有哪些

    • 提高寻找用户价值的效率
      • 主动去寻找最好的产品形态, 只有方向找对了, 流程产生的结果才具有价值
      • 精益创业 Learn Startup
        • 每一个时间段的成果衡量的是 价值假设 方面的进展
        • 使用最小可行性 (MVP) 产品来帮助学习
          • 要以探索价值出发来设计产品, 最快的来验证你的假设
            • 开发一个功能之前都会提前计划要验证哪些假设
            • 然后设计收集什么样的数据来验证这些假设
            • 一旦发现功能不能提供足够的用户价值, 就把该功能下线, 确保每个功能都是提供用户价值的目的
        • 度量驱动开发
          • 公司不断投资 A/B 测试验证框架, 让开发人员能够尽量容易的收集和处理数据
    • 提高用户价值的流动效率
      • 让功能尽快的流动
        • 快速开发, 问题发现的越晚, 修复的代价越高
        • 尽快把功能细分, 做好一个功能之后尽快提交
        • 降低提交的交易成本 (每一次提交都需要作的额外工作)
      • 让节点之间的联动更加顺畅
        • 通过对关键流程的自动化, 工具之间的网状互联, 以及节点之间的融合来实现
        • 通过 CI/CD 流水线来自动化代码集成过程
        • 工具提供开放的 API 来进行一个网状连接, 从而让开发者可以集成到自己的工作流程中去
          • 工具最核心的一个特点是被集成
          • 公司对这些关键的, 小范围的流程进行大量优化
      • 节点之间的融合
      • 发现整个流程中的瓶颈, 并解决他们