PG官网

  去年有个做物流的客户找我，说他们那套 TMS 上线半年，验收会开了三次都没过。我去他们办公室待了一下午，发现甲方项目经理是老板娘的弟弟，原来是管仓库的，现在每天泡在开发群里，问的都是缓存命中率、消息队列、索引优化这些词，听着挺专业。可我翻了半天，他没记过一次需求变更，没写过一条验收标准。合同附件是一个 Excel，四十七行功能，没有编号，也没有优先级。开发那边的需求池一百三十六条，两边对不上。

  这项目不是做坏的，是管散的。甲方项目经理不需要看懂代码，需要的是四本账，范围、进度、变更、验收。每一本都能落在一张纸上，每周五更新一次。

一、范围账：合同那 47 行，要能和需求池的 136 条对上

  第一件事是把合同附件里的功能清单重新编号。四十七行就编 C01 到 C47，一行一个号，不改原文，只在后面加一列。然后让乙方把需求池拿出来，按 R001 往下编，再加一列对应合同编号。这一列空着的，就是合同外的新增；一列对不上两个号的，说明合同里那条被拆过；一个合同号对着一堆需求的，说明乙方拆得比合同细，正常。

  这张表拉出来，通常当天就能看出问题。有的功能合同写了但需求池没有，那是漏做；有的需求池有但合同没有，那是有人口头答应了。两种都要当周摆到桌上说清楚，别等到验收再翻。

  状态那一列也有讲究，不要用百分比。客户管理已完成百分之八十这种话没法验收，也没法追。用四个状态，未开始、开发中、待测试、已验收，每周五更新，谁改的谁署名，改完发群里。看这张表就知道项目走到哪，比听汇报靠谱。

  还有两个细节容易漏。合同里写明免费修改包含几轮，原型两轮、UI 两轮、整体两轮，这个轮要落到表上，改到第几轮标出来，超了就是变更。谁提的需求谁签字，部门负责人签，老板在饭桌上口头说的，让对接人补一条微信确认再进表。口头需求不是不能做，是做完没人认账。

二、进度账：别问做了多少，要能看见东西

  这周做了多少，这个问题没有答案。做了多少是个感觉，看不见也摸不着。乙方说做了五个模块，你没法验；说接口联调完了，你也没法验。要问的是这周有没有东西能拿出来看，看到了才算数。

  里程碑要绑交付物，不绑日期。原型阶段交原型文件，UI 阶段交设计图，开发阶段交接口文档和联调记录，测试阶段交测试用例和缺陷清单，上线前交 UAT 签字和部署记录。每个里程碑后面挂一个具体的文件名，不写完成开发四个字。

  周会别在会议室看 PPT，直接进演示环境点一遍。点不开算没完成，点开是假数据算没完成，点开是空页面也算没完成。这个办法粗，但最有效，乙方也不好意思拿截图糊弄。

  甲方自己的事也要进账。服务器谁买、域名备案谁提、支付商户号谁申请、短信签名谁报、等保测评排到什么时候、历史业务数据谁整理，这些都不在乙方合同里，但一样卡进度。我见过一个项目，代码写完两个月上不了线，卡在备案。这种事写进进度账，标上责任人和截止日，每周过一遍。

延期必须写原因，不写就默认是乙方的问题。原因也要分清楚，是需求没定，是甲方资料没给，是第三方接口没开，还是人手不够。写明白下次才知道该改哪一头。

三、变更账：口头说的，都要落成一张单

  项目做到一半，需求一定会变。这不是乙方不专业，是业务在动。一个月改十几条很正常，改了没人知道才麻烦。真出问题的是变了没人记，做完才吵。

  变更单不用复杂，一张纸四栏就够，改什么、影响哪些模块、加多少钱、延几天。四栏填不满，这张单不成立。很多时候填到第二栏就发现，这个改动要动权限、动报表、动导出，牵一发动全身，提的人自己就撤了。

  金额要提前定阈值。五个人天以内的打包到月底一起结，不然一张单五十块钱也要走流程，谁都烦。超过五个人天单独报价，报价单附在变更单后面。阈值写进合同，后面就不用一次一次谈。

  最要紧的一条是不签字不动工。先做后补单，最后一定扯皮。乙方说我都做完了你还不认，甲方说我没让你做，这种事没有对错，只有流程。可以让乙方先评估，评估单出来签字确认，再排期。

  每月把变更金额汇总一次，发给双方老板。很多项目到后期追加的费用能到合同额的百分之二十，老板看到这个数字才知道真实成本。平时不说，最后一起算，谁都接受不了。

四、验收账：标准要在开工前写死

  验收会开成吵架会，多半是标准没提前写。合同里那句符合甲方需求等于没写，因为需求本身就没定义。你觉得不对，他觉得对，谁手里都没有依据。

  最稳的办法是按范围账那四十七条逐条过。每条写清楚怎么做算通过、谁来看、看完签哪一栏，四十七条过完，验收单也填完了。这张单子提前发给双方，开会时只对结果，不对定义。

  性能要写具体。五十个并发响应三秒以内，两百个并发五秒以内，这是能测的。写系统响应迅速没法测。测的时候用正式库的数据量，别拿二十条演示数据跑，一千万条订单和二十条订单是两回事。

  安全看三样，权限、日志、备份。哪些角色能看哪些数据，操作日志留多久能不能查，备份多久一次、恢复演练做过没有。这三样平时不显眼，出事的时候全靠它们。

  文档要清单化。部署手册、接口文档、账号清单、数据库字典，四样缺一不可。账号清单尤其重要，服务器、数据库、第三方平台、短信后台，一个个列出来交，别只给一个管理员账号就完事。

  UAT 用例让乙方写，甲方确认，业务人员执行。乙方最清楚功能边界，甲方最清楚业务怎么走，业务人员才知道点下去顺不顺手。三方各干各的，别让项目经理一个人替业务签字。

  缺陷分四级，阻断、严重、一般、建议。前两级修完才能上线，后两级进遗留清单，双方签字，约定什么时候修。不分级的结果是所有问题一样重，谁也不肯让步。

  验收款绑验收报告，不绑上线。报告签字、资料移交，两件事都完成才付款。上线只是开始，后面还有三个月到半年的稳定期，尾款留一部分在那儿，比什么承诺都管用。

最后，四本账合成一张表

  四本账不用四个文件，一个 Excel 四个页签就够。范围、进度、变更、验收，每周五下午更新一次，发到双方老板和项目对接群。

  这件事不复杂，一周花不了两个小时。难的是坚持。项目一忙，第一个被砍的就是这个会。可项目散掉，往往就是从这几周没更新开始的。

  甲方项目经理不用看懂多少技术。让每件事有记录、有人认、有下文，项目就散不了。这四本账记满一个项目，下一任接手的人翻一遍也能看懂。