项目状态

华为铁三角模式与 Git 远程异步协作

在 IoT 项目团队中，组织架构决定了”谁负责什么”，而协作工具决定了”团队如何一起干”。本节将华为铁三角模式引入 ESP32 项目团队，并结合 Git 工具，讲解如何让分布在不同地点、不同时间节奏的成员实现高效协同。

华为铁三角模式在 IoT 项目中的应用

什么是铁三角？

华为铁三角（Iron Triangle）是华为在长期大客户经营中总结出的客户界面组织模式，由三个核心角色组成：

角色	英文缩写	核心职责	在 IoT 项目中的对应
客户经理（Account Responsibility）	AR	客户关系、商务谈判、合同签署	售前工程师：客户沟通、需求收集、合同与报价
解决方案经理（Solution Responsibility）	SR	技术方案设计、产品适配、竞争力构建	技术负责人：ESP32 方案设计、BOM 评估、技术选型
交付经理（Fulfillment Responsibility）	FR	项目交付、质量保障、客户满意度	项目经理 / 测试负责人：开发进度跟踪、测试验收、上线部署

铁三角的运作原则

铁三角并非简单的”三个人分工”，而是一套完整的协同机制：

共同目标：三个角色对客户满意度共同负责，而非各管一段
前端驱动：AR（售前）作为客户界面的一线触点，驱动 SR 和 FR 响应
后端支撑：SR（技术）和 FR（交付）为 AR 提供专业弹药，支撑客户决策
授权前移：将决策权下放给一线铁三角团队，减少层层审批

IoT 项目铁三角实战示例

以一个工厂能耗监测项目为例：

客户（工厂厂长）
    ↓ 需求："想实时监测每条产线的用电量"
    ↓
[AR 售前工程师]
    → 与客户沟通，记录核心需求
    → 输出：需求文档（business/requirements/v1-energy-monitoring.md）
    → 触发 SR 评估方案
    ↓
[SR 技术负责人]
    → 设计 ESP32 + 电流互感器方案
    → 输出 BOM 清单、开发周期评估
    → 触发 FR 评估交付风险
    ↓
[FR 项目经理 / 测试]
    → 评估测试资源、交付时间表
    → 输出交付计划（business/delivery/energy-monitoring-plan.md）
    ↓
[铁三角联合评审 → 委员会立项]
    → 三方共同向委员会汇报
    → 立项通过后进入开发阶段

通过 Git 工具进行远程异步协作

为什么 IoT 团队需要异步协作？

IoT 项目团队通常面临以下挑战：

地理分散：售前在客户现场，技术在办公室或实验室，测试可能在工厂
时间错位：硬件调试周期长，软件开发节奏快，商务谈判有独立时间线
专业壁垒： firmware 工程师和售前工程师不需要实时同步，但需要信息对齐

Git 天然支持异步协作——每个人在自己的时间节奏上工作，通过 commit 和 PR 实现信息同步。

铁三角角色的 Git 协作模型

[AR 售前]                [SR 技术]                [FR 交付/测试]
    |                        |                          |
    |  在 business/ 提交     |                          |
    |  需求文档              |                          |
    |  git push              |                          |
    |                        |                          |
    |  ← PR 通知 →          |                          |
    |                        | 在 firmware/ 创建        |
    |                        | feature 分支开发         |
    |                        | git push                 |
    |                        |                          |
    |                        | ← PR 通知 →             |
    |                        |                          | 在 test/ 编写
    |                        |                          | 集成测试脚本
    |                        |                          | git push
    |                        |                          |
    |                        |       ← CI 自动触发 →    |
    |                        |                          |
    └──── 三方可随时 git log / git diff 查看进展 ───────┘

异步协作的核心 Git 操作

AR（售前）——在客户现场更新需求

售前工程师在客户现场沟通后，可以直接在本地更新需求文档，无需等待技术团队在线：

# 1. 切换到 business 子仓库
cd iot-project/business

# 2. 拉取最新内容（避免冲突）
git pull origin main

# 3. 创建本次需求更新的分支
git checkout -b docs/energy-monitoring-v2-requirements

# 4. 编辑需求文档（可以用任何编辑器）
# 修改 requirements/energy-monitoring-v2.md

# 5. 提交变更，写清楚变更原因
git add requirements/energy-monitoring-v2.md
git commit -m "docs: 根据客户二期沟通更新能耗监测需求，新增分项统计功能"

# 6. 推送到远程，发起 PR
git push origin docs/energy-monitoring-v2-requirements

PR 发起后，SR（技术）和 FR（交付）会在自己方便时查看，无需实时会议。

SR（技术）——异步响应技术方案

技术负责人收到 PR 通知后，可以在自己的时间评估方案：

# 1. 在 firmware 子仓库切出新分支
cd iot-project/firmware
git checkout -b feature/energy-sub-metering

# 2. 开发完成后，在 PR 描述中关联需求文档
# PR 描述示例：
# "基于 business/requirements/energy-monitoring-v2.md 新增分项计量功能
#  - 新增 ADC 多通道采样
#  - MQTT 上报分项电量数据
#  - 关联需求：REQ-EM-002"

# 3. 推送并创建 PR
git push origin feature/energy-sub-metering

FR（交付/测试）——独立编写测试计划

交付经理可以在技术方案开发的同时，并行准备测试方案：

# 1. 在 test 子仓库创建分支
cd iot-project/test
git checkout -b test/energy-monitoring-integration

# 2. 编写测试脚本
# test_energy_sub_metering.py

# 3. 提交
git add test_energy_sub_metering.py
git commit -m "test: 新增分项计量集成测试，覆盖 ADC 采样与 MQTT 上报"
git push origin test/energy-monitoring-integration

解决异步协作中的信息对齐问题

问题：三方都在各自工作，如何确保信息不同步？

Git 提供了多种机制解决这一问题：

1. PR Review 强制跨角色可见

在 GitHub / GitLab 中配置 PR Reviewer 规则：

子仓库	默认 Reviewer	目的
`business/`	SR（技术负责人）	技术侧知晓需求变更
`firmware/`	FR（交付/测试）	交付侧知晓功能实现
`test/`	SR（技术负责人）	技术侧知晓测试覆盖范围
`hardware/`	FR（交付/测试）	交付侧知晓硬件变更

2. 主仓库 README 作为项目状态看板

每次铁三角有重要进展，更新主仓库 README 的项目状态：

## 项目状态

| 维度 | 当前状态 | 负责人 | 最后更新 |
|------|---------|-------|---------|
| 需求 | v2 需求文档已评审通过 | AR-张三 | 2026-06-10 |
| 技术 | firmware 分项计量功能开发中 | SR-李四 | 2026-06-11 |
| 交付 | 集成测试脚本编写中 | FR-王五 | 2026-06-11 |

3. git log 作为异步沟通的”时间线”

每个角色上班时，第一件事是拉取最新代码查看变更历史：

# 查看主仓库及各子仓库最近的变更
git log --oneline -10
cd firmware && git log --oneline -5 && cd ..
cd business && git log --oneline -5 && cd ..
cd test && git log --oneline -5 && cd ..

这个简单的习惯，相当于每天自动同步一次全团队的工作进展，无需开会。

远程协作中的分支策略

铁三角三个角色的工作节奏不同，分支策略需要匹配这种异步性：

main（稳定主线）
  │
  ├── docs/需求更新      ← AR 售前：随时可以发起
  ├── feature/功能开发    ← SR 技术：按 Sprint 节奏
  ├── test/测试脚本       ← FR 交付：与 feature 并行
  └── fix/紧急修复        ← 任何人：随时可以发起

关键规则：

main 分支始终代表”已确认的项目状态”
所有变更通过分支 + PR 进入 main，保留完整审核记录
不同角色的分支互不干扰，可并行推进

异步协作中的冲突处理

问题：如果 AR 和 SR 同时修改了相关文档，会不会冲突？

Git 的分支 + PR 机制天然处理这个问题：

# 场景：AR 更新了需求文档，SR 同时在技术方案中引用了旧版需求

# 1. AR 的 PR 先合并到 main
# 2. SR 在合并前需要 rebase 或 merge main 到自己的分支
git checkout feature/energy-sub-metering
git merge main
# 如果有冲突，Git 会提示具体冲突位置

# 3. 解决冲突后提交
git add .
git commit -m "merge: 合并 main 最新需求文档变更"
git push origin feature/energy-sub-metering

PR 系统会在合并前自动检测冲突，确保不会出现”静默覆盖”。

铁三角 + Git 协作的完整工作流

以下是从需求收集到项目交付的完整异步协作流程：

阶段 1：需求收集（AR 主导）
    AR → business/ 提交需求文档 PR
    SR → Review PR，了解需求
    FR → Review PR，评估交付可行性

阶段 2：方案设计（SR 主导）
    SR → firmware/ 和 hardware/ 创建 feature 分支
    AR → Review 技术方案 PR，确认是否满足客户需求
    FR → Review 技术方案 PR，评估测试难度

阶段 3：开发实现（SR + FR 并行）
    SR → firmware/ 功能开发
    FR → test/ 编写测试脚本（与开发并行）
    AR → business/ 更新客户沟通记录

阶段 4：测试验收（FR 主导）
    FR → 运行集成测试，输出测试报告
    SR → 修复测试中发现的问题
    AR → 准备客户验收文档

阶段 5：交付上线（铁三角联合）
    FR → 更新主仓库 README 交付状态
    SR → 合并所有 feature 分支到 main
    AR → 向客户提交交付报告

实践建议

铁三角落地常遇到的问题：

问题：团队只有 3-5 人，能跑铁三角吗？ 可以。小团队中一人可以兼任多个角色，关键是职责边界清晰，而非人数对等。例如技术负责人同时兼任 FR，但 Git 提交时仍需分开记录，保证信息可追溯。
问题：Git 对商务同事门槛太高？ 商务同事只需掌握 pull → 编辑 → add → commit → push 五个命令。复杂的分支策略和 PR 流程可以由技术同事协助设置，商务同事只需在 business/ 子仓库中简单操作。
问题：如何避免 Git 仓库变成”文件垃圾场”？ 约定目录结构规范：需求文档放 requirements/、沟通记录放 communications/、合同放 contracts/。每次提交必须写有意义的 commit message，便于后续检索。

下一步：在理解了铁三角组织模式与 Git 异步协作机制之后，下一节将介绍售前工程师如何在 business/ 子仓库中使用模板高效收集客户需求。

正在开发商业 IoT 产品？

我们提供 ESP32 ODM 定制设计与制造服务。从原型到量产——编写这套教程的团队，可以和你一起实现。

联系我们 →