上个月有个客户跟我诉苦，他们花40万找团队做的库存管理系统，上线才两个月，报表模块就卡死，供应商却说是他们数据量太大，得加钱升级服务器。我一看合同，验收条款写的是“系统可运行”，这定义太模糊了，等于白纸黑字留了后门。这种事儿在定制开发里太常见了，今天我就把项目现场踩过的几个坑拿出来说说。
第一坑：需求评审不做细，后面全是补丁
很多企业选型时只看供应商给的方案PPT，里面画得花里胡哨，流程动效一个不少。但真正的需求评审不是看演示，而是坐下来把每个业务场景掰开揉碎。我们去年接一个仓储项目，客户说“要支持波次拣货”，结果需求会没细问，开发到一半才发现他们要的是“边拣边分”而不是“先拣后分”，返工了三个星期。
所以你在选型时，别急着看报价。先要求供应商做一次现场需求调研，至少花半天时间让他们的产品经理跟你的仓库主管直接对话。如果对方只派售前顾问来，不派能写代码的人，那基本可以判断他们后续需求落地会走样。我们内部有个规定，需求文档必须细化到每个页面字段和状态流转，模糊地带全部用“待确认”标出来，绝不带病进入开发。
第二坑：技术栈选得偏，运维都是泪
有个朋友的公司找团队做CRM，开发时用了某个冷门框架，据说是那个开发者的“私藏”。结果项目交付后，原来的开发者离职了，新接手的人看代码看了两天，直接说要全部重写。技术选型不是越新越好，也不是越偏门越显高级，而是要看你们公司能不能养得起、招得到人。
我们在选型清单里会明确要求：后端用Java或.NET，前端用Vue或React，数据库用MySQL或SQL Server，这些都是主流。如果供应商给你推一些听都没听过的组合，你就要多问几句。另外，代码必须要求放到你们自己的Git仓库，而且要有完整的注释和部署文档。别嫌麻烦，这些都是在给未来运维买保险。
第三坑：售后响应没写进合同，出了事就推
定制软件上线后，bug是必然的，但bug修多久、谁负责、费用怎么算，这些不提前约定，后面就是扯皮。我们见过最离谱的案例，一家供应商在质保期刚过一周，就发来一份“年度维护合同”，价格是项目总额的20%，不签就不处理线上故障。客户气得不行，但合同里没写“质保期后维护费如何计算”，只能吃哑巴亏。
所以签合同时，一定要把响应时间写死：核心功能故障，4小时内响应，24小时内给出修复方案；一般bug，48小时内修复。质保期建议至少一年，而且质保期内的bug修复不得额外收费。还有一点，源代码和数据库脚本必须托管在第三方或你们自己手里，别让供应商拿这个当筹码。我们给客户的合同里都有“源代码托管”条款，说白了，就是防止供应商跑路或坐地起价。
几点实在的选型动作
说了这么多，给你几个能直接用的操作：
- 让供应商提供过去两年类似规模项目的合同原件（脱敏），看里面的验收标准和违约条款，比看案例集有用多了。
- 要求供应商提供核心开发人员的社保记录或简历，确认不是临时拼凑的团队。我们有个客户就靠这招，避开了个只有两个兼职开发的小作坊。
- 分阶段付款，别一次性付超过30%首款。按照需求确认、开发中期、测试验收、上线稳定四个节点付款，每个节点都要有可验证的产出物。
- 验收测试别用他们给的测试数据，拿你们自己的真实业务数据跑一遍，最好让业务骨干参与，他们能发现很多专业问题。
最后说一句，选型不是挑贵的，也不是挑便宜的，而是挑一个“能跟你一起把系统用起来”的伙伴。如果对方在售前就敷衍，那交付后更指望不上。你现在就可以做的一件事是，整理一份你们最核心的三个业务痛点，发给候选供应商，让他们拿出针对性的解决方案，而不是通用PPT。