前面三篇文章大致讲了如何接单，如何和客户沟通需求，如何报价和签订合同的注意事项。这一篇就来讲讲开发，部署和售后环节需要注意的地方。
外包项目的发展过程有时候也不一定是按照沟通需求，报价，签订合同，开发，交付这种线性方式。可能还没签订合同就已经进入开发阶段了，这个风险需要你自己去把握。我是没遇到已经在开发了，结果后面又不和我签合同的。
开发阶段如何进行，很大一方面要看你的客户的专业程度，有些甲方本身就是开发公司，他们可能会要求你使用类似teambition这样的项目管理工具，将开发进度明确地展现出来，例如进度要精确到周，要能知道开发成员都在做什么功能，对应的需求是什么。还要求出日报、周报等。对这种客户的要求说实话我是厌烦的。因为这些过程管理很费时间，需要你不断地和开发人员去对齐进度。用项目管理工具本身没问题，但是要看项目的情况。一个5个人参与的，耗时3个月内的项目，我真的不太想用项目管理工具，因为我本身的经验就足以应付对项目进度的管控了，这么说可能有点装逼，但是事实就是如此。做得多了就懒了，每周给客户汇报一下进度，每个月给客户一个可演示的版本，一般情况下客户也都觉得满意了。
具体到项目上，因为现在接到的单子要么是WEB系统，要么是APP，要么是小程序，所以我们主要用java和php两种写后端代码，前端一般就是vue了。遇到APP的话就用react native写前端。代码管理我们在自己的服务器上搭建了git环境，现在不用码云这样的商用代码管理环境了，因为免费的私有项目只能放5个开发进来，收费的又太贵，不如自己搭一个环境来放代码。在项目的开发阶段，如果不涉及调用客户的第三方系统对外接口的话，我们都是在自己的机器上搭建测试环境。3个代码分支，1个dev,1个test，1个master。基本是按照开发，测试和主干三种情况划分分支。开发在本地跑通后，提交到dev分支，由开发leader根据计划时间和统一进展情况，提一个版本到test分支给测试人员测试。测试人员会在原型确定了，写用例。一般用例出来后会大家开会评审一次，有时候测试写的测试用例会提出一些，大家之前都没想到的一些异常分支情况。所以测试用例出来的时候，我都会拉开发一起过一遍，这样也有助于我自己和开发人员发现之前没有想到的一些情况。测试发现的问题会在项目管理工具上做bug追踪，这个演示版本的大BUG改完后，我们会提这个test分支的代码部署到测试环境，给客户演示。客户验收后，由leader汇总到master分支上。大致的代码提交流程就是这个样子的。
说说开发过程中的进度管理。如果客户强烈要求的话，我会用项目管理工具，将之前确认了的需求，记录到项目管理工具的需求模块，再根据需求划分不同的功能到功能模块，每个功能指定一个开发人员，明确开始和完成时间。并将一组功能划分到某个迭代中去，作为一个给客户演示版本的功能集合。测试人员测试发现的问题，会关联上具体的功能和具体的开发人员。这样一来，不管是我自己还是客户都可以一目了然地了解到目前项目的进度情况。只是说实话，我不想这么干，我有时候几个项目并行，真的不想去搞这些东西。项目有风险也是之前在需求分析和确认过程中没有明确清楚，结果在开发过程中，客户提出和自己想的不一样。真正在开发过程中发生的风险和问题很少，因为根据需求情况，我是留足了开发时间的，一般不会因为开发时间不足导致项目延期，最多也就是客户临时提出新的需求，这种情况我都会去评估新需求的开发量，如果需要2个人超过1周的开发量，我都会明确告知客户，为什么要花这个时间才能满足。客户一般也会简化需求，或者留到下一期再做。因为你有理有据嘛，合同范围也不包含这个新需求，所以项目一般都能按期交付的。只有一次是延期的，那就是有一单接的是一个二次开发的项目，该项目逻辑很复杂，代码结构也复杂，里面有很多子系统混在一起，之间的接口关系也很混乱。之前在评估的时候轻视了，结果在开发了一段时间后开发人员反馈进度缓慢，给我急得啊，有几天我啥事没干，就一直打电话，通过各种渠道去找开发人员，因为你答应了客户，那就是一种承诺，打破牙齿也得往肚子里咽。还好找了几个经验丰富的开发临时加入进来，最终在延期了2周的情况，交付了项目。客户最后也表示理解。这里多说一句，二次开发的项目要谨慎！
在开发过程中，我有时候会把代码拉下来，看看开发人员写的代码规范不规范，每个方法的逻辑是否太复杂，不够单一。如果时间比较充分的时候，会要求他们重构代码。主要是为了养成一个好的习惯，因为做开发的都知道，一开始大家可能会好好地按规范写代码，但是时间长了，特别是时间比较紧急的时候，往往顾不得代码质量了，怎么快怎么来。久而久之代码的可维护性就变得比较差了，所以得定期得有人给他们一些监督和压力。为了客户的口碑，有时候得罪一些开发也是值得的，只有你说的在理。
关于在开发过程中，我们使用的技术。如果是java的话，就是springboot+mybatis+redis+mysql，php就是基于laravel框架来写。有些大点的C端项目，为了保证某些功能的并发，我们会拆分系统形成类微服务的方式，只是不是完全按照微服务的架构来（要考虑项目成本和时间）每个服务之间采用kafka来交互。涉及到对接第三方系统的时候，会根据情况采用webservice或者直接就是双方约定接口的方式实现。不过这类项目比较少，因为外包的单子一般规模都不算大。
项目部署的时候，我们会根据和客户的事先沟通情况，如果客户是数据不敏感的话，一般也就是客户采购云服务器，给我们SSH账号密码，我们自己去部署。如果客户对数据有保密性要求，有自己机房的，我们就直接去机房部署。有些客户有自己的运维，我们就会提供部署文档，配合客户的运维部署上线。
售后过程中其实也是体现我们服务的地方。有些外包商收到尾款后，就不太理客户了，客户系统出现一些问题，也是反应不太积极。当然如果客户在整个外包项目过程中，确实很垃圾。这种情况也可以理解。不过我确实还没遇到不讲诚信的客户。在收到尾款后，客户有时候也会打电话或者微信来，说系统出现了一些问题，我们都会及时去处理。其实人与人之间在相处一段时间后，都会知道对方的“度”在哪里。所以我的客户都知道如果是BUG，不管是不是在维护期内，我都会帮忙处理。因为我觉得是我开发的东西，出了问题我应该去处理，和钱没关系。如果是新需求，我会给客户明确出来，超过一定工作量的新需求，我是要重新收钱的。
这个系列文章我花了四篇文章，把软件外包项目从开始到结束都讲了一遍，都是自己的亲身经历。这也是给自己两年外包接单生涯的一个阶段性总结。都是想到哪里写到哪里，去年看了一本《金字塔原理》主要讲授如何写文章的，当时看完还很有感触。但是当自己真正开始写文章的，又懒得提前去构思文章的结构，呵呵。都是想到哪里写到哪里，只求能把想说的话说清楚说明白就行。我觉得作为软件外包的从业者，除了赚钱还是要花时间去提升自己，自己的技术，自己的产品能力，与人沟通协调的能力。特别像我这样自己出来开公司，没有人给你的收入兜底了，一切都靠自己去争取，又不是什么有名望的大公司。靠的真的是实打实的能力和服务态度，慢慢地积攒起自己的口碑。希望这个系列文章能给有想法接外包单子单干的程序员或者和我一样的外包公司人员一些借鉴和参考吧，有问题可以给我留言，大家共勉！