评估模型 — 方法论与路径
Evaluation Model – Approach & Methodology
📊 数据分析方法
理论：Medallion三层架构
数据从14个系统接入后，经过三层处理：
- Bronze层（原始层）：按数据源分区存储原始数据，保留完整血缘。失败不影响其他源。
- Silver层（证据层）：将原始数据转换为"证据对象"（Evidence Object Model），统一Schema包含员工ID、维度标签、信号强度、证据文本、来源系统、时间戳、同意状态。
- Gold层（评分层）：基于证据聚合生成评分，支持按员工/维度/时间窗口快速查询。
理论：双轨映射
7个数据源同时支撑两条评分轨道：
- Track A（绩效评分）：D1-D5（全员）+ M1-M3（管理者），1-4分量化评分，进入校准流程。
- Track B（成长推论）：G1（修身）+ G2（齐家），不评分，仅用于个人发展，数据防火墙隔离。
理论：置信度加权
每个维度的分数附带"置信度"，反映数据可靠性。低置信度评分在Dashboard中标注"建议补充证据"。
落地：技术实现
- 基础设施：Azure Data Lake Storage Gen2 + Databricks，部署在新加坡区域。
- 连接器开发：每个系统独立开发连接器，定时调度（如BIPO每日凌晨、Profit.co每6小时）。
- 证据标记：Silver层自动将数据打上维度标签。例如：OKR完成率 → D1；360反馈提到"协作" → D3。
落地：执行计划
| 阶段 | 时间 | 交付物 | 负责人 |
|---|---|---|---|
| 连接器上线 | Sprint 1-2 | BIPO、Profit.co、SharePoint Bronze层 | Data Engineer |
| Silver层 | Sprint 3-4 | EOM Schema冻结 + 单元测试 | Data Engineer |
| Gold层 | Sprint 5-6 | 评分引擎 + 70人批量评分 | ML Engineer |
实例：员工张三的D1（交付成果）评分
📥 Bronze层：从Profit.co拉取OKR数据 → "Q2目标完成率90%，关键结果3/4达成"
🏷️ Silver层：自动标记 → 维度=D1，信号强度=强，来源=Profit.co，时间=2026-05-15
⭐ Gold层：D1评分=3分（Strong Impact），置信度=85%（证据充分且时效性高）
⚠️ 如果张三缺少OKR数据（如新员工），D1评分会标注"置信度45% — 数据不足，建议补充PCG表或1-1记录"
🤖 模型训练考量
理论：LLM分层模型选择
不同场景使用不同模型，平衡成本与性能：
- Claude Sonnet 4：实时交互场景（员工Dashboard问答），响应快、体验好，成本高。
- DeepSeek-V3：批量处理场景（证据提取、批量评分），成本低（约前者的1/8），延迟可接受。
- Claude Haiku：轻量任务（可解释性文本生成），成本最低。
理论：偏差与漂移监控
在Azure ML Registry中部署监控，确保AI输出质量：
- 输出质量评分：每批AI输出随机抽样10%人工标注，F1-score低于0.85触发告警。
- 维度漂移检测：监控各维度评分的均值/方差变化，超过2个标准差触发审查。
- 群体公平性：按部门/性别/职级分组，确保评分分布无系统性偏差。
落地：成本优化策略
- Prompt Caching：将系统提示和评估框架定义缓存30天，减少重复token消耗约35%。
- Batch API：证据提取和批量评分使用Batch API，延迟容忍24小时，成本降低50%。
- 预估节省：月度LLM成本从约$3,200降至约$1,400（基于235人全量+每日同步）。
落地：LLM降级机制（待客户确认）
- 触发条件：API错误率>5% 或 响应时间>10秒 或 成本超预算120%。
- 降级路径：Claude Sonnet → Claude Haiku → 本地规则引擎（关键词匹配）。
- 调用方：Azure API Management网关自动检测并路由，无需人工干预。
- 通知：降级事件自动发送到Teams channel + 邮件通知Tech Lead。
⚖️ 评分引擎初步方案
理论：4级量表设计
为什么选4级而非3级或5级？
- 3级太粗糙：所有人聚集在中间，无法区分。
- 5级有"舒适中间点"：管理者倾向于给3分（中等），逃避真正判断。
- 4级没有安全中间值：迫使管理者明确表态，分布更合理。
| 等级 | 标签 | 含义 | 建议分布 |
|---|---|---|---|
| 4 | Exceptional | 持续超越期望 | ~10-15% |
| 3 | Strong | 达到并经常超越 | ~40-45% |
| 2 | Steady | 持续达到期望 | ~35-40% |
| 1 | Below | 未达期望 | ~5-10% |
理论：权重分层
随着责任增长，权重从"个人交付"转向"赋能他人"：
| 支柱 | IC/AM | People Manager | Senior Leader |
|---|---|---|---|
| Performance (D1) | 40% | 25% | 20% |
| Process (D3+D4+D5) | 40% | 35% | 30% |
| People (D2+M1-M3) | 20% | 40% | 50% |
理论：两表分离
- Form A（评分表）：打1-4分，用于晋升、薪酬。员工+经理+HR+校准小组可见。
- Form B（成长表）：不评分，记录个人成长洞察。仅员工+经理可见。
- 数据防火墙：Form B内容永远不进入校准流程，技术上数据库层物理隔离。
落地：评分引擎技术实现
- 基础评分层：基于EOM证据的量化规则（如OKR完成率→D1分数映射），确保可审计。
- LLM增强层：对定性证据（360反馈文本、1-1记录）进行语义分析，提取维度信号。
- 校准层：支持管理者在UI中调整分数，所有调整记录审计日志。
落地：EVS聚合计算示例
People Manager (D1:3, D2:3, D3:3, D4:2, D5:3, M1:3, M2:2, M3:3):
Composite = (3×0.25) + (3×0.10) + (3×0.15) + (2×0.10) + (3×0.10) + (3×0.10) + (2×0.10) + (3×0.10) = 2.80 → Strong Impact (2.50-3.49)
落地：上下文调整机制
- 部分年度任期：按在岗月数/12比例加权（如6个月→权重0.5）。
- 角色转换：分段计算（旧角色贡献×旧权重 + 新角色贡献×新权重）。
- 审计要求：每次调整必须填写理由，自动通知校准小组，原始分数永久保留。
👥 70人Shortlist聚焦
理论：分阶段验证
不急于一次给235人全量打分。先选70人把整个评分流程跑通，发现问题及时调整，再扩展到全员。
落地：筛选标准
- Tier 1 (~40人)：Wave 1的35名高管 + 5名数据最完整的个人贡献者。
- Tier 2 (~20人)：各部门代表，确保7个部门均有覆盖，职级均匀分布。
- Tier 3 (~10人)：数据稀疏场景（如ES00009仅12个文件），测试系统在信息不足时的表现。
落地：执行计划
| Sprint | 时间 | 任务 | 交付物 |
|---|---|---|---|
| Sprint 5 | 7月中 | 70人数据清洗和EOM映射 | 清洗后的数据集 |
| Sprint 6 | 7月底 | 批量评分 + 置信度分析 | 评分报告 + 异常值清单 |
| Sprint 7 | 8月中 | 与客户联合评审 | 反馈清单 + 调整方案 |
Viva Insights — 限制与解决方案
Viva Insights – Limitations & Solutions
⚠️ 当前面临的限制
理论：Viva Insights是什么？
Microsoft 365的高级功能，提供协作行为数据：
- 协作小时数、跨团队会议次数
- 网络广度（独特协作者数）
- 非工作时间比率
这些数据是D3（协作）和M3（组织影响力）维度的主要信号源。
- 许可证依赖：需要M365 E5许可证，每个员工都需要 — 当前状态尚未确认
- API访问：Graph API协作分析端点在无E5许可证时不可用
- 时间窗口：Viva Insights属于Wave 4 (W18-W20)，需在W18之前获得批准
- 维度覆盖有限：主要贡献D3(强)、D2(中)、M3(中)，其他维度为弱信号
💡 潜在解决方案
理论：三层应对方案
按优先级排序，确保无论E5结果如何，D3维度都有可用信号：
方案A：推进E5许可证申请（推荐路径）
- 行动：请客户指定E5申请owner，供应商提供技术需求文档。
- 时间线：06-30前提交申请 → 07-15前获得初步反馈 → 07-31前完成采购。
- Fallback：如07-31前未获批，自动触发方案B。
方案B：替代数据源（并行准备）
| 替代源 | 覆盖维度 | 工作量 | 状态 |
|---|---|---|---|
| Fireflies.ai / Read.ai | D3(中), M3(弱) | ~3 SP | 原型就绪 |
| MS Teams Transcripts | D3(中), M2(中) | ~5 SP | 需Consent Dashboard |
| 360 Survey（现有） | D3(中), M1-M3(强) | ~0 SP | 已集成 |
| PCG Form + ePCG（现有） | D3(弱), D4(强) | ~0 SP | 已集成 |
方案C：降级处理
- D3维度标注"数据有限 — 基于有限信号推断"
- 自动下调D3权重20%，权重重新分配给D1/D4/D5
- Manager Dashboard推送提醒："D3评分置信度低，建议通过1-1补充证据"
实例：D3维度评分的三种情况
✅ 理想情况（E5获批）：Viva Insights提供"每周跨部门协作12小时、与15个不同同事合作" → D3评分=3分，置信度=90%
⚠️ 替代情况（E5未批，用Fireflies+360）：Fireflies显示"参与8次跨部门会议" + 360反馈"协作能力4/5分" → D3评分=3分，置信度=70%
❌ 降级情况（无行为数据）：仅PCG表提到"协作良好" → D3评分=2分，置信度=45%，Dashboard标注"数据不足"
- 决策1：E5许可证申请的owner是谁？供应商需要提供什么支持材料？
- 决策2：如E5未在07-31前获批，是否接受方案B（Fireflies.ai + 360 Survey替代）作为生产方案？
- 决策3：Consent Dashboard是否提前到Sprint 3启动？需要客户法务团队确认同意文本。
前端页面展示
Frontend Page Display
🎨 设计方案/原型讨论
理论：5个角色定制化Dashboard
不同角色看到完全不同的界面，信息层级和权限严格区分：
| 角色 | Dashboard | 核心功能 |
|---|---|---|
| Employee (P4) | Personal Cockpit | 3D Track A评分、EVS趋势、证据追溯、Track B G1+G2画像、成长目标设定 |
| Manager (P3) | Team View | 团队EVS分布、成员详情钻取、并排比较、校准支持工具、教练效能 |
| P&O (P2) | BU View | BU 3D热力图、组织模式洞察、CSV/PDF导出、审计追溯 |
| Executive (P1) | Strategic View | 全组织EVS分布、跨BU趋势、战略规划支持 |
| Admin | Console | 权重配置、数据源管理、模型版本管理、RBAC、LLM配置 |
落地：技术栈选型
- Next.js 14 + TypeScript + Tailwind CSS：SSR减少首屏加载，类型安全，快速对齐品牌设计。
- Recharts / D3.js：数据可视化（3D热力图、权重堆叠条形图、EVS趋势折线图）。
- React Query + Zustand：服务端状态管理 + 客户端全局状态，缓存策略优化API调用。
落地：开发优先级
| Sprint | 时间 | 交付物 | 优先级 |
|---|---|---|---|
| Sprint 7-8 | 8月 | Employee Dashboard (P4) | P0 |
| Sprint 8-9 | 8-9月 | Manager Dashboard + 校准工具 | P0 |
| Sprint 9-10 | 9-10月 | P&O Dashboard + Executive Dashboard | P1 |
| Sprint 10-11 | 10月 | Admin Console | P1 |
落地：UI/UX Mockups交付计划
- 06-08：Design System文档（色彩、字体、组件库）
- 06-12：Employee Dashboard高保真原型（Figma）
- 06-15：Manager Dashboard + 校准工具交互原型
- 需要客户在06-13前反馈Employee Dashboard原型，否则开发推迟到Sprint 7。
📈 数据/模型输出的前端呈现
理论：Track A可视化组件
- 维度评分卡片：每个维度一个卡片，显示1-4分评级 + 置信度进度条 + 证据数量。颜色编码：L4琥珀/#FFA30D, L3青色/#009CA8, L2灰蓝/#44546A, L1浅灰/#B3BBC6。
- EVS仪表盘：圆形仪表盘显示综合分数（1.0-4.0），外圈显示置信度百分比。
- 证据追溯面板：点击维度展开证据列表，每条证据显示来源系统、时间、信号强度，支持跳转到原始文档。
- SHAP贡献图：水平条形图显示各证据对评分的正负贡献。
落地：Track B可视化组件
- G1(修身) 雷达图：8 Living Habits作为8个维度，显示个人自评/经理评/AI推论对比。
- G2(齐家) 网络图：五伦关系可视化，节点大小=互动频率，连线粗细=关系强度。
- 成长目标面板：员工设定季度成长目标，系统推荐相关学习资源。
落地：校准工具交互设计
- 并排比较：选择2-4名员工，并排显示各维度评分卡片，差异用颜色高亮。
- 证据拉取：点击"查看证据"自动聚合选中员工的该维度所有证据，按时间排序。
- 校准批注：校准小组可在比较界面添加批注，批注自动关联到员工记录。
✨ 展示需求与用户体验
理论：非功能性要求
- 200并发用户，p95响应时间<3秒
- 99.9%核心服务可用性（2026-11-01至2027-01-15）
- 响应式设计：桌面/平板/手机三种断点
- SSE流式传输：AI对话和分析结果实时流式返回
落地：性能保障方案
- CDN缓存：静态资源通过Azure CDN分发，全球边缘节点缓存。
- API响应缓存：Redis缓存Gold层聚合数据，TTL=1小时（评分数据）/ 5分钟（实时数据）。
- 数据库优化：Gold层表按employee_id分区，常用查询建立复合索引。
- 负载测试：Sprint 10使用Azure Load Testing进行200并发压测，验证p95<3秒。
流程/沟通回顾
Process / Communication Retrospective
📢 团队需要更主动地清晰沟通问题
理论：当前Sprint进展
Sprint 1 (05-18 ~ 05-29)：6个并行流，18个故事，20 SP loaded，预计关闭10-12 SP。
关键外部依赖风险：
- Azure订阅 — 原定05-12到位，进行中
- MSC签署 — 原定05-15，进行中
- 多个API凭证 — 尚未收到
落地：供应商沟通改进措施
- 每日依赖检查：每个工作日上午9:00，Tech Lead检查关键依赖状态，逾期项立即升级到客户PM。
- 依赖看板：Confluence维护实时更新的依赖状态看板，客户可随时查看。
- 升级机制：逾期3天→邮件通知；逾期5天→会议讨论；逾期7天→正式风险报告。
📝 问题描述应包含完整信息
理论：标准化问题报告格式
所有技术问题按以下格式报告，确保信息完整：
- 背景：问题发生的上下文和环境
- 症状：具体错误信息、异常行为、影响范围
- 已尝试步骤：排查过程和结果
- 疑似根因：初步分析和判断
落地：问题报告模板
之前："BIPO API连不上" 😰
之后：
【P1-高】BIPO连接器同步失败
背景：Sprint 1部署BIPO Bronze层连接器时
症状：API返回401 Unauthorized，全部员工数据无法同步
影响：Bronze层缺少BIPO数据，影响后续Silver层转换
已尝试：检查OAuth2凭证有效期(到8月)，重新生成token，问题依旧
疑似根因：BIPO侧IP白名单未添加我们Azure服务器的IP
需要支持：请客户联系BIPO确认IP白名单配置 ✅
落地：沟通渠道规范
- 紧急技术问题 (P0-P1)：Teams即时消息 + 邮件，15分钟内响应
- 一般问题 (P2-P3)：Jira ticket + 每日站会同步，4小时内响应
- 需求变更/范围讨论：正式会议 + 会议纪要邮件，24小时内确认
- 进度汇报：每周五下午发送Sprint进度报告（燃尽图、完成故事、下周计划）
🔍 建议在Sprint回顾/评审中讨论
理论：待确认的Open Questions
| 问题 | 内容 | 截止日 | 状态 |
|---|---|---|---|
| Q1 | G1(修身)最终评分规则 — 8 Living Habits中哪些是P0 vs P1? | 06-30 | 待确认 |
| Q2 | G2(齐家)的五伦 vs Network Strength权重 | 06-30 | 待确认 |
| Q3 | 全部4个Dashboard的UI/UX设计确认 | 06-15 | 关键路径 |
| Q4 | 35人高级领导者试点名单及同意收集计划 | 08-15 | 待启动 |
| Q9 | LLM降级触发机制 — 谁来调用、何时调用、用什么标准 | — | 待确认 |
落地：Open Questions推进计划
- Q1 + Q2 (G1/G2评分规则)：06-10安排与OI方法论owner专项工作坊，06-12输出草案，06-30前锁定。
- Q3 (UI/UX设计)：06-08交付Design System，06-12交付Employee Dashboard原型，需要客户在06-13前反馈。
- Q4 (试点名单)：建议客户在06-15前提供初步名单，Sprint 5启动同意收集流程。
- Q9 (LLM降级)：今天提出方案（见议题1），客户确认后Sprint 2实施。
落地：Sprint Retrospective改进建议
从Sprint 2开始，每次Retrospective增加以下环节：
- 依赖回顾（5分钟）：回顾上Sprint承诺的依赖是否按时交付，分析逾期原因。
- 沟通效率评分（5分钟）：团队自评1-5分，讨论改进点。
- 知识分享（10分钟）：每个Sprint由一个团队成员分享技术/业务知识。