软件项目应该如何正确定价

大多数人都知道按小时计费的缺点，因此转而要求固定价格。如果我们告诉你，软件项目的固定价格其实也没好到哪里去呢？这篇博文写给你，让你下次收到信赖的软件供应商发票时不会被吓到。

首先，每个项目都不一样。我们有按小时计费合作的客户，也有按固定费用合作的客户。但我们最好的经验来自敏捷 固定价格。

在我们看敏捷固定价格之前，先简单聊聊传统定价模式的优缺点：

按小时计费

按实际工作量计费。供应商和客户约定一个固定的小时费率，朝着共同目标推进。项目范围通常定义得比较模糊。

• 对软件外包来说不错，前提是他们低估了工作量。
• 一般来说，预算确定性较低，最终成本可能高于客户预期。
• 另一方面，项目灵活得多，需求变更不会带来额外的官僚开销和项目延期。

固定价格

为项目设定固定价格，要求严格定义清楚。范围外的任务通常按小时计费或单独报价。

• 对软件外包来说不错，前提是他们高估了工作量。对客户来说则不好，因为他们多付了钱。固定价格下，供应商总要加上一份不确定性溢价，免得自己倒贴。
• 整体存在大量不确定性。项目需求必须细到最末端（额外开销），这也让项目在出现新需求时变得非常僵硬。
• 如果供应商低估了工作量，质量会急剧下降，因为再做下去就不够本（见下图）。

"永远不要为了假定的速度而牺牲计划。"

敏捷固定价格

软件供应商中有一个非常普遍的关于敏捷项目管理的误解。敏捷方法并不能免除项目规划的必要，但实际中却经常被这样使用。

因此，我们通常把较大的项目分成 3 个阶段。

几乎更重要的是： 这样你不会变得依赖。每个项目阶段都被安排成让你不会掉进“外包陷阱”。也就是说，你可以随时结束合作，在内部或者换一家供应商继续推进项目，不必从零开始。

1. 发现阶段

在 1-2 周内，我们尽可能多地收集信息，与你共同制定项目战略。这包括变现策略、项目真正的目标（例如降本、向投资人融资，或打造一个能直接盈利、可上市的产品）。

阶段结束时，你会拿到一份概念文档。根据项目规模，长度在 1-5 页之间，这是一份自成体系的交付物，你可以拿着它去找其他外包，或者在内部实施项目。

这份文档不是需求规格说明书，而是覆盖项目的关键要点，包括优先级、时间线、核心功能等通常会被遗漏的内容。

2. 试验阶段

现在动真格了。我们启动你的项目！

在试验阶段，会确定一个小时费率和小时配额。试验阶段让项目能更早开始，并把项目复杂度和真实需求理清。同时，新需求和用户反馈也能被快速响应。

试验阶段中，你会持续收到项目进展更新。此外，进度会在 1-2 周间隔由你或你的一位同事评审，确保项目朝期望方向发展。

一旦小时配额用完，需求和软件现状会被评估。如果定义的项目目标尚未达成，项目就进入“收尾阶段”。

试验阶段的结果不一定是 MVP（“最小可行产品”），但一定是一份自成体系的交付物，含文档，你如果愿意，可以由其他外包或在内部继续推进。如果发现阶段定义的目标是“首位付费客户”，那我们就具体朝这个目标努力。

3. 收尾阶段

如果可能，剩余的项目需求会以 epic 和 user story 的形式定义出来。然后以固定价格提供，提供更强的预算确定性。

之所以可能，是因为各方对项目的优先级和目标都已经清楚。

此外，项目中最大的不确定性通常此时已经被消除。

另请参见：我们对资深工程领导力也采用同样透明的固定价格逻辑，详见 奥地利 Fractional CTO 服务，公开日费率，签署 Werkvertrag（劳务合同）明确范围。