昨天是从整体上说了一下处理方法，今天开始，我会根据我的工作日志慢慢的从各个细节来跟大家分享一下我的做法，大家也可以讨论一下：

关于提报NC的问题

刚开始做质量保证的时候，我一发现项目组有不合格就提报NC，但是发现效果不太好。反思后我发现：以前提报的很多NC都不是大问题，时间长了，PM对NC就不会太在意了。

找到问题后我改变策略，发现不合格后自己先思考为什么会这样。如果是我这边的培训不够导致的，我会加强培训，给大家讲解清楚；如果是PM忘了或者疏忽了，我会及时提醒PM并协助PM一起完成；如果的确是PM拒绝执行，我会跟PM沟通，找到他不愿意执行的原因，针对不同的原因来进行不同的处理；遇到非常顽固的PM，则需要将NC写清楚，跟PM的领导沟通，从另一个角度去给PM压力。

整体的思路就是通过沟通来解决问题，让PM知道QA是为他服务的，大家的目的都是为了项目正常运行。不是什么问题都需要提报NC，NC只要提了就是真正需要大家重视和解决的问题，而且，有时是需要惊动领导的。这样，PM就会重视NC了。

经过一段时间的实践，我发现跟我打交道的PM都会很配合，甚至有的PM会主动提醒我需要什么样的培训，以及从我这里了解项目的风险并一起商量解决办法。

这次就写NC这一点，下次再写点别的。

SQA的能力，做事方法，对CMMI的真正掌握，这个其实很有关系。很多QA就是脱离项目，为了执行流程而执行流程，项目的情况千差万别，要去套一个流程提出的意见肯定不会被接受。
我们公司，度量数据很多，但是真正分析过吗，没有，脱离项目的分析肯定也是表面的。
如果QA深入项目，能真正发现一些实际的问题，我想项目经理一般都会接受，除非真是人品性格有关系。

引用:

原帖由 luckyera 于 2008-3-4 15:23 发表
SQA的能力，做事方法，对CMMI的真正掌握，这个其实很有关系。很多QA就是脱离项目，为了执行流程而执行流程，项目的情况千差万别，要去套一个流程提出的意见肯定不会被接受。
我们公司，度量数据很多，但是真正分析过 ...

很同意楼上的说法。QA要深入到项目中去，通过度量的数据找到项目真正的问题，这样才能协助PM一起解决问题。能做到这一点的话，PM也会很乐意跟QA合作的。

引用:

原帖由 henrybenben 于 2008-3-4 15:42 发表


很同意楼上的说法。QA要深入到项目中去，通过度量的数据找到项目真正的问题，这样才能协助PM一起解决问题。能做到这一点的话，PM也会很乐意跟QA合作的。

谢谢鼓励。第一篇加钱的帖子。

引用:

原帖由 luckyera 于 2008-3-6 11:16 发表


谢谢鼓励。第一篇加钱的帖子。

这个板块鼓励原创和讨论。只要是大家原创的东东，来源于工作，对其他人有帮助，我都会给予奖励的。

大家共同营造原创和互助的环境。

QA除了监督以外更重要的是要做好教练的职责，给项目组带来好处或者想办法借用其他项目的好的经验帮助项目经理解决困难，或者是让项目经理和项目成员理解按照规定执行的好处，后面的事情也就自然而然了

引用:

原帖由 jhwu 于 2008-3-6 15:29 发表
QA除了监督以外更重要的是要做好教练的职责，给项目组带来好处或者想办法借用其他项目的好的经验帮助项目经理解决困难，或者是让项目经理和项目成员理解按照规定执行的好处，后面的事情也就自然而然了

楼上的其实说到了两个方面：
1. 积极沟通
2. 组织过程资产积累

如果能详细说明一下自己是如何在工作中实施的就更好了，也会成为一篇加分的帖子。期待中...

[ 本帖最后由 henrybenben 于 2008-3-6 15:43 编辑 ]

老实说我自己没有做过QA但是做过EPG Leader，在推行CMM的过程中也总是遇到PM不配合的情况，总的归纳起来有以下几点：
1. 流程不适合或者太复杂，没有了解到CMM的精髓。比如我们在做配置管理的时候，划分了开发库、基线库和产品库，并且是物理上隔离的三个库，在实施的时候推行困难很大，项目经理抵触也很大，后来修改为在配置项上打tag标识，推行难度就下降了很多
2. 项目经理不清楚项目实施的最佳实践，标准不统一。如功能点估算，后来我们做了一个专门培训，找了一个好的项目来让大家参与估算
3. 项目经理间沟通不畅通，对于其他项目已经解决过的问题、开发过的构件等，其他项目经理不清楚而造成重复开发，一般QA会和多个项目打交道，并且了解组织财富库，从这个角度帮助项目经理往往会达到事半功倍打效果
4.组织财富的建立和补充 需要QA经常发掘各项目的优点，充实到公司财富库，多给项目经理表扬也会推进实施，人总是喜欢听好话的不是
5. QA的做事方法和自身修养  需要对CMM有很深的理解，抓住实质。要理解CMM各KPA不是孤立隔绝的，而是相互联系和渗透的，如评审、配置管理、培训基本上和所有KPA都有关系。
6. QA、EPG自己的工作也需要按照体系要求来做，可以作为一个项目的模板
7.关于数据度量，个人意见是是度量的数据必须要确实使用，度量标准要事先定义和培训，让每个项目经理有一致的理解，个人认为最开始从计划的准确性来做也就可以了，不需要太多。
8.做CMM的任何工作需要能够验证，以事实说话对项目经理对促进会更大

最近一直有点私人的事情在处理，所以没有跟贴。

今天谈一下沟通的问题：

沟通是解决问题最根本的手段。

沟通的方式包括聆听和表达。

QA更多的时候应该是聆听。QA要知道PM拒绝合作的真正原因是什么，要了解问题的真正原因：特殊情况？PM不熟悉过程？PM觉得麻烦？PM心情不好？等等。而且，不仅要从PM这里了解情况，还需要从其他的厉害相关人那里了解情况。了解的越多，越容易做出正确的判断。其实这也是IDEAL模型中的D（诊断），就像医生一样，对病人要先从各方面了解情况，只有了解清楚了，才能做出正确的诊断。

聆听完了以后，则需要我们从不同的角度去分析问题，特别是要站在PM的角度考虑问题。因为我们让你长期站在QA的角度考虑问题，会忽略了对方的感受的情景，这样会对我们的判断造成影响。通过各种渠道汇集来的信息，我们进行整合分析，找到问题的根结所在。也就是医生通过完整的了解病人的情况，然后再找到病因。

找到原因后则需要我们用不同的方法让PM知道，并且给出你的解决方法。这一点是非常重要的。让PM知道问题的原因是需要技巧的，这也不是本帖的主题，这里就不展开讲了，主要的一点就是因人而异：胡罗卜+大棒是个屡试不爽的法则。还有一点就是我们找到原因后还需要给出一到两个解决方案，这样PM才会认为你是真的在帮他解决问题。如果我们只提出问题，而不给出解决方法，那么人家就会认为我们是在找茬。如果这个时候PM有更好的解决方法那是更好了，我们也可以跟PM多多学习。三人行必有我师嘛。

我目前基本上都是这么去做QA工作的，应该来说还没有遇到特别不配合的PM。也希望大家都来分享一下这类情况的处理方法。

拜读了以上大家的帖子，感触良多。大家都提到了“度量”，的确在日常工作中也涉及到了度量分析，所得出的数据大多是很不准确，有些甚至是错误的。分析期原因，在初期所提交、收集的数据多半是“动过手脚”的（由于跟绩效挂钩），这样在项目讨论的会议上，SQA给出的意见和评估结论一般都没什么实际意义。
接下来再说说沟通，其实跟PM私下说什么，他都可以理解甚至是赞同，但在会上他往往是以开发人员的想法为主，这样就使得QA跟开发之间有了很大分歧，这又合上面提到的“数据手脚问题”关联，所以整体感觉SQA的位置有些尴尬。