有些甲方会想，干脆派个人天天坐在开发公司，进度总能管住了。这个想法方向没错，但执行起来经常走偏，派去的人变成催进度的传声筒，或者反过来被开发方带着走。
要不要派人、派谁去、去了干什么，这三件事值得想清楚再动。
一、什么项目值得派人
金额大、周期长、业务逻辑复杂的项目，派人盯着通常划算。特别是那种涉及多个部门、规则还得边做边确认的项目，现场有个人随时能拍板，效率差别很大。
还有一类是时间紧的项目。工期压得越紧，越经不起来回确认浪费的时间，现场有人能当场答复，等于把沟通成本压到最低。
反过来说，标准化的、需求清晰的小项目，派人反而添乱。开发方每天要花时间陪聊天陪开会，实际产出会下降。
二、派什么样的人
最关键的一条，派去的人必须懂业务，最好有决定权。不懂业务的驻场，开发方问一个业务规则他要打电话回去问，来回一轮就是半天，比远程沟通还慢。
理想人选是业务部门的骨干，熟悉全流程，说话别人认。如果实在抽不出这种人，退一步的做法是安排一个懂技术或者懂项目的对接人，同时约定每天固定时间由业务方在线答疑。
最不该派的是完全不懂业务又没决定权的行政人员。这种情况下的驻场，通常演变成每天问一句做得怎么样了，然后回去汇报一切正常，等上线才发现全是问题。
三、驻场该管什么，不该管什么
该管两件事。一是业务规则的答疑，随问随答，这是驻场最大的价值。二是验收，开发方交出来的每一个阶段成果，当场看，当场提意见。
不该管的是开发过程的细节。用什么技术、代码怎么写、数据库怎么设计、几个人的活怎么分，这些属于开发方的专业范围，甲方插手通常帮倒忙。遇到技术选型确实影响后续维护的情况，可以要求对方解释清楚再做决定，但不要替对方做决定。
还有个容易被忽略的点，驻场的人要有汇报渠道。每周给甲方决策层一份简报，写清楚这周完成了什么、下周要做什么、有没有卡住的地方。光靠驻场的人口头汇报，信息会在传递中失真。
四、没条件派人怎么办
多数甲方派不出全职的人，这时候靠三个机制补。
第一个是固定节奏的例会。每周固定时间开一次短会，开发方演示本周做的部分，甲方当场提意见。会议不超过一小时，重点是看东西不是听汇报。
第二个是可访问的测试环境。要求开发方从早期就开始部署测试环境，甲方随时能自己点进去看。这比任何进度报告都真实。
第三个是变更走书面。任何需求变化都通过邮件或者工单确认，口头说的一律不算。这条能在很大程度上避免后期扯皮，也让甲方内部对需求变化有记录可查。