-------由于种种原因，最近有了换工的想法，联系了以前混的不错的同事，哥们说啥也不需要准备，总结一下这几年的管理、技术经验，跟老板聊聊就行。在此背景驱动之下，决定总结一下四年多外包的工作经历，也跟大伙分享一下，估计有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、尊重每个成员的想法，培养他们自己计划自己的工作任务能力，我们管理者只需要评估计划的合理性，是否在效率允许和可承受风险范围内，这样才能让团队成员迅速成长，一两年后你的团队不缺乏骨干成员。
----------------------由于时间关系，后续再做补充，初次写博文，本身写作水平能力有限，还望各位多提意见纠正，非常感谢--------------------------------
在外包的这几年，技术和管理经验总结,布布扣,bubuko.com