Microservice/cn-rdms
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f8231c2d514d40657233a8d9394766226b558f83
cn-rdms/rdms-project/rdms-project-boot/product/02-产品管理_业务设计.md

1058 lines
47 KiB
Markdown
Raw Normal View History

feat(other): 产品基础功能提交
2026-04-18 14:19:45 +08:00
# 02-产品管理 详细设计
## 0. 文档定位
| 项目 | 内容 |
|---|---|
| 文档目标 | 将《设计任务书》7.2 产品管理章节展开为开发、测试、接口、数据库可直接承接的详细设计 |
| 适用版本 | V0.5 |
| 设计范围 | 产品主数据、产品团队、产品与项目关系、产品生命周期、轻量需求管理 |
| 非本期范围 | 产品版本、路线图、评审流、基线、产品文档与附件、工单反馈管理 |
| 上游来源 | `04-设计阶段/设计任务书/设计任务书_V1.0.md`、`02-产品规划阶段/产品需求文档PRD_V1.0.md`、`02-产品规划阶段/术语与边界对齐_产品-项目集-项目.md`、`04-设计阶段/权限设计/权限设计方案.md` |
| 下游约束对象 | `04-设计阶段/数据库设计文档.md`、`04-设计阶段/API接口设计文档.md`、`04-设计阶段/业务设计/03-项目管理_业务设计.md`、`04-设计阶段/权限设计/` |
| 设计原则 | 先固化稳定归属和最小闭环，再扩展增强能力；产品层不承载任务、工时、周报等执行主数据 |
本文档回答 6 个问题：
- V0.5 产品管理到底做哪些页面、动作和字段。
- 产品、项目、产品团队、产品需求之间怎么关联。
- 每个动作的前置条件、校验规则、状态流转和审计要求是什么。
- 产品可见范围、建项目资格、产品团队成员池之间如何衔接。
- 产品需求如何与项目需求分流，不互相替代。
- 数据库、接口、权限、测试应按什么口径承接。
## 1. 设计目标与范围
### 1.1 模块目标
- 建立稳定的产品主数据管理能力，作为项目归属的上层业务对象。
- 形成“产品 -> 项目 -> 执行/任务 -> 工时/周报/统计”的稳定主链路。
- 为产品侧长期协作提供独立于项目团队的产品团队机制。
- 为通用需求沉淀提供轻量需求池，不把定制交付需求混入产品侧。
### 1.2 V0.5 包含范围
- 产品创建、编辑、查看、列表查询。
- 产品经理维护与产品团队管理。
- 产品启用、暂停、归档、废弃、逻辑删除。
- 项目创建时强制选择所属产品。
- 在当前产品上下文中查看关联项目。
- 产品轻量需求的录入、编辑、查询、基础状态流转、关闭。
- 产品研发令号按产品年度维护的数据结构预留。
- 产品需求在 V0.5 仅承接轻量需求池管理；是否进入 `待评审` 由业务判断决定，但不引入正式审批流、工作流引擎和复杂评审编排。
### 1.3 V0.5 不包含范围
- 产品版本管理。
- 产品路线图。
- 基于工作流引擎的正式产品评审流、审批流。
- 复杂产品需求增强管理，包括多级评审编排、会签/或签、退回重提等流程能力。
- 产品研发令号独立管理界面。
- 产品基线。
- 产品文档与附件管理。
- 工单/反馈与产品需求自动联动。
- 产品维度统计看板。
### 1.4 当前设计口径
- 产品管理当前不设置产品模板或产品类型正式字段。
- 产品方向为正式字段，统一通过系统字典承接；字典类型编码统一为 `rdms_product_direction`，业务表字段 `direction_code` 存字典 `value`，初始值为 `embedded`、`power_electronics`、`system_group`。
- 产品需求支持按业务判断进入 `待评审` 状态；当前版本仅表达业务评审待处理语义，不展开正式评审流程、工作流引擎和复杂评审编排。
## 2. 上下游约束
### 2.1 术语约束
- 产品（Product）是持续交付和维护的业务对象，生命周期长。
- 项目（Project）是围绕某次明确交付目标建立的执行单元，生命周期短于产品。
- 项目集（ProjectSet）是多个项目的统筹容器，不直接承载任务。
- 任务（Task）必须归属项目，不直接归属产品。
### 2.2 对项目管理的约束
- 项目创建时必须选择所属产品。
- 项目创建后不允许改挂产品。
- 项目负责人和项目成员必须先属于所属产品的产品团队，才能被选入项目团队。
- 当前产品上下文中的关联项目列表必须按项目权限二次过滤。
### 2.3 对权限模型的约束
- 产品团队权限和项目团队权限分离。
- 产品可见不等于可编辑，不等于可在该产品下建项目。
- 高风险动作和普通协作动作分离控制。
- 删除、归档、暂停、恢复、废弃都需要独立动作权限和审计留痕。
## 3. 功能架构
### 3.1 功能拆分
| 一级能力 | 二级能力 | V0.5 是否落地 | 说明 |
|---|---|---|---|
| 产品主数据 | 创建、编辑、查看、查询 | 是 | 主数据最小闭环 |
| 产品团队 | 产品经理、产品成员、产品观察者管理 | 是 | 同时承接项目团队来源池 |
| 产品生命周期 | 启用、暂停、归档、废弃、逻辑删除 | 是 | 删除为高风险动作 |
| 产品与项目关系 | 项目创建时选择产品，产品侧查看关联项目 | 是 | 关系由项目模块维护 |
| 产品需求 | 轻量需求池、基础状态流转、分流到项目 | 是 | 只承接通用需求 |
| 产品版本 | 版本主数据、版本状态、目标版本 | 否 | 当前不包含 |
| 产品路线图 | 时间线、版本计划 | 否 | 当前不包含 |
### 3.2 页面信息架构
```text
产品管理
├── 未选中产品时
│ └── 产品对象入口页
│ ├── 产品分组/分类
│ ├── 产品列表
│ └── 新建产品弹窗
└── 已选中产品时
├── 当前产品概览
├── 产品需求
│ ├── 待确认需求
│ └── 产品需求维护弹窗
├── 产品团队
└── 关联项目
```
## 4. 页面详细设计
### 4.1 页面模型与布局原则
产品管理采用“对象上下文型业务域”布局，不采用传统后台中“列表页 -> 详情页 -> 多页签详情”的固定写法。
页面结构应分成两种状态：
- 未选中产品时：头部只显示业务域锚点 `产品管理`，内容区承接产品对象入口页。
- 已选中产品时：头部显示 `产品管理 + 当前产品`，并切换为该产品上下文下的功能导航。
这意味着产品管理的核心不是单独设计多少个静态页面，而是先建立“当前是否已经进入某个产品上下文”的状态。
V0.5 约束如下：
- 未选中产品前，不在头部伪造一排产品功能菜单。
- 已选中产品后，头部才显示当前产品下的功能导航。
- 当前产品上下文内的功能项按 V0.5 已落地能力收敛，不预设额外功能带。
- 产品新建、编辑统一采用弹窗，不拆成独立路由页；轻量需求新增和编辑可在当前产品上下文内通过弹窗完成。
### 4.2 未选中产品时的入口态
#### 4.2.1 头部状态
- 显示业务域锚点：`产品管理`
- 不显示当前产品对象位
- 不显示产品上下文功能导航
该状态的核心目的，是让用户先完成“选择哪个产品”这一步，而不是先进入产品下的某个功能页。
#### 4.2.2 内容区结构
内容区展示产品对象入口页，主要承载：
- 产品分类或产品分组入口
- 产品列表
- 搜索、筛选
- 新建产品入口
产品分组入口放在内容区左侧的对象列表导航内，而不是放在头部。
#### 4.2.3 查询与列表
支持以下筛选条件：
- 关键词：匹配产品编码、产品名称
- 产品方向
- 产品经理
- 状态：启用、暂停、归档、废弃
- 最近更新时间
展示以下列表字段：
- 产品编码
- 产品方向
- 产品名称
- 产品经理
- 状态
- 关联项目数
- 轻量需求数
- 更新时间
说明：
- `关联项目数` 仅统计当前用户有权查看的项目数量。
- `轻量需求数` 为产品下未删除需求数量。
- 创建人、创建时间等审计字段不在入口态列表中展开，统一放在更多列或对象概览中查看。
#### 4.2.4 入口态操作
入口态只保留以下高频动作：
- 新建产品
- 进入产品
- 编辑产品
- 暂停 / 恢复 / 归档 / 废弃 / 删除
规则如下：
- `新建产品` 为独立主按钮，仅授权管理员和具备全局创建权限的产品经理可见。
- 点击产品名称或行主操作，表示“进入该产品上下文”，而不是进入传统详情页。
- 编辑和状态动作可通过行内更多菜单或右侧操作区触发，避免列表区堆积过多按钮。
### 4.3 已选中产品时的对象上下文态
#### 4.3.1 头部状态
当用户从入口态选择某个产品后，系统建立当前产品上下文，头部应切换为：
- 业务域锚点：`产品管理`
- 当前对象位：当前产品名称
- 功能导航区：显示当前产品上下文下的功能入口
交互要求：
- 点击业务域锚点，退出当前产品上下文并返回产品入口页。
- 点击当前产品对象位，可打开产品切换面板，或回到产品列表重新选择。
#### 4.3.2 V0.5 功能导航范围
V0.5 下，当前产品上下文内的功能导航保持最小集合，仅承接以下内容：
- 概览
- 产品需求
- 产品团队
- 关联项目
说明：
- `概览` 承接产品基本信息、状态信息、关键摘要和常用动作。
- `产品需求` 承接轻量需求池的查询和维护。
- `产品团队` 承接产品团队成员管理。
- `关联项目` 承接当前产品下项目查看。
- `产品研发令号` 不作为 V0.5 头部导航项，通过独立入口承接。
- `操作记录` 不作为 V0.5 头部一级功能导航单独占位，统一作为概览中的区块或独立记录查看页承接。
#### 4.3.3 对象上下文保持规则
- 用户进入某个产品后，应保持当前产品上下文，直到主动切换产品或返回产品入口页。
- 用户在产品上下文内切换功能时，不应丢失当前产品。
- 从头部切换产品时，优先保留当前功能；若目标产品下该功能不可用，则退回目标产品默认首页。
### 4.4 当前产品上下文下的功能承载
#### 4.4.1 概览
`概览` 是当前产品上下文的默认首页，用于集中展示该产品的核心信息，而不是再拆成独立详情页。
承载以下内容：
- 产品编码、产品方向、产品名称、产品经理、状态、描述
- 创建人、创建时间、更新时间等审计摘要
- 关联项目数、轻量需求数、待确认需求数等统计摘要
- 编辑、暂停、恢复、归档、废弃、删除等常用动作入口
- 待确认需求区块，用于提示由工单流转到当前产品、但尚未被产品负责人认领或拒绝的需求
- 最近动态区块，用于展示该产品最近发生的关键变更
待确认需求展示：
- 需求标题
- 来源工单
- 提交时间
- 当前工单负责人
- 快捷处理入口
待确认需求支持：
- 认领
- 拒绝
- 查看来源工单
待确认需求规则：
- 工单被归属到某产品后，不等于自动进入正式产品需求池。
- 工单流转到产品侧后，应先进入该产品下的待确认需求队列。
- 由产品负责人或授权管理员执行认领或拒绝。
- 认领后，该需求进入正式产品需求池，状态进入 `待处理`。
- 拒绝时必须填写原因，并保留与来源工单的追溯关系。
- 本设计不承接工单状态回写；产品侧只承接来源追溯、认领拒绝结果和审计留痕。
最近动态展示：
- 产品创建
- 产品编辑
- 产品经理变更
- 产品状态变更，如暂停、恢复、归档、废弃
- 产品团队关键调整
- 产品需求新增、关闭和关键状态流转
最近动态展示字段：
- 时间
- 动作描述
- 操作人
- 原因或摘要说明
最近动态的边界要求：
- 仅展示最近 `10` 条关键记录，作为概览摘要信息
- 数据来源以 `rdms_biz_audit_log` 和 `rdms_product_status_log` 为主；其中产品暂停/恢复/归档/废弃/删除来自 `rdms_product_status_log`，产品经理变更、团队成员调整、需求认领/拒绝/关闭等来自 `rdms_biz_audit_log`
- 概览中的最近动态不替代完整审计记录查询
- 完整留痕通过“查看更多操作记录”进入独立记录查看界面或展开面板
规则：
- `编辑` 仅授权管理员和当前产品经理可见。
- `暂停` 仅启用状态可见。
- `恢复` 仅暂停状态可见。
- `归档` 仅启用、暂停状态可见。
- `废弃` 仅启用、暂停状态可见。
- `删除` 仅授权管理员可见，且保持高风险动作的二次确认要求。
#### 4.4.2 产品需求
`产品需求` 承接当前产品下的轻量需求池管理，是 V0.5 产品上下文内最核心的功能页之一。
支持以下筛选条件：
- 关键词
- 分类
- 来源
- 状态
- 优先级
- 提出人
- 默认实现项目
- 是否待确认
展示：
- 需求标题
- 分类
- 来源
- 来源引用信息
- 优先级
- 状态
- 提出人
- 默认实现项目
- 更新时间
支持：
- 新增需求
- 查看需求
- 编辑需求
- 认领工单流转需求
- 拒绝工单流转需求
- 状态流转
- 关闭需求
规则：
- 产品需求来源至少包括手工新增和工单流转两类。
- 对于工单流转到产品侧的需求，需先由产品负责人或授权管理员认领或拒绝；认领后才进入正式产品需求池。
- 来源字段应支持区分 `手工新增`、`工单流转` 等来源类型；如来源于工单，还应展示来源工单编号或来源引用信息。
- 产品需求列表应支持按来源筛选，便于单独查看由工单流转进入产品侧的需求。
- 即使工单流转到产品侧的需求最终被拒绝，也应继续保留在产品需求列表中，并允许按来源和状态查询追溯，不应因被拒绝而从产品侧视图中消失。
- 产品需求既支持来源追溯，也支持父子拆分；来源追溯和拆分关系分开建模。
- 同一产品下，同一来源工单只允许沉淀 1 条源头需求记录；该源头需求和手工新增需求都允许继续拆分为 N 条子需求。
- 子需求不参与来源唯一约束；拆分链路统一由 `parent_requirement_id`、`root_requirement_id` 承接。
- 录入和维护默认仅产品经理、授权管理员可执行。
- 产品成员、产品观察者默认仅查看。
- 已关闭、已拒绝、已取消需求默认只读。
- V0.5 的 `产品需求` 只承接轻量需求池管理；是否进入 `待评审` 由业务判断决定，但不在当前版本展开正式审批流程、工作流节点和复杂评审编排。
#### 4.4.3 产品团队
`产品团队` 承接当前产品下的成员关系管理。
展示：
- 用户姓名
- 团队角色
- 状态
- 加入时间
- 退出时间
支持：
- 新增成员
- 调整角色
- 移出产品团队
规则：
- 同一产品下，同一用户只允许一条有效团队关系。
- 同一时刻只允许一个有效产品经理。
- 将某成员设为产品经理时，需要同步更新产品主表的 `manager_user_id`。
- 新增成员、调整角色、移出产品团队、变更产品经理等非状态敏感动作统一写入 `rdms_biz_audit_log`。
- 产品团队成员退出后，不自动影响其已参与项目的历史关系。
- 已退出产品团队的成员，不能再被该产品下的新项目继续选入。
#### 4.4.4 关联项目
`关联项目` 承接当前产品下项目的查看，不承接项目归属维护。
展示：
- 项目编码
- 项目名称
- 项目负责人
- 项目状态
- 更新时间
规则：
- 只展示当前用户有项目查看权限的数据。
- 不提供项目改挂产品入口。
- 产品经理不因负责产品而自动获得该产品下全部项目查看或编辑权限。
### 4.5 对象维护方式
#### 4.5.1 产品新建与编辑
产品新建和编辑作为对象维护动作处理，不单独定义独立页面。
承接方式：
- 新建产品：在入口态通过弹窗完成
- 编辑产品：在当前产品上下文的概览中触发弹窗完成
表单字段保持一致：
- 产品编码
- 产品方向
- 产品名称
- 产品经理
- 产品描述
规则：
- 产品编码支持手动录入或自动生成；创建后不可修改。
- 产品名称需校验未删除范围唯一。
- 产品方向为必填正式字段，统一通过系统字典承接；字典类型编码统一为 `rdms_product_direction`，业务表字段 `direction_code` 存字典 `value`，不存字典数据主键 ID。
- 研发令号不作为产品主表字段维护，按年度通过独立的产品研发令号能力维护。
- 产品经理允许调整，不强制等于创建人。
- 若产品经理不等于创建人，创建人只保留审计意义，不自动获得持续管理权限。
- 保存成功后自动写入创建、更新审计字段；创建时默认状态编码为 `active`，并自动建立产品经理团队关系。
#### 4.5.2 轻量需求维护
轻量需求的新增和编辑，通过当前产品上下文内的弹窗完成，不拆为独立页面。
表单字段包括：
- 需求标题
- 需求分类
- 需求来源
- 来源引用信息
- 优先级
- 需求描述
- 提出人
- 默认实现项目
规则：
- 产品需求来源至少包括手工新增和工单流转两类。
- 手工新增需求通过新增弹窗录入，默认状态编码为 `pending_process`，显示状态为 `待处理`。
- 工单流转到产品侧的需求，不通过普通新增弹窗直接进入正式需求池，而是先进入待确认队列，由产品负责人或授权管理员认领或拒绝。
- 认领后，该需求进入正式产品需求池，状态进入 `待处理`；拒绝时必须填写原因，并保留来源工单追溯关系。
- 工单来源需求在同一产品下只允许形成 1 条源头需求记录；后续如需细化，统一从该源头需求继续拆分子需求。
- 手工新增需求也允许继续拆分子需求；来源追溯和拆分关系分开承接。
- 是否进入 `待评审` 由业务判断决定；需要评审的需求进入 `待评审`，不需要评审的需求直接进入 `待分流`。
- 一个产品需求只能归属一个产品。
- `需求来源` 用于标识来源类型，如 `手工新增`、`工单流转`；如来源于工单，还应在 `来源引用信息` 中展示来源工单编号或引用信息。
- `默认实现项目` 如有值，必须指向当前产品下的合法项目。
- `reject`、`cancel`、`close` 等终态动作统一回写主表 `terminal_action_code`、`terminal_reason`、`terminal_time`。
- V0.5 不启用目标版本字段。
## 5. 对象关系与数据设计
本章描述数据关系与承接口径，物理表结构以专项 SQL 文档为准。
### 5.1 数据结构承接口径
- 产品管理实际执行 SQL 统一以 `rdms-project/rdms-project-boot/src/main/resources/sql/product/01_product_schema.sql` 为准；专项 SQL 文档仅承担设计审阅和说明。
- 系统 RBAC 角色与资源元数据以 `04-设计阶段/数据库/system_menu.sql` 的 DDL 为准。
- RDMS 对象成员关系统一由 `rdms_user_object_role` 承接。
- 产品研发令号统一由 `rdms_product_rd_order` 承接，按产品年度维护；同一产品可维护多个年度研发令号。
- 产品方向统一由系统字典承接；字典类型编码统一为 `rdms_product_direction`，`rdms_product.direction_code` 存字典 `value`，不存 `system_dict_data.id`。
- 产品状态统一由 `rdms_object_status_model`、`rdms_object_status_transition` 承接；`rdms_product.status_code` 存状态编码。
- 产品需求统一由 `rdms_product_requirement` 承接；`status_code` 存需求状态编码，状态定义与流转统一由 `rdms_object_status_model`、`rdms_object_status_transition` 承接，其中 `object_type = product_requirement`。
- 产品需求来源追溯和拆分关系分开建模；`source_type`、`source_biz_type`、`source_biz_id`、`source_biz_code` 承接来源追溯，`parent_requirement_id`、`root_requirement_id` 承接拆分链路。
- 同一产品下，同一来源工单只允许一条源头需求记录；源头需求和手工新增需求都允许继续拆分为多个子需求，子需求不参与来源唯一约束。
- 产品需求主表统一承接终态结果字段 `terminal_action_code`、`terminal_reason`、`terminal_time`；完整过程留痕继续由 `rdms_biz_audit_log` 承接。
- 产品状态留痕必须保留 `from_status`、`to_status` 字段；产品状态日志和通用业务审计日志统一按状态编码记录前后变化。
### 5.2 保留的核心关系
```text
产品(Product) 1 ---- N 项目(Project)
|
+---- N RDMS对象成员关系(UserObjectRole, object_type=product)
|
+---- N 产品研发令号(ProductRdOrder)
|
+---- N 产品需求(ProductRequirement)
|
+---- N 子需求(ProductRequirement, parent_requirement_id)
```
关系约束：
- 每个项目必须归属一个产品。
- 产品与项目关系由项目模块的 `product_id` 维护，不建立独立中间表。
- 产品团队和项目团队不是同一对象；项目团队是产品团队中的执行子集。
- 产品研发令号不属于产品主数据的一对一字段；按产品维度一对多维护。
- 同一产品同一年度只允许一个有效研发令号；研发令号本身默认不做全局唯一约束。
- 产品需求只归属产品，不直接归属项目；需要项目承接时通过 `implement_project_id` 建立默认实现关系。
- 来源追溯统一挂在源头需求上，父子拆分通过 `parent_requirement_id`、`root_requirement_id` 承接，不混用同一组字段表达两类关系。
- 同一产品下，同一来源工单只保留 1 条源头需求记录；该源头需求和手工新增需求都可继续拆分子需求。
- 当前用户在某产品中的对象角色，由 `rdms_user_object_role` 绑定 `system_role` 中 `scope_type = object`、`object_type = product` 的角色定义。
- 当前产品上下文下的导航和按钮，由 `system_role`、`system_menu`、`system_role_menu` 共同驱动。
## 6. 详细业务规则
### 6.1 主数据规则
| 编号 | 规则 |
|---:|---|
| PDD-01 | 创建产品时必须填写产品名称、产品方向、产品经理；产品编码可手动录入，也可由系统自动生成。 |
| PDD-02 | 产品编码自动生成格式统一为 `CNPD + YYYY + NNN`，按年从 `001` 递增。 |
| PDD-03 | 产品编码、产品名称在未删除范围内必须唯一。 |
| PDD-04 | 产品创建后默认状态编码为 `active`，对应产品状态模型中的“启用”。 |
| PDD-05 | 产品编码创建后不可修改。 |
| PDD-06 | 产品研发令号不作为产品主表字段；应按产品维度一对多维护，统一由 `rdms_product_rd_order` 承接。 |
| PDD-07 | 同一产品同一年度只允许一个有效研发令号；研发令号本身默认不做全局唯一约束。 |
| PDD-08 | 产品方向为必填正式字段，统一通过系统字典承接；字典类型编码统一为 `rdms_product_direction`，`direction_code` 存字典 `value`，初始值为 `embedded`、`power_electronics`、`system_group`。 |
| PDD-09 | 产品经理允许变更；创建人不可编辑修改。 |
| PDD-10 | 产品不引入产品模板、产品类型等其他正式扩展字段；方向字段除外。 |
### 6.2 产品团队规则
| 编号 | 规则 |
|---:|---|
| PDD-10 | V0.5 产品团队默认提供 `产品经理`、`产品成员`、`产品观察者` 三类对象角色。 |
| PDD-11 | 同一产品下，同一用户只允许存在一条有效团队关系。 |
| PDD-12 | 同一产品下，同一时刻只允许一个有效产品经理。 |
| PDD-13 | 产品经理变更时，必须同步产品主表和团队关系。 |
| PDD-14 | 产品团队成员是项目团队的人员来源池，但不自动继承项目权限。 |
| PDD-15 | 已退出产品团队的成员不影响历史项目关系，但不能继续被该产品下的新项目选入。 |
### 6.3 产品与项目关系规则
| 编号 | 规则 |
|---:|---|
| PDD-20 | 项目创建时必须选择所属产品。 |
| PDD-21 | 项目创建后不允许改挂产品。 |
| PDD-22 | 当前产品上下文中的关联项目列表必须按项目权限二次过滤。 |
| PDD-23 | 建项目时的产品选择范围，按“`status_code = active` + 当前用户具备该产品建项目资格”过滤。 |
| PDD-24 | V0.5 默认仅产品经理和授权管理员具备在产品下建项目资格。 |
### 6.4 产品可见范围规则
统一口径：
`产品可见范围 = 关联项目反推范围 + 产品团队范围 + 创建人范围 + 授权管理员范围 + 特殊授权范围`
细化规则：
| 编号 | 规则 |
|---:|---|
| PDD-30 | 已有关联项目的产品，任何可见该产品下至少一个项目的用户，均可查看产品基础信息。 |
| PDD-31 | 尚未关联项目的产品，仅产品团队、创建人、授权管理员和特殊授权用户可见。 |
| PDD-32 | 产品可见不等于可编辑，也不等于可在该产品下建项目。 |
| PDD-33 | 关联项目、任务、工时、周报等执行数据权限仍按项目和任务侧口径控制。 |
### 6.5 轻量需求规则
| 编号 | 规则 |
|---:|---|
| PDD-40 | 产品需求只承接通用、可复用、应进入标准产品能力的需求。 |
| PDD-41 | 单一项目、单一区域、单一客户交付诉求，应进入项目需求，不进入产品需求池。 |
| PDD-42 | 手工新增的产品需求默认进入 `待处理`；工单流转到产品侧的需求默认先进入 `待确认`。 |
| PDD-43 | 产品需求最多只挂一个默认实现项目。 |
| PDD-44 | 默认实现项目如有值，必须属于当前产品。 |
| PDD-45 | 产品需求录入、认领、拒绝、维护、关闭默认由产品经理或授权管理员承接。 |
| PDD-46 | 是否进入 `待评审` 由业务判断决定；需要评审的需求进入 `待评审`，不需要评审的需求可直接从 `待处理` 进入 `待分流`。 |
| PDD-47 | V0.5 不引入正式审批流、工作流引擎和复杂评审编排；`待评审` 仅表达业务评审待处理状态。 |
| PDD-48 | V0.5 不启用目标版本字段。 |
| PDD-49 | 产品需求本身不承接排期状态；排期由项目侧承接。 |
| PDD-50 | 工单流转到产品侧后，不等于自动进入正式产品需求池，需由产品负责人或授权管理员认领或拒绝。 |
| PDD-51 | 产品需求应保留来源类型和来源业务追溯信息；被拒绝的工单流转需求仍需可按来源与状态查询追溯。 |
| PDD-52 | 产品需求主表统一使用 `status_code`。 |
| PDD-53 | 同一产品下，同一来源工单只允许沉淀 1 条源头需求记录；该源头需求和手工新增需求都可继续拆分为 N 条子需求。 |
| PDD-54 | 来源追溯和拆分关系分开建模；来源由 `source_*` 字段承接，拆分由 `parent_requirement_id`、`root_requirement_id` 承接。 |
| PDD-55 | 子需求不参与来源唯一约束。 |
| PDD-56 | `reject`、`cancel`、`close` 等终态动作统一回写 `terminal_action_code`、`terminal_reason`、`terminal_time`，审计日志保留完整过程留痕。 |
## 7. 状态机与流程设计
### 7.1 产品状态定义
| 状态 | 说明 | 是否可被新建项目选择 | 是否允许编辑 | 是否允许新增需求 |
|---|---|---|---|---|
| 启用（`active`） | 正常可用 | 是 | 是 | 是 |
| 暂停（`paused`） | 受环境或资源限制临时暂停推进，仅保留交接与存量维护 | 否 | 是，仅限交接与存量维护 | 否 |
| 归档（`archived`） | 历史留存，只读为主 | 否 | 否 | 否 |
| 废弃（`abandoned`） | 经调研或决策确认不再继续推进 | 否 | 否 | 否 |
| 逻辑删除 | 删除结果 | 否 | 否 | 否 |
说明：
- `rdms_product` 主表统一存 `status_code`。
- 产品状态定义统一由 `rdms_object_status_model` 承接；状态动作与流转统一由 `rdms_object_status_transition` 承接。
- `逻辑删除` 不纳入正常状态模型，通过 `deleted` 表达。
- `paused` 允许通过 `resume` 动作恢复到 `active`。
- `paused` 后不自动解绑历史项目和历史需求关系。
- `paused` 后仅允许产品经理交接、产品团队维护、描述/备注修正和恢复启用，不允许继续新增产品需求。
- `archived`、`abandoned` 和删除在 V0.5 不支持恢复。
### 7.2 产品状态流转
允许流转：
- `active` --`pause`--> `paused`
- `paused` --`resume`--> `active`
- `active` --`archive`--> `archived`
- `paused` --`archive`--> `archived`
- `active` --`abandon`--> `abandoned`
- `paused` --`abandon`--> `abandoned`
补充说明：
- 上述流转以 `rdms_object_status_transition` 中 `object_type = product` 的配置为准。
- 逻辑删除不属于正常状态流转，不写入 `to_status_code` 终态，而是通过 `deleted = 1` 表达。
### 7.3 产品状态动作前置条件
#### 7.3.1 暂停（`pause`）
前置条件：
- 当前状态为 `active`。
- 产品下不存在状态为 `待开始`、`进行中`、`已暂停` 的项目。
- 产品下不存在阻塞暂停的执行和任务。
- 操作人具备暂停权限。
动作要求：
- 必填暂停原因。
- 暂停后不自动解绑历史项目和历史需求关系。
- 暂停后仅允许产品经理交接、产品团队维护、描述/备注修正和恢复启用。
- 暂停后不允许新增产品需求；已有需求可继续按权限查看、认领、分流、关闭等存量维护动作。
- 写入状态日志。
#### 7.3.2 恢复（`resume`）
前置条件：
- 当前状态为 `paused`。
- 操作人具备恢复权限。
动作要求：
- 不强制填写原因，允许补充说明。
- 写入状态日志。
#### 7.3.3 归档（`archive`）
前置条件：
- 当前状态为 `active` 或 `paused`。
- 产品下不存在状态为 `待开始`、`进行中`、`已暂停` 的项目。
- 产品下不存在阻塞归档的执行和任务。
- 操作人具备归档权限。
动作要求：
- 必填归档原因。
- 归档后产品默认只读。
- 写入状态日志。
#### 7.3.4 废弃（`abandon`）
前置条件：
- 当前状态为 `active` 或 `paused`。
- 产品下不存在状态为 `待开始`、`进行中`、`已暂停` 的项目。
- 产品下不存在阻塞废弃的执行和任务。
- 操作人具备废弃权限。
动作要求：
- 必填废弃原因。
- 废弃后产品默认只读。
- 废弃后不支持恢复。
- 写入状态日志。
#### 7.3.5 逻辑删除
前置条件：
- 产品下关联项目均已满足项目侧删除条件并已逻辑删除。
- 操作人具备删除权限。
- 二次身份确认通过。
- 二次输入产品名称确认通过。
动作要求：
- 必填删除原因。
- 写入删除人、删除时间、删除原因。
- 写入状态日志。
### 7.4 产品需求状态定义
| 状态编码 | 状态名称 | 说明 |
|---|---|---|
| `pending_confirm` | 待确认 | 工单流转到产品侧后的待确认状态，待产品负责人认领或拒绝 |
| `pending_process` | 待处理 | 手工新增后的默认状态，或工单流转需求认领后的正式初始状态 |
| `pending_review` | 待评审 | 仅针对需要评审的需求，待产品侧完成业务评审判断 |
| `pending_dispatch` | 待分流 | 需求成立，等待明确承接方向 |
| `dispatched` | 已分流 | 已明确承接方向 |
| `in_progress` | 实施中 | 承接项目已进入正式执行 |
| `accepted` | 已验收 | 承接结果已完成验收 |
| `closed` | 已关闭 | 生命周期闭环完成 |
| `rejected` | 已拒绝 | 评审后确认不成立 |
| `canceled` | 已取消 | 原已进入推进链路后终止 |
### 7.5 产品需求状态流转
允许流转：
- 待确认 -> 待处理
- 待确认 -> 已拒绝
- 待确认 -> 已取消
- 待处理 -> 待评审
- 待处理 -> 待分流
- 待处理 -> 已拒绝
- 待处理 -> 已取消
- 待评审 -> 待分流
- 待评审 -> 已拒绝
- 待评审 -> 已取消
- 待分流 -> 已分流
- 待分流 -> 已取消
- 已分流 -> 实施中
- 已分流 -> 已取消
- 实施中 -> 已验收
- 实施中 -> 已取消
- 已验收 -> 已关闭
补充规则：
- 产品需求主表统一存 `status_code`；状态定义与流转统一以 `rdms_object_status_model`、`rdms_object_status_transition` 中 `object_type = product_requirement` 的配置为准。
- 手工新增需求首状态为 `待处理`；工单流转需求首状态为 `待确认`。
- `待确认 -> 待处理` 表示产品负责人已认领，需求正式进入产品需求池。
- 只有需要评审的需求才进入 `待评审`；不需要评审的需求可直接从 `待处理` 进入 `待分流`。
- `待评审` 仅表达业务评审待处理状态，V0.5 不展开正式审批流、会签/或签或工作流引擎实现。
- `已分流 -> 实施中` 以承接项目进入正式执行为触发条件。
- 到达 `已拒绝`、`已取消`、`已关闭` 时，主表同步回写 `terminal_action_code`、`terminal_reason`、`terminal_time`。
- 产品需求认领、拒绝、分流、关闭等关键动作统一写入 `rdms_biz_audit_log`。
- 已关闭、已拒绝、已取消状态默认不再继续流转。
### 7.6 关键流程
#### 7.6.1 创建产品
1. 用户在产品入口态点击“新建产品”，打开产品新增弹窗。
2. 填写产品名称、产品方向、产品经理、产品描述，可手动录入产品编码。
3. 系统校验名称唯一、编码唯一、产品方向字典值合法、产品经理有效。
4. 编码为空时系统自动生成编码。
5. 保存产品主数据，默认状态编码设为 `active`。
6. 自动建立产品经理团队关系。
7. 写入创建审计记录。
#### 7.6.2 变更产品经理
1. 当前产品经理或授权管理员发起编辑。
2. 选择新的产品经理。
3. 系统校验目标用户有效。
4. 更新 `manager_user_id`。
5. 同步调整产品团队角色关系，保证仅一个有效 `manager`。
6. 写入 `rdms_biz_audit_log`，记录变更前后产品经理、操作者和原因。
#### 7.6.3 暂停产品
1. 用户发起 `pause` 动作。
2. 系统按 `rdms_object_status_transition` 校验 `active -> paused` 流转存在且可用。
3. 系统检查项目、执行、任务阻塞项。
4. 用户填写暂停原因。
5. 校验通过后写入状态编码为 `paused`。
6. 写入 `rdms_product_status_log`。
#### 7.6.4 恢复产品
1. 用户发起 `resume` 动作。
2. 系统按 `rdms_object_status_transition` 校验 `paused -> active` 流转存在且可用。
3. 校验通过后写入状态编码为 `active`。
4. 写入 `rdms_product_status_log`。
#### 7.6.5 归档产品
1. 用户发起 `archive` 动作。
2. 系统按 `rdms_object_status_transition` 校验目标流转存在且可用。
3. 系统检查归档阻塞项。
4. 用户填写归档原因。
5. 校验通过后更新为 `archived`。
6. 写入 `rdms_product_status_log`。
#### 7.6.6 废弃产品
1. 用户发起 `abandon` 动作。
2. 系统按 `rdms_object_status_transition` 校验目标流转存在且可用。
3. 系统检查废弃阻塞项。
4. 用户填写废弃原因。
5. 校验通过后更新为 `abandoned`。
6. 写入 `rdms_product_status_log`。
#### 7.6.7 删除产品
1. 授权管理员发起删除动作。
2. 系统复核关联项目是否已全部逻辑删除。
3. 弹出二次身份确认。
4. 要求输入产品名称确认。
5. 用户填写删除原因。
6. 校验通过后执行逻辑删除，并写入 `rdms_product_status_log`。
#### 7.6.8 新增产品需求
1. 产品经理或授权管理员在当前产品上下文的“产品需求”功能中点击“新增需求”。
2. 系统弹出新增需求弹窗，填写需求标题、分类、来源、优先级、描述、提出人、默认实现项目。
3. 系统校验默认实现项目属于当前产品。
4. 保存后状态编码默认为 `pending_process`，显示状态为 `待处理`。
5. 写入 `rdms_biz_audit_log`。
#### 7.6.9 认领或拒绝工单流转需求
1. 工单归属到某产品后，产品侧生成一条来源为工单流转的源头需求记录，状态编码为 `pending_confirm`。
2. 产品负责人或授权管理员在概览的待确认需求区块，或在产品需求列表的待确认视图中查看该记录。
3. 若认领，系统将需求状态从 `pending_confirm` 更新为 `pending_process`，并保留来源工单追溯信息。
4. 若拒绝，系统要求填写拒绝原因，并将需求状态更新为 `已拒绝`。
5. 认领或拒绝后，系统写入 `rdms_biz_audit_log`；本设计不承接工单状态回写。
#### 7.6.10 产品需求分流
1. 产品经理在产品需求中判断该诉求是否成立。
2. 若不成立，转 `已拒绝`。
3. 若成立但待确定承接方向，转 `待分流`。
4. 若已明确由具体项目承接，写入默认实现项目并转 `已分流`。
5. 本次分流动作写入 `rdms_biz_audit_log`。
6. 项目侧承接后，按项目需求和执行流转规则继续推进。
## 8. 权限与动作矩阵
### 8.1 角色定义
| 角色 | 说明 |
|---|---|
| 授权管理员 | 全局管理和高风险动作控制者 |
| 产品经理 | 单个产品的核心责任人 |
| 产品成员 | 产品侧协作成员 |
| 产品观察者 | 产品侧只读协作成员 |
| 创建人 | 审计身份，不作为长期业务角色 |
### 8.2 动作矩阵
| 动作 | 授权管理员 | 产品经理 | 产品成员 | 产品观察者 | 创建人（非产品经理） |
|---|---|---|---|---|---|
| 查看产品 | 是 | 是 | 是 | 是 | 是 |
| 创建产品 | 是 | 有条件 | 否 | 否 | 否 |
| 编辑产品 | 是 | 是 | 否 | 否 | 否 |
| 管理产品团队 | 是 | 是 | 否 | 否 | 否 |
| 暂停/恢复/归档/废弃 | 是 | 是 | 否 | 否 | 否 |
| 删除产品 | 是 | 否 | 否 | 否 | 否 |
| 查看轻量需求 | 是 | 是 | 是 | 是 | 是 |
| 新增轻量需求 | 是 | 是 | 否 | 否 | 否 |
| 编辑轻量需求 | 是 | 是 | 否 | 否 | 否 |
| 关闭轻量需求 | 是 | 是 | 否 | 否 | 否 |
| 在该产品下建项目 | 是 | 是 | 否 | 否 | 否 |
说明：
- “有条件”表示需要同时具备全局创建产品权限。
- 创建人若不是产品经理，只保留查看自己创建产品的可见补充，不自动拥有编辑和管理权限。
### 8.3 对象上下文权限与导航控制
产品管理属于对象上下文型业务域，因此权限判断需要拆成两层：
- 全局 RBAC：控制用户能否进入 `产品管理` 业务域
- 对象上下文 RBAC：控制用户在选中某个产品后，能看到哪些功能导航、访问哪些页面、使用哪些按钮
对象上下文下的权限控制规则如下：
- 当前用户在某产品中的对象角色，以 `rdms_user_object_role.role_id` 为准，且 `object_type = product`。
- 头部功能导航不直接按全局菜单固定展示，而应根据对象角色绑定的对象资源动态返回。
- 页面按钮不直接复用全局按钮集合，而应根据当前产品上下文内的对象资源权限单独判断。
V0.5 产品对象上下文按以下方式控制：
- 产品经理：可见 `概览`、`产品需求`、`产品团队`、`关联项目`，并具备产品编辑、状态动作、需求维护、团队维护等按钮权限。
- 产品成员：可见 `概览`、`产品需求`、`关联项目`，默认不具备产品状态动作和团队维护权限。
- 产品观察者：可见 `概览`、`产品需求`、`关联项目`，默认只读。
说明：
- 是否展示 `产品团队` 导航项，应以对象角色授权结果为准，不要求所有产品角色都能看到。
- 即使两个用户都能进入产品管理业务域，在不同产品中也可能看到不同的导航与按钮。
- 导航、页面、按钮三类资源应统一通过对象资源模型配置，不在前端写死角色判断。
## 9. 接口承接
### 9.1 产品主数据接口
- `GET /products`
- `GET /products/{id}`
- `GET /products/{id}/context`
- `POST /products`
- `PUT /products/{id}`
- `POST /products/{id}/change-status`
- `DELETE /products/{id}`
### 9.2 产品团队接口
- `GET /products/{id}/members`
- `POST /products/{id}/members`
- `PUT /products/{id}/members/{memberId}`
- `POST /products/{id}/members/{memberId}/inactive`
### 9.3 产品需求接口
- `GET /products/{id}/requirements`
- `POST /products/{id}/requirements`
- `GET /products/{id}/requirements/{requirementId}`
- `PUT /products/{id}/requirements/{requirementId}`
- `POST /products/{id}/requirements/{requirementId}/change-status`
### 9.4 产品关联与动态接口
- `GET /products/{id}/projects`
- `GET /products/{id}/activities`
补充说明：
- 概览中的待确认需求区块可直接复用 `GET /products/{id}/requirements`，并按 `statusCode=pending_confirm`、`sourceType=work_order`、`pageSize` 取前 `N` 条，无需重复建设独立接口。
- `GET /products/{id}/projects` 只承接关联项目查看，列表结果仍需按项目权限二次过滤。
- `GET /products/{id}/activities` 用于承接概览中的最近动态与“查看更多操作记录”，数据来源以 `rdms_biz_audit_log`、`rdms_product_status_log` 为主。
### 9.5 依赖与选择器接口说明
- 产品经理选择器复用用户中心用户查询接口 `GET /users`；产品服务负责校验目标用户有效性。
- 产品团队成员选择器复用用户中心或组织用户查询接口 `GET /users`；产品服务负责校验成员有效性和产品团队约束。
- 默认实现项目选择器复用项目模块查询接口 `GET /projects?productId={id}`；只返回当前产品下、当前用户可见的合法项目。
- 查看来源工单复用工单模块详情接口 `GET /work-orders/{id}`；产品模块只保留来源引用信息。
### 9.6 接口共性要求
- 列表接口统一支持分页、筛选、排序。
- 列表和详情接口必须做服务端权限裁剪。
- 对象上下文型业务域应提供按对象返回上下文能力的接口，至少返回当前对象摘要、当前用户对象角色、对象导航集合、对象按钮权限集合和默认首页。
- 状态动作不得复用通用编辑接口混写。
- `POST /products/{id}/change-status` 必须按动作编码传参，不允许直接透传任意目标状态；V0.5 产品状态动作统一支持 `pause`、`resume`、`archive`、`abandon`。
- `POST /products/{id}/requirements/{requirementId}/change-status` 必须按业务动作传参，不允许直接透传任意目标状态值；统一支持 `claim`、`to_review`、`to_dispatch`、`dispatch`、`reject`、`cancel`、`close` 动作。
- `claim`、`reject` 动作仅适用于工单流转形成的待确认需求；`reject`、`cancel`、`close` 必须传原因。
- `dispatch` 若直接明确承接项目，则必须同时传入 `implementProjectId`；服务端需校验该项目属于当前产品。
- 需求详情和需求列表返回体中应保留 `statusCode`、`sourceType`、`sourceBizType`、`sourceBizId`、`sourceBizCode`、`parentRequirementId`、`rootRequirementId`、`terminalActionCode`、`terminalReason`、`terminalTime` 等字段，便于前端联动来源追溯、拆分链路和结果态展示。
- 删除、归档、暂停、恢复、废弃、关闭等敏感动作必须记录审计信息。
## 10. 异常与边界
### 10.1 重复创建
- 前端需要防重复提交。
- 后端以唯一约束作为最终兜底。
### 10.2 产品重名
- 若新名称与未删除产品重名，则拒绝保存。
### 10.3 产品建错
- 不支持直接修改项目的 `product_id` 纠偏。
- 统一按“关闭/作废旧项目 + 新建正确项目”处理。
### 10.4 产品经理离岗
- 用户停用前应先完成产品经理转交。
- 系统应提示存在未交接产品，避免静默失效。
### 10.5 无项目产品
- 产品创建后允许暂时没有项目。
- 无项目产品不应全员可见。
- 仅产品团队、创建人、授权管理员和特殊授权用户可见。
### 10.6 暂停、归档和废弃后的历史关系
- 暂停、归档、废弃不自动解除历史项目归属。
- 历史统计、历史审计保留对该产品的引用。
- 暂停、归档、废弃影响的是新增和维护能力，不影响历史追溯。
## 11. 测试关注点
### 11.1 功能测试
- 产品创建、编辑、查看、查询。
- 产品编码手动录入与自动生成。
- 产品方向必填、字典值校验、筛选与展示。
- 产品研发令号按年度维护与同一产品同年度唯一校验。
- 产品经理变更与团队同步。
- 暂停、恢复、归档、废弃、删除动作。
- 轻量需求创建、编辑、来源筛选、需求拆分、状态流转、关闭。
- 工单流转需求的待确认、认领、拒绝与追溯。
### 11.2 权限测试
- 不同角色的按钮可见性。
- 无权限用户越权编辑、删除、暂停、恢复、废弃拦截。
- 当前产品上下文中的关联项目是否按项目权限二次过滤。
- 建项目产品选择器是否按资格过滤。
### 11.3 数据一致性测试
- 产品经理字段与产品团队 `manager` 关系一致。
- 删除前关联项目删除条件复核正确。
- 默认实现项目必须属于当前产品。
- 产品需求分流后与项目侧口径一致。
- 工单流转需求的来源类型、来源业务 ID、来源业务编号是否保留一致。
- 同一产品同一来源工单是否只生成 1 条源头需求记录，子需求是否不参与来源唯一约束。
- 产品需求主表 `status_code`、`terminal_*` 字段与审计日志记录是否一致。
### 11.4 回归测试
- 产品暂停后是否不能再被新建项目选择。
- 归档后产品是否只读。
- 废弃后产品是否只读且不可恢复。
- 创建人非产品经理时权限是否未被错误放大。
- 产品成员退出后是否不再进入新项目成员池。
## 12. 对下游文档的约束
### 12.1 对数据库设计文档
- 产品管理相关物理表结构统一由产品管理专项 SQL 文档承接。
- 必须落正式表：`rdms_product`、`rdms_product_rd_order`、`rdms_user_object_role`、`rdms_product_requirement`、`rdms_product_status_log`、`rdms_biz_audit_log`。
- 必须落正式表：`rdms_object_status_model`、`rdms_object_status_transition`，并写入产品和产品需求的状态定义与流转配置。
- 对象上下文 RBAC 的角色与资源元数据统一复用 `system_role`、`system_menu`、`system_role_menu`，并通过 DDL 定义 `scope_type`、`object_type` 字段。
- `rdms_biz_audit_log` 虽放在产品管理专项 SQL 中维护，但定位为 RDMS 通用业务审计表，产品、项目共用。
- 必须实现产品编码、产品名称的未删除范围唯一约束，以及产品研发令号按产品年度的未删除范围唯一约束。
- 产品方向必须统一通过系统字典承接；字典类型编码统一为 `rdms_product_direction`，业务表字段存字典 `value`，不存字典数据主键 ID。
- `rdms_product_requirement` 主表必须使用 `status_code`。
- 必须区分来源追溯字段和需求拆分字段，不得再用同一组字段混合承接两类关系。
- 必须保留 `terminal_action_code`、`terminal_reason`、`terminal_time` 三个终态结果字段。
- 必须保留创建、更新、删除审计字段。
### 12.2 对 API 接口设计文档
- 必须按“主数据接口、团队接口、状态动作接口、需求接口”拆分。
- 状态动作单独建接口，不与通用编辑混用。
- 删除、归档、暂停、恢复、废弃、关闭动作必须定义审计参数或服务端补全规则。
### 12.3 对项目管理业务设计
- 项目必须归属产品。
- 项目创建时的产品选择器范围按本文件规则执行。
- 项目成员必须来源于所属产品的有效产品团队成员池。
- 项目创建后不允许改挂产品。
### 12.4 对权限设计
- 需落实 `product_view`、`product_create`、`product_edit`、`product_status_manage`、`product_delete`、`product_member_manage`、`product_requirement_manage`、`project_create_under_product` 等动作权限。
- 需落实产品可见范围、建项目资格范围、项目成员来源范围三套口径分离但联动的实现方式。
Reference in New Issue Copy Permalink