拿到清单那天，我以为这单稳了
一家做工业设备维保的公司，两百多人，华东。采购负责人发来一个 Excel，附件名叫"需求清单 V3 终版"，30 行，编号 1 到 30，每行后面标了优先级：高、中、低。
我当时的判断很简单：列得这么细，说明他们真想买。列得越细的客户，越知道自己要什么。
这个判断后来被证明是反的。
我们拉了四个人，一周做完 demo。真的是一周，周日晚上十一点还在改一个导出按钮的样式。演示那天会议室坐了六个人，客户那边来了采购、IT，还有两位业务负责人。
我对着屏幕把 30 项往下过。过到第 12 项，采购负责人抬手打断我：这个先跳过。
然后他问了一个问题。
他问的那一项，写在倒数第四行
清单第 27 项，优先级标的是"低"，备注栏只有四个字：权限要细。
开会时他在这四个字上花了四十分钟。不是问我们能不能做——能不能做他们心里有数。他问的是：你们的权限是按角色分，还是按数据分？一个人能不能同时属于两个组？一个人调岗了，历史单据归谁看？
问到第三个问题我才反应过来，这不是功能问题。他们公司销售和售后两拨人，客户信息互相看不见，同一台设备两边各派一次人上门，一年重复出车几百次。谁该看到哪个客户，内部吵了大半年没吵出结果。
他要买的不是一套系统。他要的是一个能替他们做裁决的东西。
剩下 29 项，他后来跟我说了实话：从另外两家厂商的招标文件里抄的。凑够 30 项是为了走内部立项流程——少于 20 项，财务那边不好过。
清单是采购流程的产物，不是需求的产物
这句话我后来在很多场合说过，说完自己也会心虚一下。
因为清单确实有用。它好报价，好交付，好验收。验收的时候双方拿出同一张表，打勾，签字，谁也不欠谁。我们销售也喜欢清单，我自己就催过客户"您把需求整理成表发我"。
问题在于，清单一旦生成，它就自动变成了项目范围。团队照着做，做完交付，客户用不上。三方都没错，但钱花了。
那一周我们做的 demo，29 项是废的。不是说做得不好，是没人看。真正被看的那一项，我们做了个大概，反而是最粗糙的部分。
如果重来一次，我会在拿到那份 Excel 的当天问一句：这 30 项里，如果只能留三项，你留哪三项？
这句话不好问。客户会觉得你不专业，或者觉得你想偷工减料。但它能把人从流程里拽出来，回到"你到底为什么掏这笔钱"。
我也还在发清单
说一件让我自己不太舒服的事。
上个月我们给一个客户做方案，也发了一份功能清单，二十几项，带勾选框。发出去的时候我盯着屏幕看了一会儿——我在做一件我自己刚批评过的事。
后来我想，这两件事不完全一样，但也没有我想的那么不一样。清单作为"确认边界"是必要的，作为"发现需求"是无效的。我们那份清单是用来对齐范围的，前提是前面已经聊过三轮。可我没办法保证每个客户都聊过三轮，也没办法保证我们自己的销售不把清单当成开场白。
所以我现在只留了一条规矩：清单可以发，但发之前必须有一次不带 PPT 的通话，只问三个问题——你现在最难受的是哪件事？这件事一个月发生几次？上次因为这件事吵起来是什么时候？
第三个问题经常问不下去。有人会沉默很久，我也不知道该说什么，就等着。
半年后如果这条规矩自己也变成了流程，我再来写一篇检讨。