做业务分析这行时间长了，会发现一个挺尴尬的现象：流程图画得漂亮的团队，做出来的系统往往没人用；PRD写得厚的项目，上线后返工最多；指标看板做得花哨的部门，开会还是靠拍脑袋。这三件事看着是三个工种干的活——业务分析、产品设计、数据度量，实际上是一条链上的三个环节，任何一环断掉，后面全是白做工。我这几年反复在做的，就是把流程梳理、PRD撰写、指标体系搭建这三段接起来，让它们互相咬合而不是各说各话。这篇东西不讲概念，讲的是我实际怎么从一张乱七八糟的业务现状图，一步步推到能交付的PRD，再推到能拿去做决策的指标口径表，中间哪些地方最容易翻车、怎么绕过去。
如果你是从业务岗转产品、或者刚接手一个陌生业务域的分析工作，又或者你手上正有一个"需求方说不清楚要什么、研发说需求写得不清楚"的项目，下面这些内容应该能直接拿去用。我会尽量把每一步的"为什么这么干"讲透，因为照抄模板谁都会，难的是知道什么时候该改模板。
1. 流程梳理最容易做成表演：先想清楚你在还原哪一段现实
我见过太多流程梳理的产出是一张巨大的跨部门泳道图，横向十几个角色，纵向几十个节点，打印出来能铺满一张会议桌。然后呢？然后这张图被贴到墙上，再也没人看过。问题不在于图画得不对，而在于画图的人一开始就没想明白：这张图是给谁看的，看完要拿它做什么决策。
1.1 三种梳理动机，决定你该画到多细
流程梳理不是目的，是手段。手段的精度要由目的倒推。我一般先把动机归成三类，精度要求完全不同：
| 梳理动机 | 典型场景 | 颗粒度要求 | 产出形态 |
|---|---|---|---|
| 找断点做优化 | 某个环节效率低、错误率高 | 细到单个操作动作和等待时长 | 带时长和频次的现状流程图 |
| 定系统边界做产品 | 要开发或替换一套系统 | 细到每个节点的输入输出和数据载体 | 带数据流的业务流程图 |
| 对齐认知做沟通 | 跨部门扯皮、职责不清 | 粗到角色和交接点即可 | 角色职责矩阵加主干流程 |
很多人的错误是拿"对齐认知"的精度去干"定系统边界"的活。结果图画得挺大，但每个节点下面写的是"业务人员处理订单"这种话，既没说清输入什么、输出什么，也没说清处理规则是什么。研发看了等于没看，只能再问一遍，问到第三遍双方就开始互相抱怨。
我的做法是，在动手画之前先在文档最上面写一行字：这次梳理的产出，将被用于____。这句话填不出来，就先别画。
1.2 从"部门视角"切换到"事件视角"
新手画流程，习惯按组织架构铺开：销售部干什么、运营部干什么、财务部干什么。这种画法画出来的其实是组织架构图加了箭头，业务的真实流动被切碎了。一个订单从产生到交付，中间跨了五个部门，你按部门画，读者得在图上跳来跳去才能拼出全貌。
正确的切法是找业务事件。业务事件指的是"某件有明确起点和终点、有可观测结果的事情发生了"，比如：客户提交了一个申请、仓库发出了一批货、一笔款项完成了核销。一个业务事件对应一条端到端的流程，这条流程穿过多少个部门不重要，重要的是它从哪开始、到哪结束、中间经过哪些状态。
我通常会先列出这家公司所有的核心业务事件，一般不会超过十个。然后挑其中发生频次最高、或者单次价值最大的两三个作为第一批梳理对象。全量梳理是最蠢的做法，投入产出比极低，而且梳理周期一长，业务本身都变了。
提示：如果对方说"我们业务太复杂了，有几十种流程"，别急着画。先让他按"一个月内发生过几次"排序，前五个通常覆盖了八成的实际业务量。剩下的长尾流程，等主干跑通再说。
1.3 访谈里最值钱的几类问题
流程梳理的信息来源主要是访谈和现场观察。访谈最怕问"你们的流程是怎样的"，对方会给你讲一个理想化的、制度文件上的流程。真实流程永远藏在异常和例外里。
我常问的是这几类：
- "最近一次让你加班到晚上的事情是什么？"这个问题能直接挖出流程里最痛的环节，而且对方有具体故事，不会给你抽象描述。
- "这张表填完之后，下一个环节的人会拿它做什么？"用来确认每个节点的输出是不是真的被消费了。我做过一个项目，梳理下来发现有四张报表是"填了存档、从来没人看"，直接砍掉，省了大量人力。
- "如果这一步跳过去直接到下一步，会出什么问题？"用来判断节点的必要性。很多节点存在的唯一理由是"以前出过事"，但那个事放到现在的业务量下根本不重要。
- "这个规则是谁定的？最近一次改是什么时候？"用来判断规则的稳定性。规则半年改三次的地方，先别做系统化，做了就废。
- "同样的信息，你们在几个地方各录了一遍？"重复录入是最高频、最容易量化收益的痛点，几乎每个项目都能挖到。
现场观察这一步不能省。坐在工位旁边看一个人干半小时活，比访谈两小时拿到的东西更准。你会看到他把三个系统来回切、看到一个字段要手工复制粘贴、看到他用微信问同事要数据——这些都不会出现在访谈记录里，因为当事人觉得"这很正常"。
1.4 什么时候可以停了
流程梳理没有"画完"的概念，只有"够用了"。我给自己定的收敛标准是三条：
- 同一段流程，找两个不同岗位的人分别描述，画出来的图能对上八成以上。对不上说明你对业务的理解还有盲区。
- 每个节点的输入、输出、处理规则都能用一句话说清楚。说不清的节点，就是个黑盒，得继续钻。
- 异常分支覆盖到了实际发生频次的八成。不用追求穷举，但要覆盖主流异常。剩下的长尾异常在PRD里用兜底规则处理。
三条都满足，我就停手。继续往下钻的边际收益会迅速下降，而且拖太久项目会失去势能——业务方耐心有限，你梳理一个月还没动静，他们就开始怀疑这事能不能成。
2. 把流程里的"丑东西"揪出来：从断点到需求候选
流程图本身不值钱，值钱的是你在图上标出来的那些问题。我习惯在流程图的每个节点上做四类标记，我管它叫"流程体检"。这一步做完，需求候选池基本就自动长出来了，不需要坐在会议室里头脑风暴。
2.1 四类损耗：等待、返工、交接、搬运
这四类损耗借的是精益生产的思路，搬到业务分析里同样好用，因为本质上都是"不产生价值的动作"。
等待指的是一个节点做完，下游要等一段时间才能接上。等待的原因通常是审批、排期、人工确认。等待的时间成本最容易被低估，因为它散落在每个人身上，看起来都不长，加起来很吓人。我做过一个采购流程的梳理，从申请到下单，实际处理时间加起来不到两小时，但端到端用了六天。剩下五天半全是等待。
返工指的是做完的东西被打回重做。返工率高的节点，往往是因为上游给的信息不完整，或者校验规则不清。返工是最值得优先解决的，因为它同时消耗两个人的时间，而且带来情绪成本。
交接指的是信息或实物从一个角色转到另一个角色。每一次交接都是一次信息衰减，也是一次责任转移。流程里的交接点数量，某种程度上就是流程脆弱程度的指标。我的经验是：一个端到端流程超过五次交接，出错的概率就非常高了。
搬运指的是同一条信息在不同系统、不同表格里被反复录入或转移。这是最容易通过系统化解决的一类问题，也是ROI最好算的——直接数一下每天录多少次、每次多少秒，乘一下就是省下来的人力。
把这四类损耗在流程图上用不同标记画出来，一张图立刻就有了"哪里该改"的指向性。这比一张干干净净的流程泳道图有用一百倍。
2.2 需求候选池怎么排优先级
标完损耗，你会得到一堆候选改动点。这时候最忌讳的是"哪个呼声高做哪个"，因为呼声高往往等于嗓门大。我用一个很土但很管用的打分法：
优先级得分 = (影响人数权重 × 发生频次权重 × 痛感权重) / 实现成本权重每个维度按1-5打分，权重可以按行业特点调整。比如To B业务里影响人数少但单次金额大，就把影响人数换成影响金额；内部工具类项目就把频次权重调高。
这个公式的价值不在于算出精确分数，而在于逼你把"痛感"和"成本"分开看。很多需求之所以被排到前面，纯粹是因为提需求的人级别高，一旦拆成这三个维度打分，就会发现它的频次和影响面都很低。
表格形式大概长这样，实际项目里我会填满二三十行：
| 候选改动 | 影响面 | 频次 | 痛感 | 成本 | 得分 | 结论 |
|---|---|---|---|---|---|---|
| 订单信息自动带入 | 5 | 5 | 4 | 2 | 50 | 优先做 |
| 审批流可视化 | 3 | 5 | 3 | 3 | 15 | 排期靠后 |
| 历史数据迁移 | 2 | 1 | 5 | 5 | 2 | 暂不做 |
打分完之后还有一步很关键：把"不做"的也写清楚，并且写明理由。这条在后面写PRD的时候能省掉大量扯皮。
2.3 有些环节根本不该被产品化
这是我踩过最深的坑之一。刚做产品那几年，看到流程里有手工活就想做成系统功能，觉得这是价值创造。后来发现，做出来的功能一半以上是白做的。
不该产品化的典型情况有这么几种：
- 频次极低但逻辑极复杂。比如一年发生两次的特殊结算，规则涉及十几个条件分支。做成系统功能，开发成本高、维护成本高、还容易出bug，不如保留人工处理加一个标准模板。
- 规则还在剧烈变化。业务的规则半年改一次的地方，任何系统化都是在给自己挖坑——你做完它就变了，改一次的成本可能比重新做还高。这种地方正确的做法是做"可配置"，或者干脆先不做，等规则稳定。
- 本质是组织问题，伪装成系统问题。这条最要命。两个部门互相不配合，导致流程卡住，需求方会说"你做个系统让他们必须走这个流程"。系统能强制流程，但强制不了配合。这种情况下做出系统，卡点会从流程里转移到系统外，问题一点没解决。
- 涉及线下实物或线下判断。验货、面谈、现场勘察这类环节，强行线上化往往只是把线下动作搬到线上重做一遍，效率没提升，还多了一层录入负担。
判断标准其实很简单：这个环节的问题，是"信息不流通"造成的，还是"人不想干"造成的？前者适合产品化，后者产品化没用。我在评审需求时经常用这句话把一些需求挡回去，大部分需求方听完会愣一下，然后承认是后者。
2.4 从流程节点到功能模块的映射
需求候选确定之后，要做一次映射：每个需求点落在哪个流程节点上，对应PRD里的哪个功能模块。这一步不做，PRD写起来会散。
我的做法是拉一张二维表，行是流程节点，列是功能模块，交叉格填这个模块在这个节点上要干什么。这张表有个隐藏的好处：空白格会暴露你的功能覆盖缺口。你会看到某个节点上三个模块都有活干，另一个节点上一个模块都没有——后者要么是漏了，要么是确实不需要系统介入，两种情况都得确认一下。
举个具体的例子，一个审批类业务的映射大概是这样：
| 流程节点 | 表单模块 | 流转模块 | 通知模块 | 归档模块 |
|---|---|---|---|---|
| 提交申请 | 填写、校验、暂存 | 发起流程 | 提交成功提示 | - |
| 主管审批 | 只读展示 | 同意/驳回/加签 | 待办推送 | - |
| 财务复核 | 只读展示+补充字段 | 同意/驳回 | 待办推送 | - |
| 完成归档 | - | 流程结束 | 结果通知 | 生成归档记录 |
这张表写完，PRD的章节结构基本就定下来了。而且跟研发过方案的时候，直接拿这张表讲，比讲一百页文档高效。
3. PRD的骨架：研发能照着做，测试能照着验
PRD这东西，写得厚不是本事，写得让人不用问问题才是本事。我评判一份PRD合不合格，标准很粗暴：研发看完之后，提问的数量能不能控制在一轮以内，而且问的都是真问题（业务规则层面）而不是"这里到底什么意思"。
3.1 第一屏就要把结论说完
很多PRD开头写三段"项目背景"，讲行业趋势、讲公司战略，写完两页还没说清楚这个功能是干嘛的。研发看了只想跳过。
我现在的写法是，文档第一屏必须包含这六项，一屏之内说完：
- 一句话说明：这个功能是什么，用大白话，不超过三十个字。
- 解决什么问题：对应流程梳理里标出来的哪个损耗，影响多少量级。
- 本次做什么：范围清单，条目化。
- 本次不做什么：同样条目化，这一项的重要性不亚于上一项。
- 关键决策：涉及方案取舍的地方，写清楚选了A不选B的原因。
- 依赖与风险：依赖哪些外部系统、哪些数据、哪些人的配合。
"本次不做什么"这一节，是我从无数次扯皮里总结出来的救命条款。你不写，评审会上一定有人问"那XX场景支持吗"，然后你现场解释、现场承诺，最后范围失控。写下来之后，越界需求就有了挡箭牌：这个在"不做"清单里，我们下一期评估。
3.2 三层流：主流程、分支流、异常流
功能描述部分，最忌讳的是只写主流程。主流程是理想情况，写起来最轻松，但开发和测试真正花时间的是分支和异常。
我的写法是分三层：
主流程用编号步骤写，每一步写清楚"谁在什么条件下做什么操作，系统产生什么结果"。这里的关键是"条件"和"结果"必须具体，不能写"系统进行校验"，要写"系统校验A字段非空、B字段在有效期内、C字段不与已有记录重复，任一不通过则在对应字段下方显示红色提示，提示文案见附录"。
分支流按业务规则组织。我把分支整理成规则表，比用文字描述清楚得多：
| 规则编号 | 触发条件 | 系统行为 | 用户可见反馈 |
|---|---|---|---|
| R-01 | 金额 ≤ 5000 | 自动通过，跳过主管审批 | 状态直接变为已通过 |
| R-02 | 5000 < 金额 ≤ 50000 | 流转至主管审批 | 待办推送至主管 |
| R-03 | 金额 > 50000 | 主管审批后追加财务复核 | 两级待办依次推送 |
异常流是最容易漏的，我给自己定了一个检查清单，每次写PRD都要过一遍：
- 重复提交（用户连点两次、网络重试）
- 并发冲突（两个人同时改同一条记录）
- 超时（审批超过N天未处理）
- 数据不合法（脏数据、历史数据字段缺失）
- 依赖系统不可用（接口挂了、第三方超时）
- 权限变更中途发生（审批人离职、调岗）
- 流程中途撤回或作废
这七条基本覆盖了实际项目里八成的异常。每一条在PRD里都要写明"系统怎么表现、用户看到什么、数据怎么处理"。漏掉任何一条，上线后大概率会有人在群里@你。
3.3 状态机和字段字典：返工率最高的两个地方
如果要评PRD里最容易出问题的两节，我一定选状态机和字段字典。这两块写不清楚，开发阶段必然返工，测试阶段必然扯皮。
状态机要写成迁移表，不能只画个图。图能表达"有哪些状态"，但表达不了"在什么条件下从哪到哪"。表长这样：
| 当前状态 | 触发事件 | 前置条件 | 目标状态 | 副作用 |
|---|---|---|---|---|
| 草稿 | 提交 | 必填项齐全 | 待审批 | 生成审批实例、推送待办 |
| 待审批 | 主管通过 | 当前审批人为主管 | 待复核 | 记录审批时间、推送下一节点 |
| 待审批 | 驳回 | 无 | 已驳回 | 记录驳回理由、通知提交人 |
| 待审批 | 撤回 | 操作人为提交人且下一节点未处理 | 草稿 | 终止审批实例 |
"副作用"这一列很多人不写，但它恰恰是开发最需要的——状态变了之后要发通知、要写日志、要触发下游，这些都写清楚，开发才不会漏。
字段字典我要求精确到可以直接建表。字段名、类型、长度、是否必填、取值范围、默认值、数据来源、校验规则、示例值，一个都不能少。看起来啰嗦，但这是唯一能避免"开发理解的字段含义和业务理解的不一样"的办法。
特别提醒一句：枚举值一定要在PRD里定死，并且预留扩展位。我见过太多项目上线三个月就要加一个新状态，结果发现数据库字段长度不够、前端写死了判断逻辑、报表口径也得跟着改。一开始就在设计上留好扩展，成本几乎为零，事后补的成本是它的几十倍。
3.4 权限和数据可见性：最容易整节漏掉的部分
权限这块，十个PRD里有六个是只写一句"按角色控制权限"就带过的。这句话等于没写。开发和测试看到这句话，只能按自己的理解实现，上线后必然出问题——要么该看的看不到，要么不该看的看到了，后者更麻烦。
我要求PRD里必须有一张权限矩阵，而且是"角色 × 操作 × 数据范围"三维的：
| 角色 | 可执行操作 | 数据可见范围 | 字段级限制 |
|---|---|---|---|
| 申请人 | 创建、编辑草稿、提交、撤回 | 仅本人创建 | 全部可见 |
| 主管 | 审批、转交 | 本部门全部 | 隐藏薪酬相关字段 |
| 财务 | 复核、导出 | 全公司 | 隐藏个人联系方式 |
| 管理员 | 全部 | 全部 | 全部可见 |
字段级限制这一列是关键。很多业务场景里，同一个单据不同角色能看到的字段是不一样的，这个不写清楚，开发很可能就全放开了。
还有一个容易被忽略的点：权限变更的历史记录。审批人中途调岗了，之前他审批过的记录归属怎么算，这个在PRD里要明确。我一般规定"审批记录跟随当时角色，不随人员变动而变"，避免历史数据被追溯修改。
3.5 验收标准：可测试性优先
PRD最后一部分是验收标准。这块我见过两种极端：一种是完全不写，让测试自己悟；另一种是写成"系统运行稳定、用户体验良好"这种没法测的废话。
我的写法是把验收标准写成可执行的检查项，每一条都能对应到一个具体的操作和预期结果。比如：
- 提交一份金额为6000的申请，主管账号应在10秒内收到一条待办，待办内容包含申请人、金额、事由三个字段。
- 对同一份草稿连续点击提交按钮五次，系统应只生成一条审批实例。
- 主管驳回后，申请人修改并重新提交，审批流程应从第一节点重新开始，历史审批记录保留且可见。
- 导出功能在数据量达到1万条时，响应时间不超过30秒，超出时给出明确提示。
这种写法的好处是，测试人员可以直接把它转成测试用例，不需要再来问你。而且写的过程中你会发现一些自己也没想清楚的地方——这就是PRD最大的价值，它逼你把所有模糊地带都想明白。
4. 指标体系：不是给汇报用的，是给决策用的
流程梳理清楚了，PRD也写完了，很多人到这就收工了。但系统上线只是开始，接下来要回答的问题是：这东西到底有没有用？这个问题不靠感觉回答，靠指标。
我见过太多指标体系最后沦为汇报材料：每个月出一张漂亮的大盘，数字涨了说战略正确，跌了说市场环境不好。这种指标体系是没有决策价值的。有价值的指标体系，必须能回答"下一步该做什么"。
4.1 北极星指标的三个淘汰条件
选北极星指标，大部分团队的做法是"老板最关心什么就选什么"。这个做法的问题是，老板关心的往往是结果指标（营收、利润），而结果指标离一线操作太远，团队做任何动作都看不到它的变化，时间长了就没人看了。
我给北极星指标设了三个淘汰条件，三个都过才算合格：
第一条，不可被单点操纵。如果一个指标靠一个动作就能刷上去，那它一定会被刷。比如"注册用户数"，投一波广告就能涨，但它不代表任何真实价值。真正好的指标，提升它必须做对一系列事情，走不了捷径。
第二条，能反映用户获得的价值。指标要指向"用户因为用了这个产品而变得更好"，而不是"我们做了多少事"。这两个经常被混淆：功能上线数、需求交付数、系统调用量，这些都是"我们做了多少"，不是"用户获得了什么"。
第三条，团队能影响它。这条最实际。如果团队做了一堆优化，指标纹丝不动，那这个指标就不该是团队的目标，它可能是公司层面的战略指标，但落不到这个团队头上。
举个对比：
| 候选指标 | 可操纵性 | 反映用户价值 | 团队可影响 | 结论 |
|---|---|---|---|---|
| 页面访问量 | 高（刷量即可） | 弱 | 强 | 淘汰 |
| 功能使用次数 | 中 | 中 | 强 | 备选 |
| 任务一次通过率 | 低 | 强 | 强 | 采用 |
| 季度营收 | 低 | 中 | 弱 | 作为结果指标观察，不作北极星 |
"任务一次通过率"这一类指标有个共同特点：它衡量的是"用户是不是顺利把事办成了"，只要流程里有任何一个环节设计得不好，这个数就上不去。这种指标天然把团队的努力方向拉到了正确的地方。
4.2 指标拆解树：从结果指标拆到能动手的粒度
北极星指标是结果，结果不能直接指导行动。中间需要一层拆解，把结果拆成可干预的过程指标。
拆解的基本思路是找乘法关系。业务上的结果指标，绝大多数可以拆成几个因子的乘积或加和。比如一个交易类的业务：
成交额 = 访问用户数 × 下单转化率 × 客单价 下单转化率 = 有效浏览率 × 加购率 × 支付成功率拆到最后一层，每个因子都要能对应到具体的产品动作。比如"支付成功率"对应的是支付流程的顺畅程度，"加购率"对应的是商品详情页的说服力。这样拆完之后，团队每次做优化，都能在树上找到自己的位置，也知道该看哪个数。
拆解树有两个常见错误：
一是拆得太细。见过有人拆到第五层，十几个叶子节点，每个节点都要单独埋点、单独出报表。这种做法维护成本极高，而且叶子节点之间的相关性很强，看一个就够了。我的经验是，三层足够，最多四层。
二是拆出了不可干预的因子。比如把成交额拆成"市场需求 × 市场份额 × 客单价"，看起来很对，但"市场需求"团队完全影响不了，这种因子留在树上只会让人沮丧。拆解树的每一层，都应该问一句：这个数变了，我们能知道是哪个动作导致的吗？
4.3 口径定义表：同名不同义的灾难现场
这是我在实际项目里见过最多、后果最严重的问题：同一个指标名，两个团队算出来的数差了一大截，然后开会花一小时争论谁对谁错，最后发现两边定义根本不一样。
最常见的是这几种分歧：
- 时间口径：按下单时间算还是按支付时间算，按自然日还是按24小时滚动
- 主体口径：按账号数还是按人数，一个人多个账号算一个还是多个
- 状态口径：取消的订单算不算，退款的算不算，测试数据算不算
- 去重口径：同一用户一天内多次行为算一次还是多次
解决办法只有一个：建口径定义表，并且把它当成唯一事实来源。表里至少包含这些字段：
| 字段 | 说明 |
|---|---|
| 指标名称 | 统一命名，避免中英文混用 |
| 业务含义 | 一句话说清这个指标衡量什么 |
| 计算公式 | 分子分母分别是什么，用什么算子 |
| 数据来源 | 来自哪张表、哪个埋点事件 |
| 过滤条件 | 排除哪些数据（测试、内部、异常） |
| 统计周期 | 日/周/月，是否滚动 |
| 更新时点 | 每天几点出数，T+1还是实时 |
| 负责人 | 口径变更找谁确认 |
| 变更记录 | 什么时候改的、改了什么、为什么 |
这张表的价值不在于好看，而在于争议发生时有个裁判。我的做法是，所有指标口径变更必须走这张表的变更记录，并且同步通知所有使用方。听起来很重，但比每次开会吵一小时便宜多了。
提示：口径表最好和数据看板放在一起，看板上每个指标旁边挂一个问号图标，点开就是口径定义。这样业务方看数的时候顺手就能确认，减少大量"这个数怎么来的"的沟通。
4.4 埋点方案：指标能不能落地，八成看这一步
指标定义得再漂亮，没有数据采集就是空的。埋点这块的坑，我总结下来主要是三个。
第一个坑是事件命名混乱。同一个动作，有人叫click_submit，有人叫submit_click，还有人叫btn_submit_1。三个月后没人记得这些事件是干嘛的。我现在强制要求事件命名遵循"对象_动作"的格式，比如order_submit、order_cancel，属性名统一用下划线，并且所有事件必须登记在事件字典里，没登记的不允许上线。
第二个坑是属性缺失。事件采了，但关键属性没带上，导致后面想按维度拆分拆不了。比如提交事件只记了"提交了"，没记"提交时表单填了几项""是不是修改后重新提交"，那你想分析失败原因就无从下手。我的原则是：埋点的时候宁可多带属性，也不要事后补。多带属性成本很低，事后补要重新发版，可能要等一个月。
第三个坑是去重和异常处理没做。用户网络不好连点三次，埋点上报三条，数据就虚高了。这类问题在数据量小的时候看不出来，量一大就非常明显。方案上要么在前端做防抖和幂等，要么在数据侧按会话ID去重，两者选一个，但必须明确写进方案里。
一个典型的埋点方案长这样：
{ "event": "order_submit", "description": "用户点击订单提交按钮", "trigger": "点击后立即上报，失败重试最多3次", "properties": { "order_id": "string，订单唯一标识", "amount": "number，订单金额，单位元", "item_count": "number，商品件数", "is_modified": "boolean，是否为修改后重新提交", "form_duration": "number，表单填写耗时，单位秒", "source": "string，来源渠道" }, "dedup_key": "order_id" }这个方案里，dedup_key就是去重依据，form_duration是为了后面分析"填写耗时是否影响转化"，is_modified是为了区分首次提交和返工提交。每一个属性都有明确的分析用途，不是随便加的。
4.5 指标也要有生命周期
指标不是定了就一直用。业务变了，指标的意义也会变。我一般按季度做一次指标盘点，把指标分成四类处理：
- 核心指标：持续跟踪，口径冻结，变更要走审批。
- 观察指标：还在验证阶段，允许调整口径，不对外发布。
- 下线指标：已经失去决策价值，但保留历史数据，不再出现在看板上。
- 待建指标：业务上需要但还没法采集的，列入埋点需求池。
下线指标这件事，很多团队不敢做，觉得删了可惜。但看板上的指标越多，注意力越分散，真正重要的指标反而被淹没。我做过一次清理，把一个看板从四十多个指标砍到十二个，使用率反而上去了——因为大家终于能一眼看完了。
5. 三张图对不齐的时候：流程、PRD、指标的交叉校验
前面三块分开做，各自都能做得挺像样。但真正决定项目质量的，是这三块能不能对上。我一般在上线前做两轮交叉校验，能捞出一批隐藏问题。
5.1 拿流程节点反查指标覆盖度
做法很简单：把流程梳理出来的节点列成一列，把指标体系里的指标列成一行，交叉格里填"这个指标能不能反映这个节点的表现"。填不出来的格子，就是覆盖缺口。
比如一个审批流程，节点有"提交、主管审批、财务复核、归档"，指标有"提交量、平均审批时长、一次通过率、驳回率"。交叉下来你会发现：
| 流程节点 | 提交量 | 平均审批时长 | 一次通过率 | 驳回率 |
|---|---|---|---|---|
| 提交 | 覆盖 | 部分 | - | - |
| 主管审批 | - | 覆盖 | 部分 | 覆盖 |
| 财务复核 | - | 覆盖 | 部分 | 覆盖 |
| 归档 | - | - | - | - |
一眼能看出问题：归档节点完全没有指标覆盖。归档看起来是个收尾动作，但如果归档失败率高，会直接影响后续的查询和审计。这种缺口不查一遍是发现不了的。
反过来的情况也要注意：某个节点挂了五六个指标，那多半是过度度量，实际决策时根本看不了那么多。这时候该做减法。
5.2 拿指标反查PRD的功能完整性
这一轮是从数据反推功能。思路是：每一个指标，都必须有对应的产品功能在影响它；如果没有，要么是指标没用，要么是功能缺失。
举个实际例子。指标里有一条"任务一次通过率"，要提升它，PRD里必须得有对应的功能设计：提交前的完整性校验、常见错误的实时提示、驳回理由的结构化记录。如果PRD里这些都没有，那这个指标就是空中楼阁——团队知道要提升它，但没有任何抓手。
反过来，PRD里有一个功能，但没有任何指标能反映它的效果，那这个功能的存在价值就存疑。我见过不少"做了但没人知道有没有用"的功能，追根究底就是设计的时候没想清楚怎么衡量。
这两轮校验做完，通常会改一批PRD，也会砍一批指标。这个过程有点痛苦，但比上线后发现"不知道该看什么数"要好得多。
5.3 上线后的复盘节奏
系统上线不是终点。我一般会安排三个时间点的复盘：
上线后第一周，看的是技术指标：错误率、响应时间、流程中断率。这一周不看业务指标，因为数据量太小，波动大，看了容易误判。
上线后第一个月，看的是采纳指标：目标用户里有多少人真的在用、用了多少次、完成率如何。这个阶段最常发现的问题是"功能做了但没人用"，原因往往是培训不到位或者入口太深。
上线后第一个季度，才看效果指标：流程时长有没有缩短、返工率有没有下降、一次通过率有没有提升。这个阶段的数据才有统计意义。
三个阶段的关注点完全不同，混在一起看就会得出错误结论。我见过有团队上线三天就看效果指标，发现没变化就开始怀疑方案，其实只是还没到能看出效果的阶段。
6. 几个我踩过的坑，以及当时的处理方式
说几个具体的，都是真实项目里发生过的，改头换面讲一下。
6.1 流程梳理阶段：把"应该怎样"当成了"实际怎样"
有个内部流程优化的项目，我前期访谈了六个岗位，每个人都跟我讲了一套流程，我整理出来发现居然能对上。当时还挺得意，觉得梳理得很清楚。结果开发做完第一版给业务方演示，业务方说"这不是我们实际干活的流程"。
后来去现场蹲了两天才发现问题：制度上的流程确实是我画的那样，但实际操作中，因为某个系统不好用，大家自己建了个共享表格在系统外面走，等于是有两套流程并行。访谈的时候没人提这个表格，因为在他们看来那是"临时凑合"，不算正式流程。
教训是：访谈只能拿到"制度流程"，现场观察才能拿到"实际流程"。这两者之间的差距，往往就是最有价值的需求点。现在我一定会要求至少半天现场观察，而且专门问"有没有什么表格是你们自己在用的"。
6.2 PRD阶段：边界条件没写清，上线后数据错乱
一个数据录入类的功能，PRD里主流程写得很细，但有一个边界没考虑到：同一个业务对象，允许被多个用户同时编辑吗？
当时默认是允许的，因为没写就是默认。结果上线后出现了一种情况：两个人同时打开同一条记录，A改了字段1保存，B改了字段2保存，B的保存把A的修改覆盖掉了。数据看起来没报错，但错得很隐蔽，过了两周才被业务发现。
修复方案是加了乐观锁（版本号机制），保存时校验版本号是否变化，变了就提示"数据已被他人修改，请刷新后重试"。技术上不难，但已经产生了一批脏数据，清洗花了不少时间。
这件事之后，我在PRD的异常流清单里加了一条固定项：并发编辑处理。而且明确规定，凡是涉及多人协作的数据对象，必须写明并发策略，是加锁、是后写覆盖、还是合并，三者选一，不能空着。
6.3 指标阶段：口径没对齐，两个团队的数差了30%
最典型的一次，两个团队分别做报表，同一个"月度活跃用户数"，一个算出120万，一个算出85万。开会吵了半天，最后查出来是两个原因叠加：
一是去重逻辑不同。A团队按账号去重，一个人有两个账号算两个；B团队按人去重，通过实名信息合并。二是时间口径不同。A团队按自然月，B团队按滚动30天。
这两个差异单独看都不大，叠加起来就是30%的差距。
处理方式是建了口径定义表，并且规定所有对外发布的指标必须引用口径表里的标准定义，不允许自行计算。同时对已有的报表做了一次全面盘点，把口径不一致的十几张报表全部重做。
这个过程挺痛苦的，但从那以后，跨部门对数的时间成本下降了很多。我现在做任何项目，只要涉及数据，第一件事就是把口径表建起来，哪怕一开始只有五六个指标。
6.4 一个通用教训：别在梳理阶段就承诺方案
这条是我自己的毛病，也是很多做分析的人的通病。梳理流程的时候，业务方会不断问"这个你们打算怎么解决"，你一激动就说"这个我们做个自动带入就行"。听起来是积极回应，实际上给自己挖了坑——方案还没验证，成本还没评估，你就已经承诺了。
后来我改成固定话术："这个点我记下来了，具体怎么做要看跟其他几个点一起评估，下次沟通给你方案。"把承诺推迟到方案成型之后，既不失礼，也给自己留了余地。
7. 一些可以直接拿去用的做法
前面讲了不少方法论，这里集中说几个我这几年固定下来的操作习惯，都是些不起眼但很省事的细节。
流程图上每个节点都标上"数据来源"。这个节点用到的信息，是从哪个系统来的、还是人工填的、还是从别的表抄的。标完之后，你对系统改造的难度就有了直觉——数据来源全是人工填的节点，改造难度最高。
PRD里所有涉及数量的地方都写具体数字。不要写"支持大量数据"，写"支持单次导入不超过5万行，超出时分批处理并显示进度"。不要写"响应要快"，写"列表页首屏加载不超过2秒"。模糊的形容词是返工的高发区。
每个需求都写清楚"如果不做会怎样"。这一条能挡掉大量伪需求。如果一个需求说不出不做的后果，那它大概率不重要。
指标看板上每个数字都标注更新时间和数据范围。业务方看到数字的第一反应往往是"这个数什么时候的、包含哪些数据"，标注清楚能省掉一半的解释工作。
每次评审会结束后，当天就把结论写成文档发出去。会上达成的口头共识，过三天就会有两种版本的解释。当天发出去，谁有异议当场提，过了就不再改。
保留一版"废弃方案"文档。做过的方案取舍、为什么否掉某个方向，都记下来。半年后有人重新提起同一个方案，你直接翻文档给他看，省得重新论证一遍。
这套流程跑顺之后，一个中等复杂度的业务分析项目，从梳理到PRD交付大概三到四周，指标体系再花一到两周。时间主要花在访谈和现场观察上，文档本身写起来反而不慢——因为前面的信息足够扎实，写的时候只是在整理，不是在创造。
真正容易出问题的从来不是文档写得好不好，而是你有没有真的搞清楚业务在干什么、用户卡在哪里、数据能不能反映出来。这三件事想明白了，文档只是把它们记下来而已。
