选择软件开发商时要问的五个问题

首先准备一份类似的职位描述

当您向三个软件开发人员询问同一应用程序的报价时，您可能会遇到三个不同的范围。一种仅对屏幕定价，一种增加数据传输，另一种则单独提供维护。这些优惠不能在相同的总数上进行比较。首先用一个简单的例子描述当前的工作和预期的结果。准备提案的员工会收到哪些信息、谁批准提案以及哪些文件会发送给客户？通过提取个人数据来共享真实示例比仅仅列出功能名称提供了更容易理解的开始。

职位描述不必是详细的技术规范。让用户、强制信息、基本操作、预期输出和重要例外都清晰可见。然后要求每位候选人对相同问题做出书面回答。以下五个问题可用于了解价格并了解应用程序在交付后如何生存。长答案并不能证明质量。更重要的是它适用于你的业务并且可以在验收时进行测试。

第一个问题：谁来进行维护工作？

软件交付后，产品列表、业务规则或外部服务可能会发生变化。报告错误时谁将做出回应以及将使用什么渠道？ Bug 修复、安全更新和新功能添加应在维护范围中单独编写。不要假设这些价格相同。还将响应时间与解决时间分开。说已收到通知并不意味着错误已被修复；应明确界定各方在每种情况下的期望。

与唯一提供商合作本身并不是问题。但要询问当该人休假或离开项目时谁将继续工作。备份、回滚和更改日志记录也是维护的一部分。请他们举例说明在实施更新之前他们是如何测试更新的。 自动化工程 在规划时确定维护人员可以减少项目结束后出现的不确定性。不要选择满足每种需求的最广泛的包，而是确定您实际需要的支持。

第二个问题：谁有代码和送货包？

现成服务和定制软件的交付模式可能不同。能否提供专门为您开发的部分的源码、安装文档和依赖信息？不同团队可以继续申请的条件是什么？不要只用口头回答这些问题。交货包和使用条款应在报价中查看。提供存储库的链接并不公开所有使用权利；必要时应与相关专家一起评估合同和组件条件。

确定一个小测试来测试交付的可用性。在干净的环境中安装、完成基本过程并恢复示例备份可以是良好的开始。记录可以使用哪个文档执行哪个交易。 源代码交付控制 你也可以阅读。将密码和密钥放入代码中并不是一种交付方法。访问权限必须通过单独、授权和记录的流程进行转移；不必要的访问应在项目结束时关闭。

第三个问题：数据将在哪里以及如何管理？

客户、订单或人员数据将保存在什么环境中？谁将能够查看数据，哪个角色将能够执行哪个操作，以及如何导出记录？要求提供商用简单的图表展示数据流。还应明确发送给外部服务的领域。不要仅仅为了准备报价而分享真实的个人数据；使用样本或匿名数据。根据应用范围，数据处理义务可能需要专家评估。

评估备份的声明以及备份的恢复方式。备份在哪里，谁有权访问它，以及之前是否测试过恢复？另请询问服务完成后您将以什么格式收到数据。单独提供 PDF 报告可能并不意味着所有记录都可以移动到另一个系统。导出中必须包含字段名称、关系和其他文件。将这些要求添加到初始提案中可以减少在出发时定义新项目的需要。

第四个问题：首次发布将完成哪些工作？

没有必要在第一个版本中包含所有想法。重要的是从头到尾完成既定的工作流程。如果用户登录但无法打印批准的文档，则基本作业可能尚未完成。询问候选人对第一个版本的详细报道可以让这种差异显而易见。明确哪些数据将手动输入、哪些连接将被推迟以及将生成哪些报告。编写示例操作的预期结果，而不是模糊的属性列表。

创建同一工作的验收标准。当缺少必填字段时会发生什么，如何处理重复注册，以及如果交易被放弃，用户会看到什么？考虑错误流可以避免仅基于成功演示进行评估。从一开始就了解新功能的变更方式和定价方式。不要保证项目每个阶段的准确时间，而是要清楚地评估依赖关系、期望从您那里获得的信息以及决策日期。

第五个问题：谁来训练球队，如何训练？

开发者的演示并不能证明员工可以使用该应用程序。根据您的示例流程规划培训。让用户打开记​​录，更正错误字段，获得必要的批准并创建输出。还应该解释更改管理员权限和报告问题的步骤。简短的用户指南和示例记录对新手也很有帮助。训练中的卡点不应仅仅被视为用户错误；应考虑是否需要改进显示或描述。

将五个问题的答案收集在一张表中：范围、责任、交付文件、验收测试和成本。在签署要约之前澄清任何悬而未决的问题。目的不是根据技术术语的数量对候选人进行排名。一个可靠的基准是选择了解您的业务、清楚地传达其边界并使其交付可验证的团队。因此，后续的使用和维护与第一次显示一样都包含在决策中。

常见问题

如何比较报价？

与相同的流程、范围、交付指标和护理期望进行比较。仅比较总价格是不够的。

每个功能都应该包含在第一个版本中吗？

可以选择限量版来补充主要工作流程。分解缺失的功能和下一阶段的写作。

培训是否应该成为交付的一部分？

实践培训和简短的用户手册，将使用该工作的人员可以执行示例操作，可能包含在交付范围内。