QA过程审计职责

Scott

go6e6

过程改进和过程审计报告的QA工作,针对项目组存在不合理地方,分析项目组风险,提出可行性建议。

QA针对本周提出的项目风险,在接下来的一周内,进行过程跟踪监控，并提出风险解决的可行性办法，如有必要可以MAIL给高级管理层。

QA要随着过程规范和能力成熟度等级的提高，QA应逐步关注过程有效性。---〉高层次qa人员的要求


上一篇：我们常用的简易设计评审检查单
下一篇：说说项目开发团队中的SQA

Scott

fishred

我觉得QA首先要根据项目情况确定过程审计的checklist，只有这个确定了，才能进行审计，否则审计没有一个标准.

然后根据计划，实施审计，并与PM沟通解决方案；

每周对审计发现的问题进行分类并进行分析，并提出建议解决方案，并通报给高层；

冰封伯爵

我有一个疑问：谁来制定过程审计的checklist？谁来审核过程审计的checklist？谁来维护过程审计的checklist？谁来保证制定过程审计的checklist被有效执行？:lol

fishred

标准的做法：
EPG制定，QA来执行；

fishred

其实偶觉得checklist很重要

coral

但是checklist也很不好定义的．

1、组织级先有一个比较全面的总的checklist；
2、ＱＡ在实施过程检查和产品审计时，再根据项目当前的实际情况调整该checklist；
3、项目结项阶段或某个里程碑点，QA分析本项目的审计情况；然后根据分析结果将组织级定的checklist不合理之处向EPG报告。
4、组织评审是否采纳建议。

问：如何较好的定义好checklist呢？
    如果checklist多了，项目组未必都执行，如果checklist定义的不全的话，又担心组织定义的过程-活动项目组未都能执行到。

fishred

回到如果确定checklist的问题上了，我觉得适合是最重要的，具有可实施性是我们必须要考虑的，如果制定了却不去执行，长期下去就失去流程的威信！

xixiaojing666

原帖由 coral 于 2008-4-18 10:48 发表
但是checklist也很不好定义的．

1、组织级先有一个比较全面的总的checklist；
2、ＱＡ在实施过程检查和产品审计时，再根据项目当前的实际情况调整该checklist；
3、项目结项阶段或某个里程碑点，QA分析本项目的 ...

我们目前也是按照这个方法实施的．但是反馈情况通常都是在项目结项的时候，进行反馈的．

xixiaojing666

问：如何较好的定义好checklist呢？
    如果checklist多了，项目组未必都执行，如果checklist定义的不全的话，又担心组织定义的过程-活动项目组未都能执行到

我觉得这个要看你公司的实际情况，如果公司执行能力比较差，checklist多了一点好处也没有，反而成了累赘，还不如少而精，对于那些执行力度弱的过程，你们可以制定简单的checklist，只要满足你们组织的基本流程就可以了．

iamredeye

这个checklist只是用来提示QA，随着项目的进展自己应该关注那些方面，而不应该把它当作一个检查表来打勾或打叉，否则就成了走形式。所以checklist要全面，但同时每个checkpoint线条要比较粗（也只能很粗），还是要靠个人的判断（所以对QA的要求其实很高）并和通过PM沟通来驱动项目的执行。

iamredeye

原帖由 xixiaojing666 于 2008-5-4 15:45 发表


我们目前也是按照这个方法实施的．但是反馈情况通常都是在项目结项的时候，进行反馈的．

项目结束的时候太晚了。QA的结果是用来修正项目的问题，不是为了结束的时候给PM打分。

xixiaojing666

原帖由 iamredeye 于 2008-5-4 16:34 发表


项目结束的时候太晚了。QA的结果是用来修正项目的问题，不是为了结束的时候给PM打分。

我可能没有说清楚，我们目前的做法是这样的:
1、项目开展过程中QA进行随时报告和跟踪NC
2、在每周的周报中、里程碑点、项目结项时，QA分析本项目的审计情况，所以我们有QA周报、里程碑质量总结报告
3、项目开展过程中收集组织的checklist的不合理之处，项目结项的时候向EPG报告。（并将经验和教训都充入到组织资产库）
4、组织评审是否采纳建议，如果采纳，按照流程checklist进行版本升级。

dorainbow

QA提需求，EPG分析流程，设置监控点，制定checklist ;QA 执行checklist,收集基础数据（可能数据来源于PME，项目组员等），整理，分析；得出对过程的评价，提出需要解决的问题；反馈给EPG；EPG分析流程，对问题点提出解决方案；QA跟踪问题到最终关闭。这样形成一个闭环，共同保证流程的执行并促进过程改进。

iamredeye

原帖由 xixiaojing666 于 2008-5-5 13:40 发表

我可能没有说清楚，我们目前的做法是这样的:
1、项目开展过程中QA进行随时报告和跟踪NC
2、在每周的周报中、里程碑点、项目结项时，QA分析本项目的审计情况，所以我们有QA周报、里程碑质量总结报告
3、项目开展 ...

原则上肯定没什么问题。能不能请教一下你们的项目规模大概是多大，同时大概有多少个项目在进行呢？

lily_014

一开始看到这个主题不知道是说的组织级QA还是项目组QA过程审计职责。后来看内容是说的项目QA过程审计。
前面dorainbow同学和coral以及xixiaojing666同学也说过了：设置监控点—制定checklist —QA 根据checklist执行日常检查—收集基础数据，整理—分析—得出对过程的评价—提出需要解决的问题—反馈给EPG等等这一系列流程。都是一个PDCA的循序渐进的过程。
至于后面说的将问题反馈至EPG由EPG组来评审以及改进 那不是项目QA的职责了吧？
另外，无论是项目结束还是阶段总结反馈的问题拿到EPG组去改进，改进后的成果我认为如果再放到正在实施的项目（按照改进前的流程走）不太合适，因为如果改动的太频繁会导致项目组的抵触，EPG改进后的发布可以是周期性的。并且在执行流程中项目组如果认为不合适的，QA反馈到EPG，一致认为项目组的建议是可采取的那么项目可以按照这个好的建议走，但为没必要通过EPG改进后发布或者称是版本更新后重新发布的流程来过。最终目的一致，并且是一个持续改进的过程。。一点建议，欢迎斧正

[ 本帖最后由 lily_014 于 2008-5-9 15:05 编辑 ]