💋 인트로
안녕하세요. 우아한테크코스 5기 깃짱입니다.
우아한테크코스 잠실 캠퍼스의 복도에는 회의 준비의 중요성에 대해 말하는 포스터가 붙어 있습니다.
회의 준비를 안 하면 새로운 회의가 생긴다
그렇다면, 회의 준비란 무엇일까요?
이번 포스팅에서는 백엔드 개발자가 회의를 어떻게 준비해야 하는지 저의 지극히 개인적인 프로젝트 경험을 통해 작성해 보려고 합니다.
이 포스팅이 개발자 회의 문화에 도움이 되었으면 좋겠습니다.
💋 효과적인 회의 준비 방법
✔️ 회의 도중에 결정해야 할 사안과 회의 전에 결정할 수 있는 사안을 분리한다.
회의 시간은 한정되어 있고, 모든 사람이 하나의 주제에 집중한다는 것은 사실 생각보다 어려운 일입니다.
회의 전에 결정할 수 있는 사안이 있다면, 미리 결정해서 최대한 회의 시간 동안 안건의 사이즈를 줄이는 것이 성공적인 회의를 위한 가장 좋은 방법이었습니다.
저의 개인적인 경험을 통해서 성공했던 회의와 실패했던 회의를 공유 드리겠습니다.
[깃짱의 회의 절망편]
스탬프크러쉬 서비스 개발 초기에 있던 일입니다. (자세한 이야기는 링크 참고)
서비스를 처음 만들다보니, 팀원들 모두 기획에 참여하고 있었고, ‘많고 다양한’ 서비스를 제공하는 것에 대해 팀원들 모두 욕심이 있었습니다.
우리 서비스는 사장님의 카페 쿠폰에 대한 '개성'을 굉장히 중요시 했습니다. 따라서, 유효기간을 쿠폰에 둘지 스탬프에 둘지, 최대 스탬프의 개수 등 많은 부분에서 최대한 자유도를 주어 사장님이 선택할 수 있는 서비스를 만들고 싶었습니다.
회의를 시작할 때는, 유효기간을 쿠폰에 둘지 스탬프에 둘지, 최대 스탬프의 개수 중 어떤 것에 선택 권한을 줄 지에 대해서 요구사항을 확실히 정하지 않고, 모두 각자가 생각하는 기획에 따라 이야기를 시작했습니다.
안건의 사이즈가 너무 컸기 때문에, 구현을 시작하기도 전에 과도한 추상화를 하게 했고, 엣지 케이스에 대한 고려도 만만치 않았습니다. 당연히 그 회의는 아무것도 결정하지 못한 채 체력 소모만 한 채로 끝나게 되었고, 이후에도 의사소통마다 각자 다른 이야기를 하는 상황이 발생했습니다. 하마터면 개발을 시작하기도 전에 풀이 꺾여 구현하지 못할 뻔 했습니다.
[깃짱의 회의 희망편]
위의 절망편을 통해서, 서비스 기획은 무언가를 만들어서 성공시키기 전에는 최대한 간략하게, 오로지 우리가 ‘해결하려고 하는 문제’만 해결할 수 있도록 해야 한다는 사실을 깨달았습니다.
이번에는 서비스의 사장 모드에서 카페에 방문한 손님 리스트를 정렬해야 하는 요구사항이 생겼습니다. 그리고 정렬 조건 구현 후보로는, 최근 방문순, 방문수 많은 순, 이름 순, 스탬프 많은 순 등 많은 후보가 나왔습니다.
해당 요구사항에 대한 책임을 맡은 저는 깃허브 디스커션 기능을 통해서 먼저 팀원들이 우선적으로 구현해야 한다고 생각하는 정렬 조건을 선정했고, 안건을 축소시켜서 곧바로 ‘정렬’을 위한 ‘구현’에 대한 회의로 바로 다이빙할 수 있었습니다.
✔️ 회의의 안건을 분명히 한다.
회의의 안건을 분명히 하는 것은 당연하지만, 팀원 중 한 명이라도 신경쓰지 않는다면 제대로 이루어지지 않습니다. 회의 시작 전에 정확하게 어떤 의사결정을 해야 하는지에 대해서 명확하게 하는 것이 회의를 다른 곳으로 새지 않게 하는 방법이라고 생각합니다.
아래와 같이, 회의에서 논의해야 할 내용에 대해서 미리 공지하는 것은 생각보다 큰 도움이 됩니다.
✔️ 회의 때 보고하거나, 논의해야 할 이슈에 대해 자세히 설명하는 글을 작성한다.
팀원이 2명 이하라면, 글을 작성하는 것보다 직접 이야기하는 것이 훨씬 수월한 방법일 것입니다. 하지만, 팀원이 3명 이상이라면 모두 한 자리에 모여 논의할 이슈에 대해 이야기하기 어려울 수 있습니다.
각자 현재 할당된 이슈가 있고, 하는 일이 다르다 보니 다른 팀원의 상황에 대해서 곧바로 이해할 수 없을 수도 있습니다. 또한 구두로 전달하다 보면 백엔드의 경우에는 테이블이나 객체의 구조에 대해서 말하는 사람과 듣는 사람이 상상하는 모양이 달라질 수 있습니다.
제가 개인적으로 사용했던 방법은 문제 ‘상황’에 대해서만 굉장히 자세하게 설명하는 글을 작성하는 것입니다. 글 바로가기
때에 따라 더 좋은 솔루션이 나오는 것을 막을 수 있는 가능성은 있지만, 구체적인 방법에 대해서도 생각한 것이 있다면 적어두는 것도 좋았습니다. 해당 부분을 담당한 사람이 가장 그 도메인에 대한 이해도가 높기 때문에 좋은 방법이 나올 수 있기 때문입니다.
아래는 제가 해당 방법을 사용했던 예시입니다. (내용은 이해하지 않으셔도 좋습니다.)
또한 내가 생각한 솔루션이 유효하지 않다는 것을 피드백을 통해 깨닫고 회의 전에 더 많은 솔루션을 떠올릴 수 있어서 좋았습니다.
상황을 미리 공유하게 되면, 회의 자리에서는 해결 방법에 더 몰두할 수 있습니다.
가장 좋은 상황에는, 해당 글을 모두가 읽고 피드백을 주는 것만으로도 회의를 생략할 수 있습니다.
✔️ 회의의 목적은 의사결정과 일정 추정
회의에서 논의할 내용은 대부분 나 혼자 결정할 수 없는 의사결정에 대한 내용입니다. 이외에도 팀의 공통적인 목표를 위해 일정을 정하기도 합니다. 회의의 목적에 대해 기억하는 것이 매우 중요합니다.
각자 생각하는 것이 다를 수 있으니, 의사 결정과 일정 추정에 대해서는 최대한 직설적인 언어로 표현하는 것이 중요합니다.
그래서 그냥 두번째로 하기로 한거지? 와 같이 오해가 있는 말보다는, 테이블을 분리해 JPA의 상속관계 매핑을 포기하고 enum으로 타입 구분을 대체하기로 한거지? 와 같은 명확한 언어를 사용해야 합니다. 또한, 일정추정과 관련해서도 최대한 빨리 할게요 가 아니라, 최소 화요일, 최대 이번주 목요일까지 완료할 수 있습니다. 이후에 데이터 이관을 하면 시간이 맞을 것 같습니다. 와 같이 명확하게 표현하는 것이 중요합니다.
💋 회의에서 결정한 일정을 잘 지키는 것이 다음 회의에 대한 준비
제가 경험했던 우아한테크코스의 프로젝트의 경우에, 2주~3주를 하나의 스프린트로 진행됩니다. 하나의 스프린트 동안의 필수적인 요구사항이 주어지고, 팀 내부적으로도 기획한 내용을 4개의 스프린트에 걸쳐 나누어 구현해야 합니다.
아래에서의 예시와 같이, 해당 스프린트에서 구현할 기능을 구체적으로 결정하고, 해당 스프린트에서 완료하기 위해서 더 작은 단위로 업무를 나누어 생각해야 합니다.
해당 스프린트에서의 할 일을 정리하기 위해서 Github Organization의 issue, milestone 기능을 적극적으로 활용할 수 있습니다.
아래는 우리 팀이 일정을 추정하기 위해서 사용했던 Project입니다. 바로가기
하기로 약속한 작업을 완료하지 못하면 어떻게 될까요?
A에 대한 회의를 진행하고, 이슈를 분배하면서 다음 회의에서는 B에 대해 이야기하기로 했는데, A에 대한 작업을 마치지 못했다면 어떻게 될까요? 다음 회의에서 B에 대해서 논의할 수 없게 될 것입니다.
위에서 말한 모든 방법이 다 무용지물이 될 것입니다.
내가 기한 내에 작업을 완료하지 못할 것 같다면, 변명보다는 상황에 대한 정확한 설명과 함께 팀원들에게 양해를 구해야 합니다. 대응 시간을 늘리기 위해서는 최대한 빠르게 소통하는 것이 중요할 것입니다.
💋 참고자료
도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!
💋 인트로
안녕하세요. 우아한테크코스 5기 깃짱입니다.
우아한테크코스 잠실 캠퍼스의 복도에는 회의 준비의 중요성에 대해 말하는 포스터가 붙어 있습니다.
회의 준비를 안 하면 새로운 회의가 생긴다
그렇다면, 회의 준비란 무엇일까요?
이번 포스팅에서는 백엔드 개발자가 회의를 어떻게 준비해야 하는지 저의 지극히 개인적인 프로젝트 경험을 통해 작성해 보려고 합니다.
이 포스팅이 개발자 회의 문화에 도움이 되었으면 좋겠습니다.
💋 효과적인 회의 준비 방법
✔️ 회의 도중에 결정해야 할 사안과 회의 전에 결정할 수 있는 사안을 분리한다.
회의 시간은 한정되어 있고, 모든 사람이 하나의 주제에 집중한다는 것은 사실 생각보다 어려운 일입니다.
회의 전에 결정할 수 있는 사안이 있다면, 미리 결정해서 최대한 회의 시간 동안 안건의 사이즈를 줄이는 것이 성공적인 회의를 위한 가장 좋은 방법이었습니다.
저의 개인적인 경험을 통해서 성공했던 회의와 실패했던 회의를 공유 드리겠습니다.
[깃짱의 회의 절망편]
스탬프크러쉬 서비스 개발 초기에 있던 일입니다. (자세한 이야기는 링크 참고)
서비스를 처음 만들다보니, 팀원들 모두 기획에 참여하고 있었고, ‘많고 다양한’ 서비스를 제공하는 것에 대해 팀원들 모두 욕심이 있었습니다.
우리 서비스는 사장님의 카페 쿠폰에 대한 '개성'을 굉장히 중요시 했습니다. 따라서, 유효기간을 쿠폰에 둘지 스탬프에 둘지, 최대 스탬프의 개수 등 많은 부분에서 최대한 자유도를 주어 사장님이 선택할 수 있는 서비스를 만들고 싶었습니다.
회의를 시작할 때는, 유효기간을 쿠폰에 둘지 스탬프에 둘지, 최대 스탬프의 개수 중 어떤 것에 선택 권한을 줄 지에 대해서 요구사항을 확실히 정하지 않고, 모두 각자가 생각하는 기획에 따라 이야기를 시작했습니다.
안건의 사이즈가 너무 컸기 때문에, 구현을 시작하기도 전에 과도한 추상화를 하게 했고, 엣지 케이스에 대한 고려도 만만치 않았습니다. 당연히 그 회의는 아무것도 결정하지 못한 채 체력 소모만 한 채로 끝나게 되었고, 이후에도 의사소통마다 각자 다른 이야기를 하는 상황이 발생했습니다. 하마터면 개발을 시작하기도 전에 풀이 꺾여 구현하지 못할 뻔 했습니다.
[깃짱의 회의 희망편]
위의 절망편을 통해서, 서비스 기획은 무언가를 만들어서 성공시키기 전에는 최대한 간략하게, 오로지 우리가 ‘해결하려고 하는 문제’만 해결할 수 있도록 해야 한다는 사실을 깨달았습니다.
이번에는 서비스의 사장 모드에서 카페에 방문한 손님 리스트를 정렬해야 하는 요구사항이 생겼습니다. 그리고 정렬 조건 구현 후보로는, 최근 방문순, 방문수 많은 순, 이름 순, 스탬프 많은 순 등 많은 후보가 나왔습니다.
해당 요구사항에 대한 책임을 맡은 저는 깃허브 디스커션 기능을 통해서 먼저 팀원들이 우선적으로 구현해야 한다고 생각하는 정렬 조건을 선정했고, 안건을 축소시켜서 곧바로 ‘정렬’을 위한 ‘구현’에 대한 회의로 바로 다이빙할 수 있었습니다.
✔️ 회의의 안건을 분명히 한다.
회의의 안건을 분명히 하는 것은 당연하지만, 팀원 중 한 명이라도 신경쓰지 않는다면 제대로 이루어지지 않습니다. 회의 시작 전에 정확하게 어떤 의사결정을 해야 하는지에 대해서 명확하게 하는 것이 회의를 다른 곳으로 새지 않게 하는 방법이라고 생각합니다.
아래와 같이, 회의에서 논의해야 할 내용에 대해서 미리 공지하는 것은 생각보다 큰 도움이 됩니다.
✔️ 회의 때 보고하거나, 논의해야 할 이슈에 대해 자세히 설명하는 글을 작성한다.
팀원이 2명 이하라면, 글을 작성하는 것보다 직접 이야기하는 것이 훨씬 수월한 방법일 것입니다. 하지만, 팀원이 3명 이상이라면 모두 한 자리에 모여 논의할 이슈에 대해 이야기하기 어려울 수 있습니다.
각자 현재 할당된 이슈가 있고, 하는 일이 다르다 보니 다른 팀원의 상황에 대해서 곧바로 이해할 수 없을 수도 있습니다. 또한 구두로 전달하다 보면 백엔드의 경우에는 테이블이나 객체의 구조에 대해서 말하는 사람과 듣는 사람이 상상하는 모양이 달라질 수 있습니다.
제가 개인적으로 사용했던 방법은 문제 ‘상황’에 대해서만 굉장히 자세하게 설명하는 글을 작성하는 것입니다. 글 바로가기
때에 따라 더 좋은 솔루션이 나오는 것을 막을 수 있는 가능성은 있지만, 구체적인 방법에 대해서도 생각한 것이 있다면 적어두는 것도 좋았습니다. 해당 부분을 담당한 사람이 가장 그 도메인에 대한 이해도가 높기 때문에 좋은 방법이 나올 수 있기 때문입니다.
아래는 제가 해당 방법을 사용했던 예시입니다. (내용은 이해하지 않으셔도 좋습니다.)
또한 내가 생각한 솔루션이 유효하지 않다는 것을 피드백을 통해 깨닫고 회의 전에 더 많은 솔루션을 떠올릴 수 있어서 좋았습니다.
상황을 미리 공유하게 되면, 회의 자리에서는 해결 방법에 더 몰두할 수 있습니다.
가장 좋은 상황에는, 해당 글을 모두가 읽고 피드백을 주는 것만으로도 회의를 생략할 수 있습니다.
✔️ 회의의 목적은 의사결정과 일정 추정
회의에서 논의할 내용은 대부분 나 혼자 결정할 수 없는 의사결정에 대한 내용입니다. 이외에도 팀의 공통적인 목표를 위해 일정을 정하기도 합니다. 회의의 목적에 대해 기억하는 것이 매우 중요합니다.
각자 생각하는 것이 다를 수 있으니, 의사 결정과 일정 추정에 대해서는 최대한 직설적인 언어로 표현하는 것이 중요합니다.
그래서 그냥 두번째로 하기로 한거지? 와 같이 오해가 있는 말보다는, 테이블을 분리해 JPA의 상속관계 매핑을 포기하고 enum으로 타입 구분을 대체하기로 한거지? 와 같은 명확한 언어를 사용해야 합니다. 또한, 일정추정과 관련해서도 최대한 빨리 할게요 가 아니라, 최소 화요일, 최대 이번주 목요일까지 완료할 수 있습니다. 이후에 데이터 이관을 하면 시간이 맞을 것 같습니다. 와 같이 명확하게 표현하는 것이 중요합니다.
💋 회의에서 결정한 일정을 잘 지키는 것이 다음 회의에 대한 준비
제가 경험했던 우아한테크코스의 프로젝트의 경우에, 2주~3주를 하나의 스프린트로 진행됩니다. 하나의 스프린트 동안의 필수적인 요구사항이 주어지고, 팀 내부적으로도 기획한 내용을 4개의 스프린트에 걸쳐 나누어 구현해야 합니다.
아래에서의 예시와 같이, 해당 스프린트에서 구현할 기능을 구체적으로 결정하고, 해당 스프린트에서 완료하기 위해서 더 작은 단위로 업무를 나누어 생각해야 합니다.
해당 스프린트에서의 할 일을 정리하기 위해서 Github Organization의 issue, milestone 기능을 적극적으로 활용할 수 있습니다.
아래는 우리 팀이 일정을 추정하기 위해서 사용했던 Project입니다. 바로가기
하기로 약속한 작업을 완료하지 못하면 어떻게 될까요?
A에 대한 회의를 진행하고, 이슈를 분배하면서 다음 회의에서는 B에 대해 이야기하기로 했는데, A에 대한 작업을 마치지 못했다면 어떻게 될까요? 다음 회의에서 B에 대해서 논의할 수 없게 될 것입니다.
위에서 말한 모든 방법이 다 무용지물이 될 것입니다.
내가 기한 내에 작업을 완료하지 못할 것 같다면, 변명보다는 상황에 대한 정확한 설명과 함께 팀원들에게 양해를 구해야 합니다. 대응 시간을 늘리기 위해서는 최대한 빠르게 소통하는 것이 중요할 것입니다.
💋 참고자료
도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!
