문성준의 단단해지기

오랜만에 10번째 에피소드입니다.

오늘은 일하면서 들어본 이상한 단어와 웃픈 에피소드에 대해서 말해보려고 합니다.

#1 아삭하게 해주세요.

제가 아웃소싱에서 일할 때였습니다.

고객사에서 급한 일감이 들어왔는데요.

언제까지 해야 하는지 물어봤는데

돌아온 대답은 "아삭하게"였습니다.

아삭하게? 뭘 아삭하게 하라는 거지?

어느 지역 사투리지??

야무지게 하라는 건가???

평소 사투리를 쓰시던 분이셔서 

어느지역 사투리인지 검색을 하다가

ASAP이라는 단어를 검색하고 

깊은 탄식을 내뱉은 적이 있습니다.

As Soon As Possible

빨리빨리 / 가능한 (최대한) 빨리라는 뜻입니다.

본래 1900년대 중반에 미군에서 사용되던 단어이고,

미군에서 퍼져 보통 사람들 사이에도 적잖게 사용되는 단어라고 합니다.

에이에스에피라고 하거나 글자를 그대로 읽어서 에이쌥, 아삽이라고 읽기도 합니다.

사람마다 다르게 말한다고는 하지만

 다만 영어권 원어민이 “아삽”이라고 읽는 경우는 없다고 합니다.

즉, 고객사에서는 가능한 빨리 업무를 수행해 달라고 했었지만

저는 야무지게 하라는 뜻으로 이해했던 그런 해프닝이 있었습니다!

#2 tl;dr로 말씀드릴게요~.

오늘 있었던 일입니다.

앱 배포 때 minor 한 버그를 포함시켜야 할지 말지를 논의하고 있었습니다.

제가 답변 내용을 크게 보지 않고

변경점이라는 포인트에 집중하다 보니 

어떤 의미인지 다시 여쭤봤습니다.

저는 tl;dr이

채팅으로 대화를 했기 때문에

한/영 키를 잘못 누른 상태에서 입력하신 줄 알았습니다.

역시나 검색해 보니 

아래와 같이 나왔습니다.

TL;DR

TL;DR, 풀어서 "too long; didn't read"(너무 길어서 읽지 않았다)라는 뜻입니다.

응답이 되는 어떠한 텍스트가 그 길이 때문에 무시되고 있다는 것을 말하는 인터넷 속어입니다.

인터넷에서 글이 지나치게 길어 이를 비난하거나 글을 줄이는 것을 조언하기 위해 쓰는

'생략'과 흡사한 단어입니다.

즉, 두괄식으로 요점만 말해주겠다.라고 이해할 수 있겠습니다.

TL; DR로 한번 표현을 해보면

TL;DR : 이번 배포에 포함시키지 말죠! 
(뒤의 내용~~~ )

이런 식으로 응용해 볼 수 있겠네요.

오늘은 일하면서 처음 들어본 생소한 단어에 대해서 

재밌게 풀어보는 시간을 가졌는데요

일할 때 처음 듣는 단어라고 너무 거부감을 가지거나 놀라지 마시고

적극 활용한다면 지식도 얻고 업무처리도 빠르게 할 수 있습니다.

그럼 이만!

아홉 번째 에피소드입니다.

오늘은 이런저런 넋두리를 하려고 합니다.

프로젝트가 끝나고 나면 복잡한 감정이 생깁니다.

짧게는 2주, 길게는 2달 이상의 프로젝트를 주기적으로 하다 보면

리뷰 → 설계 →  QA → 결과보고 → 리뷰 → 설계 →  QA → 결과보고

무한 루프에 빠지게 됩니다.

 프로젝트가 끝났다는 안도감

몰려오는 피곤함

프로젝트 중 받은 스트레스

다음 프로젝트에 대한 고민

엄청 심경이 복잡해집니다.

이럴 땐 아무것도 하기 싫어지는데요.

잘못하다간 번아웃 증후군으로 이어질 수도 있을 것 같습니다.

https://namu.wiki/w/%EB%B2%88%EC%95%84%EC%9B%83%20%EC%A6%9D%ED%9B%84%EA%B5%B0

결국에는 이런 복잡한 감정들을 어떻게 정리하느냐

정리하고 나아가느냐 아니면 무기력 해지느냐의 싸움인데요.

사실 앞으로 나아가야 할 걸 알면서도 몸은 쉽게 따라주지 않습니다.

그럴 때 저는 주위를 한번 정리합니다.

주위를 정리한다는 것은 Feedback 활동을 진행하는 겁니다.

프로젝트가 마무리된 후

설계된 Testcase의 부족한 점은 없었는지

Test를 진행할 때 도움이 된 테스트에 대한 경험을 팀원들과 공유한다거나

다른 부서와 의사소통할 때 더 완곡한 표현을 쓰면 어땠을까

하는 나만의 피드백을 진행하여

무기력함에 빠지는 일이 없도록 해야 합니다.

그렇게 되면 복잡한 감정도 하나씩 정리가 되고요.

앞으로 나아가는데 큰 무리가 없게 됩니다.

오늘은 프로젝트가 끝난 후 몰려오는 감정에 대해

넋두리를 해봤는데요.

결국엔 앞으로 나아가는 QA 엔지니어가 되기 위해서는

주변을 정리하고(Feedback) 다시 달릴 준비를 해야 합니다.

프로젝트는 기간이 종료되었다고 해서 끝이 아니라

어떻게 보면 다시 출발점으로 돌아온 거나 마찬가지입니다.

다들 멘털 관리 철저히 하시고

나만의 방법으로 성장할 수 있도록 노력합시다.

그럼 Episode09 마무리하겠습니다.

다음에 만나요~

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

오늘은 처음으로 면접관이 돼서 면접에 참여한 이야기를 해볼까 합니다.

면접은 항상 긴장되고 떨립니다.

파트장으로 승진한지 1년도 되지 않은 어느 날이었습니다.

새롭게 인력을 충원해야 하고, 프로세스를 개편해야 하는 단계였죠.

매일매일이 바쁘고 어지러웠습니다.

그러던 어느 날 면접관의 부재로 제가 대신해서 1차 면접에 면접관 자격으로 참석하게 되었습니다.

물론, 지원자의 이력서만 잠깐 확인한 정도였습니다.

사실 제가 늘 했던 생각은

"내가 면접관이 되면 안 떨리겠지?"

라는 생각을 많이 했습니다.

그런데 웬걸 면접을 보는 지원자일 때와 별반 다를게 없이 긴장이 되었습니다.

첫 면접의 기억

그렇게 해서 면접관으로 첫 면접을 들어갔습니다.

지원자는 신입사원으로 지원을 하였습니다.

지금 생각해보면 지원자에게도 굉장히 죄송스럽습니다.

면접을 보기 위해 얼마나 많은 준비를 하고 긴장을 하는지 누구보다 더 잘 알기 때문입니다.

어찌 됐던 면접에 참석을 하였으니 최선을 다해야겠다고 생각했습니다.

제가 중점적으로 확인하고 싶었던 건 

QA 엔지니어로써 어떤 기술력을 가지고 있느냐 보다는

내가 속해있는 QA 팀이 나아가고자 하는 방향성과 부합한 인물인지 확인하는 것이었습니다.

신입사원으로 지원한 만큼 QA 이론보다는 업무를 빠르게 습득할 수 있고, 팀에 어울릴 수 있는 사람인지를 

확인해야 하기 때문에 커뮤니케이션 능력, 성격 위주로 질문을 구성해서 면접을 진행하였습니다.

현실의 벽에 부딪히다.

여러 번 면접관 업무를 진행하다 보니

현실의 벽에 부딪히는 경우가 많았습니다.

우리는 좋은 인력이 필요하지만, 내가 소속된 회사는 그렇게 좋지는 않았습니다.

어떻게 보면 "양두구육"(羊頭狗肉) 이였죠.

면접이 끝나갈 무렵 항상 지원자에게 회사에 대해 궁금한 점을 질문을 받습니다.

신입으로 지원한 지원자의 경우 

대부분 회사에 대한 기대감이 눈에 드러날 정도로 기대를 하는 모습을 많이 보았습니다.

저는 그러나 회사에 4년 가까이 몸담았기 때문에 사실 좋은 모습보다는 안 좋은 모습을 많이 알고 있습니다.

그렇기 때문에, 만약에 이 지원자를 채용한다고 했을 때, 지원자가 나중에 가지게 되는 실망감이 

저에게 돌아올 수도 있다고 생각을 하여 많은 고민에 잠을 설친 적이 하루 이틀이 아녔습니다.

현실의 벽을 부수다.

사실 위와 같은 고민은 쉽게 해결되었습니다.

나 자신이 "복지"가 되는 것이었는데요.

내가 성장해서 많은 것을 알려주고, 내가 분위기를 주도한다면 

회사까지는 아니겠지만 최대한 내가 속해있는 Team도 분위기가 변할 것이라고 생각하였습니다.

그렇기 때문에 나 스스로 성장을 해야겠다는 생각이 많이 들었고,

목표로 설정한 건 " 회사는 별로지만 팀원분들이 너무 좋다."

라는 소리가 나올 정도로 케어를 해줘야겠다는 생각도 들었습니다.

물론 늘 이직을 생각하고 있었지만, 왠지 모를 책임감이 생겨 인력을 충원할 때에는 이력서 사이트를 모두 OFF 시키기도 하였습니다.

아직도 많이 부족하지만 그래도 이때 다짐했던 목표를 지금까지는 잘 수행하고 있는 것 같습니다.

오늘은 처음 면접관의 자격으로 면접에 참석했을 때 기억을 되살려봤는데요.

면접관의 자격으로 한 20번 이상의 면접을 진행한 것 같습니다.

그런데도 아직 면접 일정이 잡히게 되면 

지원자일 때와 동일하게 잠을 설치고 소화도 잘 안되고 긴장이 되는건 마찬가지더라고요.

내가 지원자일때 면접관들은 피도 눈물도 없는 냉혈한인줄 알았지만

다 똑같은 사람입니다.

면접관들도 행여 실수를 하여 지원자의 마음에 상처를 주지 않을까

굉장히 고민을 많이 한다는 점.(물론 안 그런 사람도 있지만)

그럼 Episode08 마무리하겠습니다.

다음에 만나요~

일곱 번째 에피소드입니다.

오늘 제목은 솔직합니다.

모든 업무는 투명하게 기록되어야 합니다.

투명하게 기록한다.

오늘의 핵심 키워드는 "기록" 입니다.

오늘은 제가 실무를 진행하며 겪었던 일에 대해 

MSG좀 첨가하여 예를 들어보겠습니다.

왜 QA 한테는 공유를 안 해주시나요?

프로젝트 단위로 QA를 진행하다 보면 엄청 다양한 일이 일어납니다.

그리고 여러 책임감 없는 사람도 볼 수 있습니다.

며칠 전에는 QA Plan, Design 기간이 종료되고 검증일이 시작한 후에 일부 정책이 변경되었다는 것을 알 수 있었습
니다.

명세 기반 작성법으로 Testcase를 작성하고 수행하게 되면 설계기간 이후에 발생되는 정책 변경 사항은 치명적입니다.

회사 정책 같은 경우에는 굉장히 민감한 사항입니다.

관련 사업부서, 마케팅 부서, 영업 부서도 정책을 기반으로 한 매뉴얼대로 움직이고 각 회사 법무팀에서 법적으로 위반되는 사항이 있는지 까지 확인을 하기 때문입니다.

그런 중요사항이 검증 시작 이후 공유가 된다면, QA는 다시 Testcase를 손 볼 수밖에 없습니다.

명세 기반 Testcase를 작성할 때는 명세서에 있는 기능에 대해 모든 Testcase를 작성한 후에 작성한 case들이 정책에 위반되지는 않는지 CrossCheck 프로세스가 추가되기 때문입니다.

하지만 QA를 단순 Tester로 보는 구성원, 혹은 회사라면 이런 정책 변경사항을 공유를 잘해주지 않습니다.

정책 같은 부분이 Software에 적용된다는 사실을 간과하기 때문이죠.

그렇기 때문에 최종적으로 QA Plan, QA Design 전에 QA 엔지니어는 바뀐 정책이 있는지에 대해 항상 확인을 해야 합니다.

사실 QA가 확인한다고 해서 100% 대비할 수는 없지만  QA 엔지니어는 항상 최악의 경우를 대비해야 되기 때문에  명심하고 조심해야 합니다.

또 QA 한테는 공유를 안 해주셨네요? 

이런 적도 있습니다.

Dev ↔ 기획자 둘만의 소통으로 인해 QA에게 정보가 누락된 경우가 있습니다.

이는 주로 빠른 업무처리를 위해 BTS에 등록하지 않고, 그 자리에서 즉흥적으로 기획을 변경하거나 개발을 수정하는 경우가 많습니다.

그래서 나중에 검증기간에 관련해서 결함으로 등록하면 돌아오는 답변은

" 기획자와 유선으로(구두로) 수정된 사항입니다."

라고 답변이 옵니다.

이럴 경우 화가 머리끝까지 치밀어 오릅니다.

같은 프로젝트를 진행하는데 왕따를 당한 기분이 드니까 말이죠.

사실 이런 경우에는 힘이 빠지긴 하지만 저 같은 경우는 프로젝트 관련 게시글 혹은 Slack에 공지를 합니다.

1. 기획 변경 시, 꼭 QA를 포함한 모든 관련 부서에게 공유 부탁드립니다.

2, QA 기간 동안에는 보고되지 않은 결함 수정은 진행되지 않아야 합니다.

3. 프로젝트 진행 시, 프로젝트와 관련된 모든 사항들은 해당 게시글(Slack 등)에 기록되어야 합니다.

라고 공지를 합니다.

왜 강하게 공지를 하냐면, 결론적으로 QA는 일을 두 번씩 하게 되는 무의미한 업무를 진행하게 됩니다.

예를 들어 기획에 맞지 않는 기능이 있어 해당 issue를 BTS에 등록합니다.

Assign to dev 상태로 등록이 되겠죠?

그러면 Fix 상태로 와야 될 결함이 Not a bug 상태로 오게 됩니다. 왜냐면 이미 QA 가모르는 상태에서 기획이 변경되었기 때문이죠.

그러면 해당 issue는 벌써 여러 상태 값이 존재하게 되고 QA > 개발 > QA > 기획 > QA라는 불필요한 핑퐁이 생겨나게 됩니다.

QA > 개발 > QA에서 끝나게 될 일을 말이죠.

이건 싸우겠다는 건가요?

제 경험상 프로젝트 진행 중 언성이 높아지는 경우는 위와 같이 어떠한 내용이 공유가 되지 않을 때입니다.

" 왜 공유해주지 않으셨죠?"

"저희는 몰랐는데요?"

"저희한테 공유 안 해주셨으니 책임지지 않겠습니다." 등등

사소한 내용이라도 공유가 되지 않았을 경우 같이 협업하는 입장에서 이미 기분이 상하기 때문에 언성이 높아질 확률이 높다고 생각됩니다.

그래서 제가 하고 싶은 말은 모든 업무는 투명하게 기록되어야 합니다.

왜 "투명하게" 기록되어야 하냐면, 각자 A라는 주제에 대해 소통을 하더라도 어떤 사람은 A로 이해를 하고 또 어떤사람은 B로 이해를 할 수 있기 때문입니다.

그렇기 때문에 업무에 대해 기록을 할 때는 객관적으로 기록을 해야 되며, 주관적인 생각이 들어갈 때에는 반드시 "제 의견은", "00팀 의견은" 이런 식으로 꼭 명시를 해줘야 됩니다.

그래야 추후 오해가 생기지 않고, 누구나 수긍 가능한 결과를 도출해낼 수 있기 때문입니다.

오늘은 업무를 진행할 때, 

불필요한 커뮤니케이션 또는 오해를 방지하기 위해 QA 엔지니어는 어떻게 업무를 진행해야 하는가에 대해

제 경험과 함께 알아봤습니다.

물론 다들 각자의 방법이 있겠지만 저는 투명하게 기록하는 것

업무의 정석이라고 생각됩니다.

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

다음에 또 만나요~

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

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

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

제목 : 프로젝트를 위해

거친 개발자와~~ 불안한 기획자와~~ 그걸 지켜보는 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. 다른사이트를 기획한 사람에게 히스토리를 물어봅니다.

●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 마무리하겠습니다.

다음에 또 만나요~

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

입사 후 수습기간이 끝나고 나면 

이제 저도 정식직원입니다.

그러면 나를 대표할 수 있는 종이 한 장 필요하겠죠?

오늘의 키워드는 명함 입니다.

사람을 주로 만나는 높은 자리의 임원 혹은 영업직이 아니면 

명함을 주로 쓰는 일은 없을 겁니다.

그래서 명함을 그냥 포스트잇처럼 주고받고 하는 사람이 있는데요.

그건 더더욱 안되죠.

오늘은 명함 예절에 대해 알아보도록 하겠습니다.

명함 "名銜" 이름 명, 재갈 함

성명, 주소, 직업, 신분 따위를 적은 네모난 종이 쪽. 흔히 처음 만난 사람에게 자신의 신상을 알리기 위하여 건네준다.

사전적 의미입니다.

자신의 신상 혹은 존재를 알리기 위해 사용하는데요

관용구로는 

명함도 못 들이다 라는 표현과 명함을 내밀다 라는 표현을 자주 쓰곤 합니다.

명함도 못 들이다 라는 표현은 주로 수준이나 정도 차이가 심하여 도저히 견줄 바가 못 될 경우 사용하죠.

예를 들면,

"Critical issue를 을 분석하기 위해 초급 테스터가 왔다가 명함도 못 들이고 갔다." 

라는 식으로 쓸 수 있겠네요.

명함을 내밀다 라는 표현은 존재를 드러내 보일 때 사용하곤 합니다.

예를 들면,

" QA 업계에 문성준이 처음으로 명함을 내밀다."

하하하 이런 식으로 존재를 드러내어 보일 때 사용합니다.

위의 두 가지 예를 든 것은 그만큼 명함의 중요성을 강조하기 위해서 예시를 들었습니다.

그만큼 중요한 물건을 남에게 전달할 때도 소중히 전달해야겠지요?? 

1. 탈것을 타고 전단지를 뿌리듯 전해준다.	2. 공중으로 뿌려 던진다.
3. 수리검 던지듯 던진다.	4. 두 손으로 건네며, 상대방이 명함을 바로 확인할 수 있게 상대 방향으로 돌려서 전달한다.

어려운 문제였는데요.

정답은 4번입니다.

명함을 줄 때는 두 손으로 건네며, 상대방이 명함을 바로 확인할 수 있게 상대 방향으로 돌려서 전달해야 합니다.

그리고 명함은 서열이 낮은 사람이 먼저 건네야 합니다. (단, 상대 서열이 낮다고 해서 앉아서 명함을 받는 행위는 예의가 아닙니다.)

그렇지만 예외는 있습니다.

만약 파견업무를 갔지만 나보다 서열이 낮은 사람이라도 방문한 사람이 먼저 건네는 것이 예절입니다.

또한, 한 손으로 전달하는 방법도 있습니다.

오른손으로 전달해야 하며, 상대 방향으로 돌려서 전달해야 합니다.

또한 왼손은 오른손을 받쳐서 전달해야 합니다.

명함을  같이 교환할 때 주로 한 손 전달법을 사용합니다.

오른손으로 주고, 왼손으로 받아야 합니다.

그리고 항상 명함을 줄 때는 손가락으로 이름을 가리는 일은 없어야 합니다.

오늘은 명함을 전달하는 방식에 대해 알아봤습니다.

QA 엔지니어라고 해도 명함이 있고 언젠가는 명함을 주거나 받는 일이 생길 수 있습니다.

어버버 하다가 예의범절 없는 놈이라고 낙인찍히지 말고

간단한 예절 숙지해서 

젠틀한 QA 엔지니어가 됐으면 좋겠습니다.

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

다음 Episode로 돌아오겠습니다.

네 번째 에피소드입니다.

실무를 하다 보면 의견이 맞지 않거나, 돌발행동을 하는 사람들을 심심치 않게 볼 수 있습니다.

그때 대부분은 

" 점마 와 이라노?"

이렇게 생각할 겁니다.

하지만!! 우리 긍정적 사고방식을 가지고 있는 QA 엔지니어들은

" 아 그럴 수 도 있겠구나~"

긍정적인 사고방식, 열린 사고방식으로 여러 사람들의 의견을 취합할 수 있어야 합니다.

오늘의 키워드는 긍정, 오픈마인드 입니다.

여기 머리카락이 있습니다.

당연히 머리카락입니다.

그런데 누군가는 스파게티라고 주장을 하고 있습니다.

이해가 가지 않습니다만. QA 엔지니어라면 왜 스파게티라고 주장을 하는지 인터뷰를 진행해야 합니다.

선생님 왜 스파게티인가요?

"제가 봤을 땐, 스파게티가 확실합니다. 왜냐하면 이태리에 한 음식점에서 먹었던 스파게티와 모양이 똑같습니다."

선생님 그러면 저걸 드실 수 있으신가요?

"스파게티이니까 먹을 수 있겠죠."

후루 룹 

네, 그렇습니다.

결국 선생님은 실려가셨습니다.

여기서 우리는 간과했습니다. 우리는 익숙해진 사물에 대해서 충분한 가이드라인을 공지하지 않았습니다.

이런 비상식적인 상황은 비개발자가 포함된 회의에서 발생할 수 돼있고, 종종 CS로 인입되기도 합니다.

왜냐면 우리는 우리가 하는 일에 대해 익숙해져 있기 때문에 간과할 수 있습니다.

그래서 QA는 "그럴 수도 있겠다. 저걸 스파게티라고 생각하는 사람이 있을 수 있으니 사전에 스파게티가 아니라는 것을 알려주는 장치를 심어놔야겠다."

라고 생각을 해야 됩니다.

다시 시간을 돌려서 선생님이 실려 가기 전 상황으로 돌아가 보겠습니다.

선생님 혹시 저게 스파게티처럼 보이시나요?

" 저게요?? 저건 스파게티가 아니라 누가 봐도 머리카락입니다!"

다행입니다.

한 번에 머리카락임을 인지하였습니다.

QA 엔지니어는 항상 오픈 마인드를 가져야 합니다.

위와 같이 왜 저렇게 생각하였을까? WHY에 대한 답을 생각해 내야 합니다.

그렇게 하기 위해서는 긍정적인 사고방식을 가져야 합니다.

나와 다른 의견에 대해서 거부감을 보이기보다 왜 다른 의견을 가지고 있는지 생각해야 됩니다.

충분히 훈련할 수 있습니다.

사소한 것부터 말이죠.

극단적인 예를 들어보겠습니다.

옆자리 신입사원이 지각을 하였습니다.

당연히 ' 신입사원이 벌써부터 지각을 해?'라는 괘씸한 생각이 들겠지만

우리는 긍정적인 사고와 오픈 마인드를 가지고 있는 QA 엔지니어입니다.

" 오늘 조금 늦게 오셨네요. 이유가 있으실까요?"

그러면 신입사원이 이유를 말하겠죠.

"사실 전날 술을 마셔서 늦잠을 잤습니다."

속으론 열이 나겠지만,

"그러면 술을 마시기 전에 컨디션을 드시거나, 알람을 여러 개 맞춰놓으면 늦잠은 안자더라고요"

상황에 대해 공감해주며 대안을 제시해주는 방법으로 이끌어 나가는 것 

긍정적인 사고와 오픈마인드를 가지는 첫 발걸음입니다.

물론 계속되면 얄짤없이 바로 팀장님께 보고합니다. 흐흐흐

사실 긍정적인 사고를 갖는다는 건 내 속이 타들어갈 수도 있는 위험하기도 한 사고방식이기도 합니다.

긍정적인 사고방식이라고 해서 뭐든 다 OK가 아닌 품질을 높일 수 있는 선에서 OK가 되어야 합니다.

즉, 여러 의견을 존중하고 취합하려면 긍정적으로 생각하는 것이 첫 발걸음이 된다고 말씀드리고 싶습니다.

오픈마인드 또한 모든 결함 가능성을 생각해야 하는 QA 엔지니어에겐 필수 능력치입니다.

오픈마인드는 긍정적인 사고방식을 습득하게 된다면 자연스럽게 얻어질 것입니다.

결국 한 단계 더 성장하려면 이렇게 받아들인 의견을 취합해서 설득하고 전달하는 것!

제일 중요하다고 생각됩니다.

위의 스파게티 선생님 예시처럼, 우리는 Web, App을 제작하고 사용자들에게 전달할 때 가이드라인을 제시하는 이유가 있습니다.

사용자들이 편히 사용하라고 가이드라인을 제시하지만, 스파게티 선생님처럼 의도하지 않은 방식으로 사용하는 유저들에게 사전에 장치를 심어놓는 것이죠. 

여러 의견에 대해서 수용할 수 있는 것

그 의견들을 종합해서 낸 결론으로 다른 상대를 설득해야 하는 것

오픈 마인드로 살아가는 것

제가 일하고 소통하는 방식입니다.

오늘은 나와 다른 의견에 대해 

QA 엔지니어는 어떤 역량을 가지고 의견을 대해야 하는지

간략한 예시와 함께 알아봤습니다.

업무를 진행하다 보면  나와 다른 의견에 대해 설득하는 것만큼 힘든 일이 없습니다.

그렇지만 왜 나와 다른 의견을 낸 사람이 그렇게 생각하는지에 대해 알아보기 위해서는

긍정적인 사고방식과 오픈마인드가 필요하다고 강조하고 싶습니다.

그럼 Episode 04 마무리하도록 하겠습니다.

다음 Episode로 돌아오겠습니다.

세 번째 에피소드입니다.

옛 속담 중에 사공이 많으면 배가 산으로 간다는 말이 있습니다.

여러 사람이 저마다 자기주장대로 배를 몰려고 하면 결국 배는 물로 못 가고 산으로 올라간다는 말로 

지시하고 간섭하는 사람이 많으면 일이 제대로 되기 어렵다는 뜻이에요.

그러나 저희는 QA 엔지니어입니다. 산에 올라간 배를 끌고 내려와야 해요.

그래서 직장인들이 항상 품속에 사직서를 들고 다닌다지만, QA 엔지니어는 차선책을 들고 다녀야 됩니다...

오늘의 키워드는 최선과 차선 입니다. 

지금 프로젝트가 산으로 가고있습니다.

거리를 두고 보니 왜 프로젝트가 산으로 가고 있는지 알겠네요.

정작 다른 사람들은 눈에 보이지도 않겠지만요.

아니, 눈에 보이지만 못 본 척하는 것 일수도 있지만요.

왜 내가 참여하는 프로젝트 구성원들은 협력이 아닌 난투를 좋아하는 것일까?

왜 일정 연기에 대한 긴급회의, 리뷰는 항상 누군가가 범인이 되길 바라고 탐정놀이를 할까?

그래서 프로젝트 QA Lead를 하다 보면 인민재판에 끌려가지 않을까... 하는 걱정이 앞설 때가 있어요...

걱정 마세요.

QA 엔지니어는 절대로 싸움에 휘말려서도, 주도해서도 안됩니다.

요구사항을 만족할 때까지 품질향상에 신경 써야 돼요.

선수는 전광판을 보지 않습니다. 하하하

그렇습니다.

카우보이가 되어서 산에 있는 배를 끌어내려서 목적지에 가야 합니다.

이미 예정된 일정보다 늦춰지거나 긴급 이슈가 발생했을 때 QA의 목표는 하나입니다.

요구사항을 만족할 때까지, 일정 수준 이상의 품질이 나올 때 까지 끌고 와야 합니다.

예정된 일정대로 계획대로 흘러간다면 최선책이겠지만

이제부터는 차선책을 생각해야 됩니다.

예를 들어 상황을 부여해보겠습니다.

퇴사율이 높은 회사에서 일을 하고 있는 QA 엔지니어가 있습니다.

요구사항 전달 > 기획 정의 > 개발 > 테스트 > OPEN의 프로세스로 프로젝트를 진행하고 있었습니다.

테스트 단계에서 예상치 못한 기획이슈가 발생했습니다.

테스트 기간을 늘려야 하는데 기획을 정의하는 기획자가 오늘이 마지막 날이라네요.

QA 엔지니어는 눈앞이 깜깜해졌습니다.

이미 예정된 OPEN 일자는 다가오고 있습니다.

주변에서는 프로젝트를 엎어야 한다. 다시 뜯어고쳐야 한다. 누가 책임을 질 것이냐.. 등등 

사공이 많아질 거 같은 기분이 드는데요?

여기서 우리는 어떻게 해야 될까요??

놀랍게도 이 상황은 제가 겪은 실화입니다.

그래서 제가 진행한 방법으로 설명해드리겠습니다.

저는 일단 프로젝트에 참여하는 모든 이해당사자들에게 현재 상황에 대해 공유를 했습니다.

제가 상황 공유를 할 때는 항상 두괄식 표현을 씁니다.

즉 말하고자 하는 핵심 내용을 첫 문장으로 써야 합니다.

상황이 어떻고 누가 나갔으며, 개발이 덜됬고 일정이 부족하다? 

위에서 볼 때는 변명으로 느껴질 수 있기 때문입니다.

그리고 제가 두괄식 표현을 쓰는 이유는 항상 근거가 있기 때문입니다.

저는 차선책을 가지고 있었습니다.

문제가 발생한 기획이슈 부분에 대해 위험성을 먼저 인지하고 있었습니다.

왜냐하면 처음 시도하는 기법이었고, 기존 인력이 아닌 새로운 인력들로 구성된 팀이었기 때문입니다.

그렇기 때문에 저는 타 업체가 만든 유사한 프로그램은 어떻게 동작하는지에 대해 모든 분석을 미리 완료했었습니다.

그렇기 때문에 두괄식 표현으로 결론을 먼저 전달한 다음 그 이후로 설득을 진행했습니다. 물론 100% 근거 있는 자신감으로요.

설득하기 위해서 저는 요구사항에 포커스를 맞췄습니다. 

그다음 현재 우리가 가용할 수 있는 모든 시간과 인력을 동원해서 요구사항을 만족하는 데에 목표를 두고

QA 엔지니어인 제가 이슈가 발생한 부분에 대한 기획을 일부 수정하였습니다.

해당 이슈사항에 대한 해결책과 품질 가이드라인을 이해당사자들에게 전달하였습니다.

그 결과 초기 기획과는 다르지만 결국엔 요구사항을 만족하는 결과물이 나왔습니다.

어떻게 보면 임기응변이거나 운이 좋았다고 할 수 있겠지만 

퇴사율이 높은 회사에서 일을 하고 있는 QA 엔지니어는 항상 차선책을 품고 다녀야 합니다.

그래서 초기 일정에 대한 계획 수립할 때에도 참여하는 인력 외의 유사한 작업을 진행한 인력, history 등 프로젝트에 도움이 되는 정보를 모두 파악하고 있어야 합니다. 

이렇게 글로 쓰면 어렵다고 생각하실 수 있는데

쉽게 말하면 차선책은 소화기 같은 겁니다.

화재가 발생하지 않으면 최선이겠지만, 화재가 났을 경우를 대비해 항상 소화기를 구비하고 있죠?

실무도 똑같습니다.

최악의 상황이 발생하지 않으면 좋겠지만, 최악의 상황을 대비한 해결책은 항상 존재합니다.

문서를 백업해 둔다던지, 작성하던 글을 중간저장한다던지 이런 것들이 차선책입니다.

위험을 인지하는 것 으로부터 여러분들의 차선책은 이미 준비되어있습니다.

당황하지 않는 것, 보이지 않는 긴장을 하고 있어야 하는 것 

제가 일하고 소통하는 방식입니다.

오늘은 예상치 못한 상황에 대해

QA 엔지니어는 어떻게 대처를 해야 하는가에 대해 

간략한 상황설명과 함께 알아봤습니다.

불안, 긴장, 초조 , 압박이 몸을 지배하면 안돼요 ㅠㅠ 

항상 차선책을 생각하는 습관을 가지는 게 좋습니다.

그럼 Episode 03 마무리하도록 하겠습니다.

다음 Episode로 돌아오겠습니다.