——-由於種種原因，最近有了換工的想法，聯絡了以前混的不錯的同事，哥們說啥也不需要準備，總結一下這幾年的管理、技術經驗，跟老闆聊聊就行。在此背景驅動之下，決定總結一下四年多外包的工作經歷，也跟大夥分享一下，估計有90%以上的java程式設計師會對下面系統感興趣。
我是2010年4月份進入華為外包公司，然後在5月份跳槽到現在的公司，一直待到現在，目前是公司持證PM，華為技能定級五級。
技術篇：
這些年主要一直在做同一個專案，某個業務發放閘道器管理系統（這裡簡稱SPXX），主要是用於管理所有的BOSS系統和組網內所有網元，組網之間採用的是Webservice技術進行資料通訊，大概結構如下。
營業廳BOSS（多個）<—>SPXX（一個）<—>網元（多個）
一、組網說明：一個SPXX系統北向支援320個營業廳BOSS同時線上發放，南向支援64個網元版本和例項。
二、系統結構：該分散式系統有6↑個程式，支援新增擴充套件板負荷分擔，程式之間是通過Mina和Jms進行資料通訊，標配主備雙活兩塊板，支援倒換，支援擴充套件，主要涉及Java、C++、Shell、Python、VB、Xslt等語言，大概結構如下。
1）業務發放程式（程式間都是使用Mian進行資料通訊）
營業廳BOSS（多個）
↓↑Webservice呼叫（ACL/使用者名稱密碼鑑權）
——SPXX——————————————————————————–
DPU4N（北端業務分發程式，監聽SOAP、TL1、MML等訊息埠，支援併發320連線）
↓↑Mina
SPU（訊息處理程式，有多個，支援隨時擴充套件，DPU4N輪選）
↓↑Mina
DPU4S（南向匯聚）
—–SPXX———————————————————————————-
↓↑Webservice呼叫
網元（多個）
2）配置管理程式（程式間都是使用JMS進行資料通訊）
PMU（Tomcat程式）、CMU（資料持久化程式）、OMA（配置管理程式）、JMX（程式監控程式）、Common（非程式，公共程式碼工程）
三、工作原理：採用MyEclipse作為開發工具，總共有8個工程，該系統是在SUSE版本的Linux系統上部署，標配主備雙活兩塊板、支援倒換、支援擴充套件、升級等操作。
1）該系統有Web管理介面，主要是用於業務和配置管理，包含系統使用者、BOSS使用者、角色許可權、日誌、網元版本、網元例項、業務流管理、使用者策略管理、分權分域管理、Batch/Bulk批處理等等功能。
a、系統北端是採用Webservice呼叫，配置管理主要是給北向BOSS配置ACL和使用者名稱密碼鑑權資訊，只有通過鑑權的訊息才允許發放到網元；
b、系統可以為每個BOSS使用者指定業務發放許可權和分權分域許可權，也就是限制某些使用者只能開戶或者換號、某些使用者只能設定139號段等等；
d、SPXX系統本身沒有任何業務，只做閘道器管理，主要是由網元提供wsdl介面。SPXX系統南向有十幾個網元，每個網元都是用SPXX系統提供的模板工具，生成介面包（該包包含wsdl介面檔案），然後把該包載入到SPXX系統上，再新增一個例項物件（該物件包含網元IP/埠/服務名），SPXX系統會根據網元載入的介面包自動生成業務發放介面（wsdl介面檔案裡面本身包含命令和引數型別、引數範圍等資訊），該自動生成的介面只用於維護，BOSS需要拿介面包中的wsdl介面進行二次開發，這樣就起到遮蔽BOSS直接對接十幾個網元，只要對接一個SPXX系統，由SPXX系統來管理所有網元，避免介面混亂的局面；
c、該系統支援業務定製功能，內部有一個業務流解析引擎，支援封裝多個網元命令，主要原理是通過XML編寫一套業務流程檔案和wsdl介面，然後將該業務流載入到SPXX系統中，再把該wsdl介面釋出給BOSS系統，當BOSS系統下發該命令到SPXX系統，系統通過機制判斷該訊息是個業務流，再通過名稱空間路徑+命令找到該XML指令碼，解析裡面定義的原子命令，把原子命令分解傳送到各個網元，再把各個網元的返回結果根據XML指令碼定義規則組裝返回給BOSS系統，這樣就解決一個開戶十幾條命令對BOSS呈現只需要一條命令搞定。另外該業務流指令碼支援定義變數、迴圈、條件分支判斷、失敗回滾等操作，說白了就是SPXX系統提供了一套自己的程式語言和語言解析器。
d、該系統還提供了批量發放功能，類似市面上那種充值卡、直接開好的手機卡都是通過批量開戶完成的，支援步長累加批處理和多個命令放到檔案內的批處理。
2）分散式程式主備是雙活的，這裡雙活的概念是部署到兩套單板，都是活動狀態，一塊單板掛了不會影響業務發放，如果程式掛掉JMX會對故障程式進行自動修復，多次修復不成功會就行倒換操作，支援升級、補丁。
3）其他程式功能和工具工作原理這裡不細講，後續博文再輸出。
管理篇：
這裡必須植入一個背景，早期我們團隊由於管理計劃不明確，人員技能過於單一，再加上系統過於複雜，由簡單的WEB系統改造成多程式的分散式系統，涉及技術非常多技能要求也比較搞。導致版本轉測試延遲和Bug改不對、修改不全的問題非常嚴重，經常被客戶投訴。我進專案半年內，專案經理、區域經理迫於壓力相繼離職，每天加班加點老員工也陸續離開，專案已經瀕臨要黃掉的地步。歷時半年勉強交付一個版本，客戶要求我帶一批人駐場交付。
合作模式：每個版本需求包分成兩份，客戶+合作方共同開發，合入同一個SVN庫，雙方投入比例3：7。
獨立運作：我們開發模式是敏捷開發，一般2周左右一個迭代，整個開發階段有4到5個迭代，一個版本大概有4.5萬行程式碼量。
1、任務分配：客戶PM跟我劃分交付特性，然後我跟骨幹員工一起把每個需求劃分責任人，這裡主要是每個人認領制，也會根據重要程度進行劃分;
2、計劃制定：我們內部制定了完備的開發流程，所有成員可以根據該流程特性屬性2天左右就可以給出交付計劃；
3、任務跟蹤：採用早會站立會議，每個成員講述自己的計劃完成情況和下一步計劃，反饋風險和求助。我主要解決風險和求助，糾正計劃偏差；
4、流程保障：我們有專門的SVN目錄用於歸檔開發和日常規範的流程規範文件，有迭代開發流程規範、特性串講&答辯流程規範、檢視格式規範、編碼規範（這個包含客戶要求的規範）、轉測試CheckList規範等等。統一專案人員的操作規範和輸出規範，保障交付結果。我也因為有這一系列流程保障，每天投入管理的工作時間可以縮短到2個小時左右，其餘時間跟組內成員一起寫程式碼，處處以身作則，遷移組內成員保障流程；
5、技能提升：專案各個模組採用程式碼責任田制，總共19個模組都有田主和副田主，每人至少有2塊以上的田，我們定期進行程式碼互檢挖掘歷史版本問題、知識點文件寫作，根據知識點文件每週兩次下午茶培訓，人員技能增長效果非常明顯。多個模組都有專家，面對一線緊急問題定位，田主基本都輕鬆應對；
6、團隊活動：我們採取兩兩一組，每個月組織一次活動，目前已經爬遍深圳各大名山、穿越、燒烤、騎車等等，至今三年以上的老員工佔8成；
工作成果：
1、工作1年以上的員工都具備獨立開發能力。我們的迭代開發流程：從特性熟悉、概要設計、串講、模組設計、模組答辯、BBIT用例寫作、編碼、用例測試、VT、轉測試都是有一個開發人員單獨完成。涉及到安裝、升級、前端等都由特性交付責任人全流程完成開發，而且效率和質量都符合客戶要求；
2、專案再次離岸交付。通過一年多駐場改造，我們的交付能力已經跟客戶員工基本對等，實現再次離岸交付；
心得：一個團隊制定合理的流程規則非常重要，通常一個管理者耗費太多時間和精力在人員管理和任務跟蹤上，而團隊成員則把時間浪費在瑣事上。
1、我們專案管理者在專案前期制定好交付計劃，跟客戶約定任務下發和反饋機制，維護好跟客戶的需求列表，不能讓團隊成員幹了活沒地方體現。
2、每天早會把握好計劃是否正常進行，解決每個成員當前的困難和求助，讓成員都能專心寫程式碼，周邊溝通和求助是每個程式設計師的通病，尤其是外包公司，不要讓他們把時間浪費在這個上面。
3、尊重每個成員的想法，培養他們自己計劃自己的工作任務能力，我們管理者只需要評估計劃的合理性，是否在效率允許和可承受風險範圍內，這樣才能讓團隊成員迅速成長，一兩年後你的團隊不缺乏骨幹成員。
———————-由於時間關係，後續再做補充，初次寫博文，本身寫作水平能力有限，還望各位多提意見糾正，非常感謝—————————-