50000沙盘模拟经营视频讲解教程，凤凰项目 mobi

50000

如何通过沙盘模拟快速学习——凤凰项目[林西DevOps沙盘经验总结

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

会上，项目管理行业大咖王军先生带我们一起探索IT武侠小说《凤凰计划:IT运维传奇》中的奥秘，在激烈的实战模拟中，引导组织从混沌走向协同作战，从中学习团队组织的完善和各种DevOps工具方法的使用。

虽然对DevOps的了解有限，但还是想把自己的收获和想法整理记录下来，以便日后运用到实践中。

实战开始前，王老师给我们讲了“凤凰计划沙盘”的由来和规则，让大家通过抽签来确定自己的部门。

我当时画的是零售运营。那一刻，萨拉在《凤凰计划》这本书里的角色立刻浮现在我的脑海里。通过向上管理，不断给组织施压，推卸责任，导致凤凰计划紧急启动后出现了很多漏洞。

我不知道在这场暴风雨般的战斗中，我面临着怎样的考验。

凤凰计划的部门和角色包括首席执行官，CISO，首席技术官，首席财务官，零售运营，人力资源，IT副总裁，开发，IT支持，IT运营，测试团队和变革管理。

“虚拟公司”的组织结构图如下:

整个团队的目标是通过各个部门的合作，完成来自市场的项目，提高公司股价，这对我们新组建的团队来说，确实是一个很大的挑战。

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

休克期:刚开始，整个团队处于休克期，工作流程没有建立起来。

大部分团队都是沙盘项目新手，他们不熟悉活动规则，甚至不知道卡片上的内容是什么意思。老师还故意把检测部门拉到一边，造成部门之间的分裂。

业务部门接到项目的时候，只有领导关起门来讨论，闭门造车，各部门之间没有太多的配合。团队之间的交流也是口口相传，所以结局还是比较悲剧的。第一轮只做了一个项目。

作为业务部门的负责人，本想提建议，却把卡片上的描述错当成了需求。我不仅被细节缠住了，还把团队引向了错误的方向。一度整个局面相当混乱。

规范期:要想在混乱中找到秩序，必须总结复盘。

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

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

测试人员开始讲解项目验收规则，我们发现卡片上的数字作为项目验收的前提，决定了项目能否成功验收。在新上任的VP指导下，各部门也开始合作，项目工作在摸索中顺利交接。

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

虽然最后一步建立了流程，但是现场还是有点混乱。老师忍不住打断了我们，给我们介绍了之前的活动案例，从中我们受到了启发。

为了快速定位项目集中的关键项目，需要对不同部门之间的信息处理过程进行可视化。这个时候我们会借鉴一个团队的经验，把牌平铺在地上，按照各部门的工作容器依次安排项目工作。

但是由于信息不是所有员工同步的，开发部门对我们即将发布的项目并不了解，导致部门被动接受指令，降低了团队工作的效率。

虽然过程有点坎坷，由于时间有限只经历了两轮项目发布，但最终在团队的共同努力下，完成了高利润的项目，为公司创造了商业价值，提振了公司股价。

过程中有很多不尽如人意的地方，也很难通过这次活动体会到DevOps的魅力，但通过这次沙盘活动，我有以下深刻的感悟。

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

不熟悉业务流程规则，就会乱七八糟，抓胡子眉毛一把抓，干工作是大忌，不去想关键因素和关键流程。如果把这些时间用在规则和流程的制定上，可能会事半功倍。

2.要想跑得快，必须依靠头带；

管理层的职责是快速建立流程规则，迭代优化，逐步明确业务优先级，推动价值驱动的开发。只有让团队工作不断专注于“凤凰计划”，不受内部项目约束，才能实现价值最大化；

3.部门之间的分割阻碍了信息的流动；

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

4.工具的使用是使过程运行的重要手段；

例如，如果项目中的所有参与者都是可见的，视觉看板可以确保信息被传递；

5.学习不要太依赖闭门造车；

团队在混乱中探索出绝望之谷会更有价值，如果有专家指明方向，开悟之路会更顺畅。事后回想，老师在活动中的角色就像小说中的埃里克，简单的指令让人醍醐灌顶。希望在实际工作中能找到这样的专家指导。