关于甲方敏捷教练6大职能的思考丨IDCF
共 8976字，需浏览 18分钟
·
2022-07-22 13:10
来源：敏捷DevOps那些事儿 作者：杨久成
敏捷教练是企业敏捷转型过程中非常重要的角色，除了基本的敏捷团队辅导和转型推动工作之外还有很多方面的工作都是需要关注的，这一篇就来简单探讨下敏捷教练在转型过程中可以从哪些方面帮助个人、团队、组织和企业。
笔者认为敏捷教练需要从敏捷度量、敏捷教练基本能力提升、双模研发体系搭建、敏捷转型推动者、敏捷文化建设和研发效能改进6个方面考虑自己的定位，虽然在不同的企业背景之下可能存在差异，但是当你具备了这6个方面要求的能力后，个人的敏捷之路会很好走，企业也会因你的存在而真正受益。
敏捷文化建设
兵马未动粮草先行，转型未动文化先行，文化的塑造是敏捷转型非常重要又非常困难的一点，我们都知道文化转变是一个长期努力的过程，所以更应该尽早从这方面入手，通过COP（community of practice）打造企业敏捷文化。
在一些企业中会聘请外部咨询顾问进行敏捷转型推动，但是有一点必须要认清，外部咨询顾问毕竟是外来的和尚，外来的和尚总有离开的一天，敏捷文化建设还要靠自己！所以内部敏捷教练就要承担起这样的责任，除了社区的建立和运营还可能包括培训活动、开展工作坊、内部教练培养体系搭建等活动。
概括来说敏捷文化的打造可以帮助我们实现敏捷技能提升、知识共享、促进过程改进和打造创新能力等多个方面的收益。
而敏捷教练需要重点关注社区运营时开展的活动必须形成节奏，而不是三天打鱼两天晒网，员工参加社区活动可以获得个人成长，有了成长空间才会持续的参与继而为社区的成长助力。还有最重要的一点是社区的运作最终一定要考虑到为业务赋能，近些年大家都在谈论业务敏捷的话题，社区也是一样的道理，自己玩的多开心不重要必须能够为业务赋能帮助公司创造价值，领导才会持续的给与支持。
敏捷转型推动者
这个是比较容易理解的一个方面，敏捷教练必须要承担起企业敏捷转型的推动工作，这里只想强调几个需要关注的方面：
敏捷教练需要以敏捷的方式推动敏捷，这句话意味着作为敏捷教练你嘴边总挂着敏捷一词，自己的行为是否真正的敏捷呢？
你是不是也按照迭代的方式在推动转型的进展，是否起到了以身作则的榜样作用？
规划敏捷教练培养计划，这一条在上一个段落中也有提到过，敏捷教练需要关注的重点是敏捷教练的培养不只是做几场培训，分享几篇知识普及的文章那么简单，需要建立敏捷教练团队的使命、价值观以及敏捷教练的升级体系和制度，包括星级评定、积分体系，甚至是证书颁发等细节。
敏捷教练需要为敏捷转型过程中遇到的障碍找到解决方案，我们知道scrum master是帮助团队消除障碍的，那敏捷教练就是为转型工作消除障碍的关键角色，包括找领导申请资源，协调专家团队支持等活动。
精益和敏捷都关注杜绝浪费，作为敏捷教练需要从更高的视角进行思考，比如如何打破团队简仓，进行端到端的价值流优化等，从完整的流程和整个组织的层面帮助团队进步和成长。
那么当一个企业开始推动敏捷转型时，内部的转型推动者需要如何与外部顾问打好配合，助力敏捷转型顺畅推动呢？下面某企业的转型案例中内部教练在不同阶段的工作内容或许能给您带来一些启发：
（1）调研和方案 一般来说如果已经确定了敏捷转型的大方向，外部顾问就会启动需求和现状调研工作，在这个阶段内部推动者需要协调好调研工作，包括调研计划制定、调研会议组织、调研方案初审和评估以及方案材料编写和汇报等，在这个过程中外部顾问起主导作用，很多工作内部推动者处于配合的地位，但是也会有一些工作需要内部顾问给出合理的建议，毕竟外部顾问对企业现状的了解程度无法通过几周的调研了解透彻，内部推动者的配合是助力转型成功的关键因素。
（2）组织架构调整 在企业转型过程中，很多情况下都会需要相应的调整组织架构以促进变革效果的达成，所以在这个过程中需要内部推动者协助内部组织架构的调整工作，包括组织架构信息、人员信息、角色定义和迭代机制确认等工作。
（3）培训阶段 前面两个阶段的工作完成后，按理来说就到了万事俱备只欠东风的程度了，所谓的东风就是一系列的培训工作，培训会针对不同的阶层和群体有不同的规划和课程内容设计，过程中内部对接人需要做好培训组织、培训效果评估和费用报销等工作；
（4）Quickstart 敏捷转型没有一蹴而就的，所以不管是从甲方还是咨询顾问的角度都希望能够通过快速启动获得一些收益，在这个阶段内部对接人需要协助外部顾问对具体试点的团队进行流程和运作机制等方面的调研，以我个人的认知来看选择一些对团队变革较小的方法和实践会较容易启动，比如说Kanban方法对团队的改革就相对较小，但是反过来说我们也不能为了对团队变革最小化而盲目的选择敏捷方法和框架，具体的选择还要从整个组织的层面结合敏捷转型整体方案进行思考和设计，当以上的内容都明确后在具有一定规模的组织中还需要签发一些宣导类、流程规范类文档，这个过程很有可能是外部顾问、内部对接人、PMO、EPG等多个角色共同协作来输出必要的规范和材料。
（5）试点落地 各方面准备妥当后就可以开始试点工作了，内部对接人需要重点关注试点进展和效果评估，要做好对领导层的信息同步和汇报工作。
（6）持续改进 随着试点取得一定的成功，敏捷转型的范围需要进一步扩大，会有更多的团队加入试点范围，也意味着外部咨询公司需要投入更多的顾问提供咨询和辅导工作，但更重要的一点是我们应该同步制定内部教练的培养计划，内部教练培养要提前做好规划，理清内部教练的基本职责，确保在外部顾问离场后能够顺利的完成工作的承接。可能有的朋友会问为什么到现在才开始内部教练的培养工作，这一点基于几个原因，第一是前期工作内容较繁杂且时间紧迫，无论是外部顾问还是内部对接人都没有过多的精力进行内部教练的培养，虽然可以尽早规划，但是具体的实施还是要放到这一个阶段，第二是当试点的效果还没有体现出来时，如果采用报名制的方式招募敏捷教练，目前的工作成果还不具备说服力，所以容易出现大家兴趣度不高的情况，第三是前期试点过程中对敏捷教练的需求量还不是很大，敏捷教练的工作内容有限，对组织和敏捷教练个人来说都会产生一些浪费。
双模研发体系搭建
为什么会有双模研发体系？敏捷就是敏捷为什么还要双模？首先，当组织大到一定的程度，敏捷转型是一个漫长的过程，在这个过程中必然存在新旧两种研发模式并存的情况，甚至会出现在同一个项目中采用多种研发模式的混合模型，另外即使组织已经完成了敏捷转型也必然有一些场景不需要或者不是一定需要通过敏捷的研发模式交付，在之前的文章中我们介绍过Cynefin模型，所以我们知道敏捷也有它的适用范围，在不同的情景下需要按需使用敏捷实践，那具体会产生哪些需要双模研发体系的场景呢？我们来看一下下面这幅图：
敏捷+瀑布模式 不是所有的企业都会具备条件全面推行敏捷，部分企业会考虑到企业的现状，在转型初期只是采用部分敏捷实践，或者是部分项目采用敏捷方式，而另一部分项目还是采用传统的瀑布式方法进行管理，所以就形成了“敏捷+瀑布”的双模研发体系；当然还有一种比较特殊但是很常见的情况，就是在所谓的迭代周期内跑小瀑布，虽然已经实现了1-4周的迭代周期，但是在迭代中还是遵循了需求、设计、开发、测试等瀑布式的流程，距离所谓的流式开发还有很大的差距，但是反过来看也算是有了进步，毕竟客户反馈的周期还是变短了，只是苦了搞研发的朋友们，以前几个月一次加班赶工现在变成了常态，所谓循序渐进，或许对很多企业来说这也是一条必经之路吧。
先敏捷后瀑布 部分项目可能工期很长，在项目的早期因为部分因素导致项目存在不确定性和风险，所以前期采用敏捷的方法推动项目，当项目不确定因素消除或者风险都已解决后，因为各方面都比较明确，加之环境也比较稳定不存在过多的变化，所以后期还是回到了瀑布式管理模式。当然也可能是因为产品投入市场没有达到预期的效果，但是又存在一定的存量用户，当市场和竞争对手都没有给我们施压时，更多的是依靠我们的业务和产品进行规划和创新，所以完全可以规划清楚后再慢慢投入市场，也就走入了瀑布式的开发模式，但是笔者还是建议即使是以上的情况，尽量多采用好的敏捷实践还是会从中受益的。
瀑布为主，敏捷为辅 在一些传统瀑布式管理的项目中，当遇到一些未知因素时会按需采用敏捷研发模式以应对充满变化的情况，或者是在整个项目稳步运作的前提下，组建一支小团队进行创新试验，看到创新这个词采用敏捷模式肯定比瀑布会更加有效。所以就形成了“瀑布为主，敏捷为辅”的双模体系，通过瀑布式推动项目进展，通过敏捷创新小队对方案和架构设计进行快速试错。
敏捷为主，瀑布为辅 从规模化敏捷SAFe的观点来看，我们期望供应商是敏捷发布火车上的一部分，所以最好的状态是与所有团队的节奏保持一致并按需交付，但是在实际的情况中有一些供应商并不能完全按照甲方的要求保持同样的开发方法和节奏，所谓的甲方爸爸这时候也变成了干爹，当然可能有很多客观因素导致了这一现象的发生，比如供应商不具备敏捷研发能力，供应商产品有特殊性不适合甲方的敏捷模式，也可能是供应商产品化成熟度高没有必要，总之这样的情境之下供应商按照自己喜欢的方式进行功能开发与甲方形成了“敏捷为主，瀑布为辅”的合作模式。这样的场景需要甲方对供应商的交付能力具备信心，同时在部分实践中要求供应商做好配合工作，比如每次版本发布后都要求供应商参加我们的评审会，并结合我们的产品进展评估供应商所处的阶段和对应的设计与未来产品的匹配程度，加强沟通和反馈才能避免因为供应商的进度延迟影响整体项目交付。
敏捷教练能力
这一条说的是敏捷教练最本质也是最基本的能力，参考敏捷教练能力框架敏捷教练需要具备4个方面的能力：
通过精益敏捷知识的运用和实践能力帮助客户按照敏捷的方式开展工作；
通过教练和引导能力帮助客户（教练对象）找到自己需要关注和改进的方向；
通过教导和辅导能力传授给客户知识和能力以帮助其成长；
通过技术、业务与转型方面的硬知识的运用并结合以上的教练、辅导等能力更好地帮助客户解决问题，这里多说一句，技术方面不是单纯的懂一些技术而是可以运用敏捷工程实践为团队提供指导，业务方面也不只是懂必要的业务知识，而是可以运用业务敏捷的的探索方法为业务发展助力。
图片来源：https://agilecoachinginstitute.com/
在很多企业敏捷转型的初期，内部敏捷教练团队的水平还较低，更多的敏捷教练还处于急需补充敏捷知识的阶段，其他方面的教练、引导等技能都需要在后续慢慢的学习和实践中积累，而敏捷知识的学习我个人的观点是可以尽量集百家之长，可能一家企业运用的敏捷方法和规划化框架都是非常明确的，但是作为敏捷教练需要掌握尽量多的知识体系，很多框架即使在你的组织无法落地，框架里学到的知识都可以给你更多的视角和指导作用。
除了以上的内容之外，作为敏捷教练需要时刻谨记一句话“读万卷书，也要行万里路！”，敏捷学习这条路就像坐上特斯拉——根本停不下来，同时理论需要与实践结合，只有不断实践才能真正成长并不断积累经验更好地为团队赋能！
在我个人所经历的组织中，教练团队的运作一般需要关注如下的几个方面：
（1）协作机制 敏捷教练团队成员间需要建立基本的协作机制，作为一个高效运作的团队，可以考虑建立微信社群来满足快速沟通和交流的需求，通过confluence等工具沉淀团队过程资产，同时定期的例会和团队建设活动也是必备的交流方式。
（2）活动类型 除了辅导团队工作之外，敏捷教练需要通过各种各样的活动在提高影响力的同时持续为团队赋能，可以通过线下的工作坊、线上的直播活动、定期的公开课加强与组织中各部门和团队的交流；而对于敏捷教练团队内部也需要开展知识竞赛分享和定期的教练评级活动以提高团队的技能水平。
（3）教练体系 谈到教练评级我们就来说一说教练的认证体系，一般比较常见的是把教练分为认证教练、资深教练和首席教练三个级别，从服务层级上对应到团队层、部门级和组织级，内部教练需要建立完善的晋升机制促进教练队伍的成长，常见的晋级形式包括积分制、答辩评级等。例如说积分制，那如何获取积分，是通过培训和工作坊的交付数量还是通过辅导团队获得的评价等级进行积分？类似的机制都是需要考虑并逐步建立起来的内容。
（4）传播渠道 敏捷教练队伍和其他的团队有区别，需要通过自己的努力不断的建立影响力，所以可以依靠各种方式和渠道将敏捷文化渗透到各个团队中去，可以采用的方式包括活动月刊、实战案例分享、度量和评估数据传播等。
敏捷度量
度量永远是一个逃不过的话题，在传统项目管理中有所谓的项目管理四大金刚即：进度、成本、范围和质量，从度量的角度去分析就是需要做到多快好省，下图中按照多快好省的维度罗列了很多度量指标，但是我想表达的观点是，指标虽多却不可照搬和复用，每家企业都面对独特的环境，每位领导关注的度量指标也会有所差异，所以度量指标的好坏应该以是否能够帮助企业发现问题解决痛点为目标。
度量指标没有办法照搬，但是度量的基本原则却可以参考，下图中的内容表达了我对度量的一些观点：
首先，度量工作必须站在较高的维度通盘考虑，一个组织就是一个系统，这就要求我们站在系统思考的层面关注到企业完整的端到端价值流优化，而不是双眼紧盯某一个职能或团队把资源利用率发挥到极致，组织中常见的现象是开发只关注开发流程，测试只关注测试流程，大家都认为自己的工作已经做得非常好，但是领导并不满意，认为产品交付速度慢质量也不过关。
其实，我们需要把目光从个人绩效的提升转变到团队的发展和成长上来，传统的运用KPI的硬性考核指标约束的思路已经不适用于知识工作者的管理，我们更多的需要为团队成员提供安全的环境和可发展的空间。
第三点是需要长期的积累度量指标，关注指标的趋势变化而是不是单纯某个数值的大小，有些团队的指标一直很棒，拿出任何一次数据来都比其他团队要优秀，但是如果整体趋势上已经出现缓慢下降的情况就意味着已经有隐藏的问题点需要我们挖卷并想办法改进。
最后一点是关于技术精进，技术精进虽然很重要，但是技术的精进归根结底还是为业务目标服务的，只有保证客户满意度高才是真正的有价值，所以我们需要从业务视角出发去度量技术指标保证度量工作的有效性。
下面分享一个企业中常见的度量流程，供读者借鉴和讨论：
（1）度量工作的第一步一般是确认度量指标，其实在企业中度量指标并不是按照顾问、专家和教练的设想一步步建立的，常见的情况是领导会提出他认为重要的指标，相关角色需要结合领导的观点和自己的经验进一步的进行细化，另一种现象是基于问题产生的指标，比如最近发生了一些生产问题，高层会特别关注同类型问题的预防和规划，继而会产生具有相关性的一系列指标，敏捷教练的知识和经验固然重要但同时一定是要和组织的目标和领导的期望相吻合。关于与领导的期望相吻合不代表我们要拍马屁，领导关注的我们就重点去做，而是因为当你的组织规模大到一定程度后，不同层级间的信息差较大，我们需要利用好领导的视角，作为度量的切入点重点关注。
（2）第二步是确认数据的来源，数据最好的来源必定是通过系统自动采集和生成的数据，不仅效率很高也避免了人为统计出错的情况，但是如果是领导突然提出的指标暂时在系统中无法生成，就需要具备专业知识的人员通过手工收集和整理的方式进行统计和汇报，同时如果指标确实有价值就要进行指标和系统设计确保后续可以通过自动化工具获得对应的指标数据。
（3）第三步是度量工作的培训，度量工作不是领导的事情也不是敏捷教练的事情，度量工作需要所有涉及到的团队共同努力和配合，首先要确保数据来源的可靠性，所以参与者需要理解度量的目标以及对度量数据相关工作的要求，同时负责人需要向团队宣导度量本身不是为了绩效考核而是期望通过度量活动促进团队的改进，因为当你试着通过度量进行考核的时候就应了那句话，度量什么你就得到什么，团队有各种各样的办法可以让度量指标看起来很漂亮，但是问题是否真的解决就不一定了，正所谓社会很单纯复杂的是人啊！
（4）建立检视机制，度量数据获取后往往需要经过专家的分析，同时根据指标情况与涉及的团队进行核对，度量分析和度量指标的汇报工作需要形成固定的机制，并且应该在度量活动开始之前就与所有的干系人达成一致，避免度量工作启动后受阻。
（5）最后一步是回顾和改进，度量工作需要长期坚持才能根据趋势发现问题并找到解决方案，所以需要定期进行度量活动的回顾和反思，不断运用更合理的度量措施并保证度量工作的有效性，而与此同时，也需要重点思考结合现有的度量数据是否有新的指标可以更好的体现团队真实状态，让度量数据更具价值！
研发效能提升
在谈研发效能之前，我想先和大家分享一个内容，在VUCA时代管理者思维应该发生的转变，VUCA时代带来的影响是竞争更加激烈，留给企业思考和规划的时间会更短，要想获得竞争优势就应该尽快的为客户交付价值，而回到管理者思维上来说就应该从关注output转变为关注outcome，按照以前的项目管理思路，我们需要确保项目按照既定的进度、成本、范围等约束顺利交付，如果以上的因素都能满足就能顺利拿到客户赏的第一桶金，而现在的管理思维应该从产品本身的角度思考，确保交付的成果能够解决客户问题，能够帮助客户应对市场冲击和变化，用彼得德鲁克大师的话说：“效率是以正确的方式做事，而效能则是做正确的事”。
敏捷和研发效能有着千丝万缕的联系，甚至很多公司的敏捷教练在组织内的职位名称就是研发效能改进工程师，一定角度上来说敏捷也只是提升研发效能的手段而已，企业可以通过敏捷提升交付效率和价值，也可以通过DevOps加速产品发布和保证质量，或者是找了一个新的称谓来帮助企业改变现状，只要最终效能在提升叫什么名字或者有没有名字都不重要。
近几年研发效能越来越受到重视，作为敏捷教练需要通过结合度量手段和改进措施帮助团队和组织提升研发效能，首先我们需要知道为什么现在越来越多的企业都开始关注研发效能这件事，现在，企业间的竞争越来越多的依赖于企业软件产品的支持，所谓软件正在吞噬这个世界，人们生活工作的各个方面都已经越来越离不开软件，所以现在的竞争不是我有软件你没有，而是大家都有的前提下谁能更快的交付，谁的质量更高的问题，那研发效能自然成为了企业关注点的重点。
图片来源：https://andrebartholomeufernandes.com/why-software-is-eating-the-world/
我对研发效能的理解就是“又快又好”而快起来的第一步就是要做到“对事不对人”，对事不对人意味着我们需要把目光从资源效率（对人）转变到流动效率（对事）上来，在《this is lean》这本书中作者提到一个效能矩阵的概念，如下图所示可以分成四个象限：
来源：TheEfficiency Matrix (Modig and Åhlström, 2012, p. 98)
第一象限是左下角的部分，流动效率和资源效率都较低是我们最不希望看到的现象，左上角的象限代表着资源效率很高但是流动效率很低，也就意味着大家都很忙但是产品交付可能并不能满足市场需要，右下角的象限意味着流动效率很高但是资源效率很低，虽然我们发现客户价值的交付已经达到到了一定的水平但是资源的利用上是存在浪费的，所以我们最期望的一定是右上角的象限，当资源效率和流动效率都很高时才能做到快速高质量的响应客户的需求。
另外一个很重要的问题是，我们会理想的认为如果企业处于左下角的象限，我们通过提高流动效率走到右下角的象限再不断的改进做到资源效率和流动效率的双高也就到了右上角的理想位置，但是在企业实际情况中往往当我们开始关注资源效率和流动时，已经处于左上角的象限，在这种情况下想要改进，需要先将资源效率降低才能一步步的由左下角、右下角再到右上角的理想位置，但是当我们提出这个观点时很难得到企业领导层的支持，毕竟降低资源效率看起来需要作出很大的牺牲，所以这也是企业研发效能改进的痛点。
通过以上的内容大家可以理解研发效能改进过程中，领导层的支持是非常关键的一个因素，那除了领导支持之外还有哪些因素需要重点关注呢？这些重点因素笔者结合自己的理解按照精益屋的方式整理成了下图：
研发效能精益屋的基础是文化，这个和我们敏捷转型的观点是一致的，同时文化不仅仅是文化氛围而应该是文化基因，从高层、中层管理者到普通员工都应该有一致的理解，研发效能改进不是领导给员工安排的任务，也不是中层管理者想做改变而得不到高层的支持，各个层级和角色都应该对研发效能这件事有同样的认识和态度。
中间的四个支柱分别是组织架构、领导力、流程改进和工程效能，在很多组织进行敏捷转型初期都会涉及到组织架构的调整，即是希望从组织架构层面进行改进以支持效能提升，而领导力往往是能够获取资源并顺利推动效能活动的关键，只是如果我们过于关注左侧的两个支柱效能精益屋是不够稳定的，因为左侧的内容看起来只是做了大方向上的工作不够具体和落地，而右侧的两个支柱恰恰是比较落地的内容，我们需要做好流程改进和优化并通过好的工程实践真正的帮助个人、团队和跨团队的活动提高效能，所以四根支柱一定是相辅相成的。
在效能精益屋的屋顶是以客户为中心，也就意味着效能的提升不只是科技层面的事情，效能的提高最终还是为业务和客户服务的，这样效能的投入才更具价值！
以上就是关于敏捷教练定位的一些观点，希望这些观点能够引起读者的思考和讨论，在您的敏捷教练生涯中或许不是所有的能力都是需要的，但是如果具备了以上的能力相信不管是敏捷教练、PMO、过程改进工程师还是研发效能相关的工作您都是可以胜任的。
同时，也欢迎对文章内容有建议和指正的朋友联系我，大家一起交流、学习和进步！
2022年首场将在美丽的海滨城市-大连举办，8月6-7日，36小时内从0到1打造并发布一款产品。
企业组队参赛&个人参赛均可，赶紧上车~👇
