项目做完了，总结一下

　　在连续封闭N个月以及再后来的N个月的加班后，项目终于以延期N个月的结果结束了。不管曾经发生过什么，不管项目是否延期，重要的是项目结束了，所有的项目成员都可以松一口气了。曾经和同事开玩笑说：在我经过过的失败项目中多了一个项目，以后就能避免同样类型的失败了。同事们听了，都笑了。在那段时间里，很久没有听到过同事们畅快的笑了。

　　现在，我以我目前的知识水平，总结一下项目中存在的问题，这些问题的出现也不是一两个因素造成的。当然，专业水平太低，也总结不出什么高深的内容。不管怎么样，也算是对项目的总结吧。这里先总结一下我认为的问题，项目值得学习的方面将在下次总结。 

　　1． 项目计划的制定

　　我不是很清楚是否在一开始了解过这个项目的规模，估算过项目的成本和工期以及资源和技术的可行性。当我进入这个项目的时候，就被告知项目在3个月内完成，当时我们正在客户方做业务需求了解。（说明一下，3个月的时间是在项目开始之前公司决定的，而并没有经过项目组成员根据功能估算以及项目经理的综合制定） 也不知道了解的情况是不是这样，但不管怎么样，在还没有了解项目的功能就做好了项目的开发时间，这样项目的风险性是否较高呢？这样导致的结果是开发人员按照规定的时间制定开发计划，最后发现项目规模较大，很多功能也都没有按期完成，也很难按期完成。不但无法按期完成，为了赶进度，代码的质量也就得不到保证，某些项目组成员有推倒重写的冲动。（代码质量也不止是计划导致的，还包括个人的开发经验） 如果不是项目经理超强的管理控制能力，我想项目也不会有结束的日子。 

　　2． 开发团队的稳定

在业务了解阶段，项目组所需要的人员还在招聘中没有全部到位。进入界面原型开发阶段，项目组新近N人。在封闭开发期间，又加入N人，同时，也有N人离开。项目在开发的中前期团队就没有得到稳定，导致工作进度和计划的不一致。而且，每次来增加人员后，都得进行相关的培训和业务了解。同时，人员变更导致不同的人都接手过同一模块，造成代码维护的难度加大。 

　　3． 需求了解

       为了赶项目进度，二是对业务的不了解，三是业务人员业务掌握的差异，在没有全部了解并消化的情况，项目组进行封闭开发。同时，相关人员也在继续了解其他的业务。这所有的情况，导致开发期间发生过N次的设计变更，程序无数次的改动。而且，在开发的后期都发生过业务不断的改变的情况。 

　　4． 总体设计把握

        项目缺乏总体设计的把握，每个人都是只了解自己那块的东西，其他的模块也不了解，在做设计的时候，也考虑不到其他模块的影响和需求。当两个模块之间有交互时，更多的是两个模块负责人之间的沟通和交流。而且模块之间的交互设计是放在各模块开发差不多的情况下进行的，后面涉及到的改动也就不可避免。现在模块之间的交互，也许是各模块负责人最头疼的问题了。（当然，这个问题也不的存在也是无奈，时间紧迫，而且业务不熟，设计也就自然存在缺陷。） 

　　5． 引入第三方技术

       引入第三方技术，是受到项目进度、业务功能和公司所能提供资源的影响，也是不得已而为之 。在经过简单的测试后，就投入项目中使用。值得庆幸的是，第三方技术的引入，还没有对项目造成太大的影响。但是，我们也应该意识到引入不熟悉的第三方组件给项目造成的风险。 

　　6． 没有严格的单元测试

       因为每个成员经验的不同，代码的质量不一样，单元测试是很有必要的。也不能说没有进行单元测试，每实现一个函数都会进行调用，如果得到想要的结果，那就算成功了。但这还不够，我们很少进行边界测试、不合理数据输入测试等，最后在系统测试阶段，出现了很多不应该出现的错误，比如什么对象为空的调用、错误数据等，造成刚开始的测试进度非常缓慢。（没办法，项目工期太紧）

　　下面主要总结一下项目成功的可能因素，比较肤浅。
　　虽然项目受很多不利的因素的困扰，但最终还是交付给用户使用，不管怎么样，这中间还是有很多值得思考的方面。

　　1．  项目经理

　　这个项目经历过很多的困难，从一开始的人员没有到位，到被限定的项目时间，再到需求的不完善等。如果不是项目经理超强的全局把握能力和领导魅力，不论是在封 闭期间，还是在那段加班的日子，依然保持团队的团结和斗志。因为这个项目经理，团队核心人员都没有离去，心甘情愿的跟着他把项目完成。有一个好的项目经 理，对项目来说太重要了。当然，项目的每个成员都很重要。

　　2．  团队的团结

　　我们这个团队，是一个年轻的团队，因为这个项目而组建的，还有一部分成员是没有任何开发经验的。面对很多不利因素，所以能够完成这个项目，很重要的一个原因是团队的团结。封闭的N个月以及加班的N个日夜，虽然很艰苦，但是却是我们团队最怀念的日子。大家在一起，同甘共苦，一起培训，一起交流，一起熬夜，一起吃方便面，一起玩CS，痛并快乐着。即使中间因为讨论而出现过争吵，但从来没有影响过成员间的感情。

　　3．  宽松的管理

　　我的意思并不是说管理松散，而是项目组的柔性管理。在项目开发期间，我们因为某些事情而无法及时到岗时，都会获批处理事情，只要在以后的工作中将这次落下的 工作及时完成，不影响项目计划。我感觉这样的管理方式，至少在我们这个团队执行的很成功。我们不会偷懒，相反我们会更加勤奋地工作，回报领导的信任和关 心。因为解决了后顾之忧，我们还有什么理由不全身心投入到工作中呢？

　　4．  二次开发平台

　　在这个项目中，我们引入了二次开发平台。虽然二次开发平台因为时间的原因，并不是很成熟，中间也出现过一些问题，但二次开发平台在我们项目开发中还是起到了 很大的作用。通过使用二次开发平台，规范了部分的代码开发，减少重复劳动，强化代码复用，让开发人员更多的关注，模块功能，从而提高了开发效率。如果没有 二次开发平台，也许我们现在还陷入在开发的泥沼中。

　　5．  RUP开发过程

　　按照以往的软件开发经验，项目一般都会采用瀑布模型，未必是严格按照瀑布模型的规定的一个阶段的结束是另一个阶段的开始，但大体都是按照这个过程安排项目计划的。在这次软件开发中，我们引入了RUP软件开发过程，采用迭代模型和快速界面原型等开发模型，制定项目里程碑和迭代计划。虽然并不是严格按照RUP规定的迭代进行，因为资源的有限和团队的年轻而有些变味，但还是有效地解决了一部分项目风险。

　　6．  开发规范

　　据我了解，还是有一些公司没有一个统一的开发规范，代码质量的好坏都是由个人的开发经验决定的，我现在的公司在我来之前就是处于这种状态。在这个项目中，因 为进入开发阶段后还在招聘人员，能力参差不齐，而且有一部分是没有开发经验的，这就对代码质量提出了挑战。为了能提高代码开发质量，我们引入了开发规范， 制定了开发过程中的一些规则，所有成员都要求按照这个规范进行开发。虽然成员在刚开始时受制约而感觉有些麻烦，但这样的开发规范，不管对于项目还是整个公 司，都是重要的。