在承诺开发前，先拿到明确范围和可靠报价。
这就是软件交付旅程里已有的 Discovery + 路线图：按固定范围付费，把已明确的产品方向转化为架构、里程碑和固定价格的实施报价。
一句话说明服务
Discovery + 路线图是 Wavect 已有的付费软件规划阶段。你会得到架构、里程碑计划和固定价格实施报价；若继续由 Wavect 开发，Discovery 费用会从开发发票中全额抵扣。
适合的起点
- 产品方向已达成一致，但开发范围仍有疑问。
- 需要相关负责人统一优先级和实施限制。
其他下一步
- 需求尚未验证，需要先确认产品是否有人需要。
- 已验收的规格足以直接取得实施报价。
把交付旅程里的 Discovery 讲清楚
Discovery + 路线图与软件开发旅程 及 MVP 定价 展示的是同一个服务。上方服务卡直接读取现有定价中的固定费用、公布时长和抵扣条款，不存在另一套需要比较的 Discovery 套餐。
当产品方向足以进入规划，但用户、流程、集成或架构疑问仍妨碍可靠报价时，Discovery 能把疑问转成明确决策。如果尚未确定是否有人需要产品，可以先通过 Fractional Co-Founder 讨论更早期的需求验证。
路线图必须明确哪些事
发布边界
明确用户、任务和完成该任务的最小版本。记录排除项、可能阻塞交付的依赖，以及负责验收的人。
有理由的架构
说明应用边界、数据责任、集成、访问模型和部署职责。记录技术选择的权衡，以及哪些假设变化会导致重新选择。
里程碑计划
围绕可演示结果安排工作。明确验收决策、客户输入和依赖，用可运行行为而不是完成百分比评估进度。
可评估的实施报价
把固定价格与约定范围对应。保留未知项和排除项，说明需求变化如何在追加委托前进行评估。
带来决策与限制，不需要先写完规格书
带来业务目标、主要用户、现有流程，以及能够决定冲突优先级的人。草图、原型和旧规格即使不完整也有帮助。涉及继承软件时，需要系统概况和了解其限制的人员。
列出集成、访问要求、数据敏感程度、托管限制和真实期限。区分事实与猜测。初步讨论可用代表性或合成示例；凭据和私人客户数据不应发送到咨询表单。
原型能回答导航问题，却不能证明需求。专家审阅与观察真实用户是不同证据。访谈、招募、可用性测试或专项评估需要单独约定方法和范围。Discovery 应揭示这些需要，而不是把它们藏在一次设计工作坊里。
把模糊功能写成团队能测试的需求
已授权的公司用户下载本公司的发票。
通过完整流程能找到并取得正确发票。
每次文档请求都检查公司成员关系。
直接请求他公司发票会被拒绝且不披露内容。
账单系统负责发票及账户映射。
映射缺失或服务不可用时呈现明确可恢复的状态。
先约定文档大小与并发，再确定响应目标。
在明确环境和代表性负载下测量约定分位值。
先支持一个约定格式和一种账户角色。
后续格式和管理功能明确不在首个里程碑内。
如何从问题走到实施报价
确定要作出的决策
明确用户、目标和限制，找出阻碍开发承诺的问题及风险最大的假设。解决影响最大的未知项
讨论关键流程、数据边界和架构。针对明确问题使用原型或技术验证，额外范围需事先约定。共同审查路线图与报价
核对架构、里程碑和固定报价，并与未来验收负责人确认排除项、责任和剩余假设。
可以实施、调整方向，也可以停止
如果由 Wavect 构建产品，Discovery 费用将从开发发票中全额抵扣。你也可以保留路线图，由其他团队实施；公开服务并不要求继续购买开发。开始前应确认交接格式和访问条件，让接手团队真正能使用成果。
可信的 Discovery 可能建议缩小首版、采用标准产品，或停止缺乏支持证据的想法。目标是改善开发决策，而不是让更大的项目显得不可避免。
实施服务见软件开发 ，采购方式可比较固定价格与按时间材料计费 ，也可阅读 Discovery 采购指南 。
从产品决策到软件交付
PromptID 提供公开的产品交付背景。本页需求示例仅用于说明，实际 Discovery 范围取决于你的用户、限制和实施决策。
这些是精选项目，并非我们的全部作品。自 2018 年以来我们已交付 75+ 款产品。