DevOps案例研究：知人善任——Google敏捷核心文化

内容来源：DevOps案例深度研究-Google敏捷实践战队，本文只展示部分PPT及研究成果，更多细节请关注案例分享会。

本文内容贡献者：陈霁、刘翀、谈佳婧、张霖。

阅读干货前先感受一下热烈的氛围~

一、Google如何快速交付原型

1.1 Savioke公司实例

Savioke（公司真实存在，但公司名为化名）是一家刚创立6个月的公司。公司创立之初，大家都会思考一个问题：我们要做什么？他们的答案是：做智能机器人，并且致力于把机器人带到人类的日常生活中，如餐厅、医院和老人护理中心。

Savioke明确了目标并且通过这个目标获得了一笔融资，而公司要想存活并发展，需要准确判断和把握商机。产品已确定是机器人，那么要通过什么样的机会将这一产品推向市场呢？

他们发现在所有的酒店中存在这样的现状：在早上和晚上的高峰期，客人办理入住、退房、客房服务等各种需求会让前台人员焦头烂额，而这些需求和操作都是高频且重复的，这部分工作完全可以由机器人来代替，这就是机器人提供协助的绝佳机会。于是Savioke和百家连锁酒店达成实验协议，在这些协议酒店中引入机器人来解决上述痛点。

实施过程存在哪些困难呢？从我们自身出发，肯定首先想到的就是技术实现上的问题：怎么让机器人知道是哪个房间？机器人怎么才能通过电梯去到客人的房间为客人送东西？等等。

但团队发现其实更大的困难来源于场景：担心客户可能不喜欢递送机器人，也不确定机器人在客户面前会如何表现，毕竟机器人不可能表现得完全像真人一样，那客户会不会觉得机器人来提供服务这件事很诡异？比如下图右侧的图片来自一个电影《机械姬》看上去确实有些违和。

困难客观存在，实验的时间又非常短，只有三周，对于Savioke来说，这是用设计冲刺的好时机。最终结果如下图。

1.2 5天设计冲刺实例

设计冲刺-Savioke公司实例

还是以Savioke为例，详细拆解设计冲刺的过程。在机器人从实验到正式推向市场的三周中，最核心的只有五天，这五天就是在做设计冲刺，其中80%的时间在“设计”，技术实现只用了一天，剩下两周是原型优化和迭代升级。 

1）第一天，列出问题。

这个过程中的很多做法跟我们现在所说的用户故事地图很像，第一件事都是头脑风暴，把所有东西罗列出来。区别在于设计冲刺更专注于how级别的问题，而我们平时过早地把how转化成what具体的问题了。

第一天的问题罗列决定接下来所要做的范围。所以Savioke做了一件事，它选定了一个很常见的客户需求：酒店客人忘记带牙刷。围绕这一需求来进行功能设计，这就是所谓的MVP(最小可行性产品)的理念。

要完成机器人为客户递送牙刷这一服务，这一过程中包含的角色有四种：客人、酒店前台、机器人、其他相关人员。上图右侧是Savioke的机器人递送地图，详细展示了整个交付路径。

2）第二天，找出解决方案。

第一天把问题罗列好并确定下来之后，第二天就需要找出关键点，和对应的解决方案。罗列的问题和事情有很多，但不是所有的都要解决，不能给机器人设置过多的功能，而应该让它专注在某一个核心功能点上，解决关键需求。

3）第三天，找出最佳方案。

每个人都依据“闪电演讲”的方法对自己做出的场景规划进行阐述，比如机器人看到客人时是说“Hello”还是“Bonjour”（法语“你好”），是不是需要考虑面对不同客人说不同的话？

通过闪电演讲一共收集了23个方案，用HMW投票和结构化讨论的方式选出最佳方案，即上图右侧所示。

4）第四天，制作测试原型。

三天过去了，似乎一点落地的东西都没有，第四天开始制作测试原型。听起来似乎有些不可思议，三天做计划一天做出原型，但仔细想想是可能的，因为前面已经明确了要做的事情，Savioke就是一个成功的案例。

5）第五天，执行测试。

原型做出来后，第五天执行测试。这个测试不是把机器人直接放到酒店中心，随机服务客户，而是提前选择用户，并征得用户同意，与客户沟通好后，再由机器人执行给客户送牙刷的工作。机器人到门口后会先敲门，客户打开门后看到一个很可爱的闪光的圆柱体（机器人）。

上述就是Savioke五天设计冲刺的全过程，有几点值得注意：

• 我认为它是一个比较典型的业务驱动的过程，需要在短时间内交付产品，并且强调花一天的时间去验证。 

• 强调前面的设计过程，技术实现只用了一天时间，当然这取决于团队的技术基础，这也是后文将重点介绍的Google文化，业务敏捷和技术敏捷整合在一起，实现了Google敏捷化。

设计冲刺-实施准备

接下来我们通过几张幻灯片来看这五天设计冲刺的细节。

1.3 Google最佳实践总结-设计冲刺

这是一种用一周时间，把领导、开发者、相关专业专家聚集起来，从找问题到做出方案、制作原型，并通过用户测试的快速验证想法和试错的方式，设计冲刺非常适合用于业务初期，利用很短时间快速试错，验证方案的商业可行性。

适合的项目和成功案例如图所示。

1.4 设计冲刺带来的启示

对于我们这些并非创业公司的SM或者PM们，从上述案例中能学到什么呢？ 

实际上我们现在实行的CI/CD只是一个技术上的交付，并没有直接触达用户，敏捷的开发方式帮助我们快速实现价值交付的内环道，demo发布上线，还需要引入用户进行线上的灰度和体验。

用足以以假乱真的原型去替代我们以前做的内容，它会带来意想不到的效果。如果能够尽早做到真实性，且发起测试是在一个可控范围，得到的反馈效果会变得及时且有效。

在实施过程中，如果不能有效模拟出最终想要的效果，可以通过技术手段去规避和调整。

1.5 构成敏捷核心基础

Google具备两个特点：

• 业务敏捷性，强调在初期使用五天设计冲刺的方法快速完成原型制作和与用户的沟通。 

• 技术敏捷性，能够支撑一天制作出原型、两周把所有事情落地。

二、Google的核心文化

技术和业务是不可分离的，技术敏捷和业务敏捷共同构成了整个敏捷的核心。那么支撑整个敏捷核心的关键是什么？答案是文化。

2.1 选拔

在Google只招聘最优秀的人才。当然我们都知道要招优秀的人加入，但什么是最优秀的人才？Google如何招聘最优秀的人才？

2.2 使命

优秀的人才有了，如何让他们发挥最大的潜力呢？为工作赋予使命。

“地球上最有才华的人才需要能够激励人心的抱负。”通过赋予工作意义，更能激发和调动员工的潜力。

2.3 授权

人人平等和足够的授权，才能让员工有足够的发挥空间。只有公司基于员工充分的授权和信任，才能取得业绩提升。问题是如何让授权不仅仅是一个口号？

当管理者被限制起来以后，员工才能真正的被授权，做到员工自治。

2.4 培训

如何有效提升员工能力？

看数字很乐观，实际上，结果却是大部分的培训没有达到一个良好的预期，员工的行为并没有改变。为什么大部分企业做培训投入大回报少？

Google是怎么做培训的呢？在Google，培训是一种强目的性的活动。

2.5 激励

Google是如何激励员工的呢？在Google薪酬是不公平的，两个相同岗位的人员奖励却又百倍之差的情况。

2.6 绩效

Google如何评价员工？

评价员工最直接的方法就是通过绩效，当一个员工绩效不好的时候，如何对待他？传统公司的做法是：绩效糟糕要么走人要么好好干。Google是怎么做的呢？

2.7 Google的敏捷文化

Google的敏捷文化可以用16个字总结：以人为本、开放透明、互帮互助、有效激励。

三、Google如何构建团队

介绍了设计冲刺的实例和Google的敏捷文化，接下来简单介绍Google的团队结构。

3.1Google的 团队角色

我们较熟悉的Google三类角色：

值得注意的是：中间SET（也就是大家所说的测开）的角色已经不存在，这部分的工作主要是提供给软件开发工程师相关的自动化脚本测试支持等，现在大公司的一般做法是把测开重新调到工程效能团队，逐渐降低测开人员比重，提供平台承担相应工作。

3.2 Google的软件版本及发布规则

案例研究者介绍：