레이블이 회의인 게시물을 표시합니다. 모든 게시물 표시
레이블이 회의인 게시물을 표시합니다. 모든 게시물 표시

2020년 9월 18일 금요일

진짜 비대면 업무 방식 vs 가짜 비대면 업무 방식

 최근 코로나 19 때문에 비대면 업무 방식으로 전환이 강하게 요구되고 있다. 그러면서 비대면 업무 방식을 많이 추진하고 있는데, 가짜 비대면 업무를 하고 있는 회사도 많다.

비대면 업무 방식은 생산성이 높기 때문에 코로나 19가 아니더라도 도입이 권장된다. 그러면 진짜 비대면 방식으로 일하고 있는지, 가짜 비대면 방식으로 일하고 있는지 9가지 지표로 알아보자. 


툴, 시스템


재택근무를 도와주는 솔루션만 도입했다고 진짜 비대면 업무를 하는 것이 아니다. 

가짜 비대면 업무를 하는 회사는 몇 가지 특징이 있다. 완전한 비대면 업무 방식으로 일하기 위해서 필요한 시스템과 툴을 충분히 도입하지 않아서 여기 저기 구멍이 있는 경우다. 그래서 수시로 메신저나 이메일로 업무를 물어봐 가면서 처리하고 시스템을 따라 업무가 유기적으로 진행되지 않는다. 

또, 부서마다 사용하는 툴이 다른 경우도 있다. 진짜 비대면 업무를 하기 위해서 가장 중요한 시스템이 이슈 관리 시스템인데, 이것을 부서마다 다른 것을 쓰거나 일부 부서만 사용하는 경우다. 그러면 업무 협조 시 상황에 따라서 써야 하는 시스템이 달라서 매우 번거롭고 업무가 물 흐르듯 흐르지 않는다.

하지만 진짜 비대면 업무를 하는 회사는 필요한 시스템과 툴이 촘촘히 잘 구축되어 있고, 서로 연동이 잘 되어 있고, 모든 직원이 동일한 시스템을 쓰며, 내재화가 잘 되어 있다. 그래서 업무가 매끄럽게 흘러가고 한 두개의 대시보드에서 자신의 업무가 다 모니터링 되고, 관리자는 부서의 업무를 한눈에 파악할 수 있도록 되어 있다.

대부분 들어본 시스템과 툴이지만 전사적으로 제대로 구축하여 잘 쓰는 것은 매우 어렵다.


문서 관리


비대면 업무 방식을 주장하면서 문서를 개별 PC에서 작성해서 이메일이나 메신저로 서로 주고받으면서 공유하고, 관리를 하고 있다면 가짜 비대면 업무를 하고 있을 가능성이 높다.

또는 문서 공유 시스템을 쓰기는 하는데, 부서별로 서로 다른 시스템을 사용해서 타부서와 문서를 공유할 때는 이메일이나 메신저 등으로 파일을 전달하는 경우도 있다.

진짜 비대면 업무를 하려면 전사의 모든 문서를 하나의 문서 관리시스템에서 체계적으로 관리하고 있어야 한다. 물론 부서별 업무별로 권한 관리를 잘하여 보안 상으로도 문제가 없어야 한다.

문서의 작성, 협업, 리뷰, 관리, 공유 등 모든 작업이 하나의 시스템으로 관리가 되어야 효율적인 비대면 업무를 할 수 있다. 


문서 작성 역량


비대면 업무를 제대로 하기 위해서는 문서 작성 역량도 매우 중요하다.

문서를 많이 작성해야 한다는 의미는 아니다. 대면 업무 방식에서는 문서의 내용이 부족하면 수시로 옆에서 물어가며 일할 수 있지만 비대면 방식에서는 그렇게 하기 곤란하다.

기획 문서, 스펙 문서, 설계 문서 등 여러 종류의 문서들이 문서만 가지고 충분히 내용을 파악할 수 있어야 한다. 100%는 불가능하지만, 80~90% 문서로 충분히 내용을 전달할 수 있는 역량을 가지고 있어야 한다. 물론 이런 문서도 문서 관리시스템에서 협업과 리뷰를 통해서 만들어지므로 잘 작성될 가능성도 높아진다.

가짜 비대면 업무를 하는 회사는 문서를 가지고 일하기 어려워 일할 때 커뮤니케이션이 너무 많이 필요하다. 그래서 옆에 앉아서 같이 일하기를 원한다. 예를 들어 소프트웨어 회사에서 외주를 줄 때 스펙 문서를 기반으로 외주를 주지 못한다. 대략의 기획 문서를 기반으로 외주를 준 후에 요구대로 소프트웨어가 개발이 잘 안되니 옆에 끼고 설명을 해주거나 나중에 프로젝트 일정이나 품질에 문제가 생기는 것이 다반사다.

진짜 비대면 업무를 하기 위해서는 직원들이 모두 말보다는 문서 위주로 일하기 때문에 문서를 제대로 작성할 수 있는 역량이 필요하다. 그래서 채용 시 글을 잘 쓰는 사람을 뽑기도 하고, 직원들에게 글을 잘 쓰고 문서를 잘 작성하도록 교육할 필요가 있다.

물론, 비대면 업무를 계속 하면서 문서 작성을 계속 하고 리뷰를 거쳐 피드백을 많이 받게 되면 누구나 문서 작성 역량이 조금씩은 향상된다.


보고


진짜 비대면 업무를 하는 회사는 별도의 보고가 많이 줄어든다. 또한 보고를 위한 보고는 보기 어렵다.

별도의 보고가 따로 필요하지 않은 이유는 촘촘하게 커버되는 시스템에서 업무의 진행 상황을 훨씬 더 자세히 파악할 수 있기 때문이다.

직원들도 별도의 시간을 들여서 보고서를 작성하지 않고 본연의 업무에 더 많은 시간을 쏟을 수 있다. 

하지만, 가짜 비대면 업무를 하는 회사는 업무는 업무대로 다하고, 일일보고, 주간보고 등 여러 형태로 보고서를 작성해서 보고를 해야 한다. 보고 방식은 온라인이라 할지라도 낭비요소가 아닐 수 없다. 

관리자는 또 상위 관리자에게 보고를 하기 위해서 직원들의 보고를 취합하여 또 보고를 한다.

보고를 줄이는 것은 진짜 비대면 업무 방식의 증거이자 혜택이다.


화상 회의 빈도


가짜 비대면 업무를 하는 회사는 형식만 비대면이지, 수시로 화상 회의를 실시하여 대면 업무 방식과 별 차이 없이 일한다.

화상 회의는 실제 만나서 얘기하는 것보다는 전달성이 떨어지지만 이동하지 않고 커뮤니케이션을 할 수 있는 장점이 있는 것이다.

하지만 화상 회의를 너무 자주 한다면 차라리 모여서 일하는 것이 더 효율적이다.

회상 회의를 해야 하는 안건이 대부분 이슈 관리 시스템이나 여러 시스템에 온라인으로 등록되고 프로세스를 따라서 처리되며 화상 회의는 꼭 필요할 때 최소화해서 해야 한다. 그래야 진짜 비대면 업무 방식으로 일한다고 할 수 있다.

회상 회의도 비싼 수단이다. 하루의 10~20% 넘는 시간을 화상 회의에 사용하고 있다면 일단 의심을 해보자.


회의 결과 관리


가짜 비대면 업무를 하는 회사는 회의도 자주 하지만 회의 기록이 없거나 회의 결과 해야 할 업무의 추적이 잘 안된다.

그러고는 한참 있다가 “지난 번에 내가 시킨 일 어떻게 되고 있지?”하고 묻는다. 전형적인 대면 업무 방식과 다를 바가 없다.

회의를 자주하는 것과도 관련이 있다. 회의를 계획하에 하지 않고 수시로 소집하기 때문에 회의록도 제대로 남기지 않고 후속 관리도 잘 안된다.

진짜 비대면 업무를 하는 회사에서는 회의 빈도도 적을 뿐만 아니라, 필요한 회의는 미리 계획이 되어 있고 회의 결과가 제대로 정리, 공유되어 있다. 또한 회의 결과로 인해서 해야 할 일은 회사의 온라인 시스템에 등록되어 실시간으로 추적이 된다. 

회의록만 보아도 후속 업무의 처리 현황을 실시간으로 볼 수 있도록 시스템이 구축되어 있기도 하다.

예를 들어 소프트웨어 회사의 경우 유지보수를 위해서 소스코드를 볼 때 특정 소스코드의 한 줄만 보아도 해당 줄을 누가 언제 작성해서 관련된 요청은 언제 누가 했으며, 이와 관련된 회의는 언제 누가 진행했고, 결론은 어떻게 나왔는지 줄줄이 모두 몇번의 클릭으로 추적이 된다. 그래서 누가 와서 유지보수를 해도 소스코드의 역사를 훤히 볼 수가 있다.


메신저 사용


가짜 비대면 업무를 하는 회사는 메신저를 끼고 업무를 한다. 회상 회의까지는 아니지만, 수시로 여러 사람에게 메시지를 날리고 이거 저거를 물어본다. 회상 회의보다는 작지만 비용이 많이 들어가는 일이다. 답변을 하기 위해서는 하던 일을 중단해야 한다. 만약에 집중 업무를 하고 있던 경우라면 다시 집중하는데 필요한 시간까지 최소 30분은 그냥 날아간다. 이런 일이 한 두 건이면 모르겠지만, 메신저를 통해서 메시지가 여기저기서 수시로 쏟아지면, 정작 집중해서 본연의 업무를 할 시간이 부족하다.

메신저의 문제점 중 하나가 기록이 체계적으로 남지 않아서 회사의 정보 자산으로 축적되지 않는 다는 것이다. 

그래서 메신저는 정보 자산과 관련 업무를 위해서 가벼운 용도로만 최소화해서 사용해야 한다.

편리하다고 수시로 메시지를 날리는 것은 대면 업무 방식과 크게 다를 바가 없다. 


업무 만족도


가짜 비대면 업무를 하는 회사는 현재 회사에서 진행하는 비대면 업무 방식에 불만이 많다. 아무래도 과거 대면 방식보다 불편하고 업무 효율성이 떨어지기 때문이다. 원인은 여러가지가 있을 수 있다. 시스템이 충분히 구축되어 있지 않은 채로 강제로 몰아붙일 수도 있고, 역량은 안되는데 과도하게 시스템을 도입한 경우도 있다. 

직원들이 충분히 시스템에 적응하지 못한 경우도 있다.

진짜 비대면 업무를 하려면 추가로 시스템이 필요한지, 직원들의 문서 작성 역량 향상이 필요한지, 시스템 사용 교육이 더 필요한지 회사에 따라서 다를 것이다.

대면 업무 방식으로 오랫동안 일하던 회사가 하루 아침에 완전 비대면 방식으로 전환하기는 어렵다. 인식의 전화, 시스템 사용 적응, 문서 작성 역량 등 필요한 것이 한두개가 아니고 수년 걸리는 일도 있다. 전문가의 도움을 받아서 하나씩 하나씩 꾸준히 추진하는 수밖에 없다.


재택근무 가능 여부


가짜 비대면 업무를 하는 회사는 100% 재택 근무를 하지 못한다. 최근 뉴스에 100% 재택 근무를 하고 있는 미국의 많은 회사를 접한다. 1200명 전원이 회사 사무실 하나 없이 100% 재택 근무를 하는 깃랩도 있고, 구글, 페이스북도 100% 재택근무를 하는 직원이 꽤 많다.

하지만 가짜 비대면 업무를 하는 회사는 일주일에 1~3일 정도 재택근무를 하고 나머지는 회사에 나와서 일해야 한다. 또는 재택근무가 가능한 특수한 직군만 100% 재택 근무가 가능하다. 최근 코로나 때문에 이런 식으로 일부 재택근무를 하는 회사가 있다.

물론 재택근무가 100% 우월한 것은 아니다. 대면 업무 방식은 얼굴 보고 일하면서 팀워크가 증가하는 것도 있고, 생활 리듬에 안정을 주는 것도 있다. 하지만 여기서 얘기하는 것은 필요할 때 재택근무를 할 수 있냐는 것이다.

100% 재택근무가 가능해야 진짜 비대면 업무를 하고 있다고 볼 수 있다. 그런 역량을 가지고 모여서 일하는 것은 회사의 선택이다.


이글은 ZDNet Korea에 기고한 칼럼입니다.

2020년 9월 7일 월요일

비대면 온라인 화상 회의를 효율적으로 하는 방법

코로나 19로 인해서 비대면 업무의 필요성이 대두되면서 회의도 비대면으로 진행해야 하는 요구가 커졌다. 인터넷을 통해 화상 회의를 하는 여러가지 시스템이 있고, 이런 시스템을 이용하면 효율적으로 비대면 회의를 진행할 수 있다. 현재 비대면 온라인 화상 회의 솔루션을 제공하는 회사의 가치는 하늘 높은 줄 모르고 치솟고 있다. 클라우드 기반 회상회의 서비스 회사인 줌(Zoom)은 최근 IBM의 시가 총액을 추월했다. 


코로나 19가 아니더라도 회의를 비대면으로 진행하는 것은 여러가지 장점이 있다. 먼저 비용이 더 적게 든다. 대면 회의는 한자리에 사람들이 모이려면 이동 시간도 필요하고, 넓은 회의 공간도 필요하다. 회의실도 제약이 있어서 원하는 시간에 회의를 못하고 시간을 조정해야 한다. 앞 회의가 늦게 끝나서 기다리느라고 시간을 낭비하기도 한다.  


하지만 온라인 화상 회의는 회의실도 필요 없고, 지구 반대편에 있는 사람과도 시간만 정하면 언제든지 회의를 할 수 있고 업무 효율성 면으로 많은 이익이 있다. 


오랫동안 온라인 화상회의에 익숙해진 회사라면 문제가 없지만 온라인 회의를 처음 도입하는 회사라면 막상 온라인으로 화상 회의를 진행해보면 오프라인 대면 회의와는 다른 점이 많다. 이것을 비교해보고 효율적으로 비대면 회의를 하는 방법을 알아보려고 한다. 


화상 회의의 단점


회상 회의는 인터넷을 통하기 때문에 0.5초~1,2초 정도의 시간 지연 효과가 있다. 내가 말한 후 약 1초 정도 후에 상대방이 듣는다는 의미다. 그래서 서로 얘기를 하다 보면 말이 서로 겹치고 꼬이는 경우가 발생한다. 그래서 대면회의처럼 서로 중간에 말을 끊고 열띤 토론을 하다 가는 뒤죽박죽이 된다. 그래서 화상 회의에서는 말하는 에티켓을 지켜야 한다. 한사람이 너무 오래 말을 하는 것도 좋지 않고, 중간에 말을 끊는 것도 좋지 않다. 한사람이 말을 하고 나서 동시에 두사람이 말을 시작하는 경우도 있다. 그래서 회상 회의 시스템에는 “손들기”기능이 있는 경우도 있다. 이 경우 손을 든 순서대로 발언의 기회를 주기도 한다. 회사에서 화상 회의 때 발언하는 규칙이나 에티켓을 정해서 시행하면 좋다. 


화상 회의를 하다 보면 소리가 울리는 하울링이나 시스템 문제 때문에 중간에 회의가 중단되는 일을 여러 번 겪게 된다. 그래서 가능하면 회상 회의 장비는 좋은 것을 갖추고 네트워크도 충분히 갖추는 것이 좋다. 비용을 조금 아끼려다가 툭하면 회의가 중단되어서 더 큰 비용을 지불하기도 한다.  


화상 회의의 단점 중 하나는 아무래도 대면으로 얘기하는 것보다 전달력이 떨어진다. 미묘한 표정의 변화를 읽기가 어렵고 소리가 100% 깨끗하게 전달되지 않거나 잡음이 좀 섞이기도 해서 대면 회의보다는 떨어진다. 따라서 회의 내용을 명확히 정의하고 안건을 해결하는데 집중하는 것이 좋다.  


화상 회의의 장점


가장 큰 장점은 비용이 적게 든다는 것이다. 회의실이 필요 없고, 한자리에 모일 필요가 없으니 이동 시간이 절약된다. 한 빌딩 안에 있는 사람들이 아니라면 이동 시간은 더욱 절약된다. 해외 지사의 인원이나 재택 근무자와도 이동없이 바로 회의를 할 수 있다. 회상 회의 시스템을 도입하는데 비용이 들기는 하지만 회상 회의를 통한 비용 절약은 비용을 넘어서고도 남는다. 


회의를 녹화 또는 녹음할 수 있기 때문에 나중에 재검토를 할 수도 있고, 비참석자도 회의 내용을 확인할 수 있다. 


화상 회의는 급한 안건으로 긴급하게 회의를 소집할 때 매우 유리하다. 빠르면 10분안에도 서로 다른 곳에 있는 사람들을 모아서 회의를 진행할 수 있다. 대면 회의로는 도저히 할 수 없는 신속함이 가능하다.  


 회상 회의에서 지켜야 할 사항


화상 회의도 편리하다고 아무 때나 마구 진행하면 비싼 비용을 치러야 한다. 미리 스케줄러에 계획을 하고 명확한 아젠다를 정의하고 가능하면 24시간 이전에 공유를 해야 한다. 모든 참석자는 아젠다를 철저히 검토하여 자신의 의견을 정립하여 참석해야 한다. 아젠다에 미리 의견을 첨부하여 회의 시간을 단축할 수 있다. 이것은 고스란히 회의록으로 이전된다. 


온라인 화상 회의도 회의 주도자가 있어야 한다. 그래야 여러 의견 충돌 시 조율을 하고 진행을 원활하게 할 수 있다. 회의는 핵심 이견만 논의하여 신속하게 결론을 내리면 된다. 온라인으로 공유하면 되는 내용을 공유하기 위해서 굳이 회의를 개최할 필요가 없다.  


온라인 회의도 시간을 지켜야 하는 것은 마찬가지다. 3시가 회의라면 적어도 5분전에 시스템에 접속을 해야 한다. 가끔, 문제가 생겨서 접속하는데 시간이 소요되기도 한다. 그래서 5분전에는 접속을 시도해야 회의에 늦지 않을 수 있다. 이래저래 준비하느라고 5분, 10분 늦게 회의를 시작하는 것이 일상화된 회사가 종종 있다. 항상 일찍 접속해서 기다리는 사람은 항상 시간을 낭비하고 회사 입장에서도 큰 손해다. 


재택근무시 화상회의를 하게 되면 너무 편한 복장으로 접속을 하는 경우도 있는데, 최소한의 예의를 갖추는 복장 정도는 입어주는 것이 좋다. 그리고 나름 조용한 공간도 필요하다. 주변이 너무 시끄러워도 회의에 방해가 되고, 회의 때문에 시끄러워서 주변에서 일하는 사람들에 방해를 주는 것도 조심해야 한다. 


앞에서도 언급했다시피 화상회의는 인터넷 속도의 한계상 지연이 발생할 수밖에 없으므로 상대방의 발언을 경청하는 습관을 들이고 중간에 끼어들지 않도록 하고 자신도 꼭 필요한 말만 간결하게 하는 습관을 들여야 한다. 화상회의를 이렇게 진행하면 업무 효율성이 많이 향상된다. 


회의록을 작성하는 방법


화상 회의를 하면서는 회의록을 실시간으로 작성하기 좋다. 회의가 끝나고 회의록을 따로 작성해서 배포하고 검토하고 수정하고 하는 것은 꽤나 번거롭고, 귀찮은 일이다. 그래서 회의 내용과 다른 회의록이 작성되기도 한다. 회의록은 실시간으로 작성하는 것이 좋은데, 회상 회의 때 회의 진행자가 회의록을 직접 작성하기를 추천한다. 아젠다를 띄워 놓고 직접 수정해가면서 회의록을 작성하면 좋다.  


회의록은 실시간으로 작성해서 모든 참석자가 실시간으로 눈으로 보면서 문구 하나하나 검토해서 의견이 다르면 회의록 수정을 요청해서 이것도 즉석에서 다시 적어야 한다. 회의록을 즉석에서 적고 공유할 수 있는 시스템도 있다. MS 팀즈에는 위키(Wiki)를 통해서 회의록을 실시간 공유할 수 있도록 되어 있다. 또는 화면 공유를 통해서 위키나 회의록 시스템에 실시간 기록할 수 있다. 


회의록을 작성하면서 결정사항, 미결사항, 해야 할 일 등을 태그로 표시를 하고 추후 해야 할 일은 Todo 시스템과 연동이 되도록 하는 것이 좋다. Atlassian의 Confluence의 회의록 시스템은 이런 기능이 잘되어 있다. 


간단한 일은 Todo와 연동하면 되지만 회의 후 해야 할 일이 꽤 큰 일이고 추적이 필요하면 이슈관리시스템과 연동을 하는 것이 좋다. 이렇게 해야 할 일을 등록해 놓고 추적하지 않으면 흐지부지 되는 경우가 많다. 


온라인 화상 회의는 이렇게 회의 준비, 과정, 결과, 후속 조치가 모두 온라인 시스템에 등록되어 회사의 자산이 된다. 그리고 지구상 어디에서든지 접근 가능한 정보가 된다. 온라인 회의가 제대로 정착되면 회사의 생산성이 증가할 수밖에 없다. 또한 비대면 업무로 전환하기 위한 강력한 무기가 된다.


이글은 ZDNet 코리아에 기고한 칼럼입니다.


2017년 9월 5일 화요일

나쁜 회의가 회사를 망친다

나쁜 회의 문화가 회사를 망친다.
잦은 회의와 장시간 회의 때문에 일 할 시간이 없다고 하소연하는 사람이 많다. 특히, 고참 개발자들에게는 그 폐해가 더 크다. 개발과 회의는 두뇌의 모드가 완전히 달라서 섞어서 하게 되면 개발 효율이 나지 않고, 많은 회의에 끌려 다니다 보면 어느새 개발자로서의 정체성을 잃어버리게 된다. 이런 시간이 지속되면 개발자의 경력에서 벗어나 돌아올 수 없는 어정쩡한 관리자의 길을 걷게 된다.
그럼, 우리 주변에서 흔히 볼 수 있는 회의의 나쁜 증상들을 살펴보자.
“여러분, 회의 좀 합시다.”
상급자의 요구에 의해서 수시로 소집되는 회의 유형이다. 갑자기 소집을 하기 때문에 주제와 내용이 회의 참석자들에게 충분히 공유되지 않고, 참석자들은 각자의 업무 계획이 있었는데 갑작스런 회의 때문에 일정도 틀어지고, 부족한 준비로 회의 진행도 부실하게 된다.
“직급이 깡패.” 회의를 하면서 서로 합리적으로 논의하여 결정을 못하고 상명하복식으로 무조건 윗사람이 결정하는 회의 유형이다. “편하게 얘기들 해보세요”라고는 하지만 편하게 얘기할 수 없고 결국에는 윗사람이 독단적으로 결정한 것을 통보하는 회의가 되곤한다.
“그럼, 네가 한번 해봐." 아이디어를 꺼내면 얘기를 꺼낸 사람이 일을 떠맡는 유형. 그러다 보니 해야할 얘기나 아이디어가 있어도 쉽사리 얘기를 꺼내지 못하게 된다.
“설명 좀 해 줘봐.” 상급자가 모르는 내용이 있거나 업무를 파악하기 위해서 실무자나 팀장들을 소집해서 브리핑을 받는 회의 유형. 업무 내용파악을 위해 수시로 실무자들을 불러서 시간을 낭비한다.
“언제 끝날지 모르는 마라톤 회의.” 어려운 주제를 일단 회의시간에 만나서 끝장을 보려고 진행하는 회의 유형. 사전 의논이나 조율없이 달랑 회의에 참석해서 난상토론을 하면서 몇시간을 훌쩍 넘기는 회의. 그렇게 장시간 회의를 하고 결론을 짓지 못하고 다음에 결정하자고 하기도 한다.
“회의는 회의.” 회의에서 나온 결론이나 업무들이 추적이 안되는 유형, 회의는 열심히 하는데 그 뒤에 어떻게 처리가 되는지 추적이 잘 안되는 경우가 많다. 이를 확인하기 위해서 다시 회의를 소집하기도 한다. 또한, 회의에서 결정된 사항들이 제대로 기록되고 관리가 안돼서 나중에 회의 참석자들끼리 회의 내용에 대해서 다툼을 하기도 한다.
이외에도 비효율적인 회의 유형은 다 나열 할 수 없을 만큼 많다. 많은 회사에서 중간 관리자, 고참 개발자들은 회의에 불려다니느라고 낮에는 일을 못하고 어쩔 수 없이 밤에 일을 하고 있다. 그러다 보면 고참 개발자들은 개발할 시간이 점점 부족해져서 결국에는 개발과는 멀어지게 된다. 회사 입장서는 중요한 개발 자원을 잃게 되는 것이다.
이우소프트에서는 5,6년에 걸쳐서 회의 문화 개선을 위해서 노력을 해왔고, 이제는 어느 정도 정착이 되어가고 있다. 이를 몇가지만 간단히 소개하려고 한다.
■ 가능하면 짧게…최소 24시간 전에 아젠다 공지
첫째, 가급적 회의는 하지 않는다.
회의의 관행을 바꾸는 가장 중요한 요소다. 불필요하거나 다른 것으로 대체 가능한 회의는 최대한 줄여야 한다. 회의의 비용은 상상 이상으로 엄청나다. 회의를 하면서 소모하는 비용도 크지만, 기회 비용은 그보다 더 크다. 무조건 회의는 1/10로 줄인다는 생각으로 시작하자. 진행하는 일을 모두 온라인 시스템으로 공유하면, 회의는 획기적으로 줄일 수 있다. 정보 공유, 업무 진행상황 확인, 업무 지시 등과 관련된 거의 모든 회의는 할 필요가 없고 온라인 시스템을 통하면 된다. 꼭 필요할 때만 회의를 통해서 논의를 하면 회의를 최소화할 수 있다.
둘째, 최소 24시간 전에 상세한 Agenda와 함께 회의를 초청한다.
그래도 회의를 하는 것이 효율적일 때는 미리 회의를 초청한다. 이때 상세한 Agenda를 공유하고 발표자료나 참고자료는 미리 같이 배포를 해서 참석자들이 완전히 숙지를 하고 들어올 수 있게 한다. 덜렁덜렁 내용도 모르고 회의에 참석하는 것은 금기다. 회의 시간에 자료를 발표하거나 낭독하는 것은 시간 낭비다. 이렇게 하면 회의 때문에 업무에 지장을 초래하는 일이 줄어들고 회의 시간도 짧아진다.
피치 못하게 급작스럽게 소집되는 회의도 시스템을 통해서 Agenda와 회의 자료를 등록 후 회의를 소집한다.
셋째, 회의시간은 가능하면 짧게 한다.
보통 30분을 넘기지 않도록 하고 길어야 1시간을 넘기지 않도록 한다. 그러기 위해서 회의 참석자들은 회의 주제와 내용을 사전에 모두 파악하고 빠른 결론을 내기 위해서 노력을 한다. 모두 회의에 집중해야 하며, 중간에 전화를 받거나 잠깐 나갔다 오는 행동은 금지되어 있다.
넷째, 회의록은 실시간으로 작성한다.
가급적 회의록은 회의를 하면서 동시에 작성한다. 작성되고 있는 회의록은 회의 참석자 모두가 볼 수 있게 해서 즉석에서 수정하도록 한다. 또한 회의록에는 2가지가 꼭 적힌다. 결정사항과 “Action Items”다. 회의에서 어떠한 결론을 냈는지는 별도의 항목에 정리를 하고 회의 이후에 해야 할 일들은 “Action Items”로 따로 정리한다. 회의 참석자들은 실시간으로 내용을 확인해서 동의를 해야 한다. “Action Items”에는 꼭 담당자와 Due date를 지정한다. 회의 후에 바로 이슈관리시스템에 Task를 생성해서 모든 관련자들이 실시간으로 “Action Items”의 진행을 추적할 수 있도록 한다.
다섯째, 회의록은 전직원에게 공유된다.
회의록은 회의 참석자 외에도 전직원에게 공유하는 것이 좋다. 회의록 공유는 성숙된 공유 문화의 중요한 요소다. 실시간으로 공유된 회의록에는 누구나 회의 내용에 질문을 하거나 의견을 줄 수가 있다. 또한 회의 내용이 모두에게 공유가 되면서 업무는 투명하게 진행이 된다. 정보는 독점을 할 때보다 공유를 할 때 더 큰 힘을 발휘한다. 이우소프트는 회의록을 위키시스템을 통해서 작성하고 있다. 따라서 모든 회의록은 손쉽게 검색이 가능하여 회의 내용에 대한 다툼이 없다. 해야 할 일은 이슈관리시스템과 연계돼서 회의와 관련된 모든 업무가 추적된다.
회의는 매우 중요하다. 잘하면 약이 되고 잘못하면 독이 된다. 회의 문화의 변화는 회의 이전에 정보 공유 시스템을 통한 공유 문화가 우선되어야 한다. 그래야 회의가 줄어들면서 회의 문화가 개선되기 시작한다.

이글은 ZDNet Korea에 기고한 글입니다.


2014년 11월 2일 일요일

쓸데없는 회의를 줄이는 방법

'회의가 많은 회사는 곧 망한다'는 속설이 있다. 다른 분야에서도 마찬가지지만 개발자도 회의에 많은 시간을 빼앗기면 개발에 집중하기 어렵고 이는 개발 생산성 저하로 이어진다. 꼭 필요한 회의는 해야 하지만 과도한 회의는 줄여야 한다. 그럼 어떻게 회의를 줄일 수 있을까? 
 
물론 개인 혼자서 회의를 줄이려고 노력한다고 해서 되는 것은 아니다. 직원들이 회의를 줄이는 것이 왜 중요하고 어떻게 줄여야겠다는 방법도 서로 공유를 하고 노력을 해야 한다. 일단 회의가 얼마나 비싼 활동인지 생각해보자. 
 
10명이 1시간동안 회의를 하면 얼마의 비용을 쓴 것일까? 회사마다 다르겠지만 적게 잡아도 100만원쯤 쓴 것으로 생각하면 된다. 개발자는 1인당 회사에서 사용하는 비용은 급여와 부대비용을 계산하면 알 수 있다. 여기에 개발자가 그 시간 동안 다른 일을 했을 때의 기회비용까지 계산하면 최소한 한 시간에 10만원은 생각해야 한다. 이보다 낮다고 주장하는 개발자가 있을 수도 있지만 평균 이 정도는 생각해야 한다. 
 
30명이 참석하는 회의에 몇 사람이 늦게 와서 10분 늦게 시작하면 50만원은 그냥 손해를 본 것이다. 이렇게 회의에 직접적으로 소모하는 비용과 회의에 참석하기 위해서 준비를 하거나 자료를 읽는 시간, 회의 참석에 이동하는 시간, 앞뒤로 어영부영 지나가는 시간을 합치면 훨씬 많은 시간을 소모하게 되고 그 비용은 상당하다. 
 
이렇게 비싼 회의는 꼭 필요한 경우에만 효율적으로 해야 한다. 그렇지 않고 회사의 생산성을 높일 수는 없다. 그럼 어떻게 회의를 줄일 수 있는지 알아보자. 회의를 줄이기 위해서는 아래 3가지 원칙을 지키면 된다. 
1. 회의를 하지 않는 것이다. 
2. 회의에 참석하지 않는 것이다. 
3. 회의 시간을 줄이는 것이다. 
 
첫째, 안해도 되는 회의는 하지 않는다. 회의를 전혀 안할 수는 없다. 특히 의사결정은 문서나 시스템으로 하기 어렵고 대부분은 회의를 통해야 한다. 하지만 회의를 하지 않거나 대규모 회의로 하지 않아도 되는데 무신경하게 또는 일상적으로 회의를 하는 경우가 많다. 
 
정보를 단순 공유하거나 브리핑을 위한 회의는 줄일 수가 있다. 일상적으로 시스템을 통해서 공유가 잘 되는 회사는 이런 단순 공유 회의는 거의 하지 않는다. 단, 시스템을 잘 쓴다는 전제하에 이런 회의는 거의 하지 않아도 되는 것이다. 이를 위한 가장 중요하고 유용한 시스템은 이슈관리시스템이다. 이슈관리시스템은 소프트웨어 회사에서는 없어서는 안될 중요한 시스템이다. Trac, Jira, Mantis, Redmine과 같은 시스템이다. 
 
하지만 필자의 블로그에서 시행하고 있는 수년간의 설문 통계를 보면 약 40%의 회사는 아직도 이슈관리시스템을 사용하고 있지 않다. 이메일과 엑셀 등으로 이슈를 주고 받거나 관리를 하는데 그렇게는 효율적인 소통이 어렵다. 게다가 이슈관리시스템을 사용하고 있는 회사도 정말 효율적으로 잘 쓰고 있는 회사는 10%가 안된다. 
 
회의를 줄일 수 있을 정도로 이슈관리시스템을 잘 쓰는 방법은 책 한권으로 설명해도 부족하겠지만 요약하면 다음과 같다.
 
모든 공식적인 요청은 이메일, 전화, 말로 하지 않고 이슈관리시스템에 등록해야 한다. 나머지는 보조수단이다. 전 임직원이 예외 없이 규칙을 따라야 한다. 이슈관리시스템에 대시보드를 자신에게 맞게 잘 만들어서 적어도 하루에 한번 이상 대시보드를 확인하고 처리를 해야 한다. 이슈관리시스템에 이슈를 등록하고 상태를 변경하며 댓글을 다는 등의 행동은 성의껏 해야 한다. 
 
내가 남긴 한 줄의 문장을 수많은 사람이 읽고 공유가 되며 대화와 회의를 대신하고 오랫동안 남아서 여러 사람에게 정보를 제공할 것이기 때문에 엉터리 문장으로 적으면 안된다. 10년 후에 후배가 봤을 때 알아 볼 수 있도록 잘 적어야 한다. 물론 이렇게 사용하려면 무신경하게 엉터리로 사용하는 것보다 약간의 노력이 더 필요하지만 충분히 그럴 가치가 있다. 
 
둘째, 내가 참석하지 않아도 되는 회의는 참석하지 않는다. 
 
회의는 참석자가 적을수록 효율적이다. 내가 참석하지 않아도 되는 회의는 참석하지 않아야 한다. 그리고 회의에 똑 필요한 인원만 초청을 해야 한다. 
 
회의 참석의 목적은 여러가지가 있지만 의사결정을 하기 위한 것이거나, 전문가로서 의견 제시하거나 정보를 습득하려는 등의 목적이 있다. 
 
가끔 회의 요청을 받으면 이런 단순 정보 공유 회의에 내가 왜 참석해야 하는지 의문이 들 때가 있다. 특히 내게 당장 필요하지는 않지만 알면 좋은 정도로 애매한 경우도 있다. 이런 때는 내가 지금 이 시간을 투자해서 참석할 필요가 있는 회의인지를 판단해야 한다. 물론 이런 회의에 무조건적으로 참석하라고 하면 안된다. 누구나 들으면 좋은 회의라고 참석자를 잔뜩 늘려서 초청을 하면 수백만원의 비용을 지불하는 것이라는 생각을 잊으면 안된다. 
 
내가 전문가로서 의견을 제시해야 하는 경우라면 회의 내용을 사전에 꼭 숙지를 하고 참석해야 한다. 이런 회의에 전문가가 아닌 사람을 여러명 불러 놓고 난상토론을 하는 것은 정말로 시간 낭비다. 회의 때마다 잘 알지도 못하지만 그냥 이슈를 마구 던지거나 자신의 취향이 전문적인 의견인양 얘기하는 사람들이 있다. 이런 회의의 참석자는 꼭 필요한 사람으로 잘 꾸려야 한다.
 
리뷰 회의가 대표적이다. 교육적인 목적으로 내용을 익히려고 참석하는 경우도 있지만 각 분야의 가장 전문가가 미리 내용을 한 글자, 한 글자 꼼꼼히 읽어보고 빠르게 의견을 제시해야 한다. 그래서 고참이 될수록 이런 리뷰 회의에 참석하는 일이 많아지게 된다. 
 
셋째, 회의 시간은 최소화 해야 한다. 
 
회의 시작 전에 회의 아젠다를 미리 공유하고 회의 자료나 문서를 미리 배포해야 한다. 회의는 시작 시간과 종료 시간을 미리 정해야 하며 무작정 길게 시간을 잡는 것은 삼가야 한다. 회의에 따라서 다르지만 대부분의 배포된 문서를 꼼꼼히 읽고 와야 한다. 경영진이라고 하더라도 미리 꼼꼼히 읽어야 한다. 회의시간에 자료를 다시 브리핑하는 것은 여간 낭비가 아니다. 
 
따라서 회의 공지는 자료를 충분히 검토할 시간이 필요하므로 충분히 미리 해야 한다. 회의 1,2시간 전에 갑자기 공지를 하면 준비할 시간이 부족하게 된다. 
 
회의시간에는 회의에 집중해서 계획한 시간 안에 꼭 내도록 노력해야 한다. 쓸데 없이 경영진이 교장선생님처럼 이런 저런 얘기를 하는 것은 좋지 않다. 회의 주제에 집중해야 한다. 
 
개발자들과 아침에 하는 5분 회의는 효율적인 회의의 대표적인 예다. 자료는 이슈관리시스템에 있고 대시보드를 확인하며 주요 이슈만 확인을 하고 꼭 공유해야 할 내용을 얘기하면 개발팀 일일회의는 5분에서 10분안에 끝나게 된다. 
 
그 외에 스카이프나 구글행아웃을 이용한 원격회의도 회의를 효율적으로 하게 해준다. 회의를 위해서 먼거리를 이동하지 않고 원격으로 회의를 할 수 있고 요즘은 스마트폰으로 회의를 하기도 한다. 코드리뷰시스템을 사용하는 것도 좋은 방법이다. 온라인으로 코드리뷰를 할 수 있도록 하여 코드리뷰 자체의 효율성도 높아지고 코드리뷰 때문에 모여야 하는 시간을 줄여주고, 코드리뷰 내용을 모든 사람과 공유할 수 있어서 좋은 정보가 된다. 
 
마지막으로 회의를 했다면 가능하면 빠른 시간에 회의록을 정리하여 회의 참석자와 참석하지는 않았지만 관련된 모든 사람에게 회의록을 배포해야 한다. 이슈관리시스템 등의 시스템을 활용해서 회의록을 배포, 관리하는 방법도 좋다. 
 
다시 한번 회의가 얼마나 비싼 활동인지 명심하자. 하루에 회의 3,4번이면 개발자는 다른 일은 거의 못한다. 개발자뿐만이 아닐 것이다. 회의는 지금의 10분의 1로 줄인다는 마음으로 회의를 줄여보자.

이글은 ZDNet Korea에 기고한 칼럼입니다.

2013년 12월 4일 수요일

회의 많았던 SW 개발 회사의 비극(개발문화 시리즈7)

이번 개발문화 이야기는 '회의 문화'다. 

회의 문화는 IT 분야에만 국한된 얘기가 아니다. 이미 많은 논의가 있었고, 회의 문화가 개선된 회사들도 많다. 그러나 변화가 필요한 회사들도 아직 많다. 

회의가 많은 회사는 망한다는 속설도 있는데, 하루종일 회의하느라 정작 일은 퇴근 시간 지나서야 할 수 있다고 하소연하는 고참 개발자나 팀장들을 많이 봤다. 회의를 많이 하는 증상이 있는 회사는 회의 자체의 문제보다 근본적으로 해결해야 할 문제들이 따로 있을 가능성이 높다. 

회의를 하는 방식 자체보다는 근본적인 원인에 대해서 얘기를 해보고자 한다. 

첫째, 우리나라 회사들은 재택근무가 쉽지 않다. 이것은 여러 문화의 결과이기도 하다. 업무지시를 서로 만나서 해야 하고 얼굴을 봐야만 얘기가 되는 상황이라면 재택근무로 일하기 어렵다. 

지금 같이 일하고 있는 동료들이 모두 집에서 일한다고 생각하면 어떻게 될지 상상을 해보자. 전혀 일이 진행되지 않거나 효율이 너무 떨어진다면 다시 한번 생각해봐야 한다. 

회의를 통해서 해결하는 안건의 상당수는 만나지 않고 시스템을 통해서 온라인으로 충분히 의논할 수 있는 것들이다. 물론 회의를 통해서 해결하는 것이 효율적인 안건들도 있다. 이런 안건도 만나서 난상토론을 하기 보다는 이슈를 다 정리한 후에 공유하고 몇가지 핵심 결정사항만 회의를 통해서 해결하면 된다. 

굳이 만나서 해결할 필요도 없고 전화나 화상회의로도 충분히 가능하다. 내용은 이미 공유되어 있고 핵심 사항만 의논하고 결정하면 되기 때문에 시간도 얼마 걸리지 않는다. 그리고 일하는 과정이 시스템을 통해서 투명하게 공유가 되면 굳이 만나서 회의를 해야 할 일은 대폭 줄어들게 된다. 

SI 프로젝트를 진행하다 보면 고객이 개발자의 출석체크를 한다는 얘기도 있다. 모아 놓고 일을 하지 않으면 일이 제대로 진행 되지 않는다고 생각하고 안보이면 제대로 일을 하고 있다고 믿지도 못하는 것이다. 이 또한 투명하게 일이 진행되지 않는 것이 주요 원인 중 하나다. 

재택근무 대신 모여서 일을 한다고 해도 재택근무가 가능한 형태로 일을 해야 더 효율적이다. 현재 재택근무가 불가능하다면 근본 원인을 생각해보자. 

둘째, 경영진에 보고하는 회의가 비효율적이다. 

주간회의와 같은 형태로 주기적으로 정리를 해서 한주간의 업무를 부서별로 취합, 정리해서 보고를 하는 형태의 회의는 우리나라에서 아주 흔하게 볼 수 있다. 다른 분야에서는 어떨지 모르겠지만 소프트웨어 분야에서 이런 형태의 보고회의는 많은 문제를 유발한다. 이런 회의가 없어야 한다는 것은 아니다. 

그러나 이런 회의는 준비과정에 많은 시간이 걸리고 대부분의 회사에서 개발자를 겸하고 있는 개발팀장들의 시간을 많이 소모한다. 그리고 취합되고 정리되는 과정에서 많은 핵심정보는 사라지고 예쁘게 꾸며진다. 경영진은 적나라한 개발현황은 보고 받지 못하고 화장이 잘 된 보고를 받게 된다. 

앞에서도 얘기했지만 모든 개발과정은 시스템을 통해서 투명하게 공유되어야 하고 경영진은 이 시스템들을 통해서 개발 진행상황을 직접 볼 수 있어야 한다. 경영진이 약간의 노력을 보여주는 것도 필요하지만 시스템이 경영진이 필요한 보고서를 실시간으로 만들어 낼 수 있어야 하고 우선적으로 개발문화가 투명하게 바뀌어야 한다.

경영진은 실시간으로 모든 개발상황을 파악할 수 있어야 하고 시스템을 통해 이슈 관련 논의에 직접 참여해야 한다. 앉아서 보고를 받고 구도로 지시하는 방식으로는 너무 비효율적이고 느리다. 회의시간에는 중요한 이슈 몇가지만 논의하면 된다. 시스템에 있는 정보를 굳이 다시 보고를 받을 필요는 없다. 

회의에 관련해서 몇가지 이슈를 섞어서 얘기를 했지만 이 또한 여러 개발 문화와 얽혀있다. 공유가 부족하면 수시로 만나서 물어봐야 하기 때문에 회의가 많아진다. 문서화를 싫어하니 정리한 후에 간단히 결정만 해도 될 회의를 만나서 얘기로 다 풀어야 한다. 

시스템을 통해서 논의를 했으면 자동으로 공유가 되는데 만나서 논의한 내용은 기록에도 남지 않는다. 나중에 딴 소리를 하기도 하고 다른 사람들이 내용을 모르니 똑같은 사안을 또 물어본다. 시스템에 개발 현황이 투명하게 공개가 안되니 일일이 만나서 공유해야 한다. 

뭐든 빨리 빨리 해결하려고 하니 일단 이슈가 생기면 시간이 약간 더 걸리더라도 효율적인 시스템을 이용하지 않고 즉시 만나서 해결하려고 한다. 문서를 작성하고 공유하는 것에 습관이 안돼 있으면 회의를 하면서도 기록을 하지 않고, 그렇다보니 결정사항을 추적하는 것도 쉽지 않다.

이처럼 이제부터 회의문화를 개선해보자고 회의 방법만 고쳐본들 별로 나아지는 것을 없을 것이다. 재택근무가 마치 옆에서 일하는 것처럼 효율적으로 가능할 정도로 근본 원인을 하나씩 개선해야 한다. 그러려면 프로세스, 기반시스템도 바뀌어야 하지만 무엇보다 전반적인 개발문화가 바뀌어 나가야 한다. 

그래야 회의 문화도 조금씩 개선이 되고 회의 횟수와 시간도 줄며 좀더 효율적인 회의문화가 정착 될 것이다.

이글은 ZDNet에 기고한 칼럼입니다.

2009년 8월 20일 목요일

회의 때문에 일할 시간이 없다.

경영자들은 "우리는 업무 공유가 안돼. 커뮤니케이션이 안돼" 라고 하면서 물리적으로 소통을 증가시키는 방법을 찾곤 합니다.

억지로 회의를 가지게 하고, 영업팀과 개발팀을 옆에 붙여 놓거나, 회사의 파티션의 높이를 낮추는 등의 조치를 취하기도 합니다.

회의시간을 늘인다고, 옆에 있다고 커뮤니케이션이 잘되지는 않습니다. 오히려 잦은 회의는 업무시간만 줄어들고 성격이 다른 부서들이 서로 뭉쳐 있으면 소음 때문에 개발에 방해만 됩니다. 

커뮤니케이션은 적절한 프로세스와 시스템을 통해서 해결해야 합니다. 스펙을 작성하고 리뷰할 줄도 모르는데 제품이 어떻게 만들어지고 있는지 공유가 안된다고 한탄할 수는 없습니다. 프로젝트 관리 시스템이 있다면 회사의 모든 사람들이 프로젝트 진행과정을 물어보지 않아도 훤히 알 수 있습니다. 

대화는 커뮤니케이션에서 가장 중요한 수단이기도 하지만, 가장 비싸면서 오류도 많고 휘발성입니다. 따라서 커뮤니케이션을 강화하려면 대화의 수단은 줄이고 시스템과 기록을 강화해야 합니다.

체계를 제대로 갖추고 있는 소프트웨어 회사라면 대부분의 업무가 몇 가지의 핵심 시스템을 통해서 이루어지며 대화는 꼭 필요한 경우에만 사용됩니다.

물론 당사자들이 모두 모여서 한번이면 해결 가능한 이슈를 메일이나 다른 수단을 이용해서 여러차례 반복해서 소통을 하는 것은 비효율적이죠. 하지만 반대로 시스템으로 간단히 공유하고 의견을 전달할 수 있는 것들을 만나서 해결하는 것은 더 비효율적입니다.

아직도 문제가 생기면 매일 모여서 회의하고 또 결론이 없어서 다음에 또 회의를 반복하고 정보를 공유하기 위해서 또 회의하고 개발 시간은 점점 줄어들고 이런 상황인가요? 프로세스와 시스템이 필요할 때가 된 겁니다.