四周内确定应用第一版的范围：如何避免第一次开发做得过大

大多数第一次定制开发的失败，并不是因为开发方做不出来，而是因为第一版悄悄变成了最终版：每个人想到过的点子、会计可能想要的每份报表、每种角色、每个对接和每个精致的页面，全都被承诺在上线那天交付。结果是项目漫长、报价庞大、上线一再推迟，而真正需要一个简单工具的人只能继续等待。

本指南写给第一次委托开发应用或业务系统、希望第一版小而能上线的非技术老板。它告诉您如何把一个想法缩小到可以上线并投入使用的程度，所用的都是在联系任何开发方之前就能在纸上完成的简单步骤。文中的四周时间盒只是规划练习的示例，不是任何供应商的承诺。这是一般性指导；真实项目需要多久取决于其规模，唯一可靠的数字是书面报价上的数字。关于哪些因素决定工期，请见定制业务系统需要多长时间。

为什么第一次开发会越做越大

同样的几件事一再发生，而且都不是谁的错。提前认出它们，有助于及早发现。

• 每个人都加一点。 被问到系统应该做什么时，每个人都会加上自己喜欢的功能。没有人删除任何东西，清单只会越来越长。
• “顺便也做了吧”。 既然页面已经有了，多加一个按钮似乎很便宜。但每个按钮都要设计、开发、测试和讲解，很少真的便宜。
• 担心没有第二轮。 老板怕只有一次机会，于是现在就要所有功能。一个小而能用的第一版，才是最稳妥地换来第二轮的方式。
• 含糊的词。 “好用”“完整”“灵活”无法测试，所以永远做不完。具体的任务才能做完。
• 靠猜而不是靠观察。 在没人用过系统之前选定的功能都只是猜测。真实使用才会显示哪些重要。
• 隐藏的额外工作。 听起来很小的功能，例如多语言、多种用户类型、与其他软件对接，或者在网络应用之外再做手机应用，每一项都可能带来很大的隐藏工作量。

第一步：用一句话写出问题

在列功能之前，先写一句这样的话：“[谁]在[什么事]上遇到困难，这让我们[损失了什么]，当[可观察到的变化]时，我们就知道问题解决了。” 如果一句话说不清，说明这仍然是好几个项目。

比较两种写法。“我们想要一个管理生意的应用”只是愿望，没人知道什么时候算完成。“客户总是打电话问维修好了没有，员工花很多时间找纸质单据，当员工能在几秒内找到任何一张工单并告诉客户状态时，问题就解决了”，这才是可以开发、可以测试的问题。

把这句话放在每份文件和每次会议的最前面。当一个新想法无助于解决它，这个想法就属于以后清单。

第二步：“一个用户，一件事”的取舍

大多数生意想法涉及好几类人：老板、经理、员工、客户、供应商。第一版如果想服务所有人，规模就会爆炸，因为每一类人都需要自己的页面、规则和测试。

相反，选择一个用户和一件事：

• 一个用户：使用系统最频繁、或者最痛的那个人。系统对他有用，您就有了价值的证明。
• 一件事：该用户必须能从头到尾完成的一项任务，例如接收一张维修单，之后能再找到它。
• 一条终点线：您能亲眼看到有人用真实信息、不需要帮助就能达成的结果。

其余的，包括老板的总览、客户自己的页面和报表，都有道理，但放在后面。把其他用户放一放，不等于忘记他们，而是请开发方避免做出以后会挡住他们的选择，等第一件事跑通后再做。谁能查看和修改什么，是另一个话题：定制业务系统中的用户角色与权限。

第三步：把想法分成必须、应该和以后

现在把每个人的每个想法都写下来，先不评判，再逐条归类。这是一种常见项目管理方法 MoSCoW（必须、应该、可以、不做）的白话版。第一版用不到四个类别，所以这里只用三个。

对“必须”要严格。关于这种方法的资料指出，“必须”和“以后”很容易达成一致，争论多发生在“应该”。如果您的必须清单对一个用户一件事来说超过寥寥几项，请再问一次更难的问题：没有这一项，他们能完成那件事吗？ 如果能，它就是“应该”。

也请开发方标出那些看起来小、其实不小的项目，例如与其他系统的对接或第二种语言。在接受报价之前发现意外，成本最低。

一个虚构的示例：维修店的工单跟踪应用

这个例子是为了说明方法而虚构的。它不是真实客户、真实项目，也没有真实价格。设想一家小型维修店，只有一个柜台和两名技师，修理手机和小家电。工单写在纸上，客户通过电话和 WhatsApp 询问进度。

• 问题一句话：客户总是问维修好了没有，员工花时间找单据；当任何一张工单都能在几秒内找到并告知状态时，问题就解决了。
• 一个用户：柜台员工。
• 一件事：接收维修单，之后能找到它并告诉客户进展。

第一版就是五个必须项。它并不惊艳，而这正是重点：做好后几天内就能在真实柜台上测试，店家也会知道以后清单里哪一项才是真的缺。

一个四周时间盒的示例

这是规划练习的示例，不是 Gotka 的承诺，也不是典型工期。时间盒的意思是先定下时间，再把范围缩小到放得进去，而不是先定范围再指望时间配合。您可以要求任何开发方按这样的时间盒评估您的必须清单，再把他们的回答与书面报价对照。如果开发方说您的必须项需要更久，请问是哪些项目造成的，先删减清单，再考虑压缩进度。

请留意这个示例保护了什么。开发拖延时，测试那一周不会被压缩，缩小的是必须清单。您自己的回应同样重要：第二周决定得慢，任何进度都会被拉长。至于第三周该怎么做，请见接受定制业务系统之前如何检查和测试。

该推迟什么，以及为什么

有四类功能最常在第一天就被要求，也最常更适合放到以后。

• 报表和仪表板。 报表需要真实数据才有用，而您现在还不知道自己想看哪些数字。一开始先把清单导出到电子表格。等问题清晰了，再看业务仪表板与报表。
• 与其他系统的对接。 每一个与会计、网店、消息或电子发票的对接，都会在两边增加工作量和新的出错点。先保留手动步骤，等流程稳定后再自动化。
• 额外的角色和审批。 先从老板加一类员工开始。等真实使用显示需要时，再加经理、分店限制和审批步骤。如果您的业务本来就需要严格分权，请在需求说明里写明。
• 视觉打磨。 自定义配色、动画、花哨的新手引导和额外语言会让系统更舒服，但并不证明它能用。现在做到清晰整洁即可，以后再打磨真实用户抱怨的地方。

有两个决定值得在删减之前认真想：做网络应用还是手机应用（见网络应用与手机应用），以及没有网络时是否必须能用（见离线使用）。两者都会改变开发规模，所以在第一周就定下来，不要拖到第三周。安全基础也不是打磨；请见定制业务系统的安全基础，适用的部分要留在必须清单里。

如何拒绝范围蔓延

范围蔓延是指范围确定之后，“小”请求一点点地加进来。它很少以要求的形式出现，更多是聊天里的一句“能不能顺便……”。如果您备好了说法，也有地方安放这个想法，拒绝就容易得多。

• “可以，放进以后清单。” 想法得到尊重，没有丢，也不在现在做。
• “要拿掉什么才放得下它？” 加入新东西，就要拿掉差不多大小的东西，否则日期顺延。这句话也要对自己说。
• “它为我们那一个用户解决什么问题？” 回看问题一句话。如果答不清楚，就先等一等。
• “能不能先手动做一个月？” 手动变通不花钱，也能看出这项功能是否真的需要。
• “上线后再看。” 真实使用给出的答案，比会议室里的猜测好。

请指定一个人，通常是您自己，负责范围。如果五个人都能在聊天里批准新增内容，就没有人在掌控。

养成变更申请的习惯

并非所有变更都不好。开发过程中的真实发现，是调整计划的正当理由。关键习惯是有意识地、用书面方式去改。变更申请是一张简短的书面说明，半页纸就够：

• 内容：变更是什么，一两句话。
• 谁提出，为什么：它为那一个用户解决了什么问题。
• 不做会怎样：等待的真实代价。
• 对价格和日期的影响：由开发方在动工之前填写。
• 决定和日期：批准、与其他项目互换，或移到以后，并写明决定人。

每周做一次简短的复盘，集中处理未决请求，而不是逐个即时回应。把以后清单放在同一个地方，让“我的想法去哪了”始终有答案。上线后如何处理变更，见上线后的缺陷与变更；不同计价方式如何对待变更，见固定价格与按小时计费。

开发前先写好验收标准

验收标准把“完成”变成任何人都能测试的陈述。为每个必须项写一条或多条，用简单的话，针对真实任务，不要用形容词。以维修店的例子来说：

• 柜台员工可以建立含姓名、电话、物品和故障的工单，系统给出工单号。
• 员工可以用电话号码或工单号再次找到这张工单。
• 技师可以把状态从已接收改为维修中再改为已完成，柜台能看到新状态。
• 三名员工各用自己的登录，工单上显示最后是谁改了状态。
• 关闭并重新打开系统后，之前输入的所有工单仍然存在。

避免“快”“简单”“用户友好”这类标准，除非为它们附上任务和人：“新员工听完五分钟讲解后能独立建立一张工单”可以测试，“好用”则不行。必须项通过就验收第一版，而不是等每个愿望都实现。完整流程见验收测试指南。

该向开发方问的问题

把这份清单带到第一次会面。好的开发方会欢迎这些问题；回避的回答本身也是有用的信息。

• 您能否按我选定的时间盒评估我的必须清单，并告诉我哪些放不下？
• 我的必须项里，哪些比看起来更大，为什么？
• 您会把什么留给第二版，并且会避免做出挡住它的选择吗？
• 变更如何提出、报价和批准？我能看一份变更申请样本吗？
• 报价单里写明哪些不在范围内？
• 在最后日期之前，我能在什么时候看到并测试什么？
• 包含几轮测试和修正？什么算修正，什么算变更？
• 为保住进度，您需要我做什么，要多快？
• 以后清单怎么处理：您会保留吗？我能用它来要第二份报价吗？
• 最后代码和数据归谁？见源代码所有权。

收到报价后，先比较范围；如何比较定制软件报价介绍了方法，第一次沟通前要准备什么则说明该带哪些资料。

常见错误

• 把所有东西都叫必须。 如果一切都是必须，就没有必须。请用检验问题。
• 只定时间，从不缩范围。 时间盒只有在范围缩小到放得进去时才有效。
• 压缩测试。 为省时间跳过真实用户测试，只是把问题挪到上线当天。
• 只让老板一个人测试。 最了解系统的人，恰恰是最差的测试者。
• 在聊天里同意变更。 口头的“小”新增，正是预算和日期跑偏的原因。
• 从不写以后清单。 被丢掉的想法会变成抱怨回来，写下来的想法可以等待。
• 把上线当作结束。 第一版是学习的开始；请在上线几周后安排一次复盘。

Gotka Technologies 的角色

Gotka 的应用与系统开发服务开发手机应用、网络应用和业务系统，网络应用和仪表板的参考起价为 RM8,000，业务系统和集成为 RM12,000，手机应用为 RM15,000，均在评估您的需求后以书面报价为准。本指南是一般性建议，不说明 Gotka 的任何交付时间。上文的四周计划是可与任何开发方使用的示例；真实的时间表只来自书面报价。如果您想一起梳理您的必须清单，欢迎联系我们。

关于成本与适用性的相关阅读：手机应用成本由什么决定和您需要手机应用的迹象。

本指南中的关键术语

• 第一版：让一个用户完成一件真实任务的最小发布版本。
• 范围：写明将做和不做什么的书面清单。
• 范围蔓延：通过未记录的小新增，范围慢慢变大。
• 必须、应该、以后：对想法的白话分类，基于 MoSCoW 方法（必须、应该、可以、不做）。
• 时间盒：固定一段时间，把范围缩小到放得进去，而不是反过来。
• 变更申请：范围确定后，对新增或修改某项内容的书面提议，附带对价格和日期的影响。
• 验收标准：简单、可测试的陈述，用来界定每个必须项何时算完成。
• 问题清单：测试中发现的问题清单，分为马上修和可以等。