去年冬天，一个做汽配的客户找我聊第三次。前两次他找了两家外包，报价差了将近一倍，功能列表看起来差不多。第一家做到第三个月，项目经理换了人，需求文档里“库存预警”四个字，开发理解成了低于安全库存发邮件，客户想要的是按车型、按供应商动态算补货点。扯皮两个月，项目停了。他问我：怎么在签合同之前，看出哪家能真正把东西做出来？
先看需求文档，别先看报价
很多老板拿到报价单，第一反应是横向比价格、比功能项数量。这个顺序是反的。功能列表谁都能写，“订单管理”“报表导出”这种词，写十行和写一行没区别。真正要看的，是对方有没有把你的业务场景拆到可执行的程度。
我见过一份靠谱的需求文档，光“审批流”就写了四页：谁发起、什么条件下自动跳过、驳回后回到哪一步、超时多久升级、手机端能不能批。对应报价自然不便宜，但开发排期能精确到周。
反过来，如果对方只给你一张 Excel，功能项后面跟个总价，你就要小心了。这不是报价，这是猜谜。后期每一处模糊，都是加钱和延期的理由。
所以选型第一步：让对方把需求说明书写出来，哪怕收几千块咨询费。愿意先花时间拆需求的团队，通常也更愿意对结果负责。
演示环节，看的是节奏不是界面
第二家外包公司演示时，界面做得挺漂亮，点哪哪响应。客户很满意。但我问了一句：如果两个仓库同时出库同一批货，系统怎么处理？对方愣了一下，说“这个可以后面加锁”。这就是典型的演示型产品——把静态页面包装成能跑的系统。
真正做过项目的团队，演示时会有意暴露边界。比如他们会主动说：“这个模块我们上周刚处理过一个并发问题，目前的方案是队列排队，极端情况下会延迟3秒。”这种话听着不完美，但说明他们踩过坑。
我的经验是，演示时你挑三个最刁钻的业务场景问：退货怎么冲减、跨月对账怎么处理、权限临时授权怎么收回。如果对方能当场画出流程，或者坦诚说“这个要回去确认”，都比含糊点头强。
另外，别只看演示环境。要求看他们正在维护的某个真实项目的后台，看日志、看工单记录。一个项目上线后三个月内的bug列表，比任何PPT都有说服力。
合同里最该抠的是维护条款
大部分定制开发合同，验收标准写得很细，维护条款就一句话：“维护一年、不另收费”。这一句话，后面能扯出无数麻烦。
什么叫维护？改个按钮颜色算不算？加一个报表算不算？服务器迁移算不算？我见过一个客户，上线后想把订单导出从Excel换成PDF，外包说这是新需求，报价八千。客户觉得被宰，外包觉得委屈——合同里没写。
比较务实的做法是，把维护分成两类：缺陷修复和功能调整。缺陷修复不另收费，响应时间写清楚，比如“工作时间内4小时响应，24小时给出方案”。功能调整则约定一个年度人天包，比如每年包含10个人天的小调整，超出部分按单价算。
还有源码。很多合同只写“交付源码”，但没写交付什么形态。是完整可编译的工程，还是只给几个核心文件？数据库脚本给不给？部署文档有没有？这些不写清楚，后期想换团队接手，成本极高。
我一般建议客户在合同附件里加一条：验收时，由我方指定一名外部技术人员，在对方协助下完成一次独立部署。能跑通，再付尾款。这一条能筛掉不少“只能在他们自己电脑上跑”的项目。
上线后的第一个月，比开发期更重要
很多企业把上线当成终点，其实第一个月才是真正的考验。用户不按你设想的方式操作，数据量比测试时大十倍，各种没想过的组合冒出来。
我合作过的一个团队，上线后前两周每天派人驻场，不是去改代码，就是坐在用户旁边看他们怎么用。结果发现，仓库管理员根本不用系统推荐的补货点，因为那个数字没考虑卸货区容量。这种问题，坐在办公室永远想不到。
所以选型时，可以问对方一句：上线后前两周，你们怎么安排？如果回答是“有问题随时远程”，那你要有心理准备，响应速度可能跟不上。如果对方主动提出驻场或每日复盘，说明他们把上线当成项目的一部分，而不是交付的终点。
写在后面
如果你现在手里正拿着两三份报价单，别急着比总价。挑一份，让对方把需求文档补到能看懂每一步逻辑的程度，再约一次演示，专门问边界场景。这两件事做完，哪家能干活，基本就清楚了。合同可以慢慢谈，但选错人，后面全是成本。