Gr Product Dev Ops

🌍 Language / 语言: 中文 | English | 日本語 | 한국어

📦 Install

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 几乎所有成长期产品都会遇到的三个矛盾

1.2 解决思路

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

四大核心机制：

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

2.1 两层看板结构

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

流向逻辑：

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

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

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

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

2.3 Bug 与 Feature Request 分流处理

三、迭代节奏设计

3.1 迭代周期选择

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

3.2 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 会议频率总览

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

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

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

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

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

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

6.1 反馈→优化闭环

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

6.2 内测用户访谈机制

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

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

七、核心指标体系

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

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

7.2 商业化核心链路指标

7.3 迭代健康度自检

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

8.1 触发重构的信号

8.2 资源分配建议

8.3 重构类需求处理

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

九、阶段性重点

十、工具推荐

附录一：Bug Report 模板

## 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（下个迭代修）]

附录二：迭代规划会模板

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

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

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

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

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

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

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

附录三：产研运职责边界

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