한빛출판네트워크

 

『개발 7년차, 매니저 1일차』 356쪽 중

 

프로젝트를 효율적으로 잘 관리한다는 것은 험하고 먼 길을 걷는 것과 같습니다. 목적지로 가는 길이 여러 갈래일 수 있듯이 프로젝트 또한 다양한 방식으로 관리될 수 있습니다. 상황에 따라서는 효율성을 평가하는 기준이 달라집니다. 예를 들어, 여러 팀이 공동 개발하는 프로젝트의 경우 팀 간의 개발 진척상황 공유가 프로젝트 효율성에 중요한 반면, 서비스 운영 프로젝트의 경우 해야 할 일의 우선순위를 정하는 과정이 효율성에 더 중요할 수 있습니다.

다시 말해서 특정 프로젝트 관리 방법이 모든 프로젝트에 효율적이라고 단언할 수 없습니다. 프로젝트를 효율적으로 관리하기 위해서는 내가 속해 있는 환경과 프로젝트의 성격을 잘 이해하고, 그 속에서 가장 효율적인 프로세스를 만들어야 합니다. 그렇다고 해서 여지껏 본 적 없는 독창적인 프로세스를 만드는 것은 추천하지 않습니다. 관리 방법의 발전 속도는 기술의 발전에 비해 비할 수 없을 만큼 느립니다. 효율적인 프로세스를 만든다는 것은 보편적으로 통용되는 관리 방법을 토대로 상황에 맞게 약간 변화를 주는 정도입니다.

프로젝트 관리를 험하고 먼 길을 걷는 것이라고 말한 이유는, 프로젝트란 사람들이 모여서 산출물을 만드는 과정이며, 사람과의 관계에서 발생하는 문제 해결과 끝없이 변하는 상황에 적합한 프로세스를 만들어가는 과정이기 때문입니다. 처음부터 프로젝트 관리를 잘하기 위한 정답을 찾기보단 최선의 선택을 위해 많은 경험을 쌓는 것이 더 중요합니다. 경험이 쌓이다 보면 언젠가는 최선의 선택이 그 상황에 꼭 맞는 정답이 될 수 있습니다.

지금부터 제가 중요하게 생각하는 프로젝트 관리 항목 중 하나를 설명하고 어떤 식으로 사용될 수 있는지 사례를 들어 설명하겠습니다.

· · ·

첫째 ‘공유의 힘’입니다. 성숙되지 않은 조직에서는 정보가 공유되지 않곤 합니다. 이런 조직에서는 다들 자기만의 노하우라 여기는 것들을 숨기고 그것이 자신의 가치로 평가되길 원합니다. 작업의 진척 상황을 알려주지 않는 경우도 있습니다. 계획된 작업이 완료되었다 하더라도 마지막 날이 되기 전까지 알리지 않습니다.

크게 두 가지 이유가 있습니다. 첫 번째 이유는 작업이 끝난 뒤 종료일까지 일하지 않기 위해서입니다. 정말 열심히 기한 내에 처리했든 일정 계산을 과하게 했든 상관없이 작업이 완료되었다는 것이 알려지면, 남은 일정과 상관없이 다른 작업을 맡게 되기 때문입니다. 대부분의 업무 담당자는 일정을 길게 잡으려 합니다. 그렇기 때문에 이미 그 작업을 경험해본 프로젝트 매니저와 일정을 산정할 때 의견이 충돌하곤 합니다. 두 번째 이유는 스스로 만족할 때까지 노력하고 싶기 때문입니다. 첫 번째와 비교하면 바람직하다 할 수도 있지만 어쨌든 작업 진척도가 공유되지 않기는 마찬가지입니다.

공유하지 않는 것은 어떻게 보면 인간의 본능일지도 모릅니다. 내가 준비하고 있는 것을 남에게 알려주고 싶어하지 않는 겁니다. 사람들은 본인의 일이 공유되거나 또는 공개되는 순간 마음이 편치 않습니다. 나만 알고 있던 것들을 남들도 알게 되면 압박을 느끼고 긴장합니다. 반대로 생각해봅시다. 나만의 일을 공유했을 때 동료들의 칭찬, 격려를 받는다면 사람들은 쉽게 그리고 자주 공유할 것입니다. 공유가 편해지는 최소한의 조건은 팀 내에서 나의 안전입니다.

그렇다면 안전한 환경은 어떻게 만들 수 있을까요? 안전한 환경이란 솔직히 표현하자면 덜 위험한 환경이며, 문화와 프로세스를 통해 만들 수 있습니다. 예를 들어 해외 여행을 간다고 합시다. 어느 나라에 가면 어떤 것을 하지 말라거나 어떤 것을 하라는 등 문화적인 차이로 인해 알아야 할 것들이 있습니다. 우리가 수영복을 입고 거리를 돌아다닌다면 눈총을 받겠지만, 수영장이라면 누구도 이상하게 보지 않을 것입니다.

· · ·

· · ·

아마도 많은 분들이 애자일이나 스크럼에 대해서 들어봤을 겁니다. 이제는 너무 흔하게 사용되기에 자세하게 설명하지 않겠습니다. 앞서 소개한 이야기들을 애자일 방식으로 생각해 봅시다. 스프린트 미팅에 모두 모여 각자의 업무를 리뷰하고, 스토리를 만들어 미리 공유하고, 매일 모여서 서로 업데이트합니다. 이런 몇 가지 규칙을 정해서 ‘공유’하는 여러 상황을 익숙하게 만들고 이를 프로세스로, 문화로 정착시킵니다. 어떤 행위를 문화라고 인식하는 순간 사람들은 왜 그렇게 해야 하는지 생각하기보단 어떻게 해야 잘 할 수 있는지를 먼저 생각합니다.

애자일 방식은 이런 일련의 행위를 통해 내 업무와 진척 과정이 ‘공유’되는 것이 당연하다는 문화를 형성합니다. 공유를 통해 여러 사람의 피드백을 받아 결과물을 개선하고, 나의 업무가 다른 이의 업무에 참조가 됩니다.

· · ·

이번에는 공유가 압박이 되는 실제 사례를 예로 들겠습니다. 개발조직에는 개발자만 있는 것은 아닙니다. 기획자, 디자이너, 프로젝트 매니저, 일반 매니저 등 조직의 목표 달성을 위한 다양한 직군들이 속해 있습니다.

이름만 들으면 모두 알만 한 유명한 제품/서비스가 출시를 앞둔 때였습니다. 대내외의 관심이 집중된 제품 출시를 앞두면 담당자들뿐 아니라 회사 전체에 스트레스가 최고조를 찍습니다. 야근과 주말 근무가 이어지다 보면 별것 아닌 이유로도 담당자끼리 충돌하는 일이 잦아집니다. 제품 개발 막바지 단계에서는 주로 버그 수정에 가장 많은 시간과 노력을 들입니다.

이 시기에는 다들 번아웃 상태지만 다들 정말 열심히 버그를 수정합니다. 버그 수정은 항상 우선순위와 심각도^{Severity 또는 Urgency}에 따라서 어떤 버그가 먼저 고칠지 결정합니다. 보통 버그는 1~5의 우선순위를 가지고 있습니다. 1은 최대한 빨리 수정해야 하는 크리티컬한 버그, 5는 수정하지 않아도 큰 영향이 없는 버그란 의미입니다. 출시일까지 남은 날이 많을수록 우선순위가 낮은 버그까지 수정하는 반면, 출시일과 가까워질수록 우선순위가 높은 버그 수정에 집중합니다. 그렇다 보니 중간 또는 그보다 낮은 우선순위의 버그들이 많이 남겠지만요.

이 프로세스가 잘못됐다고 할 수는 없습니다. 프로젝트 관리의 3요소(리소스, 범위, 일정)에서 일정 변경이 안 되니 리소스를 더 투입하거나 우선순위가 낮은 버그를 고치지 않는 것은 분명 합리적입니다. 막바지에 리소스를 더 투입하는 것은 큰 의미가 없기에 이미 할 수 있는 모든 것을 하고 있다고 봐야 합니다.

나무가 아닌 숲을 보라는 말이 있습니다. 전문가 집단에는 나무만 보고 싶어하는 분들이 적지 않습니다. 내 일에만 관심이 있지 남의 일이나 전체 일까지 신경 쓰고 싶지 않은 것입니다. 한 가지에 심취한, 나무만 보는 분들이 대단한 일을 해내기는 높지만, 가끔은 먼저 숲을 보고 나면 나무가 더 잘 보일 때도 있습니다.

그래서 전체적인 준비 상황을 한눈에 볼 수 있는 통계 자료를 만들어 모든 관련자에게 매일 리포트를 보냈습니다. 통계는 아주 간단합니다. 얼마나 많은 버그가 있는지, 그 버그의 우선순위는 몇 인지, 매일 발생하고 수정되는 버그는 얼마나 되는지, 출시 시점에 어느 정도의 버그가 남을지 등이었습니다. 여기에 단 한 가지 항목이 없다면 어쩌면 정성스럽게 만든 통계 데이터와 리포트를 읽지 않는 사람들이 많았을 겁니다. 그 한 가지가 무엇일까요?

그것은 담당자별로 가지고 있는 버그의 개수입니다. 처음부터 리포트에 넣었던 것은 아닙니다. 리포트를 보낸지 얼마 지나지 않아 매니저를 제외한 실무자들은 이 통계 자료에 흥미를 잃었습니다. 실무자가 보지 않으면 이 리포트는 생산력과 품질에 아무런 영향을 주지 못합니다. 그래서 담당자별 버그 현황을 추가했습니다.

전 직장에서 해봤기 때문에 이 리포트가 어떤 결과를 가져올지 전 이미 예상할 수 있었습니다. 반응은 폭발적이었습니다. “수정했지만 버그 티켓을 종료 처리하지 않았다.” “다른 담당자의 버그가 나에게 잘못 할당됐다.” “이것은 버그가 아니다.” 등 엄청난 항의가 들어오기 시작했습니다. 티켓을 올바르게 업데이트하고, 담당자를 찾아 다시 넘겨주고, 버그가 아닌지 확인하는 과정은 그리 오래 걸리지 않았습니다. 각자가 처리하기 때문에 빠르게 정리되었습니다. 그 뒤 어떻게 되었을까요? 놀랄 만큼 버그가 사라졌습니다. 그뿐만이 아닙니다. 정리되고 남아 있는 버그들이 처리되는 속도는 담당자별 버그 개수를 공개하기 전후로 완전히 달라졌습니다. 대신 저와 담당자들의 관계는 제가 준 스트레스만큼 나빠졌습니다. 제품의 품질과 약간의 인간관계를 맞바꾼 결정이었습니다.

이 사례도 정답은 아닐 것입니다. 단지 주어진 상황에서 품질을 높이기 위해 선택한 고육지책이었을 뿐 다른 조직에 통용되기에는 무리가 있습니다. 효율적인 프로젝트 관리는 여러 요소들을 종합적으로 생각하고 결정해야 합니다. 저는 단지 두 가지 사례를 들었지만 더 나은 방법이 어딘가에 있을 것입니다. 경험이 쌓일수록 더 세분화되고 더 효율적인 방법을 찾아낼 수 있습니다.

· · ·

지금까지 간단한 사례를 통해 ‘공유’하기의 현실적인 의미를 이야기했습니다. 회사를 다니면서 그리고 많은 프로젝트를 진행하면서 이것만은 올바르다고 생각되는 것이 있습니다. 어떤 것과도 타협하기 싫은 것이 있습니다. 제게는 그것이 바로 ‘공유’입니다. 투명하고 솔직하게 공유되는 정보는, 그 정보가 부정적인 내용일지라도 비판해서는 안 됩니다. 투명하게 모든 것을 공유한다는 것은 용기 없이 할 수 없습니다. 우리는 그러한 용기에 감사해야 합니다. 그런 용기 있는 문화를 만들어야 합니다.

 

배상언