什么是Devops凤凰沙盘
DevOps《凤凰项目沙盘》是由欧洲著名沙盘研发机构Gaming Works的创始人Jan Schilt先生联手《凤凰项目》一书的作者Gene Kim 先生联手开发的同名沙盘演练课程。
一些个人感悟
对于Devops本人真的是所知甚少。由于长期从事的是开发工作，对Devops的认知仅停留在自动化测试，自动化运维方面。最近公司组织了一场凤凰沙盘的活动，有幸得以参加。在参加前也搜索了一些相关内容，对Devops有了一些更广泛的认识。DevOps是一种文化，是一种跨团队(Cross-Team)的团队协作，通过单件流(one-piece-flow)，JKK的理论，在保证业务连续性(Business Continuity) 的前提下，实现持续集成(Continuous Integration)、持续交付(Continuous Delivery)的要求，最终实现提升业务产量(Business Outcome)的目标。
本次凤凰项目沙盘个人觉得更像是将公司的整个流程压缩到了一个桌游中，更偏向的是通过实践快速暴露工作中的问题，反思再实践再反思的过程。通过多次(4次)迭代帮助团队找出问题，并通过反思总结问题，找出解决方案。毕竟一千个人眼中有一千个哈姆雷特，每个团队有每个团队的问题，如果讲师按照固有的解决方案进行培训可能是最好的方案，但不一定是最适合这个团队的方案，只有通过实践暴露出问题并且团队自治解决问题才是最好的方案。
还有一点是看到网上有人说这个沙盘以客户价值为中心，这一点不太认同。这场沙盘是完全围绕盈利展开的，所有的工作都指向为本公司创造更多的价值，提高公司的盈利，提高公司的股价。这一点在商业中也无可厚非，毕竟大家都是以盈利为目的，而不是慈善。但是如果披上以客户价值为中心，就有点瞎扯淡的意思了。
在这场桌游中，我的Role是IT Test Team,团队有三个人，也得益于这样，让我有更多的时间不只是参与在自己的角色中，也观察并体验了其他角色的工作。得出了一点自己的心得和感悟。
全局的决策
在活动刚开始的时候，是先发放了一部分的任务出来，然后管理团队(CEO, CFO, CIO, Human Resources)就开始开会讨论，哪些要做，哪些不做。这样做是正确的，但问题在于讨论的时间过长，太注重把整体串起来，详细计算所有收益之后再分配工作，就导致了第一个回合的时候管理团队讨论的热火朝天，其他团队放羊。
所以这个地方所说的全局的决策不只是说要把控全局的收益，还在于把控全局的人员调配。让每个角色有活干，还要让团队最后整体是有收益的。从现实中来考虑，如果过分注重详细设计之后才开始动工开启项目，那前期会导致大量的人力空闲。在敏捷中有个概念是快速迭代，拥抱变化。就是可以考虑尽快动工，可能我们最开始的版本或者成果都是粗糙的，甚至最开始的时候我们或者客户并不知道自己想要什么(通常情况下也是这样的),但是随着时间的推移，随着迭代的推进，随着功能的叠加，越往后我们就会越知道我们需要什么，怎么做，怎么赢利。
统一的标准
在游戏开始的时候，主持人介绍了一遍规则，但是规则比较长，比较复杂，并且环境当时比较嘈杂，所以其实大家都不太懂具体的规则，只是有一个大体的概念要怎么玩。这个时候团队的CEO站起来说要统一下规则，当然这是一个很好的建议，很不错的事情，方便后续的操作，但是就在大家按照统一的规则进行的时候，团队还有一个比较热心肠的HumanResources，可能现实中也是比较强势的领导之类角色，就挨个对其他的角色，比如Lead Engineer，IT Support，Technology Operations等多个职位进行指导，指导的方式竟然还不是之前沟通过的规则。虽然最后证明CEO和HumanResources给的规则都是错误的，但是这中间有很多需要反思的。
所有人按照第一次的规则执行完一遍之后，HumanResources又用自己的规则重新执行了一遍，先不说这中间的人员和时间成本浪费，这是对执行任务相应角色的执行能力的一种不尊重，对团队工作成果的不尊重。如果对规则有异议，应该在规则制定会议上提出，经全体人员表决之后再集体执行，这种政策制定与执行不统一的行为在团队中是最要不得的。对资源是一种浪费，对团队积极性也是一种打击。
之前在团队中遇到过一个同事，我要跟他调试一个接口，我们坐在一起开了个会，制定了接口规范，然后大家就都拿着制定好的规范回去实现具体逻辑去了。但是到了两周后，业务合并进行集成测试的时候，问题出现了，他竟然自己又重新定义了接口，理由是这么开发比较方便。导致结果就是我重新按照他的接口开发了一遍实现。为什么我这么苦逼没跟他计较？因为他是甲方的人啊(苦笑脸)。呵呵哒。
有效的沟通
在沙盘的进行中，我们遇到了很多问题，有管理方面的，有理解游戏规则层面的，有执行层面的，但最重要的是沟通方面的。一整天的沙盘游戏，整个上午基本就没有什么规则，每个人各自为营，自己按照自己的理解去做，并不管最后结果怎样，也不对最终结果负责。但其实我们的CEO是有过几次指定规则的，分别是在游戏伊始和第一回合之后，组织大家一起开会制定了一些规则，但是并没有人贯彻执行，或者说刚开始有人尝试执行，但是一旦出现不太稳定的因素，或者有人质疑这些规则，就有人开始不按照规则执行了，而我们的CEO也并没有及时纠正，这就导致整个团队运作的方向就一直在偏离，偏离，再偏离，直到错到离谱的时候我们才能认识到错误所在。
最近在看阿里的一个纪录片，讲阿里云的发展是多么不顺，讲王坚博士如何坚持把阿里云做了下来，讲马云对阿里云的信任，对王坚博士的信任。而在马云和王坚博士之间，这就是有效沟通的本质，有效沟通不是只停留在沟通上，最终的结果是一定要体现在贯彻和执行上的。
核心人员的话语权
要保证核心人员有足够的话语权，但是这么做也是有问题的，就是如果核心人员制定的策略是错的呢？所以还要保证足够的定期反思，下级有机会对上级提出挑战，从而保证最小化屁股决定大脑的决定。这件事情说起来容易，但是做起来比较难。在中国这个深受官本位思想影响下的大环境，要做到领导定期反思，下属勇语发言，实在是不太好办。这就要领导有耐心的时间培养团队的这种文化，对人的领导能力要求还是蛮高的。
Team Work
有效的团队合作，不能放散羊。现代社会发展到现在，已经很难说某个人靠自己的英雄主义就可以做成某件事，所以就出现了Team Work这个词。但是Team Work并不是1+1=2那样简单的一件事情，如果团队合作好，价值可能远远大于2，但如果合作不好，可能价值还没有1大。
授权工作，还要放权工作
授权和放权这件事情，真的是挺难的，我个人深有感触，关键在于很难把握这个度。在工作中也遇到很多的问题，有自身的，有看到他人的。
授权这件事，比较容易出现在从开发人员刚提升到管理层的人身上，事必躬亲，自以为是诸葛亮，但最后会发现自己累个半死，结果却差强人意。在上一家单位的时候，曾经有幸手下管理一些人，就犯了不授权的问题。我当时就是刚从开发升到TL，所有的事情都会去管，甚至组员写的代码我觉得不满意的都会自己重构一遍。但是这个事情非常不好，导致了两个结果，第一是组员对自我的怀疑，时间长了他可能会怀疑是不是自己能力有问题或者我对他们有意见，你能很明显的看到他们的状态和表现出来的态度，这个对团队向前走是百害而无一利的，而这个问题也是致命的，我在很长一段时间并没有意识到这个问题的严重性，直到有人离职。第二个结果是我很累，真的很累，每天有自己的工作要做，还要把别人的工作核查一遍，这不是一个良性循环。
提到授权，还有更重要的是放权。之前遇到一个组，有个SeniorManager级别的领导层，招了一堆的Manager给他干活，但是实际连表怎么设计，元素怎么办方这种事情都要插手过问，最后就导致大家每件事情都要发邮件确认，效率极其低下，但这位领导却乐此不疲。
不要形式主义，结果驱动
上面有一张图片，在公司某面墙壁上贴满了便利贴，很漂亮。这是我们的Round 2的时候做的一些事情，过程漂亮的连对面的组都觉得我们做的很好，但是结果呢，我们在Round 2的时候输了。原因是所有人都在关注这个形式，却没有人对结果负责。
合理控制团队外围
在这次的沙盘中，由于报名的人过多，并且还有临时加入的几个同学，导致人数大大超控，所以最后是每个组十几个人。而其实这个沙盘游戏每个角色一个人就差不多了，甚至好几个角色可以一个人兼任。由于过多的人加入，却没有足够的管理，大多数时候，多数的同学们都在玩手机，唠嗑，像我所在的IT Test就分配了三个人，其中一个人真正在干活玩游戏，另外两个一个在玩手机，另一个还是玩手机，并没有起到实际推动项目向前进的良性效果，导致了人力成本的浪费。所以在管理中要严格控制团队人员增长，不应该为了扩张而扩张，并且要合理拆分项目人数。就像《人件》中所描述的那样，一个人10个月昨晚的工作，10个人一个月并不一定会做完。
站在对方的角度考虑问题
其实这是一个老生常谈的问题，因为无论做什么事情，都要站在对方的角度考虑问题，无论多么自私的人，也都会至少是尝试过站在对方的角度考虑问题。但是为什么在这样沙盘中又把这个问题提出来呢，问题的关键在于是否以正确的姿态站在对方的角度考虑问题。在Play这个沙盘的过程中，我们的决策团队一直在开会，大量的开会，试图通过大量的会议预先复盘所有的过程，保证每个过程都是对的，也就是他们尝试站在所有的角色的位置把问题考虑一遍，但是很容易出现的问题就是他们不认为是问题的问题刚好变成了问题，他们认为是问题的问题反而不是问题，这句话有点绕，但是却实实在在的在我们的现实生活中出现着。
我曾经工作过的一个单位，这里不提及老东家的名字了，我们曾经遭到过一个客户抱怨，原因是我们的出差人员提前回来了。其实这个事说起来也有意思，出差之前，领导对这位出差的同事说只需要去两周，并且信誓旦旦的保证只要两周就可以了，于是此同事就去了，并且提前就买好了到两周后回来的机票，当然，项目的事，你知道的，总不会那么一帆风顺，由于另一个区域的同事的失误，导致项目在两周内没有完工，而出差的同事本来对出差就颇多怨言(我们的差补少的可以忽略不计)，于是在两周后他就按照原计划回来了，谁也没有通知，但是谁也没有通知他不用回来。结果到了周一，客户现场大家都在找这位同事的时候，才知道他已经优哉游哉的回本部上班了。我们不去说这中间究竟谁有问题，当然问题很明显，大家都有问题。这件事反应的就是你有没有站在对方的角度考虑问题，有没有真正的站在对方的角度考虑问题。
还有一种情况就是当我们接到一个大的项目，项目进行了大半之后，客户突然说要变更需求，我们怎样去应对。其实客户的变更倒也不是说多难，但是这是个连锁反应，就像是老鹰捉小鸡，小鸡链条上的头鸡可能并不需要怎么走动就可以了，接下来第二个可能只需要走动1-2步也可以安然无恙，但是之后的所有的小鸡呢？可能到最后的小鸡需要满场的跑才能摆脱危险。所以这就需要我们冲锋在最前线的跟客户做对接的同学要深刻的站在他背后那些同学的角度考虑问题，才能避免这种可能引发的蝴蝶效应。
其他一些
- 减少重复工作
- 透明的信息共享
- 试错而不能坚持错下去
参考资料
玩转DevOps《凤凰项目沙盘》 :http://bj.learnfuture.com/article/1754
关于DevOps“凤凰项目沙盘”的一些思考 ： https://www.jianshu.com/p/b70cac925b09?from=groupmessage