Quality 마인드셋 트레이닝
사고방식은 배우는 것이다
Quality란 어디에나 있고, 내 책임이 있다.
Quality란 단순히 어떤 제품의 질이 좋고 규격에 맞는가를 나타내는 게 아니다. Quality가 Product quality인 품질(品質)이라고 왜곡된 번역 때문에 잘못 이해하는 사람들이 대다수이다. Quality는 단순히 제품뿐 아니라 그 제품을 만들기 위한 활동, 과정 및 결과물 모두를 의미한다. 따라서 quality는 단순히 제품을 만든 사람 혹은 테스트한 사람의 책임이 아니라, 처음 기획 한 사람부터 제품 제작에 참여한 모든 사람들의 책임이다.
품질 (品質) - Product Quality
품질을 좌우하는 것은 테스트 결과인가? 아니다. 품질은 처음 어떻게 기획되었는가부터 어떻게 디자인이 되었는가, 어떻게 개발되었는가 그리고 어떻게 테스트되었는가. 이 모든 게 좌우한다. 고급의 디자인과 개발, 테스트까지 완벽했다 하더라도, 처음 기획의도에서 어긋난 제품이 만들어졌다면, 그 제품의 품질을 좋다고 말할 수 있을까? 손님이 간짜장을 시켰는데, 만들다 보니 정말 맛있는 짜장면이 되어 나갔다. 과연 간짜장을 주문한 손님은 본인이 원하지 않은 음식을 받고도 맛있으니 드시라는 식당의 말에 행복할까?
결국 품질은 그 제품을 사용하는 유저의 판단에 달려있다. 개발팀에서 항상 실수하는 부분이 "나도 유저야. 나는 좋아!" 라며 진행하는 것이다. 내가 요리해놓고 나는 맛있으니까 남들한테도 무조건 맛있어!라고 말하는 것과 똑같다. 분명히 품질을 확인하는 데 있어서는 본인의 판단보다, 명확한 리서치와 검증이 필요하다.
Process Quality
프로세스, 과정의 질은 그 프로세스를 이행하는 팀에 달려있다. Agility (속도), Cost (비용), Stability (안정성), Maintainability (관리성), Flexibility (유연성), Communication (의사소통) 등 각 회사와 팀에 중요한 부분에 따라 Process quality의 기준을 잡는 것이 우선이다. 단순히 빠르거나, 비용이 저렴하거나, 관리하기 쉽다고 해서 다 좋은 프로세스는 아니다. 각 회사와 각 사람들에 맞게, Optimisation (최적화) 하는 것이 관건이다.
왜?
"나는 개발자니까 개발이 우선이야", "나는 프로덕트 매니저니까 기획이 우선이야"
틀린말은 아니다. 개발에 대한 검증은 개발의 일부가 아닌 것인가? 기획에 대한 검증은 중요하지 않은가? 이건 옳고 그름의 문제는 아니다. 이 프로세스를 선호하고, 최적화가 된 회사라면, "나는 테스터니까 테스트를 할 거야" 하는 사람을 고용하면 된다.
하지만 여기서 한 가지 더 생각해봐야 하는 것은 Efficiency (효율성)이다. 프로덕트 매니저가 기획을 할 당시, 테스터는 기획에 대한 모든 회의에 참여하고 내용을 모두 이해하고 알고 있는가? 테스터가 기획에 대한 테스트를 하기 위해서는, 이 내용을 똑같이 그대로 전달받아야 한다. 만약에 중간에 어떤 내용이 빠지게 되거나 잘못 전달되면, 테스트를 결국 잘못된 방향으로 흘러가거나, 검증할 때 빠지는 부분이 생길 수도 있다. 그럼 이걸 전부 다 자세하게 아는 프로덕트 매니저가 검증을 하는 것이, 인력도 줄이고, 시간도 줄이는, 더 효율적인 방법 방법 일수도 있다. 그러나 이 프로덕트 매니저는 급하게 굉장히 중요한 기획을 맡게 되고, 이전 기획에 대한 테스트보다는 그 기획이 중요도 순위에서 더 위에 있다고 생각해보자. 그렇다면 테스트를 대신 맡아줄 사람이 필요하다. 이런 상황은 최대한 미리 예측해보도록 하고, 커뮤니케이션 프로세스에서 가장 효율적으로 움직여서 최대한의 모든 정보가 테스트를 맡아줄 사람에게 정확하게 전달될 수 있도록 해야 한다. 효율성은 최대한 모든 상황에 대처할 수 있도록 계획해야 한다.
내 똥은, 내가 쌌으면 남보고 "내가 어딘가에 똥을 쌌는데, 찾아서 치워줘" 라기보다는 내가 가서 치우는 게 가장 효율적이다. 똥을 치우는 사람이 따로 있으면, 적어도 쪽지로든 뭐로든 내가 똥을 어디다 쌌는지는 미리 알려주자. 안 그럼 결국 그냥 아무 데나 똥 싸는 훈련되지 않은 개가 되는 것이다.
