Masterpiece

Sow a Thought,Reap a Action.
Sow a Action,Reap a Habit.
Sow a Habit,Reap a Character.
Sow a Character,Reap a destiny.

种一个思想，收获一个行动；
种一个行动，收获一个习惯；
种一个习惯，收获一个品质；
种一个品质，收获一种命运；

1.PMP新解：P(Prople),M(Management),P(Project).
2.项目管理的精髓思想：管理变更、管理风险、重视计划的力量。
3.项目管理文档化，经验教训知识化。

    项目收尾可能是我们在开发项目中最容易忽略的一个环节，原因很多：比如项目组马上会启动一个新的项目，无暇估计已经完成的项目，或者，认为项目已经结束，可以好好歇一阵子了，等等等等。
    实际上，放弃项目首尾管理的机会也就相当于放弃了一个团队提升的机会，纵然我们能够在开发过程中学到一些东西，但每个人学到的必然是有限的，中国有句古话：三个臭皮匠顶一个诸葛亮，在项目结束的时候坐在一起总结一下得失是必要的。
    个人觉得在项目首尾的时候重点检查下面几点：
    1.在整个项目开发过程中，哪些步骤或者哪些措施得到了很好的效果。
    2.哪些项目管理手段并没有收到预期的效果，为什么？
    3.哪些文档在开发当中利用率不高，也就是说没有太大的意义？ 
    4.项目质量的起伏有没有原因（比如跟踪项目的关键事件以及Bug的趋势图也许会发现项目中哪些关键事件影响的项目的质量，比如我们在这次开发中能够明显看出PM插入新需求必然导致Bug有明显的上升趋势，当然这个不用分析也可以知道），实际上通过这些数据的分析本身能够发现一些潜在的问题。 
    5.哪些会议是低效的，为什么？
    。。。。。。。
    其实还有很多，需要自己总结，当然采用Brainstorm的方式也不错。

    对了，最重要的别忘记：项目干系人聚在一起庆祝项目的顺利结束。

    对于每个项目，不管成败与否，你总结了吗？

    在各式各样的项目管理类书籍中都提到过，对项目进行WBS分解，分析任务并指定负责人即Task Owner，画出任务间的关系依赖图，查找关键路径，制定GANTT图，给出风险列表并赋予优先级的定义，回顾以及优化现有的计划并改进。这只是项目计划这个过程要做的事情，然而实际项目开发中，是否有足够的时间来做这些工作呢？不知道大家所在的公司在这方面是怎么做的，可不可以说出来大家学习探讨一下：

    我先开个头，我所在的公司是一家提供企业信息化产品软件的公司，有时候迫于产品的上市压力以及客户的压力，在项目计划阶段很少有显式的WBS分解，一切都是Schedule说话，而且往往Schedule上的任务也都是粗粒度的，没有详细的定义以及沟通与职责说明，风险管理也趋于形式，没有分析以及应对策略的定义，至于关键路径的分析，以及在分析关键路径时候对活动时间的安排也没有，从而导致在项目开发过程中常出现要不忙的要死，要不闲的没事的情况。总之，是纯粹的敏捷开发啊！呵呵！大家谈谈吧！