一、背景

由于公司在东南亚，以及其他各种不方便多说的原因吧，在做系统的时候是通过选择，国内的外包厂商来做。

下面直接说心得，心得对应的都是两条腿或一条腿踩进去，或大或小的坑。

二、心得

1、厂商选择

品牌及规模：对于应用成熟或者说比较广泛的系统，这个自然不用多说，看他们的客户就知道。但是对于一些相对来说，小众或者说是比较专精的系统来说，最好能够让boss利用自己的资源，从同行的嘴巴里面，问到一些比较有价值的评价，这个可能是我认为唯一比较靠谱的办法。

运营经验：这一点我认为最为重要，因为知名客户的案例的话，有可能客户用了他们的系统，不好用后来又换了，同行的嘴巴里面的话可能也只是道听途说，也或者，厂商本身就不大，你很难得到他很多的信息。所以个人认为从用户数据，还有多个维度的真实使用场景，这两个角度的话去反问厂商一些问题，来判断他们的客户，在实际战场中怎样应用，以及遇到过什么问题，厂商是如何配合解决的，这一套组合拳打下来，基本上可以得到对方是不是靠不靠谱的结论。不过这当然有一个前提，就是你们这边有人起码是业务上的内行。

实地考察：这一点其实和买硬件设备很像，去对方的公司，看一看实地的情况，尤其看一看对方的程序员的年龄，很多做外包的厂商都是喜欢聘请一些刚毕业的大学生，不仅价格实惠，而且相对来说，也不难胜任，但这个事情对于甲方来说其实是一个坑，由于代码编写以及版本管理能力的问题，测试的时候总会发现，这里改了，那里没改或者是问题不断的在新的版本复现，会比较让人头疼。

说个题外话，有一些厂商的话虽然不大，但是项目经理，可能自己会有公司的股份，甚至是创始人之一，这个可以去网上扒的到，一般情况下这样服务会比较上心，所以小公司的话这种情况是一个加分项。

核心业务：厂商小没有关系，但关键要看这一块的系统方案是不是他们的核心业务，非核心业务的话可能会由于，更新的不及时，程序员的流动性，甚至是版本过老带来的APP的兼容性问题，导致你在验收的时候各种不爽，会花比较多的精力去解决很多小的问题。

2、合同

付款：这个问题上我认为是，情愿总体的报价稍微给对方高一点，也要能换来多批次付款的条件，这点对于甲方来说尤为重要，特别适合一些小开发商合作的时候，倒不是说不信任对方，而是说这样子的话，可以在服务的过程中不断地鞭策对方。

内容：这块不要偷懒，不要从网上扒一个模版下来，改一改就给对方发过去，不仅要给法务审，最好还要给公司里面，签合同签的比较多的财务以及技术的老人看一看，就算在合作前和对方聊的千好万好，但在最后发生分歧的时候，肯定还是要通过合同来谈问题的。尤其是软件系统的问题，为了开展业务，不可能等到一半再来换开发厂商，越早解决这些问题实际上对甲方越有利，拖到越后面，对双方都不利，但尤其对甲方更不利。

总言之这块，要拿出写需求文档的态度来搞定。

3、合作中

角色：这个问题我认为要通过双方的沟通频次来区分角色，我方的产品经理和对方的项目经理一定要扮演白脸的角色，商务的同学可能更多的要在产生分歧的时候扮演黑脸的角色，只有需求的具体负责人在沟通上顺畅了项目才能真正的得到有效的推进，但是商务的同学可能就要辛苦一下了，这个问题要提前和商务同学沟通好，嘿嘿。

新需求：这个问题，首先作为产品经理，你要尽量保证在双方开始合作前，就能够把确切的需求文档给产出，然后让对方评估后，将功能点写在合同，这是最理想的情况。

其次，如果在开发过程中发现真的有一些需求需要添加，也要尽量和对方保持良好的沟通关系，不能因为自己甲方的身份，而对对方施加过多的压力，或者是恶言相向。同时也应该尽力的向对方传达，长期合作长期迭代的商务意向。

再次，如果有相对比较大的功能需求，或者是和原始需求相差比较大的改动。个人认为是最好能提前和对方的项目经理和技术通个气，评估一下工作量和修改难度，以及对方的难处，以示工作的严谨和对对方的尊敬，不要上来就直接走商务谈判。如果对方不愿意的话，可以提前许诺适当提升下一期合作的价格。或者是，我们自己本身有其他资源如同行客户，可以向对方提做一些资源置换。

最次的情况下就只能押尾款，但是这种方法不到万不得已，真的不要去做，损人不一定利己。并且随着尾款逐步的支付，以及面对即将开张的业务，这时候做这种事，对于甲方而言是一种很冒险的行为。

三、总结

系统开发，能不外包，就别外包。

非要外包，请选择一次性的东西，定义好需求，以及多批次付款。