（原载于Argo逸仙时空Java版)

前两天收到站内信叫我交工作报告，想来这段时间对Java版实在没什么贡献，适逢上周五
是我入职一周年的日子，倒不如写一篇这一年来的工作经历跟大家分享，抛砖引玉，也给
这冷门的版面添点话题。
还记得当初面试的时候，经理最后一句问我：“你是不是真的有兴趣做这份工作呢？”。
我毫不犹豫地回答：“对！我就想做点跟以前不一样的东西！”经理说：“好！欢迎加入
我们的团队！”等待我的这个职位叫做Build Engineer（后简称BE），恐怕很多人都没听
过，我们这家外包公司做的是一家全球知名银行的系统，有着复杂的流程和分工体系，
像我一个从小外包中心作了3年出来的年轻人，连自己都没搞清楚这个职位到底要做些什么
。但这不要紧，经理给了很长的一段时间我去犯错误，去学习，在工作中不断地成长。
一、
“有问题一定要多问，你不知道问谁就来问我，即使我解决不了的我也可以找人来帮你解
决。”
08年金融海啸，这家银行亏了很多钱，因为他本来就是世界最有钱的银行之一，因此在这
次海啸中亏得也是最厉害的。这个外包中心在09年也走了很多人，直到年末突然间又开始
招了很多人回来，我也是其中的一分子。我刚来没多久就加入了一个英国的项目，整个开
发团队大部分都是新人，却要完成把整个英国系统升级的庞大任务，带队人却还是一个盲
目乐观的新领队。可想而知我们面临的情况有多糟糕，但完成这个项目却让我学到了很多
很多东西。

首先解释下我们内部的组织形式和我作为BE这个角色所负责的任务。我们的外包中心（OD
C）是作为乙方，而银行是外包关系中的甲方。我们ODC的员工是以人力资源的形式给甲方
租用，所以甲方会根据每个人每天为项目做了多长时间（以半天为单位）来给钱。ODC里面
有除了PM（项目经理）以外的绝大部分角色，包括DEV（开发人员），BA（需求分析），T
A（技术架构），QC（测试），CBT（Central Build Team，我想翻译成“集成构建”差不
多了），是一个比较完整的团队结构。项目经理都是甲方的，他们将会从银行全球各个分
部拿项目回来做，然后找ODC的中层经理要人力资源来负责项目的开发实现测试以及交付。

我们BE是属于CBT的其中一个团队，主要负责项目代码的编译打包，部署，发布版本以及跟
进客户在部署过程中出现的问题。CBT下面还有EE（Environment Engineer，负责管理所
有 项目用到的开发测试环境），SCM（软件配置管理，主要负责源代码的版本管理）。CBT
就像是一个公共的资源，每一个项目组需要环境支持，打包部署，发布版本以及代码管理等
服务，就要找CBT的经理根据需求分配相应的人手完成他们的任务。而BE又是一个比较特别
的资源，其实从整个SDLC（Software Development Life Cycle）来说，BE的介入是贯穿整
个项目的：首先，BE要跟客户确认他们的运行环境，包括机器和拓扑图，了解部署的需求
；第二，BE要负责把开发测试环境配置好，比如某个项目是在现有的系统基础上做开发 ，
那我们必须先确保能模拟一个现有的系统出来；第三，在开发过程中，可能需要重复地部
署package进行集成测试；第四，到产品交付环节，需要确保所有流程都已经正确无误地完
成，然后将package上传到release server，并发布通知给客户；最后，还需要给客户提供
部署的技术支持，协助他们完成UAT(User Acceptance Test)。

当然，我进入项目的时候并不清楚这些，反而要面对的是一大堆不知名的文档和一大群人
。第一个任务是要把一个克隆的环境调试好，给DEV作为对比测试的基础。光是搞这一个环
境就搞了我两个月，英国的系统总共有五十多个component，有一些component很多年都没
有人碰过的，那些曾经碰过的人都基本已经离开公司了，无论是打包还是配置都存在很多
问题，亦没有清晰的文档可查。解决这些问题需要的两大要素————“Knowledge”和“
Experience”都相当缺乏，只能到处找人问。我的经理就时常跟我说：“有问题一定要多
问，你不知道问谁就来问我，即使我解决不了的我也可以找人来帮你解决。”正是这一种
求知的精神，让当时的我茅塞顿开，在经理的帮助下，把我以前连碰都没碰过的Unix，We
bSphere，Maven，QuickBuild等等，全部都鼓捣了一遍。
自此以后，我就明白了应该怎样去学习知识，并形成了自己的学习习惯。以前我还很佩服
经理的勇气，没有笔试，只在面试里简单问了我一些概念，我甚至很明白地说我只弄过CV
S和ANT，他都敢把我招进来。原来他是早已明白train up一个人需要什么，招一个人的时
候最看重的应该是什么，才会以别具一格的方式来招揽人才。事实证明了他在培养团队方
面确实有一套。