沙盘模拟项目介绍（如何通过沙盘模拟来快速学习）

沙盘模拟项目介绍（如何通过沙盘模拟来快速学习）“虚拟公司”组织架构图如下：凤凰项目部门及角色有CEO、CISO、CTO、CFO、Retail Operations、HR、VP of IT、Development、IT support、IT Operations、Test team、Change Management。实战开始前，汪老师为我们讲述了“凤凰项目沙盘”的来历和规则，让大家用抽签的方式确定了自己所属的部门。我当时抽到的是业务部门（Retail Operations），那一刻，凤凰项目一书中莎拉的角色立刻在我脑海中浮现，通过向上管理不停给组织施压，一味推卸责任，导致凤凰项目紧急上线后漏洞百出。不知道在这场风云之战中我又面临着怎样的考验。

如何通过沙盘模拟来快速学习--凤凰项目DevOps沙盘经验总结【灵犀】

为了帮助大家加深对DevOps的认识，将理论付诸于实践，11月19日，PMO前沿举办了主题为“凤凰项目DevOps沙盘实战”的线下交流会。

会议上，项目管理行业大咖汪珺老师带我们探索了IT届武侠小说——《凤凰项目：一个IT运维的传奇故事》中的奥秘，并且引导组织在激烈的实战模拟中由混乱无序走向协同作战，从中学习团队组织改进，各种DevOps工具和方法的使用。

虽然对DevOps的了解有限，但还是想把自己的收获和思考整理记录下来，便于今后可以应用到实践中去。

实战开始前，汪老师为我们讲述了“凤凰项目沙盘”的来历和规则，让大家用抽签的方式确定了自己所属的部门。

我当时抽到的是业务部门（Retail Operations），那一刻，凤凰项目一书中莎拉的角色立刻在我脑海中浮现，通过向上管理不停给组织施压，一味推卸责任，导致凤凰项目紧急上线后漏洞百出。

不知道在这场风云之战中我又面临着怎样的考验。

凤凰项目部门及角色有CEO、CISO、CTO、CFO、Retail Operations、HR、VP of IT、Development、IT support、IT Operations、Test team、Change Management。

“虚拟公司”组织架构图如下：

整个团队的目标就是通过各个部门的协作完成来自于市场的项目，将公司跌至低谷的股价再提升上来，这对我们新组建的团队而言确实是个很大的挑战。

老师通过卡牌给我们发布项目，也就是团队的任务，其中不仅仅有外部项目，中间还穿插着内部的业务项目，另外还有不同部门之间的培训。

震荡期：最开始整个团队处于震荡期，未建立起工作流转的流程。

团队中大多数都是第一次接触到沙盘项目，不熟悉活动规则，甚至不清楚卡牌上的内容是什么意思，老师还故意把测试部门拉到一边造成部门之间的割裂。

当业务部门接到项目时只有领导层在那里关门商议，闭门造车，各个部门之间也没有太多的协作，团队之间的沟通也是口口相传，所以结局也相当惨烈，第一轮下来只做了一个项目。

我自己作为业务部门的负责人，本想建言献策，但是错把卡牌上的描述当成需求，不但自己陷入细节中，还把团队引到错误的方向，一时间整个局面相当混乱。

规范期：如果想要在混乱中寻找秩序那就少不了总结复盘。

在老师的引导下成功建立了业务流程。完成第一个项目后老师给我们时间优化，引导我们去找到业务优化的约束点。

我们开始尝试去在白板上通过组织架构找到工作流转的路径，因为对业务流程熟悉程度的不同，中间还进行了一次“人事调动”，公司高层决定把测试和VP的人员进行调换。

测试人员发言开始讲解项目验收规则，同时我们发现卡牌上的数字作为项目验收的前提决定着项目是否能顺利验收。在新上任的VP引导下，部门也开始协作，在探索中，项目工作顺利流转起来。

执行期：充分发挥关键角色的作用，引入可视化工具，并根据项目优先级确定工作顺序。

上一步虽然建立了流程，但是场面依然有些混乱，老师忍不住打断我们，为我们介绍了之前的活动案例，我们从中得到启发。

为了使得在项目集中快速定位关键项目，信息在不同部门之间的过程需要可视化，此时我们就借鉴其中一个团队的经验，在地上将卡牌平铺，以各个部门的工作容器为准，将项目工作依次排开。

但是因为信息并没有全员同步，开发部门并不知道我们即将发布的项目，导致部门只是被动地去接受指令，降低了团队工作的效率。

虽然过程有些坎坷，时间有限也只体验了两轮项目的发布，但是最终在团队的共同努力下，完成了高利润项目，为公司创造了业务价值，抬升了公司股价。

过程中有很多不尽人意的地方，对于DevOps的魅力也很难通过这一次活动就能体验到，但是通过此次沙盘活动，我有以下几点深刻的感悟。

1.流程是团队创建期的约束点；

不熟悉业务流程规则的情况下就是乱作一团，胡子眉毛一把抓，工作比较忌讳的就是拿到就做，没有思考关键因素关键流程，如果把这些时间运用到规则流程的制定上可能就会事半功倍

2.要想跑得快，全靠车头带；

管理层的责任就是在混乱中快速建立流程规则，迭代优化，逐步明确业务优先级，价值驱动开发，只有使团队工作不断聚焦“凤凰项目，不被内部的项目牵制，才更有可能价值最大化；

3.部门之间的割裂阻碍信息的流通；

流程的建立需要打破部门墙，业务部门和IT部门在资源的利用上有时会发生冲突，这时候就更需要明确共同的目标，大家劲往一处使，并且找到关键资源，如果某一方遇到瓶颈，通过关键资源去协调，互帮互助，完成任务的同时提升效率和质量；

4.工具的使用是让流程跑起来的重要手段；

比如可视化看板，前提是项目全部参与人员可见，保证信息拉通；

5.学习不能过度依赖闭门造车；

团队在混乱中协作探索走出绝望之谷的价值会更大，如果有高人指出方向那么开悟之坡的道路会更加顺畅。事后回顾，在活动中老师的角色有如小说中的埃瑞克，简单的点拨让人醍醐灌顶，希望在实际工作中我们也能找到这样的高人指点。