这个项目需要什么样的团队

core主要是业务逻辑，admin是个后台的swt管理工具

如果是从头开始的话:
人员应该整体分为三个大层次: 模型组,设计组,开发组

模型组负责逻辑建模,抛弃界面和语法,从逻辑上抽象出一套核心模型出来,主要的工作是定义有那些核心模型,每个模型的功能范围和相互交互联系关系.
模型组同时负责建立核心模型和数据库存储之间的对应关系描述

设计组则选定具体的技术架构,定义通用的界面元素和通用的功能代码类,设计出每个具体功能的界面和实现逻辑.负责将模型组定义的核心模型包装成开发可用的代码

开发组按照设计组的要求,一一加以实现,开发组的具体功能相对独立,相互之间不需要太多交互.

admin抛弃swt,用jsp实现即可.

需要一个狂加班的团队。

那么admin的工作量也是大打折扣的，看来取最小值就可以了，分成3个team，每个team8~15人就可以了。
core作为项目肯定可以细分的，这部分应该是最花时间的。像admin之类的，就是堆代码，改动也不会太大。

还没看明白，是这个项目需要维护/重构,还是重新做?

admin(管理工具),担心设计公司数据和顾客信息,暂时无法截图上来,总之是个超级复杂UI(SWT),曾经试图把C/S改成B/S的,但调研中发现,目前的web表现层无法满足,也极难维护.即便是现在ajax,yohooUI等成熟框架,方案如此丰富的现在,开发起来也要比swt痛苦的多,flash就更不用说啦,如果可以从头再来,也许会选择B/S,赶ajax的风,但似乎船大掉头难啊.

200多万的代码,的确有很多冗余和不必要的,除去历史背景和客观原因,单从代码上看,admin要有60+%的折扣,core要40+%吧,其他工程都是很实在的,尤其是common,像名字一样实在.

一步步走到现在,不同的历史时期有不同的特征,有其自身的背景和客观原因.
因此很难用简单的文字来恰当的重现整个过程.(或许等有时间,纠集原班人马,出书吧),只能晒晒现在的数据.加班是在所难免了,记得Darren说分3个时期(早9晚9,早9晚11,黑白颠倒),很多项目的发展期应该都加班吧.

现在已经分叉成5个版本了,因为,业务上有5个公司(部门),处理不同的业务,需要必要的隔离,处理个别的逻辑,执行非共通的批处理等等吧.

项目还在滚雪球,也暴露和埋下了一些问题,有待发现,解决,避免和改善.
是速度的竞争,业务需求速度和解决问题的速度,后者快,则生,前者快则苦.
(还有一种就是die,但,百足之虫,死而不僵,也许很多人不让他死,哪怕是植物人,也得活着,哈哈)

项目现在活的还很硬朗,在和业务与时俱进,业务方面还在收购,并购一些小公司,要大发展.

找gigx去看看。。。他刚刚写了篇文章，用来重构老项目

1.产品化
2.测试/产品质量
3.拒绝加班
4.需求管理

>抛出异常的爱
gigx 是那位? URL多少?
重构的可能性不太,时间上也不允许,不过最近正在学习这方面理论.
比较认同RCFans说的
"这样的项目……还是需要一些编码能力强的人以保守姿态进行维护吧，稳定的运行最重要
估计项目中那种特杂乱竟然又能神奇正确运行的代码特别多"
现在的实际情况也的确如此.
另外因为业务方面一直在折腾,项目也没停止过新功能的开发,原功能的修正,bug修补,数据调查等.

>ALL
感谢大家的关心,分析和建议,没想到晒出这么多贴来.
补充点文档方面的统计吧,方便大家估算需求.

=======================
JIC业务 文档
other:24(472.2K)
word:62(33.6M)
excel:54(19.5M)
visio:20(8.5M)

业务文档
other:1190(299.4M)
word:275(139.9M)
excel:285(128.1M)
visio:49(19.5M)

合计:1959个文档 共648.9M

以上只是需求文档,不包括运营手册,技术资料等
===========================

这是个日本项目,文档也是日本人写的.
项目期初是livedoor集团的内部项目(可看06年的活力门事件)
虽然livedoor成了历史,但项目一直活着,蛰伏在另外一个集团.
现在似乎又有了复苏的迹象.

对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx