接手这两类驾驶舱时，我已经是智慧建设平台的需求侧负责人。平台产品线按造价、质量、安全等业务分为多个部门，两类驾驶舱都需要整合这些部门的业务内容。
我负责驾驶舱的需求与项目推进，既承担一部分具体设计，也统筹各部门与业主的沟通，最终确定页面的展示内容和形式。
先分清两种驾驶舱
多项目管理驾驶舱面向业主单位，用于统筹多个工程项目，从整体情况逐步查看部门、项目的详细数据。项目驾驶舱以单个施工合同段为对象，围绕现场管理和项目汇报组织内容。
多项目管理：业主统筹全局
汇总业主单位所辖项目、投资、参建单位等信息，再进入专题分屏或具体项目。
业主总览 → 部门或专题 → 项目明细
项目汇报：围绕现场组织内容
以数字沙盘为基础，组合进度、安全、质量等看板，展示单个合同段的情况。
合同段 → 业务分屏 → 对应看板
多项目管理驾驶舱的投资需求就是一个例子：总览展示业主单位整体的投资与支付情况，进一步查看各部门和项目的数据。这样可以保留整体视角，也为具体问题留下继续查看的路径。
把看板拆成可复用单元
项目驾驶舱需要服务不同工地。如果每来一个项目就重新设计整屏，后续维护会越来越重；全部使用同一套内容，又无法容纳现场差异。
我将看板按通用、定制和位置调整三类组织，分别管理所属分屏、默认版本、使用状态、应用项目和研发进度。
共用内容进入通用看板
项目概况、进度产值、安全风险、质量验收等内容，按对应业务分屏组织，供不同项目使用。
现场特有内容保留定制
例如盾构机实时监控、特定项目的监测或检测信息，在相同展示框架内安排定制看板。
已上线与实际使用分别记录
看板发布后，我继续跟进具体项目是否启用，将上线进度与实际使用分开管理，找出仍未用起来的功能。
这让后续讨论有了具体对象：这次是新增一种通用能力，补充一个项目的特殊内容，还是只调整已有看板的位置。
不稳定的数据如何接入
部分汇报内容尚没有对应的业务模块，也没有稳定的数据来源。如果为每一项临时展示需求都开发完整模块，交付范围会不断扩大。
我的处理方式是先区分已有平台数据与额外补充的数据。对于暂时无法由业务模块提供的部分，采用模板导入，先满足展示需要，并为后续内容变化留出调整空间。
模板里的数据需要人工整理和更新。这种方式适合当时的交付条件；是否继续做成业务模块，需要结合后续使用再判断。
统筹跨部门需求与交付
我会带着各业务部门的产品经理与业主一起讨论，逐页明确需要展示什么。在共同讨论的基础上，由我统一确定具体的展示内容和形式，各部门的产品经理再据此编写、细化需求文档。
客户对第一版范围的意见并不总能及时确定，交付日期却已经排定。我先确定可以进入研发的内容，继续跟进尚未明确的部分，把各部门的工作安排到同一套交付计划中。
推进过程中，我协调 UI 设计、研发和测试的工作，明确下一步由谁处理、还缺什么。上线之后，还需要组织生产验证和数据导入，确认各部门提供的内容能在完整的驾驶舱中共同呈现。
在竞品对比中验证方案
项目推进过程中，另一家供应商带着驾驶舱方案进入了客户的比较范围。团队需要利用一个周末集中迭代，准备周一的现场方案对比。
时间有限，改动必须围绕真实的项目汇报需求展开。各产品部门分工优化业务板块，同时联系实际项目，反复核对汇报逻辑和展示重点，把项目的 BIM 管理应用呈现出来。
那次由我向客户主讲。我们展示的是已经上线、贴近实际项目汇报场景的版本，我负责讲清楚方案怎样支持具体业务、哪些内容能够用于现场汇报。最终，我们的方案在这次对比中胜出。
随后，我又配合客户领导完成正式汇报，由客户领导主讲、我操作系统。准备时，我们一起过流程，我逐页记下讲述内容与页面切换的对应关系，让系统的呈现跟上实际汇报的节奏。
上线之后继续迭代
上线后的项目驾驶舱以数字沙盘为基础，汇集平台各模块信息，展示单个施工合同段的数据。我继续跟进不同项目的使用情况，调整默认看板配置，处理具体使用问题，并推进新增分屏。
同属智慧建设平台的计量支付模块，更侧重把业务规则整理成可以执行的流程；驾驶舱这部分工作，则需要不断在展示需求、数据条件和交付范围之间做取舍。
