作者简介：

专注于软件质量及过程改进的咨询师和技术顾问，超过20年的IT行业经验。是PMI组织认定的PMPer，国家信息系统项目管理师，TMMi Professional专家，持有ISTQB AM，Scrum敏捷教练CSP、CSM、CSD等认证，熟悉PMBOK、TMMi、TPS、DevOps、Scrum、Agile、Lean、ITSM、ITIL、COBIT、CMMI等领域知识。

凤凰项目沙盘起源于Gene Kim、Kevin Behr等人合著的《凤凰项目：一个IT运维的传奇故事》，是一个将DevOps的理论应用于企业的IT运维和运营上的模拟游戏。

老早就听说过这个沙盘，据说在北京、上海、台北等地巡回上演时，百余人同场竞技的盛况曾刷爆朋友圈，是一个风靡全球的游戏。一直盼望着能玩玩，但一致没有玩成过。最近参加第五空间的DevOps Master课堂，作为必玩（修）内容，终于得愿以偿。

沙盘玩了一天，很开心，也很有收获。有些感悟，觉得私藏着是不道德的，所以分享出来。也有一些困惑，希望能与同道中人探讨，盼望有大牛能指点迷津。

进入正题前，有必要先简单介绍（回顾）一下什么是凤凰项目，什么是沙盘，为下文的讨论先“热”个身。

在第五空间的课程介绍中是这样描述的：

《凤凰项目：一个IT运维的传奇故事》是一本少见的IT类小说，全书讲述了一名IT经理Bill临危受命，新接受公司IT运维部总监职位，在未来董事的帮助和自己“三条黄金法则”理念的支撑下，通过改变以往“救火”模式的工作方式和管理方法，将一个严重超出预算和工期延误的凤凰项目“救活”过来，挽救了一家具有悠久历史但又陷入困境、濒临破产的汽车配件制造商（无极限零部件公司）的故事。

凤凰项目沙盘是由欧洲著名沙盘游戏研发机构Gaming Works的创始人Jan Schilt联手《凤凰项目》的作者Gene Kim开发的同名沙盘演练课程。课程以《凤凰项目》小说为背景，通过扮演小说中各种角色，运用 DevOps 的理念，模拟再现小说中的场景，让参与者们直观感受DevOps的文化精髓，加深对跨部门协同工作的理解，并建立全局视野，挽救濒临破产的“无极限零部件公司“。

玩过沙盘后，才知道，沙盘的内容其实不仅仅只是上面的介绍，还需要知道沙盘包含的两类关键角色，他们分别是业务角色和IT角色，每个角色都有各自的角色描述卡，其中CEO / CIO 角色由教练担任，业务角色包括财务总监（CFO）、人力资源部老大、IT运维部老大（VP IT Operations，也正是书中临危受命、带领运维团队使凤凰项目起死回生的主角）、首席信息安全官（CISO），IT角色包括开发团队、测试团队、技术支持团队、技术运维团队、技术大拿首席工程师（Lead Engineer）和变更管理负责人（Change Manager）。

看起来挺多的。没错，这就是一家汽车零部件制造公司的IT部门，还有业务部领导和公司老大CEO。

沙盘的业绩目标是提升项目价值并最大化。沙盘共玩4轮，参与者有机会通过改进过程来提高效率，完成业绩目标。

玩沙盘时，由不同的人担任以上不同角色，业务部下达模拟的需求或任务，由IT部门通过完成“开发软件“、”修复bug“、”处理Issue“等任务来改变项目价值，影响公司股价，模拟维护那个“病入膏肓”但又对公司生存有致命影响的凤凰项目。

沙盘的具体规则和玩法就不说了，再说就扯远了。下面进入正题，谈谈本次沙盘的几点收获和困惑。

01、关于团队管理者的思考

无论是PMBok的项目管理知识体系，还是《持续交付》等很多技术或管理类书籍中都讲过团队的生命周期，团队组建与磨合常常会经历五个阶段：创建期、风暴期（也称震荡期）、规范期、运转期（也称成熟期）和调整/重组期。

创建期团队开始形成，团队成员开始互相了解，这时候效率是低下的。

风暴期团队成员花大量时间讨论如何领导，如何分配工作，怎样工作，这时候工作效率也是较低下的。

规范期团队确定了决策流程，并开始规范自己的行为，关注怎样工作才能最好的达到目标，效率上升。

运转期团员开始懂得怎样做决定和工作，在工作中避免个人冲突，效率很高。

调整/重组期是指经过一段时间的运转后，项目解散重组，或团队出现新的问题，需进行调整和重组。

参与玩沙盘的人，互相都是陌生的（企业内训玩沙盘的例外），大家第一次聚在一起，组成一个团队，来完成模拟的任务，确实符合以上团队建设的规律。

作为管理者，在团队建设中最关键的是如何带领团队尽快渡过低效的创建期和震荡期，尽快进入高效的规范期和成熟期。

在这个沙盘中，“管理者”也是游戏的一份子，短短1天时间内，要如何做才能快速适应角色，如何做才能快速掌握全局情况，如何做才能快速做出决策，如何做才能带领一家公司或一个部门尽快步入工作的正轨，这不是每个团队管理者都应该思考的问题吗？

作为IT行业爬模滚打了几十年、项目管理和部门管理岗位也干过多年的“老人”，当玩完这个游戏时，我被“震“住了：一个由2小时前还互不相识的陌生人组成的团队，仅仅经过2轮的沙盘，就“跨过”团队的初创期和称震荡期，快速进入高效的规范期和成熟期（团队产出变化见下图，经过前2轮，团队产出从第3轮起开始大幅增长），这是如何做到的？

作为其中的一员，我在反思，团队管理者在实际工作中，该如何做，才能做到同样的效果？我想，至少，管理者应该要有全局观，首先需要快速熟悉环境、熟悉团队、熟悉“游戏规则”，然后，尽快把自己融入团队，才能做出正确的选择或决策。如果“再来一遍”（不是游戏的重复），作为管理者，除了自己要主动融入团队，更重要的是要激发团队能动性，让团队自组织起来。

我觉得，这个演练过程中表现出来的”症状“可以映射到实际工作中的很多“惰性”现象，对它的反思，有助于发现这种“惰性”，对实际工作和个人能力的提升特别有用。

02、“弄脏你的手”和“让流程跑通（Run起来）”一样重要

对于习惯了 “先制订规范管理”和“先做好需求再开发”思维的人，当接手一项新任务的时候，通常认为应该先做规划，先计划好工作流程、明确人员职责和任务分工，再开始干活。

但实际情况是什么？实际情况是计划做好了，流程定出来了，人员职责划分了，任务也分配了，开始干活的时候，发现计划不灵了，流程不好使了，大家不知道从何下手，各种问题，各种不解，各种困惑，一团混乱，典型的低效现象。厌谁呢？谁都不厌！谁都没有错（如果一定要抓个顶包的，那一定是管理者）。因为这是人类认识世界、管理世界、掌控实际的“自然规律”，是谁都抗拒不了的“自然规律”。

做任何事情，都有一个逐步熟悉和熟练的过程。敏捷的最佳实践中有一句话叫做“弄脏你的手”，持续交付中也要求在项目的开始阶段就“拿一个真实的需求让整个基础设施运行起来”，它们表达的意思都是“让工作尽快进入正轨的最有效方式就是先做起来，在做的过程中再修正，再持续改进和完善“。检验一个流程是否有效、是否能工作，最好的办法就是“让它出来走二步看看”。

先动手干起来！这应该也是敏捷思想的一个精髓。敏捷宣言中的四个核心价值，其中最后一个核心价值就是“响应变化高于遵循计划”。动手干起来，再响应变化，这才能“迎合”事务的客观发展规律，有利于快速、高效的达成目标，获得“业务价值”。

03、PDCA中的A远比想象的还重要

业界诸多的过程改进方法中，最有名的应该是戴明环（也称PDCA环）。PDCA是计划(Plan)、执行(Do)、检查(Check)、处理(Action)的首字母组合。(我更喜欢把Action叫做经验教训总结)。

PDCA环上的每一项工作都需要经过计划、执行、检查、对计划进行调整并不断改善这样四个阶段，采用PDCA改进工作流程，可以使工作步骤更加合理、清晰、高效，并不断优化，向良性循环的方向发展。

PDCA循环中，最重要也是最关键是“处理(Action)”阶段。通过“处理(Action)”检视当前循环中的“得失”，对下一轮计划进行调整，并不断改善，它的价值和重要性，怎么描述都不过分，它比我们想象中的还要重要。通过“处理”，发现优势和问题，并在后续阶段保持优势、改正问题，正向循环的力量无穷之大，超乎你的想象和预期。（前提条件是要真正的做好Action，真正有效的发现现存的优势和问题，并真正改正问题）。

在本次沙盘中，我们从最初的“茫然不知所措”，到后来的快速赶上，超预期完成“业绩”（具体数据参见上图，第3轮、第4轮的产出增长速度超过50%），Action阶段的总结、持续改进发挥了极为重要的作用。

这带给我一些思考，在实际工作中如何做好这个“A”？为什么游戏中的“A”能发挥那么大的作用，而实际工作中却鲜见收效？

也许与这个游戏的“无责文化”有关，游戏中，大家可以毫无保留的把短板、问题暴露出来，而实际工作中却因各种顾虑，需要隐藏问题，推诿责任，错失了改进的机会。

也许，还有其他因素，留待后续慢慢再思考吧。把这个问题想明白，搞清楚，我觉得一定是会带来很大价值的。

04、无责文化与员工绩效考核的矛盾如何解决？

DevOps文化推崇无责（Blamelessness）。在沙盘演练中，大家都是“游戏一场”，不受绩效考核的影响，所以根本不需要有什么顾虑。虽然在开始阶段各人的参与热度可能有所不同，有人“热情参与”，有人“抱臂观望”，也有人“漠然处之”，但最终每个人都会按自己的意愿，自然而然的进入到积极“献身”的状态。这不得不说是“无责文化“的强大力量。

在项目过程中，为了发现问题，为了持续改进和提高，项目数据收集和度量是必然的也是必需的。在敏捷和DevOps的环境下，数据主要是用来发现问题，改进问题。但在组织中，员工绩效考核也是需要的（吃“大锅饭”绝对不是一种好的现场）。用来发现问题的那些数据，是对员工（特别是技术人员）绩效考核的最直接、最有说服力的证据。

如果用这些数据来考核员工的绩效，则有悖于无责文化，必然导致这些数据的不准确性（这是人之天性，很难避免）。如果不用这些数据来考核员工的绩效，有什么好的办法或客观的有说服力的数据可以使用呢？

在一些组织中，员工的绩效考核采用其他的模式，由独立的HR部门采用另外一套评估系统，与项目中的工作效率评估分离开。也许，这是一种不错的选择。 

在DevOps的体系中，没有提及如何处理员工的绩效考核，感觉有一点缺憾，以后若能补充说明，则更加完善。

以上，纯属个人感悟和思考，知识有限，难免不足，欢迎同道中人拍砖探讨。

关于Devops Master或凤凰沙盘具体课程安排和学习计划，联系第五空间学习中心的课程顾问丹丹老师索取。

邮箱：dandanzhu@5thspace.net,

电话/微信：18918852841