近年来我一直在研究IT行业的管理框架，希望能帮助设计行业改进一下项目管理的方法。前些天在Medium上看到一篇有用敏捷框架解析俄乌战争的文章，感觉很有启发，索性翻译过来，分享给大家。
原文名为：
Agile, and the failure of the Russian Waterfall battle management in Ukraine.
2022年3月31日 发表于 Medium， 原作者: Marco Capriz 翻译：李海乐
有关俄军在乌克兰的特别军事行不动，已经有了很多的讨论，为什么军事力量强大的俄罗斯就是对付不下来特别弱鸡的乌克兰？我判断的原因是，俄军采用了类似瀑布流的方法来指导军事行动，而非敏捷方法。
你可能会疑惑，软件开发管理能跟战争有什么关系？你又怎么知道俄军高层是如何在指挥战役的？好问题，我先来回答第二个。
从我读到的各种资料来看(不光是英文资料，还包括乌克兰和俄罗斯方面的报道——感谢谷歌翻译)，在命令和执行层面，俄军出现了很大的问题。由于补给线被切断，大量的坦克和各种重型装备被乌军阻止，停滞甚至是缴获。看起来乌军竟然知道俄军补给线的致命缺陷在什么地方，精准打击，导致俄军士兵士气低落，进而直接放弃他们的重型装备。同样的原因，也造成俄军高级将领需要直接到最前线去指挥战斗，这又导致将军们一个一个被狙击手或是精准制导武器射杀。
这些问题都可以用项目管理方法来进行审视。可以观察到的是，俄军没能对随时发生变化的战地环境作出及时的反馈，尤其是在士官和低级军官层面，这导致俄军高级军官的损失高得出奇。我可以做出判断，俄军并没有以现代战争的方法来指导战斗。这由我们观察到的另一个问题作为支撑：俄军的内部协作都没有执行下去。俄罗斯空军损失惨重，他们无法有效躲避乌克兰的防空力，甚至还被自己的防空力量误伤。
所有这些迹象都表明了，俄军在作战指令和执行上脱节了。其实，这就是项目管理失败的典型案例。俄军在前线遇到的状况跟战争准备时所预计的完全不一样，他们只能停下来等待高层去重新制定计划。这让我想到了瀑布流的管理方法，也就回答了刚才提到的第一个问题。
我承认我有偏见，我不喜欢瀑布流。我之前在实施瀑布流管理方法的公司工作过，当然不可避免地发现，在项目周期中，只要有哪怕很小一点儿条件变化，都会对结果和交付时间产生非常负面的影响。瀑布流只适用于项目经理能够完全把控周围环境条件的情形下。典型的瀑布流管理流程是：提出概念，初始准备，分析研究，设计，建造，测试，发布，以及维护。执行过程中条件变化，就要回退到更前面的流程去重新制定计划，这会影响到下游的所有工作。我参与过的瀑布流项目，无一例外结果都很糟糕。我最近工作过的一家游戏开发公司，管理层坚持在所有层面使用瀑布流的方法，结果导致灾难性后果，主要因为开发前期研究总是在项目执行的过程中被推翻。
我们重新用项目管理的理念来审视这场战争，你会发现之间的关联：俄罗斯看起来就是在使用瀑布流的方法，他们本计划发起一场闪电战，在几天时间内逼迫乌克兰投降。结果执行下去发现完全不是那么回事。他们在前期计划的时候没有考虑到乌军的强烈抵抗意志，这也导致他们的后勤系统规划并没有考虑持久支撑前方推进。他们也没有对初始计划进行演练测试，以至于在执行过程中发现面对的情况完全出乎意料。截止我写作至此的时间，有消息称俄罗斯会改变作战目标，致力于控制住乌克兰东部地区，已经跟之前的目标大相径庭了。
以上提及的战场变化，在北部和东北乌克兰给俄军造成了巨大的资源浪费和人员物资损失。俄军的特别军事行动让乌克兰人民更加坚定地抵抗侵略者，而俄军失去了另一项更为宝贵的资源：时间。乌克兰人已经利用这一段时间获取了比开战时多得多的各种武器装备，这使得俄军的行动会更加困难。
与之相对应的，乌军采用了完全不一样的战斗策略。很明显，抵抗侵略的战斗需要根据战场的变化及时反馈，因地制宜地快速做出行动。乌军实际上将作战决策下放到了更小的战斗单位，让他们在战场上为更具体的小目标自己做决策。很可能连乌军自己都没有意识到，他们正在打一场敏捷战争。在敏捷开发的语境中(因为我熟悉Scrum，所以我在此使用了Scrum术语):
史诗级(Epic)目标就是：抵抗侵略保卫祖国；故事级(Story)目标可以被定义为在各个地点的系列战斗目标；冲刺(Sprint)就是每一个单独的抵抗行动；每日立会(Daily Scrum meetings)相当于每日的战斗目标和推进过程，这些目标和推进过程根据当下情况以及敏捷教练Scrum Master(排长指挥官)和产品负责人Product owner(高级军官)提供的全局情报来及时调整。根据每天行动的情况，失败或是成功，及时作出评估和调整，每日回顾作为短期调整的依据，而冲刺评审和冲刺回顾作为相对长期行动的评估依据。
如果您觉得我是在将软件项目管理的方法强加在看起来完全不相关的事情上，那么请了解一下：在许多西方国家的军队中，敏捷管理，已经被特种部队广泛采用。安东尼·马克诺是一名曾经为特种部队服务的软件顾问，他将敏捷开发和特种部队行动的显著相似之处描述为：
很少有人会将特种部队战术跟软件开发管理联系到一起。但现在特种部队的行动方式跟软件开发团队的工作方式的确非常相似。
马克诺在一篇文章中指出，如果组织中某个成员拥有的专业技能不能在团队中分享，那就对团队工作没有贡献。在一个敏捷团队中，总有几个专家，在大多数情况下，他们都或多或少地分享了他们的特殊技能。这样，当周围环境发生变化时，团队内部就能及时作出调整，甚至是在相关专家并不在场的情形下也能作出调整。
敏捷，更是促进了战场上的另一种优势：下放权力，自主决策——这又将我的思绪带回俄军在战场上的离奇表现。
在二月开始的这场特别军事行动之前，俄军在乌克兰成功地实现了自己的目标。吞并克里米亚，有效占领顿巴斯地区，都是格拉西莫夫全面战争理论指导下的成功案例。格拉西莫夫将军在一篇名为《科学的价值在于先见之明》的文章中阐明了这种战略思维，这篇文章发表在俄罗斯的 《军事工业速递》周刊上。格拉西莫夫提倡通过军事行动建立战略优势。这些策略的应用都造就了俄军在克里米亚行动的成功。
格拉西莫夫比较了对于军事力量的传统用法和新方法的区别：
军事力量的应用
政治，外交，经济和其他非军事手段，同军事力量综合使用
传统的方法
新的方法
-战略部署之后开展军事行动
-以和平时期的部队集结初始化军事行动
-摧毁对方人员与武器，攻破对方防线，占领对方领土
-多个部队配合执行高机动性，非接触战斗
-摧毁对方经济，通过摧毁对方经济控制占领的土地
-在短时间内摧毁对方关键军事民用设施，以降低对方回复军事与经济力量的可能性
-地面，空中，海面作战
-大规模运用精准制导武器，特种作战部队，和基于新的行动原则的机器人和武器系统
-在物理环境和信息环境中同时执行战斗
-非对称和间接的军事行动
-通过严格的层级结构传达和执行作战指令
-在统一信息空间下传达和执行作战指令
格拉西莫夫的一些方法被成功(当然是站到俄罗斯的立场而言)运用到了乌克兰的行动中：
-高机动性能，非接触的战斗。例如俄军在顿巴斯跟当地叛军一起开展的军事行动。
-大规模使用特种部队。基于新的作战原则，由当地武装参与，利用对当地居民的同情。
-同时在物理空间和信息空间发起战争。俄罗斯非常善于利用代理人散播不实消息，无论在乌克兰或是世界范围都是如此，他们非常成功。
在这篇文章中，格拉西莫夫还声称：
非对称战斗行动被广泛应用，使得敌人的军事优势无法发挥。在这些行动中，我们利用敌人的内部反对力量，在敌人全境发起攻击，并且不断改进优化。
以及：
新的信息技术已经极大降低了军事力量和管理体系在空间和信息上的差异。在前线聚集大量军事力量的做法已经过时。远程，无接触的行动，正在成为首选的方法。战胜敌人的战斗在整个领土纵深上展开。战略，执行，战术，以及进攻和防御行动的区别正在消失。
最后一段尤为有趣。将军指出，由于指挥系统变得扁平，这就要求在战术层面上做出更加迅速的反应，这只有颠覆传统的管理角色才能实现。马克诺有关行动角色定义的思考，正好与之密切相关。只有在敏捷环境中，扁平化的组织结构和快速反应才能达成。西方第四代战争准则强调了扁平化的指挥构架，这些新的战争范式如下：
在平民有伤亡风险的区域：
平民伤亡导致被敌军征兵平民伤亡导致主和派在政治上的尴尬
外科手术式精确行动：
打了就走间接侧翼攻击攻击后勤供应线
形成连锁破坏
制造连带损失第四代战争准则的地缘文化景观被敌军熟悉，但和平派并不了解
用来应对复杂多变环境的战法已经出现，近十年来，在中亚和中东都得到了应用。这些新的方法要求形成更加灵活和扁平的组织结构，以便在战场环境中随机应变。前线的战队单位得到了比以往多得多的信息，使得他们对自身所处的情形有着全面的了解。在敏捷/Scrum语境中，情报部门提供给前线作战单位的信息作为 用户故事 的拟定支撑，从而进入到情报循环和OODA(观察-导向-决定-行动)行动链条中。在四代战法环境下，前线战斗单位对完成用户故事全权负责，士官就是敏捷教练，当行动情报发生改变时，只接受高级军官（产品负责人）的指令输入。马克诺提出的方法不仅用于特战部队，还延展到了所有前线作战单位。
俄军在入侵乌克兰行动中的问题是显而易见的，他们未能执行四代战法的重要元素：
-在平民受到战损威胁的区域
-外科手术式的打击
-地理文化环境
另外，很明显俄军并没有给前线士官充分的授权。他们似乎遵循了事先确定好的瀑布流式策略，而这种策略根本无法应对战场上的动态变化。俄军指挥官看起来放弃了在前几年还很成功的战斗策略，进而采用了类似二战时期的过时战法。
实际上，就算是用瀑布流的语境来看，俄军也没有切实执行，概念，分析，设计，建构，测试，执行和维护，一个都没有做到位。因为完成建构，执行阶段的前线部队根本就不知道这场战争的概念是什么，当他们跨越边境，进入乌克兰的时候，还被告知这是一场演习。
这使得我更加确认了瀑布流和敏捷的区别。在我的经验中，瀑布流方式管理经常被用于组织构架完整而严密的公司。这样的组织架构很难适应环境变迁，尤其是迅速变化的场景。俄军在乌克兰遇到的场景显然就是急速变化的。
格拉西莫夫可能想要通过应用他的准则来印证他的观点。而另一方面，应用敏捷的机构必须明白两件事情：1，决策权必须下放；2，必须信任被予以决策权的人。这就是为什么在经理不信任员工的公司，总是不敢采用敏捷策略。在应用瀑布流的框架下，当项目研究成果被证实有问题时，他们总是会用掉远超预期的资源，而且这种问题会在项目运行的很后期才能够被发现。
对于权力只被最高层掌控的政府而言，这样的情形也会发生。这种权力结构会在没有实权的中层管理和劳动阶层中形成积怨(就俄军的案例而言，就是士官和士兵阶层)，忠诚度和战斗士气都被削弱。当项目运行发生偏差时，高层能够想到的办法就只有堆更多人上去，而不是重构管理模式。这在独裁的机构中会形成持续的问题，因为他们拒绝下放权力。
在敏捷环境下，目标和责任都被分解下放，被赋予权力的员工能够在环境改变的情形下及时有效地自主决定，加以应对。这就是为什么在民主政体，或是类似架构的公司中，解决问题会更加迅速而高效。当然，这是很粗略的观察。但越来越明显的趋势表明，敏捷能够且应当被用于一些政府项目的管理上。这些管理理念也最终会影响到组织构架特别严密的军队中。许多四代战法准则要求扁平结构，快速决策和权力责任下放。我曾经为制造未来士兵系统的公司工作过。这种系统将战术情报一直传递到前线作战人员，让他们能够对环境变化做出迅速反应，当然他们也会知道他们自己的决策会对更大范围内的战斗形成什么样的影响。这对士兵提出了更高的要求，他们不仅需要在技术上非常熟练，还要学会在没有高级指挥官命令的前提下，自行做出决策。特种部队已经具有这些能力，但在技术手段的帮助下，这种能力可以被赋予更多的士兵，前提是要改变作战指挥的理念。
在战争环境中全面应用敏捷方法，可能不会在短期内实现，但促使这种转变的技术手段已经存在，从而加快转变。
在政府管理的其他领域，已经有了敏捷方法的成功案例。根据一家提供敏捷培训，叫做Scale Agile的公司报道，有超过500家的州和联邦机构，办公室和承建商信任敏捷框架。 敏捷还被芬兰的学校用来作为教学方法支撑。在名为政府革新——构建以敏捷和市民为中心的公共事务的活动中，欧盟为发展和实践支撑的政府改进学习计划提供财政支持。
但为了乌克兰的明天，我们希望俄军跟上敏捷的改变不要发生太快。
原文链接：
https://medium.com/@marcocapriz/agile-and-the-failure-of-the-russian-waterfall-battle-management-in-ukraine-244138ee53a5
Powered by冲啊Scrum
