jsharness 1.0.0

package/.harness/docs/team-guidelines/pm-team.md

@@ -0,0 +1,337 @@
+# 产品团队 (PM) Harness 使用规范
+
+> **适用角色**: 产品经理、项目经理、需求负责人  
+> **对应 Agent**: PM 路由 Agent (project-manager)  
+> **模型档位**: Lite（轻量模型，专注分类调度）  
+> **参考契约**: `.harness/agents/project-manager/contract.yaml`  
+> **参考 Prompt**: `.harness/agents/prompt-templates.md` → PM Agent 部分  
+
+---
+
+## 一、角色定位：你是交通指挥官，不是技术决策者
+
+### 1.1 核心职责（3件事）
+
+```
+┌────────────────────────────────────────────┐
+│          PM 的三大核心职责                   │
+├────────────────────────────────────────────┤
+│  ① 需求路由 — 接收需求，判断类型，分配流程    │
+│  ② 进度追踪 — 维护 TaskBoard，识别阻塞      │
+│  ③ 协调沟通 — 跨角色协调，变更管理           │
+└────────────────────────────────────────────┘
+```
+
+### 1.2 绝对禁止做的事（触碰即违规）
+
+| # | 禁止行为 | 违规等级 | 后果 |
+|---|---------|---------|------|
+| 1 | 指定技术实现方案（如"用 Redis 缓存"） | **严重违规** | 记入绩效，流程回退 |
+| 2 | 评价代码质量或设计优劣 | **严重违规** | 口头警告 + 记录 |
+| 3 | 跳过必要的流程阶段 | **严重违规** | 需求打回重走 |
+| 4 | 在闸门判定为 BLOCK 时强行推进 | **致命违规** | 流程终止 + 通报批评 |
+| 5 | 修改任何技术文档内容 | **中等违规** | 文档还原 + 警告 |
+| 6 | 给出具体的工期承诺（不经开发确认） | **中等违规** | 承诺作废 |
+
+> 以上禁令来源: `.harness/rules/global/process-discipline.md`
+
+---
+
+## 二、日常工作规范
+
+### 2.1 需求接入与路由
+
+#### Step 1: 接收需求
+
+需求可以来自：
+- 业务方口头/邮件/IM 描述
+- Jira/Tapd 等项目管理工具的 Ticket
+- 内部优化建议
+- Bug 报告
+
+#### Step 2: 分类路由
+
+收到需求后，**必须在 4 小时内** 完成分类并选择流程变体：
+
+| 需求类型 | 判断标准 | 选择流程变体 | 预计阶段数 |
+|---------|---------|-------------|-----------|
+| **新功能** | 全新功能模块 | 标准七阶段流程 | 7 |
+| **功能增强** | 已有功能扩展 | 标准七阶段流程 | 7 |
+| **Bug 修复** | 已知缺陷修复 | Bug 修复轻量流程 | 5 |
+| **紧急热修复** | 生产环境故障 | 热修复最快路径 | 3-4 |
+| **文档/配置** | 非代码变更 | 微型流程 | 3 |
+
+**路由输出格式**：
+
+```yaml
+decision: route_type           # new-feature / bugfix / hotfix / micro
+assigned_to: requirements-analyst  # 下一步处理人
+reason: "简短理由（一句话）"
+taskboard_updated: true        # 是否已更新看板
+priority: P0/P1/P2/P3         # 优先级
+expected_complexity: low/medium/high  # 复杂度预估
+```
+
+#### Step 3: 更新 TaskBoard
+
+每次路由操作后，必须更新 `.harness/task-board.md`：
+
+```markdown
+## 进行中
+
+| 任务ID | 名称 | 类型 | 当前阶段 | 负责人 | 路由时间 | 预计交付 |
+|--------|------|------|---------|--------|---------|---------|
+| TASK-2026-001 | 用户登录优化 | 新功能 | ①需求分析 | 张三(需求) | 05-21 | 06-05 |
+```
+
+### 2.2 TaskBoard 维护规范
+
+#### 更新频率要求
+
+| 操作类型 | 响应时效 | 说明 |
+|---------|---------|------|
+| 新任务注册 | 接收后 **4小时内** | 含分类和初始路由 |
+| 状态变更通知 | 收到后 **2小时内** | 阶段切换时同步更新 |
+| 阻塞标记 | 发现后 **1小时内** | 标注阻塞原因和等待对象 |
+| 交付归档 | 完成后 **当天内** | 移至"已完成"区 |
+
+#### TaskBoard 必填字段
+
+```markdown
+### 进行中任务列表
+- [ ] 任务ID（格式: TASK-YYYY-NNN）
+- [ ] 任务名称（简短明确）
+- [ ] 需求类型（新功能/Bug修复/热修复等）
+- [ ] 当前所处阶段（①-⑦）
+- [ ] 当前负责人（具体到人）
+- [ ] 路由时间（首次分配日期）
+- [ ] 预计交付日期（与开发确认后填写）
+- [ ] 阻塞状态（如有阻塞标注原因）
+
+### 度量指标区域
+- 平均交付周期: X 天
+- 本月完成数: N 个
+- 打回率: X%
+- 各阶段平均耗时:
+  - 需求分析: X 天
+  - 方案设计: X 天
+  - 开发实现: X 天
+  ...
+```
+
+---
+
+## 三、各阶段参与规范
+
+### 3.1 ① 需求分析阶段 — 你的职责
+
+**你做什么**：
+- ✅ 向需求分析师提供业务背景和用户场景
+- ✅ 回答分析师提出的澄清问题（24h 内响应）
+- ✅ 确认验收标准的业务正确性
+- ✅ 将原始需求整理成结构化输入
+
+**你不做什么**：
+- ❌ 不自己写需求文档（那是需求分析师的事）
+- ❌ 不指定验收标准的技术指标（如"响应时间<100ms"需技术评估）
+
+### 3.2 ② 方案设计阶段 — 你的职责
+
+**你做什么**：
+- ✅ 参与方案评审会议（如有）
+- ✅ 确认方案是否覆盖了所有业务需求
+- ✅ 对方案提出业务层面的疑问
+
+**你不做什么**：
+- ❌ 不评价技术方案的优劣
+- ❌ 不指定使用什么技术栈
+- ❌ 不修改 API 定义文档
+
+### 3.3 ③ 闸门评估阶段 — 你的职责
+
+**你做什么**：
+- ✅ 提供/确认资源可用性信息
+- ✅ 确认商业优先级排序
+- ✅ HOLD 状态下等待时配合提供补充信息
+
+**你不做什么**：
+- ❌ 不干预 PASS/BLOCK/HOLD 的技术裁决
+- ❌ 不因为"赶进度"而施压放行
+
+### 3.4 ④-⑥ 开发/审查/测试阶段 — 你的职责
+
+**你做什么**：
+- ✅ 定期查看 TaskBoard 了解进度
+- ✅ 回答业务层面的问题（及时响应）
+- ✅ 如有需求变更，通过正式流程发起
+
+**你不做什么**：
+- ❌ 不催促"快点做完"（应关注阻塞点而非施压）
+- ❌ 不在中途添加新需求（变更走正式流程）
+- ❌ 不直接找开发者改东西
+
+### 3.5 ⑦ 交付归档阶段 — 你的职责（主要责任！）
+
+这是 PM **最核心的操作阶段**：
+
+**必须完成的动作清单**：
+
+| # | 动作 | 完成标准 | 截止时间 |
+|---|------|---------|---------|
+| 1 | 汇总全链路交付物 | 所有阶段文档已收集归档 | 交付后 1 天内 |
+| 2 | TaskBoard 移至已完成 | 更新状态 + 填写实际交付周期 | 交付后 4 小时内 |
+| 3 | 记录度量数据 | 周期时间、各阶段耗时、打回次数 | 交付后 1 天内 |
+| 4 | 通知相关利益方 | 发送交付通知（含摘要） | 交付后 4 小时内 |
+| 5 | 更新项目整体状态 | 同步到公司级项目看板 | 交付后 1 天内 |
+
+**交付摘要模板**：
+
+```markdown
+# 交付摘要: {任务名称}
+
+## 基本信息
+- **任务ID**: TASK-YYYY-NNN
+- **任务名称**: xxx
+- **负责人**: xxx
+- **交付日期**: YYYY-MM-DD
+
+## 交付周期总览
+| 阶段 | 耗时 | 负责人 | 打回次数 |
+|-----|------|-------|---------|
+| 需求分析 | X 天 | xxx | N |
+| 方案设计 | X 天 | xxx | N |
+| 闸门评估 | X 天 | xxx | - |
+| 开发实现 | X 天 | xxx | N |
+| 代码审查 | X 天 | xxx | N |
+| 测试验证 | X 天 | xxx | N |
+| **总计** | **X 天** | | **N** |
+
+## 产出物清单
+- [x] 需求文档 (requirements-{id}.md)
+- [x] 验收标准 (acceptance-criteria.md)
+- [x] 设计文档 (design-{id}.md)
+- [x] API 定义 (api-definition.yaml)
+- [x] 实现代码 (src/)
+- [x] 单元测试 (*.test.*)
+- [x] 代码审查报告 (review-report.md)
+- [x] 测试报告 (test-report.md)
+
+## Gate 检查结果
+- 静态检查: PASS/WARNING/FAIL
+- 构建检查: PASS/FAIL
+- 测试合规: PASS/FAIL
+- 安全扫描: PASS/FAIL
+- 工程一致性: PASS/WARNING/FAIL
+
+## 经验教训（可选）
+（记录本次交付中的问题和改进点）
+```
+
+---
+
+## 四、变更管理规范
+
+### 4.1 需求变更流程
+
+```
+发现需要变更 → 填写变更请求单 → PM 评估影响范围 
+→ 通知当前阶段负责人 → 暂停或回退 → 变更处理后继续
+```
+
+**变更请求模板**：
+
+```markdown
+# 需求变更请求
+
+## 基本信息
+- **原任务ID**: TASK-YYYY-NNN
+- **当前阶段**: 第X阶段（名称）
+- **申请人**: xxx
+- **申请日期**: YYYY-MM-DD
+
+## 变更内容
+### 变更前
+（原需求描述）
+
+### 变更后
+（变更后的需求描述）
+
+## 变更原因
+（为什么需要变更）
+
+## 影响范围评估
+- [ ] 需要重新做需求分析
+- [ ] 需要修改设计方案
+- [ ] 需要修改已写代码
+- [ ] 影响测试用例
+- [ ] 影响交付时间
+
+## PM 初步意见
+（同意/有条件同意/拒绝 + 理由）
+```
+
+### 4.2 变更时机规则
+
+| 当前阶段 | 小变更处理方式 | 大变更处理方式 |
+|---------|--------------|---------------|
+| ① 需求分析 | 直接修改 | 直接修改 |
+| ② 方案设计 | 发起变更请求，通常可就地修正 | 可能回退到① |
+| ③ 闸门评估 | HOLD + 变更请求 | 回退到②或① |
+| ④ 开发实现 | 严格限制，仅允许修 bug | 必须回退到② |
+| ⑤ 代码审查 | 原则上不接受 | 必须回退 |
+| ⑥ 测试验证 | 仅接受 bug 修复类变更 | 必须回退到④ |
+
+---
+
+## 五、绩效考核关联指标
+
+作为 PM，以下指标将纳入你的绩效评估：
+
+| 指标 | 目标值 | 权重 | 数据来源 |
+|-----|-------|------|---------|
+| 需求路由时效 | ≤ 4小时响应 | 20% | TaskBoard 时间戳 |
+| TaskBoard 准确率 | ≥ 95% | 20% | 月度抽查 |
+| 交付归档完整性 | 100% 字段齐全 | 15% | 归档检查 |
+| 流程违规次数 | = 0 严重违规 | 25% | 违规记录 |
+| 需求交付周期达标率 | ≥ 80% | 20% | 度量数据 |
+
+---
+
+## 六、常用命令速查
+
+```bash
+# 查看 TaskBoard
+cat .harness/task-board.md
+
+# 查看当前工作流状态
+node .harness/workflow/validate.js
+
+# 查看流程变体定义（用于路由决策）
+cat .harness/workflow/variants.yaml
+
+# 查看 PM 自身契约约束
+cat .harness/agents/project-manager/contract.yaml
+
+# 查看流程纪律规则（你的行为边界）
+cat .harness/rules/global/process-discipline.md
+```
+
+---
+
+## 七、检查清单：PM 日常自查
+
+每天上班前花 2 分钟确认：
+
+- [ ] TaskBoard 中"进行中"任务状态是否准确？
+- [ ] 昨天是否有未处理的阻塞需要跟进？
+- [ ] 今天是否预期有需求到达？准备好接收了吗？
+- [ ] 本周是否有预计交付的任务？提前准备归档。
+
+每周五下班前：
+- [ ] 本周新增/完成/取消的任务数量统计
+- [ ] 本周是否有流程卡点需要上报？
+- [ ] 下周重点任务的优先级排序确认
+
+---
+
+*本规范是产品团队在 Harness 体系中的完整操作指南。有疑问请查阅 `../README.md` 总纲或联系工程效能组。*