如今的乙方市场良莠不齐，专业的乙方会让甲方省时省力；但不靠谱的乙方不但不能帮助到甲方，甚至会埋一个大坑给到甲方。那么本期就试着说一下碰到这些不靠谱的乙方该如何应对。

01 欺负甲方不懂技术

有一次甲方公司需要开发一个内部管理系统，当时也不知道管理层如何决定的，最终甲方的项目经理是职能部门的领导，对软件开发是一个彻彻底底的门外汉。乙方项目经理通过几次交流之后，摸清甲方的底子，在评估工程的时候大肆注水，导致远远超出了预算。

这个时候甲方觉得成本无法承担，所以想请一个技术领域的人协助看一下，我有幸被选中参加了启动会。

首先看了他们的工程评估，真是不看不知道，一看吓一跳。一个简单的头像上传居然预估了1周，其他功能就更加离谱了，这样下去这个项目就是个无底洞。

而当我询问乙方项目经理为什么这个功能需要1周的时候，我算见识了对方的口吐莲花。从云存储聊到了前端技术框架，光这个理论给我说了10几分钟。

当然我也从这次交流中察觉到这位项目经理也根本不是技术出身，他东拉西扯地把所有知道的技术专业名词都搜刮了一遍，然后陈述给了我听。当我不动声色地问了他几个云存储的问题之后，他开始顾左右而言他，最后在我的追问下只能说这个方案需要回去和技术人员继续讨论。

在修改了方案之后，消停了一阵子，然后我也开始忙我自己的项目。又过了一段时间，同事又找到我，说已经在测试阶段了，但乙方提出要我们派人一起参加测试，希望我帮着一起看一下怎么安排。

我一开始认为到验收阶段了，甲方做验收测试很正常。谁想到了那里一看才知道，乙方连单元测试都没有做，更离谱的是连单元测试用例都没有。他们希望甲方派人协助他们做单元测试。

后来从乙方项目经理的交谈中了解到，他们的预算见底了，根本没有测试的人头，所以他们想出了让甲方的人参与进来一起帮他们渡过难关。而甲方还真的派了几个业务部门的人员去测试，但由于根本没经过单元测试，这个系统一跑就崩，导致他们几个浪费很多时间在这个阶段。

我当即指出这样的安排是不合理的，要求乙方立即安排人员编写测试用例，并进行单元测试，而甲方人员也应做好验收测试的准备。

最后这个项目是勉勉强强延迟上线了，当然质量就只能暗自祝福了。所以甲方项目经理必须要有一个该领域的人士一起参与进来，否则整个项目将被乙方牵着鼻子走，最后的成本和质量很难被保证。

02 开发没有计划

这点就更为普遍，有的乙方估算工作量的时候都是信口开河，然后真的到了时间又交不出成果物。

再次有幸参与了这样的一个项目。看了他们的开发计划，所有功能预估的时间，小的也起码是一周，大的甚至有半个多月。

我问乙方的开发：“你今天开发这个功能，今天需要做到什么范围，你知道吗”？

他的回答很精辟：“看今天运气是否顺利了，如果顺利就多做一点，不顺利明天再做”。

我：“那如果到时候做不完怎么办”？

他：“那也没办法，延期不就好了”。

评估时间对他们来说其实就是形同虚设，因为有的乙方看出甲方很着急要上线系统，而现在已经开发开始了，不让他们做根本不现实，所以工期就是一拖再拖。

可能有人会说，那很简单啊，不是有合同吗，直接让甲方赔钱啊。这里面的水深了，由于篇幅有限就不在这里展开陈述了，呵呵。

最后解决方案就是，我给他们制定开发计划，最小单位划分到了一天为单位。这样我就能每天监控他们的输出成果，尽量避免出现延期的风险。

所以碰到这种情况，甲方最好是能辛苦一点，积极参与到项目的进度管理和监督管理中，不要到最后验收的时候才发现项目要延期。

03 交付质量差

相信这个是很多甲方诟病最多的一个点，而乙方声誉被毁也大多出现在质量问题上面。

原因很简单，项目结束之后，乙方就会离场，后续都会有甲方来接手。所以在开发的时候，乙方只关心实现就好了，后续什么维护啊健壮性啊，压根不在考虑范围之内。

另外有的乙方为了压低成本，派出的很多开发人员都是刚刚毕业的实习生，根本没有实际开发经验，赶鸭子上架，最后质量可想而知。

所以在这点上，验收阶段就变得尤为重要。很多甲方往往忽视这个过程，认为乙方东西都做好了，自己只要走过场地去验证一下就可以了（甚至很多时候是由内部的业务部门验收）。

乙方离场后，你再想让他们回来可就难了。那就要在他们离场之前，尽量把问题暴露出来，让他们赶紧修正完毕。那么这个就要依赖验收需要专业和细致的把控。

验收必须要有标准，然后根据这个标准再列出验收的清单，每个验收人员必须严格按照清单进行测试检查。碰到问题应及时报告，并督促乙方必须在某个时间段内解决。只有在所有问题都已经处理完毕之后，整个项目才可以进入收尾。

结语

我在这里无意去指摘外包开发，因为我也是乙方出身，也知道乙方有很多的难处。

但现有的市场中确实存在一些质素不是很高的外包公司，他们的行为已经影响到了整个行业的声誉。我也很希望有的软件外包这个行业能慢慢解决以上的这些问题，再度重拾大家对他们的信任。

本文由 @Tony 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。