先别急着画原型，我那次差点被“客户成功看板”坑死
2023年4月11日，我在一家做跨境客服SaaS的40人小公司救火。会议室叫“鼓浪屿”，白板上写着“客户成功看板V1”，老板说很简单，就是把工单、续费、客户健康度放一起。 我第一次评审开了2小时17分，第二次1小时46分，第三次43分钟，还是没结论。 不是大家不聪明，是每个人嘴里的“看板”不一样：销售要预警，客服主管要排班，客户成功经理想少点Excel。 后来上线30天，使用率23%，二次留存11%。我盯着Metabase埋点，才发现第一版做了18个字段、6个筛选、4种角色权限，却没人定义“什么样算失败”。 从那次以后，我不再把需求分析当成“把用户说的写下来”，而是先写清楚：不做什么、谁拍板、失败长什么样。
大厂方法论和小公司现实，差的不是工具，是“需求债务”有没有标价
大厂讲用户研究、数据看板、A/B测试，听起来很完整；小公司往往只有老板一句话、客户群截图、三张Excel。 但两边本质一样：需求分析不是消灭不确定性，而是给不确定性标价。 一个没写清的字段，可能就是后期3天联调；一个没定义的权限边界，可能让客服看到全量客户续费金额。 我现在的做法是建一张“需求债务表”，列：假设、影响角色、验证方式、最晚确认日、如果错了谁背锅。 比如“工单列表响应<1.5秒”是假设，“导出上限5000行”是假设，“管理员能改状态”也是假设。 每张表最多留7行，超过7行说明这个需求太大，先砍到能两周验证的粒度。 这比一上来画高保真原型有用，因为原型容易让人讨论按钮颜色，而不是业务规则。
我用的7步土办法：反需求清单、3问访谈、7项评审、RICE加赖账成本
第1步，先写“反需求清单”：这版不做什么，比如不做自定义报表、不做移动端、不做多语言。 第2步，访谈前15分钟发3个问题：上个月最烦的3件事？现在怎么绕过？如果系统明天消失，哪件事最痛？ 第3步，把需求翻译成行为指标：每天操作次数、平均耗时、错误率、需要几个人复核。 第4步，评审只查7项：目标、反目标、角色、数据边界、异常流、验收口径、谁拍板。 第5步，优先级不只用RICE，我加一个“赖账成本”：以后改口成本高不高，高就往前排。 第6步，PRD里放参数表：字段18个还是9个、并发50还是500、响应1.5秒还是3秒、角色4个还是2个、埋点9个还是3个。 第7步，上线后第7天看使用率，第30天看二次留存，不达标就开复盘会，不骂人，只改假设。
一个具体对比：同样做“导出”，两种需求写法差了多少
模糊写法是：“客户成功要能导出工单数据，方便分析。”这句话打印出来不到20个字。 结果开发问了11个问题：导哪些字段？时间范围默认几天？上限多少行？谁有权限？空值怎么显示？失败怎么办？ 我后来改成参数化写法：导出字段12个，默认最近30天，最大5000行，仅主管和管理员，异步生成CSV，失败重试2次，通知站内信。 验收标准也写死：1000行数据在8秒内生成，5000行在40秒内生成，文件名含日期和筛选条件哈希。 这还没完，我要求埋3个事件：点击导出、导出成功、导出失败，失败原因分4类：权限、超时、空数据、系统错误。 你看，需求分析不是写得更长，而是把“到时候再说”变成“现在能测”。
最后说个可能挨骂的观点：需求分析的第一交付物不是PRD
我现在的第一交付物是一页“决策记录”，第二交付物才是PRD，原型排第三。 决策记录里必须回答：谁提的、解决谁的什么问题、不解决会怎样、什么时候必须上线、失败指标是什么。 如果这页写不出来，说明需求还没分析完，画再多流程图也是自我感动。 我也不是每次都做得好，上个月还把一个“批量分配”需求漏了异常流，导致客服把200个工单分给了离职账号。 所以别迷信完整方法论，先抓住三个动作：写反需求、标需求债务、定失败指标。 这三个动作做完，再去开评审会，通常能少扯1小时，开发也能早两天动手。