一个非常稚嫩的项目经理的艰辛历程-2.总结过失+改进方案

友情提示：由于这是具体项目的反思+总结，项目又涉及到公司的一些内部的平台系统，但是我相信有一点常识的开发人员是能够理解的。

项目整体感悟：项目是公司的生命线，一切给项目带来风险（质量、时间、成本）的，都是不合理的。改革从项目抓起。

 

需求阶段2010-5-27.doc

 

1.需求描述不够清楚，导致测试人员不清楚项目整体有哪些需求。

2.需求评审时忽略的一些必要的信息，如数据类型，传输方式等。

3.需求还不够具体，不够细致，不能充分的反应用户的操作方式。

4.测试进入比较晚，在项目进入编码阶段，测试人员开始进入(人员紧张)，对需求提出很多很好的建议。

解决方法：

1．  测试组、开发组成员、美工组要提前进入，协助项目经理将需求做得更细致到位。

2．  期望的需求阶段流程： 细化需求、会上讨论重点（争议）。

 

设计阶段2010-6-2.doc

 

1.美工功能原型设计粗糙，没有进行合理的评审。区别见附件：\附件\监察记录.bmp 和 \附件\美工原型\监察记录1.jpg, 监察记录2.jpg

2.开发人员对界面的设计和与用户的交互方式上缺乏经验。

3.界面设计的经验库可以积累，美工之间是可以相互评审的，以保证质量。

4.针对PDA这种与用户交互很强的开发工作可以在概要设计的过程中将用户交互方面作为一个重要的方面进行评审。（评审的重点的改变）。

 

   我画功能圆形的初衷是展示界面中需要显示的元素，让美工设计一下展示的方式，以保证界面操作的友好性。

 

解决方法：

1．【公司项目经理培训】【风险管理】【问题升级】 当一个问题可能严重影响项目的时间、质量、成本时，可以将问题升级技术经理层面，技术经理出面协助解决，以降低项目风险。

前提：清组织结晰的构，可以随时查看到的。遇到问题时知道找那个技术经理。

 

概要设计阶段 2010-6-10.doc

 

1． 概要设计文档设计的相当的不到位，没有严格的概要设计评审、把关。

2． 详细设计由于开发时间比较紧裁掉了，导致后期的实现阶段，开发人员以自己的设计为中心进行整个的系统开发，出现设计的缺陷了很多的时，进行代码的重构，浪费时间和精力。

3． 对进行概要设计和详细设计的开发人员进行有效的指导、培训。

 

解决方法：

1．  概要设计、不要轻易裁剪详细设计，可以忽略部分不重要的模块设计。

2．  概要设计、详细设计阶段需要技术指导。

3．  概要设计、详细设计的评审，合适的人去评审.

 

编码阶段2010-06-17.doc

 

1.      项目再次偏移2周

A．项目计划本身不够客观合理，没有包括单元测试、开发环境的布置的时间。（遗漏了一些东西）。

B．开发人员对采用的技术WebServics不够熟练，导致耗费了大量的测试时间。

C．服务器端的业务比较复杂，开发人员对业务不够了解，所以就会有牵一发动全身的感觉，导致功能点的开发不断的修改，自己也不是十分确认。

 

2. 开发人员手中拿到的版本需要统一管理。

 

解决方法:

1. 项目计划的制定，和评审。

2.为二次开发（像PDA）提供一个稳定、健壮的环境。

3.加强业务知识的培训，培训开发人员捕捉需求，分析业务的能力和方法。

4.代码质量不高，建立人才梯度、增加审查、评估体系 。

5 WebServics 新技术需要培训，怎么发起，谁来培训。

 

编码阶段2010-06-24.doc

 

1. 由于时间、进度限制，功能实现的不够细致。

 

数据同步存在的问题 ：

1.信息服务器只支持批量更新，不支持单条记录的更新。

2.批量更新时由于数据量可能很大、信息服务器不支持分页。因此，

 

首先获得按更新时间排序的节点ID列表

然后客户端按不同节点ID进行一条一条请求。

最后本地出来，增加所有记录，如有记录已经存在，先删除记录然后在增加。

3.服务器端删除同步暂时没有实现。

 

解决方法:

1. 在计划时间比较紧的情况下，重点实现关注程度比较高的需要。

 

测试阶段2010-07-12.doc

 

1.      需求变更导致测试用例更改。

2.      在问题确认以后，测试用例更新的问题。

3.      严格控制需求的变更、走需求变更流程。

4.      可以规避一些Bug等到下一个版本再修改。

5.      测试的结果中包含PDA客户端的Bug和服务器端的bug，增加测试负担。

 

测试阶段2010-08-11.doc

 

1. 平台版本不够稳定，监察记录查看不了，给测试人员带来一定的难度。

2. 开发过程中不够仔细，插入到数据库里的记录没有和字段对应上。

3．我们为测试做计划不知道合不合理，不知道每天测试做了多少工作，不知道时间安排的是否合理。

 

解决方法：

1.管理方面需求变更要走严格的变更流程，同时在变更后及时更新项目计划、风险管理、测试人员更新测试用例。

2.希望在新的项目中后台综合业务的测试能和PDA的测试逻辑上独立。

3.项目经理制定测试的大概计划，详细计划由测试负责人自己制定。

 

版本控制.doc  

搭建测试环境出现的问题.doc

 

1. 发布开发包以后，查找错误比较困难。各个【服务器】（公司内部的平台）提供的错误信息比较少，分析和定位问题比较困难。

2. 搭建各个服务器的环境过于繁琐，出现问题的概率大大增加，通常都得2-3天的时间。

3.测试人员从配置管理员拿到要测试的包，正常情况下开发人员不应该随意的进行代码的修改，但是实际情况是开发人员经常会手动的修改一下jar包，导致项目的版本无法控制

 

解决方法：

1. 平台出通用的配置文件（已实现）

2. 项目根据自己的配置出相应的 “项目配置说明.doc”。

3.测试人员监控开发人员对安装包做过的所有改动，并及时的反应到项目经理这里，便于对版本的整体控制。另外，在发给客户前的最后一轮测试时，所有的包都必须从配置管理员那里获取，开发人员不得有任何的修改。

 

团队意识缺乏

 

解决方法:

1.       开项目周会，发现和解决问题、跟踪成员的完成情况.树立团队意思。

2.       对整个项目的计划进行时间的度量，形成拓扑图，查找关键节点，对降低项目风险很重要。

3.       配置管理是对单个对象的版本控制，无法对对象之间的进行控制。

 

 解决办法：当一个对象改变时，通知和他相关的对象，进行修改。

 

 

 

上面出现的问题都是自己分析的解决方法，一部分也没有经过有效的论证，希望有想法的兄弟们给出你们的答案，感激不尽。