*물론 이 글에서 의미하는 회의는 '시간을 들여 논의를 할 가치가 있어 진행되는 대단히 합리적인 회의'를 전제로 합니다.
안녕하세요, 플러터 장인을 꿈꾸는 만 2년 차 주니어 개발자 김삼콩입니다. '회의가 너무 좋다'고 말하는 부사수를 신기하게 쳐다보시는 사수님의 눈빛에서, '나는 왜 회의를 좋아하는가'에 대해 정리해보자는 마음이 들었습니다.
회사에서 늘 '1인분은 해내고 있는가'에 대한 회의가 드는 연차인 주니어 연차분들에게, 저는 주니어 연차에서 팀에 이런 것들을 기여하고 있음을 공유하고자 이 글을 씁니다. 물론 회의가 끝나고 나면 '너무나 의미 없었다'라는 생각이 드는 회의도 있지만, 소모적인 논의들이 오갔던 시간들조차도 백그라운드를 알게 되는 의미가 있다고 생각합니다. 서론이 길었습니다.
회의를 개발 업무에 활용하는 방법
1. 회의록을 통해 커뮤니케이션 비용 줄이기
보통 회의록이라 함은 그 회의에서 결정된 사안들이 주로 기록되는 경우가 많습니다. 혹은 회의록 자동화 도구로 회의의 전반적인 내용들을 기록 및 요약하는 팀도 있을 것입니다. 직접 작성하는 1차적인 목표는 회의 기록을 통해 강제로 집중도를 높이기 위함입니다. 특히 이 회의록을 전사에 공유할 것이라는 목표를 가지고 있으면 집중할 수밖에 없죠.
회의록에는 회의에서 결정된 사항만 적고 끝내지 않고, 기능이 결정되기까지 제기된 여러 시안들과 그 시안들이 fade된 이유들도 모두 적어 놓습니다. 전사 팀원들에게 공유할 회의록이기에, 회의에 참여하지 않은 다른 팀원들도 회의록만 보면 이 기능에 대한 백그라운드를 알 수 있습니다. 저희 조직은 목적 조직인 셀 단위로 움직이기 때문에 언제든 기능의 담당자가 변할 수 있습니다. 누구든 이전 논의를 참조해볼 수 있기 때문에 커뮤니케이션의 비용을 낮출 수 있습니다.
딱히 정해진 회의록 형식은 없고, 회의가 열린 배경과 주요 사안, 그리고 과정, 마지막으로 업무 분담을 적습니다. 결론적으로 이 회의를 통해 누가 어떤 업무를 맡기로 했는지를 정리해두는 것입니다. 물론 회의에 참여한 담당자가 스스로의 업무를 기록하겠지만, 크로스 체크를 할 수 있음과 동시에, 제 스스로가 일의 담당자를 정확히 파악하기 위한 용도입니다. 추후 기능을 개발할 때 회의 때 미처 발견하지 못한 의문점들이 들 때마다 담당자가 누군지 물어물어 찾는 것보다 빠르게 커뮤니케이션할 수 있습니다.
- 회의가 열린 배경
- 주요 사안
- 회의록
- 업무 리스트
2. 기능에 대한 목적성 이해
이 부분이 회의를 좋아하는 이유 중 가장 큰 비중을 차지합니다. 기능이 수정될 때 '왜'라는 목적성을 알고 개발하는 것과 아닌 것에는 큰 차이가 있기 때문인데요. 내가 현재 개발해야 하는 기능이 나에게 오기까지의 백그라운드를 알고 개발하면 많은 장점이 있습니다.
일을 하면서 이 일이 사용자의 어떤 편의를 개선시키는지, 그리고 이 기능이 개발되었을 때 어떤 데이터 지표를 보면 성공으로 정의할 수 있는지를 쉽게 파악할 수 있기 때문입니다. 실제로 기능을 개발하기 위한 업무 리스트 상위에 목적을 작성하고 시작합니다. 주니어 연차 때는 보통 말단의 기능 작업들을 개발하게 되는데, 비록 아무리 작은 기능을 개선하는 작업이라도 목적성을 알고 개발한다면 스스로 '무언가 기여하고 있다'는 성취감과 함께 업무에 대한 동기부여가 됩니다.
- 배경
- 가설
- 성공의 정의
- 기능 개발 업무 리스트
또한 목적성을 이해하고 개발을 한다면, 그 목적성에 벗어난 UX/UI를 거를 수 있습니다. 개발 과정에서는 디자이너가 미처 생각하지 못한 부분을 맞닥뜨리기 마련이고, 해당 UX/UI를 논의할 때 커뮤니케이션하기 좋습니다. 팀이 공통으로 이해하고 있는 목적성이 있기 때문에 여러 선택지가 있더라도 목적에 부합하는 우선순위에 따라 일을 진행할 수 있습니다.
3. 사용자 관점으로 생각하기 연습
주체적으로 기능에 대한 아이디어를 내보일 수 있는 것이 회의에 참석하는 것의 장점입니다. 혼자 사용자의 관점에 대해 생각해봤자 정해진 기획과 디자인에 따라 짜여진 기능을 개발하면 주도적으로 사용자의 관점에 대해 생각하기 어렵습니다. 하지만 아직 개발에 대한 기능 문서가 완벽하게 정리되지 않은 말랑말랑한 상태일 때, 스스로 의견을 제시할 수 있는 것만으로도 사용자에 대해 생각해보는 연습이 됩니다. 또 좋은 아이디어가 있다면 팀에 제시해보고 직접 반영되는 기회까지 얻을 수 있습니다. 주니어 연차 때부터, 사용자 관점으로 연습하고 의견을 제시하는 습관을 지닌다면 좋은 개발자가 될 수 있을 거라 생각합니다.
회의에 회의적인 개발자들이 많습니다. (라임은 노렸습니다.) 물론 개발자의 주 업무는 개발이기에 주 업무가 방해가 되리만큼 잦은 회의는 오히려 역효과가 나죠. 하지만 정말 의미 있는 회의라는 전제하에, 주니어 연차에 계신 분들이 회의를 잘 활용하신다면 좋을 것 같습니다. 개발팀이 아닌 여러 부서와의 커뮤니케이션을 통해 업무 용어에도 친숙해질 수 있고, 큰 플로우를 볼 수 있는 눈이 점차 생기기 때문입니다.
아직 개발을 잘 못한다는 생각 때문에 개발에 몰두하는 주니어 분들이 많습니다. (당사자성 발언입니다.) 그렇기에 회의가 불필요하다는 생각을 많이 하실 수도 있을 것 같아 제가 회의를 활용하는 법을 공유해보았습니다. 혹시 더 좋은 회의 활용법이 있다면 댓글로 달아주시면 감사히 읽겠습니다. 읽어주셔서 감사합니다.
