회의 진행 방식 개선을 위한 회의 요청

개요

이번 데모데이까지 회의 시간이 많이 줄어들었습니다. 또한 팀원들의 바쁜 스케줄로 인해 + 개인 사정으로 인해 회의 시간 뿐만 아니라 회의 개수도 줄어들게 되었습니다.
회의 개수가 줄어들게 되니, 이번 스프린트 때 이전 회의에서 이야기했던 기획의 고도화된 부분, 상세한 구현사항에 대해 이야기 할 시간이 부족했습니다.

이번 스프린트를 기준으로 이야기해보자면, 장르 카테고리를 만든다! 까지는 전체 회의에서 정해진 내용입니다.
그렇지만 장르 카테고리의 디자인, 장르 카테고리 API 구성, 어떤 장르를 내려줄 것인지, 몇 개의 데이터가 필요할 것인지, 이런 세부사항에 대한 논의를 하는 회의는 없었습니다.

이렇게 세부사항에 대한 회의를 못한 이유가 무엇인지 생각해보았습니다.

세부 사항에 대한 회의를 할 수 없을 정도로 일정 추정을 잘하지 못했다.

장르 카테고리 기능이 일정 추정이 잘 안 된 이유도 있습니다.
굉장히 급하게 정해진 기능이고, 이것저것 할 일이 많아 생각보다 조급하게 구현했습니다.

그러다보니 장르 카테고리를 구현하는 팀원들끼리 임의로 정한 부분들이 많습니다.
급하게 정하다 보니 문서화도 되지 않았고, 고민했던 부분에 대한 정리도 미흡했습니다. 서로 생각날 때마다 고민거리 이야기, 구현 사항 이야기를 하다보니 시간이 낭비되는 부분도 있었습니다. 아마 세부 구현 사항들은 팀원들도 제대로 모를 수도 있습니다. 서로의 싱크에 매우 치명적인 사항이라고 생각합니다.

해결책

문제점은 결정되지 않은 사항들에 대한 회의가 효율적으로, 체계적으로 이루어지지 않았다는 것입니다.
제가 제안하는 해결책은 다음과 같습니다.

회의에서 결정되지 않은 사항들을 우선순위를 매겨 정리합니다.

회의에서 결정되지 못한, 시간이 모자라 하지 못한 사항들을 개인적으로 정리하지 말고 팀 노션에 정리합니다.
팀 노션에 정리된 사항들은 데일리마다 확인하며, 우선순위별로 하나씩 회의를 진행합니다.

결정되지 않은 내용을 픽스하기 위해 필요한 회의들의 데드라인을 정의합니다.

각 회의들은 무한정 그대로 둘 수는 없습니다. 회의들이 반드시 이루어져야 하는 기간을 정하고, 그 안에 논의하는 것을 원칙으로 합니다.

이렇게 하면 놓치는 사항 없이 회의를 효율적으로 진행할 수 있을 거라 생각합니다.

모두가 모여야 회의를 시작할 수 있다.

우리 프로젝트의 병목 지점은 '다 모이면 이야기하자' 라고 생각합니다.
회의가 늦춰지는 이유이기도 하고, 다 모일 수 있는 시간을 정하기가 굉장히 어렵습니다. 시간이 적기도 하고 말이죠.

모든 프로세스를 모든 팀원과 함께, 동기적으로 작업하는 것이 레벨3 때는 싱크도 가장 잘 맞고 적합한 방식이었습니다.
그렇지만 레벨4 처럼 바쁜 상황에서 모든 팀원의 상황을 고려하여 회의 시간을 맞추는 것은 현실적으로 너무나도 어렵다고 생각합니다. 반드시 필요한 세부 회의를 안 할 수도 없는 노릇이구요.

해결책

모두가 모이지 않더라도, 세부 구현에 대해 이야기 할 수 있는 비동기적 기능 개발 프로세스를 제안합니다.

지금처럼 큰 기능을 정하는 회의를 짧게 가져가는 흐름은 그대로 두고, 정해진 기능들을 BE&FE 스쿼드로 각각 나눠서 각 기능의 세분화는 스쿼드의 결정대로 하는 방식을 제안합니다.
이때 정해지는 스쿼드와 기능들은 각 주의 팀원들이 공유한 이번 주에 할 수 있는 일정 추정대로 정합니다.

==Q. 스쿼드로 나뉘었을 때 스쿼드에 속하지 않는 팀원들과 싱크가 맞지 않는 부분은 어떻게 할 수 있나요? ==

A. 각 기능의 세부사항이 픽스되었을 때는 문서로 작성하여 반드시 팀원에게 공유하는 프로세스가 작동해야 합니다. 세부사항이 픽스되었을 때 피드백을 받는 시간은 너무 길어지지 않도록 세부사항 구현이 올라왔을 때 1시간 동안 피드백을 받도록 합니다. 생각해본 상세 프로세스는 다음과 같습니다.

스쿼드끼리의 상세 구현이 정해진 날, 최대한 빨리 슬랙 채널에 상세 구현 사항을 정리하여 올린다. 상세 구현은 두루뭉술하지 않고 정해진 자세한 사항들을 모두 적어서 공유한다.
다른 스쿼드에 속한 팀원들은 반드시 1시간 내에 상세 구현을 읽고 피드백을 남긴다. (1시간 뒤에 제공된 팀원 피드백은 해당 스쿼드에서 의견 기여도를 낮게 책정하는 것으로 간주한다.)
팀원들의 피드백을 반영하고, 반영되지 않은 피드백의 경우 근거를 정리한다. 피드백 반영은 빠르게 이루어져야 한다.
피드백을 반영하여 최종 상세 구현 예정 사항을 슬랙 채널에 업로드한다. 들어가야 하는 내용은 대략 다음과 같다.
1. 상세 구현 사항
2. 반영된 피드백과 근거
3. 반영되지 않은 피드백과 근거
완전하게 정해진 최종 상세 구현에 대해서는 피드백을 더 이상 남기지 않는다.

==Q. BE, FE 의 구현 속도가 다른 경우는 어떻게 하나요?==

A. 보통 구현 속도가 빠른 팀원이 문제가 될 수 있을 것 같습니다. 따라서 시간이 남은 경우에 진행할 수 있는 간단한 Task들을 정리하는 것이 필요하다고 생각합니다.
금방 진행할 수 있지만, 우선순위가 낮은 Task 들을 정리한 뒤, 해당 팀원에게 할당해주면 좋을 것 같습니다.

==Q. 완전히 정해진 최종 상세 구현에 대해 피드백을 남기지 않는 이유는 뭔가요?==

A. 최종 상세 구현에 피드백을 남기게 되면, 계속 피드백이 이어지게 됩니다. 이런 경우 세부 회의를 모두 모여서 하는 것이 더 효율적일 것입니다.
그렇지만 항상 논란이 되는 부분은 정해져 있고, 그 부분에는 정답이 없는 경우가 많습니다.
만약 최종 상세 구현에 대해 추가적인 피드백 혹은 불만 사항이 있는 경우, 다음 스프린트 때 '결정되지 않은 사항' 으로 등록하여 회의하는 것이 좋다고 생각합니다.

==Q. 회의에서 결정되지 않은 사항들은 모두 세부 회의로 취급되어 스쿼드끼리만 이야기하게 되나요?==

A. 아닙니다. 모두의 논의가 필요하다고 생각되는 회의들은 모두의 시간이 맞는 때에 회의해야 한다고 생각합니다.
그러나 이 기준이 매우 모호할 수 있기에, 큼직한 결정이 필요한 경우에만 모두 모이는 것으로 하고, 그 외에는 세부 구현으로 간주하는 방식을 제안합니다.

세부 사항 구현이 늦어진 이유 중 하나 - 각 파트별로 세부 진행 상황 전달이 늦다.

BE, FE 모두 각자 세부적으로 진행된 상황이 전달이 늦습니다.
API 에서 변경 된 사항이 있어도 잘 전달되지 않는 경우도 있고, BE 측에서는 FE 에서 얼마나 기능이 진행되었는지도 알기 힘든 것 같아요.

해결책

각 파트별로 필수적으로 공유해야 하는 사항들을 정하고, 각각의 변경 사항이 빠르게 공유될 수 있도록 즉시 공유합니다.
공유하기 위한 슬랙 채널 shook-개발-패치노트 , shook-prod-패치노트 를 만들어 보았습니다.

BE
- shook-개발-패치노트 에 API 를 공유한다. 기존 API 에 변경 사항이 있다면 함께 기록한다.
- API 공유는 API 가 픽스된 즉시 공유한다. 공유된 API 에 변경 사항이 있다면 수정될 때마다 전달한다.
- 완전히 배포가 완료된 경우,
FE
- 디자인 완료 시 shook-개발-패치노트 에 공유한다. 디자인이 수정될 때에도 함께 기록한다.
공통
- 기능 구현 완료 시, shook-개발-패치노트 에 기능 구현 사항을 공유한다.
- 기능 배포가 완료된 경우, shook-prod-패치노트 에 변경 사항과 함께 공유한다.
- PR 템플릿에 '변경 사항 슬랙 공유 여부' 체크리스트를 추가한다.

추가 - 팀원 간 공유 강화

기능을 구현할 때 어려운 점이 있을 때는 아무리 늦어도 스크럼 때 공유합시다. (가장 좋은 것은 주변에 즉시 알리는 것이지만 힘들 수도 있으니까) 어려운 점을 혼자 해결하는 것보다 함께 해결하는 것이 더 빠르다고 생각해요.
팀과 기능 구현 사항에 대해 불만이 있을 때도 스크럼 때 반드시 말하는 것으로 합시다. 불만사항이 감정회고 까지 지체되는 건 좋지 않은 것 같아요. 물론 스크럼 시간이 빨리 끝나는 것도 중요하지만, 각 파트 간의 싱크가 맞는 게 더 중요하다고 생각해요.
의문 사항, 불만 사항은 스크럼 때는 간단하게 제시만 하고, 자세한 논의는 다음 날 회의로 잡아서 최대 30분 동안 논의해 보는 것으로 하는 건 어떨까요? 불필요한 시간 낭비를 줄이고, 좀 더 효율적으로 회의할 수 있을 것 같습니다.
불만사항 예시
- 너무 할 일이 많다.
- 디자인 너무 어렵다.
- 내가 맡은 일이 다른 스쿼드에 비해 너무 많은 것 같다.
- 내가 할 게 없다.
- 내가 맡은 부분이 그렇게 중요하지 않은 것 같다. 다른 일 없나요

제가 항상 이런 민감한 사항에 대해서 회의 안건을 내게 되어 팀원들에게 어느 정도 미안한 마음이 있습니다. 우리 팀 중에 특정 팀원을 탓하는 게 절대절대 아니라는 점, 언제나 회의 안건은 S-HOOK 을 위해 제안하는 것이라는 점 알아주시면 감사하겠습니다 🥺

저는 이런 문제들은 분명 정책적으로, 팀 문화적으로 해결할 수 있다고 생각해요.
이 회의도 우리 팀의 행복한 개발 생활에 도움이 되기를 (간절히) 바랍니다.

비고

해당 회의 / 안건 / 제안에 대한 비판, 불만, 칭찬, 개선점, 뭐든 좋습니다.
추가적인 의견이 무엇이든 있으시다면 남겨주세요 :)