外包项目的发展过程有时候也不一定是按照沟通需求,报价,签订条约,开拓,交付这种线性办法。
可能还没签订条约就已经进入开拓阶段了,这个风险须要你自己去把握。
我是没碰着已经在开拓了,结果后面又反面我签条约的。

开拓阶段如何进行,很大一方面要看你的客户的专业程度,有些甲方本身便是开拓公司,他们可能会哀求你利用类似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周的情形,交付了项目。
客户末了也表示理解。
这里多说一句,二次开拓的项目要谨慎!

php后端开发接单软件外包接单经验谈开辟安排售后 SQL

在开拓过程中,我有时候会把代码拉下来,看看开拓职员写的代码规范不规范,每个方法的逻辑是否太繁芜,不足单一。
如果韶光比较充分的时候,会哀求他们重构代码。
紧张是为了养成一个好的习气,由于做开拓的都知道,一开始大家可能会好好地按规范写代码,但是韶光长了,特殊是韶光比较紧急的时候,每每顾不得代码质量了,怎么快怎么来。
久而久之代码的可掩护性就变得比较差了,以是得定期得有人给他们一些监督和压力。
为了客户的口碑,有时候得罪一些开拓也是值得的,只有你说的在理。

关于在开拓过程中,我们利用的技能。
如果是java的话,便是springboot+mybatis+redis+mysql,php便是基于laravel框架来写。
有些大点的C端项目,为了担保某些功能的并发,我们会拆分系统形成类微做事的办法,只是不是完备按照微做事的架构来(要考虑项目本钱和韶光)每个做事之间采取kafka来交互。
涉及到对接第三方系统的时候,会根据情形采取webservice或者直接便是双方约定接口的办法实现。
不过这类项目比较少,由于外包的单子一样平常规模都不算大。

项目支配的时候,我们会根据和客户的事先沟通情形,如果客户是数据不敏感的话,一样平常也便是客户采购云做事器,给我们SSH账号密码,我们自己去支配。
如果客户对数据有保密性哀求,有自己机房的,我们就直接去机房支配。
有些客户有自己的运维,我们就会供应支配文档,合营客户的运维支配上线。

售落后程中实在也是表示我们做事的地方。
有些外包商收到尾款后,就不太理客户了,客户系统涌现一些问题,也是反应不太积极。
当然如果客户在全体外包项目过程中,确实很垃圾。
这种情形也可以理解。
不过我确实还没碰着不讲诚信的客户。
在收到尾款后,客户有时候也会打电话或者微信来,说系统涌现了一些问题,我们都会及时去处理。
实在人与人之间在相处一段韶光后,都会知道对方的“度”在哪里。
以是我的客户都知道如果是BUG,不管是不是在掩护期内,我都会帮忙处理。
由于我以为是我开拓的东西,出了问题我该当去处理,和钱没紧要。
如果是新需求,我会给客户明确出来,超过一定事情量的新需求,我是要重新收钱的。

这个系列文章我花了四篇文章,把软件外包项目从开始到结束都讲了一遍,都是自己的亲自经历。
这也是给自己两年外包接单生涯的一个阶段性总结。
都是想到哪里写到哪里,去年看了一本《金字塔事理》紧张讲授如何写文章的,当时看完还很有感触。
但是当自己真正开始写文章的,又