Back to Details

art-of-war-software-engineering

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

⚔️ Art of War for Software Engineering

⚔️ 软件工程版《孙子兵法》

"The general who wins a battle makes many calculations in his temple before the battle is fought." — Sun Tzu
Without this framework, teams commit to initiatives with hidden weaknesses — wrong timing, technical terrain that can't support the feature, no clear ownership, or engineers building without knowing why. The Five Factors surface these risks before resources are spent.
“夫未战而庙算胜者，得算多也。”——孙武
如果没有这个框架，团队会投入存在隐藏缺陷的项目——时机错误、技术架构无法支撑功能、缺乏明确负责人，或是工程师在不清楚原因的情况下盲目开发。这五大因素能在资源投入前就暴露这些风险。

🏛️ The Five Fundamental Factors (Ngũ Sự)

🏛️ 五大核心因素（Ngũ Sự）

Five parallel evaluation criteria. Score all simultaneously — not a sequential pipeline.
五个并行的评估标准。需同时对所有因素评分——而非按顺序进行。

1. Tao (道 — The Way)

1. Tao（道）

Definition: Shared vision and alignment between stakeholders and the engineering team.
  • Software Mapping: Does every engineer know why we are building this? → 
    why-strategic-rationale
  • Check: Can any engineer articulate the business value without reading a doc?
ScoreSignal
1–3No WHY Statement. Direction changes weekly. Engineers "just completing tickets".
4–6Some alignment but different team members give different answers to "why".
7–10Clear WHY Statement + JTBD defined. All engineers can articulate business value.
If score < 5: Run 
why-strategic-rationale
before proceeding.
定义： 利益相关者与工程团队之间的共同愿景与对齐度。
  • 软件工程映射： 每位工程师都清楚我们开发这个的原因吗？→ 
    why-strategic-rationale
  • 检查项： 任何工程师无需查阅文档就能阐述业务价值吗？
评分信号
1–3无WHY声明。方向每周变动。工程师仅“完成工单”。
4–6存在一定对齐度，但团队成员对“为什么”的回答不一致。
7–10清晰的WHY声明 + 已定义JTBD。所有工程师均可阐述业务价值。
若评分 < 5： 在推进前执行
why-strategic-rationale
。

2. Heaven (天 — Timing)

2. Heaven（天）

Definition: External conditions beyond control — market trends, timing, competition.
  • Software Mapping: Is the market ready? → 
    diffusion-release-tracking
    Rogers curve
  • Check: Launching too early (market not ready) or too late (missed window)?
ScoreSignal
1–3No market validation. Building on assumption. Competitors dominate with no visible gap.
4–6Some demand signals but timing unclear. Problem unvalidated.
7–10Problem validated via 
problem-discovery
. Target segment identified. Chasm strategy defined.
If score < 5: Run 
problem-discovery
+ 
diffusion-release-tracking
before proceeding.
定义： 不受控制的外部条件——市场趋势、时机、竞争态势。
  • 软件工程映射： 市场是否已准备就绪？→ 
    diffusion-release-tracking
    Rogers曲线
  • 检查项： 过早发布（市场未准备好）还是过晚发布（错失窗口）？
评分信号
1–3无市场验证。基于假设开发。竞争对手占据主导且无明显可切入的缺口。
4–6存在部分需求信号，但时机不明确。问题未经过验证。
7–10已通过
problem-discovery
验证问题。已确定目标细分群体。已定义跨越鸿沟的策略。
若评分 < 5： 在推进前执行
problem-discovery
+ 
diffusion-release-tracking
。

3. Earth (地 — Terrain)

3. Earth（地）

Definition: Technical landscape, legacy systems, infrastructure — the "ground" you must traverse.
  • Software Mapping: Tech debt, system boundaries, architecture → 
    c4-model
    + 
    ddd-core
  • Check: Is tech debt too heavy to traverse? Should we buy instead of build?
ScoreSignal
1–3Massive tech debt. Monolith. >6 months to change core component. No CI/CD.
4–6Some debt, partially modular. Deploy takes days. Inconsistent test coverage.
7–10Clean C4/DDD architecture. Loosely coupled. Core Domain isolated. Deploy < 1 hour.
If score < 5: Run 
c4-model
audit. Identify debt hotspots. Evaluate SaaS/managed services for Generic Subdomains before committing to build.
定义： 技术环境、遗留系统、基础设施——即你必须攻克的“阵地”。
  • 软件工程映射： 技术债务、系统边界、架构 → 
    c4-model
    + 
    ddd-core
  • 检查项： 技术债务是否过重以至于难以推进？我们应该采购而非自行开发吗？
评分信号
1–3大量技术债务。单体架构。修改核心组件需耗时6个月以上。无CI/CD。
4–6存在部分债务，架构部分模块化。部署需耗时数天。测试覆盖率不一致。
7–10清晰的C4/DDD架构。松耦合。核心域已隔离。部署耗时<1小时。
若评分 < 5： 执行
c4-model
审计。识别债务热点。在决定开发前，评估针对通用子域的SaaS/托管服务。

4. Command (將 — Leadership)

4. Command（将）

Definition: Leadership qualities — wisdom, accountability, decision-making clarity.
  • Software Mapping: Architects, PMs, Senior Engineers → 
    business-product-leadership
  • Check: Is there one DRI (Directly Responsible Individual) for the technical vision?
ScoreSignal
1–3No clear owner. Decisions by committee or HIPPO (Highest Paid Person's Opinion).
4–6Nominal ownership but unclear accountability. Gut-feel decisions dominant.
7–10Clear DRI. Data-driven decisions. WHY understood and owned by leadership.
If score < 5: Establish ownership and define RACI before execution begins.
定义： 领导力特质——智慧、责任感、决策清晰度。
  • 软件工程映射： 架构师、产品经理、资深工程师 → 
    business-product-leadership
  • 检查项： 是否有一位DRI（直接负责人）负责技术愿景？
评分信号
1–3无明确负责人。决策由委员会或HIPPO（最高薪资者意见）主导。
4–6名义上有负责人，但问责制不清晰。凭直觉做决策占主导。
7–10清晰的DRI。基于数据做决策。领导层理解并认同WHY。
若评分 < 5： 在执行前确定负责人并定义RACI。

5. Method (法 — Discipline)

5. Method（法）

Definition: SDLC discipline, logistics, operational structure.
  • Software Mapping: CI/CD, testing, DORA metrics → 
    dora-core
  • Check: Are deploy pipelines robust? Is testing/linting consistent?
ScoreSignal
1–3Manual deployment. No CI/CD. DORA: Low tier (deployments < monthly).
4–6Some automation but inconsistent. DORA: Medium tier.
7–10Full CI/CD. Automated testing. DORA: High/Elite tier. Lead time < 1 hour.
If score < 5: Run 
dora-core
baseline. Fix CI/CD before adding feature complexity.
定义： 软件开发生命周期规范、流程、运营结构。
  • 软件工程映射： CI/CD、测试、DORA指标 → 
    dora-core
  • 检查项： 部署管道是否稳健？测试/代码检查是否一致？
评分信号
1–3手动部署。无CI/CD。DORA：低层级（部署频率<每月1次）。
4–6存在部分自动化但不一致。DORA：中层级。
7–10完整的CI/CD。自动化测试。DORA：高层级/精英级。交付周期<1小时。
若评分 < 5： 执行
dora-core
基线评估。在增加功能复杂度前修复CI/CD问题。

⚖️ Strategic Assessment Matrix

⚖️ 战略评估矩阵

Score all five factors simultaneously before committing to any initiative.
FactorScore /10If Low → Action
Tao 道 — WHY clear to every engineer?Run 
why-strategic-rationale
Heaven 天 — Market timing validated?Run 
problem-discovery
+ 
diffusion-release-tracking
Earth 地 — Tech terrain navigable?Run 
c4-model
audit, consider SaaS
Command 將 — Single DRI accountable?Establish ownership, define RACI
Method 法 — Pipeline automated?Run 
dora-core
baseline
Total/50
ScoreDecision
40–50Excellent positioning. Proceed at full speed.
30–39Proceed with caution. Fix lowest-scoring factor before sprint planning.
< 30STOP. Fix the two lowest-scoring factors. Re-assess before committing resources.
在投入任何项目前，同时对所有五个因素进行评分。
因素评分 /10低分→行动
Tao（道） —— 每位工程师都清楚WHY吗？执行
why-strategic-rationale
Heaven（天） —— 市场时机已验证？执行
problem-discovery
+ 
diffusion-release-tracking
Earth（地） —— 技术环境可推进？执行
c4-model
审计，考虑SaaS
Command（将） —— 有单一DRI负责？确定负责人，定义RACI
Method（法） —— 管道已自动化？执行
dora-core
基线评估
总分/50
评分决策
40–50定位极佳。全速推进。
30–39谨慎推进。在 sprint 规划前修复得分最低的因素。
< 30停止。 修复得分最低的两个因素。在投入资源前重新评估。

🎯 Strategic Stratagems

🎯 战略策略

1. "Know Yourself, Know Your Enemy"

1. “知己知彼”

"If you know the enemy and know yourself, you need not fear the result of a hundred battles."
Know yourself: Audit team capabilities, tech debt (Earth), Core Domain boundaries. Know your enemy: Run 
problem-discovery
— customer interviews + LMR (job board scan) + competitor analysis. Competitor analysis reveals the beachhead niche.
DO: Complete 
problem-discovery
before defining JTBD. DON'T: Substitute SWOT gut-feel for actual market signals. Assumptions are not intelligence.
“知己知彼，百战不殆。”
知己： 审计团队能力、技术债务（地）、核心域边界。 知彼： 执行
problem-discovery
——客户访谈 + LMR（招聘平台扫描） + 竞品分析。竞品分析可揭示突破口细分市场。
应做： 在定义JTBD前完成
problem-discovery
。 勿做： 用SWOT直觉替代实际市场信号。假设不等于情报。

2. "Win Without Fighting" (The Sheathed Sword)

2. “不战而屈人之兵”（藏锋）

"The supreme art of war is to subdue the enemy without fighting."
For every feature, ask: Core Domain or Generic Subdomain?
  • Generic Subdomain → buy SaaS (Auth → Auth0, Payments → Stripe, Email → SendGrid)
  • Core Domain → build with full engineering investment
DO: Default to SaaS for anything outside Core Domain. DON'T: Build Generic Subdomains. Every one you build steals engineering energy from your Core Domain — the only place you can actually win.
“是故百战百胜，非善之善者也；不战而屈人之兵，善之善者也。”
对于每个功能，问自己：核心域还是通用子域？
  • 通用子域 → 采购SaaS（认证→Auth0，支付→Stripe，邮件→SendGrid）
  • 核心域 → 投入全部工程资源开发
应做： 对于核心域外的内容，默认选择SaaS。 勿做： 开发通用子域。每开发一个通用子域，都会从核心域——你唯一能真正取胜的地方——分散工程精力。

3. "Avoid Strength, Attack Weakness"

3. “避实击虚”

"Water runs away from high places and hastens downwards."
Strength = dominant competitors with moats, or your own legacy codebase. Weakness = underserved niches competitors ignore, new isolated microservices vs. monolith.
DO: Identify underserved segment from 
problem-discovery
competitor analysis → use as beachhead. Dominate that niche completely, then cross the Chasm (
diffusion-release-tracking
). Target Early Adopters first. DON'T: Compete head-on with dominant player. Don't refactor a massive monolith when you can build isolated new value instead.
“水因地而制流，兵因敌而制胜。”
实 = 拥有护城河的主导竞争对手，或你自己的遗留代码库。 虚 = 竞争对手忽略的未被服务的细分市场，新的独立微服务 vs 单体架构。
应做： 从
problem-discovery
的竞品分析中识别未被服务的细分群体→将其作为突破口。完全主导该细分市场，然后跨越鸿沟（
diffusion-release-tracking
）。首先瞄准早期采用者。 勿做： 与主导玩家正面竞争。当你可以构建独立的新价值时，不要重构庞大的单体架构。

4. "Binh Như Nước" — Water Strategy (Adaptability)

4. “兵形象水”——水策略（适应性）

"Shape your flow according to the nature of the ground over which it flows."
DO: Ship behind feature flags. Maintain high Deployment Frequency (
dora-core
). Keep architecture loosely coupled. DON'T: Build tightly coupled monoliths or plan big-bang releases. Frozen water cannot flow — when Heaven (market) changes, you must be able to pivot.
“故兵无常势，水无常形；能因敌变化而取胜者，谓之神。”
应做： 通过功能标志发布。保持高部署频率（
dora-core
）。保持架构松耦合。 勿做： 构建紧耦合的单体架构或计划大爆炸式发布。结冰的水无法流动——当天（市场）变化时，你必须能够快速转向。

🔄 Integrated Workflow

🔄 集成工作流

1. Ngũ Sự Assessment (score /50)                    [Sun Tzu, ~500 BC]
   ├─ < 30  → Fix 2 lowest factors → re-assess
   └─ ≥ 30  → Proceed

2. "Know Yourself/Enemy" → problem-discovery
   ├─ Customer interviews                            [Blank 2005]
   ├─ Lean validation (landing page, smoke test)    [Ries 2011]
   └─ Output: Problem Statement + beachhead niche

3. "Establish Tao" → why-strategic-rationale
   ├─ VPC (Value Proposition Canvas)                [Osterwalder 2014]
   ├─ PR/FAQ (Working Backwards)                    [Amazon; Bryar & Carr 2021]
   └─ Output: WHY Statement + JTBD                 [Christensen; Moesta]

4. "Map Earth" → c4-model + ddd-core
   ├─ C4 architecture mapping                       [Simon Brown 2011]
   ├─ Domain-Driven Design                          [Evans 2003]
   ├─ Generic Subdomain → "Win without fighting" → buy/SaaS
   └─ Core Domain → build

5. "Water strategy" → ship/release
   ├─ Feature flags (dark launch)                   [Fowler 2010]
   ├─ Early Adopters → Rogers curve → Cross Chasm   [Rogers 1962; Moore 1991]
   └─ DORA metrics = measure adaptability           [Forsgren, Humble, Kim 2018]
Ngũ Sự runs as audit layer at each step — not just at the start.
1. Ngũ Sự 评估（评分 /50）                    [孙武，约公元前500年]
   ├─ < 30  → 修复得分最低的2个因素 → 重新评估
   └─ ≥ 30  → 推进

2. “知己知彼” → problem-discovery
   ├─ 客户访谈                            [Blank 2005]
   ├─ 精益验证（着陆页、烟雾测试）    [Ries 2011]
   └─ 输出：问题陈述 + 突破口细分市场

3. “确立道” → why-strategic-rationale
   ├─ VPC（价值主张画布）                [Osterwalder 2014]
   ├─ PR/FAQ（逆向工作法）                    [亚马逊; Bryar & Carr 2021]
   └─ 输出：WHY声明 + JTBD                 [Christensen; Moesta]

4. “绘制地” → c4-model + ddd-core
   ├─ C4架构映射                       [Simon Brown 2011]
   ├─ 领域驱动设计                          [Evans 2003]
   ├─ 通用子域 → “不战而屈人之兵” → 采购/SaaS
   └─ 核心域 → 开发

5. “水策略” → 交付/发布
   ├─ 功能标志（暗发布）                   [Fowler 2010]
   ├─ 早期采用者 → Rogers曲线 → 跨越鸿沟   [Rogers 1962; Moore 1991]
   └─ DORA指标 = 衡量适应性           [Forsgren, Humble, Kim 2018]
Ngũ Sự 在每个步骤中作为审计层运行——而非仅在开始时。

🔗 Connection to Ecosystem

🔗 与生态系统的关联

  • → 
    why-strategic-rationale
    : Establishes the Tao (WHY Statement)
  • → 
    problem-discovery
    : Executes "Know Your Enemy" (market + competitor signals)
  • → 
    diffusion-release-tracking
    : Navigates the Heaven (Rogers curve + Chasm)
  • → 
    c4-model
    + 
    ddd-core
    : Maps the Earth (architecture + domain)
  • → 
    business-product-leadership
    : Exercises the Command (JTBD + MVP + DRI)
  • → 
    dora-core
    : Refines the Method (CI/CD + DORA metrics)
  • → 
    why-strategic-rationale
    : 确立Tao（WHY声明）
  • → 
    problem-discovery
    : 执行“知彼”（市场 + 竞品信号）
  • → 
    diffusion-release-tracking
    : 应对Heaven（Rogers曲线 + 鸿沟）
  • → 
    c4-model
    + 
    ddd-core
    : 绘制Earth（架构 + 领域）
  • → 
    business-product-leadership
    : 践行Command（JTBD + MVP + DRI）
  • → 
    dora-core
    : 优化Method（CI/CD + DORA指标）

🚫 Strategic Anti-Patterns

🚫 战略反模式

Anti-patternDetection SignalConsequenceFix
High Method, Zero TaoEngineers ship daily but can't explain business valueEfficiently building the wrong thingWHY Statement before next sprint
Attacking strengthCompeting head-on with dominant player in their core marketResource drain, no path to winBeachhead: dominate underserved niche first
Building Generic SubdomainsAuth, payments, email built in-houseEngineering energy stolen from Core DomainReplace with SaaS, redirect capacity
Ignoring the EarthAdding features to high-debt codebase with no auditVelocity collapse, production incidentsC4/DDD audit before committing to timeline
Frozen waterMonolith, big-bang releases, no feature flagsCannot pivot when market changesLoosely coupled services + feature flags + high DF
Command without MethodStrong vision, inconsistent/manual pipelinesVision never ships reliablyDORA baseline → CI/CD investment
反模式检测信号后果修复方案
高规范，无愿景工程师每日交付但无法解释业务价值高效地开发错误的产品在下一个sprint前制定WHY声明
以实击实在核心市场与主导玩家正面竞争资源消耗，无取胜路径突破口：先主导未被服务的细分市场
开发通用子域认证、支付、邮件均为内部开发工程精力从核心域被分散替换为SaaS，重新分配资源
忽视技术环境在未审计的高债务代码库中添加功能交付速度骤降，生产事故频发在确定时间线前进行C4/DDD审计
静水模式单体架构、大爆炸式发布、无功能标志市场变化时无法快速转向松耦合服务 + 功能标志 + 高部署频率
有领导无规范愿景清晰，但管道不一致/手动愿景无法可靠交付DORA基线评估 → 投入CI/CD

📚 Sources

📚 资料来源

ConceptAuthor / SourceYearSearch keywords
Five Factors (Ngũ Sự)Sun Tzu, The Art of War~500 BC"Art of War Sun Tzu five factors"
Customer DevelopmentSteve Blank, Four Steps to the Epiphany2005"Customer Development Steve Blank"
Lean Startup / smoke testsEric Ries, The Lean Startup2011"Lean Startup Eric Ries validated learning"
Value Proposition Canvas (VPC)Alex Osterwalder, Value Proposition Design2014"Value Proposition Canvas Osterwalder"
Working Backwards / PR/FAQAmazon; Colin Bryar & Bill Carr, Working Backwards2021"Amazon Working Backwards PR FAQ"
Jobs-To-Be-Done (JTBD)Christensen; Ulwick; Moesta, Demand-Side Sales 1012003+"Jobs To Be Done theory Christensen"
Crossing the Chasm / BeachheadGeoffrey Moore, Crossing the Chasm1991"Crossing the Chasm Geoffrey Moore beachhead"
Diffusion of InnovationsEverett Rogers1962"Diffusion of Innovations Everett Rogers"
Domain-Driven Design (DDD)Eric Evans, Domain-Driven Design2003"Domain Driven Design Eric Evans"
C4 ModelSimon Brown2011"C4 model Simon Brown architecture"
DORA MetricsForsgren, Humble, Kim, Accelerate2018"DORA metrics Accelerate book DevOps"
Feature TogglesMartin Fowler2010"Feature Toggles Martin Fowler"
概念作者/来源年份搜索关键词
五大因素（Ngũ Sự）孙武，《孙子兵法》~公元前500年"Art of War Sun Tzu five factors"
客户开发Steve Blank，《四步创业法》2005"Customer Development Steve Blank"
精益创业/烟雾测试Eric Ries，《精益创业》2011"Lean Startup Eric Ries validated learning"
价值主张画布（VPC）Alex Osterwalder，《价值主张设计》2014"Value Proposition Canvas Osterwalder"
逆向工作法/PR/FAQ亚马逊; Colin Bryar & Bill Carr，《逆向工作法》2021"Amazon Working Backwards PR FAQ"
Jobs-To-Be-Done（JTBD）Christensen; Ulwick; Moesta，《需求侧销售101》2003+"Jobs To Be Done theory Christensen"
跨越鸿沟/突破口Geoffrey Moore，《跨越鸿沟》1991"Crossing the Chasm Geoffrey Moore beachhead"
创新扩散理论Everett Rogers1962"Diffusion of Innovations Everett Rogers"
领域驱动设计（DDD）Eric Evans，《领域驱动设计》2003"Domain Driven Design Eric Evans"
C4模型Simon Brown2011"C4 model Simon Brown architecture"
DORA指标Forsgren, Humble, Kim，《加速》2018"DORA metrics Accelerate book DevOps"
功能开关Martin Fowler2010"Feature Toggles Martin Fowler"