[내소기]Episode_#06 : 거친 개발자 불안한 기획자 그걸 지켜보는 QA

여섯 번째 에피소드입니다.

 

제목이 오늘 엄청 특이하죠?

 

가수 임재범의 "너를 위해"를 패러디했습니다.

 

제목 : 프로젝트를 위해

 

거친 개발자와~~ 불안한 기획자와~~ 그걸 지켜보는 QA~~

 

실무를 하다 보면 여러 사람이 있습니다.

 

개발자로서의 프라이드가 엄청 강하신 사람이 있고,

 

경력이 얼마 되지 않아 자신이 한 기획에 대해 자신감이 없는 사람도 있습니다.

 

모든지 완벽할 수 없습니다.

 

제가 생각하기에는 완벽한 프로젝트는 개발&기획&QA가 서로 마주 보고 손바닥을 쳤을 때

 

짝 소리가 나야 합니다.

 

삼위일체가 되어야 한다는 뜻이죠.

 

오늘은 프라이드가 강한 거친 개발자, 경력이 부족한 불안한 기획자, 그걸 지켜보는 QA에 대해서 이야기해보겠습니다.

 

 

---

 

 

오늘도 쉬운 예를 들어보겠습니다.

 

여기 기획서가 있습니다.

 

구매하기 BTN을 클릭하면

 

구매하기 Alert 이 출력되어야 합니다.

 

QA 도중 해당 페이지에서 구매하기 BTN 을 클릭했는데 

 

바로 결제 페이지로 이동되는군요.

 

결함을 등록합시다.

 

 

 

이게 왜 결함이야!!!

개발자가 엄청 화가 났습니다.

왜일까요?

QA에서 BTS에 등록한 결함을 보고 왜 결함이냐고 묻습니다.

●QA : 기획서에 명시된 대로 BTN 클릭 시 Alert 이 출력되어야 합니다.

●Dev : 어차피 유저는 구매할 생각으로 눌렀는데, 왜 Alert을 띄워줘야 하죠?
그리고 또 결제 페이지로 이동되면 정상 동작 아닌가요?
이 issue #001 은 수정하지 않겠습니다.

●Planner : 헉! ㅠㅠ 

●QA : 흠... 

냉정하게 분석하기

●QA : 기획자님 해당 기능에 대한 기획의도가 무엇일까요?

●Planner : 어... 그냥 다른 사이트도 구매하기 BTN을 클릭하였을 때, Alert 이 나와서 동일하게 기획하였습니다.

●QA : 흠... 그러면 해당 기능에 대해서 수정을 진행할 수 없습니다.
사실 구매하기 BTN을 클릭하였을 때, 결제 페이지로 이동되는 현상은 정상적입니다.

●Planner : 어떻게 하죠 ㅜㅜ

●QA : 잠시만요...

기획자가 경력이 부족하여 자세한 히스토리를 모르는 업무에 대해

 

기획서를 쓰다 보니 이런 사소한 기능에서도 

 

Description이 왜 이렇게 정의되어 있는지 모르고 있습니다. 

 

이전 대화에서 기획자가 "다른 사이트도..... 동일하게...."

 

라고 말한 것 기억하시죠?

 

자 그럼 다른 사이트를 확인해보면 QA가 해야할 일은 두가지가 있습니다.

 

1. 다른사이트를 기획한 사람에게 히스토리 물어보기  2. 관련된 프로젝트 문서를 확인해보기

히스토리 파악하기

1. 다른사이트를 기획한 사람에게 히스토리를 물어봅니다.

●QA : 혹시 00 사이트를 기획하실 때, 해당 Alert을 띄우는 이유에 대해 알고 계신가요?

●다른 기획자 : 흠... 잘 모르겠지만 CS 관련 부서에서 요청이 들어왔었어요.


2. 관련된 프로젝트 문서를 확인해보기 

CS 관련부서에서 요청이 들어왔기 때문에 CS 확인할 수 있는 게시판에서 특정 키워드로 검색을 하거나 

관련된 프로젝트 문서에 대해 열람 권한을 획득한 후 히스토리를 파악할 수 있습니다.

●QA : 그럼 해당 프로젝트를 진행할 때에 문서를 확인할 수 있도록 열람 권한을 주시겠습니까?

●다른 기획자 : 네 ~ 드렸습니다.

관련 프로젝트 문서를 확인하던 도중 

 

CS 관련부서의 요청을 확인할 수 있었습니다.

 

이유는 두 가지였습니다.

 

1. 강성 컴플레인 유저

 

2. 구매하시겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많았던 점.

 

자 그럼 이제 개발자를 설득할 시간이 되었습니다.

 

수정해주세요. 얼른!!

●QA : 개발자님

●Dev : 왜요! 

●QA : Issue #001 수정해주셔야겠습니다.

●Dev : 왜요!! QA 도 개발팀 소속이면서 기획자 편을 들어주는 거예요?!

●QA : 해당 기능은 과거 유저 CS로 인해 생긴 기능입니다.
바로 구매 페이지로 이동하여 강성 컴플레인을 건 유저가 있었습니다.
그리고 구매하겠습니까? Alert을 띄우지 않았을 때, 환불하는 유저가 많아 다른 사이트에도 모두 Alert 을 노출시켜주고 있습니다.
그래서 이번 00 사이트에서도 구매하기 BTN을 클릭하였을 때, Alert 이 출력되어야 합니다.

●Dev : 깨갱.. 알겠습니다. 수정되었습니다.

---

이렇게 해서 잘 마무리되었습니다.

 

물론 위의 예시는 쉽게 설명하기 위해 들은 예시입니다.

 

실무를 하다 보면 많은 사람들과 커뮤니케이션을 하지만

 

늘 잘되는 일은 없습니다.

 

실제로 저는 위와 같은 경험을 굉장히 많이 겪었습니다.

 

Minor 한 결함이고, 당연하다고 생각되는 기능이지만

 

의문을 가지고 자신이 한 개발이 항상 맞다!

 

이런 식의 대화도 많이 겪었습니다.

 

여기서 QA는 그 누구의 편도 아니며, 항상 품질만을 생각해야 되기 때문에

 

이런 상황에서는 "근거"가 명확해야 합니다.

 

저는 회사를 다닐 때, 항상 다른 사람과 친하게 지냅니다.

 

물론 사람들과 대화하는 걸 좋아해서 그렇죠.

 

이런 상황이 오면 또 다른 사람들에게 도움을 받기에도 엄청 좋습니다.

 

물론 저도 제 일이 아니더라도 도움을 받는 만큼 돌려줍니다.

 

그리고 항상 확인하는 것이 프로젝트를 진행할 때에 유사한 프로젝트는 어떻게 진행되었으며

 

특이사항이 있었는지에 늘 체크를 합니다.

 

그리고 이번 프로젝트에서 예외적인 상황이 나올 수 있는지 미리 체크리스트를 작성하여 대비를 하는 것이지요.

---

오늘은 거친 개발자, 불안한 기획자 사이에서 QA는 어떻게 행동해야

 

품질을 높일 수 있는지 알아보는 시간을 가졌습니다.

 

QA 는 항상 품질만 생각해야 합니다. 

 

커뮤니케이션은 양팔저울처럼 어느 하나 기울어진 곳 없이 

 

동등하게 대해야 합니다.

 

그럼 Episode 06 마무리하겠습니다.

 

다음에 또 만나요~