03. 팀이 성장하는 두 가지 루프

팀에 꼭 필요한 회고 문화 이야기

팀에게 가장 도움 되는 회고는 무엇일까요? 여러 회고를 경험해 보고 최종적으로 더 나은 팀이 되기 위해 꼭 필요한 2가지 회고에 대해 공유합니다.

팀 회고의 필요성

PM은 팀원과 함께 팀의 성장을 주도해야 하며, 또 그 속도가 회사의 성장보다 뒤처지지 않게 신경 써야 합니다. 팀과 조직은 잘못되거나 비효율적인 부분을 인지하고 개선하기로 마음먹었을 때 크게 성장합니다. 그래서 항상 이런 부분을 인지하기 위한 시스템이 필요합니다. 우리는 이 시스템을 ‘회고’라고 말하며 반복되는 실수를 기록하고 다시 재발하지 않도록 방지하는 과정을 뜻합니다.

회고 경험을 기반으로 가설 수립의 실수를 줄이고, 개발 과정의 비효율성을 개선할 때 비로소 뾰죡한 가설과 효율적인 실행력으로 팀과 조직의 성장을 가속화할 수 있습니다.

그럼 어떤 회고의 형태가 가장 적합할까요?

팀의 업무 방식에 따라 다르겠지만, 저희 팀에서는 서비스 개선 결과를 보고 같이 토론하며, 액션 플랜을 정리하는 ‘데이터 리뷰’와 스프린트 개발의 프로세스를 회고하는 ‘디브리프 회의’ 2가지를 시스템화하여 수행하고 있습니다.

1. 데이터 리뷰 : 가설 검증과 넥스트 액션 플랜

여기서는 데이터 리뷰의 how to에 대해서 집중적으로 이야기합니다. 스프린트에서 데이터 리뷰의 배경과 역할이 궁금하시다면 아래 글을 참고 부탁드립니다.

https://brunch.co.kr/@mootae/10

01. 회사에 맞는 스프린트 운영법 찾기

*참고할 사항
데이터 리뷰는 스프린트 개발이 완료되어 기능이 릴리즈 된 후, 3주가 지난 뒤에 팀원 모두가 모여서 진행합니다. 회의의 목적은 가설의 정량적 지표의 달성 여부를 확인하고, 인싸이트에 따라 다음 스프린트의 실험의 액션 플랜을 정리하는 것에 있습니다. 과정을 하나하나 살펴보도록 하겠습니다.

A. PM의 리포트 작성

PM은 회의 직전에 기존에 세웠던 가설을 검증하기 위해 PA툴을 통해 데이터를 분석합니다. 데이터를 분석할 때는 데이터 노이즈를 줄이는 것이 중요합니다. 기간과 세그먼트를 명확하게 구분하고, 그에 따라 코호트를 설정하여 각 세그먼트 별로 개선 전후를 비교합니다. 가설의 실험 지표를 기준으로 달성 여부를 기록하고, 분석 과정이나 결괏값에 대해서 고민해 볼 수 있도록 인싸이트 질문을 작성합니다.

데이터 리뷰를 위한 리포트 중 일부

확인해야 할 데이터의 난이도와 범위에 따라 리포트의 양은 다릅니다. 예상대로 가설이 유효하다면 1장으로 끝나기도 하고, 예상과 다른 결과가 나오거나 엎친데 덮친 격으로 원인까지 파악이 안 될 때는 훨씬 더 길어지기도 합니다. 여기서 결과가 어찌하든 PM은 넥스트 액션플랜과 함께 최종 결론을 정리합니다.

B. 팀원분들의 리포트 피드백

리포트 작성이 끝났으면, 슬렉을 통해 데이터 리뷰 날짜와 미리 리포트를 공유합니다. 팀원들은 공유된 리포트를 꼼꼼하게 스크리닝하고 제가 미처 보지 못한 포인트나 새로운 관점의 의견을 양식에 따라 회의 전에 미리 코멘트합니다. 이 코멘트도 회의 때 토론의 주제가 되며 그 과정에서 서로의 관점 차이를 이해하고, 의견의 합치를 이루게 됩니다.

팀원들의 실제 코멘트

코멘트는 직관적으로 궁금한 사항과, 회의 때 같이 논의하고 싶은 부분 그리고 분석한 지표 이외에 더 보고 싶은 지표가 있을 때 요청하는 부분 이렇게 3가지로 나누어져 있습니다. 이렇게 구분하는 이유는 팀원의 질문 의도를 정확히 파악하고 답변하기 위해서이며, 코멘트를 작성하는 입장에서는 자신의 질문의도를 한번 더 정리할 수 있는 도구가 되기 때문입니다.

C. 데이터 리뷰

회의는 예고된 날짜에 모여, PA툴과 리포트를 보면서 회의를 진행합니다. 주요 가설 검증 결과를 같이 확인 후, 각자의 관점과 의견을 주고받으며 이야기합니다. 회의까지 진행한 후 PM은 회의 내용을 통해 종합적인 인싸이트 도출하고 그 내용을 바탕으로 다음 스프린트 실험에 반영할만한 넥스트 액션 플랜들을 정리합니다. 만약 바로 새로운 가설이 도출되면 백로그 시트에 기록하고 우선순위를 할당해놓습니다. 이렇게 ‘데이터 리뷰’ 과정이 끝나게 됩니다.

D. 마무리

저 개인적으로 어떤 회의보다 이 ‘데이터 리뷰’가 팀워크를 만들어내는 데 아주 큰 역할을 한다고 생각합니다. 이 과정에서 팀원들은 서비스 개선 결과에 대해 서로의 관점과 생각을 인지하게 되며, 이 상호작용을 바탕으로 암묵지가 형성됩니다. 이렇게 서로의 지식이 암묵적으로 동기화되면 넥스트 스텝에 대한 방향성의 합일치가 빨라지고, 큰 실행력이 생기게 됩니다. 또 회의를 넘어, 팀원 개인이 회사의 성장에 어떻게 기여하고 있는지 주기적으로 확인할 수 있는 수단이기도 합니다.

2. 디브리프 회의 : 스프린트 팀에 최적화하기

디브리프 회의는 스프린트 개발 과정의 프로세스에 대해 개선 사항을 이야기하는 자리입니다. 보통 개발 과정에서 다양한 커뮤니케이션과 핸드오프를 거치게 됩니다. PM이 기획서를 작성해 디자이너에게 전달하고, 디자이너가 화면 설계서를 완료하면 개발자분들에게 전달합니다. 이 과정에서 어떤 양식과 문서로 전달되어야 가장 효율적이며, 현재 불필요한 과정은 없는지 이야기하며, 이외에 이번 스프린트 과정에서 미스커뮤니케이션이 있던 상황들을 재조명하여 반복되지 않도록 방지하는 역할을 합니다.

디브리프 회의는 스프린트 개발이 배포된 직후 진행됩니다. 이 회의도 마찬가지로 사전 팀원에게 피드백을 요청하는 문서를 공유하고 다양한 의견이 작성된 뒤 모여서 이야기합니다. 회의 방식은 데이터 리뷰와 비슷하게 진행되기 때문에 생략하고, 여기서는 디브리프 회의를 통해 어떤 개선들이 진행되었는지 사례를 같이 보면서 설명드리겠습니다.

A. 화면 설계서 포맷 변경

제가 처음 PM으로 스프린트를 진행할 때 저희 팀의 화면설계서(Story Board)는 PPT나 문서파일 대신 협업의 편의성을 위해 노션을 사용했습니다. 피그마에서 디자인된 화면을 노션에 첨부한 뒤 하단에 정책, 조건, 동작 등을 화화면과 넘버링하여 정리하는 작성 방식이었습니다. 이에 따라 개발자에게 화면설계서를 핸드오프 할 때, 노션 문서와 피그마 파일 2가지를 전달하게 됩니다.

기존의 화면설계서(노션)

그러던 중 디브리프 회의에서 개발자 한분이 노션 문서와 피그마 파일을 스왑 하면서 개발하는 게 불편하다는 의견을 제시합니다. 개발 경험이 전혀 없는 저는 그 상황을 이해하기 위해 직접 작업 화면을 같이 모니터링하게 되었고, 생각보다 더 많은 창을 동시에 사용하고 있는 걸 확인했습니다. 코드 에디터, 모바일 테스트 화면, 터미널/콘솔 등이 이미 많은 상황에, 복잡한 정책과 조건이 쓰여있는 화면설계서가 추가되고, 거기에 화면의 간격과 레이아웃을 확인하러 피그마로 이동하니, 화면 간 스위칭이 너무 많이 일어나고 있었습니다.

이 부분을 해결하기 위해 팀과 함께 논의하여, 기존의 노션 화면설계서를 모두 피그마로 통일하는 방법을 시도해 보게 됩니다. 이 당시에는 피그마가 지금처럼 파일 내에 텍스트 검색 기능을 제공하지 않아, 위키 역할을 하지 못한다는 의견도 있었지만, 개발자분들의 체감되는 효용이 너무 커서 ‘노션 화면설계서’는 역사 속으로 사라지게 됩니다.

그 이후로도 화면설계서를 통한 미스커뮤니케이션을 줄이고 효율적인 개발을 위한 형태를 추구하면서 계속 저희만의 화면설계서 형태를 만들어 나가고 있습니다.

기획의 디자인과 정책, 조건, 동작등을 모두 한 페이지에서 확인할 수 있는 화면설계서

B. 기획&개발 누락 방지하기

QA를 진행하다 보면, 조건이나 정책 반영이 누락된 부분들을 발견하게 됩니다. 스프린트마다 적게는 1,2개 많게는 4~5까지 빠짐없이 등장하면서, 수정에 많은 시간을 들이고 있었습니다. 사람의 하는 일이라 어쩔 수 없는 부분으로 보고 넘길 수도 있지만, 빈도가 적은 경우에도 분명 발생하는 원인은 있을 것이기에 디브리프 회의에서 해당 원인에 대해 논의했습니다.

결과적으로 화면설계서가 핸드오프 된 이후 수정사항이 제대로 인지되지 않은 경우가 문제였습니다. 이처럼 화면설계서를 핸드오프 한 후에 상황에 따라 정책이나 조건이 변경되는 경우에는 피그마의 화면설계서를 내용을 직접 수정한 후 메신저를 통해 내용을 전달드리거나, 피그마 코멘트 기능을 사용하여 변경 내용을 작성한 뒤 담당 개발자분을 어싸인하게 됩니다.

이후 개발자분이 피그마 알림이나, 슬랙 메신저에를 통해 확인해야 하는데, 피그마 알림에서 내용이 명확하게 보이지 않아 패스되거나, 슬랙을 확인 늦어질 시 다른 메세지에 해당 내용이 유실되고 있었습니다.

해당 문제를 해결하기 위해서는 핸드오프 이후 수정변동 사항만 따로 볼 수 있도록 로그로 쌓여 있어야 하며, 어떤 영향으로 해당 내용이 유실되지 않아야 했습니다. 피그마와 노션 같은 툴을 활용하여 다양 방식을 고민한 끝에 개발자분들이 가장 자주, 직관적으로 들여다보는 메신저 슬랙을 통해 해결책을 찾았습니다.

슬랙에 저희 팀만의 ‘핸드오프’ 채널을 따로 생성한 뒤, 다른 이야기 없이 핸드오프 문서 전달만 가능한 채널로 규정하고, 해당 메세지 시점 이후로 변경된 기획은 스레드를 통해 기록하기로 했습니다. 이렇게 해당 프로젝트 핸드오프 메세지와 수정사항이 스레드로 묶여 있으니, 개발자분들도 누락된 요소가 없는지 체크하기 수월해졌고, 기록과 공유 역할까지 하고 있어 추후 미스커뮤니케이션이 생겼을 때 점검이 가능합니다.

슬랙 '핸드오프' 채널 활용 모습

C. 마무리

과정을 효율적으로 개선하는 방법은 꼭 어려운 기술을 활용한 시스템 구축이 아니어도 충분히 많이 있습니다. 그렇기에 개선이 필요한 상태를 인지하고, 사소한 불편함에 익숙해지는 것이 아니라 개선해야 할 문제점으로 바라보는 것이 더 중요합니다. 그리고 이런 관점은 디브리프 회의 같은 ‘장치’를 활용하면 조금 더 쉽게 성장시킬 수 있습니다.

긴 글 읽어주셔서 감사합니다.

------------

글에 관련해 궁금한 부분이 있으시거나, 커피챗이 필요하다면 언제든지 편하게 이메일로 요청해 주세요.

moo_tae@kakao.com