关于外包开发的碎碎念

今年着手跟进了几个与外包商对接的项目，在这个过程中走过了无数的弯路，跌进了无数的坑，这里简单总结记录一下，以纪念小生内心无数次的OS~

一、什么情况下会选择外包商

1、公司的开发团队工作量极度饱和的情况下，会外包出去一部分非核心的功能、模块、或系统；

2、公司没有开发团队；

3、公司的关联公司有开发团队，但是不方便调用；你以为小生会跟你说这个可以用么？你以为小生会跟你说亲兄弟明算账即可么？emm... ... 想多了。

二、怎样筛选外包商？

一般行业内的外包开发商都是众所周知的那几家，比如基金行业的底层基础系统供应商恒生、金证等。如果需开发的是对应的上层建筑，可直接找恒生、金证或请他们推荐技术能力还算靠谱的开发商。

如果您以上都不选，想自寻，没问题的呀，但是需要您所在的团队有成员能准确的把控与判断供应商的实力，并且尽可能减少影响该成员决策的因素。

自己找供应商一般来源于：

1、搜索引擎；

2、关系网络： 领导、同事、朋友推荐；

3、拥有相似业务、想法的公司（实际需求与标准产品难以揉合，彼此达成战略合作，取长补短）；

搜索引擎中查到的开发商良莠不齐，如果需要鉴别对方能否满足你的要求，请注意以下几点：

1、系统供应商的公司规模、人员配比（项目经理、架构师、数据库架构师、产品经理、设计、开发、测试等）和能力。

2、请系统供应商提供同业成功案例和失败案例（或费时远超合同约定的案例），尽量请对方提供联系方式以方便确认，如果对方无法提供核实方式，则需要自行想办法确认情况是否属实（存在造假的情况）。

如果供应商没有同业案例，然后对方还拍着胸脯说会认真做这个项目并且打包票这个项目一定做好，这时候请一定要录音录像，如果可能尽量请对方签字盖章，因实际情况常常并不是这样。

会存在团队内成员和系统供应商联合造假欺骗的情况，即使被发现，你也可能会得到一套说词： “经验这个东西，谁也不是一开始就有的，都是从无到有的过程... ... 而且我们这不是还有XXX(人名)么... ...” 。如果你也遇到了，请想办法把这尊“大神”移出你的团队或者请他对这个项目全权全程负责；如果无法做到，请绕过他；如果绕不过去，那... 请节哀吧~

3、请系统供应商提供公司资质、公司信息、是否能开专票、在业内信用如何和是否有相应的管理规范等信息，并需要自行调研确认（天眼查、企业信息公示系统等渠道）。笔者曾遇到过一个团队有多个公司名称，然后还存在公司不能开专票，需要要换主体才能签合同的情况等, emm... ...

4、尝试跟对方沟通一个需求，然后请对方解读并形成书面文档和原型，看看他们理解的和实际的需求之间差距，如果出现反复多次调整的情况，请不要选这家， emm... ...

5、尽可能的多问几句，不论是技术、业务还是其他信息，因为只有你有足够的信息才能有较为准确和全面的判断；

6、试探性的提几个过分的要求，看对方的应对方式，如果对方一口答应，这时需要留心并反复确认对方是否能达到你的要求；

7、跟业内人员事先确认好，想做的产品/软件/系统大概多少钱能做成什么效果，然后与供应商提供的报价和方案进行比较，如果二者存在一定的差距，需要明确误差在什么地方。

敲黑板啦：供应商的作风是拿多少钱做多少事儿。其中钱与事的等价标准，可能与业内人员的认知都有一定的误差，尽量在确认合作之前弄清楚这条标准，以避免后续的麻烦。

8、所有的对外操作建议录音，甚至是录像，且需要说明时间、地点、参与人员，会议主题等内容。因大部分外包商的售前和售后是不同的岗位，且实际执行人员会因为时间、价格、重要程度、人情等因素会有所变动且难以维继。

9、如项目/程序/系统对应的行业性较强，建议选择有相关经验的人或理解能力学习能力较强的人来做，并跟供应商确认清楚，需供应商在什么时间段把相应的能力匹配的人员提供到位。

10、如果项目行业性较强，且要求快速上线，则建议选择已有标准产品，可快速开发交付或可分期交付，尤以运维见长的供应商。

11、请供应商提供推荐的开发语言、框架、同类案例的样本，里面可以没有核心数据，包括但不限于：需求文档、概要设计、详细设计、原型图、数据库设计、代码片段、测试案例、测试报告、性能报告、用户验收报告、部署图等等；

12、确认一下外包商在交付给甲方进行测试之前是否会有相应的内部测试（包括但不限于：单元测试、集成测试、功能测试、性能测试、回归测试、alpha测试等），存在外包商只提供程序员所作的测试，其余测试需要甲方再找三方测试机构进行测试或者自行测试，否则需要额外收费；

第12条，你没看错，小生也没写错，真的有外包商不做测试~

筛选完供应商之后整理成方案上报，供上级选择，这时请保持平常心。

以上是小生从在不断的掉坑爬坑的过程中的小总结，可能不是很完善，欢迎各位大佬来提建议~

三、招标

一般招标有明标和暗标两种操作方式，还有可能是内定，最后中标的公司可能是：

1、方案中的公司；

2、方案中被判出局的公司；

3、不在方案中的公司；

请不要惊讶，这里也没写错，现实永远会超出你的预料，有时甚至会pia，pia，pia的打脸。

四、签合同（非框架协议）

1、甲乙双方责任和权利尽可能的细化。尽量不要出现甲乙双方工作内容不明确的情况，笔者曾经历过因权利义务不清，乙方的工作内容要由甲方人员来做，否则项目就进行不下去；另外违约条款也需要尽可能详实一些；

2、将甲乙双方需要提供的内容形成列表，并把提供的内容需要达到什么程度也描述清楚；

3、合同中需附上总的开发周期与项目进度计划，阶段性计划（根据项目进展不断更新）、交付物与里程碑、交付物完成程度，验收标准等，并需要弄清楚这个项目最多的能接受的延期期限，写明在合同中并标明违约期限，对双方都产生约束力；

4、合同中需附上甲方提供的需求文档或需求描述，并且确保乙方理解该需求；如果甲方在该阶段无法提供，可以在合同中约定以甲乙双方最终确认的需求(这时是属于乙方编写，可以是需求文档或原型图等形式）为准，然后双方签字确认，但是不建议出现这种情况，很可能结果是两方目标都无法达成；

5、确认清楚项目范围与实现程度，在合同期内能实现什么功能，一般甲方的认知是乙方会完全按照需求文档中的内容来实现，但是乙方可能会把你的需求划分成一期二期，并且有的供应商还会针对二期的需求重新收费，这些内容需要事先确认清楚；

6、确定团队成员能力（尤其是项目经理，产品经理、架构师、数据库架构师等）、稳定性、交接条件等；

7、如果有其他要求也尽可能的写在合同中，比如：语言、架构等要求。如果您的项目对系统架构和数据库设计有一定的要求，建议这块明确在合同中，否则后续乙方存在因为成本等问题会省略该项目的系统架构和数据库设计；另如果需要由乙方执行验收测试之前的所有测试过程，并提交相应的测试报告，尽量在合同中明确该部分内容；

8、如果甲方(乙方)有固定的合同模板且不允许修改，这时候为了保护双方的利益，最少要达到彼此条件对等。请仔细阅读并思考前后关系（因果关系、逻辑关系、隐性关系等），然后添加相应的对等条款；

9、一般软件开发项目都存在延期的可能，尽量在合同中约定相应的最长能接受的时间并规定好违约责任。增加这条条款是为了对甲乙双方做一个约束和保障而已。希望您不会走到那一步哟

上述内容即使甲乙双方彼此有决定权的领导存在“认识”、"好朋友"等关系时，也建议您尽量去做，具体原因如下：

1）领导并不是实际执行的人员；

2）如果项目进展不顺利或无法推进，合同是双方协商和评判的基石；

3）所有模糊的条款或未约束的条件都是预埋的雷，杀伤力不可预期；

tips：在外包项目中，一般人的认知是： “出钱的是老大”，“甲方爸爸”... ... 但是记住哦，如果您做的不是一锤子买卖或者没有绝对的经济实力，隐藏 boss 本质上是乙方。

五、执行

1、合同签订的同时或之后项目正式开始，需求搜集的过程中乙方至少需要出具PRD、原型图、设计图等不断与甲方进行确认。这时请注意以下事项：

1）不论你合作的供应商是否有丰富的经验，不论之前是否做过相应的产品/技术，请记住：人与人之间存在各种沟通鸿沟，信息在传递的过程中存在衰减。

2）需求沟通的过程中，针对重要内容，尽可能的从多个角度描述该内容，尽量确保对方人员能理解你的意思（可通过请对方人员复述出你的需求来确认），甲乙双方的沟通鸿沟差不多有理想和现实的差距那么大吧。比如甲方需求文档中描述了一个白釉瓷瓶；经过几番沟通之后乙方绘出了一个看起来是白色瓶子的原型图，你以为这时候就能放心了，开心了么？

nonono，太天真了啊，这时候你还需要确认一下这个瓶子的质地，制作工艺等；同时外包商还可能会拿着这个白色的瓶子（喷漆瓶）对你说： 这是你自己确认的需求，我们就是按照你的需求做的啊 ... ...emm......

3）很多情况下一个人的话语描述和落在文件上的内容并不一致，比如上面那条中，即使乙方人员复述出的内容听起来是甲方的需求，但是再看乙方输出的需求文档或图，会发现很可能两者无法匹配。

4）很多情况下，同一件事情采用电话、开会、驻场等不同的方式，同样的对接人很可能会有不同的结果。（别问小生为什么知道，谢谢~）

5）尽量留痕：尽量采用电话录音、邮件、现场签字确认等方式，以避免后续的纠纷；

6）在需求搜集与理解阶段，以己度人、换位思考等优良的品德，请抛弃吧，折衷方案、彼此退让请少做，否则最终出来的产品跟最初设计的/想要的内容完全不是同一种东西。

2、需求阶段之后，项目正式进入执行和开发阶段。一般乙方会先进行系统架构和数据库设计和搭建阶段，但是也存在相应的乙方基于节省成本等因素跳过该阶段，直接进入系统开发（所以前面建议如有需要则尽量在合同中进行约束）。

3、系统开发阶段，供应商提供的项目进度计划、开发周期 和 自己开发团队提供的最明显的不同在于实际代码编码周期的所需时间。

供应商提供的编码周期远远小于自己开发团队的。时间长短一般是1：2 或 1：3或者更多的比例。

现咨询了一下相关人员，简单分析了一下其中的原因：

1）时间短，有利于供应商拿单，时间太长，供应商的优势就消失了；

2）供应商在实际开发过程中很少跟甲方主动沟通具体的细节或实际的影响，一般会按照自有的默认规则去实现；而自己公司的开发团队会在开发过程中不断的去确认并会考虑所作功能/系统与现有功能/系统之间的逻辑连贯性、是否互通等；

3）利益关系，基于开发人员的人工费用逐年增加且远大于其他人员的实际情况，外包商压缩实际编码周期，可增加人工利用率。

4、开发过程中和完成后外包商逐步进行相应的测试，并在最后出局测试报告给甲方，要求甲方进行验收。

六、收尾

1、用户验收测试：甲方对乙方提供的内容（之前在合同中约束过）进行验收与测试，不合格和与需求由出入的地方请乙方继续修改并给出修改时限，然后有甲方进行跟踪，如此反复多次，在基本能满足业务要求的时候，完成系统的验收并签署验收报告。

2、试运行：验收之后将相应的功能/程序/系统迁移到生产环境，试运行，搜集并记录相应的反馈内容，如果是bug，协调供应商进行修改，如果是需求变更，则找外包商再次签订补充协议或者重新签订协议进行修改；

另： 如果甲乙双方签订的合同中的交付物包括源代码，建议这一阶段，由甲方相应人员接手源代码并逐步修订该项目，以服务实际业务需求。

3、正式对外上线：正式对外之后会遇到千万种客户，建议记录各种问题，形成问题集锦，并记录用户操作日志，方便后期对数据进行分析和系统不断完善。

七、其他说明

1、正常的甲乙双方合作是互惠互利，但是现实很可能并不是这样，你能做的是想方设法协调推进以使项目能正常上线，如果一旦发现有无法调和的矛盾或利益关系，请及时止损；同时需要摸清楚供应商的心态，在有问题时分析主要矛盾和次要矛盾；

2、团队每个成员的责任归属和工作内容尽可能的细化，并分清需要领导帮忙做的和实际领导能做到的东西的不同，不要对人抱有期望，并且要有应对最坏情况的计划和方案；

3、理解并接受“人都有情绪”这一事实，分清楚主次和“情绪”对实际项目的影响，在出现问题时及时协调或调整；

4、需要理解自建开发团队和系统供应商开发团队的区别；

5、售前和售后，永远是两副面孔， 例如：亲娘脸和晚娘脸；

emm.... ... 当然如果贵司资金实力雄厚，以上都不是事儿~

说明：以上图片大部分来自网络，其余自己作图，如有侵权，在此感到抱歉，还请联系小生~