维李设论

# 【工程管理】GNOC无线网络数智化运营大屏项目报告

# 一、项目概况

图片

图片

图片

图片

  • 项目名称： GNOC无线网络数智化运营大屏项目

  • 主要参与方：

    • 甲方（需求与使用方）： 集团网络部、高层管理层、无线网络优化室
    • 乙方（设计、研发与实施方）： 网络数智应用研发室

  • 项目工作及整体推进状况： 该项目旨在为集团新建的GNOC（Global Network Operations Center）全球网络运营中心打造一个面向无线网络的数字大屏。其核心使命是实时、直观、智能地呈现全域无线网络的健康状态、性能指标与突发事件，提升网络监控、故障响应和决策指挥的效率。

  • 主要工作包括：

    项目整体采用敏捷开发模式，历时约6个月，经历了为期1个月的需求洞察与原型设计、4个月的迭代开发与数据对接、以及1个月的UAT用户验收测试与上线稳定期。

    1. 与无线网络优化室及集团高层管理层深度沟通，梳理关键监控指标；
    2. 设计大屏视觉风格与交互逻辑；
    3. 对接其他系统数据源；
    4. 开发高性能可视化前端大屏；
    5. 实施部署与联调测试。

  • 项目完成情况： 项目成功上线，接入了超过15个核心数据源，对接三大核心系统。开发并交付了包含“网络覆盖”、“场景分析”、“高铁专网保障”、“用户体验”等8个核心可视化模块的大屏平台。

  • 项目成效及后续影响： 项目成效显著。GNOC值班人员得以从纷繁复杂的多套监控系统中解放出来，实现了“一屏感知全球”。平均故障发现时间（MTTD）缩短了约40%，因可视化定位使得平均故障解决时间（MTTR）降低了约25%。该大屏已成为集团高层参观、政府企事业单位等重要客户来访、客户信誉展示以及日常运营指挥的核心设施，显著提升了公司网络服务的专业形象。此外，该项目沉淀的实时数据管道和高性能可视化组件，为后续其他运维产品提供了可复用的技术资产。

# 二、项目角色

本人在项目中担任 研发负责人，全面负责技术方案的决策、团队分工、研发进度与产品质量。

  • 从事的工作：
    1. 技术架构与选型： 主导技术栈的选型与决策。最终采用以 Spring Cloud 框架编写高性能API服务，结合 Express 框架为前端提供接口聚合服务（Backend For Frontend），以 Vue + React 框架构建大屏页面，并配合ECharts 和 Three.js 的图形库，实现2D/3D可视化渲染能力。
    2. 团队组建与任务分解： 组建了一个包含前端、后端、数据和QA的10人跨职能敏捷团队。将项目拆解为“移网洞察分析专项”、“高铁专网保障专项”和“GNOC无线数智化网络”三个子系统，并分配至不同小组并行开发。
    3. 核心代码开发与Code Review： 亲自负责最核心的系统架构设计与核心代码编写，并坚持对团队所有重要代码进行Review，确保代码质量、性能规范和风格统一。
    4. 攻坚与风险管理： 主动承担技术难题的攻坚，如解决地图渲染性能与接口延时问题等。同时，持续识别技术风险（如数据缓存优化、第三方库性能瓶颈）并提前准备预案。
  • 完成情况： 本人领导团队按期完成了所有研发任务。系统上线后运行稳定，系统及地图下钻切换刷新延迟控制在3秒以内，达到了性能预期。在整个开发过程中，团队技术债务可控，代码质量保持了较高水平。

# 三、项目实施

  • 问题一：多系统集成融合的挑战。
    • 描述： 各业务子系统（移网洞察分析、高铁专网保障、GNOC无线数智化网络）提供的接口协议格式各异，开发文档缺失及相关项目负责人无法追溯，如何高效、稳定、低延迟地汇聚这些数据是首要技术挑战。
    • 应对： 我们设计了“适配器（Adapter）模式”的数据接入层。为每一类数据源开发一个独立的适配器，负责将数据归一化为内部标准格式后打入Kafka队列，最后写入统一的数据库。并且，通过现有系统反向追溯接口来源，查找已有代码仓库整理完善不同系统调用链路，并形成开发文档，为后续系统维护和扩展提供技术支持。
    • 效果： 效果极佳。虽然对现有系统反向追溯过程比较艰难，但好在通过与相关项目负责人的沟通与协调，成功整合了所需系统的接口调用链路，并完善了文档资产。
  • 问题二：需求的不确定性与“范围蔓延”。
    • 描述： 在原型演示后，集团领导和无线网络优化室的成员比较满意，不断提出各自的新思路和新想法，其给研发团队带来了很大压力，容易导致项目偏离主线且无限期延长。
    • 应对： 本人坚持“敏捷但要有范围”的原则。与产品经理紧密配合，建立了一个严格的需求管理流程：所有新需求必须录入Backlog（需求池），并在每个迭代开始前的规划会上进行优先级评估，只允许最高优先级且不超出当前迭代容量的需求进入开发；对于重要但不紧急的需求，明确安排到后续迭代。
    • 效果： 有效地管理了干系人的期望，保证了团队能够聚焦于当前最重要的任务，确保了项目核心功能的交付节奏。虽然偶尔会有争执，但建立了良好的协作规则。
  • 问题三：大屏性能优化。
    • 描述： 大屏需要长时间运行在4K甚至更高分辨率的屏幕上，渲染大量动态图表和地图元素，极易出现数据加载延迟、内存堆积、动画卡顿等问题，影响用户体验和演示效果。
    • 应对： 我们将此作为专项技术攻关。采取了包括：
      1. 使用LOD（Level of Detail）进行网格简化，实现局部加载渲染；
      2. 对实例进行池化管理，避免频繁创建销毁；
      3. 防抖节流控制数据更新频率；
      4. 使用WebWorker处理繁重的数据计算；
      5. 使用CDN缓存、反向代理缓存等分离动静态资源，减少网络延迟；
      6. 使用Redis、Caffeine等缓存静态数据，减少重复请求；
      7. 建立监控机制，收集日志进行性能及问题分析。
    • 效果： 经过多轮优化，GNOC无线网络数智化运营大屏可稳定连续运行72小时以上无显著性能衰减，达到了工业级交付标准。

# 四、项目管理

在本项目中，最重要的管理工作是范围管理和成本管理，理由如下：

1. 范围管理：

  • 实践： 我们首先通过与所有关键干系人（集团领导及无线网络优化室同事）的多次研讨会，输出了详尽的《需求规格说明书》和《功能清单》，并获得了各方签字确认，以此作为范围基线。在开发阶段，我们使用产品待办列表（Product Backlog） 管理需求，并通过迭代规划会严格控制每个冲刺（Sprint）的范围。
  • 反思： 尽管有严格的控制，但在后期仍面临来自高层的“锦上添花”式需求。我们的应对策略是建立变更控制委员会（CCB），由产品经理、我（研发负责人）、外协团队负责人和处室领导共同评估所有范围变更请求，分析其对工期和成本的影响，再决定是否纳入当前版本或后续迭代。这有效地避免了范围蔓延。

2. 成本管理：

  • 实践： 成本主要为人力成本。我们根据工时估算制定了预算，并使用了挣值管理（EVM） 的简化版进行监控，持续记录人员及工时变化，定期计算成本绩效指数（CPI） 和进度绩效指数（SPI），以确保项目在成本和进度上均受控。
  • 反思： 项目中期，因引入一项未预料到的第三方地图服务以提升视觉效果，导致小幅超支。我们通过储备分析，动用了应急储备金，并由于前期良好的CPI表现，最终总成本仍控制在预算范围内。此事启示我们，应在预算中为“技术提升”预留更灵活的储备。

除此之外，整个项目管理过程中也涉及到其他管理过程，包括：

3. 时间与进度管理：

  • 实践： 基于WBS（工作分解结构），我们制定了详细的项目进度计划，明确了关键路径（CPM），其中数据接口对接与稳定性调试被识别为关键路径上的核心任务。我们使用甘特图跟踪进度，并通过每日站会同步开发进度，每周向指导委员会（处室领导）汇报整体状况。
  • 反思： 风险在于，关键路径上的任务依赖外部团队（其他系统提供方）。我们采取了前置沟通和并行工作的策略。在对方开发接口的同时，我们模拟了接口数据格式进行开发，一旦真实接口就绪，只需简单切换和联调，节省了大量等待时间。

4. 质量管理：

  • 实践： 我们确立了明确的质量目标：

为实现此目标，我们构建了多层质量防线：

- **Web前端指标**：
    1. LCP（最大内容渲染）：最大内容渲染时间不高于3s；
    2. CLS（累计布局偏移）：累计布局偏移不高于0.1；
    3. OnLoad事件：OnLoad事件不高于2s；
    4. 完全载入：完全载入时间不高于3s
- **系统性能指标**：
    1. 响应时间：系统响应时间不高于2s；
    2. QPS：单位时间处理请求数不高于100；
    3. 并发连接数：同时建立的与接口的连接数不高于50；
    4. CPU资源利用率：CPU资源利用率不高于80%；
    5. 内存资源利用率：内存资源利用率不高于80%；
    6. 错误率：处理请求时发生错误的比例小于1%
- **过程质量：** 强制代码规范、Code Review、单元测试覆盖率要求。
- **产品质量：** 专职QA团队进行功能、性能、压力、兼容性测试。
- **质量度量：** 通过CI/CD流水线自动化收集代码质量、测试覆盖率等指标。
  • 反思： 对“用户体验质量”的量化度量不足。后期我们补充了可用性测试（Usability Test），邀请不同用户操作并反馈，才发现了若干UI及交互设计上的缺陷。未来应在质量计划中尽早纳入UAT标准和用户满意度指标。

5. 风险管理：

  • 实践： 在项目启动阶段，我们就组织了头脑风暴会议，识别了包括“关键数据接口延迟”、“大屏性能瓶颈”、“干系人需求冲突”等在内的多项风险，并记录了在风险登记册中。对每个风险进行了概率/影响分析，并制定了应对策略（缓解、转移、接受）。
  • 反思： 我们成功缓解了大部分技术风险。但低估了一个干系人风险：无线网络优化室团队认为新大屏并不具备生产环境所需功能，表现出抵触情绪。我们未能第一时间识别此风险。后续通过对其关心的区域指标突出显示等沟通策略，才将其转化为支持者。这启示我，干系人风险需要持续识别和管理，其重要性不亚于技术风险。

6. 干系人管理：

  • 实践： 我们绘制了干系人权力/利益矩阵，将公司高层和无线网络优化室及GNOC运维人员列为“重点管理”对象，保持了高频、透明的沟通（如定制化的演示报告）。将GNOC值班人员列为“保持满意”对象，通过定期培训和工作坊收集其反馈。
  • 反思： 管理成效显著，获得了高层的持续支持。但启示是，对于“消极抵制”的干系人，应更早地将其识别出来，并制定专门的参与计划，而不是等问题出现后再去解决。

# 五、项目评价

本人认为本项目是非常成功的。

判断依据：

  1. 核心价值超预期交付： 它不仅实现了“数智化运营”的初始目标，更通过系统融合和智能分析，成为了运维团队的“决策辅助大脑”，显著提升了运营效率（MTTD/MTTR的降低是最硬性的证明）。
  2. 用户满意度极高： 从集团领导到无线网络优化室及GNOC运维人员，所有关键用户都对该平台给予了高度评价，它成为了日常工作不可或缺的一部分。
  3. 技术成果具有延展性： 项目所构建的大屏工程模板和高性能可视化组件库，形成了公司内的技术资产，为后续项目节省了大量成本。

从工程管理视角看，本项目成功的最关键因素在于采用了“刚柔并济”的管理模式：

  • “刚”性层面： 坚守了范围基线和成本底线。通过严格的范围变更流程和成本控制标准，确保了项目交付物核心价值的可靠性和确定性。
  • “柔”性层面： 发挥了敏捷方法的灵活性以应对变化。通过短迭代、持续交付和频繁的用户反馈，及时调整开发细节，满足了干系人未被明说的期望（Implicit Requirements），提升了最终产品的适用性和满意度。

这种结合，既保证了项目不失控，又赋予了项目适应变化的活力。

# 六、项目总结

本项目无疑是一次成功的技术工程管理实践，其不仅交付了一个技术平台，更为公司沉淀了宝贵的组织过程资产，包括：

  1. 一套经过验证的大屏项目开发流程与规范
  2. 一个可复用的实时数据可视化技术组件库
  3. 一份详实的风险登记册与研发文档知识库

从管理角度，最大的启示是：技术项目的管理，本质上是预测、规划、沟通和适应的综合体。 完美的计划不存在，但一个强大的、可适应的管理框架，结合一个高度自律且反应迅速的团队，是应对不确定性、最终走向成功的根本保障。

# 七、项目展望

本项目在规划、实施和监控过程中，仍存在诸多不足，如果在后续项目中再次遇到类似情况，我将会做如下改进：

  1. 及时识别并评估风险，避免项目风险扩大。
  2. 在项目启动前，进行充分的需求分析和风险评估，以确保项目的成功交付。
  3. 在项目启动前，与相关干系人（包括集团领导、无线网络优化室需求方、外部供应商团队等）充分沟通，确保项目需求的准确理解和项目管理的透明性。

除此之外，在整个技术团队管理方面，我也会：

  1. 更早引入专职 DevOps/ SRE 角色： 项目初期更侧重于开发，对部署、监控、CI/CD流水线的建设投入不足，导致后期补课。如果重来，我会在项目启动时就引入该角色，实现开发与运维的无缝衔接。
  2. 建立更完善的数据治理规范及文档建设： 当时为了追求速度，对数据的Schema管理、生命周期管理略显粗糙。重来我会在数据接入层就推行更严格的Schema Registry方案，为数据的长期质量打下更好基础，并对研发文档进行更好的管理和维护。
  3. 投入更多资源进行“用户体验”走查： 虽然功能强大，但在一些交互细节上（如：告警信息过长如何滚动、颜色对比度在不同光照环境下是否清晰）可以做得更人性化。重来我会组织更多轮的可用性测试（Usability Test），邀请不同用户在实际环境中操作，收集更细微的反馈。

【工程管理】Windows操作系统工程管理案例分析：超大规模软件工程管理的应对与挑战 →