项目管理的感触

      最近一直忙着加班，很久没有写blog了，偶尔看到一个敏捷个人中提到要多写blog，多分享。想想也对，很多事情经历之初，印象深刻，感触也很多，但随着时间的流逝慢慢就消散了。事后自己也忘记了当初是何感受了。在这里就写写自己做项目管理的感触好了。

      由于之前一直在忙GIS的项目，后来项目结束了，本想着可以稍轻松一点了，谁知又来了个”中途出家“，硬是被拉到了已经开始好几个月的一个项目中。开始还负责底层流程的搭建，用的是微软4月份刚退出的WF4.0。虽然WF早期版本已经出来多时，但自己一直未曾接触。刚接手用WF4.0建立业务流程有点头晕，不知如何下手。看了老外写的一本《Begining WF Windows Workflow in .NET 4.0》基础的总算有点概念。而系统中用到的大部分也是基础的。做了一段时间完成其中几个流程的搭建，由于人手关系，其中一个子系统无人接收，自己又被抽出来去做子系统的分析设计，做来做去最后成了这个小团队的负责人，负责底层流程的搭建，负责人员的安排等一些事情。

      虽然子系统不是太大，但是和另外一个项目相比，软件开发管理方面还是有很多感触。

      1. 时间和实现间的一个权衡。当时接手这个子系统的时候上层领导说只有十天时间要开发并测试完成，说实在的当时压力还真不小。虽然不是什么大系统，但麻雀虽小，五脏还需俱全。由于经历了之前一个系统流程的搭建，感觉用WF4.0实现业务流程还是较为繁琐，且灵活性不高。就想自己设计一个简单的工作流流转组件，设计出来后，没有可以和自己一块开发，时间又紧迫，最后只能夭折了，还好用WF4.0来搭建，但是相比另外一个系统简化很多，没有考虑太多的流程灵活设置。

      2. 一个好的整体规划 。项目启动后开始进入编码阶段，事先的整体规划非常重要，之前也是听人说说而已，没有亲身体验过。仅参与底层工作流搭建的那个系统，一来真个系统较庞大，二来时间较短，开始编码是没有一个人负责整体的规划，只是将系统进行功能模块的划分，让团队成员各自负责，其中又缺少了一个致命的环节：系统设计。很多开发人员原原本本的根据需求人员编写的需求文档进行开发，没有经过自身的一个理解和加工。结果整个系统界面做出来，失去了B/S结构的页面效果，一整个C/S窗体样式，囧o(╯□╰)o。

就我个人而言觉得界面原型设计还是不能让需求分析人员来做，就目前所在公司的情形，需求分析人员完全不懂技术，做出来的界面原型也可想而知了。随说页面呈现是小事，但事后再去修改，页面一多也是很大一工程，而且交繁琐。

     3. 团队成员间的分工合作与协调，前期分工按模块划分，结果导致底层公用部分多个人去写，做了很多重复性工作，致使人力时间的浪费。而开发期间成员间没有及时沟通，很多隐藏的问题一直遗留到系统集成，模块间的衔接出现了问题。

       或许很多问题都出在团队的不够成熟上， 在此做个记录，以便自我提醒，O(∩_∩)O~~~