IT研发外包：固定总价 vs 按人天，到底哪个更常见？
这问题其实挺有意思的，每次跟朋友聊起外包，或者自己公司真要启动个项目，总会绕回这个点上：到底该跟外包公司签个固定总价（Fixed Price）的合同，还是老老实实按人天（Time & Materials）算钱？
说真的，这事儿没有一个能拍着胸脯说“绝对就是这个”的标准答案。它不像问“北京到上海高铁多少钱”那样直接。这更像是在问“租房好还是买房好”，各有各的理，也各有各的坑。但如果我们非要从“更常见”这个角度来掰扯掰扯，其实行业里是有大体趋势和默认规则的。
先聊聊大家最熟悉的“固定总价”
固定总价，说白了就是“一口价”。你把需求文档（PRD）拍在桌上，外包公司看完，评估完工作量，给你报个总价，比如“这个项目，50万，三个月交付”。只要需求不变更，这50万就是板上钉钉的事儿。
这种模式对甲方（也就是出钱的一方）来说，吸引力太大了。为什么？
- 预算可控：这是最大的定心丸。财务做预算的时候，直接就能把这笔钱划出去，不用担心项目拖个半年一年，成本像滚雪球一样越滚越大。
- 风险转移：项目开发过程中，技术难题、人员变动、效率问题，这些风险理论上都转移到了乙方（外包公司）身上。他们得自己想办法在50万的预算内把活儿干完，不然就得自己扛亏损。
- 目标明确：对于需求非常清晰、边界特别明确的项目，固定总价简直是天作之合。比如，开发一个简单的电商小程序，功能列表写得清清楚楚，UI设计稿也定稿了，这种活儿最好算钱。
听起来很美，对吧？但现实往往没那么简单。固定总价模式能成立，有一个最最核心的前提：需求必须在项目开始前就完全固定下来。
可是在IT研发这个领域，尤其是软件开发，需求变更简直就像呼吸一样自然。市场在变，用户在变，老板的想法也在变。今天说要加个功能，明天说这个按钮换个位置，后天又觉得整个交互逻辑要推翻重来。每一次变更，在固定总价合同里，都意味着要重新谈判、要走变更流程、要加钱。这个过程非常痛苦，扯皮、吵架、项目延期，很多不愉快都源于此。
而且，对于乙方来说，固定总价也是一场赌博。为了保住利润，他们必须在报价时把所有可能的风险都考虑进去，留出足够的“安全垫”。这往往会导致报价偏高。更糟糕的是，有些不那么靠谱的乙方，为了在固定价格内完成项目，可能会在质量上“偷工减料”，或者用一些经验不足的新人来练手，最后交付一个勉强能用但隐患重重的“坑”。
再来看看“按人天计费”的模式
按人天计费，或者叫“时间和材料”（Time & Materials），模式就简单粗暴得多。你不用一开始就把所有细节都定死，而是根据实际投入的人力和时间来付费。比如，一个高级工程师一天2000块，一个测试一天1500块，他们在这个项目上工作了多少天，你就付多少钱。
这种模式在什么情况下更常见呢？
- 敏捷开发和探索型项目：当项目本身具有不确定性，需要“摸着石头过河”的时候。比如，公司想做一个创新性的产品，但市场反馈未知，需要快速开发一个MVP（最小可行性产品）去验证。这时候，固定总价根本没法报价，只能按人天算。
- 长期维护和迭代：项目上线后，需要持续的功能更新、bug修复和性能优化。这种工作很难预估未来一年的具体工作量，按人天合作就非常灵活，需要人的时候就投入资源，不需要的时候就暂停。
- 人月神话：当项目复杂度高，需求模糊，或者需要外部专家提供咨询和指导时，按人天计费能确保你买到的是“智慧和经验”，而不是一个固定的交付物。布鲁克斯在《人月神话》里早就点明了，软件开发的进度和人力投入不是简单的线性关系。
对甲方来说，按人天最大的好处是灵活。需求可以随时调整，团队可以随时增减，永远能保证资源用在刀刃上。你也能深入参与到开发过程中，随时查看进度，把控质量。
但它的缺点也同样致命：预算不可控。这就像去餐厅吃饭，不点套餐，而是单点，最后吃完才知道花了多少钱。如果乙方管理不善，或者故意拖延工期，那你的账单就会变成一个无底洞。这对甲方的项目管理能力提出了极高的要求，你必须非常清楚自己要什么，并且有能力监督乙方的工作效率和质量。
那么，到底哪个更常见？
如果非要给一个答案，我的观察是：在当前的IT研发外包市场，按人天计费（或类似的按时间计费）模式正在变得越来越普遍，甚至在很多场景下已经成为事实上的首选。
这听起来可能有点反直觉，毕竟甲方都想要预算确定性。但现实是，行业在进化。
为什么会出现这种趋势？
- 拥抱不确定性：现代商业环境变化太快了，VUCA（易变、不确定、复杂、模糊）时代，没人能保证一个为期半年的项目需求从头到尾不变。与其在固定总价合同里为了变更而无休止地扯皮，不如用按人天的方式，让合作更顺畅，快速响应市场。
- 敏捷开发的普及：Scrum、Kanban这些敏捷方法论已经成为主流。敏捷的核心就是小步快跑、快速迭代、持续交付。这种模式天然就和按人天计费的“持续投入”理念相匹配，而和固定总价的“一次性交付”格格不入。
- 对“人”的价值的回归：企业越来越认识到，软件开发不是简单的搬砖，而是高度依赖人的智慧和创造力的脑力劳动。购买“时间”和“经验”，比购买一个“固定的盒子”更能保证最终产品的质量和创新性。你是在和一个团队合作，而不是在和一个工厂下单。
- 信任关系的建立：好的外包合作，本质上是建立长期的信任关系。按人天模式，如果乙方是靠谱的，他们会努力提高效率来帮你节省成本，因为好的口碑能带来长期的合作。这是一种更健康的伙伴关系。
一个更精细的观察：混合模式的兴起
当然，现实世界不是非黑即白的。在“按人天更常见”这个大趋势下，还衍生出了一种更聪明的混合模式，这在很多成熟的外包合作中非常流行。
这种模式通常是这样的：
- 大框架按固定总价：对于项目的核心模块、明确的交付物，双方可以先定一个大致的固定范围和价格，作为合作的基础。
- 迭代和变更按人天：在核心框架之外，对于持续的迭代、新功能的探索、以及不可避免的需求变更，采用按人天计费的方式。
- 设定预算上限（Not-to-Exceed）：在按人天合作的部分，可以设定一个“预算上限”。比如，约定这部分工作量不超过100个人天，如果实际用了80天，就按80天结算；如果因为不可控因素用了110天，超出的部分由乙方承担或双方协商分摊。这既保留了灵活性，又给了甲方一定的预算安全感。
这种混合模式，可以说是结合了两种模式的优点，试图规避它们的缺点。它要求甲乙双方有更高的信任度和更成熟的项目管理能力。
如何选择？看这几个关键因素
聊了这么多，回到我们自己身上。当你的公司需要外包一个项目时，该怎么选？别纠结于“哪个更常见”，而要看“哪个更适合你”。你可以拿个表格，自己对着评估一下。
| 考虑因素 | 倾向于固定总价 | 倾向于按人天计费 |
|---|---|---|
| 需求清晰度 | 需求非常明确、详细，几乎不会改变 | 需求模糊、不完整，需要边做边探索 |
| 项目预算 | 预算严格，必须在项目开始前确定总成本 | 预算有一定弹性，更看重最终价值和质量 |
| 项目周期 | 短期项目（1-3个月），时间线明确 | 长期项目，或需要持续维护和迭代 |
| 项目性质 | 标准化、重复性高的开发工作 | 创新型、探索型、技术复杂的项目 |
| 甲方管理能力 | 甲方管理能力较弱，希望“省心” | 甲方有专业的PM或技术负责人，能深度参与 |
| 合作关系 | 一次性合作，对乙方信任度不高 | 希望建立长期战略合作关系 |
填完这个表，你心里大概就有数了。比如，你想给公司做个官网，功能就是展示、联系我们，需求文档写得明明白白，那毫无疑问，找几家外包公司比个固定总价，谁便宜、谁过往案例好就选谁。
但如果你是想开发一个全新的AI应用，市场上没有竞品，技术路径也不清晰，你只是有个想法，想找个技术合伙人一起把它做出来。这种时候，你拿着一个固定总价的需求去找外包公司，对方要么报个天价吓跑你，要么接了活但最后交付的东西完全不是你想要的。这时候，按人天找一个靠谱的技术团队，大家组个联合项目组，一起探索，才是正道。
一个过来人的经验
最后，抛开理论，聊点实在的。在选择外包模式时，比合同模式本身更重要的，其实是选对人。
一个靠谱的乙方，即使在固定总价模式下，也会主动和你沟通风险，透明地展示变更带来的影响，而不是藏着掖着。一个不靠谱的乙方，即使在按人天模式下，也能通过磨洋工、堆人头的方式把成本拉到天上去。
所以，在签合同之前，多花点时间去了解对方的团队。跟他们的项目经理、技术负责人多聊聊，看看他们对你这个项目的理解，问问他们打算怎么做，看看他们过往的案例和客户评价。有时候，一个报价稍高但让你觉得“靠谱、专业、沟通顺畅”的团队，远比一个报价最低但让你心里没底的团队要划算得多。
合同模式是合作的框架，但真正驱动项目走向成功的，是框架之下的信任、沟通和专业能力。所以，下次再遇到这个问题，别再简单地问“哪个更常见”，而是问问自己：“我的项目是什么样的？我需要一个什么样的合作伙伴？” 想清楚这个，答案自然就浮现了。 灵活用工外包
