160 lines
5.5 KiB
Markdown
160 lines
5.5 KiB
Markdown
# TODO: 成果归属部门设计评审
|
||
|
||
## 1. 文档目的
|
||
|
||
本文件用于说明当前系统“成果归属部门（`assigned_departments`）”的实现现状、已暴露的业务问题，以及推荐的改造方向，供管理层评审后再确定最终实施方案。
|
||
|
||
当前阶段仅做方案评审，不进行数据库结构变更。
|
||
|
||
---
|
||
|
||
## 2. 现有设计（当前线上逻辑）
|
||
|
||
### 2.1 数据结构
|
||
|
||
- `achievements.assigned_departments`：`TEXT[]`，用于记录成果归属部门数组。
|
||
- `achievements.contributors`：`JSONB`，记录完成人列表（含 `name/phone/isMain/ranking/...`）。
|
||
- 统计与权限大量依赖 `assigned_departments`。
|
||
|
||
### 2.2 归属部门计算方式（新增/修改）
|
||
|
||
当前归属部门是这样算的：
|
||
|
||
1. 先确定主要完成人（`isMain=true`）。
|
||
2. 用主要完成人手机号去 `users` 反查其部门。
|
||
3. 将查到的部门去重后写入 `assigned_departments`。
|
||
|
||
这意味着：**成果归属只看“主要完成人”，不看其他参与完成人**。
|
||
|
||
### 2.3 “主要完成人”来源规则
|
||
|
||
- 论文：按角色自动推导（第一作者/通讯作者等）。
|
||
- 项目/成果转化：由前端勾选 `isMain`。
|
||
- 其他类型：按最小排名推导主要完成人。
|
||
|
||
### 2.4 领导部门字典的当前用途
|
||
|
||
- `dict_leader_departments` 当前主要用于“签批院领导”用户搜索过滤（如技术报告签批）。
|
||
- 它不直接参与 `assigned_departments` 的计算。
|
||
|
||
### 2.5 依赖场景
|
||
|
||
- 列表与可见范围过滤（如按部门可见）。
|
||
- 统计分析（按部门产出、趋势等）。
|
||
- 字典删除联动（部门删除时，成果归属中的对应部门会被替换为“待定”）。
|
||
|
||
---
|
||
|
||
## 3. 已出现的业务问题
|
||
|
||
### 问题 A：院领导主完成人导致归属失真
|
||
|
||
当业务上院领导必须/经常被标记为主要完成人时，归属部门会集中到“院领导部门”，导致：
|
||
|
||
- 业务承接部门贡献被淹没；
|
||
- 统计图偏向领导部门，失去决策价值；
|
||
- 跨部门协同成果无法准确反映。
|
||
|
||
### 问题 B：多部门参与信息丢失
|
||
|
||
一个成果可能有 3-4 个部门参与，但当前仅按主完成人计算，导致：
|
||
|
||
- `assigned_departments` 不完整；
|
||
- 基于部门的权限与统计存在系统性偏差。
|
||
|
||
### 问题 C：语义混杂
|
||
|
||
当前“归属部门”既被当作统计口径，也隐含承载了“牵头责任”含义，但这两个概念在业务上并不等价。
|
||
|
||
---
|
||
|
||
## 4. 推荐改造方案（不改库结构，优先）
|
||
|
||
## 4.1 目标
|
||
|
||
- 归属部门改为“参与部门口径”，提高统计与查询真实性。
|
||
- 保持当前表结构和现有 API 兼容，降低上线风险。
|
||
|
||
## 4.2 核心规则（推荐）
|
||
|
||
`assigned_departments` 改为按以下顺序计算：
|
||
|
||
1. 从 `contributors` 中取所有完成人手机号；
|
||
2. 反查这些用户所属部门并去重；
|
||
3. 排除无效值（空、null 等）；
|
||
4. 读取 `dict_leader_departments`：
|
||
- 默认将领导部门从归属集合剔除（防止“院领导部门吞噬”）；
|
||
5. 如果剔除后为空：
|
||
- 回退到提交人部门；
|
||
6. 若提交人部门也不可用：
|
||
- 回退为 `['待定']`。
|
||
|
||
> 说明：该方案不需要新增字段，直接替换归属计算逻辑即可。
|
||
|
||
## 4.3 同步改造点
|
||
|
||
- 新增成果时：使用新规则计算。
|
||
- 编辑成果时：使用同一套新规则重算。
|
||
- 封装公共函数 `computeAssignedDepartments(...)`，避免两处逻辑分叉。
|
||
|
||
## 4.4 历史数据处理（建议）
|
||
|
||
提供一次性回填脚本，重算历史成果 `assigned_departments`，否则新老口径并存会导致统计长期不一致。
|
||
|
||
建议执行流程：
|
||
|
||
1. 开发机全量跑脚本；
|
||
2. 抽样对比典型成果（院领导参与、多部门参与、单部门项目）；
|
||
3. 生产低峰执行；
|
||
4. 保留执行前快照，支持快速回滚。
|
||
|
||
---
|
||
|
||
## 5. 备选方案（供比较）
|
||
|
||
### 方案 B：保留“主完成人口径”，仅加领导部门排除
|
||
|
||
- 优点：改动最小。
|
||
- 缺点：多部门参与问题仍未解决，仍会有归属缺失。
|
||
- 结论：不推荐作为长期方案。
|
||
|
||
### 方案 C：双口径（归属部门 + 牵头部门）
|
||
|
||
- 优点：业务语义最清晰。
|
||
- 缺点：通常需要新增字段与更多改造（前后端、统计、权限口径梳理）。
|
||
- 结论：作为二期优化可评估；本期若要求“尽量不动数据库”，不优先。
|
||
|
||
---
|
||
|
||
## 6. 待管理决策项（请示时建议重点确认）
|
||
|
||
- 是否同意“归属部门 = 参与部门口径”？
|
||
- 是否同意默认剔除领导部门字典中的部门？
|
||
- 剔除后为空时，是否同意“提交人部门优先，最后回退待定”？
|
||
- 是否同意执行历史数据回填（推荐执行）？
|
||
- 统计报表是否继续沿用 `assigned_departments`（本期建议继续沿用）？
|
||
|
||
---
|
||
|
||
## 7. TODO 清单（待批准后执行）
|
||
|
||
- [ ] 确认最终业务口径（本文件第 6 节）
|
||
- [ ] 设计并评审 `computeAssignedDepartments` 规则细节
|
||
- [ ] 修改新增成果归属计算逻辑
|
||
- [ ] 修改编辑成果归属重算逻辑
|
||
- [ ] 增加回填脚本（仅更新 `assigned_departments`）
|
||
- [ ] 生成回填前后抽样对比报告
|
||
- [ ] 验证权限与统计页面关键场景
|
||
- [ ] 安排生产执行窗口与回滚预案
|
||
|
||
---
|
||
|
||
## 8. 风险与控制
|
||
|
||
- 风险：归属口径改变后，统计口径会发生可见变化。
|
||
- 控制：上线公告中明确“统计口径优化”；保留回填前快照用于追溯。
|
||
|
||
- 风险：部分历史成果完成人手机号与用户表不一致，可能回退到“待定”。
|
||
- 控制：先跑演练报告，输出异常清单再决定是否人工修正。
|
||
|