如何判断一家软件外包公司靠不靠谱？有没有避坑清单？

判断外包公司是否靠谱，不看“案例多、技术强”的口号，重点核验需求理解、在岗团队、交付样品、合同边界、过程证据和退出接管能力。

价格高不等于可靠，公司大也不等于适合。采购前先按项目风险决定尽调深度：展示型官网可以轻量核验，掌握客户数据、支付、生产控制或核心经营流程的系统则要检查安全、持续运营和替换成本。案例截图、奖项和销售口头承诺只能作为线索，不能替代可验证材料。

在把业务目标转成可执行范围时，还可以对照 中小项目应该找"小而专"的团队还是大公司？对我有什么实际区别？ 和 我们公司没有技术人员，系统做完之后日常谁来管、出问题找谁？；这些内容补充了需要放在同一项决策中考虑的上下文。

签约前由候选方提交六类证据

核验项	应看到的证据	危险信号	判断动作
需求理解	用你的案例复述流程、异常和不做范围	只按页面报总价，所有问题都说能做	先做小型需求工作坊或付费发现
实际团队	项目经理、设计、开发、测试的姓名或角色与投入	销售承诺豪华团队，合同不写资源	让核心成员参加技术与交付访谈
交付质量	脱敏的需求、测试、部署、交接样品	只能展示最终界面	抽查一个变更如何从需求走到上线
商务边界	分项范围、假设、依赖、第三方费和变更规则	明显低价但遗漏测试、迁移和运维	将候选报价统一到同一工作清单
安全与连续性	权限、备份、漏洞处理、人员交接和事故流程	云账号、密钥、数据都只在个人手里	按系统风险要求证明与演练
退出接管	代码库、数据导出、账号、文档和协助期限	只交安装包或限制客户访问	把资产清单与接管测试写进验收

报价必须先拉齐口径

客户先说明业务目标、现有流程、必须上线的时间和预算约束；候选服务商应负责把这些输入拆成需求分析、原型、前后端、管理后台、接口、数据迁移、测试、部署、培训、保修、运维、云资源和第三方服务。对多家报价进行技术比选时，还应由主持评估的一方统一推导目标平台、负载、数据量、安全等级和验收环境，而不是要求客户先写出一套技术架构。一个报价缺少迁移、测试或上线支持，看起来便宜并不代表总成本低；同样，服务商列出有依据的风险储备也不代表故意报高。

要求候选方选一个最高风险点做说明或小型验证，例如用脱敏数据跑一次迁移、接通真实 API 沙箱、展示备份恢复或让接手开发解释陌生模块。试做应明确成果归属和费用，不能索取大段免费设计后交给另一家照抄。推荐客户访谈时，由采购方自行联系并询问延期、变更、线上事故和交接情况，而不只问“满意吗”。

合同保护的是最坏情况

SOW 至少写清交付物、排除项、双方依赖、里程碑、验收样本与期限、缺陷等级、变更计价、延期处理、第三方费用、知识产权、个人信息、保密、事故通知、终止和退出协助。源码归属并非唯一问题；域名、云账号、应用商店、证书、监控、数据库备份和供应商后台若仍在对方控制，换团队时照样会被卡住。法律效果应由专业律师结合合同与适用法律确认。

CISA 的软件采购指南说明建议用结构化问题了解软件保证与供应链实践，也明确问卷最终如何使用由交易各方决定。清单只能帮助发现风险，不能产生“绝对靠谱”的认证。