8.1 KiB
8.1 KiB
交付部署组人力现状与建议汇报
汇报日期：2026年6月16日 汇报人：交付部署特战队
一、当前困境总览
1.1 交付部署特战队"正在扛住"的工作
目前团队 3人，正在尽力维持以下核心工作：
| 工作板块 | 具体内容 | 当前状态 |
|---|---|---|
| 项目交付部署（权重30%） | 外部项目的交付部署、版本升级 | ⚠️ 勉强维持，时效承诺压力大 |
| 项目生命周期维护（权重30%） | 持续交付、故障排查、维护变更 | ⚠️ 疲于应付，只能做到"灭火式"响应 |
| 研发环境维保（权重10%） | 研发环境故障修复、验收环境部署 | ⚠️ 基本维持 |
| 院内资源维护（权重10%） | 研发工具链迁移、服务器信创改造 | ⚠️ 被动配合 |
Warning
以上工作已经占据团队 100% 的时间。任何一项新增需求都会导致现有工作的延迟或质量下降。
1.2 目前"无力完成"的重要工作
以下是工作矩阵中明确要求、但当前团队确实无力推进的事项：
| 工作板块 | 具体内容 | 缺失原因 |
|---|---|---|
| 重点项目维保（权重10%） | 重大演示/汇报/验收的 SRE 保障 | 无专职人员，缺乏可观测体系建设能力 |
| 交付部署标准化 | 制定《部署说明书》、规范交付流程 | 无人力资源投入 |
| 信创国产标准化 | 中移凌云信创及基础架构改造 | 需要专项攻坚，当前无法抽人 |
| 视频流媒体标准化 | 视频流媒体模块的部署标准化 | 新增领域，无人有余力承接 |
| AI算法部署标准化 | GPU环境交付测试及标准化 | 无基础环境、无人有余力承接 |
| 项目安全维护（权重5%） | 基础组件漏洞修复、安全合规 | 耗时、无法标准化，无力承接 |
| 集成支撑中心培训 | 制定培训计划、定期培训 | 极大增加自身负担 |
Caution
标准化工作的停滞会形成恶性循环：越不做标准化 → 每次交付越依赖人工 → 人力越紧张 → 越没时间做标准化。这是当前最大的系统性风险。
二、未来面临的严峻挑战
2.1 平台数量激增带来的工作量爆发
当前 未来（可预见）
─────────────────────────────────────────────────────
老行业平台 老行业平台（持续维护）
新飞服平台 新飞服平台（持续维护）
新监管平台 新监管平台（持续维护）
视频流媒体模块 视频流媒体模块（持续维护）
AI算法部署（勉强承接） AI算法部署（常态化）
＋ 低空安防平台（新增）
＋ 数据底座（新增）
＋ 更多新平台...
Important
每新增一个平台，不仅意味着一次部署，更意味着该平台在其整个生命周期内的持续交付、版本升级、故障排查、安全合规等工作的永久性增加。工作量是只增不减的。
2.2 集成支撑中心的结构性问题
根据"应接尽接"原则，集成支撑中心将不参与我方项目交付。同时：
- 集成支撑中心无法脱手交付，强依赖我方指导
- 培训工作反而增加了我方的人力消耗
- 净效果：不仅没有减负，反而成为额外负担
2.3 研发侧交付物不规范的连锁影响
- 交付物形态不统一、配置不规范
- 交付测试支持不足，部署容易出问题
- 直接后果：每次交付都是"摸索式"作业，耗时成倍增长
三、人力结构现状与建议
3.1 当前人力缺口分析
| 项目 | 数据 |
|---|---|
| 研发团队总规模 | 监管平台45人 + 飞服平台24人 + 视频及算法17人 = 86人 |
| 行业标准配比 | 研发:交付 = 10:1（甚至更低） |
| 应有交付人员 | 9～12人 |
| 当前实际人员 | 6人 |
| 缺编人数 | 3～6人 |
3.2 人力补充建议
建议分 两个阶段 逐步补充人力：
第一阶段：紧急补充（建议增加 3人）
| 序号 | 岗位方向 | 核心职责 | 优先级 |
|---|---|---|---|
| 1 | 交付部署工程师 | 分担日常交付部署与持续交付工作，释放特战队精力 | 🔴 最高 |
| 2 | AI/GPU部署工程师 | 承接AI算法部署，建立GPU测试环境及标准化流程 | 🔴 最高 |
| 3 | SRE 工程师 | 建设可观测体系，承接重点项目维保，系统稳定性保障 | 🟡 高 |
第二阶段：能力完善（建议再增加 2～3人）
| 序号 | 岗位方向 | 核心职责 | 优先级 |
|---|---|---|---|
| 4 | 安全运维工程师 | 安全合规定制开发、漏洞修复，对接安全组需求 | 🟡 高 |
| 5 | 项目运维工程师 | 负责交付生命周期内的项目维保工作，处理项目中的交付和运维需求 | 🟢 中 |
Tip
第一阶段补充完成后，团队达到 9人，可以基本覆盖工作矩阵中的核心职能。第二阶段完成后达到 11～12人，可以实现标准化和能力建设的良性循环。
四、交付部署特战队与重资产交付的协同关系
4.1 两个小组的职能定位差异
| 维度 | 交付部署特战队 | 重资产交付（监管交付支撑） |
|---|---|---|
| 核心职能 | 软件平台的交付部署、持续交付、标准化建设 | 涉及硬件设备（监管设备、飞行器）的现场交付 |
| 工作特点 | 远程为主、标准化导向、多平台覆盖 | 现场为主、项目制、重资产交付 |
| 技术方向 | 云原生、K8s、中间件、CI/CD | 硬件集成、现场联调、设备部署 |
| 服务对象 | 所有软件平台（飞服、监管、视频、AI等） | 所有需要重资产交付的项目 |
4.2 协同建议
建议明确 "分工清晰、能力互补、资源共享" 的协同模式：
① 明确分工边界
- 特战队：负责所有平台的软件侧交付部署、持续交付、标准化建设、SRE保障
- 重资产交付：负责涉及硬件设备的项目现场交付、联调、设备部署
- 共同承担：重大项目的联合保障
② 建立能力互补机制
- 特战队向重资产交付团队输出部署标准化能力，降低重资产项目中软件部署的复杂度
- 重资产交付团队向特战队反馈现场交付经验，帮助优化交付流程
- 鼓励两组在不忙时进行交叉培训，培养"一专多能"型人才
③ 统一资源调配
- 在人力紧张时，由副组长（特战队队长与B）协商进行临时人力借调
- 建立共享工单池，按照技能标签匹配分配任务
- 重大项目采用联合作战模式，由两位副组长共同制定作战方案
五、总结与行动建议
| 优先级 | 建议事项 | 预期效果 |
|---|---|---|
| 🔴 紧急 | 优先补充 3 名核心岗位人员 | 覆盖基础交付+AI部署+SRE三个关键缺口 |
| 🔴 紧急 | 明确特战队与重资产交付的分工边界 | 消除内部协作模糊地带，提升效率 |
| 🟡 重要 | 推动研发侧交付物标准化 | 从源头降低交付复杂度，减少重复劳动 |
| 🟡 重要 | 建立集成支撑中心的自主交付能力 | 真正释放我方人力，而非增加培训负担 |
| 🟢 长期 | 完成第二阶段人员补充 | 实现团队满编，具备标准化和能力建设的条件 |
| 🟢 长期 | 建设可观测体系和自动化工具链 | 从"人工运维"向"工程化运维"转型 |
Important
核心观点：当前团队 6 人已处于超负荷运转状态，只能维持"灭火式"的基础交付。随着平台数量持续增加和新业务（AI算法、低空安防、数据底座等）即将上线，如果不在短期内完成人力补充和标准化建设，交付质量和响应时效将面临系统性崩溃的风险。建议尽快启动第一阶段的 3 人紧急补充。