人天计价和项目打包的分水岭，不在价格高低，而在需求是否已经收敛。需求还在变、边界说不清，人天计价更接近真实成本；需求已经写成可验收的清单，项目打包才真正划算。选错计费方式，往往比选贵了更麻烦。
两种模式各自在赌什么
人天计价是把风险留给甲方。用多少算多少，看起来公平，但总价不可控，需求每多一轮讨论、每加一个审批流，都在消耗预算。它的优势是灵活，适合探索型项目，或者甲方自己都没想清楚要什么的情况。
项目打包是把风险留给乙方。总价锁死，甲方预算明确，但前提是需求文档足够细，细到能判断哪些功能包含、哪些属于增项。需求写得含糊就打包，后期要么乙方亏着做、偷工减料，要么不断提出增项，最后总价照样失控。
判断标准其实只有一条
看需求能不能写到可验收的颗粒度。能列出功能清单、明确包含与不包含、说清接口对接几个、历史数据谁负责清洗，就可以打包。做不到这些，硬要打包，报出来的数字参考价值有限，签约后扯皮空间最大。
行业里常见的做法是混合：需求分析和原型阶段按人天计，功能范围确认后转为打包。这样既避免了前期反复讨论被锁死，又让开发阶段有明确的总价约束。
报价单上要盯住的三处
一是功能清单的颗粒度。只写“管理系统一套”的报价，无论人天还是打包，都没法比较。二是持续支出是否单列。服务器、短信、第三方接口年费这些每年都要花的钱，如果被排除在外，总价低只是假象。三是售后和迭代怎么计价。合同内是否含一年免费维护、之后按什么标准收费，这些直接影响长期成本。
比价时不要比总价，要把几份报价拉到同一张表上，逐项对齐功能范围、技术方案、源码文档交付、维护期和验收标准。对齐之后你会发现，有些低价是范围缩水，有些高价是多含了运维和源码。
需求写得越清楚，报价越接近真实成本，后期增项也越少。计费方式的选择，本质上是需求清晰度的选择。
