为什么目标总在执行中失真
目标失焦，本质是执行链路缺乏结构化建模。公司级目标、部门OKR、重点计划、责任任务、个人待办之间若仅靠文档/会议/口头传递，就无法形成可验证的上下文关联。
典型问题包括：
- KR未绑定具体计划，导致目标与执行脱钩；
- 计划未拆解为带负责人、时限、交付物的任务节点；
- 任务缺失目标溯源字段（如
target_id/kr_id），前端展示与后端存储均无上下文锚点。
结果就是：管理者依赖滞后周报做判断；一线员工无法在待办系统中看到'这个需求支撑哪个KR'。技术上，这暴露了业务模型中缺少目标-计划-任务三级外键关联与正向/反向下钻能力。
资源投在哪？需要一张可聚合、可切片的热力图
资源可见性差，根源在于数据分散且维度缺失。研发工时在Jira记录，市场活动在MarketCloud统计，客服响应在Zendesk沉淀------各系统ID不统一、时间粒度不一致、责任人归属逻辑不同。
真正有效的资源视图需支持三重聚合：
- 按目标维度：查询'为达成KR-2024-Q3-01累计投入多少人天'；
- 按计划维度：分析'A产品上线项目各阶段工时分布是否符合基线'；
- 按责任人维度：识别'张三当前并行承担5个计划，其中3个任务逾期率>30%'。
实现关键在于统一任务实体建模（含 plan_id, target_id, assignee_id, start_time, end_time, actual_hours），再通过OLAP引擎（如ClickHouse）或预聚合服务支撑多维实时切片。
谁在拖后腿？本质是协作过程未被结构化标记
'拖后腿'不是人的问题，而是协作信号未进入系统闭环。常见断点：
- 任务仅写'对接市场部'，但未定义主责人（
owner）、协同人（collaborator）、验收人（reviewer）； - 阻塞事件（如'采购未回函'）未转为带超时规则（
escalation_after: 48h）的子任务； - 客户投诉、会议纪要等外部信号未结构化提取为
type=incident/type=resolution的任务类型。
技术上，需扩展任务状态机：增加 blocked 状态及 block_reason, blocked_by, unblock_deadline 字段，并触发自动通知与升级流。只有将协作动态纳入统一任务图谱，才能从'模糊归因'走向'精准定位'。
构建可下钻的执行事实链：开发者可落地的三层设计
不新增管理动作，而是重构数据链路。核心是让每个判断都可穿透、可验证、可回溯：
- 目标地图 ：基于树形结构（
parent_id+depth）实现目标→KR→计划→任务→待办的全路径可视化；所有节点携带source_ref（如OKR系统ID、Jira Issue Key），支持正向展开与逆向溯源； - 资源热力图 ：以任务为原子单位，聚合
actual_hours、progress_rate、delay_count，通过前端ECharts或AntV G2按计划/人员/时间段动态渲染，后端提供/api/v1/resources?group_by=plan&filter=target_id=xxx接口； - 红黄绿健康度看板 ：非人工打分，而是由规则引擎实时计算：
health = CASE WHEN overdue_rate > 0.2 THEN 'red' WHEN blocked_rate > 0.1 THEN 'yellow' ELSE 'green' END，指标全部源自任务表实时快照。
所有视图共享同一套任务中心（Task Hub）作为事实源头，点击任一色块，直达对应SQL查询或API调试页------让管理决策回归数据本身。