敏捷给我推开一扇门

前言

我上一次分享敏捷相关的话题是在RSG大会，当时大会设置了多个分论坛，让每位嘉宾做一分钟的拉票，我的拉票发言是：“如果你想要升岗升职就来听我的报告。”今天我分享的主题是《敏捷为我推开一扇门》，这扇门就是事业提升的门，其中包含了我这些年做敏捷的感悟，跟大家一起交流。

敏捷经历和成长故事

最开始做敏捷的时候我们是花了很多心思的，因为当时公司也不知道该怎么着手，我就自费去考了几个认证：CSPO、CSM、SAFe、CAL，我在申导（优普丰）这边上完认证课拿到证书后，说服公司支持其他同事也去参加这些培训。

最先参加的是CSPO的认证培训，我觉得这个认证特别好，一下让我进入到一个新的状态；然后是Scrum Master（CSM）认证；最后是CAL，CAL让我在领导力方面有了很大的提升，它在很多地方都可以用到，如果你通过了Scrum Master（CSM）认证，建议领导力的CAL认证培训一定要参加。

在公司内推行敏捷的这些年，沉淀了经验，开阔了眼界。我作为核心编写人员参与了《研发运营一体化能力成熟度模型》标准的编写，并担任敏捷开发管理分册的编写组长。我们在敏捷转型过程中总结的“FAST+”体系获得了国家企业管理创新二等奖。

我经常受邀去大会、活动做分享，最早是分享敏捷相关的主题，近期分享的主要是云计算、算力网络、算力服务等相关的内容，因此我说我已经“离开”了敏捷。今天主要分享的是我自己在企业敏捷转型中不同阶段的成长故事及离开敏捷领域后对敏捷的思考。

2014年进入敏捷，2017年“离开”敏捷，这是我做敏捷的整个过程。在实施敏捷的过程中，公司也得到了成长，但成长不是一蹴而就的，经历了失败和不断探索、总结，最后形成了典型的FAST+2.0体系。

开始的时候，我们找了2个项目使用敏捷产品方法做试点，都失败了，因此产生了困惑，是不是敏捷不适合我们？当时我们请了外部教练来辅导，后来发现，带教的教练没有真正了解我们的业务，很多时候是闭门造车，所以教练一定要跟团队、业务一起深入结合。

后来我们跟申导一起合作，把团队一点点带起来了，包括搭建看板、DevOps/Jenkins等工具平台，帮我们梳理出比较清晰的路径和方法，那段时间我们几乎每天待在一起，我觉得这个非常重要，教练跟我们在同一个环境、同一个业务场景下工作，更深入了解实际的情况，也能及时进行辅导和纠偏。

再往后，上升到大系统层面，整个效率提升了很多。那时我们的系统还不是敏捷系统，而是一个巨石系统，正常日常开发是六七十人，我们希望使它敏捷起来，走向云化，因此就要把系统拆小。这个过程是并行的，一边对系统进行拆分，派过去1/3的人负责拆分的工作；一边保证系统正常运行，剩下2/3的人完成日常工作。可以说通过敏捷的方式，效率提升了66%，因为2/3的人承担了原来所有人的工作。通过这件事，我们觉得敏捷确实非常有效果，也因此顺利将敏捷推行到了更大的框架和系统。

在2014-2017年推行敏捷的过程中，我的个人岗位也发生了变化（编辑PS：保护隐私，“升岗”相关内容限现场的小伙伴听^_^）。很多经验和沉淀都是在这个阶段积累的，压实了很多敏捷相关的东西。

我从最开始做开发写代码做需求到做敏捷，发现把整个团队带起来、团队效率要提升，这个是关键，也就是说做敏捷一定要有投入产出比，公司才会有资金或资源支持。

从效率提升来看，做完敏捷的下一个阶段是做能效平台，让其他团队的效率都能得到提升。

这还不够，再下一个阶段就是做云计算，你会发现当你把业务代码做到更小的时候，下面底层能力全都是你搭建的，你就可以提供更高效的能效平台。

做完云计算后，发现还不够，因为我们不是为了开发人员而做效能提升，我们是希望能做到整个社会的效率提升，这时候我们就要做一个更庞大的东西——算力网络，任何一个数字化转型都需要算力，就像水和电一样，当算力成为基础，且随手能取用，整个社会的效率才能得到最大提升。为什么是算力网络而不是云计算呢？因为云计算只会提供算力，但算力到你家能不能像水龙头一样打开就能用，这就需要网络来承接。

大家都知道，算力是IT的产品，网络是CT的产品，IT和CT有一个很大的差别：IT是敏捷的，是不稳定的基础设施，而CT讲究的是稳定，做什么都是固定不变的。算力网络的核心是算力和网络组成一个整体，那这时候就要求CT做出改变，因为VUCA时代，业务越来越敏捷，CT也需要变得更敏捷，来适应变化。那怎么做呢？我们做的是算力网络云化，做可编程的CT基础设施。

然后我们发现，让运维团队去做大规模的这种弹性的网络运维有点吃不消，必须用到人工智能的技术来做这件事，这时我们就开始做自智网络。

纵观整个发展和实施阶段，我们可以看到，一切都在围绕着做敏捷时定下来的目标：让效率更高。从为小团队提升效率到现在服务全社会的效率提升，敏捷给我打开了一扇门。为什么我可以快速且持续地晋升，就是因为我每一步都知道自己将来要干什么，而且始终可以与公司的战略目标保持同步。

FAST+体系

前面提到了FAST+体系：

F-Framework，大IT架构：规划企业级大IT架构，打造大中台、小前台技术架构，驱动组织变革，实现开发运营一体化。虽然现在阿里说在拆中台，但是我认为拆中台的核心是很多东西可以往下沉淀。

A-Agile platform，敏捷能效中台：通过建设敏捷能效中台，在技术上支持需求、开发、测试、运维过程的自动化、可视化，实现需求管理、代码开发测试、运维的端到端管控，加速IT软件价值交付的效能提升。

S-Scrum，Scrum流程：借鉴敏捷Scrum流程，重塑需求模式、提升上线频次、加快开发流程等，提升业务价值速度。
T-Test operation，测评驱动运营机制：以研发运营一体化成熟度标准为助手，建立测试驱动运营机制，持续推进研发过程不断改进。

+，微文化：营造DevOps微文化氛围，通过ETC、培训认证、机构推进、社区活动等，提升全员DevOps理念。

7个感悟

01企业的真正目标是赚钱

在讲敏捷故事的书里，我个人比较喜欢这一本，它给了我一个观点：在任何一个企业，做任何一件事情，你一定要想着帮企业赚钱。前面我说了很多次目标是提高效率，其实提高效率、提高协作、减少浪费这些都不是最终目的，你在企业做的任何一件事情，都是要帮助企业赚钱，这才是关键和最终目标。

在这本书中提到一个故事：工厂里引入了一个人工智能的东西，但是发现这个东西影响了整个效率，因为它自己环节做得更快，导致积压，积压也是一种浪费，这就相当于整个工厂的效率没有提升，没有更好地实现赚钱的目标。

建议大家都懂一些财务知识，这对升职很有帮助，这样你才知道企业怎么赚钱，才能更好地匹配公司目标。

02人力资源从服务业务到指导业务

前两天去上了一个人力资源相关的课，我发现现在的人力资源和以前有很大不同。原来的1.0时代，只要把招聘、培训做好，现在都发展到人力资源4.0时代了，要求为业务创造价值。人力资源从服务业务的角色，向了解业务、指导业务的角色转变。

映射到敏捷，我认为Scrum Master在团队中就类似人力资源的这样一个角色，负责把整个团队运营得更好。你要从原来的做基本的服务团队的事情，比如QA等，转变为做指导业务的事情，最后把干系人（或者说主要利益相关者）全部拢在你周围，你是主导。现在整个组织架构都在发生变化，这些变化和对应的策略在Scrum里都能找到。

说到这里，我想推荐一本书《敏捷革命》，如果你想要了解敏捷肯定要看这本书。很多年前看的时候，书中有一句话让我印象特别深刻，大意是：甲方和乙方将成为一个整体。它说如果一个项目有甲方和乙方，站在乙方角度，以后承接项目能不能不要按多少人天去算工时，比如一个原本计划耗时一年的项目，乙方承诺2/3年干完，甲方只需要结算2/3或比这个多一些但不到全部的费用。这样一来，乙方节省了时间、释放了人力，可以去投入到其他项目，他会愿意把MVP或更好的功能往前交付；对甲方来说，节约了成本，也节约了对接和验收的时间。双方在寻找一种利益一致的平衡，这很重要，我们做任何事情，就是要能够使所有人的利益和目标保持一致。

在Scrum团队中也是一样，首先所有干系人要达成一致，每个人的想法思路都是围绕团队目标的，即怎么一起做好同一件事。

03敏捷让人更自信

2014年之前我还不是很自信，以前我都没想过自己会参与国家标准的编写，也没想过会拿国家奖项，我甚至都没上台演讲过。做了敏捷以后，我才开始逐渐走出来分享，现在面对上千人我也可以自如地演讲。

有一句话我特别认可：你能走多远取决于你的见识。一定要增长自己的见识，以前我经常参加活动，去各种活动和论坛学习，一个下午的时间，哪怕只听到一两句话是受用的，也很值得。

见识打开以后，要做什么呢？我经常跟我的团队说：我们要看3年，做当下。一定要看到将来的东西，这样才能永远站在潮头。

04人人都要成为产品经理

我做敏捷是从PO开始的，因为我认为公司里每个人都要成为产品经理，“人人都是产品经理”。

这本书里说，为什么工业时代的企业没有产品经理，因为整个公司就做一个产品，总经理就是产品经理，要做市场定位，通过工人实现，不断打磨迭代；互联网时代可以同时做很多产品，才把产品经理岗位从总经理身上剥离出来，做用户需求挖掘、产品设计，通过工程师实现。产品经理等于CEO，如果你能干产品经理的活就意味着你干什么活都是可以的。好的产品经理需要洞悉人性，要像总经理一样考虑周全，好的总经理也必须是好的产品经理。

产品经理根据其能力水平可分为ABC三个等级，对应具备的特质和能力如下：

A类：有深度思考能力或超常同理心，且具备批判思维。

B类：逻辑清晰且有产品心（工作中感受乐趣）；

C类：逻辑不清晰、同理心弱、缺乏职业热爱、自我认知过高、缺乏好奇心、不愿意改变、缺乏实践精神。

其中批判性思维非常重要，如果说产品经理只学一个东西来获取最大成长，那一定是批判性思维。从应试教育中长大的缺少批判性思维的人，如果转变成有较强批判性思维的人，就是最显著的成长。

产品经理还有一个重要“武器”——精益创业画布。这也是在CSPO的培训课上学到的，我一直在用。

做一件事情最重要的是团队的对齐。我们做云管平台的时候，都快做一半了，我发现不对，然后赶紧用精益创业画布重新梳理：

首先是问题。平台要解决3个问题，大家拿便签纸每人写3个，当时团队骨干大概十来个人，结果不重复的问题就写了27个，这样做出来的产品怎么可能是好的呢？目标就没有对齐。我们一个个排除，最后剩下4个问题。

然后是目标客户。我们通常泛泛地认为目标客户就是用户、使用者，这是不对的，要有针对性地对客户进行分类和定义。

05系统思考的能力

我们的思维方式往往很直接，不习惯做拆解，比如倒水，很简单，水龙头一开就水就来了。但是如果你用系统思维去思考的时候，你会发现它是可以拆解的。

它是一个环路，你想要的水位、感知水和杯子的差距、可以调整水龙头控制水流的大小等等。事情只有拆解后，你才能知道哪个点有问题，才能有针对性地去解决，如果没有找到问题点，就只会浪费时间和精力，问题还是解决不了。写文章、写报告的时候也是一样，如果找不到关键点，不妨多运用系统思考。

系统思考是把所有的东西分为两部分：一个是变量（要素），一个是调节变量之间的因果关系。这两样拆解以后，你要去做不同的变量的事情。

举个例子：分粥。我们要把粥分匀。日子久了肯定谁来分配谁就分得最多，怎么办呢？

一种方法是，找一个老者来分，看上去他最公平，实际上他也没办法做到公平；第二种方法是，每天换个人来分；第三种是成立一个委员会来分。最后发现，还不如碗都放在这里，分粥那个人最后拿，这样他肯定分得很均匀，要不然他自己的碗里最少。

我们改变什么得出这样的结果呢？从2个变量（人和粥）变成了3个变量（人、粥、碗），所以变量很重要，当变量发生变化的时候，变量之间的因果联系也改变了，解决问题的办法也就出来了。这就是系统思考。

最近我带了一个CT团队，他们还不太懂IT，所以我重新组建了系统分析流程、项目建设文档。把项目建设文档拆解出来最重要的是三幅图：功能架构图、逻辑架构图、系统部署图。我的团队只要给我这三幅图，我就知道整个东西大概是什么样子，成还是不成。

Cynefin框架把世界分成五类：简单的、复杂的、繁杂的、混沌的、无序的。针对每一类有其解决方法。很多问题，通过系统思考去解决的时候，需要先知道它属于哪个象限，怎么解决它最好。

06PPT六段论，用写PPT锻炼自己

如果你在公司不写PPT，我会认为你的成长可能会比较慢，因为写PPT其实很锻炼人。我总结了PPT六段论：现状、问题、分析、目标、解决方案、计划。只要你能写清楚这六个方面，老板肯定觉得OK。

不是每个人都能写好这六段，我之前收到一个关于云网络运维的PPT，也包含了这六段：现状是网络运维的难度很大，我有多少个设备、多少东西，我管的东西太多了；问题是我很难管；分析难管的原因是我缺少工具；目标是建个工具；然后解决方案…

为什么不行？还回到这个云网络运维的PPT，现状应该是因为网络问题公司损失了多少钱，比如去年出了5次故障，每次故障损失了10万元，去年一共损失了50万元；目标是我现在要做的事情是要让这个损失减少到20万。这样老板一定会给你投资，因为最后的计划肯定是跟钱相关的。PPT一定是跟企业完全相关的东西，要围绕企业怎样创造利润。

07四个之旅

标签之旅

员工对企业的价值大小 = 经验等级x平台匹配度x等级。而决定价格(交换价值)的三要素是有效用、被认知、稀缺性。

如果想让自己获得高价值（价格），有三种路径。一是要提高自身能力，使自己对企业更有效用。二是让更多的高管认识到自己的价值有哪些，有多大，你属于只此一份。三是发展自己的稀缺性，优先发展那些企业急需但市场供给不足的能力。

创新之旅

看3年，做当下。创新目标要有根弦：效益、效率。创新不在大小，关键你是给企业赚钱的。

转型之旅

一定要人人都成为产品经理，培养产品经理的思维和能力。

英雄之旅

个人成长曲线基本和Gartner技术成长曲线一致。刚开始很嗨，觉得自己很厉害，经过挫折后发现有更厉害的人和事，会有一些失落，然后通过学习和练习，得到成长。

结尾

最后我想说：心里有火、目中有光、脚底沾泥、眼望星河。做事情一定要热血，看到东西赶紧上，两眼放光，干活要脚底沾泥，脚踏实地，同时也要能够眼望星河，看到将来的发展。