qa
，乙個從
cmm開始站到主舞台的乙個角色，在很多公司中，也是被很多公司，高層所接受；而被專案團隊，員工所不認可的乙個角色。到底他是什麼樣的乙個角色？
這裡用乙個大家所能接觸到的事例，來看一下，到底這個角色都做了些什麼？或者說應該做什麼？
在大部分人的眼裡，
qa彷彿等同於大部分司機所厭惡的交警，每天在不斷的檢查各部門、專案的工作，就如同交警每天在保證著交通法規的正常執行。我們所熟知的交通法規就如同現有公司所規定的各種流程和制度；而司機就如同每天在不斷執行流程，制度的各位員工，專案團隊。
無論從實際的工作，還是實際的生活中，
qa與專案組，員工；交警與司機彷彿永遠存在著不可調和的矛盾，原因很簡單，彷彿這兩個角色永遠是檢查者與被檢查者的角色，從而慢慢的被檢查者就開始排斥檢查者，從而產生矛盾，而現實中不會因為產生矛盾而將這種狀態發生改變，從而被檢查者越來越想法設法的躲避檢查者，惡性迴圈彷彿永無休止。
我們回過頭來看為什麼會產生這種原因？彷彿
qa與專案團隊永遠是處於乙個對立的狀態，但現實中的司機難道都是厭惡交警嗎？彷彿不是，彷彿永遠是那些想違背交通法規的司機才會對交警有所排斥和厭惡，當出現交通堵塞，交通事故時，我相信大部分司機第一時間總會想到交通警察吧？我們為什麼要制定交通法規？我們且不說立法權在誰哪兒？我們就是讓司機來制定交通法規，難道司機們會因為這些活動會約束自己的行為而不制定交通法規嗎？我們平時的交通堵塞，交通事故大部分不都是因為小部分司機的違紀而造成的嗎？這時候大家是否會想到如果大家都按照交通規則來行駛，是否這些堵塞和事故會減少到最低呢？這時候大家是否會想到如果有乙個交警在這兒會多好？
以上是經常在許多文章、書籍中所將
qa作為的乙個比喻。通過以上例子我們可以看到乙個大家所都明白的事實，沒有規矩不成方圓，在
30年前，我相信沒有交通法規或者少量的交通法規，當時的交通事故肯定遠遠小於現在，難道是因為制定了如此多的交通事故反而提高了事故的比率了嗎？其實並不是，如果沒有這些交通法規，我相信整個城市交通會變得一團糟糕，原因是車輛與司機的規模提公升了，以前可以用道德，個人約束的事情現在因為數量集的突變只能通過制度來進行約束，而每個人的素質又不在同一水平線上，從而產生了檢查者與被檢查者的角色。
以上這個比喻也彷彿有些問題，出現交通堵塞，交通事故，找到交警可以直接解決問題，而現實的專案，工作**現問題找到
qa彷彿也沒有什麼作用。沒錯，這就是最根本的問題，專案團隊，員工不認可
qa的最根本原因，不是因為檢查者與被檢查者的地位問題，而是因為
qa的檢查彷彿沒有給予他們更多的支援和幫助，規定的許多活動與流程，團隊、員工付出了昂貴的管理成本，而並未看到實際的效果，這才是導致專案團隊與
qa形成對立面的最根本原因。
ok，我們回過頭來看一下，大家現在都明白乙個事實，軟體專案的成功與失敗的最主要原因是在管理和流程上，就如同那些交通事故的發生，最根本並不是因為司機的技術水平不夠而引起的，而這些管理的活動的執行不是馬上就見效的，比如在做需求分析過程中，流程中規定的需求確認，需求跟蹤這些活動，在當前階段只能看到我們增加了工作量，看不出任何的效果，沒有任何感覺，就如同我們所熟知的扁鵲論醫術的典故，扁鵲之所以成為名醫，是因為他能下猛藥治病，就如同我們的交警一樣，他來了就直接能夠解決問題，堵塞的交通慢慢被疏通，爭論不清的事故會變的責任清晰，但像需求確認，需求跟蹤這些活動就真的沒有任何意義了嗎？這些成本真的就沒必要投入了嗎？
ok，我們看到，乙個合格的
qa最根本的目的不是乙個檢查者的關係，其實很簡單，目的是為了保證流程的正常實施，只是因為我們是由人來執行各種流程，必然會因為各種原因會出現偏差，從而中間就不得以加入了
qa這樣乙個角色來保證流程的實施。而產生所謂的對立面，是因為許多人認識不到這些活動的價值。就我們現在的工作來說，是因為這些活動真的沒有價值還是我們沒有好好的去分析和利用這些活動和資料？
在與朋友交流的過程中，曾經有人提出過這樣乙個觀點，如果專案組都按照流程來走的話，是否
qa這個角色還有存在的價值？這是乙個很理想的假設，即使這個假設成立，當然我也很希望這個假設能夠成立，是否
qa這個角色就可以消失了？我覺得並不是，從上面的描述看來，彷彿
qa的目的就是為了保證制度和流程的實施，還是以交通這個例子，當大家都遵守交通法規時，我們有時還會發現某些路段會堵塞，作為交警來說他會收集這些資訊，反映給相關部門，由相關部門來考慮通過何種手段來改變這種堵塞的狀態，或者會通過調流來緩解這個路段的交通壓力，或者加上乙個訊號燈等等措施。
ok，這就是乙個為過程改進提供一線資料的活動。這裡明確一點，
qa沒有所謂制定流程與規範的權力，這個權力由更高階的管理層或者所謂的
epg來完成，而
qa只是保證這些流程的實施並提供相關的改進資料。之所以給很多人以誤解，認為制度和流程是由
qa來制定的，原因很簡單，是因為在很多人眼裡面，這些資料和流程只有
qa在使用。
以上說了很多，其實還有乙個很根本的原因，所謂的資源問題，在軟體開發過程中重量級的管理體系如
cmmi
，rup
，現在的敏捷開發等輕量級開發過程也已非常流行，所謂的區別就是因為規模和資源上。很多管理者在專案過程中也認可這些活動的必要性，但總會以沒有資源，或者難以實施來剪裁掉許多必須的活動。這時
qa的檢查發現這些活動沒有執行，又造成了所謂的對立面，即使專案組花費時間去解決，但最佳的活動時間已經錯過，到頭來的結果是什麼？是無休止的修改，無休止的開發這樣乙個惡性的迴圈。對任何問題沒有任何的可控性，只能祈禱這些問題在短時間內不被暴露，如果被暴露就寄希望於扁鵲這樣的神醫。我們都做過很多專案，有成功的專案，有失敗的專案，難道那些成功的專案資源都是足夠嗎？好像並不是吧，專案中專案經理最主要的任務不就是合理的分配資源與任務嗎？
以上的內容，只是我對
qa這個角色的一些個人認識，也希望能從不同的角度讓大家去了解，熟悉
qa這個角色，在專案中，
qa與專案團隊，在公司中
qa與各部門，永遠沒有所謂的對立，其實大家的目標很簡單，就是希望將各個任務做好，
qa可能不是作為一線的執行者，但其實更多的作為各執行者的輔助工作，協助大家完成各自的任務。我相信大家都希望遇到乙個能夠幫助大家預見風險，解決問題的qa。