Ops-PM Bridge - 运营产品协同加速套件
解决运营与产品之间的信息不对称、需求扯皮、效果归因等核心痛点。
核心痛点与解决方案
| 痛点 | 解决方案 | 命令 |
|---|
| 信息不对称 | 需求双向翻译 | /ops-translate |
| 需求扯皮 | 优先级智能计算 | /priority-calc |
| 效果归因争议 | 统一归因框架 | /attribution |
| 验收标准模糊 | 自动生成验收标准 | /acceptance |
| 数据口径不一致 | 数据定义对齐 | /data-align |
| 协同文档分散 | 一键生成协同文档 | /ops-doc |
1. 需求翻译器 (/ops-translate)
功能
运营语言 ↔ 产品语言双向翻译,消除理解偏差。
使用场景
- 运营提出需求,产品理解有偏差
- 产品给出方案,运营看不懂技术术语
输入格式
运营 → 产品翻译:
/ops-translate --from ops --to pm
运营需求:我们要搞个大促活动,用户参与度要高一点
产品 → 运营翻译:
/ops-translate --from pm --to ops
产品方案:实现用户增长模块,包含邀请码、裂变奖励、等级体系
输出示例
## 运营需求翻译(运营 → 产品)
### 原始需求
我们要搞个大促活动,用户参与度要高一点
### 产品语言翻译
- **功能需求**:营销活动模块
- **核心指标**:用户参与率提升 ≥ 30%
- **具体功能点**:
1. 活动落地页配置后台
2. 用户任务系统(签到、分享、邀请)
3. 积分/优惠券奖励发放
4. 实时数据看板
- **技术可行性**:✅ 可实现
- **预估工期**:2 周
- **依赖资源**:设计、前端、后端
### 需要确认的问题
1. 活动周期是多久?
2. 预算范围是多少?
3. 目标用户群体是全量还是特定人群?
2. 效果归因框架 (/attribution)
功能
统一数据口径,建立清晰的归因逻辑,避免效果争议。
输入格式
/attribution
活动名称:双11大促
目标:提升 GMV
涉及渠道:App推送、短信、社群、投放
输出示例
## 效果归因框架
### 一、数据口径定义
| 指标 | 定义 | 数据源 | 计算公式 |
|------|------|--------|----------|
| 活动GMV | 活动期间成交总额 | 订单系统 | SUM(订单金额) WHERE 活动ID = X |
| 参与用户数 | 至少完成1个任务的用户 | 活动系统 | COUNT(DISTINCT user_id) |
| 转化率 | 参与用户中下单的比例 | 订单+活动 | 下单用户数 / 参与用户数 |
| 渠道贡献 | 各渠道带来的GMV占比 | 埋点+订单 | 渠道GMV / 总GMV |
### 二、归因逻辑
#### 首次触点归因
- 用户首次接触活动的渠道获得 100% 归因
- 适用场景:品牌认知类活动
#### 末次触点归因
- 用户下单前最后一次接触的渠道获得 100% 归因
- 适用场景:促销转化类活动
#### 线性归因(推荐)
- 用户路径上所有触点平均分配归因
- 适用场景:多渠道协同类活动
#### 时间衰减归因
- 越接近转化的触点获得越高权重
- 计算公式:权重 = 0.5^(n-1),n 为距离转化的天数
### 三、归因配置
```yaml
attribution:
model: "time_decay" # 首次/末次/线性/时间衰减
lookback_window: 7 # 回溯窗口(天)
channels:
- name: "App推送"
cost: 0
weight: 1.0
- name: "短信"
cost: 5000
weight: 1.0
- name: "社群"
cost: 2000
weight: 1.0
- name: "投放"
cost: 50000
weight: 1.0
metrics:
primary: "GMV"
secondary:
- "参与用户数"
- "转化率"
- "ROI"
四、争议处理规则
- 跨渠道争议:采用时间衰减归因,数据为准
- 时间范围争议:以活动配置的起止时间为准
- 指标定义争议:以本文档定义为准,变更需双方确认
---
## 3. 优先级计算器 (`/priority-calc`)
### 功能
基于多维度自动计算需求优先级,减少扯皮。
### 输入格式
```json
{
"requirements": [
{
"name": "用户增长裂变功能",
"business_value": 5, // 业务价值 1-5
"urgency": 4, // 紧急程度 1-5
"effort": 3, // 开发成本 1-5(越大越复杂)
"risk": 2, // 风险程度 1-5
"stakeholder": 4 // 干系人重要程度 1-5
}
],
"weights": {
"business_value": 0.35,
"urgency": 0.25,
"effort": -0.15, // 负权重,成本越高优先级越低
"risk": -0.10,
"stakeholder": 0.15
}
}
输出示例
## 需求优先级评估报告
### 排序结果
| 排名 | 需求名称 | 综合得分 | 业务价值 | 紧急度 | 开发成本 | 风险 | 干系人 |
|------|----------|----------|----------|--------|----------|------|--------|
| 1 | 用户增长裂变功能 | **3.85** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| 2 | 数据看板优化 | **3.45** | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ |
| 3 | 活动配置后台 | **3.20** | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
### 计算公式
综合得分 = Σ(维度值 × 权重)
= 业务价值(5) × 0.35
- 紧急度(4) × 0.25
- 开发成本(3) × (-0.15)
- 风险(2) × (-0.10)
- 干系人(4) × 0.15
= 1.75 + 1.00 - 0.45 - 0.20 + 0.60
= 3.85
### 建议排期
1. **P0(本周)**:用户增长裂变功能
2. **P1(下周)**:数据看板优化
3. **P2(下周后)**:活动配置后台
### 风险提示
- 用户增长裂变功能涉及后端改动较大,建议预留 buffer
- 活动配置后台依赖设计资源,需提前协调
4. 验收标准生成器 (/acceptance)
功能
自动生成可量化的验收标准,避免模糊表述。
输入格式
/acceptance
需求:用户增长裂变功能
目标:提升用户邀请率
约束:预算有限,需快速上线
输出示例
## 验收标准文档
### 需求概述
- **需求名称**:用户增长裂变功能
- **需求来源**:运营团队
- **目标**:提升用户邀请率,实现低成本用户增长
- **上线时间**:2024-05-01
---
### 功能验收标准
#### 1. 邀请码功能
| 验收项 | 标准 | 验证方法 | 负责人 |
|--------|------|----------|--------|
| 邀请码生成 | 用户可生成唯一邀请码 | 功能测试 | 前端 |
| 邀请码有效期 | 默认30天有效 | 边界测试 | 后端 |
| 邀请码使用次数 | 单码限用1次 | 数据验证 | 后端 |
| 邀请记录 | 可查看邀请明细 | 功能测试 | 前端 |
#### 2. 奖励发放功能
| 验收项 | 标准 | 验证方法 | 负责人 |
|--------|------|----------|--------|
| 奖励类型 | 支持积分、优惠券 | 功能测试 | 后端 |
| 发放时效 | 邀请成功后24小时内发放 | 时效监控 | 后端 |
| 发放准确性 | 发放成功率 ≥ 99.9% | 数据监控 | 后端 |
| 异常处理 | 发放失败自动重试3次 | 异常测试 | 后端 |
---
### 数据验收标准
#### 核心指标
| 指标 | 目标值 | 数据源 | 统计周期 |
|------|--------|--------|----------|
| 邀请率 | ≥ 15% | 埋点数据 | 活动期间 |
| 邀请成功率 | ≥ 30% | 活动系统 | 活动期间 |
| 人均邀请数 | ≥ 2 人 | 活动系统 | 活动期间 |
| 新用户留存率(7日) | ≥ 40% | 用户系统 | 活动后7天 |
#### 验收数据采集
```sql
-- 邀请率
SELECT
COUNT(DISTINCT inviter_id) / COUNT(DISTINCT user_id) as invite_rate
FROM user_behavior
WHERE event_date BETWEEN '2024-05-01' AND '2024-05-15'
AND event_type IN ('generate_invite_code', 'share_invite_code');
-- 邀请成功率
SELECT
COUNT(DISTINCT invitee_id) / COUNT(DISTINCT invite_code) as success_rate
FROM invite_records
WHERE created_at BETWEEN '2024-05-01' AND '2024-05-15';
体验验收标准
| 场景 | 标准 | 验证方法 |
|---|
| 邀请码生成 | 点击后 1 秒内展示 | 性能测试 |
| 分享体验 | 支持 5+ 平台分享 | 功能测试 |
| 奖励提示 | 奖励到账后弹窗通知 | 功能测试 |
| 异常提示 | 网络错误有友好提示 | 异常测试 |
验收流程
- 开发自测:开发完成后自测所有功能点
- 测试验收:QA 按验收标准逐项测试
- 运营验收:运营在测试环境体验核心流程
- 灰度验收:5% 流量灰度,观察数据指标
- 全量验收:全量后 3 天内确认数据达标
签字确认
| 角色 | 姓名 | 签字日期 |
|---|
| 产品经理 | | |
| 运营负责人 | | |
| 技术负责人 | | |
| QA负责人 | | |
---
## 5. 数据口径对齐工具 (`/data-align`)
### 功能
统一运营和产品对数据指标的定义,避免口径不一致。
### 输入格式
/data-align
指标:DAU、GMV、转化率
场景:双11大促效果评估
### 输出示例
```markdown
## 数据口径对齐文档
### 一、核心指标定义
#### DAU(日活跃用户数)
| 维度 | 定义 | 说明 |
|------|------|------|
| **运营口径** | 每日登录 App 的独立用户数 | 包含注册未下单用户 |
| **产品口径** | 每日产生有效行为的独立用户数 | 有效行为包括:浏览、搜索、加购、下单 |
| **统一口径** | 每日至少完成 1 次有效行为的独立用户数 | ✅ 双方确认 |
**计算公式:**
DAU = COUNT(DISTINCT user_id)
WHERE event_date = today
AND event_type IN ('view', 'search', 'add_cart', 'order')
#### GMV(成交总额)
| 维度 | 定义 | 说明 |
|------|------|------|
| **运营口径** | 订单创建金额 | 包含未支付订单 |
| **产品口径** | 实际支付金额 | 仅统计已支付订单 |
| **统一口径** | 已支付订单金额 + 已发货订单金额 | ✅ 双方确认 |
**计算公式:**
GMV = SUM(order_amount)
WHERE order_status IN ('paid', 'shipped', 'completed')
AND payment_status = 'success'
#### 转化率
| 维度 | 定义 | 说明 |
|------|------|------|
| **运营口径** | 下单用户数 / 访问用户数 | 偏高 |
| **产品口径** | 支付用户数 / 访问用户数 | 偏低 |
| **统一口径** | 有效支付用户数 / 有效访问用户数 | ✅ 双方确认 |
**计算公式:**
转化率 = COUNT(DISTINCT paid_user_id) / COUNT(DISTINCT active_user_id)
WHERE event_date = today
---
### 二、数据源对齐
| 指标 | 数据源 | 表名 | 字段名 | 更新频率 |
|------|--------|------|--------|----------|
| DAU | 用户行为日志 | user_behavior | user_id, event_type | 实时 |
| GMV | 订单系统 | orders | order_amount, status | T+1 |
| 转化率 | 计算字段 | - | - | T+1 |
---
### 三、数据获取接口
```python
# DAU 查询
def get_dau(date):
query = """
SELECT COUNT(DISTINCT user_id)
FROM user_behavior
WHERE event_date = '{date}'
AND event_type IN ('view', 'search', 'add_cart', 'order')
"""
return execute_query(query)
# GMV 查询
def get_gmv(start_date, end_date):
query = """
SELECT SUM(order_amount)
FROM orders
WHERE order_status IN ('paid', 'shipped', 'completed')
AND payment_status = 'success'
AND order_date BETWEEN '{start_date}' AND '{end_date}'
"""
return execute_query(query)
四、口径变更流程
- 提出变更:任一方发起口径变更申请
- 双方确认:运营、产品双方确认新口径
- 技术评估:评估数据源、接口变更成本
- 文档更新:更新本文档
- 通知所有干系人:邮件 + 群公告
五、常见口径争议处理
| 争议场景 | 解决方案 |
|---|
| 指标定义不一致 | 以本文档为准 |
| 数据源不一致 | 以主数据源为准 |
| 计算公式有差异 | 以本文档公式为准 |
| 历史数据回溯 | 统一按新口径重新计算 |
---
## 6. 协同文档生成器 (`/ops-doc`)
### 功能
一键生成运营产品协同文档,包含需求、排期、验收、归因等完整信息。
### 输入格式
/ops-doc
项目:双11大促活动
运营负责人:张三
产品负责人:李四
### 输出示例
```markdown
# 运营产品协同文档 - 双11大促活动
## 基本信息
| 项目 | 内容 |
|------|------|
| 项目名称 | 双11大促活动 |
| 运营负责人 | 张三 |
| 产品负责人 | 李四 |
| 技术负责人 | 王五 |
| 项目周期 | 2024-10-15 ~ 2024-11-15 |
| 文档版本 | v1.0 |
| 更新时间 | 2024-10-15 |
---
## 一、背景与目标
### 活动背景
双11是全年最大的促销节点,需要通过活动提升 GMV 和用户活跃度。
### 核心目标
| 目标 | 指标 | 目标值 |
|------|------|--------|
| GMV提升 | 活动GMV | ≥ 1000万 |
| 用户增长 | 新增用户 | ≥ 5万 |
| 用户活跃 | DAU峰值 | ≥ 50万 |
| 转化提升 | 转化率 | ≥ 15% |
---
## 二、需求清单
### P0 需求
| 需求 | 描述 | 验收标准 | 排期 |
|------|------|----------|------|
| 活动落地页 | 大促活动主会场页面 | 见验收文档 | 10.25 |
| 优惠券系统 | 满减、折扣券配置发放 | 支持多种券类型 | 10.28 |
| 数据看板 | 实时活动数据监控 | 5分钟延迟内 | 10.30 |
### P1 需求
| 需求 | 描述 | 验收标准 | 排期 |
|------|------|----------|------|
| 用户裂变 | 邀请好友奖励 | 见验收文档 | 11.01 |
| 活动提醒 | 活动开始/结束提醒 | 支持多渠道推送 | 11.03 |
---
## 三、排期计划
10.15 10.20 10.25 10.30 11.04 11.09 11.11
|-----|-----|-----|-----|-----|-----|
需求评审 开发 测试 灰度 全量 复盘
### 里程碑
- **10.15**:需求评审完成
- **10.20**:技术方案确定
- **10.28**:P0 功能开发完成
- **11.01**:测试验收完成
- **11.05**:灰度发布
- **11.11**:全量上线
---
## 四、验收标准
见 [验收标准文档](./acceptance.md)
---
## 五、效果归因
见 [效果归因框架](./attribution.md)
---
## 六、数据口径
见 [数据口径对齐文档](./data-align.md)
---
## 七、沟通机制
### 日常沟通
- **群组**:双11大促协同群
- **频率**:每日站会 10:00
- **方式**:线上会议 + 群内同步
### 问题升级
1. **P2 问题**:群内沟通解决
2. **P1 问题**:负责人协调解决
3. **P0 问题**:升级到部门负责人
### 文档更新
- **负责人**:张三(运营)、李四(产品)
- **频率**:每个里程碑节点更新
- **同步范围**:所有干系人
---
## 八、风险与应对
| 风险 | 等级 | 应对措施 |
|------|------|----------|
| 技术资源不足 | 高 | 提前锁定开发资源,预留 buffer |
| 数据口径争议 | 中 | 使用数据口径对齐文档 |
| 需求变更频繁 | 中 | 需求变更需双方确认 |
| 效果不达预期 | 中 | 预备 Plan B 方案 |
---
## 九、签字确认
| 角色 | 姓名 | 签字日期 |
|------|------|----------|
| 运营负责人 | 张三 | 2024-10-15 |
| 产品负责人 | 李四 | 2024-10-15 |
| 技术负责人 | 王五 | 2024-10-15 |
---
*文档生成时间:2024-10-15*
*文档版本:v1.0*
工作流示例
场景:运营提新需求
1. 运营发送需求
/ops-translate --from ops --to pm
运营需求:我们要搞个年终活动
2. 产品理解需求后生成验收标准
/acceptance
需求:年终活动功能
3. 计算优先级
/priority-calc
[输入需求列表]
4. 生成协同文档
/ops-doc
项目:年终活动
参考文档
- 需求翻译词典:见
references/ops_pm_dictionary.md
- 优先级计算权重配置:见
references/priority_weights.md
- 归因模型说明:见
references/attribution_models.md
约束
- 所有文档生成后需双方确认
- 数据口径变更需走变更流程
- 优先级计算结果仅供参考,最终由人决策
- 验收标准必须量化可测试