如何选择软件开发公司？
位于匈牙利布达佩斯的软件开发公司 Mesterséges Intelligencia Központ Kft. 认为，好的选择取决于三个问题：开发商是否理解目标，其报价能否核查，以及交付后代码和系统归谁所有。
要点：请先写明目标和必备需求，然后再索取报价。值得要求对方展示实际运行的成果、透明的流程，并提供对代码的访问权限；报价必须针对同一份逐项规格说明进行比较，最好依据度量出的规模。合同中还必须明确源代码和使用权、保密、缺陷修复、运行以及退出方式。
先明确目标：软件必须能做什么？
大多数糟糕的选择并不是从开发商开始的，而是从一份含糊的委托开始的。如果没有写明软件必须能做什么，每一份报价的含义都会不同，无论是价格还是完成的工作，都将无从衡量。并不需要一份完整的规格说明（好的开发商会帮助编写），但有几件事值得事先考虑清楚：
- 目标：软件要解决什么问题，以及从哪些方面可以看出它是成功的。
- 用户：谁会使用它，是内部员工、客户还是合作伙伴。
- 必备需求：缺少了就无法上线的内容，与“有了更好”的项目分开列出。
- 现有系统：它需要与哪些系统连接（ERP、CRM、网店、开票软件、银行）。
- 数据：它处理哪些数据，其中包括个人数据。
- 约束条件：是否有固定的截止日期、内部规定，或者托管或安全方面的要求。
还值得先决定：究竟是否需要定制开发，还是一个现成产品，或者现成产品加上定制扩展就已足够。定制软件还是现成方案（SaaS）？一文可以在这方面提供帮助。
候选名单：应该联系哪些公司？
不需要联系很多公司；几个精心挑选的候选者，胜过许多敷衍的报价。筛选的标准：
- 类似的工作：是否已经构建过规模和性质相似的系统，例如企业软件、网店、移动应用、AI 集成。
- 技术匹配：是否使用现有系统需要对接的那些技术。
- 规模匹配：公司的能力是否与项目相称；大型系统需要多个专业领域，小任务需要的少一些。
- 语言和可联系性：能否用您的语言、在您的时区进行沟通。
核查过往工作和参考案例
最有力的证据是实际运行的软件。请候选者展示一个可以实际试用的系统，并准确说明他们自己在其中负责的部分。许多客户项目受保密约束，因此并不总能透露客户名称。在这种情况下，一份匿名化的描述、一次演示或公司自己的产品同样很能说明问题。
如果以前的客户愿意提供推荐，最好提出具体的问题：是否遵守了约定的范围，变更和缺陷是如何处理的，客户是否拿到了源代码，双方是否仍在合作。一句笼统的“我们很满意”说明不了什么；而客户在交付后仍与他们一起运行该系统，则很能说明问题。
技术沟通
值得与每位候选者进行一次技术沟通，最好您这一方也有一位技术人员在场。重要的不是回答听起来有多自信，而是开发商是否会提问，以及是否指出风险。好的问题包括：
- 贵公司会如何着手，第一阶段会是什么？
- 会如何对接我们现有的系统，需要了解它们的哪些情况？
- 如何进行测试，由谁决定某个部分已经完成？
- 谁会参与这个项目，谁将是我们的联系人？
- 系统将在哪里运行，由谁负责安全更新？
- 如果其中还涉及人工智能：哪些数据会流向哪里，AI 出错时会怎样？
如果候选者不提任何问题，在第一次沟通之后就给出准确的价格和期限，这是一个警示信号。
流程与沟通
在软件开发中，意外很少源于代码，更多源于沟通。因此，值得问一问您在开发过程中如何了解进展。良好实践的特征：
- 分阶段开发：工作被划分为若干阶段，每个阶段结束时都会演示可运行的软件，而不只是提交报告。
- 代码访问权限：客户从第一天起就能看到代码库（repository），而不是到交付时才拿到。
- 可追踪的任务清单：任务、缺陷和变更都记录在一个共享的跟踪系统中。
- 固定的联系人：有一个了解项目并能够做决定的人。
- 变更管理：新的或变更的需求会被写明、度量或估算，并且只有在获得批准后才纳入工作。
比较报价
两份报价只有在针对同一范围时才能比较。因此，每位候选者都应拿到同一份逐项描述，并请他们说明价格针对的是哪些功能、多大的规模。如果开发商用标准方法度量软件的功能规模，例如以 COSMIC 功能点度量，那么规模就可以根据同一份规格说明进行核查；关于这一方法，请见什么是 COSMIC 功能点？一文。
如果两份报价差别很大，值得提出以下问题：
| 问题 | 能弄清什么 |
|---|---|
| 价格针对的是多大的规模、哪些功能？ | 报价针对的是否为同一范围 |
| 哪些内容作为单独项目列出？ | 是否包含集成、数据迁移、美术设计和运行 |
| 考虑了哪些非功能性需求？ | 性能、安全、无障碍 |
| 如何处理变更？ | 过程中出现新需求时会怎样 |
| 交付后的缺陷修复安排是怎样的？ | 费用包含什么，什么算作额外工作 |
| 源代码归谁所有，我们获得哪些权利？ | 系统能否交由他人继续开发 |
| 采用固定价格还是按工作量结算？ | 由谁承担范围风险 |
当范围已逐项确定时，固定价格效果很好；按工作量结算更为灵活，但范围风险由客户承担。无论哪种方式，关键都在于范围可以度量、可以跟踪。我们如何定价，请见定价方式页面。
合同的要点
在发生争议或意外情况时，起作用的是合同。以下内容仅供参考，不构成法律意见：最好也请律师审阅合同。
源代码与使用权
匈牙利《著作权法》（1999 年第 LXXVI 号法律，Szjt.，匈牙利语）将计算机程序作品，无论是源代码还是目标代码，都作为著作权作品加以保护（第 1 条第 2 款 (c) 项），并规定软件的著作财产权可以转让（第 58 条第 3 款）。因此，客户要么取得著作财产权，要么获得使用许可（licence）；两者并不相同。
以下几条规则说明了为什么措辞精确很重要：使用许可合同只有在明确约定的情况下才授予独占权（第 43 条第 1 款）；如果合同没有写明使用的方式和范围，许可仅限于实现合同目的所必不可少的范围（第 43 条第 5 款）；如果内容含义不明确，应采用对作者更有利的解释（第 42 条第 3 款）；被许可人只有在获得作者明确许可的情况下，才能向第三方再授予许可（第 46 条第 1 款）。因此，最好在合同中写明：
- 完整源代码和文档的交付，也包括按阶段交付；
- 客户是取得著作财产权，还是获得某种范围的许可（是否独占、能否修改、能否转让）；
- 开发商对其员工和分包商编写的代码拥有相应权利；
- 所使用的开源组件和第三方组件的清单及其许可证。
保密（NDA）
如果创意或业务数据属于机密，最好在讨论细节之前签订保密协议（NDA）。请在协议中写明哪些属于机密信息、谁可以接触这些信息、保密义务持续多久，以及工作结束时如何处理相关材料。
缺陷修复与质保
合同应写明什么算作缺陷（与约定需求的偏差）、验收测试如何进行、有哪些严重级别，以及开发商对每个级别的响应速度。还请写明，对于交付时未被发现的缺陷，开发商在多长时间内免费修复，以及什么已经算作后续开发。
运行与 SLA
如果开发商在交付后仍负责运行系统，就由服务级别协议（service level agreement，SLA）来规定相关条件：承诺的可用性、报告故障的方式、按严重程度划分的响应时间和修复时间、维护时间窗口、备份以及报告。没有写下来的内容，在发生争议时就无法要求对方履行。
退出计划
退出计划回答的是这样一个问题：无论是因为不满意，还是因为开发商停止经营，如果不再与该开发商合作，会发生什么。其组成部分：
- 关于安装、架构和运行的最新文档；
- 代码库、托管服务、域名和云账户登记在客户名下，或至少客户拥有访问权限；
- 移交密码和访问密钥的规范流程；
- 数据能够以标准格式导出；
- 在向新开发商移交时提供配合。
数据保护：数据处理协议
如果开发商在工作过程中能够接触个人数据（例如因为它负责运行系统，或使用真实数据进行测试），那么根据 GDPR，它通常属于数据处理者，需要与其签订书面数据处理协议（GDPR 第 28 条）。协议中必须规定的内容包括：开发商仅按照客户记录在案的指示处理数据，确保保密和安全，仅在获得授权后才委托其他数据处理者，在服务结束时删除或返还数据，并允许进行审计。
安全实践
安全无法事后再加到软件上，因此值得问一问开发商在工作中如何对待安全。一个好的起点是 OWASP Top 10，这是一份广为人知的 Web 应用最关键安全风险清单；现行版本是 OWASP Top 10:2025（2026 年 10 月 17 日核实）。排在前三位的是：访问控制失效、安全配置错误和软件供应链失效。请询问：
- 如何管理权限，又如何测试一个用户只能看到自己的数据？
- 如何更新所使用的外部库，又如何得知其中某个库存在漏洞？
- 密码和密钥存放在哪里，谁可以访问它们？
- 是否有代码审查（code review）和自动化测试？
- 如何进行备份，是否已经尝试过恢复？
自由职业者还是开发公司？
两者都可能是好的选择；问题在于任务有多大，以及系统会使用多久。
| 要素 | 自由职业者 | 开发公司 |
|---|---|---|
| 沟通 | 直接，与一个人沟通 | 通过联系人，与多位专业人员沟通 |
| 专业领域 | 一个人的知识 | 多个专业领域：界面、后端系统、移动端、运行、测试 |
| 可替代性 | 生病或离开时工作就会停滞 | 团队成员可以接手彼此的工作 |
| 能力 | 适合较小、界定清楚的任务 | 适合较大的系统和并行工作 |
| 合同 | 直接与该专业人员签订 | 与公司签订，由公司对团队的工作负责 |
| 长期运行 | 取决于自由职业者是否有空 | 可以有组织地承担 |
自由职业者很适合界定清楚的任务，尤其是当客户有自己的技术负责人来指导并接手工作时。如果系统是公司日常运营的一部分，需要多个专业领域，并将运行多年，那么开发公司通常风险更小。无论哪种情况，退出计划和源代码的交付都同样重要。
警示信号
- 第一次沟通之后、不提任何问题就给出准确的价格和期限。
- 没有书面规格说明，或者报价没有说明它针对的是什么。
- 客户看不到代码，只能在交付时才拿到。
- 对谁将参与项目的问题含糊其辞。
- 源代码归谁所有、客户获得哪些权利，都不明确。
- 拒绝签订数据处理协议或保密协议。
- 没有可以展示的、实际运行的成果。
检查清单
| 问题 | 符合要求的情况 |
|---|---|
| 目标和必备需求是否已写明？ | 有一份简短的、各方理解一致的描述 |
| 我们是否看过实际运行的成果？ | 至少试用过一个类似的系统 |
| 对方是否理解任务？ | 他们提了问题，并指出了风险 |
| 我们能否看到进展？ | 分阶段演示，可以访问代码库 |
| 报价是否可以比较？ | 针对同一逐项范围，单独项目一目了然 |
| 源代码和权利问题是否已经明确？ | 合同写明了交付事宜和权利范围 |
| 是否签订了保密协议和数据处理协议？ | 在需要的地方已经签署 |
| 缺陷修复和运行是否已有约定？ | 严重级别、响应时间、SLA |
| 是否有退出计划？ | 文档、访问权限、数据导出 |
| 我们是否询问过安全问题？ | 在权限、更新和备份方面有具体答复 |
常见问题
自由职业者还是开发公司？
对于界定清楚的较小任务，经验丰富的自由职业者也可能是好的选择，尤其是当公司有自己的技术负责人时。如果系统是日常运营的一部分，需要多个专业领域并将长期运行，那么开发公司的风险更小，因为工作不依赖于某一个人。
如何比较两份报价？
只有针对同一份逐项规格说明给出的报价才能比较。请询问两家投标方，其价格针对的是多大的规模、哪些功能，哪些内容作为单独项目列出，以及如何处理变更。如果规模是用标准方法度量的，例如以 COSMIC 功能点度量，那么就可以根据同一份规格说明进行核查。
合同应包含哪些内容？
范围（逐项规格说明）、价格和进度安排、源代码的交付和使用权的范围、保密、验收和缺陷修复的安排、运行和 SLA、退出计划，以及在涉及个人数据时的数据处理协议。以上内容仅供参考，不构成法律意见。
如果开发商消失了怎么办？
如果源代码、文档和访问权限都掌握在客户手中，另一家开发商就可以接手系统。因此，最好从第一天起就能看到代码库，把托管服务和域名登记在自己名下，并在合同中约定退出计划。如果缺少这些，系统的后续开发可能会既困难又缓慢。
源代码归谁所有？
归合同规定的一方所有：根据匈牙利《著作权法》，软件的著作财产权可以转让，但这不是自动发生的。最好在合同中写明，客户将获得完整的源代码，以及客户对其享有的具体权利。在我们这里，源代码和使用权同样由合同约定。
我们如何提供帮助？
我们的工作方式是：首次咨询免费，我们与您共同编写规格说明，以 COSMIC 功能点度量软件的规模，并据此编制报价和进度安排。开发分阶段进行，每个阶段结束时都有演示；可应要求签署保密协议（NDA），交付后我们还承担运行与维护工作。源代码和使用权由合同约定。具体步骤见我们的工作方式页面，定价方法见定价方式页面。
我们目前正在开发一套大型 ERP 和 CRM 系统；我们自己开发、可以试用的项目展示在我们的作品页面上，关于公司的介绍请见关于我们页面，常见问题的解答请见常见问题页面。如果您正在寻找开发商，请通过联系我们页面上的联系方式给我们写信。