Ops-PM Bridge - 运营产品协同加速套件

解决运营与产品之间的信息不对称、需求扯皮、效果归因等核心痛点。

核心痛点与解决方案

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 为距离转化的天数

### 三、归因配置

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"

### 四、争议处理规则

1. **跨渠道争议**：采用时间衰减归因，数据为准
2. **时间范围争议**：以活动配置的起止时间为准
3. **指标定义争议**：以本文档定义为准，变更需双方确认

3. 优先级计算器 (/priority-calc)

功能

基于多维度自动计算需求优先级，减少扯皮。

输入格式

{
  "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天 |

#### 验收数据采集

-- 邀请率

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+ 平台分享 | 功能测试 |
| 奖励提示 | 奖励到账后弹窗通知 | 功能测试 |
| 异常提示 | 网络错误有友好提示 | 异常测试 |

---

### 验收流程

1. **开发自测**：开发完成后自测所有功能点
2. **测试验收**：QA 按验收标准逐项测试
3. **运营验收**：运营在测试环境体验核心流程
4. **灰度验收**：5% 流量灰度，观察数据指标
5. **全量验收**：全量后 3 天内确认数据达标

---

### 签字确认

| 角色 | 姓名 | 签字日期 |
|------|------|----------|
| 产品经理 | | |
| 运营负责人 | | |
| 技术负责人 | | |
| QA负责人 | | |

5. 数据口径对齐工具 (/data-align)

功能

统一运营和产品对数据指标的定义，避免口径不一致。

输入格式

/data-align
指标：DAU、GMV、转化率
场景：双11大促效果评估

输出示例

## 数据口径对齐文档

### 一、核心指标定义

#### 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 |

---

### 三、数据获取接口

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)

---

### 四、口径变更流程

1. **提出变更**：任一方发起口径变更申请
2. **双方确认**：运营、产品双方确认新口径
3. **技术评估**：评估数据源、接口变更成本
4. **文档更新**：更新本文档
5. **通知所有干系人**：邮件 + 群公告

---

### 五、常见口径争议处理

| 争议场景 | 解决方案 |
|----------|----------|
| 指标定义不一致 | 以本文档为准 |
| 数据源不一致 | 以主数据源为准 |
| 计算公式有差异 | 以本文档公式为准 |
| 历史数据回溯 | 统一按新口径重新计算 |

6. 协同文档生成器 (/ops-doc)

功能

一键生成运营产品协同文档，包含需求、排期、验收、归因等完整信息。

输入格式

/ops-doc
项目：双11大促活动
运营负责人：张三
产品负责人：李四

输出示例

# 运营产品协同文档 - 双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

约束

1. 所有文档生成后需双方确认
2. 数据口径变更需走变更流程
3. 优先级计算结果仅供参考，最终由人决策
4. 验收标准必须量化可测试