CI = 持续改进，DevOps 的动力源泉

本文要点

• 所有组织都需要不断改进

• 追求持续改进是 DevOps 最重要的目标之一

• 人们的恐惧心理阻碍了变化和改进

• 组织全体成员为共同目标努力是实现改进、取得成功不可或缺的要素

• 所有人都想做好工作；停止不必要且烦人的内部政治游戏！

这篇文章是我个人经历的一份报告总结。我的经历表明，组织内部的政治游戏和糟糕的企业文化不仅令人厌烦、浪费时间，还会损害很多组织的改进措施。我在很多组织中看到过这种情况，并且在个人的职业生涯中经历过两次这类负面影响。我曾目睹糟糕的企业文化残酷地扼杀人们想要改善工作状态的想法、浇灭人们的参与热情——想法甚至在还没公开之前就被抹杀掉了。当组织成员缺乏动力，缺少自由讨论新想法的机会时，组织也就错过了进一步发展的机会！我认为这种浪费简直令人难以置信。在 2018 年特拉维夫 DevOps 之日上，我根据这些经历发表了一篇演讲，并将在RebelCon.io 2019大会上再次发表演说。

“组织文化抢在早饭前就吃掉了改进机会”是什么意思？

Peter F. Drucker 的名言，“组织文化拿策略当早饭”这句我很喜欢。我认为这是每个组织都必须学习的基本知识之一。如果组织文化不支持组织的战略，那么这些战略从一开始就会过时。在不考虑组织文化的情况下制定战略是浪费时间和金钱，最重要的是白白消耗成员的动力。

我稍微改了一下这句话，因为公司非常需要“改进”的文化，我们 VUCA 产业尤其如此，这个行业中的一切都在飞速变化。我还添加了“之前”这个词，因为如果组织文化既不尊重也不渴望成员的参与热情，那么成员们甚至不会去思考或谈论关于改进组织的话题。换句话说公司甚至连了解员工想法的机会都没有！就算有人萌生了帮助企业改善提升的想法，这种念头也会直接被扼杀在脑海里。

谈到“文化”这个概念，我指的是管理者、部门、同事和个体的行为方式和习惯。组织文化涉及“潜规则”、组织框架和流程，以及激励措施。所有这些事物会共同塑造并不断改变组织的文化。有时，企业“真正的”文化和写在介绍页面上的价值观、愿景或企业哲学并不是一回事。

但有一件事是肯定的：每个组织都有一种文化！这种文化可能激励组织不断前进，也可能会磨灭成员的热情。也就是说，如果你们想塑造一种更具激励性，更加积极的文化，就必须找出塑造现有文化的行为习惯，并抛弃那些阻碍组织改进的负面习惯。

DevOps 中“改进”的关键作用

DevOps 的目的是让开发和运营更好地协同工作，这本身不就是一种改进吗？那我们来看看。

很多组织并没有对“人”的因素做 DevOps。但只有打破沟通困境、赋予成员更多自主权以激发他们的热情、设法让工作变得更加有趣、减轻职场压力……所有这些正面措施才是真正实现商业目标的关键所在：让企业在快速变化的市场环境中保持或获得竞争优势。

在有限的时间内接受新的需求、实现新功能并对客户行为做出反应是一项艰巨的任务。为了专注于主要目标——也就是交付符合需求的软件——我们需要改进成员在一起工作的方式，也就是加强协作。重点在于始终关注主要目标，找出所有效果不佳的环节并探索解决方案，这些环节可能是技术障碍、组织问题（如流程），还可能主要是人的问题（如沟通）。

这里我们可以参考 CALMS 这个概念。“精益（Lean）隐含着对改进、找出和减少浪费的需求，这些都是持续的过程；“自动化（Automation）“也暗示要做改进。组织应该尽可能自动化工作，前提是它达到了一定质量标准，能够减少重复性工作的“浪费”现象，这样组织就能空出更多时间专注于改进了。

“评价（Measurement）”能够让我们判断事情是否在朝着正确的方向发展，或者是否需要改进。在这个环节，你们要测试的不仅有技术指标，还应该加入诸如 A/B 测试、Canary 版本测试等内容，这样就既能检查一切功能是否按照应有的方式工作，又能评估用户的接受度了。为什么要这样做？因为我们希望能在早期阶段就找到需要改进的内容，以免这些瓶颈影响整个开发周期。我们也可以使用看板之类的方法来测算任务的前置时间以找到瓶颈。

或者说，我们的工作愈加透明，我们也能更容易找到改进的机会。一般来说，在开发过程和交付流程中检查代码质量并清洁代码时有一个所谓的“童子军规则”，这是 Robert C. Martin（Bob 叔叔）发明的：“每次编辑都要让代码质量提升一些。“这也是一个改进的途径。

“共享（Share）”也是一样的道理。通过分享，每个人都可以轻松地持续提升自己的知识和技能水平，无需大量耗时且昂贵的培训。如果能在日常工作中不断学习，解决方案也会自然得到持续改进。公开反思失败的教训也有类似的效果。

我还可以再多谈一些层面证明“改进”在 DevOps 中的重要性。但不管怎样，改进的目的都是要在较短的周期内达成高质量的标准，从而获得更多竞争力！

危险区：一种恐惧文化

几年前我曾在一家拥有约 600 名员工的公司工作。这家公司的创始人就像是所有人的“大老板”。每当他的秘书打电话给某位同事，招呼他进老板的办公室时他们都非常害怕，立马大汗淋漓。然后“大老板”就开始登台表演了：他以非常粗鲁的方式向员工提问题，审讯全程咄咄逼人，当下属回答不上来或表现得非常紧张时，老板就在那里沾沾自喜。

问题在于，当有人想出什么好点子，希望能改进与公司和我们的工作相关的事情时，大老板也要来这一套。他总要否定下属，让我们相信那是一个坏主意，对公司毫无益处。甚至有很多次，他自己后来都接受了下属的提议，却把它说成是自己的想法，还当一开始提出建议的员工不存在一样。

如果公司内部文化鼓励协作，欣赏进步，一般这都是好事情。但是我们的公司上下都在被恐惧驱使，所以有些人有想法也不敢提出来，因为他们不想被大老板审问一番。还有的人不想白白把好主意交给大老板，结果自己什么好处都得不到。

当你意识到自己的主意会导致一种非常让人不爽的结果，或者会让那些你讨厌的人占了便宜，这时你会怎么做呢？首先你不会再谈论自己的想法；接下来你不再思考改进措施；最后你甚至不会关心自己在做什么和为什么这样做。对于一家公司而言这是一个非常危险的状况。如果员工们——也就是处理所有日常业务的专家们——都不再关心自己正在做的事情，他们也就看不到有哪些事情做错了，或者有哪些方面是可以改进的。就算他们看到了这些情况，也许也会选择事不关己高高挂起；哪怕他们认真思考过对策，可能也不会对别人说出自己的想法。

可如果不是工作在一线处理日常事务的专家，谁还能提出改进提升的好思路呢？难道指望空有理论知识，却无视理论与现实之间鸿沟的那些人吗？很多顾问就是这样的。他们花了很多时间了解一家公司，做各种问卷调查、访谈和研讨会，然后提出了一个解决方案；可这个解决方案通常不会被员工真正接受，但却需要花很多钱。

所以对我来说，“早餐前”这句话意味着公司甚至没有机会倾听和讨论员工的想法，也没有从“内部专家”那里学到东西。

我在 RebelCon 的演讲中还举了另一个非常负面的案例。我是一所大学的讲师。一次我们大学决定要扩展一个系。那个系之前有一位学生去过很多国家，像印度、巴基斯坦、尼泊尔、越南、尼日利亚、加纳等等，并作为留学生在我们大学进修，成绩斐然。结果一夜之间，这个系冒出来了 260 名来自完全不同的文化和教育背景的学生进修硕士课程，本来名额才有 40 人而已（实际上以前每次最后都会招 60 人）。一下子多了 200 学生是个惊喜，可也引出了一系列问题：学校没有足够的教室，没有足够的教授和讲师，没有足够的宿舍，没有考虑语言差异的障碍，没考虑文化差异的问题，也没有考虑到可能存在的教育背景的巨大差异。在这种情况下，所谓“扩展”只是在简单地增加数量，根本没考虑整个环境是否允许。没人想到文化冲突带来的麻烦，或者秋冬季的阴郁天气对在印度等国家长大的学生有什么影响！

一些学生认为他们可以信任我，向我敞开心扉谈论他们的心理问题。由于我有多年与患有抑郁症等心理问题的人们一起工作的经验，而且联系我的学生人数还不断增多，我决定告知院长有关情况。从那时起，一段漫长而令人失望的故事开始了。

“我怎么没听其他教授说过这事儿，这肯定是瞎编的！”，这只是我得到的无知回应之一。有人企图口头威胁我，试图让我搞清楚我在组织中的“位置”，威胁说我没资格担任讲师（之前他们曾问过我是否愿意当讲师）。还有人污蔑说我是“强迫”学生告诉我这些私人事务的，因为我教的就是社科类的课程！

有人背着我向一大帮人群发了一封电子邮件，讨论我的事情并声称错都在我。不管怎样，我们开了第一次会议讨论这件事。会开了两个小时，一位教授说只有自己真正在做事情，把责任都推给了同事们。我们连想要达成什么目标都没搞清楚就在讨论“该做什么”，最后的结论仅仅是我们需要再开一次规模更大的会议。幸运的是有一位教授支持我。这件事以前，每当人们试图讨论问题所在的时候，每个人都会试图甩黑锅给别人撇清自己，这种事情她都经历过好几次了。她告诉我说大学内部的政治游戏耗费了大量的精力，以至于她无法专注于自己的主要目标——也就是好好教课！她身陷组织的资源浪费和政治游戏中难以脱身。

几周后我们举行了第二次会议，会议室里坐着许多高层面孔。

那天下午五点钟，桌子上只放了几块饼干和一些水；气氛紧张尴尬，没人觉得自己花时间待在那里能获得赞赏或鼓励。

这次会议又是像上次那样，每个人都试图责怪别人——没能到会的同事们是首要打击目标。此外一些教授还指责学生们“不像样”或“不够好”。形容起来，那场会议就像是一帮人在树林里打群架一样。会开了快一小时后，我提醒说我们这些老师自称是项目管理的专家，还教学生如何运作项目，那么现在就应该拿出点专家的样子来，别再像一帮傻子一样争吵了——结果副主任说：“别说了！我不想听！“那我当然立刻闭上了嘴，精神层面也不再关心这摊事儿了！我听了他们的讨论，听到了糟糕的结论，也听到一位教授说：“那成，现在我得走了，反正我自己的目的已经达到啦！”

我很清楚，整个组织中所有人都在试图撇清问题的责任。拿 Christopher Avery 的责任阶段理论来说，他们基本都处在否认事实的阶段，有时会转向责备他人的阶段，但实际上离主动承担责任还远着呢。

我现在开了自己的讲座。如果学生想要与我一起完成他们的硕士课题或想要讨论问题，我只是简单地拒绝掉，因为每次与组织高层的沟通都过于耗费能量，还会产生消极情绪。他们试图让我的工作更加难受。原本我肯定会放弃这份工作的，但我真的很喜欢教育年轻、有动力的学生。我知道像这样消极应对的老师不止我自己，所以当我需要与其他教授联系来获得信息时我只会这样做：给主任和其他重要人物抄送一份——这种办法每次都很有效。我不喜欢这样做，但我只能选择这种方式才能完成工作。有过这种经历的人们肯定不会再提什么“坏消息”了，反正大家都觉得提出问题改善状况的责任和自己无关。

养成不断改进的好习惯，克服坏习惯！

正念、尊重、开放、鼓励、协作、对共同目标的承诺、还有对改进、信任和安全感的期望——这些是塑造持续改进的组织文化的一些重要理念。

缺乏透明度、政治游戏、甩黑锅心态、责备他人、滥用权力和引起恐惧、先己后公、尽力维持现状、否认问题……这些都是塑造改进文化的敌人。

我认为，组织想要真正做到改进，最重要的前提条件之一就是组织愿意听取“坏消息”，不管多么糟糕的消息都能听得进去。我们不可能与坏消息绝缘，因此我们需要明白事实上组织永远都有改进的空间。如果一个组织有一种激励文化，人们在提出想法或问题时能受到赞赏，他们认为自己指出正朝着错误方向发展的事物也不会让自己陷入麻烦，那么组织成员就可能很早发现哪些问题需要改进。如果员工受到赞赏和尊重，还有足够的安全感，他们就能全方位运用自己的专业知识来改进工作，还能改进整个组织的流程和成果。员工既掌握专业知识，又能洞察组织的状况。如果管理层没能严肃对待这些想法，没有给予员工足够的信任，这样的管理层就是不合格的。如果能让每一块金子都有自己的闪耀时刻，那么不仅能让组织熠熠生辉，而且会为企业带来无可估量的巨大价值！

很多公司都在使用员工反馈系统。但这种系统并不等同于持续改进的企业文化。持续改进的文化意味着你要试图打破官僚主义的壁垒，让改进融入日常业务的旋律。你们不需要填写什么正式的表格文书，只需在团队中发起讨论，或与相关人员开始交流就迈出了第一步。起步之前你们应该达成共识，给“成功”下一个定义。不要为了改变而改变；组织的目标应该是通过改变一些事物来获得进步。如果实验没能成功，你们可以收回目标或尝试新的目标。的确，有些决策需要的时间比较长。但在持续改进的组织文化中，管理层做决策前会听取员工的专业建议，并让员工参与整个决策过程。

我坚信，许多公司如果能够更多地关注员工的报告或者激励人们发表自己的想法，而不是雇佣顾问来分析公司有哪些潜在的改进空间，那么就能节省大量资金。首先应该利用公司内部的知识——你会惊讶地发现原来大家能提出那么多有趣的办法！

另一个角度来说，如果改进的思路是员工提出来的，那么这些建议就能得到组织成员更高的认可度。实施这些改进意见比推行来自外部或自上而下提出的建议更容易成功。就算是那些试图维持现状的人们也可能更愿意尝试自己同事建议的事情，而非管理层或第三方提出的建议。

但与此同时，员工也需要了解管理层在组织中不可替代的作用，要明白有时管理层必须提出改进建议或要求大家给出想法。员工对管理层角色的认可也是很重要的；这意味着不仅要让管理层信任员工，还要让员工信任管理层！

这也是团队和每位成员的任务。当一位同事想出一个想法时，其他人都会作何反应？他们是对这个想法感到厌烦，还是愿意去讨论？大家的心态到底是“何必白费力气”，还是“让我们看看我们可以从中学到什么？”当别人提出想法时，我们应该反思自己的反应，整个团队也应该做反省——可以在总结会议上做这些事情！

每当我们开始互相指责、有人试图撇清责任、或者大家缺乏对共同目标的关注时，我们应该设法解决这些问题！不要让“房间里的大象”变成更严重的问题。但也要避免总是渲染悲观的情绪——否则过一段时间后没人会再理你了。

DevOps 的目的就是交付高品质的成果。DevOps 的关键在于让事情变得更好的意愿——包括产品、流程、协作等等！如果我们都遵循这些原则，我们不仅会创造高质量的产品或服务，还将营造一个高质量的工作环境和愉快的工作氛围，从而让自己专注于我们真正想做的事情：做好工作！

作者介绍

Sabine Wojcieszak是 getNext IT 的顾问，她称自己是“敏捷和 DevOps 推动者”。作为一名教练，她帮助团队和组织加强团队合作和沟通。她帮助人们以敏捷的方式工作或接受 DevOps 的理念，并专注于从人性层面引发这些变化。Wojcieszak 是国际技术会议上的知名演讲者、多篇文章的作者，以及 DevOpsDays Kiel 大会的组织者之一。她还在大学讲授 APM、DevOps 和开源知识的课程。Twitter：@SabineBendixen

查看英文原文：A Different Meaning of CI - Continuous Improvement, the Heartbeat of DevOps