회의는 왜 하나요

|

제 입으로 할 말은 아니지만, 저처럼 회의에 불성실한 직장인도 찾기 드물 것 같습니다. 회의가 오래 되면 졸거나 -_- 필기 도구를 갖고 들어가도 별로 쓰는 건 없지요.
뒤집어 말하면 그만큼 쓸모없는 회의가 많다는 얘기도 되지 않을까 (혼자) 위안하고 있습니다.

회의에는 여러가지 목적이 있겠지만, 대충 정리해 보면 다음과 같은 것들이 있겠죠.

  • 개발 진행상황 공유(혹은 보고)
  • 브레인 스토밍
  • 업무 자체를 위해(보고서나 제안서 작성 등)

생각나는 건 저 정도네요.
근데 제가 겪은 바에 따르면 개발자들의 바쁜 시간을 뺏아 가면서 하는 회의 중 70% 이상은 첫 번째 목적인 듯 합니다. 개발에 직접 관여되지 않은 윗선에서 어떻게 진행되는지 궁금하니까 집합을 시키는거죠 -_- 급한 사안이면 급한 사안일 수록...;
혹은 주단위로 하는 정기 회의 같은 것도 이런 범주에 포함될 수 있을겁니다. 그냥 무슨 일 하는지 점검하는 의미가 더 크죠.

브레인 스토밍 목적이라고 해도 그 효과는 크지 않은 경우가 많습니다. 중요 정보는 위에서만 알고 있다가 갑자기 해결책 내놓으라고 실무진들 소집을 한다거나 -_- 의견이 잘 안 나오면 고스톱 방향으로 돌아가면서 말하게 하기도 하지요. 자기 소개 놀이도 아니고...ㅡㅡㅋ

자주 회자되는 얘기지만 잦은 회의로 개발 자체에 안 좋은 영향을 끼치는 경우도 많고요.
회의 내용이 얼마나 잘 공유되고 개개인에게 도움이 되느냐 하는가는 별로 고려가 되지 않습니다. 같은 말을 들어도 서로 다르게 이해하는게 사람이잖아요 -_-; 회의 내용을 모조리 녹음이나 녹화하는 것도 아니지만 한다 하더라도 누가 그걸 다시 볼까요..; 회의록으로 기록해도 아마 보는 사람은 잘 없을텐데...

다른 건 몰라도 개발 진행상황 공유는 프로세스 자동화와 관련된 문제가 아닐까 싶군요.
사실 이건 개발 방법 자체에도 문제가 있습니다. 프로젝트 시작 전에 실컷 요구사항 분석하고 개발 시작해도 문제는 끊이지 않는데 체계적으로 관리되는 건 그나마 잘 되면 버그 리스트 정도죠. 요구사항이 중간에 바뀌고 개발 일정에 차질이 빚어지는 것 등은 그다지 철저하게 관리되지 않는 것이 현실입니다.

이런 폭포수 개발방법론의 대척점에 서 있는 것이 스크럼 개발방법론인데요. 개발 주기를 이터레이션으로 관리하고 요구사항을 백로그 리스트로 관리하는 것등은 개발 프로세스의 안정화에도 중요하지만 더 중요한 것은 '가시적인 개발 상황의 확인'이라고 보여집니다.
매일 갖는 스탠딩 회의는 끝난 일과 할 일만을 확인하고 추가적인 회의 부담없이 15분만에 끝내며 번다운 차트와 백로그 리스트는 현재 개발 일정이 얼마나 지연되는지, 어떤 기능들이 어떤 우선 순위를 가지고 개발 중인지 곧바로 확인할 수 있습니다.
이 정도만 해도 위에서 전체 회의를 소집할 일은 크게 줄어들겠죠.

그럼 두번째인 브레인 스토밍에 관련된 회의는 어떨까요.
개인적으로 이런 회의는 물론 꼭 필요하다고 생각은 하는데요, 조건이 있습니다. 가급적 실무진과 윗선이 섞여서 하는 회의는 피하는게 좋지 않을까 하는 겁니다 -_-
일단 모두 모여서 회의하면 서로의 스키마에 대한 차이가 많이 나기 때문에 그런 부분의 격차를 좁히거나 개발자의 경우라면 개념을 설명하는데 브레이크가 걸리는 경우가 있습니다. 이해 못하는 윗사람이 '그러니까 그냥 이렇게 하면 되는 거 아냐?' 이런 식으로 나오면 미치죠 -_-;
이슈에 대해서는 개발자들끼리 토의하고 개발팀장급 이상과 윗선끼리만 모여서 다시 회의해도 충분하지 않을까요. 바쁜 개발자들 시간 뺏지 말고...ㅡㅡ
그리고 이슈 중 많은 것들은 담배피면서, 혹은 식사하면서 관련된 사람들 두 세명만 모여서 얘기해도 방향이 가닥지어지는 경우가 많습니다.
많은 사람이 모일 수록 각 사람간의 연결고리가 늘어나고 그걸 모두 푸는 것은 불가능합니다. 그리고 결론을 내기 위해 걸리는 시간 또한 기하급수적으로 늘어납니다.

아마 많이들 겪어 보셨습니다. 마라톤 회의해도 결론은 영양가 없는... 그러므로 회의가 모든 사람에게 유용하지는 않습니다. 회의 소집 때 이런 건 전혀 생각하지 않겠죠 물론, 그냥 답답하니까 회의하는 거죠 -_-;

여러 사람이 모여서 회의를 하면 생각 못했던 점에 대해서 누군가가 얘기를 꺼내는 경우는 있습니다. 이런 건 분명 회의의 장점입니다만, 그에 비해 윗사람만을 위한 회의가 잃는 것은 또한 더욱 많지 않은가 생각이 듭니다.
회의는 꼭 필요한 사람들만 모여 필요한 만큼만 최소한으로 하고 시스템을 최대한 활용하는 것이 좀 더 효율적이겠죠.

보고성 회의가 너무 잦다면 스크럼 개발 방식을 도입해 보세요.
저도 안 해 봤어요 -_-;

'Programming Story' 카테고리의 다른 글

기술 교육  (0) 2009.10.01
회의는 왜 하나요  (6) 2009.08.30
Snow Leopard 구입  (3) 2009.08.30
제안서 쓰기  (3) 2009.08.18
Trackback 6 And Comment 6