Your Name
3ecd3d75d4
Add implementation progress reports, review reports (CTO/quality/deploy), session log, signoff table, team roster, collaboration charter, tech-stack evaluation and inventory, research reports. Remove obsolete multisync_server.py. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
18 KiB
18 KiB
name, description, emoji, color, group
| name | description | emoji | color | group |
|---|---|---|---|---|
| 部门协作章程 | 定义 8 大部门的职责边界、协作流程、接口规范和决策权限，是项目运行的根本制度。 | 📐 | blue | 管理组 |
部门协作章程
一、部门总览
| # | 部门 | 人数 | 核心职责 | 汇报对象 |
|---|---|---|---|---|
| 👔 | 管理组 | 10 | 战略决策、资源调配、需求拆解、质量终审 | 用户 |
| 📦 | 产品部 | 7 | 需求管理、产品路线图、市场研究、PRD 输出 | 产品总监→管理组 |
| 🎨 | 设计部 | 10 | UI/UX 设计、Tailwind 设计系统、视觉规范 | 项目经理→管理组 |
| 🏗️ | 工程部 | 47 | 后端开发、数据库、API、前端实现 | CTO→管理组 |
| 🧪 | 测试部 | 35 | 测试方案、质量验收、缺陷追踪、回归验证 | 质量总监→管理组 |
| 🔧 | JC组 | 11 | 运维部署、灾备、日志、缓存、Nginx/SSH | CTO→管理组 |
| 🛡️ | ECC组 | 14 | 安全审计、编码规范、文档、深度研究、TDD | CTO→管理组 |
| 🤖 | AG组 | 58 | API 设计、AI 工具、代码审查、外部情报投喂 | CTO→管理组 |
二、协作流程
2.1 全流程图
┌─────────────────────────────────────────┐
│ │
用户 ──▶ 项目经理（唯一入口） │ AG 组（横向独立支撑） │
│ 外部情报投喂 · AI 工具 · 代码审查 · 性能优化 │
═══════════════════════════════════════════════════════════════════════ │
▼ │
管理组（拆解分派 · 资源调配） │
│ │
▼ │
┌──────────────────────────┐ │
│ 阶段 1 · 立项 · 产品部主导 │ │
├──────────────────────────┤ │
│ 产品经理 → PRD 输出 │ │
│ Sprint 排序师 → 优先级列表 │ │
│ 趋势研究员 → 竞品分析 │ │
│ 产品能力评估 → 实现契约 │ │
│ │ │
│ 产品总监 → 审批 ──┐ │ │
└──────────────────│───────────┘ │
▼ │
┌──────────────────────────┐ │
│ 阶段 2 · 设计 · 设计部主导 │ │
├──────────────────────────┤ │
│ 趋势研究员 → 设计趋势报告 │ │
│ 灵感分析器 → 色彩/字体分析 │ │
│ 情绪板创作者 → 视觉方向 │ │
│ 配色策展人 → OKLCH 色板 │ │
│ 字体选择器 → 字体配对 │ │
│ UX 架构师 → CSS 布局框架 │ │
│ UI 设计师 → 组件库 + 令牌 │ │
│ 前端设计师 → Tailwind 落地 │ │
│ 设计向导 → 一站式编排(可选)│ │
└──────────────────────────┘ │
▼ │
┌──────────────────────────┐ │
│ 阶段 3 · 开发 · 工程部主导 │◀──── AG 组代码审查 ──── 贯穿全流程 ────▶ │
├──────────────────────────┤ │
│ 软件架构师 → 技术方案 │ │
│ 后端架构师 → 路由+数据模型│ │
│ FastAPI 开发 → API 实现 │ │
│ 数据库专家 → Schema+迁移 │ │
│ 前端开发者 → Tailwind 页面│ │
│ 代码审查员 → 审查报告 │ │
└──────────────────────────┘ │
▼ │
┌──────────────────────────┐ │
│ ECC 组 · 安全 / 编码规范 │◀───────────────────────────────────────── │
├──────────────────────────┤ │
│ 安全审查 → 安全审计报告 │ │
│ 编码规范 → 规范合规检查 │ │
└──────────────────────────┘ │
▼ │
┌──────────────────────────┐ │
│ 阶段 4 · 测试 · 测试部主导 │ │
├──────────────────────────┤ │
│ 测试结果分析师 → 测试方案 │ │
│ API 测试员 → API 测试报告│ │
│ 性能基准师 → 性能基准数据│ │
│ E2E 测试 → E2E 报告 │ │
│ 安全测试 → 安全测试报告│ │
│ Senior QA → 综合质量评估│ │
│ Bug Fix Brief → 修复优先级 │ │
│ │ │
│ 质量总监 → 放行/驳回 ──┐ │ │
└──────────────────────│─────┘ │
▼ │
┌──────────────────────────┐ │
│ JC 组 · 部署 │ │
├──────────────────────────┤ │
│ 灾备规划 → 回滚方案 │ │
│ 运维自动化 → Docker/CI/CD │ │
└──────────────────────────┘ │
▼ │
┌──────────────────────────┐ │
│ 阶段 5 · 发布 · 管理组终审 │ │
├──────────────────────────┤ │
│ 运维总监 → 发布许可 │ │
│ 项目经理 → 最终放行 ✅ │ │
└──────────────────────────┘ │
│ │
└─────────────────────────────────────────┘
2.2 各阶段详细说明
阶段 1：立项（产品部主导）
| 步骤 | 执行者 | 输入 | 输出 |
|---|---|---|---|
| 1.1 | 管理组 | 用户需求 | 项目章程、资源分配 |
| 1.2 | 产品部·产品经理 | 项目章程 | 产品需求文档（PRD） |
| 1.3 | 产品部·Sprint 排序师 | PRD | Sprint 优先级列表 |
| 1.4 | 产品部·趋势研究员 | 市场数据 | 竞品分析报告 |
| 1.5 | 产品部·产品能力评估 | PRD | 实现契约（接口/约束/未决项） |
| 1.6 | 管理组·产品总监 | PRD + Sprint | 最终审批 |
阶段 2：设计（设计部主导）
| 步骤 | 执行者 | 输入 | 输出 |
|---|---|---|---|
| 2.1 | 设计部·趋势研究员 | PRD | 设计趋势报告 |
| 2.2 | 设计部·灵感分析器 | 参考网站/组件库 | 色彩/字体/布局分析 |
| 2.3 | 设计部·情绪板创作者 | 趋势+灵感 | 视觉方向提案 |
| 2.4 | 设计部·配色策展人 | 情绪板 | 配色方案（OKLCH 色板） |
| 2.5 | 设计部·字体选择器 | 情绪板 | 字体配对方案 |
| 2.6 | 设计部·UX 架构师 | 配色+字体 | CSS 架构 + 布局框架 |
| 2.7 | 设计部·UI 设计师 | UX 架构 | 组件库 + 设计令牌 |
| 2.8 | 设计部·前端设计师 | 组件库 | Tailwind 代码落地 |
| 2.9 | 设计部·设计向导 | PRD | 一站式设计编排（可选流程） |
阶段 3：开发（工程部主导）
| 步骤 | 执行者 | 输入 | 输出 |
|---|---|---|---|
| 3.1 | 工程部·软件架构师 | PRD + 设计系统 | 技术方案文档 |
| 3.2 | 工程部·后端架构师 | 技术方案 | FastAPI 路由 + 数据模型 |
| 3.3 | 工程部·FastAPI/Python 开发 | 数据模型 | API 端点实现 |
| 3.4 | 工程部·数据库专家 | 数据模型 | Schema + 迁移 + 索引 |
| 3.5 | 工程部·前端开发者 | API + 设计系统 | Tailwind 页面实现 |
| 3.6 | 工程部·代码审查员 | 代码 | 审查报告 |
AG 组（外部情报投喂 · AI 工具 · 代码审查 · 性能优化 · API 设计）—— 不参与流水线排队。当各部门有问题时，AG 组到外部搜索、调研、获取情报，然后投喂给对应部门。横向独立支撑贯穿全流程。
ECC 组 · 安全 / 编码规范
| 步骤 | 执行者 | 输入 | 输出 |
|---|---|---|---|
| E1 | ECC组·安全审查 | 代码 | 安全审计报告 |
| E2 | ECC组·编码规范 | 代码 | 规范合规检查 |
阶段 4：测试（测试部主导）
| 步骤 | 执行者 | 输入 | 输出 |
|---|---|---|---|
| 4.1 | 测试部·测试结果分析师 | 技术方案 | 测试方案文档 |
| 4.2 | 测试部·API 测试员 | API 端点 | API 测试报告 |
| 4.3 | 测试部·性能基准师 | 系统 | 性能基准数据 |
| 4.4 | 测试部·E2E 测试 | 完整功能 | E2E 测试报告 |
| 4.5 | 测试部·安全测试 | 系统 | 安全测试报告 |
| 4.6 | 测试部·Senior QA | 全部报告 | 综合质量评估 |
| 4.7 | 测试部·Bug Fix Brief | 缺陷列表 | 修复优先级 |
| 4.8 | 管理组·质量总监 | 综合报告 | 放行/驳回决策 |
JC 组 · 部署
| 步骤 | 执行者 | 输入 | 输出 |
|---|---|---|---|
| J1 | JC组·灾备规划 | 系统 | 回滚方案 |
| J2 | JC组·运维自动化 | 代码 | Docker/CI/CD 配置 |
阶段 5：发布（管理组终审）
| 步骤 | 执行者 | 输入 | 输出 |
|---|---|---|---|
| 5.1 | 管理组·运维总监 | 测试报告+回滚方案 | 发布许可 |
| 5.2 | 管理组·项目经理 | 全部交付物 | 最终放行 |
三、部门接口规范
3.1 产品部 → 设计部
产品部交付：
- PRD（产品需求文档）
- 用户画像 + 场景描述
- 功能优先级列表
设计部接收后启动：
- 设计趋势研究 → 情绪板 → 配色/字体 → UX 架构 → UI 组件
3.2 设计部 → 工程部
设计部交付：
- Tailwind CSS v4 @theme 配置（颜色/字体/间距/圆角/阴影）
- 组件库（HTML + Tailwind 类名）
- 布局框架（Stacked/Sidebar/Multi-Column）
- 响应式断点规格 + 暗色模式策略
- 设计令牌文档
工程部接收后启动：
- 技术方案设计 → 数据建模 → API 开发 → 前端实现
3.3 工程部 → 测试部
工程部交付：
- 可部署的代码包（含 CI/CD 配置）
- API 文档（Swagger/OpenAPI）
- 数据库迁移脚本
- 部署说明 + 环境变量清单
测试部接收后启动：
- 制定测试方案 → 功能测试 → 性能测试 → 安全测试 → 验收
3.4 横向组支撑
ECC组提供：安全审计、代码规范检查、TDD 工作流、技术文档
JC组提供：CI/CD 流水线、Docker 配置、Nginx 路由、灾备方案、回滚方案、缓存层
AG组提供：外部情报投喂、API 设计审查、性能剖析、代码审查、AI 工具（横向独立贯穿全流程）
3.5 测试部 → 管理组
测试部交付：
- 测试报告（通过率、缺陷数、严重程度）
- 性能基准对比（vs 上一版本）
- 安全扫描结果
- 验收结论（通过/有条件通过/驳回）
管理组决策：
- 通过 → 发布
- 有条件通过 → 指定必须修复项，限期完成
- 驳回 → 返回工程部，附测试部缺陷清单
四、决策权限矩阵
| 决策类型 | AG组 | JC组 | ECC组 | 工程部 | 测试部 | 设计部 | 产品部 | 管理组 |
|---|---|---|---|---|---|---|---|---|
| 技术选型 | 建议 | 建议 | 建议 | 决定 | - | - | - | 审批 |
| 部署发布 | - | 执行 | - | 准备 | - | - | - | 批准 |
| 回滚 | - | 执行 | - | 配合 | - | - | - | 通知 |
| 架构变更 | 审查 | - | 审查 | 提案 | - | - | - | 批准 |
| 安全策略 | - | - | 制定 | 执行 | 验证 | - | - | 审批 |
| 编码规范 | 建议 | - | 制定 | 执行 | - | - | - | - |
| 设计系统 | - | - | - | 实现 | - | 制定 | - | 审批 |
| PRD/路线图 | - | - | - | - | - | - | 制定 | 审批 |
| 测试标准 | - | - | - | - | 制定 | - | - | 审批 |
| 质量放行 | - | - | - | - | 建议 | - | - | 决定 |
| 资源调配 | - | - | - | - | - | - | - | 决定 |
五、沟通规则
5.1 用户交互原则（最高优先级）
核心原则：用户只需要和项目经理对话。除非用户明确指定某个部门，否则所有内部调度由管理组自行完成。
用户
│
│ 「我要做一个 XX 功能」 ← 用户只需描述需求，无需关心哪个部门执行
│ 「设计部直接出个方案看看」
│ 「让 ECC 组审计一下安全」
│
▼
项目经理（用户唯一联系人）
│
│ 项目经理理解需求后，在管理组内部协调：
│ - 需要 PRD → 通知产品总监安排产品部
│ - 需要设计 → 通知项目经理（设计）安排设计部
│ - 需要开发 → 通知 CTO 安排工程部 + 横向组
│ - 需要测试 → 通知质量总监安排测试部
│
▼
管理组 ──内部分派──▶ 各执行部门
两种情况：
| 场景 | 用户怎么做 | 管理组怎么做 |
|---|---|---|
| 用户未指定部门 | 只描述需求，发给项目经理 | 管理组自行判断需要哪些部门参与，内部调度 |
| 用户明确指定了部门 | 如「让设计部直接出方案」 | 管理组直接路由到指定部门，无需判断 |
5.2 指令流向
用户 ←──→ 项目经理（双向唯一通道）
│
│ 项目经理在管理组内部协调
▼
管理组（集体决策）
│
│ 按章程分派任务
▼
产品部 / 设计部 / 工程部 / 测试部
│
│ 横向支撑
▼
JC组 / ECC组 / AG组
关键约束：
- 用户不需要知道哪个部门在执行——项目经理负责翻译用户需求为部门任务
- 项目经理是管理组成员，直接参与管理组决策，无需额外转述
- 各部门之间不直接接收用户指令（除非用户明确点名）
- 所有跨部门协调由管理组内部消化，不暴露给用户
5.3 冲突升级
- 同级协商：部门间直接沟通解决
- CTO 仲裁：技术争议由 CTO 裁定
- 产品总监 仲裁：需求/设计争议由产品总监裁定
- 项目经理 终裁：无法达成共识时，项目经理最终决定
5.4 信息同步
- 跨部门决策必须书面记录（PR 评论 / 文档 / issue）
- 接口变更（API / Schema / 设计令牌）必须通知所有下游部门
- 阻塞项必须在管理组周会中提出
六、附则
- 本章程由管理组制定和维护
- 部门职责边界以
docs/skills/中各文件的group:标记为准 - 成员变动需同步更新
docs/team/对应部门文件 - 本章程每季度评审一次