企业软件的第一个版本应该包含什么？

做第一个版本时，先选一项有人能做完的工作。然后把让他们在信息有误、同事不在或系统出了问题时仍能完成工作的条件也纳入范围。

想象一个周一早晨：一名员工打开软件，完成一项有用的工作，留下下一位同事可以信赖的结果。

确定工作从哪里开始，到哪里结束

假设一家虚构的维修公司要建立工单系统。第一批用户是办公室协调员和一支维修团队。协调员记录并分配任务，团队记录完成了什么，协调员核对结果并关闭工单。

这可以成为有用的第一版。单说“一个工单页面”却说明不了多少。团队能看到分配结果吗？分配有误时谁能修改？关闭工单又意味着什么？

先明确使用者和结果，再决定要做多少个页面。一套完整流程可能需要多个页面和角色。页面数量本身并不能说明软件能否用于实际工作。

英国政府关于测试版阶段的指南讨论了如何建设并测试满足用户需求的服务，也考虑整个使用过程及支持服务的人。政府的交付流程有其自身要求。对这家维修公司来说，关键是选定的用户能否把一张工单处理到底。

把难处理的情况也纳入范围

在这个虚构例子中，协调员把任务分给了错误的团队。团队出发前发现了问题。需要有人纠正分配，而且两支团队都要看得出哪个版本是当前有效的。如果把纠错留到以后，承诺支持的工作就会留下缺口。

与实际做这项工作的人逐步走一遍流程。确认谁能创建、修改、分配和关闭工单，谁能查看信息。也要决定任务无法完成时怎么办，例如无法进入建筑物，或需要订购零件。工单要有约定的下一状态，也要有人负责跟进。

第二栏取决于企业的实际流程。如果不开票就不能算完成任务，第一版需要明确如何开票。约定交接给现有开票流程或许就够了。悄悄省略这一步，只会让员工在使用时才发现缺口。

纳入让工作持续运转的条件

团队需要真实的工单信息。确定哪些现有记录必须迁入、由谁核对，以及发现错误后如何处理。导入功能即使没有醒目的页面，也不因此变成可选项。

明确谁创建和删除账户、回答员工问题、调查故障并维护服务。提供第一批用户所需的帮助或说明。还要确认服务不可用时怎么办，以及如何恢复相关信息。

Google 关于移交运行责任的文章讨论了就绪检查、文档和培训。文章描述的是 Google 自己的环境，不是对小企业团队架构的规定。这里的实际要点是明确谁负责运行和支持第一版，并确保他们具备所需条件。

承诺上线前先验证不确定的部分

原型可以帮助判断协调员是否理解分配页面，或团队能否在手机上记录一次上门工作。要说清它实际能证明什么。即使演示很像成品，也可能使用虚构记录，并跳过权限、存储或恢复问题。

批准正式使用前，先约定需要哪些针对实际版本的验证依据。在这个例子中，要在独立的测试环境里，让预定角色分别尝试正常工单和分错团队的工单。检查团队是否看不到无权查看的工作、修改是否传达给正确的人，以及未完成的工作是否仍然可见。

再按系统风险选择其他检查，例如导入记录、多人同时修改、故障恢复或系统需要承受的工作量。一次顺利走通流程，不能解决所有这些问题。为尚未解决的风险指定负责人，并决定员工开始依赖服务前必须解决哪些问题。

把准备批准的版本写清楚

这家维修公司的版本边界可以这样写：

• 使用者：协调员和一支指定的维修团队。
• 工作：从记录任务，到按约定完成任务，或明确记录仍未完成的原因。
• 必要支持：按角色控制访问权限、纠错、必要的初始记录、员工帮助，以及运行和恢复安排。
• 验收依据：约定的正常及棘手情况，加上针对已识别风险的检查。
• 待决定事项：指定负责人，在相关工作获批前给出答案。
• 以后再做：客户自助服务、路线规划和自动开票，前提是已约定与现有流程的交接方式。

与员工、业务流程负责人以及开发和运行软件的人一起核对这条边界。他们应该能说明这一版处理哪些工作，其他工作又会如何处理。

我们开发定制企业软件。如果想和我们讨论第一版，请带上希望用户完成的工作、使用者群体，以及尚不确定的部分。项目范围、交付和后续维护会按项目约定。

关于软件第一版的常见问题