软件项目红黄牌制度精编版文档格式.docx

软件项目红黄牌制度精编版文档格式.docx

《软件项目红黄牌制度精编版文档格式.docx》由会员分享，可在线阅读，更多相关《软件项目红黄牌制度精编版文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

质量保证

组织沟通

进展

进度偏差

成本偏差

产出质量

人员流失

客户满意度

项目1

■

●

项目2

项目3

项目4

项目5

过程指标反映项目是否按照公司的管理规范进行管理，通过质量经理的过程审计获得数据信息。

包括配置管理、需求管理、计划跟踪、风险管理、缺陷管理、组织沟通、质量控制7个过程域。

进展指标反映项目运行的状况，包括进度偏差、成本偏差、产出物质量、员工流失率、客户满意度5项数据。

7个过程域指标决定项目整体过程的红黄牌状态，5个进展指标决定总体进展红黄牌状态，灰色灯表示对此项目不使用此考察项。

过程/进展

标准

绿牌

每个过程域无黄灯或红灯

黄牌

各过程域中仅有一个或两个黄灯

红牌

各过程域中有三个以上黄灯或一个以上红灯

各个过程域的红黄灯标准：

对于项目过程指标，每个过程域分别设立多个检查项，各个检查项的状态决定该过程域的红黄灯状态。

检查项分别标示为关键检查项和一般检查项。

一般情况下，若有关键检查项未达到标准，该过程域即标示为红灯，一般检查项1-4项未达到，标示为黄灯，超过4项未达到，标示为红灯。

过程域

绿灯

所有检查项均达到标准；

黄灯

所有关键检查项均达到标准；

一般检查项未达到数<

=4

红灯

存在关键检查项未达到标准；

一般检查项未达到数大于4

进展指标的计算公式

进度偏差％（SVP）＝（BCWP－BCWS）/BCWS即（挣值-计划值）/计划值

成本偏差％（CVP）＝（BCWP－ACWP）/BCWP即（挣值-实际值）/挣值

人员流失率=本季度流失人数/当月项目人数

四数据来源

四.一过程数据

来自质量经理的审计报告。

质量经理对项目的检查应依据检查标准对每个检查项给出说明

四.二运行数据

其中进度和成本偏差来自项目计划、项目预算、项目财务数据以及项目周报中的进度状态数据。

人员流失率来自项目报工数据。

产出物质量来自质量经理检查报告。

五产出报告

五.一项目检查报告

针对单个项目，质量经理编写，经过项目经理确认后，发送项目领导小组及项目管理部。

《红黄牌制度检查报告（项目名称）》

《红黄牌制度检查报告（项目名称）—检查表》

五.二总结报告

按季度产出，每季度第一个月的20日前完成。

针对一次检查的所有项目，项目管理部负责编写，本部领导确认，发送所有项目经理、项目总监、客户经理和本部领导。

《税务本部项目红黄牌检查总结报告》

六考核

项目的红黄牌检查结果与项目经理的考核挂钩。

六.一客户满意度

客户满意度成绩作为项目经理考核系数的组成部分：

客户满意度成绩85分（含）以上，客户满意度系数为1

客户满意度成绩85分以下，客户满意度系数＝客户满意度成绩/100

六.二项目过程状态

项目过程状态的红黄牌结果作为项目经理考核系数的组成部分：

过程状态为红牌：

系数为

过程状态为黄牌：

两个过程域为黄灯，系数为；

一个过程域为黄灯，系数为1

过程状态为绿牌：

若为全面检查的项目，系数为；

若仅考察部分检查项的项目，系数为

七附表1：

过程检查项定义

说明：

附表1适用于开发项目，对于没有开发工作的上线支持、运行维护项目见附表3

七.一配置管理

检查项

检查项分类

是否制定了配置管理计划，配置管理职责是否明确（SCM,SCCB）

一般

配置管理人员是否相应的技能，项目组成员是否了解如何使用配置管理工具

是否建立并维护了配置库

关键

配置库是否定期备份

配置库目录结构是否清晰，权限设置是否正确

配置库中的配置项是否齐全，当前版本是否正确

是否根据配置管理计划建立了相应的基线

已纳入基线的配置项的变更是否符合变更流程

项目组是否有版本管理与发布规程，发布给客户的版本是否经项目经理批准,按流程进行；

版本发布有说明,描述版本的变化

版本中代码及其他发布项是否来自配置库或受控环境，可以获取历史任何一个发布的版本的所有配置项,包括但不限于源码,数据库脚本,配置,运行环境

七.二需求管理

是否建立并维护了需求跟踪表,对需求状态进行了跟踪

是否定义了需求变更流程，并与用户达成一致；

需求变更是否按定义的需求变更流程进行

是否应用需求变更跟踪表跟踪需求变更

对需求变更是否进行了评估并识别了变更影响范围

需求变更是否得到了SCCB的批准及用户的确认

需求变更相关记录是否纳入配置管理

需求变更是否通知到所有受影响的组与个人

七.三进度跟踪

是否制定了项目的高层进度计划，明确里程碑的时间点和产出物，产出物的评审计划

是否制定了WBS计划（使用进度跟踪表或MSProject）

WBS计划要能够全面反映项目各项任务实际进展情况

WBS计划要能够全面反映项目每个成员的任务分配情况

格式整齐，清晰，具有良好可读性。

每个里程碑点对项目的高层计划进行了更新

每周对项目WBS计划进行了更新，WBS计划与项目实际状态一致

WBS计划对近期项目任务（一个月内）的分解不能超过每人周

七.四风险管理

是否在项目启动时进行了风险评估，对风险是否进行了跟踪（项目周报、项目计划与跟踪表）

是否对项目问题进行了跟踪管理（使用项目计划与跟踪表），重大问题是否按照要求进行了及时上报

是否识别了风险发生的可能性/危害程度,并对风险进行了评级

是否对风险有应急计划,以应对风险发生后产生的问题

是否针对级别高的风险制定了行动计划,降低风险的可能性与危害程度

七.五缺陷管理

项目组是否定义了缺陷管理流程

项目组是否搭建了缺陷管理系统

对评审与测试发现的缺陷是否按流程安排修改并跟踪验证

所有的缺陷是否都得到了记录

缺陷是否明确了严重程度与优先级

（使用项目计划与跟踪表）按月对项目的缺陷进行汇总统计

七.六组织与沟通

项目的组织职责明确，无关键人员离职

项目经理经过述职和正式任命：

项目有人员投入后一个月内，完成述职和任命，一个月之后两个月内完成的为黄灯，超过两个月的为红灯

有明确的内部、外部沟通机制，有沟通计划，保留沟通记录

制定并维护项目的资源计划，

制定并跟踪维护项目的培训计划

项目周报按时提交,内容完整准确；

每季度迟交3次以上为红灯

识别项目关键干系人，记录关键干系人对项目的期望

每月至少与两位员工进行面对面的正式沟通，保留沟通记录

项目例会是否按时召开

与客户的会议是否按时召开

七.七质量保证

是否有制度化项目管理规范，有开发规范，项目产出物有确定的模版

需求经过评审

设计经过评审

代码检查，测试案例经过评审

七.八产出物质量

文档化的完整的系统需求

需求通过用户确认

需求文档符合项目规范模板要求

文档化的完整的系统设计

设计文档符合项目规范模板要求

测试案例文档化

代码规范性

发布版本出现事故，或出现客户投诉

八附表2：

进展指标标准

运维项目不考察进度偏差，研发项目不考察客户满意度

进展指标

[-10%,+]

[-30%，-10%）

（-，-30%）

产出物质量

参见过程检查定义—产出物质量

人员流失率

[0，10%]

（10%，20%]

（20%，+）

[85，100]

（若未进行调查，无投诉为绿灯）

[70，85）

（若未进行调查，有一次客户投诉，即为黄灯）

（-，70）

（若未进行调查，客户投诉超过2次，即为红灯）

九附表3：

运维项目检查项定义

适用于无开发工作的项目，如上线支持、运行维护项目。

九.一配置管理

说明

若项目组负责用户生产环境的版本升级，配置管理各项内容需要满足，否则可使用文件服务器管理产出文档，产出物齐全即为满足要求

项目组是否有版本升级规程，升级是否按流程进行；

九.二问题管理

项目组是否按流程接收和处理问题

是否有问题记录和问题统计

程序问题是否单独进行了跟踪

重大问题是否进行了上报？

九.三组织与沟通

是否按月或周向客户汇报情况

九.四质量保证

是否有制度化项目管理规范，项目各项报告有确定的模版

项目产出物符合模版要求