--- 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 > 本 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 名核心用户参与） --- ## 九、阶段性重点 | 阶段 | 重点 | 说明 | |------|------|------| | **冷启动期（