关于X项目的报告

 

关于X项目的报告

这个项目我是从2005年下半年开始听说的，是一个规模比较大的项目，项目总共涉及10多个城市，包括了遗留系统的数据转换、新系统的需求调研、系统设计、系统开发、系统测试、系统实施等流程。正式进入这个项目是在2006年3月，一开始我在做某业务系统的功能部分，后来做业务系统与其他系统的接口部分，期间交替进行着两三个项目。

系统架构基本是照搬其他地方的系统，增加了一些自己的东西，经过06年一年的开发，到07年初，系统上线了2个城市，一直运行至今，其中各种各样的问题出了很多，五花八门，使人甚是疲倦。背景就介绍到这里，下面列举一些我所看到的项目之中的问题以及一些想法。

排名不分先后，如有雷同，纯属巧合。:)

症状1，迭代式瀑布开发。项目伊始，明确要求采用RUP方法，并且贯彻迭代。在计划中也可以看到各个迭代，但是一年的开发时间，只有4个迭代周期。例如有100个模块，那么每个迭代中分25个，在最后一个迭代中做集成测试和性能测试，所以我称之为“迭代式瀑布开发”，这就为后来的部分功能存在功能和性能问题埋下了伏笔。迭代的威力并没有体现出来。

猛药1，洗脑+扣钱，对项目中从上到下反复洗脑，并且注重平时检查，防止重回老路。

 

症状2，空中楼阁。这个系统的数据库结构是从其他地方挖过来的，挖过来后对这个项目的需求所做的妥协很小。再说说需求，这个项目中的需求只有一份，调研的时间很短，却要适应多个城市的各种情况，所以最后的结果就是似是而非，这在系统上线时反映的极其明显，需求震荡变动，需求文档垃圾化。

猛药2，需求调研是系统方向，方向都不正确，怎么能有一个良好的结果。满足需求的多样性与系统的复杂度是成正比的，如果为了满足各个城市的需要，则在需求调研是必须深入了解各个地市的差异，并做比较甄别。我一直对需求调研有一种看法，需求调研人员不应该只是开会，巴望着能从会议中得到用户的需求，做梦。不深入下去，不真正参与用户的日常工作，怎么能知道用户真正需要什么，用户需要你给他一些professional的建议。

 

症状3，摸着石头过河+走钢丝。如此大的一个项目，众多的功能，没有单元测试来保证，尤其在应对频繁变动的需求时，往往就是开发人员改完简单测试一下，就交给现场发布，可想而知。

猛药3，真的迭代+每日构建。

 

症状4，沟通还是沟通。开发出来的系统，是由专门的人员来实施，但是问题来了，实施人员对系统的理解甚至还不如用户。造成开发人员陷入现场的泥潭之中。

猛药4，带考核的培训+责任心教育+压力的教育。

 

症状5，群起而攻之。这个系统十分庞大，与外部其他机构的接口就有10多个，但是这些接口所遵循的规范只有一个，这自然在开发上简单了，但是造成的工作被动的局面，不同的地方、不同的机构并不会统一这唯一的接口方案。

猛药5，不应回避需求，对用户真正的需求避而不见。不存在放之四海而皆准的需求，除非这些需求除了废话什么也说明不了。与其四处受敌，不如主动出击。

 

症状6，建立在沙子上的大厦。遗留改造系统能欢快的跑下来的充分条件是数据。当数据都不准确，甚至漏洞百出时，程序首当其冲会成为受害者。这个系统的数据转换工作历时1年，其中真正有效的转换时间也就1-2个月，直到上线前，也没有对数据进行完整的测试。

猛药6，测呗，还有啥好说的。

 

症状7，我们是战友而不是敌人。项目中的各个组成部分和用户之间都是互惠互利的关系，不应成为敌人，一荣俱荣，一损俱损。项目中的各个组成部分来自五湖四海，人在江湖飘啊，怎能不挨刀。

猛药7，加强团队精神建设，打造“胶冻团队”。

 

上面说了一些我自己的体会，有一些其他的症状就不在这里废话了。对于不同的项目应该会有不同的充要条件，但其中应包括下面这几个（想到的就写下了，没有先后顺序）：

l       大家认可的目标

l       每日构建

l       强烈的荣誉感和责任心

l       项目组的文化和核心精神

l       优秀的过程和方法

l       执行能力

 

 

 

 

 

 

                                                                                              

 

 

 

 

 Wonder

                                                                                             2007-6-1

祝所有的小朋友和即将成为小朋友的小宝宝们六一节快乐！希望你们每个人都能有自己喜欢的礼物。