課程結束后，顧問公司的咨詢人員還特地給了我這個新上任的 SQA 一些建議：要熟讀 CMM “兵書”，在項目組成員對執行情況有異議時，才能夠據理力爭，以理服人;在實際的軟件項目開發過程中，要多與項目經理和項目組成員溝通，注意處理好人際關系問題，不要輕易上報，否則很容易引起抵觸情緒。
雖然很感激他的意見，不過我更相信我的能力。
實戰( 2004 年 5 月 W 日，多云)
新項目從立項開始已經三個禮拜過去了，還挺順利的。
首先，立項時給項目組成員作了一次培訓。讓全體的開發人員感受一下 “ 軟件質量保證 ” 的功效。 SQA 的一個職能就是對項目組成員進行必要的軟件的過程培訓，理論和實際相結合，而不只是用于紙上談兵。美中不足的是，培訓會議室的優雅環境給一些人提供了一個比較理想的休息場所。
在項目經理擬定計劃時，提供必要的規范給項目經理參考，參與項目估算，組織召開項目計劃評審會，邀請公司技術專家、用戶以及項目組小組成員一起討論項目計劃的可行性。
緊接著又是組織需求評審，并邀請用戶參與，對其用戶的意見進行跟蹤檢查是否納入需求規格說明書，同時與用戶簽字確認。
在此過程中，對項目的配置管理工作的作了一次比較細致的評審，發現了配置管理中存在的問題并提出了一些建議，使項目的配置管理工作更有效率。
我在項目組中的工作如此繁忙，大家也逐漸接受了。同時， 公司高層似乎也感到“ SQA 工作確實很有成效”。
挫折( 2004 年 8 月 V 日，多云)
經過三個月的摸爬滾打，項目開發任務總算進入尾聲，剩下的就是測試了。不過， SQA 工作卻不盡人意，好像沒什么突出的貢獻，倒是經常和項目經理和部門經理爭執不休，今天下午又和項目經理爭了一把“開發已經接近完成，關鍵模塊是不是需要評審一下”，沒想到居然給“羞辱”了——你又不懂，盡是找一些雞毛蒜皮小錯誤，不要老是制造麻煩。而且，居然還告到經理那“項目組有了 SQA ，可是設計和代碼的質量還是不高”。
想起 CMM 培訓結束時，我們搞了一個模擬小項目熱身，好像有模有樣的，當時老總和技術經理還特別予以召見， SEPG 組和項目經理幾個向“組織”表決心的情形還歷歷在目。然而，事情發展到今天這個樣子，我這個 SQA 當然是難辭其咎的。
經歷了這么一段時間，多少對顧問公司的一番臨別贈言有了更深的體會。
SQA 的主要任務是項目過程監控，是間諜，所以 SQA 的地位是很微妙，也很尷尬的：在開展項目以前，高層非常希望有一個耳目來監控項目的開發情況，項目組也希望有一個角色協助使開發和管理更加規范有序。當一個項目啟動后，又是另一種局面：不管你對項目開發管理有多大幫助，只要你打了項目組的“小報告”，受到項目組成員排擠是很正常的事。只要你存在，對項目組成員就是一種壓力。對于組織而言，報告的不符合項、建議多了，高層會嫌你啰嗦，還會質問 SQA 為什么沒有能力協調解決，那要 SQA 干嗎?漏報了(這是在所難免的)，又會說你不夠盡職盡責，總之兩頭不討好。當你看到一堆問題時只能干著急，卻沒有權力去糾正，所能做的只是：報告、建議、協調，雖然向管理層報告了，也不一定會馬上處理(高層管理者自然有他的道理，如果是老板的小舅子那就更沒轍了)，你會是什么感想?上級又有什么想法?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
