项目干系人管理--承建方项目组

 “在TQM阅读全文 | 回复 | 引用通告

如果说要给改进定义一个模型的话，螺旋式上升应该是最好的。从横向来看，改进是闭环，从纵向来看，改进是持续的。

何为防火员和救火员？

先从事情说起，事情按轻重缓急可以分为：紧急重要、紧急不重要、不紧急但重要、不紧急不重要。

我想防火员做的应该是不紧急但重要的事情，而救火员一般处理的则更多的是紧急重要和紧急不重要的事情吧。

“防”重在预防，计划、风险，有计划并善于控制风险，将自己将来立于不紧急的状态中，这是防的精义吧。

对于用户手册，在多个项目的实施过程中，一直是存在比较多的争议。现在的用户手册描述内容比较详细，偏重于功能内部的操作指导，对于风格一致的软件系统，其指导的意见并不是特别的强，而且编写既废时又废力，特别是有多个层次对象使用的系统，需要从一大堆功能中找到自己使用的功能，真是不容易。

对于这种情况，一直想进行改进，但由于没有一个很好契机来进行改进，因此一拖再拖，此次中心开发了工作量软件，我认为正是一个改进的好机会，不过，为防止一次改进度过大，计划按两次来进行改进：

1、根据需求规格书的内容分析，对操作角色进行定义；

今天去开项目的专题会议，回来的路上，真有死过一回的感觉。与我上次开车转弯时一时没有回盘后差点撞上墙后的感觉差不了多少，全身虚脱，一身冷汗，即使是现在已过了三个小时，还是心有余悸。下面我再详细的来说说这件事吧。

负责的某市级项目已基本结束，系统全部上线稳定运行一个月，上周召集需求实施经理、开发经理、测试经理一起要求大家对项目各个方面的工作进行总结。

希望从以下几点进行总结：

1、需求经理对项目的建设范围管理情况，范围控制情况介绍；

2、总体计划以及各项子计划与实际进行的执行对比情况；

3、各领域中经验总结，有哪些方面取得了比较好的成绩，做了哪些改进，效果如何；可从进度控制、质量控制、风险控制、技术方面、团队建设、工作成果等方面进行分析；

4、各领域内中发现的问题，特别团队协作方面的问题；

5、改进的建议。

第一种情况：接到一个任务，不问缘由，就直接开始做；

第二种情况：接到一个任务，不问缘由，做直接开始安排怎么做（计划和方案）；

第三种情况：接到一个任务，了解目的和目标，再进行计划安排，再做；

第四种情况：接到一个任务，了解目的和目标，再进行计划安排，再做，做完了再回顾持续改进；