[프로젝트 진행하기 #4] 회의 진행

프로젝트 진행하기 4탄이다. 이번 포스팅에서는 이제 회의를 어떤식으로 진행하면 좋을까에 대해 다뤄보고자 한다. 회의 부분은 생각보다 글이 짧을 것이다.

 

🗨️ 회의는 대면? 비대면?

본론부터 말하자면 회의는 대면을 강력 추천한다. 물론 비대면으로 회의를 진행하면 장점이 있긴하다. 이동 시간을 줄이고, 직접 얼굴을 마주보면서 하는게 아니다보니깐 피로감도 덜든다. 하지만 내가 느꼈을 때, 비대면 회의는 생각보다 진도가 잘 나가지 않는다. 왜냐하면, 비대면으로 진행하면 팀원들이 딴짓을 할 가능성이 높아져서 의견 소통이 잘 안되고, 의견도 잘 내지 않는다. 또한, 사람이 적으면 괜찮지만, 사람이 6명만 되더라도 굉장히 사운드가 많이 겹쳐서 잘 전달이 되지 않는다. 반대로 대면으로 진행하면 이 사람이 무엇을 하고 있는지 바로 보이니깐 딴짓을 하고 싶어도 하지 못한다. 또한, 결과물을 즉시 보여주고, 그에 대한 피드백도 빠르게 받을 수 있다. 어쨋든간에, 회의는 대면으로 진행하는 것이 훨씬 더 진행이 잘 된다.

 

실제로, 내가 진행했다가 망한 "오늘의 출근" 프로젝트는 회의를 비대면으로만 진행하고, 그 마저도 필요할 때마다 진행했더니 진행도 잘 되지않고 결국 프로젝트는 실패로 돌아갔다. (회의가 꼭 메인 이유는 아니지만...)

 

📜회의 주기와 회의할 내용

회의 주기의 가장 베스트는 매일매일 15분 Daily Scrum을 진행하면서 각자 진행 상황을 체크하는 것이다. 하지만, 솔직히 학생들은 회사처럼 매일 한 장소로 출근하는 것도 아니고, 다들 다른 수업도 있어서 근무 시간도 일정하지 않을텐데 매일 회의를 진행하는 것은 매우 어려울 것이다. 그래서, 나는 주 1회 이상 요일과 시간을 정해서 대면 회의를 진행하면 좋다고 생각한다. 내가 진행한 "이음" 프로젝트는 주 1회 팀원들끼리 모두 모여 회의를 진행하고, 주 1회 교수님께 결과물 내역을 보고하는 시간도 가졌다. 또한, 내가 진행했던 "외국민" 프로젝트는 주 2회 팀원들끼리 모여 회의를 진행하였다. 이렇게 정기 회의를 정하고, 추가적으로 필요할 경우 Discord, Zoom 등을 이용해 비대면 회의 또는 대면 회의를 진행하는 식으로 진행하면 좋다. 일단 팀원 전부가 모이는 정기 회의는 반드시 대면으로 하길 바란다.

 

회의때는 어떤 내용을 어떤 순서로 진행해야할까?

 

1. 각자 한주동안 한 내용에 대한 리뷰 및 진행상황 체크

 

각자 한 결과물에 대해서 리뷰하는 시간을 가진다. 예를 들어, 디자인이면 Figma로 만든 UI를 보여주고 이에 대한 피드백을 받는다. 프론트엔드면 만든 프론트 페이지를 보여준다. 이때, 개인적으로 정말 중요하다고 생각하는 것이 예를 들어 챗봇을 만들었으면, 챗봇을 제작했다는 식으로 뭘 만들었다만 하지말고, 대략적인 작동 원리나 만들면서 고려했던 부분을 팀원들에게 꼭꼭 반드시 공유하길 바란다. 내가 백엔드라고 해서 AI나 프론트엔드의 작동 원리를 모르면 안된다. 왜냐하면 서비스라는 것 자체가 AI, 프론트, 백엔드 등등 여러 분야가 긴밀하게 모여서 운영되는 것이며, 면접에서도 API Rate Limiter는 어떻게 구성하셨어요? 챗봇은 어떤 원리로 작동되나요? 물어보는데 내 분야가 아니라고 모른다고 할 수 없지 않은가? 그래서 대략적인 작동원리와 자신이 고민한 부분에 대해서는 이때 팀원들 전체와 공유하는 것이 매우 좋다.

 

 

또한, 팀장은 위 처럼 노션에 개발 현황 matrix를 만들어서 현재 얼마나 진행되었는지 한눈에 볼 수 있도록 표를 만들면 좋다.

 

2. 회의 안건에 대한 논의

 

팀장은 회의 안건이 있다면 미리 생각해오는 것이 좋다. 예를 들어, 학회 참여 여부에 대한 논의, 특정 기능의 필요성에 대한 논의, 베타 테스트는 어떻게 진행할 것인가에 대한 논의, 특정 기능에 더 필요한 부분이 있는지에 대한 논의 등등이 있다. 추가적으로 1번 리뷰하면서 생긴 안건에 대해서도 이 때 논의하면 좋다. 다만, 여기서 정말 중요한게 회의할 때 다른 이야기로 빠지지 않도록 팀장이 조율해야된다. 예를 들어서, 백엔드가 서킷브레이커 패턴을 어떻게 적용할지에 대한 논의는 여기서 하는 것이 아니다. 이 시간은 디자이너, 프론트엔드, 백엔드, AI 등등 모든 분야의 팀원들이 모이는 자리이니 특정 파트의 자세한 기술적인 내용은 논의 해서는 안된다. 모두가 알아야하고 의견을 주고받을 필요가 있는 것에 대해서만 논의하는 자리여야한다. 왜냐하면, 갑자기 백엔드 기술적인 내용을 논의하면 회의 흐름도 깨지고, 다른 팀원들은 이해하기도 어렵고, 무엇보다도 회의 시간이 너무 길어진다.

 

3. 각자 할 일 분배

 

마지막으로, 다음 회의까지 각자가 해올 일에 대해서 분배하고 회의를 마친다.

 

 

개인적으로 회의할 때 진짜 중요하다고 생각하는 것이 "기록"이다. 왜냐하면, 회의 할 때 의견을 나누다보니 좋은 의견이 나왔는데, 너무 많은 의견이 나오면 100% 일부는 까먹는다. 따라서, 회의록을 작성하는 것이 매우 중요하다고 생각한다. 그런데 회의하면서 자세하게 쓰는 것은 거의 불가능하다고 본다. 따라서, 회의 할 때는 나중에 봐도 떠올릴 수 있을 만큼 간단하고 빠르게 들으면서 쓰는 것이 좋다.

 

 

 위는 이음에서 진행했던 회의록의 일부이다. 위 처럼 키워드나 간단한 문장으로 무슨 이야기가 나왔었지! 떠올릴 수 있게 적으면 된다.

 

이상 회의에 대한 글을 마치겠다.