많은 프로젝트 관리 방법론과 조직론에서 항상 얘기하는 것이 QA 부서를 독립적으로 두는것에 대해 강조하는 편이다.
테스트 역시 테스트 조직을 별도로 두는 것에 대해 강조하는 편이다.
이러한 QA 부서 또는 테스트만을 전담하는 조직이 꼭 별도로 존재해야 하는 것일까?
테스트의 경우에는 개발자와 다른 시각을 가진 사람들의 테스트의 필요성을 강조하기 위해서 테스트 조직을 별도로 두는 것을 강조하는 편이다.
만약 테스터가 개발이나 영업, 운영과 같은 조직의 하부 조직이 되다 보면 정치적인 독립성에 따라 자신만의 독립적인 시각이나 의견을 피력하기 힘든 점이 있기 때문이다.
QA 부서는 어떨까?
여기서 먼저 생각해 볼 것이 있다.
그것은 QA 부서가 과연 무슨 일을 하는 부서인가? 하는 문제이다.
여러분의 회사에서 QA 부서는 과연 어떤 일을 하는가? 여러분은 QA 부서에 대해 얼마나 호감을 가지고 있는가?
펼쳐두기..
회사마다 회사의 정책이나 전략에 따라 QA 부서의 역할은 매우 판이하다. 그리고 그 역할에 따라 회사 내에 QA 부서의 호감도도 매우 달라지는 편이다.
만약 여러분이 QA 부서에 대한 호감도가 낮다면 아래와 같은 문제가 있는 것은 아닌지 한번 고민해 보시고 댓글이나 트랙백등으로 의견을 주셨으면 하는 바람이다.
먼저 일반적으로 QA 부서가 하는 일은 제품의 품질을 측정하고 제품의 품질을 향상시킬 수 있는 모든 활동을 계획하고 제어하는 일을 한다.
그런데 문제는 소프트웨어의 품질이 문제가 된다.
먼저 공장과 같은 하드웨어를 제조하는 회사의 경우에는 품질 부서가 독립적으로 존재한다. 이 품질 부서에서 제품의 품질을 측정하고 제품의 품질을 개선하기 위해 집중하는 곳은 하드웨어 그 자체이다.
하드웨어는 각각의 부붐의 품질이 100인 제품이 모여서 하나의 제품을 구성하게 되었을 때 그 제품의 품질은 역시 100이다.
이것은 매우 명확한 사실이다.
소프트웨어를 만드는 회사의 조직과 관리 방법 역시 이러한 하드웨어를 만드는 회사의 조직과 관리 방법을 그대로 물려받았다.
그런데 문제는 소프트웨어 회사의 QA 부서가 품질에 집중해야 할 상황에 직면했을 때 QA 부서가 직면하는 제품은 형체가 없는 가상의 소프트웨어이다.
즉, 기존의 관리 방법으로는 이것을 관리할 방법이 없게 된다.
때문에 제품 자체에 집중할 수 없다면 소프트웨어를 만드는 사람에게 집중하게 된다. 즉 QA 부서가 사람을 통제하게 되는 것이다. 만약 QA 부서가 인사 부서와 연합횡종을 하게 된다면 회사내의 모든 조직에 미치는 파급은 가히 상상을 초월하는 수준에 이르게 된다.
하지만 이러한 것은 절대로 있어서는 되는 일이 아니다.
소프트웨어 회사에서 QA 부서가 제품 자체가 아닌 사람에 집중하여 사람을 통제하여 제품의 품질을 조절하려는 가장 큰 가정은 뛰어난 개발자가 뛰어난 제품을 만들 수 있다는 것이다.
그리고 사람은 우선 눈에 보이기 때문에 통제 가능하다고 생각하는 것이다.
하지만 위 두가지 가정 중 그 어느 것도 가능한 가정이 아니다.
우선 사람의 능력과 생산성의 측정은 하드웨어의 품질을 측정하는 것만큼 명확하지도 간단하지도 않다.
설령 측정 가능하다고 하더라도 뛰어난 개발자들만을 모아놓는다고 해서 뛰어난 제품이 나오는 것도 아니다.
책상 앞에 앉아서 현란하게 손가락을 움직인다고 해서 좋은 소프트웨어가 나오는 것도 아니다. 솔직히 말하면 가만히 앉아서 많은 생각을 하는 와중에 더 좋은 소프트웨어가 나올 확률이 높다.
분명 QA 부서에서 소프트웨어의 품질을 측정하는 지표 자체가 사람을 통제하는 지표는 아니다.
하지만 그러한 소프트웨어의 품질을 측정하는 지표들을 자세히 들여다 보면 그러한 지표들은 대체로 그러한 품질 측정 지표를 회피하기 위한 사람의 행동을 야기하게 된다는 것을 알 수 있다.
이러한 차이와 딜레마가 생기는 근본적인 것은 하드웨어를 관리하는 방법과 측정 지표가 소프트웨어에 적용되고 있기 때문이다.
QA 부서에서 이러한 차이를 인식하지 못하고 있다면 조직 내에서 QA 부서에 대한 호감도는 매우 낮을 것이다. 그리고 회사 내에서 품질에 대한 인식 자체가 매우 부정적일 것이다.
소프트웨어의 품질은 누군가가 책임을 지고 제어하고 측정할 수 있는 성질의 것이 아니다. 소프트웨어의 품질은 소프트웨어의 개발에 관련된 모든 사람들이 책임지고 결정할 문제의 것이다.
즉, 하드웨어처럼 뛰어난 부품을 모아서 뛰어난 제품을 만드는 것처럼 뛰어난 개발자들을 모은다고 해서 뛰어난 제품이 나오는 것이 아니다.
막상 뛰어난 제품은 뛰어난 커뮤니케이션과 정보 공유에서 오는 경우가 많다.
즉, 소프트웨어는 그 자체가 품질을 내포한다기 보다는 소프트웨어를 개발하는 과정이 품질을 내포한다고 생각한다.
따라서 소프트웨어의 QA 부서라면 이러한 것을 이해하고 소프트웨어의 개발에 관련된 모든 이해관계자의 커뮤니케이션을 강화하고 모든 이해관계자가 동일한 목표를 향할 수 있도록 이끄는 역할을 해야 한다.
그렇지 못한다면 QA 부서는 있으나마나 한 조직이다.
여러분의 QA 부서는 어떠한가? 여러분의 QA 부서는 품질을 어떻게 이해하고 있는가? 무엇에 집중하고 있는가?
trackback from: 소프트웨어 관료화
답글삭제"공무원 수는 해야 할 일의 경중이나 업무 유무에 관계없이 일정한 비율로 증가한다", "공무원은 서로를 위하여 서로 일을 만들어 낸다", "유능하지 못한 사람은 공무원이 된다." 이는 그 유명한 파킨슨의 법칙입니다. 소프트웨어를 개발할 때도 이와 같은 함정이 도사리고 있습니다. 주먹구구식으로 소프트웨어를 개발하다가 체계적으로 개발하고 싶은 요구가 생길 때 프로세스팀을 구축하고 개발 프로세스를 정립하다 보면 파킨슨의 법칙에 빠지기 쉽습니다. 프로세스팀..
결론을 말씀드리면 일반적인 SW회사에서 진짜 QA부서는 별로 필요없습니다. 테스트만 제대로 하면 되는 경우가 대부분입니다. 사실 테스트도 제대로 하기 쉽지 않습니다.
답글삭제좋은 글 잘 읽었습니다. 제가 요즘 고민하고 있는 내용과 비슷한 아니, 거의 같은 내용이네요.
답글삭제품질 향상을 위해 버그 하나를 더 잡는 것 보다는 이해 당사자 관리 및 개발자와의 커뮤니케이션, 프로젝트의 방향성 제시와 같은 역할이 맞다는 것에는 동의 합니다. 저도 현재 그 일을 하고 있고요.
여기서 궁금한것이 이러한 일련의 행동(?)들은 굳이 범위를 따지자면 PM의 역할이 아닐까요?
결국, 능력있는 PM이 있다면 QA가 필요할까?라는 의문이 생깁니다.
품질에 대한 이해나 시각을 다르게 갖는 것은 꼭 필요한 것이지만 '관리&대화'의 측면이 부각될 경우 PM의 역할과 겹치는게 많아지고 이로인한 오해도 생길 수 있을 듯 합니다. 오히려 입지가 더 좁아 질 수도 있고요.
@posha - 2009/12/08 19:41
답글삭제만약 그러한 이유로 QA 부서가 필요없다면 없어지는 것이 맞다고 생각합니다.
하지만 작은 팀이라면 PM이나 리더들이 그러한 역할을 분담할 수 있겠지만 조직이 커지고 회사 차원의 정책이나 전략이 필요한 부분이라면 그러한 것들은 QA 부서가 책임과 권한을 이양 받는 것이 맞다고 생각합니다.
결론은 Case by Case 인것이겠죠. 정답은 없습니다.
답변 감사합니다.
답글삭제그런데, 품질의 방향(제가 예시로든 대화& 관리) 때문에 'QA가 필요없어질 수도' 있다는 것에는 약간의 의문이 있습니다.
능력있는 PM이 있는 작은 팀이라면, QA 역할이 그만큼이나 축소 되는 것일까요? 큰 조직의 예시에서도, PM 개인이 아닌 전사 규모의 PM팀이 있다면(또, 일을 잘 한다면) QA 팀의 역할이 그만큼 축소 되는 걸까요?
제 생각에는 커뮤니케이션이나 관리가 품질을 더 잘 보증하기 위한 방법 중에 하나이어야지 목적이나 방향자체가 되어서는 안된다고 봅니다. 그렇게 될 경우 어느 조직에서건 PM(혹은 PM팀)과의 업무 영역이 겹치게 될 것이고 이를 협업이라는 좋은 말로 풀기에는 어려운 상황도 발생할 듯 합니다.
품질 분야에 있어 최고라고 평가 받는 블리자드, 나사의 경우에도 QA와 PM을 따로 두는 것은 그에 맞는 목적이 있기 때문이라 생각합니다. 관리나 커뮤니케이션, 전체적인 소통 등은 QA에게 있어 관점, 방향이라는 접근보다 '수단의 하나'로 범위를 좁히는 것이 오히려 품질 향상을 위해 도움이 되지 않을까 합니다.
답글삭제@posha - 2009/12/08 21:59
답글삭제서로 생각하는 바는 비슷하지만 블로그에서 댓글로 오고가는 글 사이에 정보가 충분히 녹지 못하는 것 같습니다.
저는 대화와 관리는 PM이 할 수도 있지만 그 결과를 측정하고 개선하는 작업을 하는 조직이 따로든 그 자체에서 해결하든 있어야 한다고 생각합니다.
PM의 능력이나 그런것과 상관없이 그것을 평가하고 개선하는 어떤 조직이나 프로세스는 있어야 한다고 생각합니다.
제가 말하고자 하는 것은 많은 경우 QA 부서의 역할이 말씀하신 것처럼 기존의 조직이나 PM들과 충돌하는 부분이 많기 때문에 그에 대한 논의가 있어야 하고 QA가 과연 어떤 역할을 할 것인지에 대한 논의가 있어야 한다고 생각합니다.
흠..
그리고 커뮤니케이션이나 관리가 품질을 더 잘 보증하기 위한 방법 중에 하나이어야지 목적이나 방향자체가 되어서는 안된다는 것에는 저도 동조하는 바입니다.
설명 감사합니다.
답글삭제'충돌이 없어야 한다'(저와) '충돌을 논의와 협업을 통해 장점으로 만들어야 한다'의 생각차이가 있었던 것으로 보입니다. 아직 내공 부족으로 시야의 폭이 좁습니다. 자주 오게 될듯 한데요, 많이 가르쳐 주세요^^;
개인적으로 좋아라~ 하는 PM이 제게 QA로서 품질향상에만 포커스를 두지 말고 조직구성원으로써 프로젝트에 어떻게 기여할 것인지에 포커스를 두고 업무를 진행하라고 충고한 적이 있었습니다. '내가하는 일련의 행동들은 당연히 프로젝트에 기여하는 것인데..'라는 생각에 약간은 섭섭했었는데, 뮤리안님의 글과 댓글에 좋은 방향이 있었네요.
@posha - 2009/12/09 10:12
답글삭제저도 아직 많이 부족합니다.
자주 오셔서 댓글 등으로 많이 도와주시면 고맙겠습니다.
좋은 글, 댓글 감사합니다~
답글삭제