문성준의 단단해지기

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

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

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

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

다음에 만나요~

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

오늘 제목은 솔직합니다.

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

투명하게 기록한다.

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

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

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

다음에 또 만나요~