3.2.5结项总结
很多公司在项目完成后往往忽视了后的总结,没有把在上个项目中得到的经验教训进行分析,转化成公司的巨大财富。我们认为,项目的总结是整个项目的不可缺少的重要组成部分,只有通过详尽的充分的项目总结,才能使项目组的所有成员对项目的历程有一个清楚的了解,提高他们对软件项目的认识;才能真正地把以往的项目纳入公司的资源库,转化成巨大的财富。
我们的做法是在项目完成后首先由各个项目成员写出各自的总结报告,包括所从事的工作、任务的完成情况、遇到的问题及解决方案、对项目过程的意见和自己的想法等内容。项目负责人需要把整个的项目历程整理成一份文件,其中包括项目的介绍、项目进行的具体资料(如实际花费时间、源代码数、功能模块数量等)、项目计划与实际的比较等。
在上述完成后,全体项目参与人员举行项目结项工作会议,对各人所列举的问题及想法进行讨论,目的是得出好的经验教训,从而指导后面项目过程。会议可由分别针对的问题分为几个部分,如项目过程方面的、质量管理方面的、技术方面的等,整合后形成结项会议报告。
项目负责人后把项目历程、资料、在结项会议中总结的经验教训等整理成一份总的项目过程文件,归档并分发到各成员和上层领导,并由项目经理向上层领导汇报,这时,一个完整的项目才真正告一段落。这些项目资料给以后的项目提供很好的模板和借鉴意义,并可以作为以后项目预估的依据。
3.3风险管理
微软公司认为,软件开发是一个风险驱动的过程,由此可看出风险管理在软件项目中的重要性。一个项目的风险有许多来源,如客户、进度、开发过程、人力资源等,忽视风险的后果可能是成本超支、进度推后,严重导致项目失败。项目管理培训
MSF的风险管理原则是:
1.风险应该在整个项目的进程中一直被估计,并且作为项目决策的依据之一。
2.有效的风险管理过程覆盖了所有关键的人力、过程、商务及技术领域。
3.风险在纳入管理前必须被清晰的表述。
4.重要的风险必须优先被处理。
MSF风险管理过程包括以下阶段:风险识别、风险陈述、风险分析、处理计划、风险跟踪、风险控制、风险解除。
在中小企业的风险管理过程中,一般项目经理担任风险管理员的角色,但同时需要另外的开发人员辅助,一起完成风险管理的任务。他们负责维护十大风险清单(不一定非要列出十个),并在项目进程中随时对风险清单进行更新。对风险的评级MSF采用的方式是:风险影响程度=风险的可能性×风险发生造成的损失,根据风险影响程度的大小对风险进行评级。项目经理博客
在项目实施中,我们总结的一些高风险事件主要有:需求的不准确、项目时间表过于短促、开发一个从前没进入的领域软件、开发人员对工具的不熟悉、人员流动频繁、使用了外部软件中间件等。如果对这些风险不提前作出计划,可能会对项目的顺利进行造成极大的破坏,甚至直接导致项目失败。针对每一个风险,我们需要列出who, when, how, how much等事项,并对风险处理的结果进行追踪,后决定是否已经解除风险或再进入风险处理循环。
一般国内公司的风险意识不强,没有很好的去规划处理风险。我们当时也是这样,往往要等到风险已经发生了,才意识到原来没有注意到这些问题。在风险的管理上,还需要更多的实践探索,首先应该从加强风险意识开始。项目管理者联盟文章
3.4质量管理
关于软件质量管理,现在已经得到了很多公司的重视,这里我想针对性地强调几个问题:
1.质量管理不单单是测试。一个容易犯的错误是把质量管理和测试等同起来,如果软件有问题是测试没做好。其实质量管理包括很多内容,如技术检查、缺陷追踪、源代码追踪、单元测试、系统测试等。
2.质量管理不是在代码完成后才开始,质量管理应该贯穿整个项目始终,从需求、设计到编码、测试。我们往往只重视了后期对代码的测试,而忽略了对需求、设计的质量管理,而前者比较起来可能更为重要。因为处理一个在后期才发现的错误比处理一个前期发现的错误的成本要高几十倍。training.mypm.net
3.使用缺陷追踪管理工具。我们的实践证明:使用缺陷追踪管理工具比以前单纯的使用文档传送方式的效率提高几倍,并在管理诸如优先级、防止遗漏等方面有更大的优势。training.mypm.net
3.5其他
这里谈一些没有包括在上述内容里的经验教训,供大家参考:
1.项目管理工具。我们使用的是MS Project来管理项目过程,Project一个很好的优点是能把项目管理的内容自动发布到网站上去,这极大地方便了各阶层人员对项目状态的了解,有助于及时发现问题解决问题,对项目组成员也是个很好的激励方法。转自项目管理者联盟
2.项目团队中需要开发人员。我曾经经历过一个项目,项目负责人坚持用C++ Builder开发(可能是为了学习的原因),但是公司没有任何一个人对这个工具非常熟悉,也没有进行相应的风险管理。结果在项目的过程中出了太多问题,使项目一直延期,在交付的时候都还存在很多问题。所以在项目团队中一定需要开发人员,特别是在项目的前期更是如此。
3.再次强调产品经理角色。必须牢牢记住:一个不管使用了什么先进技术、开发方法的产品,如果不能满足用户的需要,是一个失败的产品。而产品经理角色的设立能较好满足这一要求。
4.在领域性较强的项目中,好在基本的软件架构上(如COM或J2EE)实现一个该领域的基础开发平台,这样在以后的扩展上,在具体项目的实施上,都会极大的节省成本,软件的质量也有良好的保证。