出勤和交付，是两件不同的事
去年秋天，一家做仓储设备的客户找我谈二期。话说得挺客气：希望我们派两位工程师到他们园区，工位留好了，随时沟通方便。我当场没答应，说回去想想。想了两天，回了不行。
那两天我把一期复盘了一遍。一期是远程做的，两个月交付，验收单签得挺顺。二期的需求其实比一期更清楚。我实在找不出「必须坐到一起」的理由，除了他们内部有些人不习惯在系统里写清楚需求，更愿意走到工位边上说一句。
我拒绝的不是驻场本身。我拒绝的是它背后的计价方式。驻场几乎必然滑向人天、人月。一旦按人头算钱，关系就变了：客户买的不是那个功能上线，是我们的工程师出现在他工位上的小时数。
这里有个很难受的错位。我们花力气把部署流程从四十分钟压到八分钟，客户那边看到的是一张没变的人天账单。省下来的时间不产生收入。等于我每做一次效率改进，就是在砍自己的收入。这个激励是反的。我不会骗自己说团队觉悟高、能扛住这种激励——扛不住。
派出去的人，半年后回不来
小周是我带的第一批工程师之一。他被驻到一家制造企业五个月。回来第一次代码评审，他把分支策略忘了，直接推到主干。我没说他，那天晚上有点难过。不是他的问题。五个月里他每天面对的是口头需求、临时会议、上线窗口，没机会碰我们的规范，也没人给他 review。
更实际的问题是，客户后来只认他。邮件发给他，需求找他，出事打他电话。他一休假项目就停。这种绑定对两边都不健康。客户以为买到了稳定，其实买到的是一个手机号。
所以现在有人跟我说「派两个人过去就顺手了」，我听到的是另一句话：你打算用五个月，换掉一个工程师和团队之间的连接。
涉密那类项目，我接，但换个接法
有些环境没有远程这个选项。内网物理隔离，进出要审批，代码带不出来。这种我们接——但按短期封闭开发处理。说清楚几周、交付什么、谁去、怎么轮换。做完就撤，不留人长期待着。
如果客户要的是「常年有人在那儿」，那我们要么不接，要么承认自己是外包公司。这个我不装。
我现在的判断标准，很土
看合同。出现「按人月」「按人天」，或者「配合甲方工作安排」「服从现场管理」，我就先按外包报价，不按项目做。这两句话一出来，验收标准基本就没了，后面所有分歧都会变成态度问题——你态度不好，你不配合。
我知道这条线会让我丢单。可能下个季度就丢一单大的。六个月后我可能发现这个决定是错的：如果市场上客户都这么采购，那就是我们自己把门关上。这个我自己也犹豫过。
但反过来想，我们能卖的东西不多——把一件复杂的事，按约定的时间做完。这件事只有在「结果」被计价的时候才成立。按出勤计价，我们迟早会变成一群很忙、但什么都没交付的人。
明天下午有个远程验收会，我得去把上周那版部署脚本再跑一遍。