如何喝客户沟通需求，如何报价和签订合同的注意事项？

前三篇文章：

前三篇大致讲了如何接单，如何与客户沟通，如何报价和签订合同。本文将谈谈在开发、部署和售后环节需要注意的几点。

外包项目的开发过程有时不一定是沟通需求、报价、签订合同、开发和交付的线性方式。它可能在签订合同之前就已经进入了开发阶段，需要您自己把握这个风险。我从来没有遇到过已经在开发中的，因此以后不会和我签订合同。

开发阶段如何进行很大程度上取决于客户的专业水平。有些方本身就是开发公司，他们可能会要求你使用这样的项目管理工具来清楚地显示开发进度。精确到周，要知道开发成员在做什么功能，对应的需求是什么。还需要每天、每周等。老实说，我厌倦了这种客户要求。因为这些流程管理非常耗时，并且需要您不断与开发人员保持一致的进度。使用项目管理工具本身很好，但这取决于项目。对于一个5个人花了3个月的项目，我真的不喜欢用项目管理工具，因为我自己的经验足以管理项目的进度。这么说可能有点自命不凡，但事实就是这样。如果你做得太多，你就会变得懒惰。每周向客户报告以下进度，每月给客户一个演示版。一般来说，客户是满意的。

具体到项目，因为现在接到的订单要么是WEB系统，要么是APP，要么是小程序，所以我们主要使用java和php编写后端代码，前端一般是vue。如果遇到一个APP，用react native写前端。代码管理我们在自己的服务器上搭建了一个git环境，现在不需要像码云这样的商业代码管理环境，因为只能开发5个免费的私人项目，而且费用太贵ue开发外包，不如自己搭建一个环境自己放代码。在项目的开发阶段，如果不涉及调用客户第三方系统的外部接口，我们在自己的机器上搭建测试环境。3 个代码分支，1 个开发，1 个测试，1 个主控。基本上，分支按照开发、测试、主干三种情况进行划分。开发在本地运行后，提交给dev分支，开发负责人根据计划时间和统一进度向测试分支提出一个版本供测试人员进行测试。测试人员将确定原型并编写用例。一般情况下，用例出来后，每个人都会开会审查一次。有时候测试写的测试用例会提出一些大家之前没有想到的异常分支情况。所以当测试用例出来的时候，我会拉着开发一起去过一遍ue开发外包，这样也能帮助自己和开发者发现一些之前没有想到的情况。测试中发现的问题将在项目管理工具上进行跟踪。本次演示版主要bug修复后，我们会将本次测试分支的代码部署到测试环境中，并演示给客户。客户接受后，由leader聚合到master分支。一般的代码提交流程是这样的。

谈谈开发过程中的进度管理。如果客户强烈要求，我会使用项目管理工具将之前确认的需求记录到项目管理工具的需求模块中ue开发外包ue开发外包，然后根据需求将不同的功能划分为功能模块，为每个功能分配一个开发人员，并清楚地开始和完成时间。将一组功能划分为一个迭代，作为提供给客户的演示版本的一组功能。测试人员发现的问题将与特定的功能和特定的开发人员相关联。这样，我自己和客户都可以一目了然地了解当前项目的进度。老实说，我不想做，有时我有几个并行的项目，我真的不想做这些东西。在之前的需求分析和确认过程中，项目的风险也不清楚。结果，在开发过程中，客户的建议和他想的不一样。开发过程中实际发生的风险和问题很少，因为根据需求，我预留了足够的开发时间。一般不会因为开发时间不足而耽误项目。最多是客户暂时提出新的要求。在任何情况下，我都会评估新需求的开发量。如果需要两个人的开发量超过一周，我会明确告知客户为什么要花这个时间见面。客户通常还会简化他们的要求，或将其保存到下一个问题。因为你有理有据，合同范围不包括这个新要求，所以项目一般可以按时交付。只有一个延迟，即一个订单是一个二次开发项目。项目的逻辑很复杂，代码结构也很复杂，很多子系统混在一起，它们之间的接口关系也很混乱。之前在评测中鄙视它，但是经过一段时间的开发，开发者反馈进度慢，让我很着急。这几天没啥事，就不停的打电话，各种渠道找开发者。因为你答应了客户，那是一种承诺，你一咬牙就要咬牙切齿。幸运的是，我们临时找了几个有经验的开发者加入，延迟了2周后终于交付了项目。客户终于表示理解。这里还要说一点，二次开发的项目要谨慎！

在开发过程中，我有时会拉下代码，看看开发者写的代码是否不规范，每个方法的逻辑是否过于复杂，不够单一。如果有时间，他们将被要求重构代码。主要目的是养成一个好习惯，因为做开发的人都知道，一开始大家都可能按照规范写代码U3D建模外包，但是时间长了，特别是时间比较紧迫的时候，代码的质量经常被忽视。为什么？怎么来的。随着时间的推移，代码的可维护性变得相对较差，因此人们不得不定期给他们一些监督和压力。为了客户的声誉，有时候得罪一些开发者是值得的，只有你说的才有意义。

关于我们在开发过程中使用的技术。如果是java，就是+mybatis+redis+mysql，php是基于lARavel框架写的。对于一些比较大的C端项目，为了保证某些功能的并发性，我们会拆分系统形成类似微服务的方式，但是并不完全按照微服务架构（项目成本和时间应该是考虑）在每个服务之间。使用kafka进行交互。与第三方系统对接时，将视情况实施或直接通过双方约定的接口实施。不过这样的项目比较少见，因为外包订单的规模一般不大。

项目部署时，我们会提前与客户沟通。如果客户对数据不敏感，一般客户购买云服务器，给我们SSH账号密码，我们自己部署。如果客户有数据保密要求，有自己的机房，我们会直接到机房部署。Yo 1 部分客户有自己的运维，我们会提供部署文件配合客户的运维部署。

其实售后过程也是我们服务体现的地方。一些外包商在收到尾款后并没有太多关注他们的客户。客户的系统出现了一些问题，但他们的反应不是很积极。当然，如果客户在外包项目的全过程中，那真的是垃圾。这种情况也是可以理解的。但是u3d外包团队，我从未遇到过不诚实的客户。客户收到尾款后有时会打电话或微信说系统有问题，我们会及时处理。其实，相处一段时间后，就会知道对方的“度”在哪里。所以我的客户知道，如果它是一个错误，无论它是否在维护中，我 会帮忙处理的。因为我觉得是我自己开发的，有问题就应该处理，和钱没关系。如果是新的需求，我会跟客户说清楚。如果新的需求超过一定的工作量，我会重新收费。

这个系列的文章我用了四篇，从头到尾讲了软件外包项目，都是我自己的亲身经历。这也是我两年外包生涯的阶段性总结。我总是想着在哪里写。去年看了一本书《金字塔的原理》，主要讲的是如何写文章。当时，我印象非常深刻。但是当我真正开始写文章的时候，我懒得提前去想文章的结构，嘿嘿。我总是想写到我想写的地方，只为能把我想说的写清楚、清楚。我觉得作为一个软件外包的从业者，除了赚钱，你还需要花时间去提升自己，提升你的技术，提升你的产品能力，以及您与他人沟通和协调的能力。尤其是像我这样出去开公司，没有人会给你收入的底线，一切都是自己赢的，也不是什么有名的大公司。真的要靠真本事和服务态度，慢慢积累自己的口碑。希望这个系列的文章能给有想法接外包单的程序员或者像我这样的外包公司的人一些参考。有什么问题可以给我留言，大家可以互相鼓励！并慢慢积累了自己的名声。希望这个系列的文章能给有想法接外包单的程序员或者像我这样的外包公司的人一些参考。有什么问题可以给我留言，大家可以互相鼓励！并慢慢积累了自己的名声。希望这个系列的文章能给有想法接外包单的程序员或者像我这样的外包公司的人一些参考。有什么问题可以给我留言，大家可以互相鼓励！