项目如何推进

软件开发流程，一周一周讲清楚

一个健康的软件项目会经过五个阶段：一次确认双方是否匹配的首次通话，一个把想法变成明确计划的探索阶段，一段以每周增量交付可用软件的开发期，贯穿整个开发的质量工作，以及一次让你拥有全部成果的完整交接。这份指南讲清每个阶段会发生什么、整个过程要多久，以及你在每一步应该能看到什么。如果开发的头几周你还点不到能用的软件，那就有问题了。

预约三十分钟通话

简短回答

软件项目从首次通话走到探索阶段，以每周可审阅的增量交付，最后以文档、测试、可观测性和完整交接收尾。

适合

  • 第一次找软件开发公司的创始人
  • 想比较各家公司实际工作方式的团队
  • 想要可核查的节点、好向供应商问责的买家
  • 不清楚从签约到上线之间会发生什么的人

不适合

  • 已经有成熟内部交付流程、且运转良好的团队
  • 想消失三个月直接来取成品的买家
  • 没有人能参加每周评审的项目
// 01

比较各个选项

健康流程和表演式外包的区别，逐个阶段看。

阶段 健康的项目 危险信号
首次通话

问匹配度和范围，不合适就明确说不。

范围都没界定，当场就给报价。

探索阶段

需求、架构、路线图，最高风险的假设已被验证。

直接跳过，或者一份没人推敲过的付费文档。

合同

范围锁定用固定价格，范围会动用按周付费。

按小时计费，却没有定义交付结果。

开发节奏

每一两周就能点到的可用软件。

状态汇报和燃尽图，就是没有软件。

质量

测试、CI/CD 和监控随代码一起生长。

QA 被塞进上线前的最后两周。

收尾

文档、凭证和一次完整交接。

知识留在供应商手里，你走不了。

// 02

Wavect 的立场

我们的每个项目都遵循同一个形状，因为失败的方式永远是那几种。首次通话三十分钟，先弄清你到底该不该建。有时通话的结局是我们劝你别建。然后，探索阶段 把想法变成需求、架构、路线图，以及对你最高风险假设的验证，EUR 3,500 起，可从尾款中抵扣。

范围摆上桌面后，你选择与确定性匹配的合同：范围锁定就签固定价格的 Werkvertrag，产品还在变化就用可随时按周取消的周付模式。开发以可审阅的增量交付，每一两周就有可用的软件，而不是状态汇报。测试、CI/CD 和监控随代码一起生长，而不是上线前才拧上去。我们的 QA 清单 列出了到那时必须就位的东西。

合作在交接 完整时才算结束：代码带着完整历史进入你的仓库，文档齐全，测试套件和流水线你自己就能跑，每一份凭证都轮换到你名下。一个没有定义收尾状态的流程，本身就是为了让你离不开而设计的。

// 03

成本、风险与周期

探索阶段 EUR 3,500 起可从尾款中抵扣，也是每一份诚实估算的依据。
开发节奏 每周增量从开发早期起，每一两周就有可审阅的可用软件。
整体周期 数周到数月范围明确的 MVP 曾在 6 周内上线。复杂产品要几个月。诚实的人不会在探索阶段之前报日期。
// 04

这里通常会出什么问题

  • 还没人界定范围就签下固定价格，之后为每个改动争吵。
  • 数月杳无音信，然后一次性交付一个偏离目标的成品。
  • 用工单和幻灯片衡量进度，而不是能点开的软件。
  • QA 和文档被推到最后，进度一滑就先砍掉它们。
  • 客户一侧没有产品负责人，决策一拖就是几周。
  • 没有定义收尾状态，交接永远不会发生，你也走不了。
// 05

检查清单

项目的每个阶段，你都应该能核实这些。

  • 一次会质疑你的范围、而不是只顾报价的首次通话。
  • 一个交付需求、架构、路线图并验证最高风险假设的探索阶段。
  • 与你的确定性匹配的合同：范围锁定签固定价格的 Werkvertrag，否则用可随时取消的周付模式。
  • 从开发早期起，每一两周就有可审阅的可用软件。
  • 一个公开定价、公开重排优先级的变更流程，而不是悄悄吞掉范围。
  • 测试、CI/CD、监控和错误追踪在开发过程中建立，而不是事后补。
  • 一次包含代码、历史、文档、凭证和基础设施访问权的交接。
// 06

在我们的工作中是什么样子

同一套流程在真实时间线上的样子：探索、每周增量、完整交接。

PromptID

上线
6周 从零到生产

AI 原生评估平台，在压缩的市场压力下 6 周内从零到生产。

NestJS NextJS LangChain
AI 2026

LivLive

上线
1000+ 并发用户

AR-RWA 平台：通过产品募集 200 万美元+、1000+ 并发用户，整整六周。

Solidity Typescript React
BLOCKCHAIN 2025

这些是精选项目，并非我们的全部作品。自 2018 年以来我们已交付 75+ 款产品。

// 07

什么时候适用，什么时候不适用

// 01

什么时候 Wavect 合适

  • 你要的是可以核实的节点，而不是只能相信的承诺。
  • 你这边有人能每一两周审阅一次可用软件。
  • 你想在结束时拥有代码、文档和基础设施。
  • 你宁要早来的诚实拒绝，不要迟来的一团乱麻。
// 02

什么时候我们不合适

  • 你想扔下一份需求文档，到上线时再出现。
  • 你这边没有人能每周做产品决策。
  • 你的采购流程要求按小时计费和工时表。
  • 你用记录的工时衡量进度，而不是交付的软件。

一个你能一周一周核实的流程，就是雇到伙伴和资助一个黑箱之间的区别。

// 08

相关服务与阅读

// 09

常见问题

实践中是五个：确认匹配度的首次通话，产出范围、架构和路线图的探索阶段，以每周增量交付可用软件的开发期，贯穿全程的测试、CI/CD 和监控等质量工作，以及把代码、文档和凭证移交给你的交接。名字各家叫法不同，可核查的节点不应该不同。
范围明确的 MVP 要数周。我们曾在六周内把产品从零做到上线生产，但这个速度需要收紧的范围和一位果断的产品负责人。集成多或合规要求重的产品要数月。探索阶段之前给出的任何日期都是猜测，所以先定范围，再拿由此得出的日期去要求供应商。
瀑布 先把整个项目规划好，再一次性建完。敏捷 以短周期迭代、边学边调整，最常见的框架是 Scrum 。实践中，健康的项目两者兼用：探索阶段是写代码之前的一小段规划，之后的交付以每周增量按敏捷推进。标签不重要，重要的是在整个软件开发生命周期 里，你能不能定期看到可用的软件。
需求一定会变，健康的流程本来就为此留了余地。小改动通常在当前增量内消化。大改动会得到影响评估、一份标好价格的变更请求，以及和你一起公开重排的优先级。危险信号是那种一改需求就要么吵架、要么预算悄悄超支的供应商。
探索阶段最密集，因为你的回答定义了范围。之后，安排每周一次的可用软件评审，中间保持能做决策的响应度。项目扛不住的是你这边没有产品负责人，因为每一个悬而未决的决定都会拖住工作。
最近审阅: 审阅人Kevin Riedl wiki ↗
预约三十分钟通话