内容来源：DevOps案例深度研究第4期 – 火神山雷神山 DevOps实践研究战队（本文只展示部分PPT及研究成果，全程视频请移步文末）
本案例内容贡献者：赖泽薇、张扬、邓茜芸、韦一、刘德权、候利涛、冯利娟、常相宇、张力、韩丰、陈浩
IDCF指导老师：王立杰、许舟平、姚东、徐磊
作者：邓茜芸
（图片来源于网络）
向 战“疫”英雄致敬！
火神山雷神山简介
本次疫情影响范围广，确诊病例多，快速建成具备大规模病患收治能力的医院，隔离传染源，救治病人，对于疫情防控具有重大意义。传染病医院验收标准极高，如配套设施齐全，配备新风系统和负压系统以防止污染源外渗；要求是“三区两通道”，将医护人员和病患分离等。建设难度极大，工期短、工程量大，对设计、建造及人员物资调配均提出极高要求。
十天飞速建成，再次创造了奇迹，也再次让世界见证了中国速度。现在就让我们一起从DevOps视角来复盘火神山雷神山建设过程。
一、“小团队大后台”组织结构
火神山雷神山项目是集建筑、电信、IT、运输、能源、医疗器械等各行各业携手共建、分工合作的一个项目。
因此，二神山项目的组织架构不能完全类比IT行业的组织架构，但它也不是使用建筑行业传统树状结构的组织架构。从另一方面来说，它是一个典型的敏捷类项目，毕竟10天内建成一所大型的传染病医院，在世界建筑史上都是凤毛菱角。那么，二神山项目究竟使用了什么样的组织架构呢？先别急，我们先来看看这两个例子。
美军在二战时，以军为单位作战；到了越战，以营为单位作战；到中东战争，以7到11人的极小班排作战。前端能做到越来越小，是因为后台有非常强大的导弹、信息系统支持。我们说美军是今天全世界范围内最灵活的军事组织，也是核心竞争力和打击能力最强的组织，是因为它使用了这种强大后台支撑、小前端灵活应变的组织架构。
阿里巴巴在2015提出了“小前台+大中台” 的组织架构，它将之前细分的25个事业部打乱，根据具体业务将其中一些能够为业务线提供基础技术、数据等支持的部门整合成为“大中台”，统一为业务线提供支持和帮助。阿里搞“小前台+大中台”的组织模式，核心目的是希望能够促使组织管理更加扁平化，使得管理更加高效，组织运作效率提高，业务更加敏捷灵活。
雷神山、火神山建设是由政府部门武汉市城乡建设局发文、发出紧急命令，召集央企中建三局紧急召回各施工项目团队，同时，要求北京中元设计在78分钟内交付小汤山设计稿，联系专家复核改进。中信建筑设计院召集设计人员，成立全国公益项目，出BIM设计稿。同时，场平、排水道路、装修各个行业龙头团队有条不紊。
“小团队+大后台”的组织模式。政府背景的牵头人是强有力领导核心，在后台保障、资源调度方面提供强有力的支持。启动战时模式，大后台能够源源不断地为前端小团队提供弹药和粮草，让他们没有后顾之忧地向前冲锋。
现场施工团队由各细分行业的龙头企业负责，每个小队都是一个端到端的特性团队，授予他们充分的决策权力，给予充分的后勤保障和公共资源支撑，让这些企业带着清晰的目标，独立领导一个个小团队去推进业务，并且针对实际施工情况中的变化做快速反应。
小前端 ：让听得见炮声的人来做决策。
大后台：强大后台为实施团队赋能。
传统树状结构的职能组织中，特别是发展中后期，容易出现各种形式的“ 部门墙 ”， 主要表现在跨部协作困难 、员工沟通不畅 、互相推诿扯皮等问题上。火神山项目是网状结构组织，各建设单位跨部高效合作能发挥群体合力，创造1＋１〉２的团队效应 。主要有以下几个原因：
家国大义背景下，部门本位行为道德成本高。
工期紧张，任务繁重，首重按时保质交付。
网状组织沟通顺畅、信息共享。
组织架构扁平化、层次少。
精兵强将，端到端的责任意识强。
项目资源充足。
强有力外部监督：6000万云监工。
未完待续...
本次案例解读分为四篇，本文为第一篇章，请关注本公众号，持续阅读~
第一篇 坚强的领导核心，“小团队大后台”组织结构
第二篇 完善的项目计划，高效能价值流
第三篇 有力的技术保障，基建世界里的云原生缩影
第四篇 全能运维，召之即来，来之即战
