同一个脚本，我报了两次价

同一个脚本，我写了两回，报了两次价，两次的算法都不一样。

第一次是帮同事的忙。她天天要把报销单据从几个渠道倒腾到一张表里，手工核对，烦得不行，问我能不能写个小脚本自动归拢一下。我心里估摸了一下，这活儿写代码、调格式、测边界情况，怎么也得两三个小时，按外头接私活的行情，两三百块打底。周五下班前我随口说了句"这个大概两三百吧"，她愣了一下，说"不就是个脚本嘛，你们组那谁不也会写"。我没再坚持，最后请她喝了杯奶茶了事。

第二次是一个开网店的朋友。她店里每周要核一次库存，现在是两个兼职周末各花三个小时人工对账，一个月工资成本折下来小一千。这次我学乖了，报价前先问了一句："你们现在核库存是谁在弄、一个月花多少钱？"得到那个数字之后，我没按自己写代码的时间报价，按"一年帮你省下多少人力成本"报了两千。她没还价，转账比我预想的还快。

两回写的都是类似的自动化脚本，写代码花的时间也差不多，一个被觉得贵，一个秒付。真正不一样的，是我拿什么去定价。

第一次报价，我用的锚点是"我花了多少时间"：两三个小时，两三百块，看起来挺合理，其实是把自己的成本当成了对方该付的钱。可对同事来说，我写代码花了多久跟她没什么关系，她在意的是"这事儿归不归我该出钱的范畴"，一旦被归进"顺手帮忙"，两三百就显得多余。

第二次我换了个问法，先问对方原来这件事要花多少代价，再拿这个数字倒推我能报多少。同样两三个小时的代码，套在"帮同事省点手工活"上值两三百，套在"帮网店老板一年省下近万元人力成本"上就能值两千，差着整整十倍。这十倍差在算法上：工时是我的成本，不是对方的收益，这两笔账从来就不是一回事，我以前一直拿前者去定后者该付的价。

这个道理其实圈子里早有人讲透过。写过不少程序员定价文章的帕特里克·麦肯齐（Patrick McKenzie，网名 patio11）二十年前就写过一篇很老的帖子，说工程师普遍习惯按自己花了多长时间报价，而客户愿意付多少钱，从头到尾看的是这件事对他账上值多少钱，跟你花了几个钟头没什么关系。我是干这行的人，这道理听着不新鲜，但真轮到自己报价时，还是下意识先算自己的时间，而不是先问对方的账。

这套算法也不是随便怎么报都行。前提是你得先弄清楚对方原来的代价到底是多少，不弄清楚就瞎猜，两个方向都能出错：猜低了照样按自己工时报，等于白问；猜高了漫天要价，人家一听吓跑，反倒不如老实按工时报的时候还能成交。第二次那单我要是没问出"两个兼职、一个月小一千"这个数，多半也只会照旧报两三百。

还有一条边界，钱到位也解不开：一旦对方把你归进"顺手帮忙"这一类，后面想改口收钱基本翻不了身。我那个同事压根没把这事划进"该花钱"的账本里，那两三百在她眼里根本算不上钱；这时候你报多少，都是在跟她的认知较劲，跟价格没什么关系。同一件事，落在不同人的账本上，价值天差地别——有人愿意为它掏两千，有人觉得它连两百都不值，抠门大方跟这事没关系，是两本账本来就不是同一本账。想在两边都讨好，最后往往是谁的钱都赚得不痛快。

现在再有人开口要我帮忙弄点技术上的东西，我不会先说"这个大概要花我几个小时"，我会先问一句："你们现在这事儿是咋弄的、大概花多少功夫或多少钱？"这句话问出口，报价的锚点就从我这头，挪到了对方那头，这次算的是他省下的账。