To B软件类产品外包存在的诸多矛盾，资金与服务的矛盾、产品与项目的矛盾、团队能力的矛盾、契约与人性的矛盾、沟通协作的矛盾等等，以下是作者七八年产品外包的掉坑经历整理，希望能给一些初入此行的产品经理们一些启示，引发一些共鸣。

这些天，又在与外包团队进行各种产品问题的讨论纠缠，苦恼不堪。

近些年由于To B SAAS市场、互联网创业发展迅速，产品外包在软件领域日益兴起，很多创业公司、传统IT企业、集成商、运营商都纷纷参与到产品外包的价值链中，有的扮演甲方发包项目，有的扮演乙方承包项目；有的则前脚作为乙方承接项目，后脚就作为甲方转包给下家。

然而，相比项目的一次性而言，产品却是一个长期不断优化迭代的过程，因此产品的外包这其中存在太多值得思考和总结的问题。

作为身处产品外包七八年的老兵，今天就围绕To B软件类产品外包存在的诸多矛盾，给大家分享下我在此过程中所经历的一些坑，其中涉及资金与服务的矛盾、产品与项目的矛盾、团队能力的矛盾、契约与人性的矛盾、沟通协作的矛盾等等。

希望能给一些初入此行的产品经理们一些启示，引发一些共鸣。具体如下：

一、资金与服务的矛盾

“给多少钱，办多少事”在基于交易的外包中，这条真理常挂在嘴边，却也常纠缠不清。

一切服务都和钱挂钩，给多少钱、提供多少服务、准备多少资源。为了避免扯皮，甲方往往会在合同中对服务有非常明确的要求，它不仅包括基本的功能需求、交付时间、产品质量验收标准，还包括客观的管理要求，即外包团队人数、人才能力（面试评测）、人才绩效考核标准；以及产品开发过程中有关设计、运营、维护等相关服务的详细要求。

然而，理想很丰满，现实很骨感，产品外包中资金往往和服务不能划等号。

主要有两种情况：

1. 钱给少了，索要的服务过多

一方面：很多企业或者创业者，在产品外包时，总是会极力压低预算，能省则省，但他们的需求却有增无减。

谁都想要价廉物美的商品，这当然可以理解，但万事都得讲个“度”。

产品在研发过程中，需求变化在所难免，如果和乙方协商处理好就不存在冲突。但有些甲方不仅功能贪多求全，而且在签完合同之后，完全不考虑乙方的感受，想方设法的追加需求索要服务，甚至自己内部的汇报材料撰写，或者与项目不相干的事情也让乙方去做，这一点在政府客户中比较常见。

这样的情况，对于乙方，有时候迫于客户关系，可能会做一些，但这样的需求多了，且收益包不住成本的时候，要么选择拒绝，要么偷工减料降低质量。

如果甲方逼得太狠，乙方精力全在扯皮上，心累了直接撂挑子走人。

另一方面：也不乏很多外包团队，初期为了给自己赚吆喝，为公司业绩增添案例，从而不惜报超低价，只为能够拿下项目。一旦和这些厂商建立合作，后期风险可想而知，他们如果发现赚足了吆喝，且出现“入不敷出”的情况，就会立马减少投入，甚至消失的无影无踪。

2. 钱给够了，得到的服务不够

相反，有时候甲方的资金很充足，但因为乙方为了追求利益最大化，主观上偷工减料；或者因为内部能力不足、资源调配，从而降低了服务标准，造成产品无法顺利完成。

例如：乙方外包团队往往手里不可能只做一个项目，他会同时承接多个项目。这时候，乙方会根据项目的规模、紧急程度、重要性等，对资源进行重新分配，将好的资源分配给重要的项目。

所以即使甲方给的钱充足，但和其他项目比起来，依然没有足够吸引力，所以乙方会对原本甲方的项目实施资源减配。

这样的话，有可能原有项目上能力强的开发人员就有可能被抽调走，留下的人员还会存在被其他项目复用的情况。本来专注于一个项目的工程师，却被其他项目牵扯精力，可能一天只有0-10%的精力在甲方产品上，而且会不断被打断，影响工作效率，整个团队的能力和效率会下降一大截。

即便是驻点在甲方现场的开发形式，也存在这样的情况，“人在曹营，心在汉”这句谚语用在这里可能比较贴切。

二、产品与项目的矛盾

甲方做的是自己的产品，而乙方做的是别人的项目。

这两者本身就是相互矛盾的，甲乙方的立场目的完全不一样，乙方带着做项目的心态去做产品，是不可能完全把产品做好的。

双方的关注重点完全不同，甲方更关注产品本身，希望作出一款用户需要的好用的产品，以此来打开市场提升销售业绩。而乙方只看重眼前的利益，做完一单是一单，收完钱就转移阵地。

1. 周期的矛盾

做产品是没有完成之日的，是长期的，持续需要迭代演进；而做项目是有明确完成时间的，是短期且一次性的，一锤子买卖，做完就走，不会维护后续版本。开发人员都找不到了，怎么继续做优化迭代呢？

当然可以协商做一期、二期，这样阶段性的项目，但这样的折中方案依旧避免不了这样的矛盾。

2. 需求范围的矛盾

产品需求具有不确定性，是根据市场及客户需求不断新增、变化的；而项目需求是有明确项目范围的，虽然也有变更，但是是在成本、质量、时间的综合因素条件下决定的，范围相对可控。

3. 用户体验的矛盾

做产品，用户体验是必备因素，即便是To B产品也在越来越追求好用的用户体验；而做项目，首先追求的是功能，用户体验是次要的。

目前很多外包团队不重视体验设计，所以缺少交互体验专员，前期也不会做详细的交互设计原型，认为只要功能实现即可交付，并且合同中也不可能细化到交互细节要求。另外很多时候，还以“体验见仁见智”或者“我认为挺好的”这样的主观口吻来搪塞。

许多乙方虽然在前期提供了大量的UI设计稿（图片），供甲方确认，但最终做出的产品还是会和期望相差太远。一方面，前期的图片比较零散并没有体验真实交互，另一方面，原型也不能面面俱到，总有疏漏之处，而乙方则以未事先说明且经甲方确认为由不予修改。

4. 技术架构的矛盾

做产品，往往希望采用先进的架构，灵活的插件，以保证产品有较好的稳定性、扩展性、兼容性和使用体验，即便初期架构简单，后期也要重构。

但很多乙方往往抱着其公司内部老旧的技术体系架构，坚持“一招鲜吃遍天”的打法，每天忙于拓展项目赚钱，完成功能是第一要务；而同时技术重构又需要花费大量的人力和时间，所以他们根本不愿意沉下心来去重构改进。

5. 产品期望与团队能力的矛盾

人是产品能否成功的关键因素，在产品外包中，却常常因为乙方人才资源的匮乏导致做出的产品总是不尽如人意。

好的人才往往聚集在大型互联网公司、国企，或者发展前景好的创业公司，而外包公司的人才水平参差不齐，这跟外包公司的业务性质和成本结构有很大关系。

对于外包团队而言，人力成本是最大的支出占比，特别在当下IT人才薪水节节攀升的时代，外包利润缩水严重，为了谋取外包项目的最大利润，必需尽量压低项目的人力成本，这也成为了很多外包团队能力有限的主要原因。

常见问题我总结为三个方面：

（1）人少

乙方减少单个项目的人数投入，有的项目甚至只投入0.5-1个人，可谓是极度节俭。研发人员捉襟见肘，产品很难保质保量完成。

当然不能仅通过人员数量来决定团队能力，就像《启示录》中提到的那样，宁愿选择5个专业能力强的高级工程师，也不愿选择30个能力一般的菜鸟。

在我之前参与的一个产品外包项目中，曾经只有一个人主要负责开发，但因为能力强，基本可以保证交付的质量，但后期逐渐加人，反而出现了一些麻烦，还需要前期的人来填坑，不仅影响进度还造成了浪费。

（2）人不行

人员能力不行，一直是很多甲方诟病的问题，总是抱怨乙方人员总是不能很好的实现他们的预期，诸如缺少基本的规范和逻辑、功能无法实现或者开发时间过长、文档撰写太差、沟通能力有限、项目管理能力有限等等。

其实，不管什么团队，我们都想要优秀的人才，但薪水自然要求也比较高，对于乙方，平衡成本之下，不可能都做到高端配置。

所以，乙方会根据甲方项目的规模、重要性、时间计划先后等因素，对多个项目的人力配备进行深入评估，招募和配置不同等级的人才。

一般一个团队配置1-2个高级人才就已经很奢侈了，另外再招募一些应届大学生、或者中专、培训机构出来的人才，这些人的薪资要求很低，既可以达到甲方对团队人数的要求又可以降低成本。这里用“滥竽充数”这个成语再合适不过了。

（3）人难管

频跳槽：

外包团队的人员离职变动在IT行业中可能更加频繁，有些人今天刚报到，可能三天后就要离职。

而这样的人员变动，影响最大的就是工作交接所带来未知风险，不仅需要花费时间去找到下一个合适的接班人，即便是找到了，人员还需要接手和适应的时间，整个周期下来，产品已经停滞两周了。那外包行业人员离职的主因是什么呢？

我总结两点：

工作苦逼没有归属感：外包项目一般都驻点在项目现场，人员工作地点不固定，常常更换，并且驻点时间往往少则三个月，多则一年半载，工作环境也由甲方提供的场所决定，好点的提供。

多头项目没有自我提升时间：特别是能力不错的人才，由于能力较强，单位工作效率和产出较高，而这样的人往往公司会给他安排更多的项目去做，有的人甚至成了救火队员，哪里项目有问题，就派到哪里，到处奔波，身心俱疲。

正所谓“能力越强，责任越大”，这个词在外包公司这里得到了很好的体现。

长期这样，没有时间去自我提升，能力遇到瓶颈，不能与时俱进的更新知识，每天疲于应付项目，所以跳槽是迟早的事儿。

（4）不服管：

这个现象常常出现在甲方现场驻点开发的场景，正所谓“将在外军令有所不受”，外包团队长期驻点，缺少激励，士气低迷，且领导不在身边，没有约束力。

所以经常出现工作积极性不高、工作时娱乐，不认真工作；并且人员存在逆反心理，主观不听从甲方的修改要求。

这里的原因：主要是现场外包人员的个人绩效考核权利不在甲方，也就是工资不是甲方发，所以难以对其形成约束和激励。

沟通协作的矛盾

6. 异地办公

很多外包团队与产品负责人需要在研发过程中，针对设计、成果等进行不断的讨论、协作。

如果他们分属异地，即便现在有很多互联网沟通产品，也无法替代当面沟通的效果。有些产品仅靠几页草稿去开发，几个月后再看产品，质量可想而知。

所以异地情况，我们一般至少保证每周及重要里程表组织团队见面，确认每周及阶段性进展成果及下一阶段计划。另外，定期邮件往来、QQ、微信、视频等即时通讯手段给予辅助。

7. 沟通心态

有些甲方认为花钱后什么都不用管，应该得到全方位的服务，乙方应全权负责产品。这种情况下做出的产品往往没有好的结果。

就好像把自己的孩子完全托付给别人寄养，几个月后的性情肯定是这个妈妈无法接受的。如果甲方在一些场合，以“上帝的姿态”做出过激的行为，可能会触犯工程师的尊严，引起乙方不满，甚至撂挑子不干。因此，保持一个“开放、平等、合作”的心态才是项目所必需的。

乙方的不主动沟通也比较常见。一种情况是甲方的需求有时比较模糊，乙方按照自己的想法实施研发，不事先与甲方沟通。另一种情况是甲方对技术不太精通，有些问题可能乙方早就觉察到了，但因为怕耽误工期或者投入成本太高，一直捂着不主动提出，等到最后产品上线终于出了问题，那时候的损失就很难控制了。

8. 无效沟通

甲乙方的会议经常从早晨讨论到晚上，且非常激烈，但最终却没有结果，或者有结果第二天又推翻继续讨论。一来二去，既耽误了时间，又耗费了大家的精力。

所以在会议召开之前明确会议主题和目的非常重要，会议中一旦出现偏离，立即打断，必须保证整个会议的讨论朝着一个结果有序进行。

会后，形成会议纪要通告大家，重要问题最好签字确认，加强仪式感。虽然也会有推翻的可能，但至少在签字时，每个人都是报着对会议结果负责的态度。

三、甲乙管理机制的矛盾

1. 开发管理方式冲突

对于很多互联网或者SAAS产品，多采用敏捷的研发方法，迭代的速度要求也是相当高的，少则一周，多则两到三周就出一个版本。

而很多传统外包团队，依然更多采用瀑布式的开发方法，按部就班的输出需求文档、设计文档、项目计划、开发、测试，整个周期下来2个月之后才能看到成果，这时候也许市场早就没了。

我不是说所有项目都要敏捷，但有些适合敏捷的项目就应该坚持敏捷。有些文档完全不需要撰写，写了也没人看。直接出原型给开发，要比文档效果更好。

乙方自有的项目管理工具仅在内部使用，不向甲方开放共同协作使用，例如Bug管理、文档管理等。

所以，如果甲方发现软件某些问题，或者需要查看部分文档，还需要通知乙方接口人转达或者获取，非常影响协作效率。而且一旦遇到不靠谱的乙方，这些内部管理记录很多都没有规范的执行。

因此，作为甲方，建立自有的项目管理工具体系对产品推进有益无害，既可提高沟通效率，也可及时监督项目进展，发现问题。

2. 测试形同虚设

乙方对于开发完成的产品，常常不重视测试，甚至不做测试。开发完成之后，草草测试了事，或者直接甩给甲方，让甲方去验证发现问题。

这一点经常让甲方负责人恼火，一个版本要多次的验证打回，再验证再打回，劳心费力，既浪费时间又没有进展，完全充当了乙方的测试角色。

这里原因有很多，包括：

• 乙方公司规模较小：专业的测试人员只配备1-2人，有的甚至没有测试人员，或者有其他职位的人兼职，测试水平较差。如果乙方承接的项目较多，人力资源有限，有些项目时间紧，根本来不及测试就提交甲方。
• 乙方公司的开发理念重开发轻测试：有些公司领导依旧持有这种陈旧的思想，所以在招聘人员上，测试人员的数量和水平一直不被重视。而且，测试在公司的话语权和交付责任机制，并不是以测试为中心，出了问题也不会找测试问责，这也是造成了这一现象的原因。

3. 内部管理不畅波及项目

有人的地方就有江湖，有时乙方内部的不合理管理和派系斗争，也会波及到甲方项目。

例如：内部开发人员与项目经理分属不同部门，之间存在工作量结算或者内部KPI考核的矛盾；或者内部提交开发的流程死板，都会影响内部资源的调配和项目推进。

四、契约与人性的矛盾

虽然合同在法律上规定了甲乙方的责任与义务，但很多时候并不是非黑即白的。

特别是在中国，除了“一纸约定”去约束项目和规避风险，其实还有甲乙方的中国式关系、以及职业操守这样的灰色区域。这些我把它们归结为人性，也就是人际关系和诚信问题。

有人的地方就有主观喜好，这种喜好会表现在对合同执行的干预作用，执行好的项目可能会被人为破坏，执行差的项目可能会被“润滑”、或者调和改进。

1. 负面激化矛盾

• 甲方的诚信问题：因为乙方在实施过程中，没有遵循“潜规则”，使得甲方主要负责人不满意，从而在项目验收时，故意刁难、延迟验收，拖欠款项。乙方随即暂停工作，使得项目无法收尾。
• 乙方的诚信问题：因为乙方与甲方某位项目关键人关系不一般，且大包大揽，不问需求先承诺，甚至以虚假案例最终拿到项目，但之后发现没有能力承接，或者二次转包，最后做成了烂尾产品，即便关系好，合同上也说不过去。

2. 正面化解矛盾

人际关系和契约有时候不一定是激化矛盾，有的时候也可以化解矛盾，成为矛盾的“润滑剂”。

例如，在合同执行时，乙方对甲方不仅项目服务非常到位，关系也维护的很不错。之后甲方的需求因市场变化有所变更或者蔓延，这时候乙方因为人际关系，可能在成本可控的情况下会更多的承担一些开发；而甲方也可能因为人际关系，提出增补合同，追加投资。

再如，项目验收时，即便有一些产品瑕疵，因为关系好，往往睁一只眼闭一只眼，就验收通过了，后期乙方再优化完善，不影响合同付款进度。

以上就是个人对于以往To B产品外包中趟过的各种坑的一个总结。

也许你会问，这么多坑该怎么避免呢？

如果你是甲方给你几点建议：

（1）不外包自己干

首先，想好外包的原因，是因为时间来不及、缺少技术、还是资金有限。

如果仅仅是想压低成本，不建议外包，这个思路做不好产品，特别是核心部分更不建议外包。如果是因为时间紧又没有技术团队，可以考虑第一个版本外包，后续自建团队接手重构迭代产品。外包是为了寻找专业的人做你不擅长的事情，而不是仅仅为了少花钱，这一点谨记。

（2）切勿贪大求全

MVP最小可交付产品的精益方法业界已经熟知，我就不在多说了。

对于传统行业创业者，贪大求全的错误还是会犯，在产品外包中，就更要避免。如果要做移动端，你不需要iOS、Android、微信H5全做，你可以先做微信H5，成本小流量多，可以很好的验证第一版。

（3）选择靠谱开发团队

首先，最好通过熟人关系，真实了解他们团队的能力及服务。其次，团队尽量选择和自己在一个地方，避免异地。

再次，外包团队要稳定并专门负责自己项目，不能被其他项目牵绊。最后，就是项目负责人以及开发人员要有丰富的开发经验等基本考证了。

（4）过程管理抓大放小

过程两头重点抓：

开始阶段要重点抓需求范围界定、和交互体验设计。需求双方一定要吃透，尽量不要有模糊不清的地方，对于不确定的部分可以不放到第一个版本开发。

另外，建议输出高保真原型，并且对部分交互点给予说明。对于体验设计粗糙的原型一定要严格拒绝，重新打回重新设计，不能直接进入开发，要知道好的原型可以避免很多后期开发的风险。

开始阶段的项目管理模式要双方明确并严格执行，比如接口责任人、沟通机制、管理工具的选择等等，以便为后期项目执行打下良好的基础。

后期的验收标准、考核惩罚机制和验收执行要重点专注，验收标准尽量细化，覆盖产品功能、交互体验、服务、维护等多个方面，以及相关的考核细则都要在项目开始前明确，并写到合同中，以规避风险。

过程中间选择抓：

“若事无巨细，皆以身亲之，则所得至寡，所失至多矣”，所以中间过程仅作节点提醒和适度监理即可。如果事事亲为，一方面，分散注意力容易忘记重点，另一方面，要给乙方团队一定的自由度，手深的太长，会影响团队原有的节奏，也容易打击团队的积极主动性。

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

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