引言
听说凤凰沙盘很久了，这次参加DevOpsDays有幸得到了一张Marslander沙盘。第一次参加沙盘活动，虽然之前对ITIL也有一定的了解，但是这次沙盘将DevOps和ITIL很好的集成了起来，对于长期在一线的运维在流程和协作上会有很大的帮助，拖延了好久，终于抽出空来进行回顾和总结。
简介
公司已经具备成熟的ITIL流程，包括：事件管理、问题管理、服务台等。现在接到了一个一个登陆火星的计划：需要在这个项目中，用已有的ITIL流程和角色，结合不断纷至沓来的事件、需求、bug、甚至客户的服务满意度调查结果来高效的确保整个项目的顺利进行。
角色（暂不讨论角色职能）：
产品&销售：
- 销售总监：负责根据整体销售目标同产品经理确认每轮需要完成的事情。
- 产品经理：负责和销售总监分解需求优先级。
IT团队：
- 服务台：负责接收各种事件、问题、统计汇总给销售总监和产品经理。
- 开发
- 运维
- 变更发布经理
- 服务经理
- 供应商（虽然不属于IT团队，但感觉放到这里更好一些）
反馈回环：
- 飞行操作员：负责对相关发布以及改进做出评价。（对事）
- 客户支持：负责察言观色客户的喜怒哀乐。（对人）
过程（图）：
每个冲刺都会在Dashboard上显示各个指标（图）
分组
会场共四个小组：我们小组最后的名称是：只要钱队
回顾
每次回顾分别从角色、可视化、流程、价值（核心目标）、优先级、质量六个方面进行回顾分析
| 角色 | 可视化 | 流程 | 价值（核心目标） | 优先级 | 质量 | 等待浪费 |
|---|
| 第一轮 | 自己和彼此角色定义不清楚 | 有意识 桌子上看板（沟通不便废弃） 墙上有看板（没有使用） | 有意识 角色不清无法建立 | 最终人员认为是：简单完成任务 | 无优先级 | 无质量 | 等待浪费严重 |
| 第二轮 | 自确认自己的角色定义和职责 | 改进： 墙上的看板（泳道） 有doing和done | 流程依旧没有做好：有瓶颈尚未解决 | 挣钱 忽略了流程上的瓶颈以及其它指标 | | 无质量 无版本 | |
| 第三轮 | 不断提升明确自己的角色定义 | 完成了可视化 有了真正的BLP | 明确了流程，交付物开始增加。 | 交付了价值，但时间点上交付了错误的价值 | 从看板中发现价值所在 需求等信息集中到需求池中，但尚未开始排优先级。交付了错误的价值 | | |
| 第四轮 | 很清晰角色定义 并且互相之间有合作 | | | | | 改进了产生版本回退的概念 | |
| 第五轮 | 持续改进不断提升 | 持续改进不断提升 | 持续改进不断提升 | 确保目标正确 持续价值交付 提高满意度 | 持续改进不断提升 | 持续改进不断提升 | 持续改进不断提升 |
思考
明确角色定义
角色定义沙盘中有10个角色，各个角色都不一定是参与者工作的角色，因此熟悉自己的角色工作职责以及和其它角色建立好沟通就显得尤为重要。
可能遇到的问题
- BU角色容易产生业务决定一切的领导思维。
- IT团队很容易产生只低头干活不抬头看路的思维。
- 飞船驾驶员(一线员工)也很容易产生被放弃的情愫。
各个角色都无法说服对方的时候，加上事件出现之后的指责文化，拉偏架，撕逼会经常上演。
解决：
- 管理者不断调整角色定义，趋于平衡以及目标的达成。画饼、激励、赋权、资源都应该有所调整
- 相关角色不断明确自身的角色定位，和同级别的人进行沟通修正方向，提高沟通效率。
- 组织应该对人员考核有回环考核机制，及时修正相关负面情绪。
找准核心价值
找准组织的核心价值：比如我们团队定义的就是提高利润。
自上而下，即使牺牲某个岗位的利益（个人发展等）。对于这部分牺牲的人或者岗位，现实生活中可以采用外包的形式、或者建设组织梯队建设。
快速建立可视化
好处
建立可视化看板可以找出事情的瓶颈，也可以加速建立自组织的团队。
难点
在团队中实际落地。现实工作中很容易就走偏了：比如为了向上汇报建立所谓监控的大屏，而忽略了可视化应该是给团队中的每一个人看的，是用来提高团队的组织效率的工具。
工具陷阱
可视化常常陷入工具的怪圈。很多时候团队内部会因为可视化看板用A家的产品还是B家的产品，甚至是否需要自己需要开发一个撕的不亦乐乎。比起用哪个工具，更重要反而应该是实时性以及人员的参与度。
组织成熟度
君不见某领导推行看板，却从来不管WIP、泳道划分、卡片颗粒度等问题。只是当成了每周某一时间点的周报来管理。谁的卡片越多就越体现说：我的活最多，没有功劳也有苦劳吧的这种思维怪圈里。只自己一个小组玩，每个人都是贯穿整个泳道的人，这种看板最后肯定会沦为高级的周报了。
解决
提高团队整体的参与度，持续改进看板的组织形态，不能三分钟热度，没效果或者效果不好反思下是哪里做的不对，而不是遇到点困难就弃置或者转而尝试另一个管理的方法论。
持续流程改进
难点
持续改进，不是改革。改革是要革命，革命就要死人。而改进可以小步快跑，持续迭代。
容易陷入整风运动中
持续改进按照项目的形式来运作。解决一个问题的同时引入了另N个问题。这样，第一个问题被解决了，不但KPI完成了，还可以有第二期、第三期、第N期项目并且再引入N个问题继续做。恩，真香。
持续改进人员，而不是流程和工具
经常看到的是优化掉了提出问题的人，而不是问题。因为持续改进就代表：以前有问题，有问题就要有人来背锅。那么找个人背锅可以变成持续改进的副产品。恩，这说的通。
保持无指责的改进
为什么需要持续改进？多半有部门墙或者对彼此的不理解，不理解就会导致互相的指责，指责又会加深部门墙的高度。轮岗或者可视化可能无指责这事有所改进，但感觉无领导自组织的团队可能效果会更好一些。一些目标相投的一线员工结成持续改进小组。平时大家看起来都挺顺眼的，而且对对方的工作也大概知道怎么回事。不然领导乱点鸳鸯谱可能会加深指责吵架的概率。
总结
一个四个小组，有的小组拿到了不错的成绩，有的小组内部各种沟通不畅导致最后结果不尽如人意。所以天时地利人和，缺一不可。这也是DevOps比较强调文化的一个重要原因。
我们小组总来说还是拿到了一个很不错的成绩，当然前期的摩擦还是会有的。比如供应商同学的一些提议就被无情的忽略，导致后续供应商同学已经保留自己的意见了。这在现实中还是很常见的，这时候就需要考验团队中的管理者对于事和人的把控能力。
无论ITIL、敏捷、还是DevOps都需要一个明事理的老大来整体协调，毕竟房屋的各种墙拆掉还是需要房东来决定，租户之间只能多聚餐，多串门，拆掉墙内部的事情都让别人看到了，多不好。除非是和房东变为一家人才有可能推进。