3장. 애자일 전도사#2
#3-2 똑똑한 사람들의 멍청한 행동
#3-2 똑똑한 사람들의 멍청한 행동
* 전문가들의 커뮤니케이션 문제
하버드 비즈니스 스쿨의 석학인 레슬리 A. 퍼로우는 조직 행동학을 연구하는 교수이다. 레슬리는 ‘03년도부터 여러 회사들을 다니며, 몇 달의 기간 동안 특정 조직을 관찰하고 개선할 점을 제시하는 ‘에쓰노그래퍼(Ethnographer)’ 로 활약해왔다. 주로 엑손 모바일, 월마트, GM들과 같은 포츈 500(매년 포츈지가 선정한 500대 기업 리스트) 안에 드는 대형 회사들을 대상으로 컨설팅하고 연구했다.
[레슬리 A. 퍼로우]레슬리가 이 일을 하며 발견한 것 중 하나가 고액 연봉을 주는 회사들의 고학력 인재들이 때때로 매우 비효율적으로 일한다는 것이었다. 심지어 서로를 너무 존중하여 팀에 필요한 이야기를 제때에 하지도 못했다. 이의 실 예제를 들어보면 다음과 같다.
-----------------------------------
“보통 3~5년 정도의 기간 동안 프로젝트를 수행하던 회사가 있다.
이 회사에는 최상의 성과를 내기 위해 만들어진 방법론이 있다. 이 방법론을 활용하여 이들은 매달 2회 각 4시간의 워크숍을 통해 '팀 전체 공유 및 브레인스토밍'을 수행했다. 그리고 이 미팅을 통해 나온 데이터와 개선 제안들을 의사결정자들에게 보고했다. 관련된 프레젠테이션을 준비하고 의사결정자들의 눈높이에 맞추기 위해 프로젝트 열심히 노력했다.
그러던 어느 날 문제가 생겼다. 프로젝트의 기간이 3년에서 9개월로 당겨진 것이다. 하지만 훌륭한 인력들은 크게 걱정하지 않았고 이전처럼 열심히 일했다. 그들은 과거 수행해왔던 노하우로부터 모든 것을 계획하고 착착 업무를 수행했다. 처음에는 이 진행방식이 완벽해 보였다. 하지만 시간이 흘러가면서 조금씩 문제가 발생하고 커지기 시작했다.
그들은 과거에 일하던 방법을 그대로 활용했다. 매달 두 번 4시간 동안의 워크숍을 계획했다. 다만 프로젝트 기간이 짧아졌기 때문에, 한 달 대신에 일주일 단위로 화요일 목요일에 두 번의 워크샵을 했다. 또한 의사결정자들에게 생각을 공유하기 위해 똑같이 프레젠테이션을 준비했다. 4시간 회의를 위한 리포트 준비와 의사결정자들을 위한 프레젠테이션에 이전 3년 프로젝트 수행 시만큼의 똑같은 공수를 들였다. 모두가 이전에 보던 품질의 결과물을 기대했기 때문이다. 시간적인 측면에서 많은 것이 달랐다. 정말로 물리적인 시간이 부족했다. 그러다 보니, 모든 구성원들의 야근과 주말 근무가 시작되었다.
문제는 여기서 부터였다. 리포트를 위한 준비는 정작 프로젝트 수행을 위한 다른 사안들을 지연시켰다. 그 지연은 더 많은 야근과 주말 근무를 발생시켰다. 하지만, 이러한 문제를 감지했더라도, 의사 결정자들에게 현재 상황을 문제라고 이야기하는 사람은 없었다. 해당 프로젝트가 회사에 매우 중요한 것이었기에, 모두가 자존심을 걸고 열심히 프로젝트를 성공시키기 위해서만 노력했다.
얼마 후 팀원들이 정말 열심히 일하는 것을 안타깝게 보면 중간 관리자들이 그들의 팀원을 위해 현재 실적을 프로젝트 관리자에게 부풀려 보고하는 상황들이 발생했다. 이는 문제를 더 크게 만들었다. 이미 진행됐다고 보고한 일들에 새로운 일들까지 더 해져 더 짧은 시간에 작업을 더 많이 수행해야 했다. 악순환이었다.
아무리 팀을 위해서였다지만, 중간 관리자들의 허위보고 때문에 문제가 더 커졌다고 생각한 실무자들은 중간관리자에게 불만을 갖기 시작했다. 하지만 실무자들 중에 누구도 이를 중간관리자에게 명확하게 이야기하지 않았다.
중간관리자들은 프로젝트 관리자에게 불만을 갖기 시작했다. 이러한 서로가 엮여있는 문제의 매듭은 프로젝트 관리자가 풀어야 한다고 생각했다. 하지만 프로젝트 관리자는 상황을 제대로 몰랐고, 자신은 최고의 팀원들을 데리고 일하고 있다는 굳은 믿음이 있었기에, 상황을 팀원들에게 꼬치꼬치 물으려고 하지 않았다. 그가 팀원들을 신뢰하지 않는다는 느낌을 주고 싶지 않았다.
얼마후, 그렇게 훌륭하던 팀원들은 서로가 서로를 신뢰하지 않는다는 것을 알게되었다. 가장 중요했던 프로젝트의 훌륭한 구성원들 모두가 불만에 가득 찼다. 9개월 후 결과적으로 프로젝트는 후반기에 커다란 이슈들이 발생하여 실패했고, 회사는 커다란 손실을 입었다. “
-----------------------------------
여러분이 일하는 환경에서 위의 이야기 같은 일이 관찰되는 경우가 있는가? 이 일화는 매우 많은 회사들에서 흔히 발견되는 패턴이다. 이전에 관습에 의해 잘못된 행위들이 만들어지는 것이고, 레슬리 교수는 이를 “일터에서 침묵으로 만들어지는 혼란(Silencing conflict at work)”이라 정의한다.
즉, 문제가 있을 때는 필요한 말을 제때에 하고 이를 개선하는 것이 중요하다. 이 상황에 누가 프로젝트의 문제점을 찾고 개선할 수 있을까? 팀 안에서 이러한 문제를 해결할 수 있으면 물론 가장 좋겠지만, 그렇지 못한 경우들이 있다. 필자의 경험상 애자일 코치는 이러한 일을 하는데 매우 좋은 역할자이다. 팀 안에 들어가 전체 가치 체인을 보고, 개선할 부분을 찾고 팀과 함께 실행할 수 있다.
* 필요한 말을 제때에 하자.
필자는 ‘09년 레슬리가 경험한 것과 비슷한 일을 겪었다. 커리어에서 처음 수행했던 애자일 코치로서의 첫 번째 대형 프로젝트에서였다. 필자는 프로젝트가 애자일이 필요하다는 설득에 프로젝트에 코치로 참여하게 되었다.
해당 프로젝트에는 120명의 팀원이 있었다. A사 40명, B사 40명, 그리고 B사의 외주계약으로 들어온 C사 인력이 40명이었다.
이 프로젝트는 9개월 간 매우 많은 양의 개발을 해야 하는 프로젝트였다. 초 단납기에 프로젝트르 수행해야 했다. 하지만, 필자가 다녀본 어떤 팀보다 훌륭한 맨파워를 가지고 있었다. 경험과 기술 모두 훌륭했다. 해당 업무에 대해 7년 이상 프로젝트를 수행하면서 잔뼈가 굵은 사람들이었고, 심지어 이들은 대부분 좋은 학력의 소유자들이었고 열정적이었다.
필자가 애자일 코치로 프로젝트에 투입되자마자 처음 했던 것은 관찰이었다. 전체 팀을 일주일 간 관찰하며 어떻게 팀을 개선할지 고민했다. 얼마 후 한 가지 문제를 관찰하게 된다. 아래의 타임라인을 보고, 여기서의 실제 문제가 무엇인지 함께 생각해보자. 이슈 발생 후 어떻게 해결되는지 과정을 보자.
-----------------------------------
1일 차.
- A사 개발자가 B사 개발자와 협업 중에 이슈를 발견한다. (1일 차 오후 4시)
2일 자.
- A사 개발자는 A사 중간관리자에게 문제를 이야기했다.(2일 차 오전 9시 30분)
3일 차.
- A사 중간관리자는 A사 프로젝트 관리자에게 이슈를 문제를 전달했다.(3일 차 오전 9시)
- A사 프로젝트 관리자는 B사 프로젝트 관리자에게 문제를 공유했다. (3일 차 오전 10시)
3일 차.
- B사 프로젝트 관리자는 B사 중간관리자에게 이슈 해결방안을 전달했다.(4일 차 오전 9시)
- B사 중간관리자는 B사 개발자와 이야기하며, 문제를 해결했다. (4일 차 오전 9시 30분)
-----------------------------------
여러분이 위 상황을 보면, 문제의 해결에 왜 이렇게 많은 시간이 소요되어야 하는지 궁금해질 것이다. 문제를 전달하고 해결하는데 꼬박 4일이 걸렸다. 이슈를 해결하는데, 이렇게 많은 시간이 소요된 이유가 무엇일까? 원인을 찾기 위해 아래의 커뮤니케이션 체계를 보자.
[A, B사 회의 체계]- 9:00 프로젝트 관리자+중간관리자 회의 - A사 프로젝트 관리자, 중간관리자 회의 (1번 회의실), B사 프로젝트 관리자, 중간관리자 회의(2번 회의실)
- 9:30 팀 회의 - A사 중간관리자, 팀원들과의 회의(각 팀 사무실) B사 중간관리자, 팀원들과의 회의(각 팀 사무실)
- 10:00 PMO 회의 - A, B사 통합 PMO회의(1번 회의실)
위의 커뮤니케이션 방식은 매우 일반적으로 보인다. 대형 프로젝트에는 이슈를 해결하기 위해 보통 위와 같은 계층형 프로젝트 회의 체계를 만든다. 이는 프로젝트의 효율을 극대화하기 위해 적합한 채널들을 만드는 것이다.
하지만, 개발자가 상향으로 이슈를 제기하고 문제를 해결하는 데는 그다지 합리적이지 않아 보인다. 각 타임라인 별 이벤트를 커뮤니케이션 체계와 함께 생각하면 다음과 같다.
[A사 개발자가 B사 개발자에 대해 제기한 이슈가 해결되는 방법]관찰 후, 프로젝트 관리자과 중간관리자를 인터뷰하며 왜 위와 같은 커뮤니케이션 방식을 선택했는지 물었다. 그들의 답은 다음과 같았다.
“사실, 특별할 것은 없어요. 먼저 9시와 10시 회의를 만들었습니다. 9시는 프로젝트 관리자과 중간관리자 간의 회의, 10시는 PMO회의였죠. 하지만 프로젝트 초기에 정해야 할 것이 많아지면서 PMO회의마다의 전달사항이 점점 많아지기 시작했습니다. 이에 중간관리자들이 팀원들을 공식적으로 만나는 자리를 가지기 원했습니다. 그래서 9시 30분 회의가 만들어졌죠.”
일을 하다 자연스레 만들어질 수 있는 형태의 커뮤니케이션가 병목을 만들었다. 이 팀은 3주 때 이러한 방식으로 미팅을 하고 있었다. 이들에게 현재 상황을 변화시킬 수 있는 무언가가 필요했다.
필자는 PMO 회의에서 프로젝트 관리자과 중간관리자 들을 대상으로 애자일을 수행하자고 하면서, 우선 데일리 스크럼을 해보자고 했다. 이를 통해 하고 싶었던 것은 물론 커뮤니케이션 방식의 변경이었다.
우선 팀 별로 10명에서 30명까지 있던 인원들을 10명 이하의 스크럼으로 변형했다. 업무별로 1~3개의 스크럼이 생겼고, 해당 스크럼 당 A사의 리더를 PL, B사의 리더를 제품책임자(PO)라고 불렀다.
둘의 역할은 PL은 일정 및 이슈 관리, PO는 기능에 대한 정의였다. 그리고 하위 스크럼 팀마다 스크럼 마스터 역할을 부여하여, 수시로 PL, 제품책임자와 이야기하자고 제안했다.
각 팀은 데일리 스크럼이라는 저녁에 수행한 회의를 통해 팀 내 이슈를 공유하고 도출하며 필요한 경우 이를 에스컬레이션 한다. 즉, PL에게는 이슈 전달, PO에게는 이슈 공유를 수행한다.
그리고 이 PL, PO들이 모여 회의를 함께 진행하는 것을 제안했다. 그리고 PMO는 기존에 참석하던 프로젝트 관리자과 PL과 PO대표가 함께 참석하자고 제안했다. 이 체계를 개선하면 다음과 같았다.
[개선한 미팅 체계]- 1일 차 오후 5시 45분: 데일리 스크럼 (5분~10분)
- 2일 차 오전 9시 45분: A, B사 PL, PO 통합회의(15~20분)
- 2일 차 오전 10시: PMO 회의 - A, B사 공동 PMO회의(1번 회의실)
이렇게 변경하자 대부분의 문제들이 하루 안에 해결되는 상황으로 개선되었다. 피드백이 빨라지고, 팀 전체적으로 초기 이슈를 빨리 해결하게 되었다.
[개선된 타임라인 및 커뮤니케이션 방법]1일 차
- A사 개발자가 B사 개발자와 협업 중에 이슈를 발견한다. (1일 차 오후 4시)
- A사 개발자는 A사 중간관리자에게 문제를 이야기했다.(1일 차 오후 5시 45분)
2일 차
- A사 개발자는 A사 중간관리자, B사 중간관리자에게 문제를 이야기하고 해결방안을 찾고, PMO회의에서 공유를 결정한다. (2일 차 오전 9시)
- PMO회의에서 문제를 공유하고 해결방법을 찾는다. (2일 차 오전 10시)
- B사 중간관리자는 B사 개발자와 이야기하며 문제를 해결했다.(2일 차 오후 5시 45분)
이러한 시도로 120명이 일하는 거대 프로젝트의 커뮤니케이션 및 의사결정 채널 리드타임이 사흘에서 이틀로 줄었다.
여러분들의 주변에서도 비슷한 느낌의 상황을 심심치 않게 관찰할 수 있을 것이라 생각한다. 뭔가 다들 정말 열심히 하는데, 크게 보면 비효율적인 무엇인가가 있는 상황이 종종 있다. 여러분이 볼 때 문제라고 생각하면, 문제를 발견학 해결하는 촉매가 되어보면 어떨까?
기억하자. 똑똑한 사람들이 멍청하게 일하는 상황은 발생할 수 있다.
