一、前言
管理大师彼得·德鲁克在《有效的主管》一书中简明扼要地指出：“效率是‘以正确的方式做事’，效能则是‘做正确的事’。效率和效能不应偏废，我们希望同时提高效率和效能，但若效率与效能无法兼得时，我们首先应着眼于效能的提升”。携程大住宿研发效能提升的指导思想就是基于做正确的事展开，并以“持续快速，高质量的交付有效价值”作为研发效能改进的核心目标。通过持续不断的改进探索，让团队思考更加有效，工作更加高效。
在落地研发效能提升的过程中，我们遇到了很多的挑战，总结下来核心的现象有以下四种：
1. 目标不一致，导致协作低效：大住宿拥有36个规模大小不一的敏捷团队。有小型的10以下的特性团队，也有50人以上的全功能敏捷团队。各团队相对独立又存在无法规避的协作关系。当A团队的目标依赖B团队的支持，就会存在取舍和协同。当AB团队目标不对齐时，先完成自身目标还是支持对方完成目标的过程会增加非常多额外的协作沟通成本。
2. 视角割裂，产生无效价值：产品只负责产出需求，开发只管任务完成，最终交付验收发现不是想要的功能。这是大住宿在敏捷转型前遇到最频繁的问题。团队成员视角割裂导致各角色只关注于自己熟悉的领域，而忽略目标价值的交付，最终会产生非必要的浪费。
3. 基建薄弱，导致额外成本增加：有一种误会是只要转型敏捷研发效率就能10倍数提升。实践发现，基建的薄弱在一定程度上反而增加团队的负担。比如为了持续频繁的发布，自动化测试的缺失带来额外的人工回归成本；比如代码质量不可靠导致测试频繁的返工等，在一定程度上不仅影响了团队交付效率，还导致了用户满意度的下降。
4. 度量困难，缺少客观衡量数据：大住宿的敏捷转型试点，从一块物理白板，一堆便签，几只油性笔开始。缺少电子信息的沉淀，需要完成度量的费力度和成本非常的高。当时为了收集度量的数据，需要人工记录过程信息，然后通过Excel梳理整合，再进行分析处理。人为的记录和分析让数据缺失一定的客观性，无法很好的衡量团队的改进效果，也无法有效引导团队改进方向。
为了改善以上问题，我们从想好、做好、做快这几个维度齐头并进，持续优化，深度耕耘：
使用OKR工作法拉通产研，深度协作
使用MVP实践，围绕价值交付
通过深度敏捷实践，打造敏捷企业文化
通过DevOps实践，支撑团队快速交付
二、OKR工作法-上下同欲、对齐目标
明确一致的目标是组织内各个部门和全体成员的合作基础，共同的目标是组织建立和存在的客观基础，是完善和发展组织的客观依据，也是为组织创造更大价值的必备因素。OKR工作法（Objectives&KeyResult，目标与关键结果）是一种企业、团队、员工个人目标设定与沟通的优秀实践与工具，是通过结果去衡量过程的方法与实践。同时，OKR还是一种能够促进员工与团队协同工作的思维模式。大住宿OKR工作法的落地推进，有效的促进了团队成员间的紧密协作，同时也迎来了更多的挑战：
如何让整个组织的力量都聚焦在重要事项上，助力战略落地
如何管理组织内的目标横向对齐，消除“部门墙”的障碍，协作更高效
如何透明化组织、团队的目标，暴露重复、多余、无价的任务，节省成本
面对挑战，大住宿正在持续不断的探索改进中：
1. 推行产研一体，聚焦整体价值交付。以敏捷团队为单位，团队的PO/TO与团队共创价值，将每个人的工作与团队目标联系起来。以季度为周期进行规划复盘，月度review进度和风险的节奏实施落地。无论是技术还是业务的需求，都聚焦到价值的交付上，团队内部形成良性平衡。
2. 试点部门级别产研一体的季度OKR复盘活动。为了更好的达到上下和左右对齐目标，提高协作效率，大住宿从今年Q1开始试行部门级产研一体的季度规划和复盘活动。各团队会前准备好复盘材料；会上回顾复盘材料并进行讨论、反馈和建议；会后根据会议内容形成下一季度的OKR调整内容和建议。通过活动让大家看到各部门、岗位等相关方的相互依赖关系，明确自己的价值定位、实现团队间的紧密高效协作。从而打破筒仓效应，最大程度整合组织资源。
3. 借助IDEV目标管理工具更有效的透明OKR。IDEV是公司提供的统一产品研发管理平台，大住宿在去年接入IDEV后，不仅提高了产品研发过程的透明性，也率先实现了需求数字化管理。结合实践管理发现需求目标的明确，可以更好的支撑需求的交付。经过沟通和设计，IDEV平台开发目标管理功能来支持团队的数字化目标管理。通过每个需求关联专属的KR对齐目标，并使用关联功能管理依赖团队间的需求。工具支撑的信息透明让团队更高效的彼此对齐，相互支撑，保证了团队步调一致，从而完成最终目标的实现。
三、MVP实践-共识价值，杜绝浪费
O代表一种追求和方向，KR是衡量目标达成的关键结果。为了更好地支持KR的达成，团队统一使用MVP思维。在规定的时间盒内选取最合适的需求，并用最低的成本，最快的速度，向用户交付产品的主要功能及特色信息，并通过及早的接触用户，获取客户反馈和市场验证来改进产品，迭代升级，以避免做无效需求。
为了更好的落地MVP实践，大住宿主要采取了以下2个措施：
1. 合理拆分需求，降低试错成本。需求拆分越小，需求越容易理解，改动成本越低，缺陷暴露越早，价值流动越快，也能更早的交付给用户，提前得到反馈。但如果需求拆分的过小，分批开发也会带来测试和发布的成本增加。如何通过合理的拆分需求，降低试错成本？
大住宿研发效能改进计划实施中首先对产研需求进行了规范化的治理，共同约定IDEV上创建的每一个需求都是最小维度的可独立交付，可独立验收且可独立衡量价值维度。由于产研视角上的差异会产生不合理的拆分需求，研发团队如果无脑的接受产品拆分，会缺失对需求整体性的认知，也会面临技术实现相互冲突，还可能会对代码架构造成影响。在规范化需求后大住宿又进一步培训加强产研团队共同拆分需求机制落地。
2. MVP思维贯穿需求整个生命周期。MVP在实际实践中容易陷入一个误区，做完一个MVP就没有后续。大住宿在 MVP实践中提倡将思想贯彻到产品的整个生命周期当中。上线的MVP及时的验证并基于反馈快速的调整寻找下一个方向，迭代循环，最终达成目标。敏捷团队在需求评审会上共识第一次价值，然后在需求上线后及时的验收，进行第二次价值同步。针对没有达到目标需求，快速调研分析后会尽快在最近的迭代周期内安排再次上线验证。整个团队均始终围绕价值持续交付。
四、敏捷实践-敏捷升级，助力效能
敏捷是研发效能提升的又一助力工具。敏捷开发是一种应对快速变化需求的软件开发模式，核心是小步快跑，快速迭代。
大住宿从2014年开始推行敏捷转型，敏捷让团队实现价值驱动管理。传统开发模式除了瀑布接力开发外，还有一个是任务驱动管理。任务驱动管理模式下，客户第一次看到实现的功能可能是在验收阶段，这时候发生需求变化或功能新增都会让开发团队的返工成本变得无法预估。还可能为了赶进度，牺牲掉质量。而敏捷开发模式帮助团队重心放在实现对客户有价值的需求上，让团队关注真正有价值的东西。
大住宿的敏捷转型是从Scrum开始试点，研发团队从只关注怎么实现需求到共同关注优先要实现哪些需求，如何更快的实现。但一支高效能的敏捷团队，不仅需要高有效的执行落地能力还需要持续不断的改进能力。缺失任何一种能力，都只会让敏捷停留在“伪敏捷”上。
酒店研发在转型路上，也常会因为执行落地不到位而遭遇一些低效的情况：
站会变成汇报会议，只有进度同步没有阻塞反馈。
回顾会无人说话，事不关己或变成*大会。
计划会上需求方案还未确认清楚就开始迭代开发，迭代过程中反复确认，沟通成本增加，工作效率低下。
针对以上问题我们做了如下的改进措施来帮助团队提高执行，持续改进。
增加敏捷培训，邀请团队成员参与到敏捷管理活动中，从实操活动中加强团队成员对于敏捷中每个角色，每个会议的深层理解。
明确团队各阶段的完成定义并督促落地执行到位。
针对性的开展主题回顾会议，邀请相关干系人共同参与，保持频繁的反馈，持续改进。
早期的Scrum团队更多的关注在软件过程中的活动，而忽略了开发过程中的各种等待时长。Kanban方法的加入帮助酒店团队看清各种等待不增值的环节。通过Kanban方法拉通产品、设计、交互、开发、测试、BI等各职能各环节的价值流动，并通过IDEV需求管理平台实现上下游价值的流动可视化。
改进前团队的关注重心从“敏捷排期”阶段到“待验收”上线阶段。
改进后团队的关注重心从“需求规划”阶段开始到“完成”阶段的整个产品生命周期。
Scrum和Kanban都是帮助团队尽早交付和持续改进的过程方法，方法各有千秋，合适的才是最好的。只有不断的实践，不断的总结，不断的调整，才能真正意义上帮助团队提升。
酒店研发在方法的选择上，也是基于团队自身情况进行决策，比如：
有版本限制的团队，采用Scrum，节奏感可以帮助团队提高协作效率。
创新型业务，关注快速交付的团队，采用Kanban，重点聚焦需求价值流动和及时反馈。
单周交付的团队，采用了Scrum+Kanban混合方式，有效平衡速度和节奏要求。
Scrum
Kanban
实践核心：化繁为简
实践核心：可视化价值流
定义团队角色：Scrum Master、PO、Team
无特殊规则
定义迭代，固定时间盒概念（两周迭代）
限制WIP（work in progress）
Sprint开始后建议不允许新增需求
只要生产力允许，即可新增需求
尽早交付价值
持续改进
八年的敏捷文化熏陶，大住宿大部分的敏捷团队已从“守”的阶段进入“破”和“离”的阶段。
1. 守， 团队能按照scrum的流程去实施敏捷，如团队中有三个角色(PO\SM\Team)，团队按照四会（站会，计划会，评审会，回顾会）开展工作等等。
2. 破， 团队能根据自身的状况，去突破敏捷原有的部分规则，去到更高的层次，比如根据敏捷的价值观去增加其它的一些东西，例如增加TO的角色、增加code-review会议等。
3. 离， 团队的成员已经非常熟悉敏捷的流程和规范，对敏捷的价值观驾轻就熟。团队根据自身状况制定相关的实践，比如PO/TO共创团队OKR等。
敏捷实践的升级让端到端的产品、开发、利益相关人更顺滑的聚合在一起，采用合作共赢的协作方式帮助团队价值最大化。
五、DevOps实践-提升质量，加速交付
除了采用目标对齐，共识价值，高效的敏捷实践等改进措施，想要达到持续频繁的交付还需要持续集成持续发布能力的支撑。DevOps强调通过一系列手段来实现既快又稳的工作流程，使每个想法（比如一个新的软件功能，一个功能增强请求或者一个 bug 修复）在从开发到生产环境部署的整个流程中，都能不断地为用户带来价值。CI/CD作为DevOps的重要组成部分，核心价值便是效能与质量，一方面将整个软件研发流程自动化，降低人力成本，另一方面提供了相应的质量检查与测试工具，以期建立一个完整的质量度量体系。
酒店研发引入公司CI/CD解决方案，建立完善的准备环境/测试/资源构建/镜像构建一整个流程的链路，使它可帮助项目以更快的速度和更高的质量来交付。
以大住宿某前端研发团队的流水线为例，团队从以下三个目标出发：
代码效能
产品功能
产品性能
通过设置代码规范检查，单元测试、UI测试、性能测试等任务来提升自动化覆盖率，提升集成效率，强化整体代码质量，提前发现问题，最终实现加快交付频率的目标。并通过采集流水线数据，可视化项目流水线执行概况、近期质量趋势，帮助团队用数据思考，利用数据，持续提升效率。
小结：OKR工作法保障团队方向正确；MVP实践帮助团队聚焦目标价值；敏捷实践专注快速交付价值，拥抱变化；DevOps助力快速交付，强化自动化能力。四大措施持续改进，最终达到研发效能提升的目的：持续快速，高质量地向用户交付产品。
六、如何衡量研发效能得到了提升？
管理大师彼得·德鲁克还说没有度量就没有管理。度量最重要的目的是洞察出问题，进行指导改进，并衡量改进的效果。数字化时代的到来，很多企业已具备自动采集效能数据以实现度量所需的各种实时数据报表。大住宿在去年接入公司统一产品研发管理平台IDEV后，不仅提高了产品研发过程的透明性，也率先实现了需求数字化管理。
大住宿借助大量的客观数据从目标、价值、质量、效率这4个维度的进行分析找到团队的痛点，并引导团队做真正能解决问题的行为来持续改善。
1. 核心目标占比
核心目标价值的占比帮助团队对齐目标和资源整合。我们通过目标管理工具，规范需求与目标的关联，再通过度量单位时间内围绕目标的交付需求占比来反映团队的目标对齐度。试点实践中遇到最大的问题是数据的失真。数据的准确与团队关联目标的规范息息相关，需要通过对团队进行不断的培训和宣导来帮助团队养成习惯，以此保障数据的准确性。
2. 需求价值指数
需求是价值的承载体现，假设交付需求均具有价值，那么交付需求的数量越多，代表交付的价值越多。但单以需求个数无法很好的反映团队的交付价值。每个需求的规模和价值大小不一。比如单位时间内可能只交付了一个收益很高的需求，并不能说明团队的产出变少。团队需求价值指数从更客观的维度衡量团队在单位时间内是否产出高价值的内容，以此杜绝高成本低收益的投入。需求价值指数由团队负责的需求个数、人员数、预估价值、实际价值、需求价值正态分布情况等综合评估得出 。
3. 交付质量
研发交付质量是指用户感受到的质量，可以理解为线上用户保障的缺陷。影响交付质量的一个重要因素就是交付过程质量。大住宿主要以单位时间内的缺陷数量趋势来衡量团队交付质量。为了降低缺陷数量，研发团队通过质量内建、提前验收等各种方法来前置保障交付过程质量。并通过分析线上以及过程缺陷，进行归因改进。从自动化，Mock工具、开发自测等各个方面着手落实改进措施，持续提升交付质量。
4. 响应能力
需求的响应周期和团队持续发布的能力体现团队的持续和快速。交付周期指对用户需求、业务机会的响应速度。酒店研发采用从创建需求开始，到需求上线所经历的平均时长来度量交付周期；通过开始code到发布上线所经历的平均时长来度量开发周期；通过单位时间内的有效发布次数来衡量团队对外响应和价值的流动速度。经过一段时间的优化改进，大住宿2周内交付的需求占比呈稳定提升趋势。
七、总结
我们可以通过各种措施来提升改进，但研发效能的提升没有“银弹”，研发效能的提升没有最好，只有更好。需要我们从目标、价值、质量、效率每一个领域都进行深入地挖掘和思考，共同努力把持续改进的焦点从局部资源效率转向价值流动效率，以此保证全局和系统的持续优化。
OKR工作法：上下同欲、对齐目标
MVP实践：共识价值，消灭浪费
敏捷实践：敏捷升级，助力效能
DevOps实践：提升质量，加速交付
大住宿依然在探寻更好的效能提升方法的路上，就像敏捷宣言中提到的“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。”也希望本篇浅浅的实践总结可以帮助到对研发效能有期待有困惑的你。