项目杂记

      前不久接触到一个项目（客户是一个事业单位改制过来的国有企业），在我眼里，这个项目是个失败的项目（虽然领导是不可能承认失败的），失败到让我有写下来的冲动，生怕自己会重蹈覆辙。这些问题中有些是有明显的答案或者说管理措施的，但有些很难说有一个统一的答案。

1、 项目经理对需求变更没有任何的控制，基本上只是一味的答应客户的需求变更。
2、 项目组士气低落，项目经理从来没有想要搞个项目组活动，提振提振士气。而且，部分员工通宵加班，最后的绩效考核却很低，搞的项目组内怨气冲天。
3、 项目组成员在通宵加班的时候，项目经理却早早的回家睡觉了…..
4、 现场开发，有利于获取用户需求，但是，也会让客户过多的干扰项目组开发人员。而本项目客户对项目设计开发的干涉程度已经达到了严重影响正常开发的程度。

5、 需求经常变动。原因有三：第一，客户直接负责项目的人员（通常在总部）自己都没有明白业务流程；第二，客户直接负责项目的人员自己认为的业务流程，其实与真实的业务流程（一线员工的操作流程）不同；第三：领导的要求（具有中国特色，给领导演示时，领导总是要提点意见的，否则显得领导太没水平）。
6、 缺乏基本的评审，开发人员随意设计、开发自己的模块，稳定性、健壮性都不太满意。
7、 众多子系统，部署在不同的服务器和容器中，而其中某些子系统完全没有必要独立部署，大大增加了不同子系统之间的交互，而这种交互在部署在同一个应用下就可以省略。
8、 缺乏必要的需求、分析文档，测试人员（到项目后期才加入）无法透彻了解需求，能测出多少深层次的问题呢？
9、 使用了较新的技术框架（Flex），而且项目开始时，所有开发人员没有一个人懂Flex。最后除了一个外包人员做过一次Flex项目外，其余的都是现学现做。项目经理在选择系统技术框架的时候，有没有考虑到风险？
10、 很多代码无法支持正常的商用，比如获取查询结果的总条数，居然用list.size()，数据有几千条时，就能感觉的出比较慢了。而系统是要求支持几十万、几百万甚至更多的数据量的。通过代码评审、走读，或大数据量的测试，都可以把问题找到。

      暂且这么多吧，项目还有一些技术实现方案，很值得探讨，以后有时间再写出来，让大家一起来推敲推敲。