聊聊IT研发外包：到底是选固定价，还是人天制？这事儿得掰开揉碎了说

嗨，朋友。如果你正在看这篇文章，大概率是你手头有个项目，可能是公司的新系统，也可能是个App，自己团队搞不定或者不想自己搞，想找个外包。然后，你就遇到了那个经典的选择题：跟外包公司聊的时候，他们问你，“老板，咱们是走固定总价，还是按人天算？”

这个问题，说大不大，说小不小。选错了，轻则预算超支、项目延期，重则项目烂尾、团队散伙，最后闹得一肚子气。我见过太多朋友在这上面栽跟头，也跟不少外包公司的老板、项目经理聊过。这事儿吧，它不是个简单的数学题，更像是一场心理博弈和风险管理。

今天，咱们不扯那些高大上的理论，就用大白话，像朋友聊天一样，把这两种模式掰开揉碎了聊聊。我会尽量把我知道的、踩过的坑、看到过的案例，都给你说明白。看完之后，你心里大概就有数了。

先搞明白，这俩模式到底是啥玩意儿

别笑，很多人其实概念是模糊的。咱们先用最朴素的语言定义一下。

固定价（Fixed-Price）

这个最好理解。就像你去装修房子，跟包工头说：“这活儿你包了，全屋刷白、铺地砖、走水电，总共2万块，干完验收合格就给钱。”

放到IT项目里，就是你把你的需求（功能列表、设计稿、技术要求等）尽可能详细地列出来，外包公司根据这个文档，评估需要多少人、干多久、花多少成本，然后给你报一个总价。一旦合同签了，只要你的需求不变，这个价格就不变。风险主要在乙方（外包公司）那边，他们得想办法在预算内把活儿干完，否则就得自己扛亏损。

人天制（Time & Materials，简称T&M）

这个也好理解。就像你请个钟点工或者律师，按小时收费。你跟外包公司说：“我需要一个前端、一个后端，每天来我公司上班（或者远程），按天算钱，干一天给一天的钱。”

具体来说，就是外包公司给你配置几个工程师（比如Java工程师A元/天，UI设计师B元/天），他们每天的工作时间、产出都记录下来，按月结算。你用多少资源，付多少钱。风险是共担的，但主要风险在甲方（你）这边，因为项目的总成本是不确定的。

好了，基本概念清楚了。下面我们进入正题，怎么选？

固定价模式：一把“双刃剑”

很多人，尤其是第一次做外包的甲方，特别喜欢固定价。为什么？因为感觉安全啊！

固定价的“甜头”：为什么它那么诱人？

• 预算可控，心里踏实：这是最大的优点。对于公司内部审批流程复杂、预算卡得死的项目，固定价简直是“救命稻草”。你可以明确地跟老板说：“这个项目，总投资50万，误差不超过5%。”老板一听，高兴，批了。你也不用担心项目干到一半，钱不够了要去追加预算。
• 目标明确，交付导向：合同里白纸黑字写着交付物（比如一个能正常使用的App）。乙方的目标很清晰，就是把东西做出来给你。作为甲方，你只需要在关键节点（比如原型确认、开发完成、上线）进行验收就行，不用天天盯着他们几点上班、写了多少行代码。
• 乙方会想方设法提高效率：因为利润是固定的，乙方为了多赚点钱（或者至少不亏钱），会尽可能优化流程、使用成熟的方案、避免不必要的返工。他们会比你更着急把项目赶紧做完交付。

固定价的“苦果”：那些你不得不防的坑

听起来很美，对吧？但现实往往是骨感的。固定价模式下，甲方乙方很容易站到对立面。

• 需求变更的噩梦：这是固定价模式最大的痛点，没有之一。市场在变，你的想法也在变，项目进行中，你突然发现“哎，这个功能好像不太对，得改一下”、“能不能加个按钮，实现XXX？”。这时候，你去找外包公司，他们会微笑着拿出合同，指着条款说：“亲，这个属于范围变更哦，需要重新评估报价。” 一次两次还好，改得多了，你会发现，最后的总价可能比当初的人天报价还高，而且每次变更都要走流程、重新谈判，时间成本巨大。
• 质量可能被“压缩”：乙方也是要赚钱的。如果项目初期他们为了拿下订单，报了一个偏低的价格，或者过程中遇到了技术难题导致工时超预期，他们怎么办？为了保住利润，他们可能会在你看不到的地方“偷工减料”。比如，代码写得能跑就行，不考虑可维护性；测试环节能省则省；文档干脆不写或者随便糊弄一下。项目刚交付时可能没问题，但用半年，各种bug就冒出来了，想二次开发，发现代码像一坨屎，根本没法下手。
• 前期沟通成本极高：为了锁定价格，乙方会要求你在项目开始前，把所有需求细节都定义得清清楚楚。你需要花大量时间写PRD（产品需求文档）、画原型图、开无数次会来确认每一个按钮的交互逻辑。这个过程非常痛苦，而且你很难在一开始就考虑到所有情况。很多细节，你只有在看到实物后才知道自己想要什么。
• 容易陷入“合同陷阱”：有些不靠谱的外包公司，会利用信息差，在合同里埋下伏笔。比如，他们故意把需求写得模棱两可，等你验收的时候，他们说“合同里没写要包含这个呀”，或者把一些关键的技术指标（比如响应时间、并发数）模糊处理。最后扯皮起来，你非常被动。

固定价适合什么场景？

总结一下，固定价模式适合那些：

• 需求非常清晰、明确、且几乎不会变更的项目。 比如，一个简单的活动宣传页，功能固定的小工具，或者对现有系统进行一次性的、明确的功能补充。
• 预算极其严格，必须在启动前锁定成本的项目。
• 项目规模不大，周期较短（比如1-3个月）。 时间越长，需求变更的可能性越大，固定价的风险就越高。

人天制模式：一场“信任的冒险”

说完了固定价，我们再来看看人天制。很多资深的甲方和乙方其实更偏爱这种模式，因为它更灵活，也更接近软件开发的本质。

人天制的“魅力”：为什么它更灵活？

• 拥抱变化，敏捷开发：这是人天制的核心优势。市场瞬息万变，你的产品也需要快速迭代。今天发现一个新机会，明天就可以让团队调整方向。你不需要为了一个小改动去走繁琐的变更流程，只需要跟项目经理打个招呼，他们就可以在下个迭代里安排上。这种灵活性对于互联网产品来说，至关重要。
• 成本更真实，所见即所得：你花的每一分钱，都对应着实实在在的人天。外包公司没法在价格上做文章，他们要赚钱，就必须保证团队的效率和产出。同时，因为成本是按实际发生的算，你也能更清楚地看到项目的真实投入，避免在固定价模式下，乙方为了控制成本而牺牲质量。
• 更像一个团队，而不是甲乙方：在人天制下，你和外包团队的关系更像是“战友”。你们的目标是一致的：在有限的资源下，把产品做到最好。你可以更深入地参与到项目管理中，每天开站会，随时了解进度，及时发现问题。这种紧密的合作关系，更容易打造出高质量的产品。
• 启动速度快：不需要前期花几个月去写几十页的需求文档。只要有个大概的方向和第一期的目标，就可以先组建团队开始干了。在干的过程中，慢慢细化需求。这对于抢占市场先机的项目来说，是巨大的优势。

人天制的“风险”：无底洞的恐惧

人天制的缺点，对于甲方来说，也是致命的。

• 成本不可控，容易变成“无底洞”：这是所有甲方最担心的。项目开始后，感觉就像开着一辆没有油表的车。干了一个月，花掉10万，但项目好像才完成了一半。再干一个月，又花10万，还没做完……最后到底要花多少钱，谁心里都没底。对于预算有限的公司，这简直是噩梦。
• 对甲方的管理能力要求极高：你不能当甩手掌柜。你必须深度参与，清楚地知道团队每天在干什么，进度是否正常，有没有在做无用功。你需要有能力判断他们的工作量是否合理，代码质量是否过关。如果你自己不懂技术，又没有一个靠谱的项目经理帮你盯着，很容易被外包团队“带节奏”，白白浪费时间和金钱。
• 容易滋生惰性：从乙方的角度看，活儿干得越久，他们赚得越多。在缺乏有效监管的情况下，他们可能会有意无意地拖延进度，或者把简单的问题复杂化，增加不必要的工作量。虽然大部分正规公司不会这么做，但这种机制本身确实存在道德风险。
• 需求范围容易无限蔓延（Scope Creep）：因为变更方便，甲方可能会不断地提出新想法、新需求。今天加个功能，明天改个UI，看起来都是小改动，但积少成多，项目就像一个吹大的气球，永远没有尽头。最后可能钱花光了，核心功能还没做完。

人天制适合什么场景？

同样，人天制也不是万能的，它适合：

• 需求不明确、探索性强的项目。 比如，做一个全新的产品，需要不断试错、快速迭代。
• 长期合作的、持续迭代的项目。 比如，你有一个产品需要长期维护和开发新功能，建立一个稳定的外包团队。
• 项目复杂度高，技术挑战大。 这种项目很难在前期准确预估工作量。
• 甲方有较强的项目管理能力。 你有能力、有时间、有方法去管理外包团队。

实战中的“混合模式”与“第三条路”

聊到这里，你可能会觉得更纠结了。固定价和人天制，各有优劣，好像选哪个都有风险。别急，现实世界里，聪明人早就玩出了花。这两种模式并不是非黑即白，它们可以组合使用，甚至可以演化出新的模式。

1. 混合模式（Hybrid Model）

这是目前最常见也最实用的一种方式。简单说，就是把一个大项目拆分成几个阶段，不同阶段用不同的模式。

• 第一阶段：固定价。 比如，项目启动初期，需要做产品设计、原型确认、技术选型。这个阶段的产出相对明确，可以用固定价模式，锁定前期成本和交付物。
• 第二阶段：人天制。 设计和原型确认后，进入核心功能开发。因为开发过程中可能会遇到各种技术难题，或者需要根据测试反馈进行调整，这个阶段不确定性高，适合用人天制。
• 第三阶段：固定价或人天制。 开发完成后，进入测试、上线和初期运维阶段。如果需求明确，可以打包成固定价；如果需要持续优化，可以按人天结算。

这种模式既保证了前期的预算可控，又给了后期开发足够的灵活性，是目前很多中大型项目的首选。

2. 目标导向定价（Target-Based Pricing）

这是一种更高级的合作模式，需要甲乙双方有很高的信任度。它的核心是：双方的利益绑定在一起。

具体操作是：设定一个共同的目标，比如“在6月1日前上线核心功能，并达到10万用户注册”。乙方的基础报酬还是按人天算，但如果提前完成目标，或者用户数据表现好，乙方可以获得额外的奖金或分成。

这种模式下，乙方不再是单纯的“打工者”，而是项目的“合伙人”。他们会主动思考如何让项目更成功，而不仅仅是完成任务。

3. 专职团队（Dedicated Team）

这可以看作是人天制的一种变体，但更长期、更稳定。你不是按天去购买某个工程师的时间，而是直接“包养”一个完整的团队（包括产品经理、前端、后端、测试等），这个团队在合同期内（比如一年）专门为你的项目服务。

这种模式的优点是团队稳定、沟通高效、对业务理解深入，就像你自己的员工一样。成本上，通常比按天零散地找人要划算。适合有长期、持续开发需求的公司。

决策指南：到底怎么选？给你一张表

说了这么多，我们来个最实际的。当你在纠结的时候，可以从以下几个维度来评估你的项目，然后做个打分。

评估维度	倾向于固定价	倾向于人天制
需求清晰度	需求非常明确、具体、文档化	需求模糊、探索性、需要边做边改
预算限制	预算严格固定，不能超支	预算有一定弹性，更看重最终价值
项目周期	短期项目（1-3个月）	中长期项目（3个月以上）或持续迭代
市场变化速度	产品稳定，市场变化慢	市场变化快，需要快速响应
甲方管理能力	缺乏技术背景和项目管理经验	有专业的PM或技术负责人，能深度参与
对质量的要求	能用就行，满足基本功能	对代码质量、可扩展性、长期维护性要求高
双方关系	一次性合作，信任度低	希望建立长期战略合作关系

你可以根据你的实际情况，看看你的项目更偏向表格的哪一列。如果大部分都在左边，那固定价可能更适合你；如果大部分在右边，那人天制或者混合模式会是更好的选择。

最后，比模式更重要的是什么？

聊了这么多模式，其实我想说，选择哪种模式固然重要，但比模式更重要的，是找到一个靠谱的合作伙伴，以及建立一套有效的沟通和管理机制。

• 选对人，比选对模式更重要。 一个诚信、专业的外包公司，即使在固定价模式下，也会主动跟你沟通风险，而不是埋头干活最后给你一个“惊喜”。同样，一个优秀的团队，在人天制下会用专业和效率赢得你的信任，而不是磨洋工。多花点时间做背景调查，看看他们过往的案例，跟他们的项目经理聊一聊，感受一下他们的专业度和沟通风格。
• 合同是底线，沟通是桥梁。 不管是哪种模式，合同条款一定要清晰。工作范围、验收标准、交付时间、付款方式、知识产权归属、违约责任，这些都得白纸黑字写清楚。但合同是死的，人是活的。在合作过程中，保持开放、透明、频繁的沟通。定期开会同步进度，及时发现问题，共同寻找解决方案。
• 明确你的核心目标。 在开始之前，想清楚你最想要的是什么？是绝对的成本控制，还是产品的快速上线和迭代？是功能的丰富度，还是代码的长期质量？想清楚你的核心诉求，这会帮你更坚定地做出选择，并在后续的合作中做出正确的取舍。

软件外包，本质上是一场合作。它不是简单的“你给钱，我办事”的买卖，更像是两个人合伙开一家店。模式是你们约定的“合伙协议”，但店能不能开好，最终还是看你们俩能不能同心同德，互相信任，一起把遇到的问题解决掉。

所以，下次再有人问你：“老板，咱们是固定价还是人天制？” 你可以先别急着回答，反问他一句：“你觉得我们这个项目，最适合哪种方式？为什么？” 听听他的想法，也许，答案就在对话里了。

企业人员外包