前面三篇文章大致講了如何接單，如何和客戶溝通需求，如何報價和簽訂合同的注意事項。這一篇就來講講開發(fā)，部署和售后環(huán)節(jié)需要注意的地方。

外包項目的發(fā)展過程有時候也不一定是按照溝通需求，報價，簽訂合同，開發(fā)，交付這種線性方式?？赡苓€沒簽訂合同就已經(jīng)進(jìn)入開發(fā)階段了，這個風(fēng)險需要你自己去把握。我是沒遇到已經(jīng)在開發(fā)了，結(jié)果后面又不和我簽合同的。

開發(fā)階段如何進(jìn)行，很大一方面要看你的客戶的專業(yè)程度，有些甲方本身就是開發(fā)公司，他們可能會要求你使用類似teambition這樣的項目管理工具，將開發(fā)進(jìn)度明確地展現(xiàn)出來，例如進(jìn)度要精確到周，要能知道開發(fā)成員都在做什么功能，對應(yīng)的需求是什么。還要求出日報、周報等。對這種客戶的要求說實話我是厭煩的。因為這些過程管理很費時間，需要你不斷地和開發(fā)人員去對齊進(jìn)度。用項目管理工具本身沒問題，但是要看項目的情況。一個5個人參與的，耗時3個月內(nèi)的項目，我真的不太想用項目管理工具，因為我本身的經(jīng)驗就足以應(yīng)付對項目進(jìn)度的管控了，這么說可能有點裝逼，但是事實就是如此。做得多了就懶了，每周給客戶匯報一下進(jìn)度，每個月給客戶一個可演示的版本，一般情況下客戶也都覺得滿意了。

具體到項目上，因為現(xiàn)在接到的單子要么是WEB系統(tǒng)，要么是APP，要么是小程序，所以我們主要用java和php兩種寫后端代碼，前端一般就是vue了。遇到APP的話就用react native寫前端。代碼管理我們在自己的服務(wù)器上搭建了git環(huán)境，現(xiàn)在不用碼云這樣的商用代碼管理環(huán)境了，因為免費的私有項目只能放5個開發(fā)進(jìn)來，收費的又太貴，不如自己搭一個環(huán)境來放代碼。在項目的開發(fā)階段，如果不涉及調(diào)用客戶的第三方系統(tǒng)對外接口的話，我們都是在自己的機器上搭建測試環(huán)境。3個代碼分支，1個dev,1個test，1個master?；臼前凑臻_發(fā)，測試和主干三種情況劃分分支。開發(fā)在本地跑通后，提交到dev分支，由開發(fā)leader根據(jù)計劃時間和統(tǒng)一進(jìn)展情況，提一個版本到test分支給測試人員測試。測試人員會在原型確定了，寫用例。一般用例出來后會大家開會評審一次，有時候測試寫的測試用例會提出一些，大家之前都沒想到的一些異常分支情況。所以測試用例出來的時候，我都會拉開發(fā)一起過一遍，這樣也有助于我自己和開發(fā)人員發(fā)現(xiàn)之前沒有想到的一些情況。測試發(fā)現(xiàn)的問題會在項目管理工具上做bug追蹤，這個演示版本的大BUG改完后，我們會提這個test分支的代碼部署到測試環(huán)境，給客戶演示?？蛻趄炇蘸?，由leader匯總到master分支上。大致的代碼提交流程就是這個樣子的。

說說開發(fā)過程中的進(jìn)度管理。如果客戶強烈要求的話，我會用項目管理工具，將之前確認(rèn)了的需求，記錄到項目管理工具的需求模塊，再根據(jù)需求劃分不同的功能到功能模塊，每個功能指定一個開發(fā)人員，明確開始和完成時間。并將一組功能劃分到某個迭代中去，作為一個給客戶演示版本的功能集合。測試人員測試發(fā)現(xiàn)的問題，會關(guān)聯(lián)上具體的功能和具體的開發(fā)人員。這樣一來，不管是我自己還是客戶都可以一目了然地了解到目前項目的進(jìn)度情況。只是說實話，我不想這么干，我有時候幾個項目并行，真的不想去搞這些東西。項目有風(fēng)險也是之前在需求分析和確認(rèn)過程中沒有明確清楚，結(jié)果在開發(fā)過程中，客戶提出和自己想的不一樣。真正在開發(fā)過程中發(fā)生的風(fēng)險和問題很少，因為根據(jù)需求情況，我是留足了開發(fā)時間的，一般不會因為開發(fā)時間不足導(dǎo)致項目延期，最多也就是客戶臨時提出新的需求，這種情況我都會去評估新需求的開發(fā)量，如果需要2個人超過1周的開發(fā)量，我都會明確告知客戶，為什么要花這個時間才能滿足?？蛻粢话阋矔喕枨螅蛘吡舻较乱黄谠僮?。因為你有理有據(jù)嘛，合同范圍也不包含這個新需求，所以項目一般都能按期交付的。只有一次是延期的，那就是有一單接的是一個二次開發(fā)的項目，該項目邏輯很復(fù)雜，代碼結(jié)構(gòu)也復(fù)雜，里面有很多子系統(tǒng)混在一起，之間的接口關(guān)系也很混亂。之前在評估的時候輕視了，結(jié)果在開發(fā)了一段時間后開發(fā)人員反饋進(jìn)度緩慢，給我急得啊，有幾天我啥事沒干，就一直打電話，通過各種渠道去找開發(fā)人員，因為你答應(yīng)了客戶，那就是一種承諾，打破牙齒也得往肚子里咽。還好找了幾個經(jīng)驗豐富的開發(fā)臨時加入進(jìn)來，最終在延期了2周的情況，交付了項目。客戶最后也表示理解。這里多說一句，二次開發(fā)的項目要謹(jǐn)慎！

在開發(fā)過程中，我有時候會把代碼拉下來，看看開發(fā)人員寫的代碼規(guī)范不規(guī)范，每個方法的邏輯是否太復(fù)雜，不夠單一。如果時間比較充分的時候，會要求他們重構(gòu)代碼。主要是為了養(yǎng)成一個好的習(xí)慣，因為做開發(fā)的都知道，一開始大家可能會好好地按規(guī)范寫代碼，但是時間長了，特別是時間比較緊急的時候，往往顧不得代碼質(zhì)量了，怎么快怎么來。久而久之代碼的可維護(hù)性就變得比較差了，所以得定期得有人給他們一些監(jiān)督和壓力。為了客戶的口碑，有時候得罪一些開發(fā)也是值得的，只有你說的在理。

關(guān)于在開發(fā)過程中，我們使用的技術(shù)。如果是java的話，就是springboot+mybatis+redis+mysql，php就是基于laravel框架來寫。有些大點的C端項目，為了保證某些功能的并發(fā)，我們會拆分系統(tǒng)形成類微服務(wù)的方式，只是不是完全按照微服務(wù)的架構(gòu)來（要考慮項目成本和時間）每個服務(wù)之間采用kafka來交互。涉及到對接第三方系統(tǒng)的時候，會根據(jù)情況采用webservice或者直接就是雙方約定接口的方式實現(xiàn)。不過這類項目比較少，因為外包的單子一般規(guī)模都不算大。

項目部署的時候，我們會根據(jù)和客戶的事先溝通情況，如果客戶是數(shù)據(jù)不敏感的話，一般也就是客戶采購云服務(wù)器，給我們SSH賬號密碼，我們自己去部署。如果客戶對數(shù)據(jù)有保密性要求，有自己機房的，我們就直接去機房部署。有些客戶有自己的運維，我們就會提供部署文檔，配合客戶的運維部署上線。

售后過程中其實也是體現(xiàn)我們服務(wù)的地方。有些外包商收到尾款后，就不太理客戶了，客戶系統(tǒng)出現(xiàn)一些問題，也是反應(yīng)不太積極。當(dāng)然如果客戶在整個外包項目過程中，確實很垃圾。這種情況也可以理解。不過我確實還沒遇到不講誠信的客戶。在收到尾款后，客戶有時候也會打電話或者微信來，說系統(tǒng)出現(xiàn)了一些問題，我們都會及時去處理。其實人與人之間在相處一段時間后，都會知道對方的“度”在哪里。所以我的客戶都知道如果是BUG，不管是不是在維護(hù)期內(nèi)，我都會幫忙處理。因為我覺得是我開發(fā)的東西，出了問題我應(yīng)該去處理，和錢沒關(guān)系。如果是新需求，我會給客戶明確出來，超過一定工作量的新需求，我是要重新收錢的。

這個系列文章我花了四篇文章，把軟件外包項目從開始到結(jié)束都講了一遍，都是自己的親身經(jīng)歷。這也是給自己兩年外包接單生涯的一個階段性總結(jié)。都是想到哪里寫到哪里，去年看了一本《金字塔原理》主要講授如何寫文章的，當(dāng)時看完還很有感觸。但是當(dāng)自己真正開始寫文章的，又懶得提前去構(gòu)思文章的結(jié)構(gòu)，呵呵。都是想到哪里寫到哪里，只求能把想說的話說清楚說明白就行。我覺得作為軟件外包的從業(yè)者，除了賺錢還是要花時間去提升自己，自己的技術(shù)，自己的產(chǎn)品能力，與人溝通協(xié)調(diào)的能力。特別像我這樣自己出來開公司，沒有人給你的收入兜底了，一切都靠自己去爭取，又不是什么有名望的大公司?？康恼娴氖菍嵈?qū)嵉哪芰头?wù)態(tài)度，慢慢地積攢起自己的口碑。希望這個系列文章能給有想法接外包單子單干的程序員或者和我一樣的外包公司人員一些借鑒和參考吧，有問題可以給我留言，大家共勉！