Table of Contents
팀이 단기 목표를 빠르게 달성하기 위해서 고민 했던 것들
- 부제 - 함께 가면서도 빨리 가는 방법들을 위한 고민
흔히 ‘빨리가려면 혼자가고, 멀리가려면 함께 가라’는 격언이 있다. 하지만 새로운 팀을 꾸리면서 빠른 시간 안에 목표를 달성해야 하는 상황에서는 어떨까? 멀리 가는 것보다, 일은 함께 해야하는데 빠르게 결과를 내는 방법에 대해 고민하게 된다. 나의 경우에는 신규 TF에 참여하게 되어 빠르게 결과를 만들어내야만 하는 상황에 놓인적이 있었었다. 그 때의 경험을 돌이켜보며 ‘함께 빠르게 가기 위한 고민들’을 정리해보았다.
배경 - TF 상황
몇년 전에 회사에서 TF로 발령을 받아서 새로운 사람들과 프로젝트를 진행해야했던 순간이 있었다. TF는 사전적 의미로 ‘어떤 과제를 달성하기 위해서 필요한 전문가들로 구성되고 기한이 정해진 임시조직’ 이라는 의미다. 해당 영역의 전문가로 선정된(!) 것은 감사했지만, 기한이 촉박하고 전혀 안면이 없었던 분들과 일을 해야해서 상당히 도전적이었던 상황이었다.
당시 백엔드 개발자는 나를 포함해 2명이었는데 촉박한 기한내에 목표를 달성할 수 있을까? 하는 우려가 있었다.
모두들 도전적인 과제에 대해서 걱정하던 순간에 당시 TF 리더분께서 목표 달성을 위해서 정해야할 것들을 정리해서 공유해주셨었다. 그 때는 너무나 당연하게 지나갔었는데, 돌이켜보면 그런 정리가 없었다면 기한내에 프로젝트를 달성하기 어려웠을꺼라는 생각이든다.
이후에 ‘함께하면서도 빠르게 움직이기 위해서 어떤 것들이 필요할까‘에 대한 고민들이 이어졌다.
질문 - 함께 가면 멀리 갈 수 있지만, 왜 빨리가기는 어려울까?
격언에서 직접적으로 말하지 않았지만, 함께 가면 상대적으로 속도가 늦어질 수 밖에 없다. 그렇다면 그 이유는 무엇일까? 왜 팀으로 일 할 때는 개인의 속도보다 더 느려질 수 밖에 없을까?
첫 번째로 생각해 볼 것은 커뮤니케이션 비용이다.
팀으로 일할 때는 개인이 모든 결정을 스스로 내릴 수 있는 상황과는 달리, 여러 사람이 협업하는 과정에서 수많은 결정 사항들이 발생한다. 이는 단순히 ‘같이 한다’는 것에 그치지 않고 다양한 커뮤니케이션을 위한 시간들이 필요하다.
- 아이디어를 논의하고 의견을 교환하는데 필요한 시간들
- 회의를 통해서 합리적인 방안을 도출하는데 필요한 시간들
- 문제 발생시 이를 해결하기 위한 논의 시간들
결과적으로 혼자 일할 때보다 팀 단위로 일을 진행하면 당연히 더 많은 시간과 노력이 필요하게 된다.
심한 경우에 이렇게 필수적으로 발생하는 커뮤니케이션의 코스트로 인해서 단순히 개인의 합보다 조직의 성과가 낮아질 수 있다. 그렇기 때문이 이를 방지하는 것이 중요하다.
두 번째로 생각해 볼 것은 의사결정 구조이다.
협업하는 과정에서 다양한 문제가 발생하는 것은 자연스럽기 때문에 이를 해결하기 위해 무수히 많은 크고 작은 의사결정들이 필요하다.
이런 의사결정을 누가 어떻게 해야하는지 정해지지 않는다면 이를 위한 시간이 또 다시 필요하기 때문에 명확한 R&R(Role & Responsibilities) 정리가 필요하다.
- 누가 어떤 역할을 해야하는지 명확한 기준이 필요하다
- 그럼에도 기준 적용이 애매한 사항들이 발생하는데 이를 누가 어떻게 결정할지 정하는 프로세스가 필요하다
- 그리고 이런 논의과정들을 어떻게 진행할것인지 정해야한다.
세 번째로 생각해 볼 수 있는 것은 멤버들간의 연결 관계이다.
위의 두 가지가 모두 잘 정해진 프로세스가 정해져 있고, 낮은 커뮤니케이션 비용을 위해서 협업 구조가 잘 설계되어 있다고 하더라도 결국에 일을 진행하는 것은 사람과 사람이다.
그래서 일을 실행하는 멤버들이 서로 신뢰를 유지할 수 있고, 연결이 수월한 분위기를 형성하는 것이 중요하다. 특히 다양한 배경과 역할을 수행하는 구성원들이 모여서 일을 하는 경우
각자가 맡은 역할이 서로 연결되는 구간들에서 잦은 이견이 발생하는데 이를 잘 관리하는 것이 중요하다.
일을 시작하기 전에 정해두기
만약 협업 과정에서 발생하는 결정 사항들을 미리 명확하게 정리해둘수 있다면 어떨까? 팀이 일을 시작하는 시점에 이미 중요한 결정들이 내려져 있다면, 불필요한 논의나 커뮤니케이션에 소요되는 시간을 크게 줄일 수 있다.
이렇게 하면 팀원들은 본연의 업무에 더 집중할 수 있고, 결과적으로 ‘함께 가면서도 빨리’ 목표를 달성할 수 있게 된다.
이전의 경험을 되짚어보며 일을 시작하면서 정했던 항목들을 나열해보았다.
일을 시작하기 전에 결정한 중요한 사항들
- 업무 진행 방식
- 각각의 출퇴근시간, 재택여부등 확인
- 체크인 문화 (업무 시작을 동료들에게 알리는 방법)
- 동료의 업무 스케줄을 어떻게 확인하게 할것인지? (구글 캘린더등)
- 메인 커뮤니케이션 도구는 무엇인지
- 슬랙을 주로 사용하긴 하지만, 외부와의 커뮤니케이션에서는 사용하기 어려울 수도 있어 메일이나 다른 수단도 정해두기
- 문서의 관리 방법은 어떻게 할지?
- 위키나 노션
- 문서를 작성하는 방법과 트리
- 이에 필요한 링크 모음 및 권한 설정
- 업무 진행방식
- 스프린트 or 칸반과 같은 업무 진행방식
- 이슈 등록방법, 템플릿, 상태관리 기준을 마련한다.
- 정기 일정
- 데일리 스크럼을 할지 말지, 한다면 어떠헥 할지
- 위클리와 같은 정기 일정이 있는지
- 개발 환경
- 주요 개발언어
- CI/CD 환경
- 각종 인프라 도구 관리방법 및 필요시 신청 방법
- 배포, 릴리즈 절차
- 테스트를 어떻게 할것이며 어떤 주기로 할것인지
- 개인 일정 확인
- 프로젝트 예상 기간 안에 개인 스케줄이 있어서 참고가 필요한 사항들이 있을지
- 협업 동료와의 의사결정 공유 방식 논의
- 역할별 구분/의사결정이 필요할 때 공유 방식 논의
- 외부 자원(일적, 물적) 확인 방법
위와 같은 사항만 명확해도 업무를 진행하는데 큰 문제는 없을것 같다. 이 목록은 내가 TF에 참여하고 리더분이 정리해준 내용에 몇가지를 덧 붙이면서 계속 활용하고 있는 내용들이다.
더 빠르게 하기 위해서 고민들
정확한 프로세스와 의사결정 구조, 그리고 낮은 커뮤니케이션을 위해서 준비한 사항들이 잘 동작하더라도 연결 구간에서 시간이 소모되기 쉽다. 그래서 구성원들 사이의 연결 구간을 빠르게 하기 위해서 고민하고 다양한 아이디어들을 도입해보았었다.
랜덤 티타임 - 조직의 분위기 만들기
연결 구간의 중요한 부분 중 하나는 팀워크 분위기 형성이다. 나의 경우에는 신뢰가 형성되기 쉽게 하기 위해서는 ‘뭘 많이 먹어야 분위기가 부드러워진다’는 생각으로 “랜덤 티타임” 이라는 제도를 운영했었다. 구성원들이 각각 다른 역할을 가지고 있어 나의 관심도가 떨어질 수 있는데 이를 방지하고 서로의 친분을 쌓게 하기 위해서 강제로(?!) 맛있는 걸 먹을 수 있는 기회와 시간을 마련해서 팀워크를 다지게 만드는 프로그램이었다. (프로젝트 회고에서 가장 만족도가 높았던 프로그램)
이런 활동들이 팀워크를 형성하는데 도움을 주고, 심리적 안정감으로 이어질 수 있게 해준다고 믿는다.
문제가 발생할 땐 언제나 ‘진실의 방으로’
프로젝트가 진행될 때, 무언가 막히거나 문제가 발생할 때 도움이나 논의가 필요한 순간들이 있다. 이를 빠르게 해소하는 것이 팀의 속도를 높일 수 있다고 생각해서 ‘진실의 방’이라는 고정된 구글밋을 운영했었다. 구성원들의 어느 누구라도 ‘도움이 필요해요’ 라고 슬랙 채널에 외치고 진실의 방에서 보자고 하면 누구든지 참여해서 도와주고 문제를 해결하기 위해서 도와주는 방법이다.
이 제도가 유용했다고 느끼는 순간들은 회의를 위해서 별도의 회의실을 잡는다던가, 스케줄을 확인하는 과정없이 바로 즉시 문제를 공유하고 논의할 수 있었기 때문이었다. 물론 사전에 이런 방법들에 대한 공지와 누구나 도와줘야 한다는 합의가 있었다.
기술적으로 서버-클라 연결 구간에 대한 컨벤션 미리 정해두기
당시 나는 백엔드 엔지니어의 역할을 수행하고 있어서 서버-클라이언트의 연결구조를 논의하고 프로젝트 시작과 함께 문서로 정리해두었었다. 이런 부분들도 고민하는 시간을 줄여주어서 도움이 되었었다.
- API Spec 및 컨벤션
- 서버와 클라이언트 간의 소통을 위한 명확한 API 스펙과 이를 관리하는 방법 그리고 코드 컨벤션을 정했었다.
- 이런 내용들은 협업 시 혼란을 줄이고, 개발 속도를 높이게 해주었다.
- 예를 들면
- REST API 에서 object 데이터를 반환하는 경우 그 형식이 데이터의 property 를 그대로 flatten 하게 내려보낼 것인지 / 아니면
item이라는 객체 안에 담아서 내려보낼 것인지 - 객체들 사이의 Relationship 을 표현할 때 nested 구조로 할것인지 property 로 할 것인지
- list 형식의 응답을 반환할 때 “items"라는 collection 으로 wrapping 할 것인지 의미에 맞게 다른 이름으로 반환할 것인지와 같은 것들이다.
주기적인 리뷰로 빠른 피드백 사이클 가지기
프로젝트를 수행하면서 결과를 완벽하기 예측하기는 당연히 어렵다. 모두가 같은 생각을 하고 있지 않기 때문에 이를 정기적으로 점검하고 더 나은 결과물을 위해서 협의하는 과정들이 필요했다. 그래서 정기적인 리뷰 시간을 가지고, 여기에서 나온 의견을들 바탕으로 더 나은 결과물을 만드는 과정들이 중요했었다.
결국 빠른 피드백 사이클을 가지는 것이 전체 결과물의 퀄리티를 높이는데 도움이 되었었다.
결론
“함께 가면 멀리 간다”는 격언이 여전히 유효하지만, 팀으로 일을 진행하면서도 빠르게 목표를 달성하기 위해서 적절한 고민들과 잘 협의된 준비가 있다면 충분히 목표를 달성할 수 있다고 믿는다. 핵심은 바로 ‘고민을 하지 않게 만들기’ 라고 할 수 있다. 팀으로 일을 하는 과정에서 무수히 많은 순간의 멈춤들이 발생할 수 밖에 없는데, 사전에 정해둘 수 있는 것들은 최대한 사전에 결정해놓고 만약 문제가 발생하면 이를 어떻게 논의하고 결정할지 프로세스를 명확하게 만듦으로써 함께 일하면서도 빠르게 갈 수 있다. 는 확신이 들었다. 당시 내가 있었던 TF는 3개월만데 제품을 만들어서 사용자들에게 선보였었는데, 주변에서 다들 놀라워 했었던 기억이 난다.
개인적인 경험을 기반으로 하지만, 커뮤니케이션 비용을 낮추기 위한 제도들, 명확한 프로세스, 결정을 위한 구조, 연결을 강화하기 위한 다양한 활동들이 뒷받침된다면 혼자서 빠르게 달리는 것 못지않게, 팀 전체가 빠른 속도로 일을 마무리할 수 있을 것이다.
comments powered by Disqus