Thoughts2011.04.28 16:07
언더커버 보스라는 텔레비전 프로그램이 있습니다. 회사의 CEO (그러니까 보스죠)로 하여금 회사의 밑바닥 생활을 경험하게 하는 것이 골자인 프로그램이죠.



이 프로그램의 구성은 단순합니다. CEO를 변장시켜서 회사의 말단 직원으로 투입합니다. 그런 다음 한 일주일 동안 뺑이(?)를 치게 합니다. 이 과정을 통해 CEO는 회사를 지탱하는 말단 직원들의 고충과 비효율을 경험하죠. 그런 다음 다시 자기 자리로 돌아갑니다. 그리고 나서는 그들의 근무 환경과 효율을 개선할 새로운 아이디어나 제도를 내놓고, 자신에게 풍성한(?) 교훈을 안겨준 직원들에게 포상을 합니다. 그리고는 끝.

물론 이런 식의 프로그램이 갖는 문제점을 나열하라면 한도 끝도 없습니다. 포상을 받는 직원을 제외한 다른 직원들은, 그런 기회를 누릴 자격이 없었던 걸까요? 아마 아닐 겁니다. 그러니, 오늘은 그냥 리더쉽 이야기만 하도록 하죠.

언더커버 보스라는 프로그램이 나름대로 고정 시청자를 확보하면서 지속적으로 방영되고 있는 이유를 곱씹어보면 별게 없습니다. 그저 옛 성현의 말을 그대로 실천했을 뿐이죠.

"니가 한번 해봐라. 말만큼 쉽나."

겪어 보지 않으면 모른다

일반적인 관리자들이 빠지기 쉬운 함정 중 하나는, '위에서 보면 모든 것이 단순해 보인다'라는 점입니다. 그도 그럴 것이, 관리자들이 갖게 되는 지식의 대부분은 '보고 체계'를 통해 전달된 것들입니다. 보고라는 것은 보통 텍스트와 이미지로 구성된 문서입니다. 보고하는 사람에 의해 한 번 추상화(abstraction)된 결과물이죠.

관리자는 보통 이 추상화된 결과물들이 만들어 내는 다이어그램들의 연결관계로 문제를 파악합니다. 추상화의 핵심은 단순화(simplification)입니다. 단순하게 정리되지 않은 결과물을 보고하는 사람은 없습니다. 관리자는 보통 한번에 여러 직원들과 문제들을 상대하게 마련이고, 스스로 결과물을 분석할 시간적 여력이 없습니다. 그러니 관리자에게 보고되는 내용들은 가능한 한 단순화되어야 하고, 그 과정에서 문제의 세부사항은 생략되게 마련입니다.

어떻게 보고 해야 하나

세부사항이 생략될 경우에 발생하는 가장 큰 위험은 '관리자가 보는 일정 추정치'와 '직원들이 보는 일정 추정치'가 달라진다는 점입니다. 관리자들은 태스크 스위칭 오버헤드 같은 세부사항에 신경을 쓰지 않기 때문에 직원들에게 가능한 한 많은 일거리를 주려는 경향이 있고, 이런 일거리들이 어떻게 프로젝트를 지연시키는 지에 대해서는 신경을 쓰지 않습니다.

그런 상황에서 '참 또는 거짓' 그러니까 '무엇이 됐고 무엇이 실패했다'는 식으로 보고를 하게 되면, 일정 추정치를 정확하게 만들수가 없게 됩니다. 해결책은 문제를 둘러싼 상황적 맥락(context)을 기술하는 것이죠.

문제는 '상황적 맥락'이라는 것이 굉장히 모호하다는 겁니다. 여러분은 여러분이 처한 환경을 몇 줄 만으로, 가능한한 정확하게 묘사하려는 시도를 해 보신적이 있으십니까? 상황적 맥락은 텍스트로 추상화하기 가장 어려운 부분 중 하나입니다.

문제점 리스트가 왜 중요한가

상황적 맥락을 기술하기가 어렵다면, 프로젝트 진행 중간에 발생하는 이벤트들을 기록해 두는 것이 도움이 됩니다. 이런 이벤트들은 이슈 추적 시스템(issue tracking system)을 통해서 나열해 둘 수 있습니다. 이슈들의 발생 빈도, 이슈들의 양 등을 정확하게 기록해두면, 프로젝트 중간중간에 어떤 일들이 발생했고 그 일이 어떤 환경에서 발생했으며 어떤 맥락에서 처리되었는지 확인할 수 있습니다.

문제점 리스트가 갖는 가장 큰 장점은 '관리자들이 좋아하는 추상화된 형태'로 보여주기 좋다는 점이죠. 개수, 양, 그래프 등등 고도로 추상화된 수단을 동원해 시각화하기 편하다는 거에요.말로 설명하면 납득하지 못하는 사람도, 제대로 정리된 그래프를 보여주면서 이야기하면 프로젝트 중간에 발생한 불확실성의 수준을 이해하는 경향이 있으니까요.


위의 사진에서처럼 '실제로 겪어본다는 것'에는 영감을 불러 일으키는 마력이 있습니다. 지금 관리자인 사람들도 과거에는 말단 직원이었을 거에요. '경험'이라는 것에는 마력같은 부분이 있죠. 보통 관리자들이 갖고 있는 '과거의 기억'은 윤색되기 마련입니다. '과거에 나는 이랬어!' 뭐 이런 자부심 같은 것들이죠.

문제는 그런 자부심이 나쁘다는 것이 아니라, 그런 자부심이 때로 프로젝트 진행 당사자가 겪는 문제들을 올바르게 파악하지 못하도록 방해한다는 점입니다.

언더커버 보스의 CEO들도 회사의 발전을 위해 고군분투하고 있다는 점에서는 다른 직원들과 다를 바가 없는 사람들입니다. 다만 그들에게 주어지는 정보의 양이 제한적이다 보니, 프로젝트 진도와 방향에 대해, 더 나아가서는 회사의 발전 방향에 대해 '오해'를 할 수 있다는 것이 문제일 뿐이죠.

관리자들이 여러분 주변의 문제를 더 자주 파악할 수 있도록, 눈에 잘 띄는 곳에 문제점 리스트를 두세요. 그리고 그 문제점 리스트가 왁자지껄해지도록 만드세요. 할 수 있다면, 익명 게시판 같은 형태도 나쁘진 않을 겁니다. (많은 사람들이 선호하는 방법은 아니지만요.) 그럼 아마 관리자들은 여러분들이 무슨 생각을 하고 있는지, 현장에서 무슨 일들이 벌어지고 있는지 더 잘 파악할 수 있을겁니다.

물론 어떤 관리자들은 그런 정보를 봐도 '그건 네가 잘 몰라서 그래'라고 말할지 모릅니다. 하지만 그런 상황에 처하더라도, 어떤 의미에서건 '문제를 노출한다는 것'은 좋은 거에요.

한두번이면 모르겠지만, 잽도 여러번 때리다 보면 결정적 한방이 될 수 있거든요.





신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 잘보고 갑니다

    2011.04.28 16:17 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2008.09.24 11:49

불확실성(Uncertainty) : 장래 일어날 수 있는 사상()에 관해서 인간이 가진 정보의 정확성에 대한 하나의 구분. (출처 : 네이버 백과사전)

네이버 백과사전에 나온 불확실성의 정의에 따르면, 의사결정자가 가지고 있는 정보의 정확성은 ㉠ 확실성, ㉡ 리스크(risk), ㉢ 불확실성, ㉣ 무지()의 4종류로 분류할 수 있다고 합니다. 관련 부분을 인용해보죠.

㉠의 확실성은 무엇이 일어날지 확정적으로 알고 있는 경우를 말한다. ㉡의 리스크는 무엇이 일어날지 확정적으로는 알 수 없으나, 일어날 수 있는 상태는 알고 있고, 또 그 확률분포()도 알고 있는 경우를 말한다. 이에 대하여 ㉢의 불확실성은 일어날 수 있는 상태는 알고 있으나, 그 확률분포를 알지 못하는 경우를 말한다. ㉣의 무지란 무엇이 일어날지, 어떠한 상태가 일어날지, 전혀 예견할 수 없는 경우를 말한다. 한편, 넓은 뜻의 불확실성이란 ㉡의 리스크와 ㉢의 불확실성의 양자를 가리킨다.

이런 개념을 최초로 정립한 사람들은 경제학자들입니다. 돈이 걸리면 어떻게든 위험성을 줄이는 것이 좋으니까, 당연하겠죠. 소프트웨어 프로젝트에도 돈이 걸려 있기 때문에, 무슨 방법을 쓰던 위험성을 줄이면 줄일수록 이득입니다.

하지만 '확실성'이 갖는 정의 - 무엇이 일어날 지 확정적으로 알고 있는 경우 - 에 비추어보면, 확실성이란 달성이 불가능한 꿈과 같습니다. 확실성을 성취하려면 타임머신을 발명하던가 해야 합니다. '아무 일도 하지 않으면 되지 않느냐?'고 물으실 분도 계실 것 같은데, 아무 일도 하지 않으면 그 순간부터 유보수익이 사라지고, 기회비용 문제가 발생하기 시작합니다.

하지만 '불확실성'에 대한 '확실한 사실'이 한가지 있긴 합니다. 우리가 알고자 하는 것이 미래의 특정 시점에 일어날 사건에 대한 불확실성의 정도라고  한다면, 이 불확실성은 그 시점에 가까이 가면 갈수록 감소하는 경향을 보인다는 것이죠. 가령 우리 아기가 몇개월때 첫 걸음마를 뗄 것인지를 알고 싶다고 해 봅시다. 그리고 18개월쯤에는 첫걸음마를 뗄 것으로 예상한다고 해 봅시다. 이 예상이 갖는 불확실성은 시간이 흘러 18개월 근처로 가면 갈수록 감소합니다. 17개월이 되었는데도 엎드려 고개를 드는 것이 고작이라고 한다면? 아마 18개월에 첫 걸음마를 떼기는 힘들어지겠죠. 예상이 맞건 틀리건, 불확실성은 이런 식으로 감소 추세를 보이기 시작합니다. (물론 아이가 예상하지 못한 병에 걸린다거나 하는 불행한 일이 생기면 불확실성이 급상승하는 일도 생길 수 있긴 하겠습니다.)

불확실성이 갖는 이러한 속성과, 확실성, 위험, 지식이 갖는 속성들을 종합해 보면, 우리는 분명해 보이는 몇 가지 결론에 이르게 됩니다.

1. 시간이 흐르면 불확실성은 차츰 감소한다.
2. 지식이 늘어나면 불확실성은 차츰 감소한다.

이 지식에는 '확률적 지식'도 포함됩니다. 시간이 흐르면 사람들은 '어떤 사실'의 '발생 가능성'에 대한 지식을 자연스럽게 취득하게 됩니다. 확률적 지식이 100% 정확하다고는 볼 수 없습니다만, 적어도 한 잣대는 되어줄 수 있기 때문에, 불확실성은 그에 따라 차츰 감소하게 됩니다.

이런 불확실성의 개념이 소프트웨어 개발 프로젝트 관리 방법론의 한 근간으로 등장한 것은 사실 오래된 일입니다. 1981년 베리 뵘은 이후 스티브 멕코넬이 '불확실성 원추(Cone of Uncertainty)'라고 부르게 되는 그래프를 하나 그렸는데, 이것이 시발이라고 봐도 무방할 것 같습니다. 이 그래프가 보여주는 것은 사실 위에 제시했던 두 가지 뻔한 결론에 다름 아닙니다. 하지만 전통적인 개발 방법론이 이 자명한 사실을 인정하게 되는 데는 약간의 시간이 필요했죠. 애자일 선언문이 발표된 것이 2001년도이니까, 그 사람들이 지금은 '애자일'이라고 불리는 방법론을 가다듬는 데 필요했을 10년 정도의 세월을 감안하면, 불확실성이 화두로 등장하는 데는 10년 정도의 시간이 필요했다고 봐도 될 것 같네요.

그럼  불확실성이 프로젝트 관리에 있어서 가장 중요한 문제중 하나로 등장한 이유는 뭘까요? 아마 다 아시겠지만, 그것은 초기 계획대로 굴러가는 프로젝트가 별로 없기 때문이며, 초기 설계대로 우아하게 마무리되는 프로그램이 별로 없기 때문이고, 그런 일이 빈번하게 생기면 프로젝트 팀원들의 '꼭지가 돌아버리기' 때문입니다. 그리고 그런 프로젝트는 고객에게 '최선의 가치를 전달'하기가 점점 더 어려워지죠. 전통적인 방법론들은 프로젝트 도중에도 불쑥 뿔쑥 등장하곤 하는 이런 '꼭지도는 일들'을 어떻게 처리해야 하는지에 대해서는 별 이야기가 없습니다.

이쯤에서 이미 식상해졌을 지도 모를 애자일 이야기를 조금만 더 하자면... 애자일 방법론은 사실 불확실성에 관한 방법론입니다. 흔한 오해중에 한가지는 '애자일 방법론은 고객 중심 방법론이다'라는 것인데, 사실 이 이야기는 반 정도는 맞고 반 정도는 틀립니다. 사용자를 무조건 만족시키는 것이 애자일 방법론의 목표는 아니기 때문이죠. 고객이 중요한 것은, 사용자가 프로젝트의 성패에 관련된 가장 중요한 이해 당사자 중 하나이기 때문입니다. 고객을 중요하게 생각하는 것은, 그들과 어떻게 의사소통하느냐에 따라 프로젝트의 불확실성 정도가 굉장히 많이 달라질 수 있기 때문입니다.

흔히 보는 장면
A : 이번 프로젝트의 요구사항 명세표를 분석해야 하는데요.
B : 누가 작성한 명세표죠?
C : 영업팀에서 작성한 겁니다.
D : 그거 영업 팀에서 분석해야 하는거 아닌가?
A : 이전 프로젝트 결과를 토대로 우리가 추가해줬음 하는 것도 있어서요.
B : 그런걸 요구사항이라고 부를 수 있나요?
A : 엇비슷한 프로젝트니까 일단은 그렇게 하고 프로젝트를 진행해달라는 게 '영업팀의' 요구사항이죠.
B : 왜?
C : 받아온 프로젝트 기간이 좀 빡빡해서요.
(2달 후)
A : 우리가 구현한 기능들 중 한 열개 항목 정도가 잘못되었다는 군요.
B : 누가 그래?
A : 고객이요.

보통 개발자들이 고객을 미워하는 이유는 개발자들이 보기에 고객이란 사람들이 '뭘 잘 모르는 사람들'처럼 보이기 때문도 있습니다만, 가장 큰 이유는 프로젝트 진행 중에 요구사항을 변경하는 사람들이 대부분 고객이기 때문입니다. 그런 일이 자주 생기면, 개발자들의 인생은 급속도로 피폐해집니다.

그런데 사실 그건 고객 잘못은 아니에요. 위의 '흔히 보는 장면' (진짜로 이런 일이 흔하면 큰일나겠습니다만 ㅋㅋ)에서도 느끼실 수 있겠지만, 애초에 프로젝트를 진행하는 팀이 고객과 의사소통을 할 기회가 없었다는 것이 가장 큰 문제죠. 자뻑용 프로젝트를 한다면야 모르곘지만, 개발팀을 고객과 떼놓고 프로젝트를 하면 득보다는 실이 더 많아질 수도 있습니다. 고객/사용자는 종종 시장 그 자체이며, 시장의 변화를 외면하면서 시장에 '최선의 가치를 전달할' 방법 같은 것은 없습니다. 시장의 변화라는 것은 곧 '불확실성'이기 때문에, 우리는 어떻게든 불확실성을 끌어안을 방법을 찾아내야 합니다.

애자일 방법론이 의사소통의 문제를 가끔 비 이성적으로 보일 때 까지 깊이 탐구하는 것은 아마 그래서 일 겁니다. 애자일 방법론은 구두로 나눈 대화와, 그 자리에서 합의된 사항을 '개발 계획서'보다 더 중시하는 경향이 있습니다. (이 점이 전통적인 방법론을 옹호하는 사람들의 심기를 굉장히 불편하게 만들곤 합니다만...) 이건 제 개인적인 경험입니다만, 지식을 늘리는 가장 간단한 방법른 사실 구글 검색도 아니고 독서도 아닙니다. '대화'죠. 대화가 확대할 수 있는 지식의 영역은 특별히 어딘가로 제한되지 않습니다. 하지만 프로젝트 진행에 있어 가장 도움되는 부분은 다음의 몇 가지 일 것 같군요. (무순)

1. 프로젝트 자체에 대한 지식
2. 팀원에 대한 지식
3. 고객/사용자에 대한 지식

앞서도 언급했었습니다만, 지식이 증가하면 불확실성은 감소합니다. 지식을 늘리는 방법으로 스파이크(spike) 같은 것도 있습니다만, 아무래도 고수와의 커피타임만큼 짧고 효율적이진 않습니다. 요구사항 변화에서 오는 야근을 줄이는 방법으로 '무조건적인 퇴근시간 준수'같은 것도 있겠습니다만, 아무래도 요구사항을 낸 이해 당사자와의 전화통화만큼 효과적이지는 못합니다.

의사소통을 자주 그리고 효율적으로 하게 되면 프로젝트 중반에 발생하는 이런 저런 일들에 보다 능동적으로 대처할 수 있게 됩니다. 그리고 팀이 지금 어디쯤 와 있는지 좀 더 분명히 알 수 있게 되고, 앞으로 발생할 지 모를 '꼭지도는' 일들이 팀의 항로를 어떻게 바꾸어 놓게 될지 좀 더 명료하게 알 수 있게 됩니다.

의사소통을 강조하는 것이 자기 파티션 안에 처박혀 있기를 좋아하는 개발자들의 습성과 배치되긴 합니다만, 그런 개발자의 모습은 개발이라는 것을 종종 예술(art)과 비슷한 것으로 묘사하는 너드(nerd) 문화의 클리셰일 가능성이 높습니다. 개발자들은 프로그래밍이 오타쿠들이 좋아하는 저패니메이션같은 것과는 질적으로 다르다는 사실을 깨달을 필요가 있어요. 개발은 현실이고, 현실은 가혹합니다. 개발자들이 의사소통을 무시하고 파티션 안에 처박혀 있으려는 습성은 어찌보면 개발자들이 처한 현실이 주는 문제를 계속해서 재생산하는 측면이 있습니다. 그냥 그 안에 처박혀서 '사용자들은 아무것도 몰라'라고 해서는 인간다운 생활을 영위할 수 없다는 것이 문제라는 거죠. 불확실성을 감소시키지 않으면, 야근 일수는 줄어들지 않는다, 뭐 그런 이야기죠.

하지만 굳이 불확실성 이야기의 외연을 개발자 각각의 삶으로 넓혀놓지 않더라도, 불확실성을 감소시키는 것은 중요합니다. 소프트웨어 프로젝트의 목표가 '고객에게 최선의 가치를 전달'하는 것이라고 보면, '최선의 가치'라는 것의 정의는 시간이 지나면 어떻게든 변화하게 될 처지이니 (시장 상황은 자고 일어나면 바뀌죠) 불확실성이라는 것이 존재한다는 사실을 인정하고 그것과 '화해할 수 있는' 전략을 수립하도록 애쓰는 것이 프로젝트를 관리하는 사람이 해야 하는 일이 아닐까요?


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^