學這個過程是學「做」的過程。是「解決問題」的套路。

也是為了很好地理解軟體開發流程，更好地進行軟體開發搬磚工作。

而寫這個是為了練習「思考問題」的套路，工作流大概是：1正確定義問題，2建立魚骨圖/決策樹，3提出假設，4 確定數據範圍 5 收集數據。

本文屬於思考問題中的1 2工作流。

一、軍事部門的總體角色與定位

1.1軍事部門

軍事部門屬於某個政治組織，是承接這個政治組織的軍事行動項目的開發部門。

軍事部門要通過實施軍事行動項目，實現政治組織老大的某個願景，改進老大所在政治組織的某個業務指標（政治目標）。

此外 執行軍事行動的軍事部門還可以是：

1.1.1 外國遠征軍：外包項目。一個政治組織承接另一個政治組織的項目：美軍，俄軍在敘利亞；

1.1.2安保公司：政治組織不是國家，而是資本集團。僱傭軍，只要有錢賺，不問政治集團，承接任何業務；

1.1.3宗教恐怖組織。政治組織是宗教：ISIS 沒有註冊成軟體公司的自由軟體開發者或團體，黑客團體。

1.2 軍事行動

軍事行動：政治組織的軍事部門，實現政治組織的政治目標的行動。

軍事行動和戰爭有交集，但也有非戰爭軍事行動。（目標組織不是敵對的政治組織，行動也不使用武器，比如送溫暖，救災行動）

戰爭：敵對的政治集團為了各自的政治目的，進行鬥爭的活動（鬥爭手段包括軍事、經濟、顛覆、外交行動）

二、戰略

軍事行動項目的老大：某個政治組織的領導集團（國家或民族，或宗教），一般是本國。如果是外包項目，通常是因為對方矬，所以還是以本方老大為主，兼顧對方的老大的利益即可。

2.1 願景

理解政治組織領導集團對軍事行動項目的願景（術語：對上級決心的理解——究竟要軍事領域做什麼？）。

要對政治集團的業務活動建模！

內在要求：必須深刻理解軍事部門在整個政治集團中的地位和作用。軍事部門到底做什麼，才能體現軍事部門的不可或缺性？——假設在政治局全會時，軍事，經濟，外交，民政，司法，宗教各口負責人都依次上台給老大彙報自己的項目。作為軍事領域的負責人（戰區司令以上），有什麼事是你負責的軍事領域必須做，不得不做，只有靠你軍事部門做，而且只有你做了才能保住自己地位的？——綁著炸彈推銷法（假設如果軍事行動方案不能在1分鐘內打動老大，自己的隊伍就被裁軍裁掉；或者只要說「臣妾做不到」，自己就會立刻被軍紀委抓走）。

2.2 業務建模

還是屬於對上級決心的理解。

需要對政治集團與別的政治集團（外部組織）的交往，合作，鬥爭的「業務現狀」進行建模；

要改進的組織是政治集團，而不是軍事部門！（軟體系統要改進的組織 是客戶的業務，不是開發軟體的軟體公司的業務）

政治集團之間的交互業務現狀，其實包括大量經濟，文化，意識形態等其他方面的業務現狀，屬於大戰略，如果只分析軍事領域的交互，屬於軍事戰略

2.3需求

（術語：定下決心）將「對中央決心的理解」，變成軍事部門自己的 戰爭/軍事行動這個項目的需求規格說明書WRS( Warfare Requirements Specification，套用軟體的SRS)。

需求要給2個方面的人確認。

1 軍事系統外的客戶確認（上級，中央）

2 軍事系統內的架構師、項目經理：戰役部門。

明確軍事行動的執行者（雙方/多方的哪些軍事力量），和軍事行動的系統用例。（我方執行者 執行「打一頓」的系統用例，我方是主執行者，敵方是輔助執行者）

軍事領域和軟體系統的區別：必須把敵方作為輔助執行者加以考慮。不考慮的敵方行動的用例，都是自己在家裡YY。精彩戰例從來都是需要名將+豬將雙方配合，缺一不可。

甚至：必須讓敵方執行者覺得 「好用」，對方才會中招，上套。系統用例才能順利執行完。「兵以詐立」，詐的就是敵方執行者

需求：客戶可理解認可，軍事部門也可理解，可實現的軍事目標。是軍事行動中可量化的指標。包括：

2.3.1功能需求

狹義的功能：兵凶戰危、刑殺（怕見血，覺得殺人死人邪惡骯髒）：

打砸搶燒殺的目標：東西還是人？

威懾：要量化為嚇死，嚇跑對方多少投資？多少老百姓外逃？；

消滅多少敵方軍事力量，

佔領哪些軍事要地，

打擊對方軍事力量恢復能力（對敵方工業農業人口去產能去庫存XX%）

廣義的功能：

對佔領區平民送溫暖，支持率上升（伊拉克戰爭的美軍）；

根據地建設，支農支左（毛澤東）

2.3.2非功能需求

時間長短，裝備損失，少死隊友，少死我方平民；少死敵人，少死敵方平民（或者多死敵人，多死敵方平民）

三、戰策（戰役法）

指導戰役的方法與方案。方法=方向（做什麼）+法則（怎麼做），

類似作曲家編寫樂譜、架構師進行設計。

3.1分析

根據WRS，進行戰役分析 ——戰役籌劃的成果 想定籌劃方案（分析模型）

參謀部：通過系統用例 得到分析模型：模塊的屬性、方法、關係

從兩個方面 理解「聯合戰役」：

3.1.1 戰役方案籌劃的視角（分析模式）

——從面向戰役過程的結構化模型 到面向戰役對象的領域模型

傳統的戰役分析模型包括：軍事目標，戰役時間，戰役空間，戰役力量，階段劃分，主要行動……

現在的「網路/目標/火力中心戰」：目標（偵察單位，情報來源），火力（打擊單位，火力來源），目標-火力分配（目標檢測，識別，分配火力），通信傳輸，補充恢復……

——類似軟體里的 MVC 3層模式（V是發現處理外部目標，分配是C控制器，火力是M資源），或者委託代理，或者發布訂閱模式，實現了偵察（發布）與打擊（訂閱）的解耦。

不用考慮情報/火力從哪裡來。火力可以從各軍種來，為同一個目標「服務」，是為「聯合」。

3.1.2 戰役力量建設與使用（設計模式）

包括軍事裝備、軍隊建設，和戰役的設計模式。

從單塊架構的以平台、軍種為中心（偵察+打擊在同一個武器平台，同一個戰役軍團，同一個軍種），到一定程度的適配器模式，六邊形架構，微服務架構：偵察單位只管偵察，火力單位只管輸出。

領域概念以目標，火力為中心。網路是基礎設施，本身透明化。

3.2 設計（軟體開發）

作戰實施電影拍攝。成果是軍事行動的實施和項目交付

指揮部扮演控制類，調度戰術單位（實體類）完成功能

樂隊指揮不等於作曲家，導演不等於編劇，但是也要懂樂譜，懂劇本。

更加理解為什麼軟體設計中，控制類里不能有具體業務邏輯——不能靠HQ的直屬隊去打仗！樂隊指揮也不應該自己拉自己唱。

司令部：做好司（管理分發）令（命令和責任）工作就夠了。

四、戰術

進行戰鬥。演員按劇本表演。戰術單位根據戰役的設計計劃，實施具體的作戰行動。

根據指揮和樂譜，用樂器和人聲把音樂聲音出來的能力：演唱家，演奏家的功力和技藝。

實戰戰鬥（編碼+操作）的技藝+操作系統中軟硬體的能力。軍事部門裡的碼農，程序員+系統執行者操作員。「目標-火力」系統中的 運維，網管，客服，快遞員……

五、總結

5.1責任劃分

用藝術類比的話，軍隊是個武藝公司。

戰略：文藝公司老闆+市場調查分析。「為什麼人」的問題，什麼作品賣座：作品的目標市場是什麼？面向什麼涉眾？目標涉眾需要文藝片還是喜劇片？應該招募培養什麼樣的演員，積累什麼樣的劇本？（中央+戰區司令）

戰役：編劇+導演。作曲+指揮：樂章劃分，樂器聲部使用，旋律，編曲（戰區司令+參謀長）

戰術：演員。演唱演奏：樂器使用。表演、表達。（戰術單位主官）

當然，少不了「敵人上當/觀眾賞臉」的配合。作品最終要和觀眾見面，要佔領觀眾的大腦。

各自的職責和能力不可替代，也沒有從粗到細的包含關係：戰略的研究結論指導戰役方案，但是戰略學不能指導戰役學，市場調研結果和劇本之間不是從粗到細的包含關係。市場數據調查的能力和學問，也不包含導演拍戲的能力和學問。

此外，如果電影賣座，按各自的職責論功行賞（市場定位精準，還是編劇導演給力，還是演員發揮好？）；如果電影砸了，也要按各自的職責，當一天和尚撞一天鐘，當一天王八馱一天碑——在什麼位置背什麼鍋。

最矬的做法是從戰略到戰術，統統甩鍋給客觀條件和觀眾：「不是我們無能，是時間緊任務急+敵人太狡猾！」。比如相聲里這樣：

「……在人力上、物力上，都造成了不必要的損失，雖然說是個很小的錯誤，但是也有很大的客觀原因，這客觀原因是什麼呢，第一個問題牽連著第二個問題，總而言之，言而總之，錯誤不在我身上。」

人在這個開發隊伍里么？只要人在那個位置，就要擔那個位置的責任，當然，榮譽也一樣。

大戰略：政治集團的鬥爭。包括了軍事，經濟，思想，政治等政治集團的多種目標和手段，不局限于軍事層面；（中央的責任）

軍事戰略：給軍事領域的提需求。要站在軍事系統的邊界上，分析軍事部門為了政治集團的政治目標，能做什麼，該做什麼。（總部+戰區司令的責任）

張愛萍：「好的戰略計劃的核心，是對今後戰爭的認識。未來的敵人是誰，在哪裡打，打一場多大規模、什麼樣式的戰爭，我們的基本打法是什麼？這些關於戰爭研究的結論，是建設軍隊的依據。怎樣準備戰爭，建設一支什麼樣的軍隊——依據是未來的戰爭」。

「對未來面臨的戰爭，不是軍委幾個人能提出來的，軍委只是指出這個方向，這應該是全軍的任務，特別是作戰、訓練部門應該拿出來的。」

廣義的戰策：戰役力量的建設、訓練、使用的方案。（戰區司令+參謀長的責任）

狹義的戰策（戰役法）：戰役力量的使用方案。軍隊進行作戰行動的方法=方向（做什麼）+法則（怎麼做）。（戰區司令+參謀長的責任）

戰術：方案具體實現落地。（戰役軍團，戰術單位的指揮員+戰鬥員的責任）

5.2當前的問題

這10年來，聯合戰役很火爆，而戰略方面研究有弱化的趨勢。（文獻專著數量明顯不如99-02年）。

現在的問題似乎是，戰役部門聲稱「聯合戰役大法好」，只要在一個方向上組織1個大規模聯合戰役就能直接解決政治組織在這個方向上的戰略需要。

和軟體領域的互聯網公司興起，「敏捷大法好」，建模弱化的現象，很類似。

我的看法：

戰役開發領域 的 分析設計工作流的改進 敏捷+新架構，微服務/RESTful/serverless，不能代替前面的業務建模和需求工作流。

系統好壞的關鍵不在於規模有多大，是不是分散式，技術是否先進，而是要能解決涉眾的願景。

5.2.1不考慮交戰對手，就不能保證一個戰役解決問題：一次大戰前的歐洲列強，二戰德軍總參謀部，都是類似的想法。結果證明，總參謀部只做設計，沒人做需求。最後項目失敗，敗軍亡國。

5.2.2戰略部門應該明確自己領域的特有的研究問題（需求），不要從戰役戰術領域借用來大量概念，冠以戰略二字了事。孫子兵法里的五事七計，道天地將法，其實就是戰爭能不能打的限制條件。

戰略部門做好軍事行動的需求工程，提出的需求對軍事部門外有用好用；對內清晰、明確、可實現。這非常重要，也非常難得。