경영자들은 "우리는 업무 공유가 안돼. 커뮤니케이션이 안돼" 라고 하면서 물리적으로 소통을 증가시키는 방법을 찾곤 합니다.
억지로 회의를 가지게 하고, 영업팀과 개발팀을 옆에 붙여 놓거나, 회사의 파티션의 높이를 낮추는 등의 조치를 취하기도 합니다.
회의시간을 늘인다고, 옆에 있다고 커뮤니케이션이 잘되지는 않습니다. 오히려 잦은 회의는 업무시간만 줄어들고 성격이 다른 부서들이 서로 뭉쳐 있으면 소음 때문에 개발에 방해만 됩니다.
커뮤니케이션은 적절한 프로세스와 시스템을 통해서 해결해야 합니다. 스펙을 작성하고 리뷰할 줄도 모르는데 제품이 어떻게 만들어지고 있는지 공유가 안된다고 한탄할 수는 없습니다. 프로젝트 관리 시스템이 있다면 회사의 모든 사람들이 프로젝트 진행과정을 물어보지 않아도 훤히 알 수 있습니다.
대화는 커뮤니케이션에서 가장 중요한 수단이기도 하지만, 가장 비싸면서 오류도 많고 휘발성입니다. 따라서 커뮤니케이션을 강화하려면 대화의 수단은 줄이고 시스템과 기록을 강화해야 합니다.
체계를 제대로 갖추고 있는 소프트웨어 회사라면 대부분의 업무가 몇 가지의 핵심 시스템을 통해서 이루어지며 대화는 꼭 필요한 경우에만 사용됩니다.
물론 당사자들이 모두 모여서 한번이면 해결 가능한 이슈를 메일이나 다른 수단을 이용해서 여러차례 반복해서 소통을 하는 것은 비효율적이죠. 하지만 반대로 시스템으로 간단히 공유하고 의견을 전달할 수 있는 것들을 만나서 해결하는 것은 더 비효율적입니다.
아직도 문제가 생기면 매일 모여서 회의하고 또 결론이 없어서 다음에 또 회의를 반복하고 정보를 공유하기 위해서 또 회의하고 개발 시간은 점점 줄어들고 이런 상황인가요? 프로세스와 시스템이 필요할 때가 된 겁니다.
'회의 시간을 줄이자'라는 구호는 수도 없이 보고 또 들어왔다. 하지만, 프로젝트에서는 다양한 입장을 갖는 이해관계자가 참여한다. 또한, 대다수는 서로 다른 회사나 부서에 속해 있어, 이해 관계뿐만 아니라 일을 해나가는 방식에 있어서도 많은 차이를 보인다. 한 달 넘게 연속으로 치뤄진 회의가 업무에 부담이 될 즈음, 초보PM 안과장의 머릿속에는 슬슬 회의와 회의 사이의 연관성이 그려지기 시작했다. 생각해보면 무척 오랫동안 회의시간을 효율적으로 쓰려고..
답글삭제프로젝트를 진행하면서 단순 개발자를 벗어나 요구사항을 수렴하는 역할에 이르면 회의를 진행해야 한다. 회의는 요구사항 수집을 위한 인터뷰일 수도 있고, 결과물에 대한 검토가 목적이거나 이슈사항에 대한 결정을 위한 것일 수도 있다. 경험이 많지 않은 팀원들이 회의를 진행하는 것을 관찰해보면 전해줄 수 있는 노하우를 알 수 있다. 후배에게 이를 설명해줄 때 가장 먼저 떠오른 것은 스페인에서 Continuation(?) 설명을 위해 Bruce Tate가 차..
답글삭제최악의 회의는 회의 진행자가 준비한 것을 쭉~ 읽는 경우다. 더군다나 프로젝터를 활용하는 경우 오퍼레이터가 서툴게 되면 신경이 예민해지기도 한다. (내가 성격이 너무 까칠해서 그런가?) 준비한 것을 긴 호흡으로 읽어나가면 우선 회의의 목적이 불분명해진다. 이런 류의 회의는 종종 난상토론을 불러온다. 지루한 연설(?)을 들으면 불만에 찬 참석자들이 이후 결정사항이나 이슈에 대한 논의가 시작되면, 인내의 결실을 찾으려는양 열띈 의견을 내놓는다. 회의 진..
답글삭제제 입으로 할 말은 아니지만, 저처럼 회의에 불성실한 직장인도 찾기 드물 것 같습니다. 회의가 오래 되면 졸거나 -_- 필기 도구를 갖고 들어가도 별로 쓰는 건 없지요. 뒤집어 말하면 그만큼 쓸모없는 회의가 많다는 얘기도 되지 않을까 (혼자) 위안하고 있습니다. 회의에는 여러가지 목적이 있겠지만, 대충 정리해 보면 다음과 같은 것들이 있겠죠. 개발 진행상황 공유(혹은 보고) 브레인 스토밍 업무 자체를 위해(보고서나 제안서 작성 등) 생각나는 건 저..
답글삭제회의에 관한 글http://allofsoftware.net/trackback/140
답글삭제