三地开发---一个失败项目的思考（2）

继续检讨o(︶︿︶)o

失败分析：

1.大环境因素

因为是改造项目，所以心理上可能降低了对项目难度的把握。项目一开始，从上流工程到下流工程感觉都在盲目的乐观。

表现在上流工程中，BSE和日本社员，日本社员和客户间交流频度过低效率较慢。北京要确认的问题往往要一个星期至两个星期 才有结果。即使结果出来，在经过几天后可能很快就变了。而且原业务和新业务需求日本把握不足。

北京这边初期虽然很艰苦的研究着源码，但因为对日本低效率的无奈和天津庞大开发团队的乐观，无形中也纵容了这份乐观。

天津新招了四位国内开发多年经验（至少得5年以上）的leader，以及20多个毕业生外加几个部分经验的，如此庞大的队伍让大家都默契的认为项目的成功结束也是指日可待的。还是信心满满的乐观。

2.开发模式上

做过对日开发外包项目的人都知道。基本的模式都两地开发（即日本+国内）。日本做基本设计（可能再加详细设计），国内主要是编码，测试，测试书。中间的交流是以桥（BSE）。这样算来也是三方模式。

这次我们的三地开发若按上面算来该是四方模式了(ˇˍˇ） ，本意是节约成本并摸索出三地开发的经验（实践证明是失败的）。现在细细想来，三地等于设置了两个"桥"（日本，北京），而过多的"桥"设置也增加了“传话游戏”的风险。传话游戏中，10个人做和100个人做，结果相差好多。更何况在业务复杂的项目中，每个桥对复杂业务的理解转达过程中都会打下”折扣“。更严重的是，"桥"得不到下面人员业务理解的及时反馈。北京这边做完的基本设计和详细设计基本都我们说了算，日本缺少了重要的review。天津方面由于多种原因北京这也无法直接把握。

3.人员体制上

北京主力固定人员5,6,7~~？从开始进入坚持到项目结束的固定是5个。一个还去了天津做PM。多时有10多个，不等项目完全展开也就6,7个。人员流动过快。至最后真正熟悉业务的北京这也就剩4个主力。也还是只对自己的模块熟悉。

天津一个PM,外加四个leader。因为管理和各方面问题，致使某些leader中间抵制情绪滋生，负责的机能也疏于管理。毕业生的程序质量几乎无人控制，好多在北京已经开始测试时，发现竟然还有漏写的功能。至纳品前，bug随便点点还是很容易发现。

4.我们自己

现在我还在想，如果项目展开我们几个主力能去天津做段时间，虽然不能说力挽狂澜改变失败的命运，但至少不会败得这么惨。公司头对这事也应该耿耿于怀。

项目初头曾暗示过让我们过去做，出于每个人的种种考虑，大家意见统一的坚持回绝。项目中后期虽然几个人过去了20多天，也已经无力改变。

想想，继续中~~~~~