第一个项目（LIMS）管理经验阶段总结-测试版（待续）

      项目终于进入到测试版，感觉很高兴。但是同时也是最忙的时候。

     这是我第一次以项目经理的身份做项目，激动多于紧张、兴奋多于谨慎。导致的结果是在测试版应该出来的时候核心模块还没有完成。现在看来，这些问题完全可以避免。至少在项目之初的时候就可以将这些问题解决，先做什么后做什么看起来是很容易选择的问题。但是事实并不是如此。随着需求的变更，项目做起来也是很不顺利。当然这在所难免！

    现在对于我的问题不是需求的变更，而是变更后如何处理。我本来是一个培训讲师，由于这个角色决定和我做项目的是一些培训的学生。而且同时我还要教他们其它的课程，还要教他们如何解决在项目中遇到的问题。有些事情如果是员工很好解决，但是现在却不能像员工一样管理他们，反倒要想老师一样培训他们。这在进度偏慢中占很大一部分原因。另外一个原因大概就是自己没有订好计划，同时也没有完全按照预先的计划来完成。计划制定是一个过程，执行又是一个过程。这2方面是2个事情，不能混淆。然而对于学生来说他们没有那么高的悟性，在他们看来，干活是学习，学到东西就可以了，活能不能出来并不重要。这个我可以理解，但是从我的角度来看，事情就麻烦了。活干不完是要挨骂，客户还有老板都不好交差。所以与其说我是经理，还不如说我是程序员+经理+讲师+架构师。能不累么！

    需求的变更必然要有文档出来，至少是有需求变更记录。这在后期的开发中可以和客户很好的沟通。有人说沟通无极限！同意。

    这个项目原本被定义为练兵+小活。但是这种定义本身就矛盾，而且和培训的出发点矛盾。说它定义矛盾是因为：练兵本身对时间要求就不是很严，而是将活做完即可。但是如果是小活，要求就是时间短见效快，不到一个月拿出实际的东西出来。矛盾就是这样产生的。另外一个矛盾就是和培训的矛盾，如果说我是一个培训讲师的话，我可以将一个真实项目拿来讲，而不是同时做。在培训的时候做项目自己的精力无法保证，同时项目的质量进度都无法保证！

    所以经验之一就是要充分保证开发人员的时间，让他们没有后顾之忧，这样的开发人员才会拿出全部精力去开发。如果我是主管，我会和leader一起讨论项目进展，一起制定计划。每周的周一一起讨论一周的任务，周五总结。存在技术问题，则高手攻克。存在沟通问题，自己出面协调。出现需求偏差，和客户讨论。出现需求变更，及时通知确认。

    项目管理是个大问题,如果没有做过项目很难体会到.从一个管理者角度来看,如果是一个纯正的项目管理者,是不需要实际开发的,而是要将主要的精力放在研究需求上.这也就是说项目管理者主要做的是对人的管理,对整个项目的管理.主要职责应该是调动teamers的积极性,对客户负责,对老板负责,对项目负责.如果一个项目管理者进行开发,那么占用的管理时间所产生的负面影响远比他coding的东西更严重!

    这次做为PL的一个失败就是coding太多,但是手下的人做的东西实在是bug太多,而且他们主要还是学生.所以自己coding给他们做demo.从这个角度来说,还是可以原谅的.对于那些学生而言,能有一次相对来说比较正规的项目开发,对于他们的技术职业生涯,我感觉要远比做十个demo强的多.所以从我和学生来说,我们都各有收获.

    客户关系是我想讨论的第二个问题:

    客户关系得建立和合作是一个比较大的学问.从客户的角度来说,我不想知道你怎么做,我不需要你拿什么技术做.我要的是最后的成品.要得是经受住考验的测试版.这其实对于一个项目而言是比较普遍的问题.如果解决,我感觉对于一个新的小的公司这是一个大问题,但是对于有很多开发经验的公司而言,这不是问题.为什么这么说,如果你开发过很多东西,无论是OA,还是ERP,只要你开发过超过3个不同方向的项目--我是指你做的包括低层和前台的大部分.你就会感觉到其实客户认为简单的东西不是那么简单,但是他绝对不是第一个提出这样要求的客户.客户感觉到复杂的你会感觉很简单,而且极有可能他是第一个提出这样要求的客户.我得意思是说:客户往往和我们想的不一样.一般化的东西很难做.单独的要求总是很好做,但是往往是项目特有的.这时我们的策略是不讨论项目的负责度,在时间允许的范围内尽可能争取时间,同时在项目最开始让客户排除模块优先级虽然最后每个模块都要开发完,但是对于项目组成员而言,在项目最开始往往士气很高,最后往往有些疲倦,那么我们为什么不前紧后松呢?!