Skill: lijinhongucl-pixel/ops-pm-bridge (version 1.0.0)

--- name: ops-pm-bridge description: "运营-产品协同加速套件。解决运营与产品之间的信息不对称、需求扯皮、效果归因等痛点。用于：(1) 运营需求翻译为产品语言；(2) 效果归因框架生成；(3) 优先级智能计算；(4) 验收标准自动生成；(5) 数据口径对齐；(6) 协同文档生成。触发词：运营需求、产品协同、效果归因、需求扯皮、数据口径、验收标准、优先级评估。" metadata: hermes: display_name: "Ops-PM Bridge 运营产品协同套件" tags: [运营, 产品, 协同, 需求, 归因, 验收] category: productivity author: "OpenClaw" version: "1.0.0" --- # 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 产品方案：实现用户增长模块，包含邀请码、裂变奖励、等级体系 ``` ### 输出示例 ```markdown ## 运营需求翻译（运营 → 产品） ### 原始需求 我们要搞个大促活动，用户参与度要高一点 ### 产品语言翻译 - **功能需求**：营销活动模块 - **核心指标**：用户参与率提升 ≥ 30% - **具体功能点**： 1. 活动落地页配置后台 2. 用户任务系统（签到、分享、邀请） 3. 积分/优惠券奖励发放 4. 实时数据看板 - **技术可行性**：✅ 可实现 - **预估工期**：2 周 - **依赖资源**：设计、前端、后端 ### 需要确认的问题 1. 活动周期是多久？ 2. 预算范围是多少？ 3. 目标用户群体是全量还是特定人群？ ``` --- ## 2. 效果归因框架 (`/attribution`) ### 功能 统一数据口径，建立清晰的归因逻辑，避免效果争议。 ### 输入格式 ``` /attribution 活动名称：双11大促 目标：提升 GMV 涉及渠道：App推送、短信、社群、投放 ``` ### 输出示例 ```markdown ## 效果归因框架 ### 一、数据口径定义 | 指标 | 定义 | 数据源 | 计算公式 | |------|------|--------|----------| | 活动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" ``` ### 四、争议处理规则 1. **跨渠道争议**：采用时间衰减归因，数据为准 2. **时间范围争议**：以活动配置的起止时间为准 3. **指标定义争议**：以本文档定义为准，变更需双方确认 ``` --- ## 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 } } ``` ### 输出示例 ```markdown ## 需求优先级评估报告 ### 排序结果 | 排名 | 需求名称 | 综合得分 | 业务价值 | 紧急度 | 开发成本 | 风险 | 干系人 | |------|----------|----------|----------|--------|----------|------|--------| | 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 需求：用户增长裂变功能 目标：提升用户邀请率 约束：预算有限，需快速上线 ``` ### 输出示例 ```markdown ## 验收标准文档 ### 需求概述 - **需求名称**：用户增长裂变功能 - **需求来源**：运营团队 - **目标**：提升用户邀请率，实现低成本用户增长 - **上线时间**：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+ 平台分享 | 功能测试 | | 奖励提示 | 奖励到账后弹窗通知 | 功能测试 | | 异常提示 | 网络错误有友好提示 | 异常测试 | --- ### 验收流程 1. **开发自测**：开发完成后自测所有功能点 2. **测试验收**：QA 按验收标准逐项测试 3. **运营验收**：运营在测试环境体验核心流程 4. **灰度验收**：5% 流量灰度，观察数据指标 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) ``` --- ### 四、口径变更流程 1. **提出变更**：任一方发起口径变更申请 2. **双方确认**：运营、产品双方确认新口径 3. **技术评估**：评估数据源、接口变更成本 4. **文档更新**：更新本文档 5. **通知所有干系人**：邮件 + 群公告 --- ### 五、常见口径争议处理 | 争议场景 | 解决方案 | |----------|----------| | 指标定义不一致 | 以本文档为准 | | 数据源不一致 | 以主数据源为准 | | 计算公式有差异 | 以本文档公式为准 | | 历史数据回溯 | 统一按新口径重新计算 | ``` --- ## 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` --- ## 约束 1. 所有文档生成后需双方确认 2. 数据口径变更需走变更流程 3. 优先级计算结果仅供参考，最终由人决策 4. 验收标准必须量化可测试


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)