培训学习（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 工作更需要的是人际关系技能”。人际关系技能，那找个销售不就得了，还要我们这些技术人才干吗？