流程梳理到PRD与指标体系：业务分析闭环落地指南

做业务分析这行时间长了会发现一个挺尴尬的现象流程图画得漂亮的团队做出来的系统往往没人用PRD写得厚的项目上线后返工最多指标看板做得花哨的部门开会还是靠拍脑袋。这三件事看着是三个工种干的活——业务分析、产品设计、数据度量实际上是一条链上的三个环节任何一环断掉后面全是白做工。我这几年反复在做的就是把流程梳理、PRD撰写、指标体系搭建这三段接起来让它们互相咬合而不是各说各话。这篇东西不讲概念讲的是我实际怎么从一张乱七八糟的业务现状图一步步推到能交付的PRD再推到能拿去做决策的指标口径表中间哪些地方最容易翻车、怎么绕过去。如果你是从业务岗转产品、或者刚接手一个陌生业务域的分析工作又或者你手上正有一个需求方说不清楚要什么、研发说需求写得不清楚的项目下面这些内容应该能直接拿去用。我会尽量把每一步的为什么这么干讲透因为照抄模板谁都会难的是知道什么时候该改模板。1. 流程梳理最容易做成表演先想清楚你在还原哪一段现实我见过太多流程梳理的产出是一张巨大的跨部门泳道图横向十几个角色纵向几十个节点打印出来能铺满一张会议桌。然后呢然后这张图被贴到墙上再也没人看过。问题不在于图画得不对而在于画图的人一开始就没想明白这张图是给谁看的看完要拿它做什么决策。1.1 三种梳理动机决定你该画到多细流程梳理不是目的是手段。手段的精度要由目的倒推。我一般先把动机归成三类精度要求完全不同梳理动机典型场景颗粒度要求产出形态找断点做优化某个环节效率低、错误率高细到单个操作动作和等待时长带时长和频次的现状流程图定系统边界做产品要开发或替换一套系统细到每个节点的输入输出和数据载体带数据流的业务流程图对齐认知做沟通跨部门扯皮、职责不清粗到角色和交接点即可角色职责矩阵加主干流程很多人的错误是拿对齐认知的精度去干定系统边界的活。结果图画得挺大但每个节点下面写的是业务人员处理订单这种话既没说清输入什么、输出什么也没说清处理规则是什么。研发看了等于没看只能再问一遍问到第三遍双方就开始互相抱怨。我的做法是在动手画之前先在文档最上面写一行字这次梳理的产出将被用于____。这句话填不出来就先别画。1.2 从部门视角切换到事件视角新手画流程习惯按组织架构铺开销售部干什么、运营部干什么、财务部干什么。这种画法画出来的其实是组织架构图加了箭头业务的真实流动被切碎了。一个订单从产生到交付中间跨了五个部门你按部门画读者得在图上跳来跳去才能拼出全貌。正确的切法是找业务事件。业务事件指的是某件有明确起点和终点、有可观测结果的事情发生了比如客户提交了一个申请、仓库发出了一批货、一笔款项完成了核销。一个业务事件对应一条端到端的流程这条流程穿过多少个部门不重要重要的是它从哪开始、到哪结束、中间经过哪些状态。我通常会先列出这家公司所有的核心业务事件一般不会超过十个。然后挑其中发生频次最高、或者单次价值最大的两三个作为第一批梳理对象。全量梳理是最蠢的做法投入产出比极低而且梳理周期一长业务本身都变了。提示如果对方说我们业务太复杂了有几十种流程别急着画。先让他按一个月内发生过几次排序前五个通常覆盖了八成的实际业务量。剩下的长尾流程等主干跑通再说。1.3 访谈里最值钱的几类问题流程梳理的信息来源主要是访谈和现场观察。访谈最怕问你们的流程是怎样的对方会给你讲一个理想化的、制度文件上的流程。真实流程永远藏在异常和例外里。我常问的是这几类最近一次让你加班到晚上的事情是什么这个问题能直接挖出流程里最痛的环节而且对方有具体故事不会给你抽象描述。这张表填完之后下一个环节的人会拿它做什么用来确认每个节点的输出是不是真的被消费了。我做过一个项目梳理下来发现有四张报表是填了存档、从来没人看直接砍掉省了大量人力。如果这一步跳过去直接到下一步会出什么问题用来判断节点的必要性。很多节点存在的唯一理由是以前出过事但那个事放到现在的业务量下根本不重要。这个规则是谁定的最近一次改是什么时候用来判断规则的稳定性。规则半年改三次的地方先别做系统化做了就废。同样的信息你们在几个地方各录了一遍重复录入是最高频、最容易量化收益的痛点几乎每个项目都能挖到。现场观察这一步不能省。坐在工位旁边看一个人干半小时活比访谈两小时拿到的东西更准。你会看到他把三个系统来回切、看到一个字段要手工复制粘贴、看到他用微信问同事要数据——这些都不会出现在访谈记录里因为当事人觉得这很正常。1.4 什么时候可以停了流程梳理没有画完的概念只有够用了。我给自己定的收敛标准是三条同一段流程找两个不同岗位的人分别描述画出来的图能对上八成以上。对不上说明你对业务的理解还有盲区。每个节点的输入、输出、处理规则都能用一句话说清楚。说不清的节点就是个黑盒得继续钻。异常分支覆盖到了实际发生频次的八成。不用追求穷举但要覆盖主流异常。剩下的长尾异常在PRD里用兜底规则处理。三条都满足我就停手。继续往下钻的边际收益会迅速下降而且拖太久项目会失去势能——业务方耐心有限你梳理一个月还没动静他们就开始怀疑这事能不能成。2. 把流程里的丑东西揪出来从断点到需求候选流程图本身不值钱值钱的是你在图上标出来的那些问题。我习惯在流程图的每个节点上做四类标记我管它叫流程体检。这一步做完需求候选池基本就自动长出来了不需要坐在会议室里头脑风暴。2.1 四类损耗等待、返工、交接、搬运这四类损耗借的是精益生产的思路搬到业务分析里同样好用因为本质上都是不产生价值的动作。等待指的是一个节点做完下游要等一段时间才能接上。等待的原因通常是审批、排期、人工确认。等待的时间成本最容易被低估因为它散落在每个人身上看起来都不长加起来很吓人。我做过一个采购流程的梳理从申请到下单实际处理时间加起来不到两小时但端到端用了六天。剩下五天半全是等待。返工指的是做完的东西被打回重做。返工率高的节点往往是因为上游给的信息不完整或者校验规则不清。返工是最值得优先解决的因为它同时消耗两个人的时间而且带来情绪成本。交接指的是信息或实物从一个角色转到另一个角色。每一次交接都是一次信息衰减也是一次责任转移。流程里的交接点数量某种程度上就是流程脆弱程度的指标。我的经验是一个端到端流程超过五次交接出错的概率就非常高了。搬运指的是同一条信息在不同系统、不同表格里被反复录入或转移。这是最容易通过系统化解决的一类问题也是ROI最好算的——直接数一下每天录多少次、每次多少秒乘一下就是省下来的人力。把这四类损耗在流程图上用不同标记画出来一张图立刻就有了哪里该改的指向性。这比一张干干净净的流程泳道图有用一百倍。2.2 需求候选池怎么排优先级标完损耗你会得到一堆候选改动点。这时候最忌讳的是哪个呼声高做哪个因为呼声高往往等于嗓门大。我用一个很土但很管用的打分法优先级得分 (影响人数权重 × 发生频次权重 × 痛感权重) / 实现成本权重每个维度按1-5打分权重可以按行业特点调整。比如To B业务里影响人数少但单次金额大就把影响人数换成影响金额内部工具类项目就把频次权重调高。这个公式的价值不在于算出精确分数而在于逼你把痛感和成本分开看。很多需求之所以被排到前面纯粹是因为提需求的人级别高一旦拆成这三个维度打分就会发现它的频次和影响面都很低。表格形式大概长这样实际项目里我会填满二三十行候选改动影响面频次痛感成本得分结论订单信息自动带入554250优先做审批流可视化353315排期靠后历史数据迁移21552暂不做打分完之后还有一步很关键把不做的也写清楚并且写明理由。这条在后面写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-025000 金额 ≤ 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小时滚动主体口径按账号数还是按人数一个人多个账号算一个还是多个状态口径取消的订单算不算退款的算不算测试数据算不算去重口径同一用户一天内多次行为算一次还是多次解决办法只有一个建口径定义表并且把它当成唯一事实来源。表里至少包含这些字段字段说明指标名称统一命名避免中英文混用业务含义一句话说清这个指标衡量什么计算公式分子分母分别是什么用什么算子数据来源来自哪张表、哪个埋点事件过滤条件排除哪些数据测试、内部、异常统计周期日/周/月是否滚动更新时点每天几点出数T1还是实时负责人口径变更找谁确认变更记录什么时候改的、改了什么、为什么这张表的价值不在于好看而在于争议发生时有个裁判。我的做法是所有指标口径变更必须走这张表的变更记录并且同步通知所有使用方。听起来很重但比每次开会吵一小时便宜多了。提示口径表最好和数据看板放在一起看板上每个指标旁边挂一个问号图标点开就是口径定义。这样业务方看数的时候顺手就能确认减少大量这个数怎么来的的沟通。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交付大概三到四周指标体系再花一到两周。时间主要花在访谈和现场观察上文档本身写起来反而不慢——因为前面的信息足够扎实写的时候只是在整理不是在创造。真正容易出问题的从来不是文档写得好不好而是你有没有真的搞清楚业务在干什么、用户卡在哪里、数据能不能反映出来。这三件事想明白了文档只是把它们记下来而已。