专注过程改进和产品质量

虽然不知道公司的意图，但是想提高产品质量是一定的，开始筹划产品管理小组，刚刚看了别人的质量管理的失败案例，不知道会不会一样的结果。心中忐忑不安，只希望在这个过程中充实一下，正所谓谋事在人，成事也在人啊。。

附录：
一个 SQA 的工作日记 
作者： QAMM （来源：希赛网原创 ）时间：2005年07月15日
宣战（ 2004 年 3 月 Z 日，晴）

    连续两天，看着公司高层领导们闭门会议，就知道有重大决定。果不其然，第三天，技术总监召集所有的项目经理和开发人员，宣布公司向 CMM 三级冲击，本人有幸被任命为 SQA （软件质量保证）经理和 SEPG （软件工程过程组）成员（成员仅有 3 人，真有象当选为“政治局常委”）。

    感觉真是不错，走出每天呆着的写字楼，看看大街上来来往往的人，爽啊！

    下班回家，郑重向“老婆”宣布，决定下馆子小辍一顿，一时间，踌躇满志，感觉飘然，好像公司的软件产品质量将获得重大提升，震撼业界。回想多年走过的历程，两年的程序员，三年的项目经理，终于熬出头了，上司发现了我这块“可造之材”，并委以重任。经过这么多年的风风雨雨磨练，终于有机会向上司展示才能，我当然要“涌泉相报”。

赋职（ 2004 年 3 月 Y 日，多云）

    一早 6:10 就醒来，再也睡不着了，算了，还是起床吧。兴奋了一晚上，精神居然还挺好。

    8:00 就到公司了，时间太早，一个同事都没来，真想找个人侃侃自己的志向，毕竟“老婆”不是这一行的，有些东西还不能完全理解。上网溜达了一会儿， QQ 也没有好友在线，毕竟还没上班呢，只能看看 CMM 的最新动态和国内软件企业的新闻。没多久，同事们也陆续到了，上班时间到了。

    好不容易等到公司高层经理们开完了碰头会，我想，迟早我也会有机会挤进去参与的。 10:30 ，研发部经理向我们传达，经过领导们的一致同意，决定选择 XX 公司作为我们的 CMM 咨询顾问，鼓吹一通 XX 公司的业绩，（这不是有点象给他们做广告？）然后又宣布了参与培训的人员，都是一些公司的“栋梁之材”和“老马”。榜上无名的以极其羡慕的眼神看着这些幸运儿，榜上有名的“唯技术论”者则以不屑之表情，并不时发出 “项目太紧，没时间”的抗议。经理则非常明确，“高层决定，没商量，要么找老总协商”，试问有哪位有这等胆量。唉，朽木不可雕也，这些人也只能一辈子做技术了。

    完事后，经理又把我单独叫到他的办公室，问我打算如何组建 SQA ，说公司以后过 CMM 主要就靠我努力了，心头一阵激动。不过，经理接下来的话让我凉了半截，建议我 SQA 组下暂时只设一人，考虑一下小崔。不是吧？我的心有点凉了，公司里水平最差最笨的人就给我？这个人，不是仗着与老总有点不太近的远亲，估计早就给开了。我刚准备抗议，经理立马安慰，“所以才要你领导，有你在， CMM 应该不成问题，我们才放心。”

培训学习（ 2004 年 4 月 X 日，晴）

    经过将近一个月的培训，今天总算毕业了，感觉就像脱胎换骨，到底 CMM 是面向软件行业，就是比 ISO 更专业。因为是由鬼佬上课，好像自己的英文水平也提高了不少，而且还挺正规的，发了“毕业证”。真是获益良多啊！给我印象最深的还是那个北大的计算机硕士翻译，水平挺高，人也长得漂亮。

    课程结束后，顾问公司的咨询人员还特地给了我这个新上任的 SQA 一些建议：要熟读 CMM “兵书”，在项目组成员对执行情况有异议时，才能够据理力争，以理服人；在实际的软件项目开发过程中，要多与项目经理和项目组成员沟通，注意处理好人际关系问题，不要轻易上报，否则很容易引起抵触情绪。

    虽然很感激他的意见，不过我更相信我的能力。

实战（ 2004 年 5 月 W 日，多云）

    新项目从立项开始已经三个礼拜过去了，还挺顺利的。

    首先，立项时给项目组成员作了一次培训。让全体的开发人员感受一下 “ 软件质量保证 ” 的功效。 SQA 的一个职能就是对项目组成员进行必要的软件的过程培训，理论和实际相结合，而不只是用于纸上谈兵。美中不足的是，培训会议室的优雅环境给一些人提供了一个比较理想的休息场所。

    在项目经理拟定计划时，提供必要的规范给项目经理参考，参与项目估算，组织召开项目计划评审会，邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性。

    紧接着又是组织需求评审，并邀请用户参与，对其用户的意见进行跟踪检查是否纳入需求规格说明书，同时与用户签字确认。

    在此过程中，对项目的配置管理工作的作了一次比较细致的评审，发现了配置管理中存在的问题并提出了一些建议，使项目的配置管理工作更有效率。

    我在项目组中的工作如此繁忙，大家也逐渐接受了。同时， 公司高层似乎也感到“ SQA 工作确实很有成效”。

挫折（ 2004 年 8 月 V 日，多云）

    经过三个月的摸爬滚打，项目开发任务总算进入尾声，剩下的就是测试了。不过， SQA 工作却不尽人意，好像没什么突出的贡献，倒是经常和项目经理和部门经理争执不休，今天下午又和项目经理争了一把“开发已经接近完成，关键模块是不是需要评审一下”，没想到居然给“羞辱”了——你又不懂，尽是找一些鸡毛蒜皮小错误，不要老是制造麻烦。而且，居然还告到经理那“项目组有了 SQA ，可是设计和代码的质量还是不高”。

    想起 CMM 培训结束时，我们搞了一个模拟小项目热身，好像有模有样的，当时老总和技术经理还特别予以召见， SEPG 组和项目经理几个向“组织”表决心的情形还历历在目。然而，事情发展到今天这个样子，我这个 SQA 当然是难辞其咎的。

    经历了这么一段时间，多少对顾问公司的一番临别赠言有了更深的体会。

    SQA 的主要任务是项目过程监控，是间谍，所以 SQA 的地位是很微妙，也很尴尬的：在开展项目以前，高层非常希望有一个耳目来监控项目的开发情况，项目组也希望有一个角色协助使开发和管理更加规范有序。当一个项目启动后，又是另一种局面：不管你对项目开发管理有多大帮助，只要你打了项目组的“小报告”，受到项目组成员排挤是很正常的事。只要你存在，对项目组成员就是一种压力。对于组织而言，报告的不符合项、建议多了，高层会嫌你啰嗦，还会质问 SQA 为什么没有能力协调解决，那要 SQA 干吗？漏报了（这是在所难免的），又会说你不够尽职尽责，总之两头不讨好。当你看到一堆问题时只能干着急，却没有权力去纠正，所能做的只是：报告、建议、协调，虽然向管理层报告了，也不一定会马上处理（高层管理者自然有他的道理，如果是老板的小舅子那就更没辙了），你会是什么感想？上级又有什么想法？

    下班前，还特地找了部门经理诉苦， 公司既然制订了制度，实际上就相当于公司的法律，如果有法不依，执法不严，违法不究，久而久之这套制度就只是一纸空文了，以后还会有用处么？

    吃饭时都感到郁闷，喝了一瓶啤酒，郁闷的是经理所说的“ SQA 工作更需要的是人际关系技能”。人际关系技能，那找个销售不就得了，还要我们这些技术人才干吗？

无奈（ 2004 年 9 月 U 日，阴）

    每天准点上班，准点下班，默默地无休止地折腾那该死的软件。今天也不例外。

    从上礼拜二开始，经理就让我主要担任这个项目软件的测试，美其名曰“软件质量保证”，就要保证软件的质量，测试当然是保证质量的方式之一。我没有争辩，心知争辩也是徒然，而且高层不希望我成天找项目经理的茬，影响进度。资本运作当然不是我所能左右的！

    每天我机械地运行程序，检查结果，检查数据库，截图，填写缺陷报告，跟踪缺陷修复。虽然做得规范，无可挑剔，我成了孤独的斗士。

    实际上，测试是事后检验产品的质量，保证产品符合客户的需求；而 SQA 的职责是审计过程的质量，保证 CMM 中各个 KPA 过程被正确执行。因为 SQA 人员同样要检查测试的工作是否也遵循了开发过程要求，也是要被审计的，由 SQA 同时担任测试，那么谁来保证测试工作的过程质量呢？这些道理经理其实都明白，只不过项目经理完成的工作其价值是可见的，谁又能说出 SQA 产出了什么呢？

    中午休息时上了一个 CMM 的论坛蹓达，其中有一个帖子比喻得就极其形象：项目组就像是一家餐馆，项目经理是当班经理，他决定做什么，有多少人多少资源来做多大，有多大的风险；系统架构设计师就是主厨，他设计具体做法；程序员就是厨师，配置管理员、系统集成人员、数据库管理员等角色是厨房里面的服务人员。而 SQA 和测试工程师更像是第三方的检查人员， SQA 检查的是制作流程是否正确，材料是否使用正确，卫生是否做好了，他检查所有人的工作，包括项目经理。 SQA 虽然没有决定权，但是他有建议权，他向餐馆老板负责。测试工程师则更像是试菜的，看看炒出来的菜有没有合不合口味，有没有按照客人的意思多放点辣椒，如果口味不对，他们要告诉厨房就可以了。

    唉，算了， 就当混口饭吃 ，知足吧。

出局（ 2004 年 10 月 T 日，雨）

    又是一个阴雨天。

    上班了，像往常一样，上网看看新闻。

    项目已经做完了，不过心里极其不爽。 我，虽然挂名 SQA 经理，实际成了一个打杂的，真正 SQA 工作早就抛在一边。比如协助完成测试、配置管理，研究实用的测试工具，改进一下开发环境和工作过程，甚至帮助项目经理汇总文档、总结实施经验、协助客户培训 ……

    10:00 ，经理找我，觉得我更适合担任测试组长一职，但待遇要低一级，问我是否接受。这是公司对待“鸡肋”的一贯策略，我明白，上级对我的 SQA 工作予以否定。这一天终于来了，当时的我居然平静的谢绝了经理的好意，感谢公司在这段时间给我提供了这么多的锻炼机会。然后就说，那我收拾东西去了，经理还愣在那。

    没什么可埋怨的，可能是上级对 SQA 的期望太高。实际上，根据现代软件工程项目的调查研究，项目管理是项目失败的主要原因。问题是，这个事实说明了“要保证项目不失败，我们应当更加关注管理”，但是并没有推论“良好的管理一定可以保证项目的成功”。 质量保证的最终目的是希望能保证质量，但质量是过程、人、技术三者缺一不可。除了过程外，还与人员、技术有关，而人员素质和技术水平的提高并不是依赖 SQA 就能保证的，所以 SQA 虽名为质量保证，实际上也就成了项目失败的直接责任人。

    难怪现在网上有一种说法“在中国做不了编程的人去做测试，做不了测试的人去做 SQA 。”实际上，这从就反映了 SQA 的作用并没有得到大家的认同，在大家的眼里， SQA 做的都是文档功夫。

    呜呼唉哉！

    感觉真是一种解脱。吃饭时喝了一瓶啤酒，深圳的秋老虎仍然厉害，体验着啤酒冰爽的感觉，幸福啊 ∶ )

    下周又要开始投简历了，找工作是一个漫长的过程。希望下次我能够找个好婆家，理解这些。还是要思量一下是不是继续干 SQA 。

    下过雨后，凌晨两点的城市空气清新，望着远处霓虹闪烁，好美。

后记：

    据了解，我的前任婆家在我离开公司的五个月之后通过了 CMM3 的正式评估。小崔，我的继任者，编程虽然极差，文档却是可以按要求完成的，不过，听说所有的项目文档都是由他执笔的。唉，怎么还是变得跟 ISO 一样了呢？只是名称改了一下。到了中国，任何的标准都有点变味了。