**电网公司*******项目总结

 

这个项目进行了大半年，现在暂停下来了，正好停下来好好思考。

      去年11月份，我换了新的工作，去了一家外包公司。刚进公司就直接外包到大软件公司参与一个新项目。虽然要出差到省外，但是我觉得还是很幸运的能参与到一个完全新开始的项目，这也是我的第一次完全体验整个项目。到现在回过头来看看，确实是一段难得和难忘的经历。

    项目刚开始时，就让我知道了一些新的东西。比如全公司各个项目采用统一的框架，及统一的项目管理文件目录。在项目中期，公司又中标了新的项目，为了更快速的建立给用户演示，公司直接从其它已有的系统抽取模块，快速的构建新系统的界面原型，这让我体会到了统一框架的好处。

      当然大半年的项目做下来，感受还有更多，下面尽量列出：

 

1. 项目背景: 这个系统是***电网公司全省推广的******项目，这是个不太复杂，但较重要的业务系统。另外还有个情况，即***的**市，及**市已使用另一家软件公司开发*******系统二年多。

这个不算太特殊的背景还是让我们吃了些苦头。在后续的设计和开发过程中，怎么看待旧的系统，是参考还是模仿，或是完全不管，我们争论了不少时间。从后来的决定和现在的角度看来，我们要做的是，模仿旧系统的加强版。至少有一个原则：以前有的功能应该也要有，以前有的缺点现在绝对不能有。不管这个决定有没有通用性，但我觉得至少很有现实意义。

 

2. 项目定义: 这是省**公司的项目，当然涉及到省内各市，这是我们的理所当然的理解，而且是省项目，当是是省部门主管。我们也刚开始就考虑省部主管这个系统，很多功能也是这样做的。但一段时间的交流后发现，是各市部门主管，省公司只看报表，根本不管这个系统的运行。从这个问题上，我想我们是没有及早的站在各相关部门用户的角度去看这个系统，可能很相关，可能根本无关，不同的用户对这个系统的定义可能不一样。当然也可能是业务理解不深造成的。

 

3. 项目预警: 现在项目停了下来，主要是因为我们系统与电网公司已有系统的接口无法继续造成的。当然这个情况也特殊，我也不知深层次的原因。但还是觉得一个项目，接口应该属于外部因素，而外部因素是应该提前考虑，和重点考虑的，有时它会比需求变动还可怕。另外，我没有做过项目管理，也没有做过项目计划，但我想在项目初期就进行项目预警，考虑计划中最重要，最困难的关键点，比项目计划更重要。

 

4. 项目需求分析: 在说其它原因之前，我们与客户的交流不够，或无法足够多的交流，是一个最主要的现实情况。应该是我经验太少的原因，因为到现在，我还是像所有夸夸其谈的人一样认为，需求调研和分析不够。还有一个原因是我认为，经理在项目刚启动时的准备使用的快速原型系统没有实施起来。快速原型系统是一个由简单html页面组成的，二三天就做好整个系统了，但最终只是做为我们开发的依据，而没有去拿它与用户交流。虽然简单，但我觉得足够，从过了两三个月后拿直正的系统去演示的结果来看，绝对足够，但是它简单，能提前让我们自己主动去找用户交流，这是极好的。

 

5. 业务规范操作文档： 虽然接口无法续续，我们还是去找了一个市去做推广，但很快碰到一个钉子，因为这个市之前没有用过这类系统，所以在演示系统时，没有一个用户说听明白的，与会的领导最后叮嘱了一句：下次先讲业务规范操作文档。后来，在经理的提示下，才知它是给用户解释我们的系统在运行后，用户通过怎样的操作，来实现业务功能，简而言之，就是系统需要具体哪些业务人员配合，如何配合的文档。这是我在这个项目见过的最重要的文档，因为在写它的过程中，我们又发现我们自认为完成的系统上业务逻辑问题，这是很严重的。后来，我们当然一致认定，这个文档需要更早的时候完成。

 

 

6. 开发文档: 因为具体负责系统开发的组长崇尚敏捷开发，所以当初不大肯写文档，但后来还是有改之。现在看来，特别是人员变动时，在我们为不停地重复争论一个问题而无解时，我们才发现文档是如此重要。

我想如果一个系统有生命，那文档应该是它的灵魂，最可怕是这些灵魂只存在主力开发人员的脑子里。

 

   正如开头所言，这是我的第一个完整的项目经历，上述的认识肯定是浅薄的。但仍然记之，以催促自己思考。