这家企业要做内部管理系统，需求文档写了四十六页：审批、考勤、报销、合同、资产、知识库、绩效考核，全都要。负责人说，反正要做一次，索性都做了。我看完的第一反应是，这个项目如果按这个范围做，多半会做不完，或者做完了没人用。
四十六页砍到三个流程
我们把需求按两个维度排：使用频率和出错代价。排下来发现，报销、合同、用章这三件事频率最高、出错代价最大，其他要么很少用，要么现有的表格也能凑合。于是建议第一期只做这三个，其余排到后面看情况。客户犹豫了两天，同意了。
砍掉的部分后来怎么样了
半年后再去看，考勤用了企业微信自带的，资产用了一张共享表格，知识库干脆没人提。三个审批流程跑得很顺，日均处理三十多单，纸质单基本消失了。那些当初一定要的功能，最后自己消失了，因为需求本来就是想象出来的，不是疼出来的。
常斌常说的一句话
我们创始人常斌有句话我记到现在：先聊透需求，再写第一行代码。这话听着像口号，实际是省钱的办法。这个项目如果按四十六页做，预算大概是最终的三倍，工期半年以上，而且大概率一半功能没人用。砍需求不是偷懒，是把钱花在真正疼的地方。
系统上线时留了扩展接口，第二期想加什么都还能加。我现在的做法是每个项目都这样：核心流程做扎实，边界留活口。太原的中小企业变化快，今天的组织架构明年可能就变了，做太死反而要推倒重来，那才是真的浪费。
这个项目交付时按我们的标准给了完整源码和一年维护，客户的技术负责人接手后自己加了两个小功能，没找我们。这件事让我挺高兴：客户能自己往下走，说明交付是干净的，不是把人锁死。这也是我们一直坚持源码交付的原因。
审批系统项目的常见疑问
需求怎么判断该不该做
看频率和出错代价。高频且出错贵的先做，低频的可以用现有工具撑，不必都上系统。
砍需求会不会显得不专业
恰恰相反。能说清为什么不做，比全盘接下更专业，也更能保证项目做成。
后续加功能贵吗
留好扩展点的话不贵，按模块增量开发即可，比推倒重做便宜得多。
总结：需求不是越多越好，是越准越好。砍掉想象出来的，做扎实真正疼的，系统才会被用起来，钱才花得值。