애자일 개발을 위한 팀 회의 규칙 6가지

회의는 2명 이상이 모여서 특정 주제에 대하여 논의하는 것을 의미한다. 즉 여러 사람이 모여서 이야기 하는 것이기 때문에 최소한의 규칙을 정하지 않으면 결론이 이상해지거나 결론 없이 시간만 소비하는 회의가 될 수 있다. 

작년에 작성한 5가지 방법에 대해서 규칙을 6가지로 확대하였다. 이유는 개발 팀내의 회의에서는 기존 5가지뿐만 아니라 추가적인 규칙이 필요하다고 느꼈기 때문이다. 기존 5가지에 대해서도 불필요한 단어는 삭제하였고 생각이 바뀐 문장에 대해서도 변경하였다.

1. 우선, 회의 참석자들에게 회의 주제와 내용을 미리 공유한다.

 

빠른 회의 진행을 위해서는 진행할 주제를 미리 공유하는 것은 필수적이다. 아무런 준비 없이 회의에 참석하게 되면 논의하는데 시간이 오래 걸린다. 또한 주제를 모른다면 불필요하게 많은 사람들이 참석하게 될 가능성이 있다. 주제뿐만 아니라 "발표 자료"와 "논의 리스트"를 공유한다면 회의 참석 전 미리 생각을 정리하고 올 수 있기 때문에 대화를 이끌어가는데 큰 도움이 된다.

 

 


 

2. 회의를 시작할 때에는 회의 주제와 이유를 설명하고 목적이 무엇인지를 이야기하고 시작하자.


회의의 본론을 이야기 하기전, 회의를 만든 이유를 설명하고 회의를 통해서 얻고자 하는 것을 사전에 공유해야 한다. 3분 정도의 짤막한 설명이라도 상관이 없다. 목적에 맞지 않는 이야기를 계속 하는 사람에게 "난 이래서 회의하는 줄 몰랐다"등의 이야기를 듣게 된다면 허탈감과 감정소비가 본인을 괴롭게 할 것이다. 사실 회의를 망치고 싶은 사람은 아무도 없다. 짧은 워밍업 시간이라도 회의 진행시 모두에게 도움이 될 것이다.

 

회의 참석자 중에서 주니어 개발자 또는 경험이 풍부하지 못한 개발자가 함께 있다면 배경을 공유하라. 능동적인 회의 참석을 유도할 수 있고 성장하는데 도움이 될 것이다.


 

3. 회의 진행시, 회의록을 작성할 사람을 지정한다. 

 

회의록은 꼭 필요하다. 이유는 회의 진행을 하면서 결론뿐만 아니라 논의 과정에서 얻게 되는 깨달음이나 정보들도 개발업무에 도움이 되기 때문이다. 또한 작성된 회의록의 내용들은 결론을 왜 도출해냈는가에 대한 데이터이기도 하다. 회의 결론을 상사에게 설명할 때 논의 과정이 없다면 결론이 왜 그렇게 되었는지 이해하지 못하는 경우도 있다. 회의를 진행하는 사람이 회의록을 적어도 되지만, 어렵다면 한 명을 지정해서 회의록을 작성하도록 시키자.

 

 

4. 용어 정리를 하자.


소통이 안된다고 느껴질 때는 가장 큰 요인은 서로간의 용어 정리가 안되어 있는 경우이다. 서로 같은 단어를 사용하지만 내용이 다르기 때문에 결국 시간을 낭비하게 되고 정신적인 체력을 소비를 하게 된다. 용어는 같지만 다른 이야기를 한다고 느끼는 그 시점에 과감하게 논의를 멈추고 사용하는 용어들의 정의를 서로 공유하고 회의를 다시 진행하자. 

 

본인 스스로도 자신만 알고 있는 용어를 사용하는것이 아닌가를 고민해보자. "코드에서 버그를 발견했다"라고 말해야 하지만 "코드가 복잡하다"와 같이 다른 말을 해버리거나 "코드가 꼬여있다"와 같이 본인이 습관적으로 사용하는 용어를 말하는 경우가 있을 것이다.

 

마지막으로 간단히 설명할 수 있는 것을 본인이 알고 있는 전문용어를 사용하면서 어렵게 이야기할 필요는 없다. 어렵게 설명하는 것은 어린아이도 할 수 있는 일이다. 복잡하고 어려운 것을 쉽게 정리하고 이야기하는 것이 진짜 능력이라 생각한다.

 

 

5. 회의를 마무리할 때에는 해야할 일과 만기일을 정하고 끝내야 한다. 


 

이야기를 하다 보면, 결론없이 회의가 끝나는 경우가 있다. 원래 목적이 무엇이었는지, 회의를 통해 결정된 사항이 무엇인지 회의 마지막에 다시 한번 점검해보자. 열띤 토론을 통해 결정된 결론에 대해서 실제 반영이 안된다면 추후에도 사람들이 열정적인 회의를 하게 될까? 회의에서 해야할 일이 결정되었다면 꼭 만기일을 정하자. 

 

또한 여러가지 이유로 결론이 나지 않을 경우도 있다. 결국 만나지 않게 되는 "다음에"라는 단어보다는 다음 회의 시간을 명확히 정하고 회의를 마무리 해야 한다.

 

 

6. 개발 로직을 이야기할 때에는 시각화 자료를 제공한다. 

 

개발 로직 및 모듈에 대해서 글로만 적어서 준비해오는 경우가 있다. 복잡한 로직을 글을 활용하여 쉽게 정리해오는 것은 특별한 재능이라 생각한다. 하지만 복잡한 로직에 대해서 복잡한 상태로 정리하면 문제가 된다. 물론 문장들 자체는 쉽게 적으려고 노력했겠지만 그 문장들을 읽어가면서 버그가 나올 것을 상상하거나 의존성을 고민해봐야 하는 것은 매우 괴로운일이다. 내가 어려운 걸 글로 정리했으니 상대방도 느껴보는 시간을 갖게하는게 목적이 아니지 않은가? 그런 목적이 아니라면 이해하기 쉬운 시각 자료를 꼭 준비하자. 

회의실에 있는 칠판이나 종이를 활용하는 것도 좋다. 개인적인 생각으로 시각 자료가 있는 것과 없는 것은 회의 시간에 큰 영향을 미친다. 회의에 참석한 사람들이 이해하고 의견을 내는데까지 오랜 시간이 걸리기 때문이다.  

 

 

Tags

Read Next

*

*