项目总结心得体会
随着各个项目实施的展开，项目各多多少少都出现了一些问题，或者是发生了事故，或者指挥和管理出现一些混乱，影响了工作目标，留下了隐患。及时总结这些经验教训是非常必要的，下面从项目管理角度对出现的问题和事故进行分析和总结。
1、 对项目经理的现场指挥
关于对项目经理的指挥，现在感觉有些混乱。项目经理在公司时还好，方便协调和管理，但他们在客户现场会遇到很多问题，商务的，技术的，有时还混合在一起。跟他们沟通的渠道也多，销售、商务、老板…… 可能就会有多个指示或者信息传给他们，且还不完全相同，如果项目经理个人的能力和经验足够，可能会处理得让公司和客户都比较满意，否则，他们会无所适从。
比如去年某项目组第一次到客户现场，发现此前在家准备的一套调研计划完全用不上，突然变成要马上写出方案并交给客户评审，作为项目总监，我怪他们没有留出一点家里评审的时间，所以要求往后推一推，而销售总监则说越早评审越好。
另一个项目组也是这样，有关需求控制，如何跟客户谈，跟谁谈，主要是销售和项目经理在沟通，老板也会有指示。作为项目管理部门的最高领导，我本人也不是每个业务领域都很熟悉，我在销售、项目经理、老板之间把话传来传去的，可无论哪一方，对传递的指示和信息提出问题，再说出一大套实际情况如何如何，我真是有些晕。例如项目经理一直跟我说他在检验中心的需求调研属于售前，是按照销售的指示来做的。说给客户做好需求，写好报告便于拿下这块。因为我对涉及的业务也不熟悉，由我来给项目经理传达指示也真怕耽误事。虽然我名义上应该管这些事情。
所以，还是得有必要明确哪一类问题谁做主，比如属于客户关系、合同范围，项目经理就应当听销售的。不能教条得去进行项目管理。
上周加了个班，这也是来本公司加班时间最长的一次，两个总监、三个部门经理加上项目组的3个人，竟然从晚上6：00一直干到凌晨7：00！而且说起来可笑，加班内容居然是做最初级的文字校对和审核工作。因为这次是咨询项目，最终交付物就是文档。所以客户也格外仔细，要说我们公司规模也不算小，平时质量体系流程抓得挺严格，谁知还是出了错，公司借此一查，好家伙，才发现很多文档都有问题，只是作为软件企业，一般最终交付物都是软件，客户也没那么认真罢了。 总结出文档常见错误有：
一． 模板使用
1. 未使用最新发布的模板；
2. 擅自改变模板的结构或内容。
二． 文件名不规范
3. 文件名中“项目编号”与《项目任务书》中确定的“项目编号”不一致；
4. 文件名中缺少下划线“_”；
5. 记录类文档文件名中的日期格式不规范，日期格式应为“YYYYMMDD”；
6. 记录类文档文件名中的日期与文件编号中的日期不一致。
三． 文件封面不规范
7. 技术类文档封面“文件编号”中的“项目编号”与《项目任务书》中的“项目编号”不一致；
8. 技术类文档分模块编写时，“文件编号”中未将可选标记“【】”删除；
9. 记录类文档“文件编号”中的日期格式不规范，日期格式应为“YYYYMMDD”；
10. 封面中的“项目名称”与《项目任务书》中的“项目名称”不一致；
11. 封面的审核、评审日期与相应《评审报告》/《会签单》中的相应日期不一致；
12. 封面审核、评审人及日期未填写；
13. 封面版本号中不应写“V”，且应与历史记录、页眉中的版本不一致；
14. 文档升版后，封面的审核、评审日期与历史记录中对应版本的审核、评审日期不一致。
四． 页眉不规范
15. 页眉中的版本号与封面、历史记录中的不一致；
16. 页眉中的版本号仍保留模板中的版本号，未按实际文档填写。
历史记录不规范
17. 历史记录中仍保留模板的内容，并未填写实际文档的历史记录；
18. 历史记录中的日期格式不规范；
19. 文档升版后，未填写历史记录（文件审批记录、文件变更记录）。
六． 目录不规范
20. 完成文档后，没有重新提取目录；
21. 目录字号、字体不统一；
22. 目录中存在小型大写字母。
七． 正文不规范
23. 字号大小不一致，有的是小四、有的是五号；
24. 行距不一致，有的为单倍行距、有的为1.5倍行距；
25. 有些段落首行未缩进或缩进距离不符合要求；
26. 标点符号使用不当，且全角/半角不分；
27. 图片插入时是在段前空两格状态下插入的，此时设置居中时图片实际并未居中；
28. 有些插入的图片中有鼠标、输入法等无用信息；有些插入的图片上有马塞克；
29. 有些图片和图片题注、表格和表格题注分在两页上；
30. 有些文字描述太过口语化；
31. 某些章节下未填写内容但没有给出原因；
32. 有些章节保留了原有模板中的说明性文字或示例，没有删除；
33. 如纸质签字的文档（如评审报告、会签单、基线申请单等），对应的电子文档未按纸质填写完整。
八． 编号不规范
34. 标题使用混乱，且有时出现标题不连续的情况；
错误重复在犯
上周紧急处理了1个项目事故，说起来真是感叹不已：这个事故居然两个月内重复了3次，结果虽然一样，但是犯错的过程却每次都不一样。
公司严格执行“内，外网”制度，凡是最后要提供给客户的软件都必须从内网拷出，拷贝的流程极为严格。一般是项目经理提交 “软件出厂申请单” ，说明要拷贝的模块名称和License起止日期，以及要安装的机器MAC地址。期间经过实施部、开发部、质量部、商务部的审核，公司总裁签字之后，运维部才会拷贝出来，拷贝出来之后实施工程师还要当场验证一把，确认无误，才会带到客户现场进行安装部署，可就是这样严密的流程，竟然2个月内出了3次事故！由于最后一道审核人是公司老板，老板脾气又大，出点事情就把大家抓过来痛骂一顿，搞得人人噤若寒蝉，各个紧张兮兮的，不可能不重视啊，可是偏偏还就老出事，真是邪乎了！
于是，我组织各部门认真反思总结了一下发生在该项目的问题，尤其是项目管理上的漏洞，追究责任是次要的，关键是要引以为鉴，后续项目不要再出现类似的事情了！
第一次事故大概在5月上旬，项目组给客户安装系统试运行，到了现场发现系统用户不能登录。项目经理当时就有些慌张，因为以前未发现，想到老板最恨已经出厂刻盘的软件系统再重新刻盘，心里就有些紧张。接到报告后，我安慰他，不要着急，想想原因。经查明是由于在此之前的系统版本都是启动jboss和license两个服务，而该项目版本为jboss和license的集成版本，只需要启动jboss服务即可。测试人员修改了服务器启动规则，却没有及时通知实施人员，实施人员不知情，启动了jboss和license两个服务，导致个别license文件冲突，系统用户不能登录。应该说这一次的事故主要是由于以下几点造成的：
1）项目参与人员没有做到知识共享，信息传递不充分；
2）实施人员只在测试环境对系统进行验证，没有充分验证系统的有效性；
3） 实施人员在出盘这项工作中比较依赖测试部，对自己的本职工作不清晰，没有从业务及实际环境对系统进行验证工作；
过了不到1个月，因为修改了一些Bug，第二次给客户安装系统时，项目经理和实施人员在现场的系统调试过程中，发现系统中的用到的第三方软件的一个功能出错，又打电话报告申请重新刻盘。这一回，又是各部门一通忙活，认定为给该系统安装的第三方软件版本不对，经查明，主要原因在于测试提供给刻盘的第三方软件版本与该项目所需要的软件版本不符造成的。这次我认为跟部门领导对于员工的责任心意识教育不够有关，明明公司三令五申，不能擅自更换软件版本，非要那么随意，想换就换！除此之外，没有将第三方软件纳入配置管理也是1大问题，版本无人管啊，也是容易乱！
近日，该项目终于要验收了，虽说出了点事情，但总的说来，这个项目控制得还是不错的，进度，成本和质量都还可以。出了两次事故，我们也反复强调注意事项，同时弥补管理上的各种漏洞，要求各个部门经理作为第一责任人。大家都想这回怎么着也该没事了。谁知上周我正开会呢，开发部经理神色慌张得来找我：“刘老师，XXX项目现场又出事了，说是License错误！”天！不过这次大家倒都挺镇静的，处理突发事故也有经验了噢，不到半小时，就找到原因，商务人员对License生成软件操作不熟悉，生成的License文件不对，而不到客户的机器上安装是查不出这个错误的。前几次都是运维部生成的License ,自从老板要求实现“三权分立”的思想，就把生成License的工作交给了商务部。如何保证商务人员也能正确生成License文件，还得在流程上增加一条啊！
看样子，无论多么完善的制度和流程都有改进的空间啊。