信息管理4.90 项目管理数据、信息与报告核心定义数据 → 信息 → 报告是项目管理中信息流转的三级台阶。原始数据经过分析变成信息信息汇总提炼变成报告。数据 信息 报告 │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │工作绩效数据│ ──→ │工作绩效信息│ ──→ │工作绩效报告│ │ WPD │ 分析 │ WPI │ 汇总 │ WPR │ └──────────┘ └──────────┘ └──────────┘ │ │ │ 处理 知道偏差了 做决策用三级对比维度工作绩效数据(WPD)工作绩效信息(WPI)工作绩效报告(WPR)是什么原始观察值和测量值将数据与计划对比后的分析结果汇总整理后的正式报告谁产出执行过程组(4.3等)各控制过程监控项目工作(4.5)谁看项目团队内部PM 和团队干系人、管理层、发起人频率高频每天/每周中频每阶段低频里程碑/按需例子「本周完成代码3000行」「比计划落后200行进度偏差6%」「Q2项目状态CPI0.9预计延期2周」数据分析三大方法一、偏差分析将实际绩效与基准/计划对比找出差距。偏差分析 │ ┌───────────────────┼───────────────────┐ ▼ ▼ ▼ 进度偏差 成本偏差 质量偏差 SV EV - PV CV EV - AC 缺陷率 vs 标准 「晚了几天」 「超支多少」 「合格吗」 判断标准 偏差在阈值内如±5% → 正常继续监控 偏差超过阈值 → 分析原因可能需要变更二、趋势分析用历史数据预测未来走向——看走向不只是看当下。完工日 │ │ ┌─ 当前状态落后2天 │ │ │ │ ●────── 趋势线 → 按当前趋势走下去将落后8天 │ │ ╱ │ │╱ │ ● │ ╱ │╱ └──────────────────────► 时间 趋势分析 不只是知道现在落后2天而是预测这样下去会落后8天三、备选方案分析对所有可选的纠正/预防方案进行对比评估选出最优方案。步骤内容①列出所有可用的纠正措施赶工快速跟进加人②评估每个方案的利弊、成本、风险③选出最优方案并提交变更请求数据流转全景4.3 指导与管理项目工作执行 │ └── 产出工作绩效数据(WPD) ── 原始数据 │ ▼ 各监控过程5.5确认范围/6.6控制进度/7.4控制成本/8.3控制质量... │ └── 产出工作绩效信息(WPI) ── 分析后的偏差和预测 │ ▼ 4.5 监控项目工作 │ └── 产出工作绩效报告(WPR) ── 给干系人的正式报告 │ ▼ 4.6 实施整体变更控制 ← 如果报告显示需要变更常见错误陷阱正解数据、信息、报告是一回事 ×数据→信息→报告三级递进越往后越精炼偏差分析只看进度 ×偏差分析覆盖进度/成本/质量等多维度趋势分析就是看一张折线图 ×核心是预测未来走向不是回顾历史备选方案分析拍脑袋选 ×是结构化对比列出→评估→决策4.91 Stacey 矩阵核心定义Stacey 矩阵用两个维度判断项目适合什么开发方式——需求明确度 × 技术确定度。技术不确定度 │ 高│ 混沌区 复杂区 │ (Anarchy) (Complex) │ 「什么都说不清」 │ 敏捷 │ 远非共识 │ ┌─────┐ │ │敏捷 │ │ │迭代 │ 中│ │增量 │ │ └─────┘ │ 复杂区 繁杂区 │ (Complex) (Complicated) │ 混合 预测 │ 低│ 简单区 简单区 │ (Simple) (Simple) │ 预测 预测 │ └──────────────────────────────────────► 需求不确定度 低 高 需求明确 需求模糊四象限对应方法论象限需求技术特征推荐方法例子简单区明确确定都知道怎么做预测型瀑布盖房子、标准化生产繁杂区部分模糊确定需求要澄清技术没问题混合型ERP系统上线复杂区模糊不确定需求和方案都需要探索敏捷/迭代/增量创新App、AI产品混沌区非常模糊非常不确定什么都说不清楚先做原型/试探颠覆性创新敏捷的适用雷达┌─────────────────────┐ │ 敏捷最适用 │ │ │ 需求模糊 ◄──────────────► 需求明确 复杂区 简单区 │ │ 技术不确定 ◄─────────► 技术确定 复杂区 简单区 │ │ 创新探索 ◄─────────────► 成熟方案 复杂区 简单区 └─────────────────────┘ 五个判断维度敏捷适用雷达 ├── 需求稳定性 → 不稳定/变化多 → 敏捷 ├── 技术不确定度 → 新技术/探索 → 敏捷 ├── 干系人参与度 → 需要频繁反馈 → 敏捷 ├── 团队自主性 → 自组织小团队 → 敏捷 └── 交付节奏 → 需要持续交付 → 敏捷四种方法的 Stacey 定位技术 不确定度 │ 高│ ● 敏捷 │ 最不确定 │ │ ● 迭代 ● 增量 │ 需求可控 逐步构建 │ 技术探索 技术稳定 │ 低│ ● 预测瀑布 │ 都确定 └────────────────────────────────────► 需求不确定度 低 高方法Stacey 位置核心特点何时用预测瀑布左下需求技术都确定标准化、重复性项目增量右下偏中技术确定需求分批功能可分批交付迭代左上偏中需求基本确定技术要探索方案不成熟要试错混合中间过渡区部分预测部分敏捷合规部分预测创新部分敏捷敏捷右上需求和方案都需探索创新、不确定性高常见错误陷阱正解敏捷适用所有项目 ×Stacey矩阵右上角才最适合敏捷左下角预测更好预测型落后 ×需求和技术明确的场景预测型效率最高Stacey只影响开发方式 ×还影响合同类型、风险策略、团队结构4.93 知识转移路径核心定义项目收尾阶段知识需要从项目团队转移到运营团队或组织。知识分为两类转移方式完全不同。知识 │ ┌────────────────┴────────────────┐ ▼ ▼ 显性知识 隐性知识 (Explicit) (Tacit) 「可以写下来的」 「说不清但会做」两条转移路径知识转移路径 │ ┌──────────────────┴──────────────────┐ ▼ ▼ 显性转移 隐性转移 (Explicit Transfer) (Tacit Transfer) │ │ 文档化、手册、 导师制、跟岗、 知识库归档、 结对工作、 培训课程录播 影子学习 │ │ ▼ ▼ 可复制、可检索 难以复制需人际传递 「看文档就能上手」 「跟师傅才能学会」显性 vs 隐性知识维度显性知识隐性知识是什么可以编码、写下来的知识经验、直觉、手感、know-how载体文档、手册、图纸、代码人脑、肌肉记忆、团队默契转移方式阅读、培训、检索跟岗、师徒、结对、模仿成本写文档成本高传播成本低培养成本高人跟人但内容流失快例子操作规程、设计文档、API手册怎么和难搞的客户沟通、哪个供应商靠谱转移策略对比显性转移隐性转移手段归档OPA、发布知识库、录制课程安排 overlap period、建立 mentor 制关键动作项目结束前强制提交文档运营团队提前介入、并行工作一段时间风险写了没人看、文档过时人走了知识就没了bus factor最佳实践模板化、结构化、可检索关键岗位必须有 backup/shadow考试关键点⚡核心认知收尾时只交文档 只做了显性转移。如果运营团队不知道怎么用那些文档说明隐性转移没做。收尾阶段的知识转移 checklist ├── 显性转移 │ ├── 技术文档、设计图纸归档完成 │ ├── 运维手册已更新并交接 │ ├── 经验教训登记册已提交 │ └── 最终报告已签收 │ └── 隐性转移 ├── 运营团队有人全程跟过项目吗 ├── 关键决策的为什么解释清楚了吗 ├── 干系人的隐性预期传递了吗 └── 过渡期内项目成员可被咨询吗陷阱正解知识转移交文档 ×文档只是显性部分隐性经验同样需要转移收尾工作最后才考虑转移 ×知识转移应在项目早期就规划逐步执行培训就能完成隐性转移 ×隐性知识需要实践和人际互动课堂培训不够