非技术背景的 CEO 如何选择软件公司

CEO 无需评估代码。需要评估的是：供应商是否理解业务问题，能否把模糊的需求转化为清晰的项目范围，以及是否具备一套能够降低风险的交付体系。

最常见的错误，是根据一场令人印象深刻的方案介绍或最低报价做出选择。真正的质量体现在软件公司如何提问、如何界定交付成果、如何管理变更，以及如何证明系统确实可以运行。

从业务成果出发

在索取报价之前，先描述您的运营中需要改变什么。例如：缩短出具报价的时间，确保任何请求都不会遗漏，将客户数据库与 ERP 连接，或者开辟新的数字化收入渠道。

不要一开始就列出一长串功能。功能只是候选的解决方案，成果才是您投资的理由。好的合作伙伴会帮助您把每一项关键功能与用户、问题和可衡量的目标对应起来。如果您的问题专门涉及 CRM，请先确认现成 CRM 还是定制 CRM更适合您。

了解需求调研如何进行

询问开发开始之前会发生什么。哪些人会参与？业务流程如何记录？需求如何确认？需求调研的交付成果是什么？

如果一家公司在一次简短的泛泛交流之后，就能为一个复杂项目给出最终价格和日期，那么它很可能要么低估了项目范围，要么在报价中预留了很大的不确定性余量。报价的准确程度，取决于其背后理解的准确程度。

要求与实际执行团队见面

销售阶段的介绍可能由资深人员负责，而项目本身却交给其他人执行。请要求与项目负责人和技术负责人见面。询问哪些人会参与、他们能投入多少时间，以及遇到技术障碍时由谁做决定。

您无需审阅每位开发人员的简历。您需要确认的是：有一位对整个项目有全局视野的责任人，并且关键知识不会只掌握在某一个人手中。

以正确的方式评估类似项目

庞大的作品集本身并不能证明供应商适合您。请对方提供两到三个在复杂度、集成或监管环境方面相近的项目。询问当时的问题是什么、交付了什么、实施过程中有哪些变化，以及衡量了哪些成果。

应用程序的截图能证明设计水平，却无法证明稳定性、用户采用情况、性能或业务成果。

要求明确的范围和验收标准

每项核心功能都应有验收标准。如果系统“与 ERP 连接”，就必须明确传输哪些数据、朝哪个方向传输、多久传输一次、出错时如何处理，以及由谁对 API 负责。

方案应清楚区分哪些内容包含在内、哪些不包含、做了哪些假设，以及哪些部分依赖第三方。

理解成本模式

在固定价格模式下，供应商承担更多的范围风险，通常会加入一定的安全余量。在按工时与材料计费模式下，客户为实际投入的时间付费，但需承担总成本方面更大的不确定性。在分阶段模式下，每个阶段都要在下一阶段开始前获得批准。

没有哪种模式总是更好。正确的选择取决于需求的成熟程度，以及预计会有多少变更。

检查安全性与连续性

询问系统托管在哪里、如何进行备份、如何管理访问权限、如何记录安全事件，以及使用了哪些次级数据处理方。了解关键账户归谁所有，以及如果合作关系发生变化，项目将如何延续。

仅凭一句“我们符合 GDPR 要求”是不够的。您需要具体的措施、明确的角色分工以及合同文件。

评估对方的沟通方式

软件项目合作必然伴随不确定性。关键在于团队能多快把问题提出来，以及能提供哪些依据来支持决策。请关注稳定的沟通节奏、书面记录的决定、可运行软件的演示，以及透明可见的待办清单。

过度自信是一个警示信号。成熟的合作伙伴会清楚区分哪些是已知的、哪些是假设的，以及哪些仍有待验证。

决定委托前的十个问题

1. 您认为我们要解决的是什么问题？我们将如何衡量成功？
2. 第一个交付成果是什么？我们什么时候能看到它运行？
3. 谁负责项目范围、技术决策和沟通？
4. 方案中包含哪些假设？
5. 变更如何审批？它们会如何影响成本和时间进度？
6. 哪些数据和集成依赖于我们，哪些依赖于第三方？
7. 验收标准是什么？
8. 安全、备份、监控和事件响应如何处理？
9. 如果合作终止，将交付哪些内容？
10. 系统上线后的总运行成本是多少？

Argonstack 的定制项目从业务分析和技术设计开始。目标是让方案描述一套能够真正交付、测试和运行的系统，而不只是一份吸引人的功能清单。

下一步

在投入预算之前，先评估项目、风险和预期成果。

常见问题

我应该选择报价最低的方案吗？

先别急着这样做，首先要确认各份报价涵盖的范围是否相同。较低的价格可能源于更少的交付成果、不同的假设，或者遗漏了关键工作。

我需要有自己的 CTO 吗？

不一定。但对于重要项目，您需要独立的技术监督，或者至少有一位经验丰富的顾问来审查架构、安全性和交付成果。

最重要的危险信号是什么？

供应商无法清楚说明自己尚不清楚哪些事情，以及打算如何加以确认。