已是八月末，东京俨是一副入秋的态势，连续一周阴雨不断，温度也一路到了十几二十度，出门只穿短袖就会有点瑟瑟发抖了。还未到九月就能凉爽下来，这的确是出乎我的意料。回想起来第一年到上海时整整过完了十一假期才开始凉快下来，看来一年一年的确是大相径庭。算一算进入目前这个银行项目也有三个月了，跟之前三得利的相比又是别有一番感概。

据称瑞穗银行的这个项目号称全日本最大项目，有人说一共三万人，到底有没有这么多我也顾不上考证了，总之是个具有日本特色的大项目。对于日本的软件服务企业来说(类似于如今美国的IBM，Oracle)，这个大蛋糕当然是人人都想吃，但分蛋糕也要讲究顺序，这一层通常是不甚明朗的，对于大企业比如富士通来说，也不能保证一定拿得到最大的一块，因为竞争对手也不少，主要看甲乙双方高层之间错综复杂的关系了。日本国内的大项目通常是大哥带小弟的感觉，大公司拉到项目后找来自己的小弟公司，商量好分配方式，每个子项目派几个管理人员，这个活就分好了。这些所谓的小弟公司，利润也基本上比较可观，而且通常都有自己长期稳定的大哥，有点类似于生态链，一层一层的展开下去。实际上从这个层面来看，我认为跟室内装修队，建筑施工队等等没有本质上的区别，甚至管理模式上都是有很大的相似性，只是事业内容有所区别，你刷墙，他垒砖，我写程序而已。

整个项目分好了以后，各单位就准备开工了，这时一个办公大楼内划出一片区域来做这个项目，看上去坐在一个公司的楼内，其实已有大大小小十几家公司的人了，按照项目内容进一步划分成技术性的团队，比如负责数据的，负责UI的，负责画面逻辑的，负责业务逻辑的等等。之后是阶段的划分，一个比较典型的分法是RD-SA-UI-SS-PG-PT-IT-ST-OT，其中RD到SS算是设计部分，PG也就是实际动手开发的阶段，之后带T的都是测试了，从单元测试一直到上线测试。这设计的每一阶段都会有大量的文档（日本的习惯似乎是用Excel来做一切文档），这些文档也就成了日后开发的根据和测试的依据。不得不说这些堆积成山的文档是一种严谨的办事方法，但随之而来的问题是，似乎很难保证这里面的内容都是同步更新的。

比方说，在设计阶段结束之后，各单位开始着手写代码，结果写着写着发现有些地方设计书没说清楚（经常发生），这时候就得讨论一番，折腾完之后确定了具体业务逻辑，想到要回去在设计书上添两笔，结果这一添问题就来了，做开发的人往往并不是做设计的人，所以设计书到底该怎么改，有没有相关联的其他设计书，这些事情作为一个负责写代码的人不一定明白，就算明白也不一定乐意花宝贵的开发时间去做（因为自己可能写完代码就换项目走人了），于是这就留下了隐患之一。想想看到了后面做测试的时候，发现实际效果跟设计不一样，为了确定哪个对那个错又要来来回回开好几次会了。

大哥带小弟的组织结构反映在项目中也是十分有趣，比如当一个团队遇到问题需要另一个团队来协助解决时，并不是随便走过去拍拍人家然后张口就问，而是先得衡量一下对方团队跟自己的关系。如果对方团队跟大哥的关系比自己要亲密，地位更高，那就要慎重了，轻易不敢问，往往是攒上好几个问题一起问，在这之前还要发个措辞谨慎的邮件跟对方说一声。与之相对，如果是高级团队找合作的下级团队帮忙（团队之间的关系有时候也并不写明，全靠默契），那便可以坐在座位上喊一声对方的负责人，等人跑过来后再指指点点吩咐一番。当然对于团队来说，总之是能把事情办了，不过站在整个项目的角度看，结果就是高级团队的效率总是越来越高，下级团队的效率越来越低还一直在东奔西跑，但项目做完是要等所有团队都结束后才算，这样一来整个项目被耽搁掉多少时间也就很难计算了。

另一个特殊的地方就在于这种分蛋糕吃的结构下，一个项目的不同阶段人员流动性也很大。比如A公司的一个团队十个人，在开发阶段有八人参与，结果由于A公司另一个项目紧缺人手，之后的测试阶段这八人全部被调走，另换了B公司的几人来接受工作。然而当B公司负责测试的人开工以后，发现A的代码质量不佳，漏洞百出，就不得不边测试边填A公司的坑，这样一来B公司的进度自然会慢下来，因为B的人还得先搞懂A的人的代码是怎么一回事。实际上每个阶段新接手的成员进入状态的周期就会越长，从每个人的角度来说当然也就越不舒服了。

回过头来看，两亿元的大项目，两万人的团队，却似乎很难说比得上二百经验丰富的人做的更好更快。财大气粗的甲方吸引来财大气粗的乙方，既是财大气粗，也自然不愿去承担让二百人来干活的风险了。依靠之发展壮大的标准流程在手，自是不敢稍有逾越。