java軟件外包方向（java編程就業方向）

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

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

開發階段如何進行，很大一方面要看你的客戶的專業程度，有些甲方本身就是開發公司，他們可能會要求你使用類似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，不管是不是在維護期內，我都會幫忙處理。因為我覺得是我開發的東西，出了問題我應該去處理，和錢沒關系。如果是新需求，我會給客戶明確出來，超過一定工作量的新需求，我是要重新收錢的。

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