Gr Product Dev Ops

---
name: gr-product-dev-ops
description: |
  🇺🇸 Your dev team ships features nobody asked for while user-reported bugs pile up for months. Operations blames engineering for ignoring users; engineering blames operations for not understanding technical constraints. This gives you the complete Product × Engineering × Operations alignment SOP — from unified backlog to 10-day sprint cadence to veto power rules.

  What's inside:
  • Dual-layer Kanban system (master backlog + sprint board with unified tagging)
  • 10-day sprint standard process (Day 1 dev → Day 6 testable build → Day 10 ship)
  • Issue template with reproducibility requirements (3x reported = auto-severe)
  • Tri-party alignment meetings (daily standup / sprint planning / sprint review)
  • Operations veto power on releases (P0 bug = block shipping)
  • User feedback → product iteration closed loop (beta testing + interview SOP)
  • Core metrics framework (acquisition → activation → retention → monetization → referral)
  • Technical debt management (20-30% sprint capacity reserved)
  • Ready-to-use templates: Bug Report, Sprint Planning, Responsibility Matrix

  Built from: Real product strategy meetings + beta testing frameworks. References Supabase sprint model, Manus/DeepSeek commercialization alignment. By @WeiYipei.

  🇨🇳 你的研发团队在做没人要的新功能，用户反馈的 Bug 堆了三个月没人动。运营觉得研发不听用户，研发觉得运营不懂技术。这份 SOP 给你从统一看板到 10 天迭代节奏到一票否决权的完整产研运协同框架。

  🇯🇵 開発チームは誰も求めていない機能を作り、ユーザーから報告されたバグは何ヶ月も放置。このSOPは、統一バックログから10日スプリント、リリース拒否権まで、プロダクト×エンジニアリング×オペレーションの完全な連携フレームワークを提供します。

  🇰🇷 개발팀은 아무도 요청하지 않은 기능을 만들고, 사용자가 보고한 버그는 몇 달째 방치됩니다. 이 SOP는 통합 백로그부터 10일 스프린트, 릴리스 거부권까지 제품×개발×운영 완전 협업 프레임워크를 제공합니다.

  Triggers: "product ops" | "engineering operations" | "product development SOP" | "sprint planning" | "iteration management" | "cross-functional alignment" | "product engineering ops" | "dev ops collaboration" | "产研运协同" | "迭代管理" | "产品研发运营" | "プロダクト開発運営" | "제품개발운영"
tags:
  - product-management
  - engineering-operations
  - sprint-planning
  - iteration-management
  - cross-functional
  - product-ops
  - agile
  - kanban
  - bug-tracking
  - user-feedback
  - technical-debt
  - release-management
  - startup-operations
  - team-alignment
  - commercialization
source: https://github.com/Gingiris-1031/gingiris-skills/tree/main/skills/gr-product-dev-ops
---

> 🌍 **Language / 语言**: [中文](#中文版) | [English](references/en/README.md) | [日本語](references/ja/README.md) | [한국어](references/ko/README.md)

## 📦 Install

```bash
clawhub install product-dev-ops-playbook
```

**What you get after installing:**
- Complete 10-day sprint cadence with tri-party alignment checkpoints
- Issue template + severity auto-escalation rules (3x reported = must-fix)
- Ready-to-use meeting templates for sprint planning, review, and daily standups

---

# 产品研发 × 运营协同 SOP

## 证据补充：避免“40 分功能”陷阱

本地播客逐字稿中的 AFFiNE 复盘指出：方案被想出来时，产品工作才刚开始。若团队不断追逐新点子，会留下大量只做到 40–60 分、没有验证激活和留存的功能。每次迭代规划必须回答：本期把哪个已有能力从“能用”磨到“可靠”，完成阈值是什么，以及为此明确停止什么。

> 本 SOP 整合一场真实产品战略会议纪要、用户反馈录入模板、内测用户访谈体系，提炼出一套**产品、研发、运营三方协同**的通用工作框架。
>
> **核心原则：** 一切面向商业化服务。一切为赚钱服务。
>
> **使用说明：** 本文档为通用模板，将所有 `[产品名称]` / `[项目代号]` / `[系统名称]` 替换为对应信息即可直接使用。

---

## 一、核心问题诊断：为什么产研运总是协同不好？

### 1.1 几乎所有成长期产品都会遇到的三个矛盾

| 矛盾 | 表现 | 本质原因 |
|------|------|----------|
| **新功能 vs 用户反馈** | 开发团队总在追新功能，用户反馈的小 Bug 被无限搁置 | 没有统一的优先级决策机制 |
| **研发想做什么 vs 运营要什么** | 研发觉得运营不懂技术，运营觉得研发不听用户 | 缺少共同目标 |
| **快 vs 稳** | 产品形态还没稳定就急着增长，技术债越积越多 | 没有明确的产品阶段判断 |

### 1.2 解决思路

> **来自真实会议洞察：** 商业化变现做得好的公司（如 Manus、DeepSeek），COO 或运营负责人直接为商业化服务，产研运三方高度协同。

**四大核心机制：**

| # | 机制 | 说明 |
|---|------|------|
| 1 | **统一看板** | 用户反馈和产品需求进同一个池子，用同一套标签体系 |
| 2 | **共同目标** | 每次迭代有明确的商业化指标（如"注册→付费转化率从 4.5% → 7%"） |
| 3 | **运营有一票否决权** | 直接伤害用户体验或付费转化的问题，运营可以直接提议推迟发版 |
| 4 | **每个迭代前三方对齐** | 产研运负责人共同决定做什么、哪些先做、哪些放下一期 |

---

## 二、统一协作载体：看板体系设计

### 2.1 两层看板结构

> **来自真实经验：** 不要只有每个迭代的小看板，一定要有总看板。所有原始 Issue 先进总池子，再流向下游各个迭代。

| 层级 | 名称 | 内容 | 负责人 |
|------|------|------|--------|
| **第一层：总需求池** | `[产品名称] 总 backlog` | 所有来源的原始 Issue（用户反馈/竞品分析/战略需求） | 产品负责人 |
| **第二层：迭代看板** | `[版本号] - [目标描述]` | 本次迭代确认要做的需求 + 必须修的 Bug | 迭代 owner |

**流向逻辑：**

```
总需求池（所有来源的 Issue）
    ↓ 经过评审，认为可以形成方案
形成方案的需求
    ↓ 经过排期会议决策
进入某个迭代的项目
    ↓ 迭代内开发
发布上线 / 回滚到需求池 / 延到下一期
```

### 2.2 Issue 录入模板（通用格式）

> **关键原则：** 运营提的每个 Issue 必须包含可复现信息，否则研发无法 fix。

| 字段 | 说明 | 示例 |
|------|------|------|
| **Issue 标题** | 简明描述问题 | "iOS 版本排盘结果与 Android 不一致" |
| **来源渠道** | 用户反馈 / 竞品 / 战略 | 用户反馈 |
| **反馈次数** | 同一问题被反馈几次 | 3次以上 → 打严重标签 |
| **系统/平台** | Web / iOS / Android / Self-host | iOS |
| **版本号** | 具体版本 | v2.3.1 |
| **复现步骤** | 能复现才能修 | 1. 打开合盘 2. 选择XX 3. 查看结果 |
| **预期行为** | 用户期望是什么 | 两版排盘结果应一致 |
| **实际行为** | 当前实际表现 | iOS 显示顺序与 Android 相反 |
| **截图/录屏** | 附上证据 | [附件] |
| **影响评估** | 对体验/付费的影响 | 导致1名用户申请退款 |
| **标签** | Bug / Feature Request / UX优化 | Bug |
| **优先级建议** | 运营侧判断（高/中/低） | 高 |

> **运营侧特殊规则：** 同一 Issue 被反馈 **3 次以上**，自动打 `severe` 标签，必须在最近一个迭代中解决。

### 2.3 Bug 与 Feature Request 分流处理

| 类型 | 定义 | 处理方式 |
|------|------|----------|
| **Bug** | 现有功能行为与预期不符 | 直接进入 Bug 看板，研发评估工时后修复 |
| **Feature Request** | 用户需要新功能 | 进入总需求池，产品出方案后才能进入迭代 |
| **UX优化** | 不影响核心功能，但影响体验 | 与 Bug 同级，运营可以推动优先级 |

---

## 三、迭代节奏设计

### 3.1 迭代周期选择

| 产品阶段 | 推荐迭代周期 | 说明 |
|----------|-------------|------|
| **早期 PMF 验证** | 1-2 周 | 快节奏，快速试错 |
| **增长期** | 3-4 周 | 平衡速度与稳定性 |
| **稳定期** | 6-8 周 | 稳定性优先，可以做大版本 |

> ⚠️ **提醒：** 现代 Web 开发节奏下建议压缩到 **10 天~2 周**。过长的迭代周期会导致团队失去紧迫感。

### 3.2 10 天迭代标准流程

| 天次 | 研发动作 | 运营动作 | 产出物 |
|------|----------|----------|--------|
| **第 1 天** | 开始开发 | — | — |
| **第 6 天** | 提交**可测试版本** | 领取测试版本，**半天内测完** | 测试报告（Bug 列表 + 优先级） |
| **第 7 天** | 根据优先级修复 P0/P1 | 运营×研发**对齐会**（20-30 分钟） | 本迭代范围确认 |
| **第 8 天** | 继续修复 + 出第二测试版 | 第二轮测试（如有必要） | — |
| **第 9 天** | 最终修复 | 准备**发布物料**（截图/官网/社媒） | 物料就绪 |
| **第 10 天** | **发布上线** | 同步发布内容到各渠道 | 发布完成 |

### 3.3 发布节奏红线

> **来自真实教训：** 绝对不要在周五或周末发版。

---

## 四、三方对齐会议机制

### 4.1 日常站会（每日，15 分钟）

**参与人：** 产品 / 研发 / 运营全体

- 站着开，限时 15 分钟以内
- 每人只说三件事：①昨天做了什么 ②今天在做什么 ③有没有 blocker
- **运营侧必须通报**：昨日用户投诉热点、新发现的高频 Bug
- **超过 1 小时的会一定有人摸鱼**

### 4.2 迭代规划会（每迭代开始，30-60 分钟）

**参与人：** 产研运三方负责人

```
议题1：复盘上一迭代（20分钟）
  - 核心指标完成情况（对比目标）
  - 有哪些没做完？为什么？
  - 用户反馈集中在哪里？

议题2：本迭代目标设定（20分钟）
  - 运营侧：本迭代最需要解决的问题（关联商业化目标）
  - 产品侧：本迭代主推的新功能/优化
  - 研发侧：技术债/重构需求
  - 共同决策：本迭代的 Top 3 目标

议题3：资源与排期确认（20分钟）
  - 各方投入多少人天？
  - 哪些功能确定进迭代？哪些 hold？
  - 是否有模块需要重构？
```

### 4.3 迭代验收会（每迭代结束，30 分钟）

**核心问题：**
1. 本迭代的**目标指标**达成情况？
2. 有哪些 P0 Bug 没修完？是否影响发版？
3. 哪些功能决定**推迟到下个迭代**？
4. 下个迭代的运营重点是什么？

### 4.4 会议频率总览

| 会议 | 频率 | 时长 | 目的 |
|------|------|------|------|
| **每日站会** | 每天 | 15 分钟 | 同步进度，发现 blocker |
| **迭代规划会** | 每迭代开始 | 30-60 分钟 | 决定这个迭代做什么 |
| **迭代验收会** | 每迭代结束 | 30 分钟 | 复盘 + 为下个迭代做准备 |
| **月度 Review** | 每月 | 60-90 分钟 | 核心指标复盘 + 方向调整 |

---

## 五、运营侧在协同中的角色

### 5.1 运营是用户和研发之间的"翻译官"

| 职责 | 具体动作 | 频率 |
|------|----------|------|
| **用户声音收集** | 整理用户反馈，提炼高频问题，归类 Bug / Feature | 每日 |
| **Bug 初筛** | 确认每个 Issue 可复现，补充复现步骤 | 每日 |
| **优先级建议** | 站在用户体验和商业化角度打优先级 | 每迭代 |
| **版本验收测试** | 第 6 天开始，**半天内测完**并出报告 | 每迭代 |
| **发布物料准备** | App Store 更新、官网更新、社媒发布内容 | 每迭代 |

### 5.2 运营对发版的一票否决权

> **触发条件：** 如果上线前发现**影响用户体验或付费转化**的 P0 Bug 未修复，运营可以提议**推迟发版**。

**P0 Bug 标准（运营侧判断）：**

| Bug 类型 | 例子 | 是否 P0 |
|----------|------|---------|
| 付费相关 | 支付失败、重复扣款 | ✅ P0 |
| 核心功能不可用 | 无法注册、无法生成结果 | ✅ P0 |
| 数据错误 | 排盘结果与其他平台不一致 | ✅ P0 |
| 界面错乱但功能可用 | 按钮位置偏移 | ⚠️ P1 |
| 文案/翻译错误 | 英文拼写错误 | ❌ P2 |

---

## 六、用户反馈驱动产品迭代

### 6.1 反馈→优化闭环

```
用户使用产品 → 产生问题/建议
        ↓
运营收集（整理/分类/初筛）
        ↓
录入 Issue 到总看板（附复现步骤）
        ↓
同一问题被反馈3次以上 → 打 severe 标签
        ↓
每迭代规划会重点讨论 severe 项
        ↓
进入迭代开发
        ↓
上线后运营验证问题是否解决
        ↓
通知用户问题已修复（增强被重视感）
```

### 6.2 内测用户访谈机制

| 阶段 | 时间 | 动作 | 负责人 |
|------|------|------|--------|
| **用户筛选** | 内测前 1 周 | 从活跃用户中筛选 10-15 人 | 运营 |
| **测试账号发放** | 内测前 3 天 | 发放测试账号 + 积分 | 运营 |
| **用户自测** | 内测期间 | 基于真实需求使用产品 | 用户 |
| **深度访谈** | 内测期间 | 30-40 分钟/场 | 运营 |
| **每日汇总** | 每日结束后 | 整理高频 Bug + 核心需求 | 运营 |
| **周维度 Review** | 每周 | 判断是否适合发布 | 产研运共同 |

**访谈结构（30-40 分钟）：**

| 时间 | 模块 | 核心问题 |
|------|------|----------|
| 5 分钟 | 用户背景 | 当前做什么？用什么工具？最大问题？ |
| 20 分钟 | 产品测试复盘 | 哪步最顺？哪步最卡？有没有 Bug？ |
| 10 分钟 | 优化建议 | 最希望优先优化什么？ |
| 5 分钟 | 收尾确认 | 是否愿意继续参与？愿意推荐吗？ |

> **核心原则：** 不讨论抽象感受，只讨论真实使用过程。

---

## 七、核心指标体系

### 7.1 每个迭代的目标指标模板

```
本迭代目标：[具体描述]
- 起始值：XX%
- 目标值：XX%
- 验证方式：[数据来源/查询方式]
- 负责人：产品/运营/研发
```

### 7.2 商业化核心链路指标

| 阶段 | 指标 | 说明 |
|------|------|------|
| **获取** | 新增注册用户数 | 按渠道拆分（自然/社媒/投放/KOL） |
| **激活** | Onboarding 完成率 | 分模块看：信息输入/功能体验/得到结果 |
| **留存** | 次日/7日/30日留存率 | 按用户来源拆分 |
| **付费** | 注册→付费转化率 | 按渠道/用户属性拆分 |
| **推荐** | K 因子（NPS/推荐意愿） | 邀请机制参与率 |

### 7.3 迭代健康度自检

| 检查项 | 健康值 | 预警信号 |
|--------|--------|----------|
| P0 Bug 平均修复时长 | ≤2 天 | > 3 天 |
| 功能按时上线率 | ≥80% | <60% |
| 用户反馈平均响应时长 | ≤24 小时 | > 48 小时 |
| 同一 Bug 重复反馈次数 | ≤2 次 | ≥3 次 |
| 测试报告提交及时率 | 100% 在 Day 6.5 前 | 超过半天 |

---

## 八、技术债与产品重构管理

### 8.1 触发重构的信号

| 信号 | 说明 |
|------|------|
| 同一模块 Bug 反复出现（≥5 个相关 Issue） | 模块设计有根本性问题 |
| 新功能开发成本越来越高 | 底层架构限制了扩展性 |
| 多端数据不一致 | 实体抽象不统一 |
| 技术选型已过时 | 需要升级技术栈 |

### 8.2 资源分配建议

| 类型 | 建议占比 | 说明 |
|------|----------|------|
| **新功能开发** | 50-60% | 直接服务商业化目标 |
| **Bug 修复** | 20-30% | 保障基础体验 |
| **技术债/重构** | 20-30% | 保障长期可持续性 |

### 8.3 重构类需求处理

- 重构类需求**单独建 Project**，周期 1-3 个月
- 重构期间**不影响正常迭代发版**（两套体系并行）
- 重构完成后需要**完整的回归测试**（建议 3-5 名核心用户参与）

---

## 九、阶段性重点

| 阶段 | 重点 | 说明 |
|------|------|------|
| **冷启动期（<PMF）** | 跑通协同流程 | 2-3 个迭代把流程跑通，深度访谈 20-30 名用户 |
| **增长前期** | 明确核心指标 | Onboarding 完成率 / 转化率 / 留存曲线 |
| **快速增长期** | 提升研发效率 | 压缩迭代到 10 天，建立 in-house 增长团队 |

---

## 十、工具推荐

| 用途 | 工具 | 说明 |
|------|------|------|
| 项目管理 | **Linear** / Jira / 飞书多维表格 | 所有 Issue 统一入口 |
| 数据分析 | **PostHog** / Amplitude / Mixpanel | 核心链路埋点 + 漏斗分析 |
| 用户反馈收集 | GitHub Issue / Linear / 飞书多维表格 | 用户可直接提交 |
| 会议纪要 | 飞书智能纪要 | 访谈记录自动整理 |
| 内部沟通 | 飞书 / Slack | 按项目建频道 |
| 内容管理 | Notion / 飞书云文档 | SOP、模板、知识库 |

---

## 附录一：Bug Report 模板

```markdown
## Issue 标题
[简明描述问题]

## 基本信息
- **来源渠道**：[用户反馈 / 客服 / 社媒 / 内测]
- **反馈次数**：[N] 次（≥3次请标注 severe）
- **系统/平台**：[Web / iOS / Android / Self-host]
- **版本号**：[如 v2.3.1]

## 复现步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]

## 预期行为
[用户期望应该是什么样的]

## 实际行为
[当前实际发生的情况]

## 证据
[截图 / 录屏链接]

## 影响评估
[对用户体验/付费转化/留存的影响]

## 标签
[Bug / Feature Request / UX优化]

## 优先级建议（运营侧）
[P0（立即修）/ P1（本迭代修）/ P2（下个迭代修）]
```

---

## 附录二：迭代规划会模板

```markdown
# [迭代名称] 规划会议纪要
**日期：**
**参与人：**

## 一、上迭代复盘
| 目标指标 | 起始值 | 结果值 | 完成情况 |
|---------|-------|-------|---------|
| | | | |

**未完成项：**
1.
2.

## 二、本迭代目标
| # | 目标 | 对应商业化价值 | 负责人 |
|---|-----|------------|-------|
| 1 | | | |
| 2 | | | |
| 3 | | | |

## 三、运营侧需求
| 需求 | 背景/用户反馈来源 | 建议优先级 |
|-----|----------------|----------|
| | | |

## 四、研发侧评估
| 需求 | 技术方案 | 工时估计 | 本迭代可完成？ |
|-----|---------|--------|-------------|
| | | | |

## 五、最终确认范围
**进入迭代：**
**延到下期：**
**技术债安排：**
```

---

## 附录三：产研运职责边界

| 事项 | 决策方 | 建议方 | 执行方 |
|------|--------|--------|--------|
| 功能要不要做 | 产品 + 运营 | 运营（需求）、研发（可行性） | 研发 |
| Bug 修不修 | 产品 + 运营 | 运营（反馈集中度） | 研发 |
| 发版时间 | 产研运三方共同 | — | — |
| 用户访谈发现的优先级 | 运营 | — | 产品 + 研发 |
| 增长策略 | 运营 + 产品 | 研发（数据支持） | 运营 |
| 技术架构/重构 | 研发 + 产品 | 运营（体验影响） | 研发 |

---

*本 SOP 整合自真实产品战略会议纪要、用户反馈录入模板、内测用户访谈体系。适用于所有需要在产品、研发、运营三方之间建立协同机制的产品团队。*