你真的懂效率？
- 定义效率
- 度量效率
- 提高效率
从持续交付到业务创新（上）：互联网时代研发效能的核心
为什么要效率以及定义效率
- 瀑布开发的本质问题并不是阶段，而是批量。
- 一个功能有多少价值， 不仅取决于其本身，还取决于什么时候交付。所以要敏捷开发，分 feature，以最快的速度交付第一个 feature。
- 团队（包括产品也包括开发、业务）什么时候对于产品和项目的知识最充分、最多？项目结束的时候。产品和业务开发本来就是一个探索的过程，开始时一定是最无知的时刻。项目中的大部分决策，是什么时间做出的呢？项目开始的时刻。这里埋藏了一个重大的悖论，我们在最无知的时刻，做出了最重要而且是绝大部分的决策，并把它作为随后执行的依据。对于这一悖论，敏捷的对策还是迭代。
- 敏捷指的是创建一个组织更快（早）的交付价值，和更有效学习和灵活应变的能力。
- 产品开发的最终目的是交付价值，那我们就必须让价值交付的过程顺畅起来，也就是让价值流动顺畅起来。计划、管理、协调活动，以及资源的配置等等，都应该服务于价值的流动。价值流动是目的，资源忙起来不是。
「技术人生」第 10 篇：如何做研发效能提升（即指标体系建设过程回顾）
- 你在日常工作中用各种工具、各种快捷键、各种飞花摘叶信手拈来的代码片段节省出来的 10 分钟，抵不过一场 15 分钟都没把问题聚焦起来的对焦大会；你用 git + docker + CI/CD 系统 + 蓝绿发布偶尔还来下金丝雀发布一整套云原生豪华大礼包跑完全部流程节省下来的 60 分钟，也抵不过产品经理路过你工位时轻飘飘的给你来一句 “需求要改了，晚上加个班”；当然，你用 teambition + 甘特图 + 项目任务燃尽图费劲脑汁地做多项目并行排班并发推进多条任务线最后节省出来的 10 天，也抵不过 leader 拉你进入紧急处置群，里面看到的第一句话就是 “老板改想法了”。
- 技术产品本身要回答 “做产品”还是 “做项目” 的问题，因此选择“做产品” 的一定瞄准尽可能多的客户的共性问题，在此基础上再解决定制化的问题，即提出各种架构、模式、机制来支持未来可能的定制化，因此它对更上层的、更具体的效能问题其实不解决的，或者说，从投入产出比的角度来看，产品型效能工具在诞生之初就无法做特例情况的支持，只能通过后期的基于各个团队实际情况的自定义开发来解决。所以这就是为什么用了效能工具还有效能问题的根本原因：它只解决了它要解决的效能问题，但是它没有解决你所面临的全部的效能问题。作为研发团队的 Leader，要非常清晰地看到哪些产品解决哪些问题，更要非常清晰地知道自己的团队目前面临的效能问题究竟是什么，怎么形成的，如何解决，事实上就是分析清楚当前团队在研发效能建设领域面临的主要矛盾次要矛盾是什么
- 很多团队的效能指标会停留在编码量、需求交付量，实际上只是照顾到了最基础的效能指标，却没有分团队类型、分业务阶段做动态调整，自然很难发挥出指标的牵引作用，原因就在于不够实事求是，对团队和业务的个性考虑不足。
度量效率
我们在阿里内部做团队效能改进时，提出了称之为 “2-1-1” 的愿景，得到了不少部门的认可。什么是 211 呢？
- “2” 指的是交付周期 2 周——85% 以上的需求可以在 2 周内交付；它涉及到整个组织各职能，和部门的协调一致，紧密协作。
- 第一个 “1” 指的是开发周期 1 周——85% 以上的需求可以在 1 周内开发完成；
- 第二个 “1” 指的是发布前置时间 1 小时——提交代码后可以在 1 小时内完成发布。需要持续交付流水线，产品架构体系和自动化测试、部署等有力保障。