주니어의 회고 방식

요즘 IT 직군에서 일을 한다면 아니 요즘에는 애자일, 스크럼 등 이런 단어들을 많이 접하게 되고 실제로 일하는 방식에 녹아져 있습니다.
오늘은 제가 스타트업에서 근무하면서 제가 진행했던 회고에 대한 방향성과 실행 경험을 공유하고자 합니다!

 

🎉 회고는 즐거워

제가 근무했던 곳 모두 스프린트가 끝나면 해당 스프린트에 대한 회고를 진행을 했었습니다.

사실 저는 스프린트 회고 하는 날이 너무 좋았어요

왜나면 그날은 맛있는 음식을 먹고 다들 좋은 이야기를 하는 시간이었거든요

그래서 다를 점심에 맛있는 음식을 먹으며 다들 고생했고 이번 프로젝트 진행하면서 이런 부분들이 너무 좋았다. 다음 스프린트도 잘 진행해 보자는 식의 말이 지나고 다들 즐거운 식사를 하는 자리였습니다.

출처 : 무한도전

 

 🤦‍♂️ 회고는 어려워

그렇게 스타트업으로 이직하고 제품 릴리즈 후 팀원들과 회고하는 자리를 가지게 되었습니다.

저는 즐거운 마음으로 팀원들과 함께 미팅룸을 들어가고 회고를 진행하게 되었죠

그런데 이전에 진행했던 방식과 사뭇 다른 느낌이었습니다. 분위기가 무겁지는 않았지만 내용들이 무거웠고

어떠한 문제들이 있었고 원인들을 찾는 자리였죠.

당연히 저는 여기서 이런 식의 회고를 처음 진행하게 되니 문제점들을 찾는 게 어려웠고 제가 찾았던 문제점들은

자아비판적인 내용들이어서 스스로 힘들었고 팀원들에게도 좋은 피드백을 받지 못했죠

 

하기 싫으면서 고민되면서 어렵고 하기 싫은 나

🤷‍♂️ 무엇이 문제였지?

사실 처음 제가 느낀 회고는 일종의 일기장 같은 느낌이었습니다.

"나는 오늘 무엇을 했는데 이걸 잘하지 못했다. 못한 이유는 내가 이런 성격이라 좀 느렸다."식의 회고 방식이었죠

회고의 목적은 더 잘하기 위해서였는데 어느 순간 반성문을 쓰고 있으니 잘 돌아갈 수 없었죠..

스프린트 회고의 목적과 뜻을 온전히 이해하지 못한 채 회고를 진행했던 것이죠..

 

💡 문제의 관점을 사람이 아닌 프로세스로 바꿔보자!

그래서 저는 여러 피드백을 받으며 진행했던 노력 중 하나가'회고에서 사람을 빼고 프로세스를 보자'였습니다.

예를 들어 이번 릴리즈에서 아쉬운 점은 'QA Sign-Off 가 늦어졌다'라고 한다면

 

AS-IS (이전 나의 방식)

• 원인 : 테스트를 진행하면서 개발자에게 요청이 필요한 데이터들이 있어 개발자에게 요청하느라 진행속도가 늦어졌다
• 다음 스프린트에서는 미리 체크해서 놓치지 않고 빠르게 진행해 보자

TO-BE (바꾸려 했던 방식)

• 원인: 테스트 데이터를 만들기 위한 시간을 고려하지 못했다.
• 다음 스프린트에서는 기획 리뷰 단계에서 개발자에게 테스트 데이터를 요청해야 하는 것이 있는지 체크하는 단계를 추가하여 미리 준비한다.

아주 간략한 예시입니다..ㅎㅎ

이렇게 회고에서 사람을 최대한 빼려고 하다 보면 자연스레 업무 방식에서 개선해야 할 부분들이 있는지 보이게되어 진정한 회고에 한 발짝 다가가게 되었던 일이 있었답니다. 물론 지금의 방식이 완성은 아니지만 조금씩 바꾸다 보면 좋은 회고가 이루어지지 않을까요? ☺️