关于开展 QA 工作的建议
结合我有限的经历，和对 QA 工作的浅显认识，阐述一下我对该项工作开展一些思路和建议，我尚不能提出完整的解决方案，只能针对一些点抛砖引玉，以下看法源于我过去从事不同工作岗位获得的经验汇集而成，生命诚可贵，时间价更高，奈何诸多原因，对每一次经历的岗位可能理解都不深入，因此可能与真理相差十万八千里，如果有明显纰漏的地方，权当我抛出一个论点，供大家讨论。

准备开展 QA 活动：

无论从公司获取某些项目招标资质或是从自身持续发展，开展 QA 工作，以及进行如 CMMI 等认证的活动都是很有必要的，这一点需要得到全员的认同，特别是高层、产品经理、研发经理的认同及支持。基于我个人的经验总结，开展类似工作的阻力基本集中在高层的坚持不够、项目经理的重视程度不够、研发经理的配合度上，其他诸如测试部、售后客服、运维对此的配合程度相对高很多。究其原因在于除了各职能岗位对 QA 工作的认知不同外，更重要在于 QA 从业者本身的能力及素养。

一个好的 QA 能够影响团队，逐步让团队中的成员认同 QA 活动，而不是持续被团队排斥。BUT HOW TO DO？QA 应该是提供解决方案的参谋，而不是简单的第三方监督。我认为，大多数人应该都不喜欢被人监督着做事，也不会喜欢被人指使着做事，我了解到的 QA，很容易或者已经成为了 “事儿妈” 这种角色（这是不正常的现象，应该是我了解的对象还不多，或者没有接触到 QA 活动开展成功的团队）；

如果一开始定位 QA 活动是监督，检查的范畴，稍有不慎，势必导致上文所述的结局，无益于项目进行，可能仅仅有益于出几个漂亮的报告给老板或者投资人看！
QA 活动应该有独立的责任人去负责开展，如果兼职，一旦工作冲突，QA 活动势必会优先级降低，一次降低，次次降低，QA 活动也就流于形式，最后不了了之!
SO：一旦准备开展 QA 相关活动，我建议做以下几件事:
 高层对全员明确 QA 活动的开展决心 ---- 提高到战略层
 选择一个中长期进行的项目 ---- 短期项目还不够热身
 选择一个 “别人乐于” 与他沟通的人，且善于整理琐碎事务，确有坚持不懈的毅力的人负责 QA 活动的组织和推进 ----太强势了不太好，因为 QA 应该是参谋，而不是军长！

初期开展 QA 活动：
一旦确定要做一件事，剩下的就是怎么做了，如果还有 “关键干系人” 质疑开展的合理性，那么先达成一致在继续后面的工作。

一个已经有所沉淀的团队，要引入新的游戏规则，新的玩儿法，必然有人不适应甚至抵触。何况，经验表明，QA 活动的开展初期，还是在给团队增加工作量，更是不受大家待见！

据说在制造业界，ERP 风起云涌的时候，不但没有救活一些公司，甚至差点被玩儿死了，后来专家分析，这些极度不适应的公司之所以没有折腾好，是犯了拿来主义，硬着陆的错误。QA 活动开展个人认为与这相似，如果一开始就上来一套完整的制度方案，方案要么是拿来的，要么是屁股决定脑袋拍出来的，得不到团队的支持不说，很可能会严重干扰到项目原来的进度和节奏。
我建议的方案是从细枝末节做起，逐步渗透，高调的启动，低调的介入。

比如以下几个点（很多工作我们已经在开展了，后面要做的就是例行，习惯！）：
 每次关键会议是否有人记录，针对会议决议，在下一次节点会议进行 review 是否履行决议，未决决议是否有专人跟进（只是跟进，不是要他解决）
 需求变更、设计变更做一下根因分析，比如：这个字段为什么要设置为 String，为什么不限制长度，为什么要设为主 KEY，…为嘛要更改需求，客户的真实意图是这样吗，他到底是要一匹跑的更快的马，还是更快的到达目的地……；总之，如果行文阐述不清除你的变更理由，说明你还没有想清楚，没想清楚就会随意，随意做出的决策，只能呵呵了！
 关键变更是否知会到变更干系人了，为嘛不让他给你复述一遍呢？磨刀不误砍柴工，这个时间绝对不能省！
 关键文档按规范更新到指定目的地，行文的时候，相关附件有明确的指向，明确的版本号；文件命名是否明义，他人是否可以见名知意，你自己三个月后能看明白吗？
 你写的文档中形容词多吗，你怎么保证你的形容词，别人和你理解的是一样的？
 代码注释写了吗，日志打了吗？注释和日志不仅仅是注释记录这个类 这个方法，还有一个作用就是梳理自己的思路，也就是说，你想清楚了吗？
 最重要的，有人跟进以上活动是否开展吗？

当然还有很多其他的工作需要做，但是，多了就没有重点了，多了就 “不容易改变” 了，因此需要 QA 关键干系人共同决议几个短期目标，坚持做下去！另外就是 QA 岗位本身的责任人，得坚持，我始终相信一个道理：
你坚持做一件事，坚持到大家都感动的时候，神仙都会来帮你！

QA 活动不是一个人的事，不是 QA 岗位的私事，需要有一个专家团队协助支撑他的工作，在初期开展活动的时候，专家团队可以是砖家团队，亦即不一定是某一个细分领域的专家，但一定是能了解该领域基本术语及基础的人。基于当前实际，专家都在各个团队的核心岗位，忙于处理项目本身的各项事务，一开始就将他们纳入到 QA 支撑活动中意义不大；可以再砖家团队无法拿出预案或者预案未决时，让专家参与决策即可！

SO:开展 QA 活动初期，我的建议如下：
 QA 活动干系人确定 3 个月短期目标，各个部门节点的细分目标不超过 6 个
 指定专人负责跟进各个目标的达成情况并每周公布
 目标需要有导向性，必须与绩效挂钩，并取得高层的认可
 组成 “砖” 家团队，负责支持统计 QA 活动的开展情况及评审

后期 QA 活动开展：坚持，在坚持！

最后，提个问题，什么是 QA?,引用最近一部电影中的话，QA 无处不在！我的理解是，QA 是一类活动的总称，一切可以触发软件质量改进的活动，都是 QA 活动的范畴，身居 QA 岗位的人做的就是发掘那些可以触发软件质量改进的活动，并分析活动是否可持续开展，总结并推广活动！