QA 툴이 탄생하는 과정-1탄
'0'에서부터 프로덕트를 만들어 가는 여정
과연 IT 초기 프로덕트는 어떻게 탄생할까?
저희 큐에잉도 이제 제작을 시작한 지 어느덧 3개월차가 거의 되어 가는데요,
큐에잉과 같은 IT 초기 프로덕트가 어떤 식으로 만들어지는지 저희 큐에잉의 탄생 과정을 통해 보여드리려 해요.
큐에잉의 시작
팀빌딩
팀큐에잉의 첫 단톡방 개설저희는 팀스파르타의 '프로덕트 캠프 2기' 활동을 통해 만나게 되었어요.
팀큐에잉은 PO, 디자이너, 프론트엔드 개발자, 백엔드 개발자 이렇게 총 4명으로 구성되어 있어요.
서로의 소개 카드를 읽으며 mbti, 성격, 취미 등을 기억하려고 애썼던 기억이 새록새록 나는데요,
이제는 3개월차만에 아주 찐한 팀이 되었답니다!
4명으로 구성된 아주 작은 팀이지만 함께 으쌰으쌰하며 지금도 나아가고 있어요.
운명같은 QAing과의 만남
프로덕트 캠프에서는 각 팀이 개발하게 될 아이템을 배정해주었는데요, 저희 팀의 아이템은 바로 QA였어요.
사실 저희 팀에서 PO님 외에는 QA의 경험이 없었기 때문에 관련 지식이 전무했어요.
그러다보니 처음에는 막막했던 기억이 나네요ㅎㅎ
그렇게 아이템을 배정받은 후, 첫날부터 바로 기획을 시작했어요 (저희에겐 3개월밖에 시간이 없었기 때문이죠..)
기획 첫걸음
문제정의
큐에잉의 첫 린캔버스(큐에잉의 가제는 원래 QAD 였답니다)
먼저 QA 과정에서의 문제 정의부터 시작했어요. IT 프로덕트를 QA를 하기 위해서 많은 사람들이 이미지 캡쳐 또는 화면 녹화를 하는데, 오류가 발생하면 이 부분을 캡쳐나 녹화를 하기 위해 다시 돌아가 재연을 해야 한다는 불편함이 있다는 것을 발견했죠.
문제점을 바탕으로 여러 경쟁사들을 조사하기 시작했어요. 국내에는 자동화 서비스 외에는 QA 관련 툴이 거의 없었고 이렇다 할 솔루션을 제공하는 곳이 거의 없더라구요. 해외에는 관련 서비스가 어느정도 있었지만 저희와 같은 관점으로 접근한 서비스는 거의 없다는 것을 알게 되었어요.
그래서 서비스의 주요 가치를 '원하는 부분을 잘라서 쉽게 공유하게 한다'로 잡았어요.
캡쳐나 녹화를 위에 다시 재연을 하지 않아도 된다는 것이 차별점이었죠.
유저 인터뷰 대잔치
초기에 진행한 유저 인터뷰 기록들바로 다음 날부터 저희는 팀스파르타의 내부 PM, 디자이너, 개발자분들을 대상으로 인터뷰를 진행했어요. 그 날만 열 분 정도 쉼 없이 인터뷰를 했던 기억이 나네요 ㅎㅎ
모두 QA를 어떤 식으로 진행하고 계신지 직접 시트까지 보여주시면서 적극적으로 참여해주셔서 너무 감사했어요. 덕분에 추가적인 문제 상황도 발견할 수 있었는데, 오류 재연의 불편함에 더해 로그 기록이나 상세 설명을 일일이 따로 전달해야 한다는 것과 QA 결과 화면을 정확하게 공유하기 어렵다는 것이었어요.
인터뷰를 하면서 무엇보다도 유저의 목소리를 직접 듣는 것의 힘을 제대로 배울 수 있었어요. 인터뷰를 진행할수록 구체적인 문제 상황과 저희의 타겟, 그리고 만들어 가야 할 솔루션에 대한 그림이 점차 그려지더라구요. 저희가 전혀 생각하지 못했던 페인 포인트를 발견할 수도 있었고, 팀마다 굉장히 다양한 방식으로 QA를 진행하는구나도 알 수 있었어요. 유저들이 어떤 것을 원하는지 직접 목소리로 들으니 더 공감할 수 있었던 것 같아요.
그렇게 저희는 총 15분 조금 넘는 분들을 대상으로 유저 인터뷰를 진행했답니다!
하지만 하나의 프로덕트를 만들어 낸다는 것은 역시 쉽지 않죠...
뭐든 처음 기획한 대로 무난히 갈 수 있는 것은 아니듯 말이죠.
저희 큐에잉도 많은 고민과 기획의 변화를 거쳐왔는데요,
어떤 변화의 과정을 거쳐왔는지, 다음 이야기는 2탄에서 계속됩니다!
