三个开发者针对同一份需求分别报出 40,000、90,000 和 250,000 的价格，通常并不是因为他们对自己的费率意见不一致，而是因为他们报价的是三个不同的产品，因为这份需求允许三种解读。
价格差距为何会出现
一份写着“用户可以上传文档”的需求，会把所有高成本决策都留空。文件可以多大？支持哪些格式？是否需要病毒扫描？是在浏览器中预览，还是只能下载？需要版本管理吗？谁可以看到谁的文件？数据保留和删除如何处理？
谨慎报价的开发者会采用简单的解读。防御性报价的开发者会假设复杂的解读，并据此定价。两者的做法都合乎情理。买方则会认为高价报价是在漫天要价，选择低价方案，随后在开发过程中发现差距，而这时它就会变成一项变更请求。
必须明确的五件事
- 用户角色以及每个角色可以执行的操作。不要只写“管理员和用户”，而要列出每个角色可以执行的操作。在大多数业务应用中，权限逻辑占据了相当大一部分工作量，但它在功能列表中通常是不可见的。
- 主要工作流程，逐步说明。写清楚用户实际经历的步骤，包括出现问题时会发生什么，例如付款被拒、会话过期或重复提交。
- 数据。需要存储什么、哪些字段必填、适用哪些校验规则、数据保留多长时间。字段列表比页面描述更有用，因为页面会变化，而数据不会。
- 外部依赖。支付、消息、地图，以及需要连接的现有系统。每一项都会带来审批时间和故障处理工作，这些都必须纳入预算。
- 验收标准。你将如何判断产品已经完成。这是最常被遗漏的部分，也是最能避免争议的部分。
用数字说明规模和性能
“应该很快”和“应该能够处理大量用户”无法用于报价或测试，而数字可以：
- 第一年预计的用户数，以及高峰期的并发用户数。
- 一年后最大数据表中预计包含的记录数。
- 最慢的常见操作可接受的响应时间。
- 文件大小和总存储容量。
这些因素会改变架构。为 200 名用户设计的应用，与为 200,000 名用户设计的应用，在数据库设计、缓存和托管成本方面都不同；如果实际只需要前者，却构建了后者，就会浪费本可投入功能开发的资金。
规格说明中不应包含的内容
有两类内容会让规格说明变得更糟：
技术选型，除非存在真实约束。仅仅因为有人推荐过某个框架就指定它，会限制开发者提出更合适方案的能力。如果确实存在约束，例如已有系统或必须负责维护该系统的内部团队，应说明约束本身，而不是直接写出结论。
功能规格中的像素级设计。设计与功能最好分开。将两者混在一起的规格说明会让双方都更难审核，并把每个视觉偏好都变成功能变更。
之后最容易引发争议的部分
通常按以下顺序：
- 报表。需求中的“报表”一旦明确字段、筛选条件、分组方式和导出格式，往往每份报表都需要一周的工作量。
- 通知。电子邮件、短信、推送和应用内通知是四种不同的实现方式，也对应四种不同的成本。“系统会通知用户”实际上没有明确其中任何一种。
- 搜索。搜索一个字段很简单；但跨相关记录搜索并进行排序，则是一个独立的项目。
- 迁移。导入现有数据几乎总是比预期更困难，因为旧数据存在各种无人记录的不一致问题。
即使只用几句话，也应在规格说明中明确写出这四项内容，这样就能将它们从假设变成范围。
一种实用方法
一份适用于小型项目的实用规格说明通常为五到十五页，包括角色列表、工作流程说明、数据字段、集成列表、非功能性指标、验收标准，以及明确的范围外事项。
最后这一部分的作用远超其篇幅所显示的程度。写下“列出的三个界面之外的报表功能不在本阶段范围内”只需一行文字，却能消除之后一整类争议。
Manboo 相关服务
- Flutter 应用开发，适用于 iOS 和 Android MVP。
- 业务软件开发，适用于 CRM、预订、库存和工作流系统。
- 管理面板开发，适用于运营仪表板和后台管理。
- AI API 集成，适用于产品准备实现智能搜索、聊天或自动化的场景。
- 申请范围审查和项目估算，适用于准备规划第一个版本的场景。