跳转至

PM-SE整合：MOSA实施的组织瓶颈

概述

MOSA实施需要两个学科深度协同：项目管理（PM）管合同和资源，系统工程（SE）管架构和设计。两者脱节是MOSA失败的组织根因——不是技术不行，是组织不会协调。

PM与SE：两个独立学科

维度 项目管理（PM） 系统工程（SE）
核心问题 "我们做得了吗？" "我们该做什么？"
关注点 资源、进度、成本、风险 需求、架构、设计、验证
工具 WBS、EVM、Gantt、合同 需求分析、架构设计、V&V
风险视角 商业/财务/进度风险 技术/接口/集成风险
成功标准 按时按预算交付 交付满足需求的系统

MOSA对PM和SE的双重要求

SE必须做的事

  • 模块化架构设计（高内聚低耦合）
  • 接口定义与开放标准选择
  • 一致性认证计划
  • 数字线程贯通

PM必须做的事

  • MOSA合同条款谈判（SOW/PWS/TEMP）
  • 数据权利条款（DFARS 252.227）
  • 多供应商协调（模块化=多承包商）
  • 架构投入的预算安排

脱节的后果

  • SE定义了接口，但合同没要求供应商遵循 → 接口规范形同虚设
  • PM签了合同，但没留数据权利 → 供应商锁定
  • SE选了开放标准，但PM没在合同中引用 → 标准无法执行
  • 架构投入被PM视为"不产生交付物的成本" → 被砍预算

MOSA五大支柱中的PM-SE整合点

支柱 SE职责 PM职责 整合失败模式
赋能环境 架构评审流程 组织文化变革 "技术上对但组织不用"
模块化设计 架构分解 WBS对齐架构 "设计好但工作包不匹配"
开放标准与接口 标准选择 合同引用标准 "选了标准但合同没写"
验证与评估 测试用例设计 TEMP编制 "能测但没计划测"
治理与可持续性 接口版本管理 供应商管理 "接口演化无人协调"

组织层面的解决方向

1. 交叉培训

PM需要理解"为什么接口定义要花钱"，SE需要理解"为什么合同不能随意改"。

2. SEP作为PM-SE桥梁

系统工程计划（SEP）既是技术文档也是项目计划的一部分。PEO Aviation的做法是把MOSA检查清单直接嵌入SEP。

3. 技术性能度量（TPM）

PM和SE共享的技术健康指标——让PM能看懂技术进展，SE能理解项目约束。

4. 联合里程碑评审

PM和SE共同审查技术成熟度+项目状态，避免"技术说能做、PM说没钱"的局面。

这个分析对知识库的意义

之前分析了速度vs模块化（政策张力）、五原则演化（技术→管理），但没有回答一个关键问题：谁来协调？ PM-SE整合就是这个"谁"——MOSA实施不是PM或SE单独能完成的，需要两者的组织融合。

这直接印证了五大支柱把"赋能环境"排第一的原因：不是因为组织管理比技术重要，而是因为没有组织协同，技术投入无法产生效果。

相关内容