跳至主要内容
Rosecraft Studios

软件准备好了?那就让我自己操作

购买定制软件,不能只看演示。让实际使用者在独立的测试环境中完成一项真实任务,再判断这个里程碑是否达标。

Corey Rosamond · 2026/9/30 · 约 5 分钟阅读

本文为英文原文的简体中文译文。资料和事件日期保留原文发表时的语境;代码示例保持原样。 Read in English

软件准备好了?那就让我自己操作

如果我付钱开发一套定制软件,总得有个时候,鼠标要交到我手里。

看开发者操作应用,能了解一部分情况。自己用它完成工作,又能了解另一部分。在认定一个里程碑完成之前,我希望两种体验都有。

好的演示当然有价值。开发者可以解释设计选择、展示新功能,并指出哪些部分还在开发。但客户不应该只能通过一套自己从未操作过的点击流程,猜测这个应用是否适合自己。

无论是内部排班工具,还是准备推向市场的新产品,这一点都重要。真正使用系统的人,知道工作中那些不顺手的情况:两个预约时间冲突、客户临时改变主意,或者某位员工需要查看预约,却不该看到发票。

封面为 AI 生成的虚构软件评审场景,不代表真实客户会议。

交付流程中一个有用的变化

9 月 28 日,Laravel 介绍了预览环境与闲置休眠的配合方式:为拟议的代码变更提供独立的运行版本,并让支持该功能的资源在闲置时休眠。评审者可以打开链接,在变更进入生产环境之前实际使用应用。

对采购方而言,关键是能亲自尝试。应该问清楚:在还有调整空间的时候,我怎样试用每一块有意义的功能?项目不必使用 Laravel;小团队也可能使用一个管理得当的预发布环境,而不是为每次变更创建独立环境。无论采用哪种方式,都应当让客户能够评估工作,同时不干扰正在运行的业务。

预览也需要列入预算。有人要准备账号和样例记录、维护环境,并处理反馈。应该问清哪些资源会收费、闲置时如何处理,以及何时清理。服务器便宜,不等于整个评审过程没有成本。

给评审者一项任务,然后让他自己完成

设想一家小型服务公司的预约系统。本次里程碑是改期。开发者演示打开预约、修改时间、保存,一切看起来都很顺利。

如果由客户评审,我会给实际负责预约的人一个测试账号,再给一项简短任务:把明天的预约移到下周,换一位员工负责,然后确认客户会收到什么通知。先让他自己操作,再解释应该点哪里。

他可能发现,移动预约后,一条重要备注悄悄消失了。也可能任务已经完成,却花了好几分钟寻找确认信息。前者是功能缺陷,后者可能是设计问题。排练过的演示可能把两者都略过去。

还可以加入工作中常见的小波折:让首选时间已被占用,或者提供一条已经取消的预约。使用能够说明这些情况的虚构姓名和样例记录。

目的是了解流程表现,而不是突然给开发者一场没有边界的考试。提前约定任务、预期结果和相关用户角色。如果本次里程碑只包括修改时间,就明确说明。只要大家都知道哪里还没完成,评审未完成的功能完全合理。

允许试错,但不要影响真实客户

评审者需要知道测试会影响什么。会发送真实邮件吗?取消预约会修改正式日历吗?调整发票会产生实际扣款吗?页面上一个令人放心的“预览”标签,回答不了这些问题。

Laravel 的预览环境文档说明了这个区别:既支持独立资源,也允许预览环境共用目标数据库。在后一种配置中,变更会影响共享数据。仅凭网址不同,不能证明环境已经隔离。

对于这里假设的预约评审,我会使用虚构预约、独立存储和测试收件人。外部服务应使用适当的测试设施,或明确说明的替代实现。在邀请客户尝试之前,应当有人确认邮件和日历变更实际会去哪里。

账号权限应当符合被评审的角色。使用管理员账号,可能掩盖前台人员无法完成必要步骤的问题。同样,员工不应为了调整预约就必须拥有管理员权限。涉及这些差异时,应使用不同的测试账号。

预览也有局限。模拟邮件服务可以展示拟发送的内容,却不能证明正式邮件服务能够成功投递。少量样例数据不能证明系统在完整业务量下的性能。把这些限制写清楚,并列出上线前还需要进行的检查。用一个过度自信的预览替代过度自信的演示,没有什么好处。

提前约定评审之后怎么办

有用的评审,应产生能够采取行动的结论。记录测试的构建版本、任务、预期结果,以及实际发生的情况。简短录屏可以帮助解释令人困惑的交互,前提是其中不包含真实客户信息。

然后,把未达到约定范围的缺陷,与新发现的需求区分开。如果已经约定的权限规则没有生效,就需要修复。如果试用过程中产生了新功能想法,则应该讨论成本和优先级。双方都不必假装这两类情况是一回事。

给评审者合理的时间,并明确谁有权接受交付。评审期间应保留被测试的版本,或者明确告知变更。否则,周二报告的问题,到了周三完全不同的构建中,可能已经无人能够复现。

这不能替代代码审查、自动化测试或专项测试。它回答的是一个这些活动无法代替客户决定的问题:预期使用者,能否通过这个功能完成约定的工作?

开发定制应用时,我会从一开始就把这种评审写进交付计划。一小块真正可用的功能,能让采购方具体判断进展,也能给开发者明确的反馈。它还可能在团队围绕某个流程继续开发之前,帮助大家发现这个流程本身就需要调整。

Rosecraft 的网站应用开发工作包括把业务流程转化为可用的软件。如果你正在委托开发系统,或希望把现有项目推进到交付阶段,告诉我们用户需要完成什么,以及他们现在能够亲自试用哪些部分。这是定义下一项交付成果的一个实际起点。

作者:Corey Rosamond,Rosecraft 创始人兼首席工程师

继续阅读

订阅工作室邮件

留下邮箱以接收工作室更新。订阅后请检查确认邮件;确认邮件目前使用英文。

了解隐私政策

下一步,从交流开始

把您的问题,变成清晰的下一步。

告诉我们您想开发或改进什么。我们会一起梳理范围、限制和合适的工程方案。

聊聊项目