題目是說：他對該公司的C先生轉任SQA後的表現不甚滿意。
因為C先生反應：從 bugfree + Harvest 到 release 的過程中，因資訊的不完整造成他在 SQA 執行上的困擾，他認為應該可以更精確的定義這個過程中的程序及資料的 input 的話，就可以讓這個系統更好。
Y先生把C先生對此項工作的重點的Powerpoint檔寫給我看。
我看過之後，雖然不能將ppt也給大家看，不過，我將回應寫在這篇文章中，一方面說明我對SQA的看法，另一方面也說明我對C先生的看法。
以下就是我的回覆，大家看了之後，歡迎留言一起討論。
回應開始
我還沒和C先生聯絡過。不過，單從他提供的這些資訊，從需求面來看，並沒有辦法看出：
- 目前的系統或流程，有那些「資訊的不完整」？
- 這些「資訊的不完整」形成的原因？（是人員的問題？還是流程的問題？）
- 解決這些「資訊的不完整」的可能手段？
- 這些解決「資訊的不完整」手段的效果？
- 還有其他解決這些「資訊的不完整」的可能手段？
從下游觀點來看
我們可以從這個過程中看他的方案是否可行，有沒有不能執行的地方。關於這點，我們可以看他提出的方案是否具備：
- 希望解決的問題列表？
- 這些手法和以前的手法有那些差異？
- 需要執行什麼活動、以讓既有人員能學習新的方法？
從上述兩個觀點來看時，他提出的方案並不能充分滿足你的期望，我想這是你會不滿意他的表現的原因。
不過，就我對他的了解，我認為他將很難扮演好SQA的角色，其中的原因有主觀也有客觀。
主觀因素一
他的人格特質根本不適合當個SQA。因為他目前不具有以下的人格特質：為了修正一個問題、然後問了更多的問題、然後去改變一個可能和問題沒有直接相關的另一個問題。
但不巧，這正是SQA作事情的風格。
如果，不願意去面對真正的問題（即使問題點是自己），他就無法找出真正發生問題的部份，進而提出改善的手法，只能從一些無關緊要的地方去改善。
主觀因素二
再者，他也不是個為了品質願意破壞與其他人和協關係的人。我想，大多數的人都不是這類的人，每個人都想要作不得罪人、且受人歡迎的人，即使事情僵在那也不願意當提出改善方案的壞人。
但也不巧，這也是SQA得面對的困境之一。
如果，不願意去面對這個必然的困境，他就無法指出發生問題的人，進而提出改善的手法，只能，當個薌願的人，相信下次發生錯誤的人自己知道錯誤了並自行改善。
主觀因素三
他是那種能多一事不如少一事的個性也不適合。這可以從我們過去一同執行外包的案子中可以看出：他寧願每次用人工的方式，花幾個小時、甚至幾天去轉檔、和找出有問題的資料，也不想寫一個script在每次月結時使用。
即便是我在他第一次執行轉檔時就已經提醒了他，但他就是懶得去作。結果轉檔一連轉了五個月，直到結束，但一直到客戶簽收，他都還是用手動的。
但也不巧，SQA就是要從許許多多的小事著手改善，即使問題很小，他也要以一般的態度去處理。
如果，不願意注意許多的細節、一遇到有疑問的地方就立即求證，只怕將有更多的事情被蒙在鼓裏，等爆發之後將更難去處理。
主觀因素四
最後，他所受的訓練也不能滿足SQA所需要的條件。
就我認為，一個合格的SQA必須能滿足以下的幾個項目：
- 了解Domain Know How。因為專業的知識將隨著領域而有所不同。
- 懂得運用IT的技術。除了了解撰寫相關的知識外，還包括使用SQA領域內工具所需的知識。
- 了解SQA的工作原理。知道要如何提高品質的手法，也包括了對提昇品質的熱誠。
但我個人認為：他在第二、三項還不夠資格，需要更多的訓練。
客觀因素一
我認為他在扮演SQA和其他角色之間是有觀點、利益、資源上的衝突，除非他的「人我分際」很強，不然，恰如其分扮演好這些角色的難度相當高。
就像我們以前的SA、SD、Coding流程，假設都是同一個人完成時，結果就是像以前那樣慘不忍睹。因為，每個人都必須在執行這些活動的過程中，其成果必須同時滿足上游的需求、和下游實作的觀點。
若非如此，直接Coding的結果，雖然在短期達到了滿足效果的結果，但長期修修、補補、改改的結果，其實並沒有真的省下簡化這些步驟的時間和精力。
在制定品質系統的過程也是如此。如果不先從SQA的上游提出更清楚的需求、並以SQA的本職來完成初步的成果，接著用下游的觀點來檢視，結果就會像你現在看到的是一樣的。
沒有留言:
張貼留言