실천가를 위한 실용주의 프로젝트 관리

위대한 관리의 비밀

실천가를 위한 실용주의 프로젝트 관리

위대한 관리의 비밀

요한나 로스맨·에스더 더비

신승환 · 정태중

나의 첫번째 멘토인 에드워드 로스먼과

관리는 진실된 대화임을 항상 일깨워 준

마크, 샤이나 그리고 나오미에게.

나의 남편 제프 리에게.

제프, 당신의 끝없는 도움에 감사해요.

그리고 적당한 시간에 퇴근하도록 일깨워 준

강아지 잭, 고맙다.

�

목차 C o n t e n t s

옮긴이 서문

추천 서문

서문

소개

첫째주 Week One

팀원과 업무에 대해 알아가기

월요일아침 34

한번에한사람씩관리하기 36

화요일아침 38

상황을잘파악하자 43

수요일오후 45

금요일오후 46

업무파악을위한데이터수집하기 52

연습하기 54

참고도서 55

둘째주 Week Two

혼돈에 질서 부여하기

화요일오후 57

프로젝트포트폴리오를만들자 63

�

목요일 67

빠른조치 72

사람들에게맞는역할찾기 72

새로운팀원융화시키기 78

금요일아침,샘의둘째주업무 79

프로젝트포트폴리오관리하기 83

연습하기 84

참고도서 85

셋째주 Week Three

팀 만들기

월요일아침 89

목요일아침 91

공통의목표만들기 97

월요일아침 98

시기적절한피드백주기 102

피드백이상황을바로잡지못할때 104

연습하기 105

참고도서 106

넷째 주 Week Four

날마다 관리하기

월요일아침 107

사람마다적당한개별목표만들기 110

월요일늦은아침 111

�

성공에대해서코칭하기 114

같은날정오 117

영향력주는방법배우기 120

월요일오후 122

피드백기회를잘활용하자 127

연습하기 127

참고도서 128

다섯째 주 Week Four

숨어 있는 문제 발견하기

성가신문제파악하기 136

금요일아침 138

관리팀으로서문제해결하기 144

연습하기 145

참고도서 146

여섯째 주 Week Six

능력 키우기

월요일아침 148

위임하는방법배우기 152

수요일퇴근무렵 154

부하직원의변화와공헌을알아차리고감사하자 155

다시월요일 158

자신을관리하자 160

여전히월요일 162

�

매주부서사람들의능력을개발해라 164

연습하기 166

참고도서 167

일곱째 주 Week Seven

넘어지지 말고 회사의 현실에 대처하자

화요일늦은아침 169

상관을관리하고팀을지지하자 173

화요일점심직전 174

화요일점심식사후 176

목요일 176

우선순위가변하는데로팀을이끌자 178

연습하기 178

에필로그 179

관리란무엇인가 180

연습하기 183

참고도서 183

실천 기술 Techniques

위대한 관리를 위한 실천 기술

팀과함께일하기 185

조직적인맥락에서일하기 187

자신에게일하기 187

실천기술:효과적인코칭을위한지침 188

실천기술:성공적인위임을위한준비 192

10

실천기술:관리자를위한촉진방법 194

회의에목표가있는지확인해라 194

아이디어를만들고통합하기 195

선택사항을평가하기 197

합의를이끌어내기 198

모두가참여하도록도와라 200

실천기술:효과적인피드백을위한지침 202

실천기술:신규직원환영하기 204

실천기술:스마트한목표세우기 206

실천기술:우리머리속에서진행되는일들 208

실천기술:돌아다니며경청하면서관리하기 210

실천기술:효과적인회의진행하기 212

일반적인회의팁 212

지침 212

실천기술:효율적인팀회의를진행해라 218

실천기술:일대일회의성공시키기 221

실천기술:영향력준비하기 225

실천기술:문제해결:새로운상황만들기 226

실천기술:프로젝트포트폴리오계획을위한팁 228

11

관리 팁 목록T i p

팀원과보내는시간이가장중요하다 39

도움을줄수없다면제안하지말자 41

멀티태스킹은집중력을흩트린다 50

‘잘나가는젊은관리자’의우화 61

제품을만들거나지원조직에있다면? 65

관리업무에서물러나기 67

능력은성공의일부일뿐이다 75

크고눈에띄는차트로작업하기 80

그룹과팀은어떻게다를까? 89

피드백에실패하면돈이상의것을지불한다 101

경력개발은누구의책임인가? 108

3의법칙 114

네가내등을긁어주면,네등도긁어줄게 121

압력밸브가되자 123

멍청이라고단정하기 125

감당할만한속도 131

사업상의우선순위냐기술상의우선순위냐? 133

집중,집중,집중 141

얼마나많은사람을관리할수있나? 153

자기자신을알자 157

제무덤파기 168

12

13

그림 목록 F i g u r e

[그림1.1]포트폴리오의시작 48

[그림2.1]프로젝트포트폴리오에서인원이부족한작업을보여줌 58

[그림2.2]패티의관리업무산출물목록 71

[그림2.3]완성된프로젝트포트폴리오 82

[그림3.1]아이디어유사집단화(Affinitygrouping) 94

[그림3.2]빌드시스템갱신을위한실행방안 96

[그림5.1]그룹에요청이들어오는과정 137

[그림6.1]관리업무시간 151

[그림8.1]코칭체크리스트 186

[그림8.2]위임체크리스트 191

[그림8.3]대안평가 196

[그림8.4]피드백의6단계 201

[그림8.5]채용을마무리하는활동 202

[그림8.6]첫째날을위한준비작업 203

[그림8.7]첫째날신규직원도착을위한작업 203

[그림8.8]새터(Satir)의상호작용모델 206

[그림8.9]회의구성템플릿 211

[그림8.10]투자수익(Returnoninvestment)투표 215

[그림8.11]투자수익히스토그램 215

[그림8.12]영향력준비시트 223

[그림8.13]바라는결과를만들기 225

[그림8.14]4주계획의예 227

14

15

옮긴이 서문P r e f a c e

팀장이 시누이보다 밉다!

“때리는 시어미보다 말리는 시누이가 밉다.”라는 속담이 있다. 시집살이를 했던 우

리네 어머니 시대에나 어울릴만한 이야기지만, 이 속담에 담긴 뜻은 무척 깊다. 고부

간의 갈등 속에서 시어미에게 이유 없는 매를 맞았던 며느리. 그 옆에서 시어미의 구

박을 말리는 시누이가 던지는 말 한 마디. “엄마가 참아! 새 언니가 배운 게 없어서 그

래.” 시누이의 깃털보다 가벼운 말 한마디는 며느리의 가슴 깊은 곳을 강타한다.

프로젝트는 고객과의 영원한 줄다리기다. 새로운 요구사항을 추가하려는 고객. 요

청된 요구사항만이라도 충실히 개발하려는 팀원. 그리고 팽팽한 줄다리기의 가운데

팀장이 서있다. 프로젝트 완료 보고서에 도장을 찍어줄 고객은 여유로운 표정으로

팀장을 쳐다본다. 다른 한편에서 힘이 부친 팀원은 애처로운 눈으로 바라본다. 팀장

이 내 편이 되어주길 바라는 마음에서 말이다. 눈이 마주친 팀장은 팀원에게 온화한

미소를 짓는다. 팀원은 힘이 샘 솟는 것 같다. 이 때 팀장은 고객 쪽 깃발을 냉큼 올려

버린다. ‘고객 승!' 그러나 줄은 아직도 그 자리에 있었다.

다시 생각해 보자! 프로젝트는 누군가의 희생이 다른 사람의 기쁨이 되는 제로섬

게임(Zero-sum game)일까? 고객과 팀원의 이해는 서로 다르다. 따라서 방향이 정반대는

아닐지라도, 고객과 팀원 사이에 이해의 교집합을 찾기란 어렵다. 그렇기 때문에 새

로운 요구사항이나 변경이 생길 때마다 고객과 팀원은 줄다리기 싸움에 놓인다. 지

루한 줄다리기 패러다임을 받아 들인다면, 팀장은 팀원의 피를 빨아 먹고 사는 흡혈

1�

귀나, 고객 만족이란 단어를 모르는 꽉 막힌 사람, 이것도 저것도 아니라면 적당한 눈

치보기로 연명하는 신세가 된다.

그러나 답은 상자 밖에 있다. 즉 줄다리기 패러다임을, 다른 두 벡터 사이에서 새로

운 힘을 찾는 것으로 생각해보자. 이 패러다임을 받아들이는 순간, 팀장은 적당한 타

협을 찾아내는 깃발에서, 팀원이라는 900마력 엔진을 달고 고객이라는 뒤바람을 맞

으면 달리는 F1 드라이버가 된다. 서로 자신만의 방향을 찾아서 움직이던 고객과 팀

원의 역동적인 힘을 프로젝트의 성공으로 향하게 만든다. 단지 팀장이 패러다임을

바꿨을 뿐인데 말이다.

패러다임을 바꾸기란 그렇게 쉽지만은 않다. 고객이 진정으로 원하는 것이 무엇인

지 파악해야 하고, 팀원들이 적절한 자기계발과 프로젝트에 기여하도록 도와야 하며,

프로젝트를 적절한 방향으로 이끌기 위해서 회사와 상관과의 이해 관계도 살펴야 한

다. 즉 다양한 역학 관계 속에서 사람을 다루어야 한다. 다르게 말하자면 프로젝트를

성공으로 이끌기 위해서 팀장은 위대한 관리자가 되어야 한다.

위대한 관리자

개발자들은 관리자가 된다고 생각하면 미지의 거부감과 두려움에 쌓인다. 개발자

들이 천성적으로 관리를 싫어하기 때문일 수도 있지만, 관리자로서 어떻게 하는지

제대로 배우지 못하고 관리자로서 임무만을 강요 받는데도 한가지 원인을 찾을 수

있다. 소프트웨어 개발 현장에서는 사수/부사수의 도제 형식으로 가르침을 받거나

각종 세미나, 교육 과정을 통해서 관리를 배울 수 있다. 하지만 어느 날 갑자기 관리

자가 된 개발자는 그 순간부터 관리자로서 태어난다. 관리자가 되고 싶었던 개발자

라도 관리자 교육을 받지 못하기 때문에, 넘어지고 깨지고 욕 먹고 혼자서 깨닫는 인

1�

고의 세월을 보내야만 한 명의 관리자로서 태어난다.

선배와 선생님으로부터 관리자가 되는 방법을 배울 수 없다면, 관리자라는 미지

의 영역에 발을 뻗을 수 있는 유일한 방법은 책을 통해서다. 이 책의 원제목은 “Behind

Closed Doors”다. 즉 위대한 관리는 닫힌 문 뒤에서 일어나는 일처럼 눈에 띄지 않는다

는 뜻이다. 훌륭한 관리자는 상하관계를 떠나서 동료로서 정서적인 교감을 통해 팀

원의 능력을 끌어낸다. 그러나 많은 관리자는 열린 문을 통해 권위의식을 드러낼 뿐,

닫힌 문 안에서 팀원에게 다가 가려고 하지 않았다. 이 책은 이 점에 착안하여 훌륭한

관리자가 드러나지 않는 부분에서 팀원의 능력을 이끌어 내기 위하여 팀원에게 어떻

게 다가서는지 보여 준다.

지난 회사 생활을 돌이켜 보면 관리보다는 개발 업무가 더 많았다. 개발을 주로 했

을 때는 관리하면 나와 상관없는 이야기로만 생각했다. 그러나 경력이 쌓이면서 어

쩔 수 없이 관리 업무를 맡게 되었다. 일반인이 타고난 천재성이 없는 경우 어떤 일에

익숙해지기까지는 많은 노력과 어려움이 따른다. 처음으로 맡은 프로젝트 관리 업무

를 생각하면 지금도 웃음이 나온다. 참으로 많은 실수를 했기 때문이다. 그러나 관리

업무에 익숙해지면서 처음과 달리 관리업무가 매력적임을 깨닫게 되었다. 결과와 일

정만을 다루는 관리처럼 손쉬운 관리도 없다. 그러나 진정한 관리의 매력은 고객과

팀원과 섞여서 동료로서 대화하고 사람들이 가진 잠재능력을 이끌어 내어 좋은 결과

로 마무리 될 때다. 결국 인간이란 천상천하유아독존이 아닌 이상 사람과 사람 사이

에서 그 의미를 찾기 때문이다.

바로 이 책이 이러한 위대한 관리의 세계로 여러분을 안내할 것이다.

1�

감사의 글

긴 시간 동안 함께 번역 작업을 한 친구 정태중씨에게 고마움을 전한다. 태중씨가

없었다면 무척이나 길고도 어려운 작업이 됐을 것이다. 아울러 좋은 책을 번역할 기

회를 주신 위키북스 관계자에게도 감사 드린다. 끝으로 사랑하는 부모님, 가족 그리

고 승현이에게도 고마움을 전한다.

겨울날 맑은 하늘 아래에서

신승환

1�

관리란 뭘까요?

저도 초보적인 관리자에 지나지 않아, 이 말에 명쾌한 답을 내리기는 어려울 것 같

습니다.그리고 비록 능숙한 관리자라 할 지라도 정의를 내린다는 것은 쉽지 않겠죠.

그래도 감히 제 나름대로 정의를 내려 본다면

‘보다 나은 일의 성과를 내기 위해 일과 그 일에 관련된 사람들에게 지속적으로 관

심을 쏟는 것'이라고 말하고 싶습니다.

우리는 일을 하며 살아갑니다. 꼭 직장인이 아니라고 해도 누구나 일은 하죠. 그리

고 모든 사람은 자신의 일에서 더 나아지기를 원합니다. 그러나, 그저 시간만 지난다

고 더 나아지는 것은 아닙니다(진정으로 그 일에 관심과 정열을 쏟을 때에만 나아질

수 있죠). 그래서 자신의 일을 ‘관리'해 나갈 필요가 있습니다. 관리란 바꿔나가는 것

이니까요.

또 우리는 개인으로서가 아니라 ‘팀으로서' 함께 힘을 합할 때 더 큰 성과를 낼 수

있습니다. 이 말은 엄청나게 큰 건물을 짓는 일에서나, 머리가 부서지도록 복잡한 프

로그램을 작성할 때나 동일하게 해당합니다. 아무리 뛰어난 개인이라도 혼자서 이런

일을 할 수는 없죠. 따라서, 팀의 역량을 극대화시키기 위해서 팀의 리더로서 관리자

는 훌륭하게 관리를 수행해야만 합니다. 그리고 팀에서의 관리의 초점은 ‘사람'이죠.

일을 하는 사람도 사람이고 일의 목적도 사람을 위한 것이니까요. 이 책의 핵심도 팀

에서 ‘사람을 어떻게 대하느냐'에 있다고 해도 과언이 아닙니다.

이 책은 프로그램 개발 회사의 관리자를 독자로 하여 쓰여진 책입니다. 팀원들의

힘을 합쳐 보다 큰 성과를 내기 위해서 어떻게 관리를 해야 하는지에 초점이 맞춰져

있습니다. 굳이 프로그램 개발의 일이 아니더라도 일반적인 일들에도 충분히 적용할

만한 내용들이죠.

20

중간 중간에 마치 소설을 읽는 것처럼 이야기를 구성해 놓았기 때문에 가벼운 마

음으로 읽어도 이해하기 쉽도록 구성이 되어 있습니다. 관리자로서 어떻게 관리를

해야 좋은 관리인지 고민하시는 분들이나, 특히 소프트웨어 프로젝트를 관리하는데

필요한 기술을 알고 싶으신 분들께서 읽으시면 실질적인 업무에서 많은 도움이 되리

라 믿습니다.

이 책을 번역하는데 참여하도록 도와준 신승환씨에게 감사의 말을 전합니다. 또

인내심을 가지고 부족한 번역물을 교정해 주신 출판사 여러분께도 심심한 감사를 전

합니다.

정태중

21

추천서문F o r e w o r d

25년 동안 기술 관리자와 일하면서, 모든 기술 관리자는 나쁜 관리자라고 여기는

나쁜 버릇이 생겼습니다. 로스맨과 더비의 짧지만 지혜로운 책인 “실천가를 위한 실

용주의 프로젝트 관리 - 위대한 관리의 비밀”은 제가 틀렸다는 것을 보여주었죠.

대부분의 ‘나쁜 관리자’는 결코 고약하지 않았습니다. 위대한 관리자는 제쳐두더

라도, 그들은 훌륭한 관리자가 되는데도 무지했기 때문이죠.

그런데 나쁜 관리자들은 왜 어리석었을까요? 초기 25년 동안의 소프트웨어 산업

에서, 나쁜 관리자들은 관리 비법을 배울만한 위대한 관리자들을 만나지 못했기 때

문입니다. 모든 선구자처럼 그들은 고단한 작업으로 황무지를 개간했습니다.

로스맨과 더비가 소프트웨어 비즈니스에 발을 담글 때쯤, 1세대 관리자 가운데 소

수가 위대한 관리자가 되었죠. 저보다 늦게 입문한 세대는 이러한 위대한 관리자와

함께 일했고 이들을 관찰해서, 훌륭한 관리자나 위대한 관리자가 어떻게 행동하는지

조금 더 긍정적인 이미지를 형성할 수 있었습니다.

다음 세대를 위해서 2세대 관리자는 수백 명의 새로운 관리자에게 위대한 관리

자가 되는 지식을 알려줬으며, 이제 운이 좋은 독자인 여러분에게 이 비법을 전수

합니다.

이제 여러분이 관리자로서 경력을 시작했다면, 혼자서 위대한 관리자의 비밀을 알

아낼 필요가 없습니다. 물론 여러분이 이해할 것이 여전히 많지만 로스맨과 더비의

책이 있기에 여러분은 처음부터 시작하지 않을 것입니다.

수십 년 전에 IBM에서 처음으로 관리직을 맡았을 때, 관리자에게 지급되는 작고도

22

비밀스러운 책 한 권을 받았습니다. 어떻게 훌륭한 관리자가 될지 감을 잡지 못했기

에 그 책을 열심히 읽었습니다. 그러나 실망스러울 따름이었죠.

작고도 비밀스러운 책에는 몇 가지 관리 지혜가 담겨있었지만, 어떤 내용도 기술

관리자와 관련되지 않았기에, 제게 그다지 도움되지 않았습니다. 그리고 내용 가운

데 일부는 저 같이 기술을 담당한 사람에게 명백히 잘못되었습니다.

수십 년 동안 초보자(그리고 몇몇 고참 관리자)를 위한 “위대한 관리의 비밀”을 알

려줄 더 좋은 책을 찾아 다녔습니다. “실천가를 위한 실용주의 프로젝트 관리 -위대

한 관리의 비밀”을 만나면서, 제 여행은 끝났습니다.

기다린 보람이 있습니다.

2005년 8월

컴퓨터 선구자

제리 와인버그Jerry Weinberg

23

서문P r e f a c e

관리를 다루는 이 책을 훑어 보면서 스스로에게 던지는 첫 번째 질문은 다음과 같

을 겁니다. “이 사람들은 누구지? 진짜 존재하는 사람이야? 아니면 컨설턴트 두 명이

지어낸 사람들 아니야?

단언컨대 모두가 진짜입니다. 사실 저자들은 다양한 환경에서 사십 년 이상 관리

직에 근무했습니다. 우리는 다양한 종류의 제품 개발 팀, 기능 팀주_�, 교차 기능 팀

(Cross-functional team)주_�, 애자일 팀과 운영 팀을 관리하고 코치했습니다. 오랜 시간

동안, 기술적인 조직에 있는 대부분의 관리자는 우리가 그랬던 것처럼 개발자에서

시작했다는 중요한 사실을 알게 되었습니다.

어떤 사람들은 관리는 중요하지 않다고 우리에게 말했습니다. 관리의 품질에 상관

없이 좋은 개발자들은 결과를 얻기 때문이랍니다. 우리의 경험 상 그렇지 않습니다.

형편없는 관리자는 비지니스주_�로 생산성이라는 환영을 만듭니다. 보통의 관리자는

일을 마칩니다(그러나 항상 올바른 일은 아니죠). 위대한 관리자는 목표를 달성하고 사람들을

키웁니다. 결과적으로, 우리는 관리의 품질이 직장 생활의 근본적인 결과와 품질에

옮긴이 주_� 기능 팀(기능 조직)은 총무부, 인사부, 개발부처럼 기능 단위로 팀을 나눈다.

옮긴이 주_� 교차 기능 팀(Cross-functional team)은 특별한 목적을 달성하기 위해서 다양한 부

서에서 사람을 뽑아서 구성한 팀이다.

옮긴이 주_� 원문에서는 busy-ness다. 진짜 비즈니스(Business)가 아닌 생산성만을 높이기 위

해서 아무 일이나 하는 것을 비꼰 표현이다.

24

큰 차이를 만든다고 믿습니다.

그러나 기술 조직의 경우 기술적인 훈련에는 많은 강조를 하지만, 관리자를 훈련

하는데 많은 관심을 두지 않는다는 것을 우리는 깨달았습니다.

극소수의 회사에서, 새로운 관리자는 관리 훈련을 받고, 회사는 관리 역할로 성공

적인 직무 이동을 하도록 이들을 코칭합니다. 보통 새로운 관리자는 기본적인 오리

엔테이션과 무슨 일을 하는지 추상적인 소개를 받지만, 관리를 어떻게 하는지에 대

한 정보를 많이 얻지 못합니다.

슬프게도 대다수의 새로운 관리자는 아무런 교육도 받지 못하기에, 어깨 너머로

시행 착오를 겪으면서 스스로 관리를 어떻게 하는지 배웁니다. 스스로 배우는 방법

은 교육 예산을 절약할지 몰라도, 조직의 낮은 생산성과 관리자와 팀의 개인적인 스

트레스 때문에 이러한 절약은 상쇄되고 말죠.

대부분의 새로운 관리자(그리고 한동안 관리직을 맡았던 관리자들)는 관리를 잘 하고 싶지만

어떻게 좋은 관리를 하는지 항상 모릅니다. 새로운 관리자 가운데 일부는 훌륭한

관리를 한번도 보지 못했는데 그들이 어떻게 효율적인 관리자 될 준비를 할 수 있

을까요?

이런 식으로는 안 됩니다.

우리는 관리자들이 어떻게 위대해지는지 보여 주기 위해서 우리의 경험과 관찰을

책으로 옮기기로 결심했습니다.

이 책에서 우리는 일부러 짧은 타임라인을 사용했습니다. 리뷰어 가운데 한 명이

물었습니다. “이 타임라인은 허구인가요?” 아니요. 한 아름의 관리 실천 방법을 효과

적으로 적용할 줄 아는 관리자는 상대적으로 짧은 시간에 많은 것을 이룰 수 있죠. 이

책에서 보여드리는 것은 우리가 고용인, 계약 관리자나 관리 코치였건 간에 관리자

로서 업무를 조직할 때 실행했던 방법입니다. 우리는 사람들을 만났고, 무엇이 사람

25

들을 움직이게 하는지 배웠으며, 일에 우선 순위를 부여했고, 피드백과 코치로 사람

들을 계발시켰습니다.

사람들이 무슨 일을 하는지 여러분이 알지 못한다면, 프로젝트 포트폴리오를 만들

지 못합니다. 여러분이 프로젝트 포트폴리오를 작성하지 못하면, 제 시간에 업무가

잘 끝날지, 여러분의 팀이 더 많은 일을 맡을 수 있을지, 더 많은 사람들이 필요한지

알 수 없습니다. 단지 알지 못하는 것만이 전부가 아닙니. 이것은 관리자로서 용납할

수 없습니다.

우리는 재능 있는 중간 관리자(부서장이면서 팀장)인 샘의 관점에서 이 책을 집필했습

니다(왜 나쁜 예를 들지 않았을까요? 우리는 이미 충분히 봤기 때문입니다). 팀원들이 관리 업무를 수행

하도록 어떻게 코치하는지 독자인 여러분에게 보여주고 싶었습니다. 또한 관리 업무

란 어떻게 하는 것인지 알려드리고 싶었습니다. 고위 관리자들은 샘보다 더욱 전략

적인 일을 합니다. 중간 관리자의 전략적인 업무는 고위관리자 보다는 적습니다. 어

쨌든 모든 관리자의 역할은 독특하며 업무 경계는 개인과 조직의 상황에 따라 나눠

집니다. 그러나 모든 관리자는 조직에서 비슷한 업무를 하기에, 우리는 중간 관리자

인 샘을 통해 관리 업무를 하는 것을 알려드리고자 합니다.

우리는 기능 조직을 보여 드리는 것을 선택했습니다. 기능 조직에서는 관리자마다

제품의 한 계층을 책임지기 때문에 제품을 완성하기 위해서는 부서를 넘나들며 관리

해야 합니다. 즉 기능 조직은 개발 조직에서 일반적인 구조입니다. 여러분은 매트릭

스 부서의 관리자일지도 모르죠(매트릭스 부서는 기능 부서마다 관리자가 있고, 프로젝트 기반으로 기

능 부서에서 사람을 데려옵니다). 아니면 자발적 조직 팀(Self-organizing team)주_�이나 애자일 방법을

옮긴이 주_� 자발적 조직 팀(Self-organizing team)은 데드라인을 맞추기 위해서 팀원들이 스스

로 조직화한다. 즉 한 번의 개발 주기(Iteration)동안 얼마나 많은 일을 할지 팀원들이 자발적으로

결정한다.

2�

사용할지도 모릅니다. 모든 조직은 조직화하는 방법에 고유한 견해가 있지만 대부분

의 관리 업무는 같습니다.

대부분의 관리 업무가 같다는 말이 확신이 서지 않는다면, 조직에 있는 기술자에

게 피드백을 하고 코칭과 경력 개발에 책임을 맡은 사람이 누구인지 스스로에게 물

어 보세요. 체계적으로 개발 팀을 누가 모니터링 하는지 자신에게 물어 보세요. 이러

한 일을 하는 사람이 바로 관리 역할을 맡습니다. 우리는 애자일 프로젝트 팀에 편견

을 보입니다. 즉 작업을 할당하고, 진척상황을 관찰하고, 문제를 해결하는 팀 업무를

팀이 관리하기 때문입니다. 관리자를 자유롭게 만들어서 팀을 방해하는 장애물을 제

거하고 더 큰 문제를 해결하게 하죠. 그러나 많은 기능 팀이나 매트릭스 팀도 효과적

인 관리자가 있을 때 성공하는 것을 목격했습니다. 따라서 이 책에서 설명하고 제시

하는 실천 방법들을 대부분의 경우에 고쳐서 적용할 수 있다고 확신합니다.

관리를 다룬 책들에 자주 다루는 주제 하나가 이 책에서 빠진 것을 여러분은 눈치

챘을지도 모릅니다. 바로 리더십입니다. 솔직히 말해서, 우리는 리더십과 관리가 다

르다는 논리를 받아들이지 않습니다. 우리는 효과적인 관리와 리더십은 얽혀있다고

믿습니다. 위대한 관리자는 하나의 역할에 리더십을 부여하지 않고, 많은 사람들이

리더십을 발휘할 수 있도록 공간을 마련해 둡니다. 그리고 한편에서 리더십에 대한

논쟁거리가 있습니다. 기능적으로 박식하지 않는 사람. 일을 제대로 못하는 사람은

관리자도 리더도 아니라는 것입니다.

앤디 아킨스, 알란 바루즈, 데이비드 복, 폴 브라운, 파스칼 카우벤버그, 달 이멀리,

새이 에리슨, 마크 에버스, 엘리자베스 핸드릭스, 빌 클렙, 프레더릭 로우렌타인, 다

윈 필립스, 밥 푸치아, 롭 퍼서, 에릭 로버츠, 버트 로디어스, 일런 살리스버리, 데이브

스미스, 마이크 스토크, 토마스 바그너, 제리 와인버그 그리고 돈 윌러튼과 여러 리뷰

어들의 매우 값진 도움에 감사 드립니다. 특히 편집자인 앤디 헌트에게 그의 도움과

지원에 고마움을 전하고 싶습니다. Pragmatic Bookshelf에서 앤디와 데이브와 같이 작

2�

업한 것은 훌륭한 경험이었습니다. 아울러 여러분이 없었다면 이 책을 끝내지 못했

을 것입니다.

메사추세츠, 알링턴

요한나 로스맨 Johanna Rothman

미네소타, 미네아폴리스

에스더 더비 Esther Derby

2�

2�

소개I n t r o d u c t i o n

우리 대부분은 직장에서 나쁜 관리를 봅니다. 나쁜 관리를 목격하고 있기 때문에

하지 말아야 할 것을 배우고 있을지도 모릅니다. 그러나 위대한 관리자가 되기 위해

서, 하지 말아야 할 것을 피하는 것만으로 충분하지 않죠. 위대한 관리자들은 능동적

으로 관리 기술을 배우기 때문입니다.

인간적인 비용이나 경제적인 비용 측면에서 위대한 관리자가 되는 방법은 배울만

한 가치가 있습니다. 나쁜 관리의 비용은 엄청나죠. 관리자들이 부서를 효과적으로

관리하지 못했기 때문에 회사가 사업을 접는 상황을 우리는 많이 접했기 때문입니다.

관리자는 부하 직원의 업무에 많은 영향을 끼치기 때문에, 나쁜 관리의 인간적인

비용은 경제적인 비용보다 더 클 수도 있습니다. 근무 의욕과 생산성을 떨어드리는

형편없는 관리자와 일하기를 거부했기 때문에 조직에 매우 귀중한 사람들이 떠나는

것을 봤습니다. 관리라는 이름으로 받는 대우가 모욕에 가까웠다고 묘사하는 사람들

과 우리는 이야기를 나누었습니다.

혼자 힘으로 위대한 관리자가 된다는 것은 쉬운 일이 아닙니다. 훌륭한 관리자를

옆에서 항상 주의깊게 지켜보고 있다고 해도 말입니다. 훌륭한 관리를 습득하기가

어려운 이유 가운데 하나는 관리의 많은 부분이 닫힌 문 안쪽에서 일어나기 때문입

니다. 여러분은 단지 관리자의 공식적인 행동이나 단순한 지시 사항과 같은 것을 지

켜볼 수 있을 뿐입니다.

하지만 관리자는 성격, 기술 수준, 동기를 두고 사람과 상호 작용합니다. 그리고 이러

한 상호작용은 개인적인 일대일 회의나 관리자와 함께 일하는 회의실에서 일어나기 때

문에, 관리 업무는 세상과 관리를 열망하는 보통 사람들에게는 잘 보이지 않습니다.

30

우리는 이러한 문을 열어서 여러분께 실행되는 위대한 관리를 보여드리겠습니다.

관리 법칙을 설교하고, 강조점과 체크리스트로 여러분을 괴롭히는 대신, 닫힌 문

을 열어서 위대한 관리자가 날마다 일어나는 도전과 위기를 어떻게 다루는지 여러

분께 직접 보여드리겠습니다. 우리의 위대한 관리자는 샘입니다.

이야기의 시작은, 샘 모건이 하이 테크(High tech) 조직의 새로운 부장직을 맡으면서

시작합니다. 샘은 마흔 중반이고 십 년 이상 기술직 부서를 관리했죠. 모든 사람은 일

을 잘하길 원한다고 샘은 확신합니다. 다만 사람들은 무엇을 하고 어떻게 일을 해야

할지 잘 모르는 것처럼 보이죠. 관리자를 포함한 부서에 있는 모든 사람들이 어떤 일

을 하고, 부서원들이 일을 하기 위해서 올바른 도구를 사용하게 하는 일이 샘의 업무

입니다. 네 명의 관리자가 샘에게 보고를 합니다.

진저 브라이언은 스무 살 후반입니다. 사용자 인터페이스(User Interface, UI) 부서를 이끌

며 처음으로 관리 업무를 맡았습니다. 그녀는 야심차고, 그녀의 일을 즐기며, 어떤 일

을 하던 올바른 방법 하나는 있다고 확신합니다. 이 방법이 무엇인지 몰라도 말이죠.

케빈 맥클라우드는 미들웨어 부서를 관리합니다. 케빈은 삼십 대 초반입니다. 그

는 지쳐있죠. 모든 일을 처리하려고 그는 날마다 힘겹게 일합니다. 그는 열심히 일만

한다면 성공할 것이라고 확신합니다.

제이슨 스톤은 백엔드 부서를 관리하지만 운영 부서에 대해서 추가적인 책임을 떠

맡았습니다. 그는 5년 동안 프로젝트와 사람들을 관리했습니다. 운영 부서 사람들은

몇 달 전까지만 해도 백엔드 부서의 일원이었기 때문에 제이슨은 운영 부서 사람들

에게서 책임감을 느낍니다.

마지막으로, 패티 라르센은 데이터베이스 부서를 관리합니다. 이전 부장의 요청으

로 관리자 역할을 대신합니다. 그녀는 스무 살 중반이고 관리자가 되는 것을 싫어합

니다. 패티는 기술 리더로서 다시 일하기를 원하죠.

31

우리는 처음 몇 주 동안 관리 업무를 하는 샘을 주시할 것입니다. 계속되는 난관에

도 불구하고, 효율적이고 생산적인 부서를 만들기 위해서 관리자와 샘이 일하는 모

습을 지켜보죠.

샘이 첫 번째로 무슨 일을 할까요?

32

관리팀과조직도

개발 부서(관리팀 팀장, 부서장)

UI팀

(팀장)

미들웨어 팀

(팀장)

백엔드 팀

(팀장)

데이터베이스 팀

(팀장)

샘

제이슨 케빈진저 패티

33

어떤 사람은 관리는 사람을 잘 다루는 일이 전부라고 생각하고, 또 다른 사람은 관

리는 일을 잘 처리하는 것이 전부라고 말합니다. 하지만 훌륭한 관리는 팀원을 잘 이

끌어서 각자가 가진 능력을 계발하여 주어진 업무를 잘 하도록 만드는 것입니다.

팀원을 잘 이끌고 싶다면 먼저 팀원에 대해서 잘 알아야 합니다. 그 사람만의 독특

한 장점, 열정 그리고 행동 양식을 파악해야 합니다. 업무를 잘 관리하고 싶다면 팀원

이 무엇을 하는지 이해하고, 팀원이 하고 있는 일이 팀의 업무 목표와 잘 부합하는지

살펴야 합니다.

새로운 조직이나 직장에서 관리 업무를 시작할 때는 다음 세가지를 알아둬야 합

니다.

팀원은 누구이며, 어떤 강점과 관심사를 가지고 있으며, 현재 무슨 일을 하

고 있는가

팀에 명시된 업무 목표와 팀이 가치를 만드는 방법은 무엇인가

자신의 팀이 상위 조직과 잘 협력하고 있는가

팀원과 업무에 대해 알아가기

Week One첫째 주

34

Week One첫째 주

출근 첫 날에 멋지고 깔끔한 서류 상자 안에서 이런 정보를 알아낸다면 아주 좋을

겁니다. 하지만 서류만을 통해서 정보를 얻는다는 것은 어려운 일입니다. 많은 사람

을 만나고 관리 업무를 수행하는 동안 이런 정보가 드러나게 됩니다. 신뢰를 쌓고 결

속력 있는 팀의 기초를 다지는 일은 우선 팀원들로부터 시작하세요. 관리 업무를 시

작하는 좋은 방법은 여러분에게 보고하는 모든 팀원과 일대일 회의를 갖는 것입니다.

월요일 아침 M o n d a y

UI User interface 팀장인 진저는 샘과의 첫 번째 회의에 숨이 찬 상태로 3분 늦게 도착

했다.

“들어와서 앉아요, 진저” 샘이 말했다.

“회의의 목적이 뭐죠? 이전 부장님은 이런 회의를 한 적이 없어요.” 진저는 붉은 머

리카락을 묶은 포니테일을 어깨 너머로 넘기며 의자에 털썩 주저앉으면서 말했다.

팔짱을 끼고 몸을 뒤로 기댔다.

“매주 직접 보고 받고 싶어서요.”

“네, 어떤 이야기를 듣고 싶으세요?” 진저가 물었다.

“이번 주에는 진저하고 더 친해지고 싶군요. 자신에 대해서 좀 얘기해 줄래요.” 샘

은 노트를 펴고 진저를 차분하고 신중하게 바라 보았다.

샘은 진저가 어떻게 일해왔는지, 직장 생활에 만족하는지를 알고 싶었다. 그래서

진저에 대한 정보를 얻고자 “이 일을 어떻게 맡게 되었죠?”, “일에서 즐거운 점이 뭔

35

팀원과 업무에 대해 알아가기

가요?”, “어떤 점이 힘든가요?”와 같은 개방형 질문open-ended question 주_�을 던졌다.

진저가 마케팅 부서의 ‘항상 변하는 요구’를 반영하기 위해서는 사람이 부족하다

고 말했다. 샘은 더 자세히 말해달라고 부탁했다.

“방금 말한 항상 변하는 마케팅의 요구에 대해서 조금 더 말해 줄래요. 대체 그게

뭐에요?”

샘은 여러 가지 질문을 하면서 진저가 마케팅 부서와 잘 협조하고 있는 부분과 그

렇지 않은 부분에 대해서 알게 됐다.

샘은 진저와 마케팅 부서가 진행했던 상황을 충분히 이해했다는 생각이 들자, 새

로운 부서에서 일을 시작할 때 항상 다루는 주제로 넘어 가기로 했다.

“당신이나 팀원 가운데서 개인적인 문제나 급여에 불만이 있는 사람이 있나요?”

진저는 어깨를 으쓱거렸다. “아뇨, 전 행복해요. 그리고 제가 아는 한 우리 팀원들

도 행복하구요.”

진저의 팀에서 진행하는 프로젝트에 대해 이야기하며 샘과 진저는 남은 시간을

보냈다.

샘은 회의를 끝내면서 물었다. “내가 빠뜨린 게 있나요?” 진저는 머리를 가로 저었

다. “좋아요. 정기적으로 매주 일대일 회의를 하는데 이번 시간이 밑거름이 되었나

요?”

“우리가 매주 만난다는 뜻이세요?”

옮긴이 주_� 개방형 질문(open-ended question)은 이 블록은 무슨 색입니까”같은 단답을 요

구하는 질문이 아닌“이 블록으로 무엇을 할 것입니까”와 같은 주관적인 답을 요구하는 질문이다.

3�

Week One첫째 주

“그래요. 매주” 샘이 말했다.

“좋아요. 언제든지요.” 진저가 순순히 동의했다.

“시간 내줘서 고마워요. 내게 알려주고 싶은 게 생기거나 나에 대해서 묻고 싶은

것이 있으면 들러 주세요”

퇴근 전까지 샘은 네 명의 모든 팀장과 만났다. UI 팀장인 진저가 그녀의 이름처럼

붉은 머리카락에 걸맞게 불 같은 성격의 소유자라는 걸 알게 됐다(진저는 영어로 생강임).

미들웨어(Middleware) 팀장인 케빈은 기술적으로 매우 훌륭한 사람이지만, 그가 맡은 팀

업무에서 어떻게 우선 순위를 부여하고 정리하는지에 대해 확신이 서지 않았다. 백

엔드(Backend) 팀장인 제이슨은 운영 부서를 지원하는 백엔드 그룹에 매여 있고, 아들이

속한 하키 팀을 가르친다는 사실도 알게 되었다.

데이터베이스 팀장인 패티는 파악하기가 쉽지 않았다. 패티는 질문에 답하였지만

그다지 자발적이지 않았다.

샘은 공통된 주제가 나타나는 것을 보았다. 모든 팀장과 팀원들은 할 일이 너무 많

으며 더 많은 팀원이 필요하다고 주장하였다.

◇◇◇

한번에 한 사람씩 관리하기

제대로만 한다면 일대일 회의는 서로 간의 신뢰 관계를 만들어 줍니다. 일대일 회

의가 관리 시간을 가장 효과적이고 생산적으로 이용하는 방법 가운데 하나라는 것을

지속적으로 일대일 회의를 사용한 관리자는 알게 됩니다. 그리고 일대일 회의는 지

3�

팀원과 업무에 대해 알아가기

시를 하고, 피드백을 주고 받으며, 경험을 쌓고, 진행 상황을 보고하기에 적당한 자리

를 제공합니다.

일대일 회의를 통해 여러분이 원하는 바가 무엇인지 팀원들에게 전달할 수 있습니

다. 뿐만 아니라 함께 보내는 시간만큼이나 그들을 존중하고 있다는 것도 알릴 수 있

습니다.

매주 일정한 시간을 정하세요. 매주 같은 시간에 자신의 팀원을 한 사람씩 만나

세요. 지속적인 회의는 고유한 흐름을 만들고 팀장과 팀원에게 준비해야 한다는 사

실을 기억하게 합니다.

몸가짐을 조심하세요. 일대일 회의동안 전화를 받거나 걸고, 서류를 보거나 다른

일을 하지 마세요. 일대일 회의를 하는 도중 관리자의 개인적인 일로 회의를 중단하

면 상대방보다 자신의 시간이 더 중요하다는 메시지를 상대 팀원에게 전달하는 셈입

니다.

일대일 회의를 충실히 지키세요. 일대일 회의를 취소하면 팀원들은 자신이 무

시당했다고 느낍니다. 그렇게 되면 얼마 지나지 않아 팀에서 벌어지는 일을 알 수 없

게 됩니다. 일대일 회의를 계속하세요. 그러면 프로젝트 지연, 불행한 팀원, 곪아 터

지는 문제 때문에 당황하지 않을 겁니다.

일대일 회의에서 일관된 형식을 따르세요. 일관된 형식을 유지한다면, 팀원은

여러분을 변덕스럽지 않고 신뢰할 수 있는 사람이라고 믿게 됩니다.[3] 모든 사람에게

같은 형식을 사용하고, 특별한 경우에도 이 형식을 지켜야 한다는 의미는 아닙니다.

그러나 시간이 지나고 나서도 일관성을 유지하면 여러분이 변덕스럽지 않고 믿을 만

하다고 팀원은 생각합니다. 생산적인 일대일 회의를 효과적으로 활용하고 싶다면

219쪽의 ‘일대일 회의 성공 시키기'를 살펴 보세요.

3�

Week One첫째 주

융통성을 발휘하세요. 사람과 작용하고 반응하는데 변화를 주지 못한다면 지속

적인 회의는 쓸모 없습니다. 개인마다 여러분의 관리 스타일을 바꾸고 문제를 다루

는데 공정해야 합니다.[2] 잘못된 방향으로 나가려는 사람이나 새로운 사람과 매주

만나세요. 업무를 계획하는 사람과 격주로 회의하는 것도 고려해야 합니다. 능동적

으로 대화하고 정상 상태에 머물게 하세요.

앞에서 말했듯이, 때로는 매주 회의를 열면 잘못된 메시지를 전달하기도 합니다.

부서가 회사의 사활이 달린 위기에 대응해야 한다면, 잠깐 동안 일대일 회의를 미루

세요. 위기가 다시 진정되면, 정기적인 일대일 회의로 복귀합니다. 정기적인 일대일

회의는 팀장과 팀원 사이에 안정적인 관계를 만들고, 문제를 일찍 알 수 있게 해줍니

다. 조기에 문제를 파악하면, 위기와 마주치기도 전에 해결책을 찾을 수 있습니다.

◇◇◇

화요일 아침 T u e s d a y

샘은 다른 부서에 있는 동료와 만날 약속을 하면서 화요일 아침을 시작했다.

마케팅 부장에게 전화를 걸어 샘은 다음과 같은 메시지를 남겼다. “샘 모건이라고

합니다. 제 소개를 드리고 싶군요. 어제부터 근무했기 때문에 이제 막 상황을 파악하

기 시작했습니다. 이번 주쯤 제 부서의 동정에 대해서 조금 더 알게 될 것 같아서 그

때 만날 시간을 정하고 싶군요.” 또한 샘은 제품 개발 부사장이자 운영부서의 부장

인 자신의 상관과도 약속을 했다.

3�

팀원과 업무에 대해 알아가기

팀원과 보내는 시간이 가장 중요하다

관리자 교육 과정이 끝나고, 한 남자가 인상을 쓰며 우리에게 다가 왔다.“매

주마다 모든 사람과 만나야 한다고 말씀하셨습니다. 글쎄요. 제게는 열 명

의 팀원이 있는데 매주마다 모든 팀원을 한 명씩 만난다면 한 주에 다섯 시

간이 걸리죠!”그는 흥분하기 시작했다.“거의 하루 종일이라고요! 팀원과

시간을 보내고 나면 관리 업무를 할 시간이 없습니다.”

사람들과 시간을 보내는 일이 관리 업무다.

예산에 대해서는 전시간 등가치(Full-Time Equivalents, FTEs)주_�를 계산하지만 훌륭

한 팀은 사람에 의지한다. 사람은 대체할 수 있는 제작자나 FTEs의 숫자가

아니다. 훌륭한 관리자는 이 사실을 알기 때문에 부서에 있는 사람에 대해

서 파악한다. 즉 사람의 강점, 약점, 욕구, 스트레스 말이다.

매일 누군가의 사무실에 종일 앉아서 어깨 너머로 지켜보라고 제안하지 않

는다. 이것은 기껏해야 자질구레한 사항까지 챙기는 쫀쫀한 관리거나, 아니

면 최악의 경우 생산성을 떨어뜨리는 간섭일 뿐이다. 사생활을 캐고 사적인

의사결정에 의견을 나누라고 제안하지도 않는다.

단, 여러분에게 보고하는 팀원에 대해 알기 위해서 매주 일대일 회의를 열

것을 제안한다. 팀원이 어느 부분을 잘 하는지, 꺼려하는 일은 무엇인지 알

아보자. 팀원이 어떤 일에 열정적으로 임하는지 알아보자. 또한 그들이 어

떤 사람인지 인간적인 관심을 보이자.

근무 시간을 정하자. 이를테면 사람들이 생각날 때 부담 없이 들릴 수 있도

록 매일마다 특정한 시간(혹은 매주마다 며칠씩)을 정한다.

옮긴이 주_� 전시간 등가치(Full-Time Equivalents, FTEs)는 근로자 한명이 정규직으로 근무할

때 노동시간을 말한다. 따라서 1 FTE = 8시간/일 * 5일/주 * 52주/년 = 2080 시간/년에 해당한다.

FTEs 상세 계산법은 http://www.dmaonline.org/resource/fte.html을 참조하자.

40

Week One첫째 주

팀원과 이야기하자. 이야기할 ‘이유’가 없을 때에도 이야기 나누자. 우리가

아는 어느 관리자는 책상 위에 초콜릿을 놓아 두자 팀원이 자기 사무실에

들르기 시작하는 것을 알게 되었다고 한다. 다른 관리자는 문 밖에 풍선껌

기계를 설치했다.(문은 항상 열어 두었다)

여러분에게 보고하는 팀원에게 인간적인 관심을 보이자. 자신의 상관은

훌륭한 관리자라고 말하는 사람과 이야기를 할 때, 우리가 듣게 되는 첫

번째 이야기는 다음과 같다.“우리 팀장님은 인간적으로 제게 관심을 보

이세요.”

◇◇◇

화요일 아침 10시 30분, 샘은 30분 동안 부서를 돌아 다녔다. 샘은 부서원들의 대

화 분위기를 파악하고 싶었으며 사람들의 에너지와 기분을 느끼고 싶었다. 이번

주말에 부서의 모든 사람이 참석하는 ‘동료 사귀기’ 피자 파티 계획이 잡혀 있지만,

그 전에 사람들을 만나고 싶었다.

샘은 부서를 돌아다니면서, 첫째 날에 만난 사람과 담소를 나눴고 처음 만난 사

람에게 자신을 소개했다.

샘이 제이슨 팀이 있는 곳에 이르렀을 때, 고함 치는 소리를 들었고 무슨 일인

지 알아보기 위해서 다가갔다. 개발자 두 명이 텅 빈 화이트보드 앞에서 싸우고

있었다.

“네가 내 설계를 지웠지! 내가 뭘 해야 할지 모르겠단 말이야.” 엷은 갈색 머리의

개발자가 손가락질하면서 말했다.

41

팀원과 업무에 대해 알아가기

도움을 줄 수 없다면 제안하지 말자

부하 직원을 도우려는 한 관리자의 이야기를 최근에 들었다.“자네들은 회

사의 성공에 꼭 필요한 일을 하고 있네. 내가 어떤 식으로든 자네들을 돕

고 싶은데.”

개발자 가운데 한 명이 말했다.“그렇다면요. 이 일을 더 빨리 끝낼 수 있도

록 세 사람을 더 지원해 주시는 건 어떨까요?”관리자는 찡그리면서 말했

다.“미안하군. 그건 할 수 없네.”

다른 개발자가 요청했다.“저기, 아무도 원하지 않는 이런 구식 장비로 일하

느라 고생입니다. 부장님이 구식 장비를 최신 모델로 교체해 주신다면, 아주

좋을 텐데요. 새로운 장비는 스무 배는 더 빠를걸요.”

관리자가 다시 찡그리면서 말했다.“미안하네. 예산이 없네.”

또 다른 개발자는 아키텍트의 집중적인 지원을 요청했다.“미안하군. 그것도

해줄 수 없겠네. 그 친구가 맡은 새로운 프로젝트도 중요하거든.”

개발자들은 도움을 요청하는 일을 관두었다. 이 이야기의 교훈은‘도움을

줄 수 없다면 제안하지 말라’ 는 것이다.

“뭐라고? 네가 내 설계를 먼저 지웠잖아.” 지우개를 받침대에 던지면서 다른 개

발자가 소리 질렀다.

샘이 끼어 들었다. “안녕하세요, 저는 샘 모건이라고 합니다. 새로운 부장이죠. 제

가 좀 도울게 있나요?“

“저만 쓸 수 있는 화이트보드를 주세요.” 엷은 갈색 머리의 개발자가 투덜거리며

말했다. “다른 사람하고 같이 쓸 필요가 없도록요.” 그의 동료를 가리켰다.

42

Week One첫째 주

“두 사람이 다투고 있는 것처럼 들리는데. 무슨 일이죠?”

두 개발자는 동일한 모듈에 영향을 주는 높은 우선 순위의 수정 작업 두 가지를 하

고 있었다고 설명하였다. 각자가 만든 설계안이 충돌하지 않는지 보장하기 위해서

개발자마다 상대방의 설계를 살펴봐야 했다. 그런데 한 사람이 다른 사람의 설계를

지운 것이다.

“그럼 화이트보드가 더 필요한가요?” 샘이 물었다.

개발자들은 서로 쳐다보았다. “아마도. 더 큰 화이트보드라면 좋을 것 같네요.” 샘

은 노트에 ‘제이슨에게 프린트가 가능한 새로운 화이트보드(- 더 많은 화이트보드?

- 더 큰 화이트보드?)에 대해서 물어 볼 것’이라고 적었다.

“제가 여러분들이 다시 일할 수 있도록 할게요.” 샘은 두 사람에게 말하고 나서, 다

시 부서를 돌아다녔다. 샘은 부서를 돌아다니면서, 이곳 저곳에서 사람들의 이야기

를 듣고 질문을 하고 메모장에 메모를 했다.

샘은 사무실로 돌아와서 메모를 훑어봤다.

모든 사람이 너무 열심히 그리고 늦게까지 일한다.

지난 밤 저녁 식사 이후 빈 피자 상자와 배달 음식 상자가 쌓였다.

직원들이 화이트보드에 도표를 지우는 일 같은 사건에 과도하게 반응

하는 것 같다.

한편으로, 직원들은 서로 존중하고 근로 의욕도 괜찮은 듯하다.

43

팀원과 업무에 대해 알아가기

◇◇◇

상황을 잘 파악하자

보이지 않는 곳에서 이뤄지는 관리에 한 가지 예외가 있습니다. 즉 돌아다니며 경

청하면서 관리하기(Management by Walking Around and Listening, MBWAL) 입니다. MBWAL은 팀의 분

위기와 에너지를 측정하기 위해서 관리자가 오감을 사용하는 비공식적인 기술입니

다.[5] 일대일 회의와 더불어, MBWAL은 여러분이 허를 찔리지 않도록 팀원이 심하게

스트레스를 받거나 근로 의욕이 저하 될 때를 미리 알려주는 조기 경고 시스템의 한

부분입니다. MBWAL을 통해 관리자는 일이 진짜로 어떻게 일어나고 팀 내의 문화가

어떻게 발전하는지에 대한 실마리를 얻을 수 있습니다.

MBWAL에 능숙해지려면 호기심을 키우고, 항상 관찰하며, 관찰한 내용의 의미에

질문을 던지세요.

팀원의 공간과 시간을 존중하세요. 팀원을 방해하지 않도록 조심하세요. 부하

직원이 전화하거나 일에 집중하고 있다면 조용히 빠져 나옵니다. 부하 직원이 한가

하다면 들러서 일 이분 정도 이야기를 나누세요. 어떤 질문은 모호해서 오해의 소지

가 있습니다. 즉 “뭐하고 있어요?”나 “어떻게 되고 있어요?”와 같은 질문은 깐깐한

관리의 인상을 줄 수 있는데, 특히 팀원이 시간에 쫓겨 일할 때는 말이죠. “잘 지내고

있어요” 같은 중립적인 질문을 사용하세요.

중립적인 질문보다 더 나은 질문은 도움을 주는 질문입니다. “필요한 게 있나요?”

나 “제거해 줄 장애물은 없나요?” 같은 질문입니다. 상황, 조직의 문화, 여러분과의

관계가 팀원이 질문을 이해하는 방향을 결정합니다. 팀원과 몇 분 이상을 보낼 필요

44

Week One첫째 주

가 있다고 느낀다면 더 많은 대화를 위해서 약속을 정하세요.

말할 것도 없이, 팀원을 도와 주겠다고 약속했다면 끝까지 수행을 해서 도와줘야

합니다. 그렇지 않으면 팀원은 다시 도움을 청하려 하지 않을 겁니다.

메모를 하세요. 팀원이 뭔가를 요청한다면 요청을 즉시 받아 적으세요. 말 없이

돌아다니면서 메모를 하면 팀원들은 여러분을 의심스럽게 생각할지도 모르기 때문

에, 사무실로 돌아와서 관찰한 내용을 기록하세요. 관찰 내용을 기록하기 위해서 메

모장을 사용하세요. 시간이 흐르면서 메모는 조직과 여러분의 관리 방법에서 패턴을

발견하는데 도움이 될 것입니다.

팀원에게 데모를 요청할 때 주의하세요. 때로는, 팀원들은 작업한 내용에 너무나 들

떠서 여러분에게 보여주고 싶어할 것입니다. 그런 경우라면 좋죠! 그러나 제품의 즉

흥적인 데모 요청은 그들의 시간을 함부로 빼앗게 되는 것입니다.

◇◇◇

45

팀원과 업무에 대해 알아가기

수요일 오후 W e d n e s d a y

수요일 오후에, 샘은 각 파트 팀장들에게 다음과 같은 메일을 보냈다.

보내는 사람 : 샘 모건

제목 : 계획 수립 회의

받는 사람 : 각 파트 팀장들에게

이번 주 초에 여러분을 만나 무슨 일을 하는지 알게 돼서 매우 좋았습니다.

제가 들은 다양한 이야기 중의 하나는 일손이 부족하다는 것입니다. 따라서

출시 날짜를 맞추기 위해서 더 많은 사람들이 필요합니다. 이 이슈 때문에

우리는 프로젝트 관리 팀으로서 함께 얘기를 나눌 필요가 있습니다.

이미 여러분에게 할 일이 산더미 같은데 제가 더 많은 일을 주는 것처럼 들

리지는 않을까 걱정되는군요. 그런데 우리가 부서 수준에서 계획을 세우지

않는다면, 어디에 사람을 더 투입 해야할지 모르기 때문에 이 위기에서 탈

출할 수 없습니다.

부서 전체 업무를 담은 큰 그림을 볼 수 있도록 금요일 오후에 두 시간 정

도 회의를 잡았습니다.

이 회의를 준비하기 위해서, 앞으로 3~4주 안에 계획된 일이나 현재 진행

중인 각 팀의 모든 작업 목록을 작성해 주세요. 다음 내용도 포함하세요.

4�

Week One첫째 주

팀의 구성원 명단과 그들이 하는 작업 목록, 그리고 각각의 프로젝트

이름을 명시할 것

앞으로 3~4주 안에 다른 팀에 넘겨 주기로 약속한 산출물

정기적인 작업 목록(예를 들어서 보고서 작업, 유지 보수, 업그레이드)

지속 작업 목록(예를 들어서 고객 지원, 데이터베이스 튜닝)

부서에서 진행 중인 모든 작업의 가능한 완벽한 목록을 보고 싶군요. 관리

팀으로서 부서원 전체가 하는 모든 일들을 우리가 보기 전까지 언제, 어디

에 더 많은 사람들이 필요한지 올바른 결정을 하지 못합니다. 따라서 도표

를 만들기 위해서 이 정보를 이용할 겁니다. 그러면 다음 달에 누가 무슨 일

을 할지 알 수 있겠죠. 요청한 사항에 대해서 질문이 있다면 회의 전까지 메

일을 보내거나 사무실에 잠깐 들러 주세요.

회의는 금요일 오후 3시 회의실 A에서 갖겠습니다.

샘

금요일 오후 F r i d a y

샘은 2시 55분에 회의실 A에 도착했다. 샘이 회의실에 들어갔을 때, 이미 패티가 공

책에 머리를 파묻은 채 있었다.

패티가 쳐다보았다. “어, 안녕하세요. 내일 수업 때문에 과제 복습하느라 자투리 시

간을 보내고 있었습니다.”

●

●

●

●

4�

팀원과 업무에 대해 알아가기

“아, 학위를 위한 수업인가요?” 샘이 질문하면서 플립 차트(Flip-chart) 종이를 벽에 붙

였다.

“그런 셈이죠. 수업과 일, 모두가 도전이죠.” 패티가 한숨을 쉬면서 공책을 덮고 메

모를 정리했다.

제이슨은 서류철을 들고 여유 있게 걸어 왔다. “회의 준비를 끝냈습니다. 제가 맡은

팀에서 진행하는 모든 작업 목록을 만들었죠.”

제이슨을 따라 케빈이 무거운 발걸음으로 들어오면서 불평을 늘어 놓았다. “제가

맡은 팀은 일이 너무 많아요. 제가 도와주기는 하지만 그래도 여전히 할 일이 많거든

요.” 케빈은 회의 탁자에 털썩 앉았다. “하지만 걱정하지 마세요. 우린 할 일은 하고

마니까요.”

오후 3시 5분, 진저가 허겁지겁 도착했다. “죄송해요. 늦었네요...”, 진저가 말했다.

“회의 하시죠!”

“그래요. 우리 모두는 회의를 좋아하죠. 그럼 회의를 시작해 볼까요. 한 팀으로서

우리가 반드시 해야 할 일과 지금 당장 해야 하지만 여건이 안 되는 것들을 알아내기

위해서 여기에 모였습니다.” 샘이 말했다. “여기 벽에 도표 하나를 그려 두었죠.”

“더 많은 사람이 필요한 건 알아요!” 진저가 불쑥 내뱉었다.

샘은 진저에게 고개를 끄덕이면서 대답했다. “모든 작업을 살펴 본 후에 팀마다 어

떻게 진행할지 결정할 겁니다.”

“여러분 각자가 이 도표에 각 팀이 하는 일을 채워주길 바랍니다. 우선은 기능별로

묶어서 우리 부서에 있는 모든 사람의 이름을 적어 두었습니다. 다음 3주 동안 각 팀

원이 할 작업을 적는 데서 시작하죠. 누가 먼저 하겠어요?”

“제가 먼저 하죠.” 진저가 말했다. 진저는 목록을 쥐고 벽으로 성큼성큼 걸어갔다.

4�

Week One첫째 주

여섯 명의 사람을 4주 동안 ‘GUI 코딩’이라고 적었다. 다른 두 사람은, 1주와 2주에는

‘포커스 그룹’주_� 그리고 3, 4주에는 ‘GUI 코딩’이라고 적었다.

“GUI 코딩을 조금 더 상세히 적어 볼 수 있나요?” 샘이 물었다. 진저는 당황한 듯이

옮긴이 주_� 특별한 주제를 사회자의 감독 아래 토의한다. 주제와 관련된 어떠한 특성을 공통으

로 가지는 7~12명의 구성원들로 토의는 진행된다. 주제에 대한 구성원들의 생각을 이해하기 위해

그룹토의는 가능하면 비슷한 대상들끼리 여러 번 이뤄져야 한다. 사회자는 토의의 방향과 분위기를

잡아주고, 모든 토론자들이 활발하게 참가할 것을 장려하고 시간 관리를 한다. 사회자가 말이나 행

동으로 자신의 생각을 토의에 반영하지 못한다. 토의에서 나온 결과를 신중하고 체계적인 분석으로

제품, 서비스, 사업 기회가 구성원에게 어떻게 인지되는지 정보를 얻을 수 있다.

[그림 1.1] 포트폴리오의 시작

4�

팀원과 업무에 대해 알아가기

보였다. “더 자세히요? ‘GUI 코딩’은 개발자들이 하는 일인걸요. 마케팅 요구에 맞춰

서 우리 팀은 GUI 코드를 작성하는 일을 열심히 하고 있어요. 우리 팀원들이 제대로

일을 하고 있다고 믿어요.”

“진저가 팀원을 신뢰하지 않는다는 뜻이 아니에요. 모든 사람이 무슨 일을 하고 우

선 순위가 어떻게 되는지 이해하기 위해서 상세한 정보가 필요하기 때문이죠. ‘GUI

코딩’ 작업 가운데 이전 출시나 앞으로 출시와 관련된 게 있나요?”

“나중에 다시 알려 드릴께요.” 진저가 말했다.

케빈이 다음 차례로 나섰다. “미들웨어팀은 항상 위기 상황이에요.”라고 말하면서

케빈은 자신의 팀이 맡은 업무를 나열하기 시작했다. “우리 팀에는 주요한 프로젝트

4개가 있습니다. 프로젝트마다 모든 사람을 25%씩 할당했습니다.” 케빈은 사각형

각각에 맞춰서 프로젝트 이름 4개를 작게 적었다. “팀원이 동시에 4개의 프로젝트에

서 일할 때 무슨 일을 먼저 해야하는지 어떻게 알죠?” 샘이 물었다.

“저글링juggling하듯이 그냥 돌아가면서 작업하죠.” 샘의 질문에 당황해서 케빈은 언

짢은 얼굴을 했다.

“제이슨 당신은 어때요?” 샘이 물었다.

제이슨은 일어서서 그의 팀이 수행하는 업무를 적기 시작했다. “이 목록을 다시 확

인해 봐야 합니다. 제 목록은 지난 달 업무 보고를 기초로 작성했기 때문이죠.”

제이슨은 일을 지원 업무 50%와 개발 업무 50%로 분류했고 작업마다 메모를 적었

다. “두 사람은 개발 작업 중이고 다른 일곱 명은 지원 업무가 없을 때는 리포트 작업

을 합니다.”

50

Week One첫째 주

멀티태스킹은 집중력을 흩트린다

두 가지 작업(프로젝트나 팀이 두 개라는 뜻이 아니다)은 생산성을 향상시킬

수 있다. 즉 어떤 일을 하면서 막혔을 때 다른 작업으로 전환하는 일이 가능

하기 때문이다. 다른 작업을 하고 있지만 무의식은 계속해서 첫 번째 작업에

매달리기 때문에 멋진 아이디어가 떠오를지도 모른다. 비슷한 수준의 작업

두 개를 처리하는 사람은 훨씬 더 생산적인데, 앉아서 빈둥거릴 틈이 없으며,

동시에 진행하는 비슷한 작업이 상승 작용을 일으킬지도 모르기 때문이다.

서로 연관된 작업을 할 때 생산성이 향상되지만, 작업의 숫자가 많아지면 생

산성은 오히려 곤두박질친다.

작업 전환마다 시간이 소요되기 때문이다. 이를테면 이전 작업을 정리하고

미진한 부분들을 마무리하는 시간과 정리하고, 휴식을 취하고, 생각의 연결

고리를 다시 만들 시간이 필요하다. 따라서 많은 작업을 추가하면 곧 많은

시간이 작업 전환에 사용된다. 즉 생산적인 일을 하는데 쓰이지 않는다.

시간은 결코 재생할 수 없는 자산이다.

“제이슨에게 있는 목록으로 우리는 의사 결정을 내릴 수 있어요. 하지만 다음 단계

를 위해서 최신 작업 목록이 필요할 겁니다. 그런데 지원 업무는 뭐 때문에 생기는 거

죠?” 샘이 물었다.

제이슨은 얼굴을 찡그렸다. “마지막 출시 이후에 끝내지 못한 일이 많습니다. 직접

대안을 찾도록 운영 부서원들을 도우면서, 마지막 출시 때 절반쯤 구현한 기능 두 가

지 정도를 마무리하고 있습니다.”

51

팀원과 업무에 대해 알아가기

패티가 마지막으로 벽에 다가갔다. “전 단지 일주일 분량의 일만 적을 수 있네요.

팀원 4명은 믿을만하고 맡은 일도 끝낼 수 있죠. 하지만 다른 세 사람은… 뭐라 말하

기 어렵습니다. 그래서 일을 다시 할당할 필요가 있는지 없는지 보려고 매주 업무를

평가합니다.”

“참 어려운 문제네요. 그 문제는 다음 주 일대일 회의에서 이야기 나누죠.” 샘은 일

어서서 벽으로 향했다.

“오늘 우리는 많은 진전을 보았지만 조금 더 세부적일 필요가 있어요. 이 작업을 계

속하기 위해서 다른 회의를 잡겠습니다. 그럼 오늘 회의 내용을 정리해 보죠. 다음 회

의 전까지 제가 말씀 드리는 내용을 끝내야 합니다.”

“진저, 팀 내에서 각 그룹이 하는 업무를 조금 더 상세하게 정리해 주세요. 알겠죠?”

진저는 고개를 끄덕였다.

“케빈, 팀원이 업무의 우선 순위를 어떻게 결정하는지 알아 보세요.” 케빈은 고개

를 떨궜다.

“제이슨, 지원과 개발을 조금 더 상세한 업무로 분류해 주세요. 아셨죠?”

“패티, 다음 3주동안 완료할 수 있는 팀 내의 모든 그룹 업무를 정의하세요. 이후에

작업 할당에 대해서 같이 처리하죠.”

“월요일에 일대일 회의를 갖겠습니다. 일대일 회의에서 여러분이 처한 상황에 대

해서 조금 더 이야기 해 보죠. 화요일에 이 작업을 계속하기 위해서 후속 회의를 잡아

두겠습니다. 플립 차트는 제 사무실에 가져다 놓을게요. 다시 모였을 때 이 도표에서

계속해서 작업할 수 있도록요.”

샘이 월요일에 각 관리자들과 만났을 때, 샘은 부서 안에 있는 업무를 조금 더 상세

한 모습으로 어떻게 발전시킬지에 대해 팀장들에게 코칭을 했다. 이를 통해 패티와

진저는 팀원과 개별적으로 이야기하기로 마음 먹었다. 패티와 진저의 팀원은 작고

52

Week One첫째 주

독립적인 프로젝트에서 작업하고 있기 때문이다. 케빈은 팀 회의에서 데이터를 모으

기로 결심했다. 왜냐하면 케빈이 이끄는 팀의 일은 서로 연관되어 있기 때문이다. 제

이슨은 자신의 팀 안에 있는 두 그룹을 별도로 만나기로 결정했는데, 두 그룹 일은 사

실상 서로 달랐기 때문이다. 한 그룹은 개발 작업을 했고 다른 그룹은 출시된 제품을

지원하고 있었다.

샘이 패티를 만났을 때, 샘은 다른 문제를 발견했다. 패티는 관리자가 되고 싶지 않

았다. 패티는 임시로 관리 직무를 맡는데 동의했고, 다시 기술 업무로 돌아가고 싶다

고 설명했다. 샘과 패티는 직무 이동을 의논하기 위한 회의를 잡았다. 샘은 패티가 이

동하기 전까지, 패티가 팀에서 관리 업무를 수행할 수 있도록 코칭을 할 필요가 있다

는 사실을 깨달았다.

◇◇◇

업무 파악을 위한 데이터 수집 하기

승인도 받지 않고, 예산도 없으며, 쓸데없는 업무가 슬며시 여러분의 부서 업무로

끼여 드는 일은 흔합니다. 여러분의 부서에서 진행되는 모든 업무와, 부서가 조직에

어떻게 가치를 부여하는지 파악하기 전에는 어떤 일을 하고, 어떤 일을 하지 말아야

할지, 우선 순위에 대한 좋은 결정을 내릴 수 없습니다.

부서원이 실제로 무엇을 하는지 이해하세요. 각 부서원에게 정보를 얻으세요. 부

서원이 하는 모든 업무, 즉 프로젝트 업무, 임시 업무, 정기 업무, 지속 업무, 관리 업무

등을 이해하세요.

53

팀원과 업무에 대해 알아가기

프로젝트 업무는 시작일과 종료일이 있으며 조직의 정해진 목표를 달성합

니다.

임시 업무는 갑자기 튀어 나옵니다. 위기, 예상하지 못한 업무 요청, 계획에

잡히지 않은 업무를 말합니다.

지속 업무는 비즈니스와 시스템 운영을 유지하고 관리합니다.

정기 업무는 일정한 간격을 두고 생기는 일입니다.

관리는 이러한 일을 계획하고 조직화 하는 것을 망라합니다.

또한 관리 업무는 채용, 인재 계발, 고용도 포함합니다. 예산 수립, 업무 보고, 영향

주기(influencing), 부서 업무를 통한 가치 창출도 관리 업무에 속합니다.

이상의 업무가 여러분 부서의 ‘업무 영역’을 구성합니다.

업무 내용을 담을 수 있는 크고 눈에 띄는 차트를 만드세요. 모든 업무를 도표

안에 펼쳐 놓기 위해서 화이트보드나 벽을 사용하세요. 모든 업무를 가시적으로 만

들어서 부서원 앞에 두면 부서원이 큰 그림과 패턴을 이해 하는데 도움을 줍니다.

반복하세요. 차트를 처음으로 작성할 때는 필요한 모든 정보를 얻지 못할 겁니다.

하지만 계속하세요. ‘코딩’이나 ‘테스트’ 같은 일반적인 업무는 충분한 정보를 주지

못합니다. 일의 결과와 이러한 결과가 비즈니스에 어떻게 가치를 만드는지에 집중하

세요. 또 질문을 할 때는 “누가 산출물을 사용하죠?” “누구에게 이 산출물이 필요하

죠?” “당신이 산출물을 제공하지 못하면 어떤 결과가 생길까요?” 와 같이 구체적으

로 물어보세요. 필요한 상세 정보의 수준을 명확히 표현하면 팀원이 작업의 우선 순

위를 결정하는데 도움이 됩니다.

반감을 이해하세요. 팀원은 실제로 무슨 일을 하는지 여러분에게 이야기하길 꺼

려할 때도 있습니다. 아마도 당신이 지나치게 깐깐하게 굴거나 자신들을 신뢰하지

않는다고 느끼고 있기 때문일 겁니다. 팀원은 조직에게는 의미가 없을 수도 있지만

54

Week One첫째 주

자신에게 가치가 있는 일을 포기해야 한다는 사실을 두려워할지도 모릅니다(여러분도

그렇겠죠). 하지만 계속해서 노력하세요. 즉 팀원이 큰 그림을 이해하도록 도와 주세요.

어떤 업무가 무슨 이유로 중요하고 조직의 목표에 그 업무가 어떻게 부합하는지 말

이에요. 그리고 팀원의 이야기에 흔쾌히 귀를 기울이세요. 여러분이 모르는 것을 팀

원은 알고 있을지도 모릅니다.

연습 하기

팀원과 매주 일대일 회의를 시작하세요. 219쪽의 ‘일대일 회의 성공시키기'

에 나온 지침을 사용하세요.

부하 직원이 직무를 잘 수행하는 것을 알아 차렸다면 그 사실을 언급해 주

세요.

사무실을 나서세요! MBWAL에 핵심은 변화를 알아차리는 것입니다. 사무

실에서 일하는 소리, 사무실 인테리어, 분위기에 익숙해지세요. 자신을 사

무실 안에만 가두지 마세요. 커피를 마시기 위해서 탕비실에 들르고, 식당

에서 점심을 드세요. 더 상세한 아이디어는 208쪽의 ‘돌아다니며 경청하면

서 관리하기'를 자세히 읽어 보세요.

부서가 수행하는 모든 업무의 목록을 만드세요. 여러분 업무도 포함하세요.

부서의 프로젝트 포트폴리오를 시작하기 위해서 이 목록을 활용해 봅시다.

55

팀원과 업무에 대해 알아가기

참고 도서

[1] 켄 블랜차트(Kenneth Blanchard), 스팬서 존슨(Spencer Johnson), 일분 경영, 21세기

북스, 2003년

[2] W. Steven Brown. Thirteen Fatal Errors Managers Make and How You Can Avoid Them.

Berkley Books, New York, 1985.

[3] Esther Derby. “What Your Weekly Meetings Aren’t Telling You.” Better Software, volume

3(6):pages 40-41, March 2004.

[4] Peter Drucker. Managing for Results. Pan Books, London, 1964.

[5] 톰 피터슨(Thomas J. Peters), 로버트 워터맨(Robert H. Jr. Waterman), "초우량 기업

의 조건" 더난출판사, 2005년

[6] Johanna Rothman. “No More Meeting Mutinies.” Software Development, March 2002.

5�

5�

대부분의 경우에 사람들이 처리할수 있는 것보다 업무량이 많기 마련입니다. 모든

일을 하는 것은 불가능하죠. 따라서 명확한 우선 순위를 부여해서 가장 중요한 일을

선택하세요.

이 원칙은 제조 회사와 IT 조직에 똑같이 적용됩니다. 모든 구성원이 하는 일을 이

해하고, 우선 순위를 명확하게 표현해서, 조직과 부서의 목표를 지원하는 업무만을

선택하세요.

혼돈은 사람과 프로젝트에 관련된 문제를 감춥니다. 혼돈이 물러나면 문제는 드러

납니다. 관리자로서 여러분은 문제를 푸는 방법을 선택할 수 있으며, 반드시 문제를

해결해야 합니다.

화요일 오후 T u e s d a y

화요일 오후에 관리 팀이 다시 모였다. “제가 소화해 낼 수 없는 프로젝트는 어떻게

하죠?” 진저가 물었다.

혼돈에 질서 부여하기

Week Two둘째 주

5�

Week Two둘째 주

“일손이 부족한 업무를 기록하는 플립 차트를 만들어 보죠.” 샘이 답했다. “세로 방

향으로 업무를 적고 가로 방향으로 주(Week)를 적겠습니다. 업무에 대해서 주마다 여

러분 생각에 필요한 인원수를 적으세요. 그러면 언제, 어디서 일손이 부족한지 볼 수

있을 겁니다.”

팀장들마다 차례로 보드에 가서 현재 업무에 대한 상세 내용과 다음 3주 동안 계획

을 적었다. 더불어 일손이 부족한 업무 목록도 추가했다.

“여러분이 ‘구조 조정’을 떠올리기 전에, 어느 누구도 직원을 줄이라고 제게 말하

지 않았다는 사실을 여러분께 말씀 드립니다.” 샘은 사람들의 얼굴에서 안도의 기운

을 느낄 수 있었다. 샘은 ‘운영 비용 감소와 이익 향상’이라고 플립 차트에 적었고 모

[그림 2.1] 프로젝트 포트폴리오에서 인원이 부족한 작업을 보여 줌

5�

혼돈에 질서 부여하기

든 사람이 볼 수 있는 곳에 플립 차트를 붙였다. “여러분이 지향하는 목표와 플립 차

트 위에 붙인 목표를 어떻게 일치 시킬 수 있을까요?”

진저가 큰 소리로 말했다. “마케팅 부서가 우리를 괴롭히지 못하게 노력하겠어요.”

“저는 시스템 운영이 잘 되게 해서 고객들을 행복하게 만들겠습니다.” 제이슨이

말했다.

케빈이 말했다 “마케팅이 새로운 데이터베이스에 인터페이스를 원할 때마다 제공

하겠습니다.”

패티가 말했다. “저희는 모든 데이터베이스 변경에 대응 할게요.”

샘은 또 다른 문제가 있다고 생각했다. 모든 팀장이 다른 목표를 갖고 있는데, 따로

따로 존재하는 이러한 목표는 비용 감소와 이익 향상을 지원하지 못하기 때문이다.

“여러분 각자가 다른 목표를 향해 일하는 것처럼 들리는군요.” 샘이 말했다.

“글쎄요, 우리 모두는 제품을 출시하길 바랍니다.” 제이슨이 말했다. “그리고 출시

될 제품을 제대로 유지할 수 있기를요.”

“그래요. 제이슨 말이 맞아요. 우리의 목표가 제때 제품을 출시하고, 운영비용을

낮추는 것이라는 지적은 어느 정도 맞는 말입니다. 그리고 출시일을 제대로 예측할

수만 있다면 이익을 기대할 수도 있죠. 자! 그럼 이 업무 목표 아래에서 작업을 살펴

봅시다. 이 목표를 달성하는데 어떤 일이 도움이 될까요?” 샘이 물었다.

제이슨이 이야기를 이끌었다. “목표가 운영 비용 절감이라면, 저희 팀의 경우 가장

중요한 일은 지난 출시에서 나타난 수정 사항을 반영하는 것입니다.” 제이슨은 샘을

바라 보았다. “다음 3주 동안 모든 개발을 중지하고 모든 사람이 임시로 땜질한 부분

을 수정하도록 배치하면 어떨까요? 우리가 3주 안에 저번 출시에서 나타난 문제에

대해 임시로 땜질한 부분을 완전히 고치면 팀원 중 절반은 일손이 빌 겁니다. 그러면

�0

Week Two둘째 주

그들을 다음 출시 작업에 배치하는 것도 가능할 겁니다.”

“다음 관리 회의의 주제는 완성이 덜된 기능을 줄여보는 방법으로 하겠습니다.”

샘이 동의하면서, 진저를 바라봤다. “진저, 포커스 그룹이 뭐죠? 포커스 그룹이 우리

부서의 목표와 맞나요?”

“음, 저희는 포커스 그룹에서 사용자 편의성 연구(usability study)를 하죠.” 진저가 말했

다. “하지만 당분간은 중단할 수 있다는 생각이 드네요.”

“포커스 그룹 작업을 일단 중지하고, 다른 일을 맡기면요?” 샘이 물었다.

진저가 말했다. “확실히, 인원이 모자란 프로젝트 몇 개를 맡을 수 있어요. 아니면

프로젝트 전부를 맡을 수 있을지도 모르겠네요.”

샘과 관리자들은 작업 목록을 가지고 계속해서 궁리했다. 그리고 지원 비용을 줄

여서 이익을 향상 시키려는 목표에 부합하지 못하는 프로젝트 목록을 만들었다. 회

의가 끝날 무렵에, 샘과 팀장들은 의구심이 드는 프로젝트 여덟 개를 담은 목록을 완

성했다.

“자, 다섯 개의 프로젝트는 작업할 필요가 없다는 것과 세 개의 프로젝트는 취소하

거나 바꿔야 한다는 사실을 확인했습니다.” 샘이 말했다. “이 세 개의 프로젝트는 마

티에게 정확한 답변을 듣기 전까지 계속 진행하세요. 하지만 취소한 다섯 개의 프로

젝트에 있는 사람은 더 중요한 작업에 재배치하세요. 반드시 재배치 이유를 설명해

주셔야 합니다. 그렇지 않으면, 재배치되는 사람들이 힘들 겁니다. 인원 배치 계획을

마련하기 위해서 금요일 오후에 다시 만나죠.”

�1

혼돈에 질서 부여하기

‘잘 나가는 젊은 관리자’의 우화

옛날 옛적에, ‘잘 나가는 젊은 관리자’가 있었다. 이 관리자는 미래가 밝다는

것을 알고 있었는데, 유능한 자신의 지시에 따라서 그날그날 업무의 완료에

초점을 맞춘 세 명의 기술 리더를 포함해서, 스무 명의 부하 직원이 있었기

때문이다.

그러나 기술 리더가 세 명(다른 사람들 17명을 포함해서)이나 있음에도 모든

업무가 결코 끝나지 않았으며, 중요한 작업이 전혀 완료되지 않았다. 기술

리더들은 불평하기 시작했고, ‘잘 나가는 젊은 관리자’도 다소 짜증을 느꼈다.

“스무 명이나 되는 사람이 있다면, 자네는 우선 순위가 높은 업무 정도는 완

료할 수 있어야 하네.” ‘잘 나가는 젊은 관리자’의 상관이 단언했다.“자네에

게 필요한 것은 세 명의 기술 리더와 17명의 사람이 정상적으로 일하도록

자네를 도울 컨설턴트라네.” 이렇게 해서 컨설턴트 한 명이 고용되었고, ‘잘

나가는 젊은 관리자’를 도와서 기술 리더 3명과 17명의 사람이 정상적으로

일하게 만들 컨설턴트가 왔다.

컨설턴트가 처음 왔을 때, ‘잘 나가는 젊은 관리자’에게 3명의 기술 리더와

17명의 사람이 하는 모든 업무를 설명해 달라고 요청했다.

“스프레드시트에 프로젝트마다 누가 담당이고 시작일, 종료일이 언제인지 모

두 담겨 있습니다.” ‘잘 나가는 젊은 관리자’는 진보적인 관리 체계에 약간의

자부심을 느끼면서 말했다.

“35개의 프로젝트가 진행 중이군요.” 컨설턴트가 말했다. “무척 일이 많네요.”

‘잘 나가는 젊은 관리자’가 환하게 미소 지었다. “사실은, 보시는 것처럼 최

근에 우리 회사는 훌륭한 제품 가운데 세 개를 단종시켰습니다. 그런데 수

년간 이 제품을 사용하는 고객을 지원했기 때문에, 고객을 못 본체 할 수가

없더군요.”

�2

Week Two둘째 주

컨설턴트가 턱을 만졌다. “당신의 고객 서비스 정신은 존경할 만하네요.” 컨

설턴트가 말했다. “그런데 제가 생각하기에 당신이 제공해 주는 고객 맞춤

지원은 공짜 아닌가요?”

컨설턴트는 눈썹을 치켜 올렸다. ‘잘 나가는 젊은 관리자’ 는 고개를 끄덕였다.

“네. 맞습니다.”컨설턴트는 계속 물으면서 메모를 했다.“그리고 고객은 무

기한으로 이 단종된 제품을 불편 없이 계속해서 사용할 수 있겠네요.”

‘잘 나가는 젊은 관리자’ 는 고개를 끄덕였으며 컨설턴트의 재빠른 상황 파악

에 만족했다.

“그렇다면 고객이 지금 제품에 만족하는데, 과연 회사가 열심히 팔려는 새로

운 제품을 구매해서 회사에게 이익을 줄까요?”

‘잘 나가는 젊은 관리자’가 잠시 생각하더니, 고개를 떨구었다.“당신은 고객

서비스를 진정으로 이해하지 못하는군요.”그리고는 ‘잘 나가는 젊은 관리자’

가 말했다. “그럼 이 일에서 손을 떼세요.”

컨설턴트가 떠난 뒤에, ‘잘 나가는 젊은 관리자’ 는 사무실로 가서, 문을 닫고

꼼꼼히 스프레드시트를 검토했다. 젊은 관리자의 얼굴은 붉게 상기되기 시

작했다.“이런, 내가 실수를 저질렀군.”하고 생각했다.

다음 날, ‘잘 나가는 젊은 관리자’ 는 모든 고객 맞춤 지원 프로젝트와 펫 프

로젝트(Pet project)주_� 몇 가지를 중단시켰다. 젊은 관리자는 두 명의 기술 리더

와 17명의 사람 가운데 몇 명을 재배치했다.

그러자, 중요한 업무가 마무리됐으며 세 명의 기술 리더와 17명의 사람은 적

당한 시간에 다시 퇴근할 수 있게 됐고 사기가 높아졌다.

옮긴이 주_� 펫 프로젝트(Pet project)는 조직의 리더가 개인적인 관심이나 중점을 두어서 추진하

는 프로젝트다.

�3

혼돈에 질서 부여하기

“컨설턴트가 진짜로 정상으로 만들어 놓았군.”‘잘 나가는 젊은 관리자’의 상

관이 얼마 지난 후 말했다.

“글쎄요. 덕분에 제 스스로 많이 깨달았죠.”‘잘 나가는 젊은 관리자’가 겸손

하게 말했다.“이익이 없는 프로젝트 때문에 혼란을 초래하게 두지 않겠습

니다. 그리고 항상 전체적인 회사 목표에 비중을 두겠습니다. 적절한 집중이

있어야 할 일이 끝난다는 사실을 알게 됐습니다.”

“역시, 자네는 확실히 계속해서 잘 나갈 젊은 친구일세.”상관이 자애롭게

미소를 지으면서 말했다.

이 우화의 교훈은 다음과 같다. 돈이 되는 업무에 집중해라.

(많은 우화처럼, 이 이야기도 실화다.)

◇◇◇

프로젝트 포트폴리오를 만들자 : 목표와 업무를 일치 시키자

모든 그룹과 부서에는 업무 목표가 주어집니다. 업무 목표는 부서의 존재 이유며

조직에 어떻게 가치를 제공하는지 설명해 줍니다. 조직이 발전하는 과정에서 사람들

은 각 시점에 합리적인 방식으로 업무를 처리합니다. 하지만 목표와 우선 순위가 변

하면 업무도 변해야 합니다. 프로젝트 포트폴리오를 구성하기 위한 정보를 한 번 수

집해 보세요. 부서의 목표에 더 이상 기여하지 못하는 업무도 발견할 것입니다.

제가 몸 담았던 모든 조직에는 적어도 리포트 하나씩은 있었습니다. 보통은 이 리

�4

Week Two둘째 주

포트 작성에 부서원이 많은 근무시간을 보내지만, 지시한 사람이 더 이상 존재하지

않게 되면 리포트는 재활용 쓰레기가 되고 맙니다. 즉 리포트를 최초로 요구한 사람

이 다른 부서로 가거나 아니면 승진해서 다른 부서로 옮겨 갔거나, 회사를 나갔기 때

문에 누구도 더 이상 그 리포트를 필요로 하지 않습니다. 재활용 쓰레기 신세의 리포

트는 단지 알기 쉬운 예제일 뿐입니다. 우리는 지속 업무에 대한 필요성을 파악하는

데 능숙하지만, 더 이상 필요하지 않게 됐을 때 그 사실을 종종 알아차리지 못합니다.

크고 눈에 띄는 차트를 만들어서 업데이트 하세요. 수행되는 일을 파악하게

될 때마다 차트를 갱신하는 겁니다. 계획을 세우는데 이 차트는 유용합니다. 차트는

동시에 모든 사람이 동일한 그림을 보도록 도와 줍니다. 차트에 대해 모두 관심을 가질

수 있도록 항상 최신의 자료를 업데이트 해서, 모든 사람이 패턴과 문제를 볼 수 있게

합니다. 그리고 때로는 해결책을 찾아보게 합니다. 사람들이 차트 주위에 모여서 일이

어떻게 맞물리는지 이야기하는 광경을 자주 보게 될 겁니다.

부서 목표를 명백히 밝히고 대화를 나누세요. 부서 목표를 이해하지 않고서

우선 순위에 대한 결정을 내릴 수 없습니다. 부서 목표를 한 페이지로 작성해서 눈에

잘 띄게 붙여 두세요. 목표는 관리자의 전유물이 아닙니다. 목표는 부서 사무실의 열

린 공간에 존재합니다. 눈에 띄는 목표는 사람들을 올바르게 나아가게 하며, 좋은 결

정을 내리도록 돕고, 부서의 목표에 일치하지 않는 일(특히 정해지지 않은 업무)에 모든 사

람이 도전하게 합니다.

여러분의 상사가 여러분을 위해서 부서 목표를 정해 줄 때까지 기다리지 마세요.

여러분의 이해에 부합하는 목표를 생각해내고, 피드백을 받기 위해서 관리자에게 그

목표를 전달하세요. 여러분에게 업무에 우선 순위를 부여하고 일을 효과적으로 하기

위해서 추구하는 목표가 있어야 합니다.

�5

혼돈에 질서 부여하기

제품을 만들거나 지원 조직에 있다면?

소프트웨어 제품을 팔아 돈을 버는 회사에서 일하는 것과 다른 제품이나 서

비스를 팔아서 돈을 버는 회사의 IT 지원 부서에서 일하는 것은 다르다. 그

러나 본질적으로 큰 차이는 없다.

소프트웨어 제품을 팔아 이익을 남기는 회사에서 소프트웨어를 만드는 작업

에 여러분의 부서가 참여하고 있다면 업무와 최종 제품 사이의 연관성은 명

백하다. 그러나 여러분이 IT 부서에서 일한다고 해도 부서와 최종 제품 사이

의 관계는 직접적이지는 않지만 여전히 중요하다.

하지만 부서의 업무 목표(그리고 전략적으로 중요한 일)를 정의하기 위한 질

문의 초점이 다르다.

소프트웨어 제품 회사에서는 다음과 같은 질문을 한다.

부서의 업무는 이익 달성에 어떤 식으로 기여하는가?

신규 고객을 유치하고 기존 고객을 묶어 두기 위해서 부서 업무는 어

떻게 하고 있나?

IT 부서에서는 다음과 같은 질문을 한다.

회사가 비즈니스를 하기 위해서(혹은 더 많은 사업을 더 능율적으로,

또는 더 효과적으로 하기 위해서) 부서 업무를 어떻게 하고 있나?

부서 업무는 회사의 최종 제품에 어떻게 영향을 주고 있나?

비즈니스 기능을 계속하고 이익을 창출하기 위해서 부서 업무는 사

업부의 실무 능력을 어떻게 지원하고 있나?

제품이나 서비스를 판매하는 회사와 소프트웨어를 파는 회사는 이익을 창출

하고 고객 관리를 하는 데 초점을 둔다. 소프트웨어 제품을 만드는 부서의

업무 목표는 IT 부서의 업무 목표와 다르게 보일 것이다. 그러나 부서의 업

무 목표를 정의해 보면 업무를 관리하는 것은 실제로 상당히 비슷하다.

●

●

●

●

●

��

Week Two둘째 주

모든 프로젝트를 분류하세요. 일단 완벽한 목록을 손에 넣으면, 부서의 목표에

맞춰서 모든 프로젝트를 검토합니다. 그리고 다음과 같은 네 가지 목록을 작성하세요.

계속 수행할 프로젝트와 업무

중단해야 할 프로젝트와 업무. 즉 ‘하지 말아야 할 작업’ 목록입니다. 회사

안의 어느 누구에게도 가치를 제공하지 못하는 업무입니다. 당장 업무를

중단하세요.

중요하기는 하지만 부서 목표에 부합하지 않는 프로젝트와 업무. 여러분이

단순히 중단할 수 없는 업무입니다. 그렇기 때문에 더욱 알맞은 부서에 업

무를 넘기세요.

어떤 부서에 맞는지 알 수 없는 프로젝트와 업무. 두 번째나 세 번째 분류에

해당하는지 확신할 수 없는 업무입니다. 프로젝트를 취소하거나 넘겨주기

전에 알아 보세요.

무엇을 할지 결정하기 위해서 관리자와 마지막 두 목록에 대해서 토론하세요. 하

지 말아야 하는, 전략적으로 중요하지 않은 업무를 다시 재배치하기 위해서 상관과

같이 의논하세요.[9] 다른 부서 사람이 업무를 인수하기 전까지 해당 업무를 계속해서

수행할 필요가 있는지 혹은 단순히 업무를 취소할 수 있는지 결정하세요. 신중하게

의사결정을 하고 상관과 이 사실을 알아야 하는 다른 사람에게 알려 주세요.

◇◇◇

��

혼돈에 질서 부여하기

목요일 T h u r s d a y

패티가 더 이상 관리직을 수행하고 싶어 하지 않는다는 사실을 샘이 안 지 삼일이

지났다. 패티는 데이터베이스 아키텍트가 되길 원했다. 샘은 출근 첫 달부터 관리 팀

의 주요 구성원을 바꾸고 싶지 않았지만, 그렇게 해야만 했다.

샘은 패티와 회의를 하기 전에 생각을 정리할 시간을 가졌다. ‘다음과 같이 세 가지

다른 길이 있다. 우선 패티는 데이터베이스 그룹에 머물길 원할지도 모르고. 아니면

회사 안에서 다른 업무를 찾거나 회사를 그만둘 수도 있다. 난 적어도 패티가 우리 회

사에 있길 바란다. 회의에서 다음의 세가지 주제를 확실히 다루어야겠다.'

패티가 관리 업무를 그만두길 원하는지 확인할 것

관리자 업무를 분석하는 데 패티의 도움을 받을 것

업무를 완료하지 못하고 있는 데이터베이스 팀원을 위해서 무슨 일을 할지

결정할 것. (아직 데이터베이스 팀원이 일에 대한 동기를 잃지 않았는지 확

신할 수 없다.)

관리 업무에서 물러 나기

관리 업무가 모든 사람에게 맞는 것은 아니다. 관리 업무가 여러분에게 맞

지 않거나, 관리 업무가 여러분에게 아직은 적당하지 않다는 사실을 깨달았

다면, 기술직으로 되돌아가도 괜찮다. 어떤 사람은 ‘물러 났다’는 오명을

씌우지만, 장기적으로 경력에 손해를 입은 사람을 본 적이 없다. 게다가 기

술직을 다시 선택한 사람과 그 사람이 관리하던 부서의 스트레스 수준이 급

격히 떨어지는 것도 봤다.

��

Week Two둘째 주

확신이 서지 않는다면, 조직 안에서 성공한 기술 관리자에게 진로에 대해서

물어 봐라. 대부분의 관리자는 기술을 선도하는 역할과 기술 관리 역할 사

이에서 오락가락했다고 말할 것이다. 그들은 한 가지 일에서만 경력을 쌓지

않았다.

관리자에 관한 우리의 연구에서, 최고의 관리자는 관리 업무나 기술을 선도

하는 역할 가운데 하나에 집중하기로 결정하기 전까지 이러한 두 가지 업무

를 번갈아 맡았다는 것도 알게 되었다.

명심해라, 기술 관리는 기술이 아니라 사람과 일하는 것이다. 물론 기술 관

리 역할 가운데 하나는 기술적 의사 결정에 맞춰져 있다. 하지만 사람들 사

이에서 부대끼며 일하고 싶지 않다면 관리 업무에서 물러 나자. 다음과 같

은 질문을 자신에게 던져 보자.

더 많은 기술적 의사 결정을 다루길 원하는가?

인사 문제보다 기술 문제를 해결하는데 더 많은 관심이 있는가?

두 질문에 대해서“예”라고 대답했다면, 여러분은 사람을 다루는 역할보다

기술을 선도하는 역할이 더욱 편할 것이다. 기술직에서도 사람을 다루는 방

법을 항상 연습할 수 있다. 이 경험은 여러분이 미래에 사람 지향적인 관리

역할을 맡을 수 있을지 스스로 판단할 수 있도록 정보를 제공해준다. 관리

업무가 여러분에게 맞다고 생각한다면 스스로에게 다음과 같이 질문하자.

사람들과 함께 일하길 좋아하는가?

사람들을 코칭을 하고 조언을 해주는 것을 좋아하는가?

피드백을 주는 법을 배우고, 필요하다면 하기 힘든 대화도 사람들과

기꺼이 하겠는가?

위의 질문들에“예” 라고 대답했다면, 관리 업무는 여러분에게 적합할지도

모른다. 지금 당장이나 미래에 말이다. 어느 누구도 태어나면서부터 위대한

관리자가 아니기 때문에 위대한 관리자가 되기 위해서는 연습이 필요하다.

●

●

●

●

●

��

혼돈에 질서 부여하기

샘이 고개를 들었을 때 패티가 문 앞에 서 있는 것을 보았다. “들어와요, 패티.”

패티는 앉으면서 노트를 폈다.

“다시 확인하고 싶어요. 관리 업무에 대해서 생각할 시간을 가졌겠죠. 패티, 확실

히 기술직으로 되돌아가길 원하나요?” 샘이 물었다.

패티는 허공을 응시하다가 샘에게 시선을 옮겼다. “전 팀장이 되고 싶은 적이 한 번

도 없었어요. 전에 있던 상관이 후임자를 찾는 동안 잠시 팀장을 맡는다고 생각했죠.

전 데이터베이스 아키텍쳐 업무를 좋아해요. 그런데 팀장이 된다면 그 일을 할 수 없

어요.”

“잠깐동안 패티의 경력 목표에 대해서 이야기 나눠 보죠.” 샘이 제안했다.

패티는 샘을 똑바로 쳐다봤다. “전 기술적인 업무를 하고 싶어요. 그것 때문에 학

교에서 석사학위를 공부하고 있죠. 관리 업무는 지금 당장 제가 하고 싶은 일은 아니

에요.”

“패티가 기술직으로 복귀하기 위해서는 데이터베이스 팀에 준비할 시간을 줘야

합니다.” 샘이 말했다. “같은 팀에 머물더라도 다른 업무를 맡을 거에요. 이것은 팀을

다시 꾸려야 한다는 뜻이죠. 그리고 사람들이 패티를 관리자가 아닌 그들의 동료로

서 다시 받아들이려면 얼마간의 시간이 걸릴 거에요.”

“새로운 팀장도 뽑아야 하고요.” 샘이 말했다. “전 패티가 새로운 팀장을 뽑는데 도

와줬으면 좋겠어요. 그러고 나서 데이터베이스 팀이 더욱 신뢰할만하게 일을 마치도

록 도울 방법에 대해 고민할 필요도 있고요.”

패티가 눈썹을 찡그렸다.

“전 새로운 팀장을 뽑아서 형편 없는 성과를 관리해야 하는 상황에 배치하고 싶지

않아요. 데이터베이스 팀원에게 피드백을 준 적은 있나요?”

�0

Week Two둘째 주

패티가 한숨 지었다. “네. 어느 정도는요. 하지만 문제는 이거예요. 저는 누군가에

게 업무 성과가 낮다고 질책하고 싶지 않아요. 어느 정도 그 팀원에게 얘기하고 힌트

를 주었지만, 이해하지 못하더군요.” 패티가 머리를 가로질렀다.

‘패티와 같이 피드백에 대해서 알아볼 필요가 있겠어. 다른 얘기가 되겠지만.'하고

샘이 생각했다.

“제대로 성과를 내지 못하는 사람들 문제에 대해 한 번 얘기해보면 어떨까요? 팀

원들이 수행한 업무 결과를 받아 들일 수 없을 때 그것을 사람들에게 알려 주는 일이

중요하죠. 패티가 그들에게 실질적인 피드백을 주길 바래요. 그래서 성과를 내지 못

하는 팀원에게 어떻게 말해야 하는지 패티에게 조언 할게요.” 샘이 제안하였다.

패티는 안심한 듯이 보였다. “좋은 생각이세요. 피드백을 주기 어려웠던 이유 중에

하나는 무슨 말을 할지 몰랐기 때문이죠.”

“다음 번에 계획된 일대일 미팅에서 피드백을 다뤄보죠. 자, 패티의 업무를 분석하

는데 남은 시간을 보냅시다. 우선은 목록을 만들어 보죠. 지금 누구랑 일하고 있고 제

공할 산출물은 뭔가요?”

샘과 패티는 패티의 역할에 대해서 의논하여 그림 2.2의 목록을 얻었다.

샘과 패티는 데이터베이스 팀장의 역할을 성공적으로 수행하기 위해서 필요한 기

술 외적인 역량, 성품, 우선 순위를 파악하려고 상호작용 및 산출물 목록을 살펴 보았

다. 그런 후에 나서 샘과 패티는 새로운 팀장이 어느 정도로 기술적으로 깊이 알아야

하는지 의논했다. 우선은 테이터베이스 기술 역량을 검토했고 새로운 팀장이 얼마나

빨리 제품 내부를 살펴보고 이해해야 하는지 의논했다. “매우 도움이 됐어요. 직무 설

명서를 작성하기 위해서 이 분석 자료를 사용할 수 있겠네요. 고마워요.” 샘이 웃으면

서 말했다.

“우리가 놓친 게 없는지 살펴 보기 위해서 관리 팀의 나머지 사람들에게 이 분석

�1

혼돈에 질서 부여하기

자료를 돌려 보죠. 패티의 역할 변경과 새로운 관리자 채용을 위해서 인사 부서와의

협의와 서류 작업은 제가 맡을게요.” 샘이 말했다. “그리고나서 면접 팀을 구성하고

지원자를 찾아 보죠.”

[그림 2.2] 패티의 관리 업무 산출물 목록

�2

Week Two둘째 주

빠른 조치

면접 팀의 도움으로 샘은 지원자를 평가했다. 3주 후에, 가장 적당한 지원자가 가

려졌다. 샘은 최고의 지원자인 브라이언에게 입사를 제안했다. 샘과 패티는 새로운

팀장이 진흙탕 속으로 걸어오지 않도록 데이터베이스 팀의 이슈를 해결하는 작업을

계속했다.

제안을 수락한 2주 후에, 브라이언이 출근했다.

브라이언이 첫 출근하던 저녁 무렵 패티는 차로 향했다. 패티는 지쳤고, 안도했으

며, 조금은 슬펐다. ‘브라이언이 첫 출근하는 날이 이렇게 힘들 줄은 미처 몰랐는걸.

데이터베이스 아키텍트로 되돌아가서 행복해. 하지만 관리 팀의 일원으로서 진저,

케빈, 제이슨과 같이 일한 것도 막 즐거워지고 있었는데. 아마도 그리울 거야. 관리

팀에 작별 인사를 하는 것이 가슴 아파.'

◇◇◇

사람들에게 맞는 역할 찾기

강점과 재능에 맞는 역할을 주세요. 자신이 갖고 있는 기술과 흥미가 역할과

맞지 않는다면 어느 누구도 성공할 수 없습니다. 우수한 많은 사람이 잘못된 역할을

맡고 있기 때문에 ‘낮은 성과’를 보입니다. 사람들에게 맞지 않는 역할에 고집하기 보

다는 맞는 역할을 찾아 주세요.[3]

피드백 하기. 때로는 사람들이 훌륭한 결과를 내지 못하는데도, 어느 누구도 그

들에게 잘못된 부분에 대해 말해 주지 않습니다. 이러한 정보가 없다면 사람들은 무

�3

혼돈에 질서 부여하기

엇을 바꿔야 하는지 모를 뿐만 아니라, 변화가 필요한지도 모릅니다. 누구를 성과가

낮은 사람이라고 단정 짓기 전에 명확한 기대치를 얼마나 잘 설정했고, 타당한 중간

산출물을 선정했으며, 업무 결과의 품질에 대해서 만족 여부를 알려 줬는지 스스로

검토해 보세요. 상세한 내용은 200쪽의 ‘효과적인 피드백을 위한 지침'을 참조하세요.

최고의 인재를 고용하세요. 업무에 적합한 사람을 고용해서 알맞은 상태에서

시작하는 것이 이상적입니다. 고용은 관리자가 할 수 있는 가장 중요한 결정입니다.[10]

사람을 뽑을 때 해당 직무의 영향도가 클수록 고용을 위한 결정이 더 중요합니다. 우

리는 앞 문단에서 패티를 대신할 후임자를 뽑는 이야기에서 말한 내용 이상으로 고

용이 중요한다고 생각합니다. 따라서 여러분께 사람을 뽑는 절차를 알려 드리겠습니

다. 더욱 상세한 내용은 요한나의 책을 보세요.[10]

업무를 분석하세요. 지원자를 모집하기 위한 광고를 하기 전에, 새로 뽑을 사람

들이 무슨 일을 하길 바라는지 정확히 이해해야 합니다. ‘관리 업무’는 적당한 직무

설명이 아닙니다. 업무를 분석하고 직무 설명을 작성해서 사람을 뽑을 준비를 하세요.

할 수 있는 한 상세하게 직무 설명을 작성해야 하지만, 인사 부서가 좋은 지원자를 탈

락 시키는 제한 요인이 되어서도 안됩니다.

다음은 과도한 제한 사항을 포함한 직무 설명 예제입니다. ‘멀티 스레드 응용 프로

그램과 실시간 임베디드 시스템 및 트랜잭션 처리 시스템 전문가. 12~15명의 개발팀

을 관리하고, 한번에 고층 빌딩에 뛰어 올라야 함.’ 이 모든 업무를 할 수 있는 지원자(어

느 누구도!)는 결코 찾지 못할 것입니다.

지원자를 모집하세요. 자격 있는 지원자를 찾기 위해서 다양한 공급원을 활용하

세요. 회사의 웹사이트, 다른 구인 게시판, 인맥, 광고, 구인 박람회는 지원자를 찾기

에 훌륭한 곳입니다. 지원자를 찾는데 어려움을 겪는다면, 외부 채용 전문가 활용하

세요. 즉 여러분이 찾으려는 종류의 지원자를 어떻게 찾는지 아는 사람들 말입니다.

지원자를 분류하세요. 이력서가 도착하면 읽고 나서 가장 적합한 사람을 분류하

�4

Week Two둘째 주

세요. 우리는 다음과 같이 세 개의 분류로 이력서를 정리합니다. 즉 합격, 불합격, 보

류입니다. 전화 인터뷰로 합격 분류에 있는 사람들을 즉시 가려냅니다. 전화 인터뷰

를 한 후에 충분한 지원자를 확보하지 못했다면, 보류 분류로 넘어갑니다. 불합격 분

류에 있는 사람들에게 불합격했다는 사실을 알려 주세요.

행동 기술 질문(Behavior description question)을 개발하세요. “… 했을 때에 대해서 이야

기해 주세요.”와 같은 행동 기술 질문은 지원자들이 앞으로 어떻게 일하길 원하는

지 보다는 과거에 어떻게 일을 했는지 설명해 줍니다.[8] “만약… 라면 어떻게 하시겠

어요?”와 같은 가설에 근거한 질문은 지원자들이 진짜로 어떻게 행동할지 알아내지

못합니다.

직접 면접을 하기 전에 전화 면접을 하세요. 특별히 관리 업무 지원자의 경우

에는, 다음과 같이 예의없는 지원자를 걸러내는 전화 테스트(dirtbag phone screen)주_�를 고

려해 보세요.[6] 일반 관리자나 관리 업무를 보지 않는 다른 사람이 전화를 걸어서 취

업 기간과 같은 기본 정보를 확인해 보세요. 또 좀더 심도 있는 전화 면접에도 대응

을 잘 하는지 살펴보세요. 좋은 관리 업무 지원자라면 이러한 전화 면접 과정에서 고

용 담당 관리자만이 아니라 어느 누구와도 이야기하길 좋아할 것입니다.

오디션을 개발하세요. 오디션을 하면 지원자가 실제로 일하는 것을 볼 기회가

여러분에게 주어집니다. 즉 업무의 작은 일부를 수행하는 것이죠.[5] 관리 업무 오디

션은 공급자(구매하는 곳)와 협상하기, 일정 변경하기, 고용하기, 회의 주재하기, 피드백

주기, 반갑지 않은 소식 전하기 및 그 외 다른 관리 업무를 포함합니다.[10] 능력을 발

휘하는 것을 보는데 오디션은 상당히 유용합니다.

옮긴이 주_�　예의없는 지원자를 걸러내는 전화 테스트는 실제 업무를 맡은 담당자가 아닌 지원 부

서 사람에게 전화를 걸게 만들어서 지원자가 어떤 반응을 보이는지 파악하는 테스트. 지원자는 보

통 지원 부서 사람들에게 무례하게 군다는 사실을 이용한 테스트다.

�5

혼돈에 질서 부여하기

능력은 성공의 일부일 뿐이다.

대부분의 관리자는 우수하고, 능력 있으며, 성공할 가능성이 많은 사람을 뽑

으려고 한다. 그러나 상당한 능력을 보이는 사람들이 항상 성공하는 것은 아

니다. 어떤 경우에는 관리자는 최적이 아닌 듯한 부하 직원을 승계 받기도

한다. 낮은 성과는 부족한 능력의 결과일지도 모르지만, 한편으로 다른 요인

때문일 수도 있다.

성과는 주변 환경과 관리 업무의 품질에도 영향을 받는다. 여러분이 누군가

를 성과가 낮은 사람이라고 단정 짓기 전에, 그 사람이 성공할 수 있는 환경

을 제공해 주었는지 확인해야 한다. 다음과 같은 질문을 자신에게 물어 보자.

나의 우선 순위를 전달해서 언제 무엇을 할지 올바른 결정을 내리도록

했는가?

자신의 언어로 나의 바람을 다시 표현하게 해서 내 기대를 확실히 이해시

켰는가?

업무 지시를 할 때 명확히 했는가? 즉 업무에 대한 초기 제약 조건

및 범위 말했는가?

내 기대에 맞게 바뀔 수 있도록 명백하고 분명한 피드백을 제공했는가?

필요한 기술을 습득하기 위한 선택 사항(option)에 대해서 논의하였는가?

이와 같은 활동들을 했음에도 낮은 성과를 내는 사람이 여러분이 여전히 원하

는 결과를 주지 않는다면, 환경(절차, 측정, 보상)과 시스템 문제 안에서 원인을

살펴 보자.

우리가 아는 한 회사는 고객 상담실 직원이 처리하는 전화의 통화 시간을

목표 지표로 설정했었다. 이 목표 지표는 간단한 문제에는 적당했다. 하지만

제한시간을 넘길 수밖에 없는 복잡한 상담 전화가 문제였다. 상담실 직원은

고객의 문제를 해결해주고도 징계를 받았다.

●

●

●

●

●

��

Week Two둘째 주

다른 회사는 촉박한 데드라인에 소프트웨어를 출시하는 습관이 있었다. 데

드라인이 촉박할수록, 개발자와 테스터는 문제를 예방, 해결, 수정하는데 더

적은 시간을 투입할 수밖에 없었다. 그렇기 때문에 기술 빚(Technical debt)주_�이

늘어났다. 매 번, 관리자가 기술 빚을 수정하기 위해서 되돌아 가려는 의도

는 가졌다. 그러나 새로운 출시 때마다 충분한 시간이 없었다. 따라서 출시

가 늘어날수록 코드는 점점 더 취약해졌고, 취약한 코드는 수정에 더 오랜

시간이 걸렸다. 따라서 출시 때마다 데드라인을 지키는 것은 더 어려워졌고,

기술 빚은 늘어갔다. 코드를 변경하는 것은 점점 더 어려워졌으며 더 많은

에러가 나타났다. 기술 빚 투성이의 코드에서 작업하는 사람은 어느 누구든

지 형편 없게 보였는데, 그 사람이 작성한 코드는 망가지는 경향이 있었기

때문이었다.

관리자들이 하는 실수 가운데 하나는 환경이나 시스템 문제를 개인 문제

로 낙인 찍는 것이다. 즉 낮은 성과를 내는 사람을 해고해 버린다. 그러나

환경 문제나 시스템 문제라면, ‘낮은 성과를 내는 사람’이 해고되어도 이

문제는 사라지지 않는다.

옮긴이 주_� 기술 빚(Technical debt)은 워드 커닝험(Ward Cunningham)이 만든 은유로써, 재정적

인 빚처럼 소프트웨어를 개발하면서 잘못된 설계나 구현 등을 제때에 수정하지 않는다면 사소한 문제들

이 빚처럼 쌓여서 유지보수나 출시 단계에서 기술 빚을 해결하기 위해서 많은 자원이 필요하다는 뜻이다.

맡아서 할 업무에 많은 양의 기술적인 내용도 있다면, ‘모호한 설계 문제내기’는 매

우 유용한 기술입니다. 지원자가 문제를 명확하게 풀기 위해서 질문을 하는지 들어

보세요. 피드백이나 새로운 정보와 마주쳤을 때 지원자가 엉성한 설계로 임하는지

관찰하세요. 지원자가 해결책 또는 타협안(Trade-off)을 잘 이해하고 받아들이는지도 살

펴 보세요.

��

혼돈에 질서 부여하기

면접 팀과 함께 지원자를 면접하세요. 면접 팀과 지원자 사이에서 일대일 면

접을 계획합니다. 답변에서 일관성을 알아 보지 않는 이상, 같은 질문을 중복해서 지

원자에게 묻는 것을 피하세요.

일대다 면접은 시간을 줄여주는 것처럼 보이지만, 효과적이기 위해서는 상당한 공

동 작업과 연습이 요구됩니다. 더 나아가 일대다 면접은 지원자에게 심문처럼 느껴

지기도 합니다.

새로운 팀원들이나 팀 리더를 선택할 때는 가능한 많은 사람을 참여 시키세요.

지원자를 면접하는 사람이 많아질수록, 여러분과 팀이 사람을 뽑는데 실수할 가능성

이 더 줄어들 것입니다. 더 적은 사람이 관련될수록, 지원자의 다른 면을 더욱 놓치기

쉬워집니다.

면접 팀의 평가에 귀 기울이세요. 면접이 끝나면, 평가 회의를 위해서 면접 팀

을 소집하세요.[6] 평가 회의에서 면접 팀원들이 각 지원자들의 인상을 공유할 수 있

습니다. 관리자로서 여러분이 누굴 뽑을지 최종적으로 결정하지만, 면접 팀의 의견

을 들어야 합니다. 면접 팀의 의견을 무시한다면 매우 위험해질 것입니다.[10]

추천서를 확인하세요. 업무에 적당한 지원자를 파악했다면, 추천서를 확인하세

요. 지원자에게서 들은 멋진 정보를 확인하기 위해서, 그리고 가능한 위험 경고에 대

해서 의논하기 위해서 추천 기회를 이용하세요.

고용 조건을 제시하세요. 적당한 고용 조건(봉급, 혜택, 보너스, 휴가, 회사에서 정한 사항을 포

함해서)을 만들기 위해서 인사 부서와 협의하세요. 지원자가 몇 주 동안 선택 사항에 대

해서 고민하면서 여러분을 기다리게 하지 않도록 만료일을 정해서 고용 조건을 제시

하세요.

◇◇◇

��

Week Two둘째 주

새로운 팀원 융화시키기

변화에 대한 계획을 세워서 새로운 사람을 융화 시키거나 동일한 사람을 새로운

역할에 빨리 적응 시킬 수 있습니다. 다음과 같은 기본 원칙에서 시작하세요. 즉 앉을

자리, 전화, 이메일 권한이 없다면, 신입 사원은 조직에서 눈에 띄지 않습니다.

신입 사원을 위한 체크리스트를 만들어서 사용하세요. 총무 부서에 신청한

것을 검증하기 위해서 203쪽에 있는 체크리스트를 사용하세요. 신입사원이 첫 출근

하는 날까지 모든 것을 갖추세요.

첫 출근하는 날 부서의 정황을 이해시키는데 시간을 보내세요. 새로운 변

화에 놓여 있는 신입 사원과 다음과 같은 특정 상황과 사정에 대해서 의논하세요. 즉

제품, 부서 목표 그리고 특히 신입 사원이 자신의 업무를 이러한 목표와 어떻게 맟춰

가야 하는지 말입니다.[2]

동료를 지정해 주세요. 특히 신입 사원의 경우, 식당, 커피, 사무용품, 화장실이

어디에 있는지 알려 줄 동료를 지정해 주세요.[10] 아울러 이 동료에게 업무의 기술적

인 부분도 신입 사원과 쭉 훑어보게 하세요.

팀웍을 다시금 다져야 한다는 걸 잊지 마세요. 언제든지 팀의 일원이 바뀌면,

새로운 팀을 갖게 됩니다. 간단하게라도 팀이 형성되는 초기 단계로 다시 돌아갈 필

요가 있을지도 모릅니다. 팀에 시간을 주고 다시 생산성을 높이도록 지원하세요.

◇◇◇

��

혼돈에 질서 부여하기

금요일 아침, 샘의 둘째 주 업무 F r i d a y

금요일 아침, 관리 팀은 회의실 A에 다시 모였다. 샘은 지난 주에 만든 플립 차트를

벽에 붙였다.

“난감한 문제에 대해 플립 차트를 작성해서 기뻐요.” 제이슨이 감탄했다. “처리할

일이 많네요.”

“시작하기 전에, 가장 중요한 업무가 무엇인지 확실히 합의하죠.” 샘이 말했다.

샘은 기능과 수정 사항에 우선 순위를 부여하기 위해서 토론을 이끌었다. 현재 우

선 순위가 높은 수정 사항과 기능에 대해서, 관리 팀은 비즈니스 가치, 비즈니스 효과,

위험, 구현 비용을 의논했다. “당장은 이것으로도 충분합니다. 다음 시간에는 마케팅

내용을 포함하고, 우선 순위가 낮은 수정 사항도 살펴 보겠습니다. 며칠 안에 마케팅

부서장을 만나서 이 점에 대해서 어떻게 협업할 것인지 의논해 보죠.”

진저는 두 손으로 얼굴을 가렸다. “이런, 좋아 죽겠네.” 진저는 신음했다.

관리 팀은 만족할 때까지 포스트잇을 정리하고 또 다시 정리하는데 남은 45분을

보냈다. 그리고 그들은 기능마다 사람들이 착수할 수 있는 가능한 가장 빠른 날짜가

언제인지 알게 돼서 흡족했다.

“휴, 이제야 인력 배치를 검토할 수 있네요.” 샘이 말했다 “가장 중요한 프로젝트에

최고의 사람을 배치했습니다. 맞나요? 이런 배치에서 특별히 새로운 기술을 배울 수

있는 잠재 능력을 가진 사람도 포함했습니다.”

모든 사람이 끄덕였다.

“어디서 일손이 부족하죠?” 샘이 물었다.

�0

Week Two둘째 주

크고 눈에 띄는 차트로 작업하기

어떤 프로젝트에서 다음과 같은 시나리오를 볼지도 모른다. 오전 10시, 열

(Column) 안에 정렬된 카드로 덮인 커다란 벽에 붙은 차트에 한 개발자가

성큼성큼 걸어 간다. 개발자는 카드 두 개를 진행 열에서 완료 열로 옮긴다.

그러고 나서 개발자는 대기 열에 있는 카드를 살펴 보다, 카드 하나에 자신

의 이름을 적고 이 카드를 진행 열로 옮긴다. 하루 동안, 개발자와 테스터는

이 과정을 반복한다.

오후 3시쯤, 테스터가 작업 보드로 걸어와서 진행 열에 있는 작업 카드 하

나에 빨간색 점을 찍는다. 오후 4시, 팀은 작업 보드 주위로 모인다. 문제가

있는 작업을 나타내는 빨간색 점을 확인하면서, 자료를 모으고 그 문제를 분

석하기 시작한다. 개발자 두 명이 문제를 해결하기 위해서 협동한다.

이 팀에 있는 사람들은 자신이 무엇을 해야 하는지 알고 있으며, 그 일을 한

다. 사람들은 일일 작업 지침이 필요 없으며 원하지도 않는다. 팀의 관리자

는 장애물을 제거하고, 코칭하며, 팀의 능력을 향상 시키는데 초점을 둔다.

이것은 마술이 아니다. 관리자가 사람들이 계획, 진행, 완료의 작업 상태를

보도록 도와 주는 기술을 사용할 때 사람들은 무슨 일을 할지 알며, 그 일을

한다. 크고 눈에 띄는 차트(Big Visible Charts, BVCs)는 모든 사람이 목

적에 맞게 일하는지 보게 한다.

우리가 아는 한 관리자는 프로젝트 포트폴리오를 눈에 띄게 하기 위해서 화

이트보드에 손으로 그린 도표를 사용했다. 제일 왼쪽의 열은 프로젝트 목록

이고, 남아 있는 각 열은 한 주(Week)를 나타냈다. 팀에 있는 모든 사람마

다, 자석 일곱 개를 나눠줬는데, 이 자석은 다음 7주 동안 사람마다 어떤 프

로젝트에서 작업할지 보여 주었다.

한번은 관리자의 상관이 관리자의 팀이 더 많은 일을 하길 원했다. 관리자는

상관을 화이트보드로 데리고 가서, 물어 보았다. “제가 무엇을 하길 원하시

�1

혼돈에 질서 부여하기

죠? 어떤 작업에서라도 사람을 줄여서, 원하시는 업무에 사람을 늘릴 수 있

습니다.” 데이터가 상관의 눈 앞에 있었기 때문에, 상위 관리자는 단순히

작업을 추가하는 것이 아니라 타협안을 도출해야 한다는 사실을 알 수 있었

다. 단지 작업을 추가하지 않고 말이다.

BVCs는 단지 프로젝트 업무와 프로젝트 데이터를 위한 것이 아니다. 우리

는 BVCs를 부서 동향, 결함 추세, 결함 밀도. 즉 팀 구성원 모두가 알아야

하는 모든 정보를 한눈에 볼 수 있도록 해준다. 단정해야 한다거나 컴퓨터

로 차트를 작성해야 한다거나 하는 고민을 하지 말자. 가시성이 목적이지,

멋 부린 표현이 목적은 아니다.

“실제로, 이런 식으로 프로젝트를 살펴 보니까, 우리는 가장 중요한 업무를 다룰

수 있을 거 같네요.” 진저가 말했다.

샘은 고개를 끄덕였다. “비즈니스 가치를 제공하지 못하는 업무를 제거하면, 전략

적으로 중요한 업무를 어떻게 완수할지 보는 게 쉬워집니다. 우리가 하지는 않지만

반드시 해야 하는 업무는 마티에게 가져 가겠어요.”

“축하합니다! 드디어 프로젝트 포트폴리오의 첫번째 버전을 완성했습니다. 다음

몇 주 동안 프로젝트 포트폴리오가 우리를 안내해 줄 겁니다.” 샘이 말했다.

�2

Week Two둘째 주

◇◇◇

[그림 2.3] 완성된 프로젝트 포트폴리오

�3

혼돈에 질서 부여하기

프로젝트 포트폴리오 관리하기

여러분의 팀이 무엇을 해야 할지 정했다면, 사람들이 어떻게 그 업무를 완수할지

보여주는 계획을 세우세요.

상위 관리자는 조직의 전략 목표를 정합니다. 하위 관리 층마다 이러한 전략 목표

를 받아서 훨씬 전술적인 목표와 실행으로 정제합니다. 계층 구조 속에서 각 단계는

상위 단계의 목표를 지원합니다.

관리자로서 여러분의 업무는 팀의 업무를 부서의 업무 목표와 일치 시키며 부서의

업무가 상위 관리자의 목표를 지원하도록 보장하는 것입니다.

업무에 우선 순위를 부여하세요. 전략적으로 가장 중요한 업무에 우선해서 인

력을 배치합니다. 전략적인 업무는 여러분을 발등에 떨어진 불을 끄는 업무에서 벗

어나게 하거나, 목표와 직접적으로 묶인 일입니다. 모든 사람들에게 우선 순위가 어

떤지, 어떤 일이 우선적으로 완수되길 여러분이 바라는지 확실하게 알려 주세요.

가장 중요한 업무에 인력을 배치하세요. 가장 중요한 업무가 적절하게 처리된

후에 덜 중요한 프로젝트에 인력을 배치합니다. 취소된 프로젝트나 하지 말아야 하

는 업무에 인력을 배치하지 마세요. 부적절한 인력 배치로도 프로젝트가 느리게나

마 진행되겠거니 생각하지 마세요. 부적절한 인력의 프로젝트는 전체 조직을 방해

합니다.

적절한 속도로 업무가 진행될 수 있도록 프로젝트를 취소하거나, 연기하거나, 배

치하세요. 프로젝트가 진짜 중요하지만 현재 인력이 없다면 더 많은 인력 배치를 위

하여 로비 하세요.

사람은 한 번에 한 프로젝트에 배치하세요. 동시에 사람 한 명을 여러 개의 프

로젝트에 배치하고픈 충동을 버리세요. 멀티테스킹은 더 많은 일을 끝낼 수 있는 것

�4

Week Two둘째 주

처럼 보이지만, 실제로는 업무를 느리게 합니다.[11][4] 사람들은 기계가 아니기 때문

에 멀티테스킹을 하지 못합니다.

컴퓨터는 상태를 바꾸고, 모든 것의 완벽한 복사본을 메모리에 유지할 수 있습니

다. 하지만 사람은 단기 기억력이 아무리 좋아도, 정신 작용의 완벽한 복사본을 저장

해 두었다가 가져 오는데 능숙하지 않습니다. 그렇게 할 수 있다 해도 사람들은 똑같

은 상태로 되돌리는데 능숙하지 않습니다.

사람이 멀티테스팅에 능숙하지 못하다는 데이터를 믿지 못하는 상관이 있을지도

모릅니다. 여러분의 상관은 여러분에게 야근을 하고, 그런 데이터는 집어 치우고 멀

티테스킹을 하라고 명령할지도 모릅니다. 이 명령에 굴복하지 마세요. 멀티테스킹을

하려는 시도는 모두 실패할 겁니다.

재계획을 계획하세요. 우선 순위가 바뀌었을 때, 이러한 변화를 반영하기 위해

서 계획을 갱신하세요. 4주나 6주마다 계획을 점검합니다. 완료된 업무를 삭제하고,

새로운 정보를 추가하며 다음 몇 주 동안 상세 내용을 덧붙입니다. 또한 우선 순위를

다시 확인하고, 적절하게 조정하세요.

우선 순위가 바뀌었을 때, 인력 배치도 바뀝니다. 사람들의 배치가 자주 바뀔수록,

개인이 완료하는 업무는 줄어듭니다. 우선 순위가 너무나 자주 바뀌어서 아무것도

완료되지 않는다면, 회사에 큰 문제가 있는 것입니다.

연습 하기

여러분 팀의 목표를 명확히 하세요. 스스로 팀의 목표를 명확하게 말할 수

있는지 알아 보세요. 명확하게 말할 수 있다면, 상관이 동의하는지 알아 보

세요. 여러분과 상관이 주요 목표에 대해서 동의한다면, 사람들이 팀의 목

�5

혼돈에 질서 부여하기

표를 무엇이라고 알고 있는지 사람들에게 물어 보세요. 여러분의 팀이 회

사에 어떻게 가치를 제공할지, 사람들이 가장 중요한 산출물은 무엇이라고

생각하는지, 토론을 시작할 때 이렇게 얻은 정보를 사용하세요. 서로 책임

져야 하는 팀의 목표를 모든 사람이 명확하게 이해하게 하세요. 상세한 내

용은 204쪽의 ‘스마트한 목표 세우기'에서 살펴 보세요.

프로젝트 포트폴리오의 첫번째 초안을 만드세요. 회의실의 한쪽 벽을 치우

고, 지난 주에 만든 작업 목록을 사용해서, 매주마다 업무를 요약하세요. 막

히는 곳이 있다면, 226쪽의 ‘프로젝트 포트폴리오 계획을 위한 팁'을 검토

해 보세요.

다음 번 일대일 회의에서, 사람들이 다루고 싶은 기술은 무엇인지 물어 보

세요. 사람들이 사용하고픈 능력은 무엇인지, 사람들이 같은 직무에서 능

력을 계속해서 계발하길 원하는지 물어 보세요. 다른 업무를 수행하길 원

하는 사람들에게 열린 자세를 보이세요. 팀 안에서 이러한 위치 이동을 지

원할 방법을 살펴 보세요. 이 사람이 여러분의 팀에서 다른 곳으로 이동하

길 바란다면, 적당한 후임자를 고용할 수 있도록 그 사람의 업무를 분석하

세요.

참고 도서

[1] Lou Adler. Hire with Your Head: Using Power Hiring to Build Great Companies. John

Wiley & Sons, Hoboken, NJ, 2002.

[2] Michael Bolton. “Are You Ready?” STQE, pages 50-54, May 2003.

��

Week Two둘째 주

[3] Marcus Buckingham and Curt Coffman. First, Break All the Rules: What the World’s

Greatest Managers Do Differently. Simon and Schuster, New York, NY, 1999.

[4] Tom DeMarco. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

Broadway Books, New York, 2001.

[5] 톰 디마르코(Tom DeMarco), 티모스 리스터(Timothy Lister), "피플웨어 : 정말로 일

하고 싶은 직장 만들기", 매일경제신문사, 2003년

[6] Esther Derby. “Hiring for a Collaborative Team.” Computerworld.com, April 2004. http://

www.computerworld.com.

[7] Esther Derby. “Setting Clear Priorities.” Computerworld.com, January 2004.

[8] Tom Janz, Lowell Hellerik, and David C. Gilmore. Behavior Description Interviewing.

Prentice-Hall, Englewood Cliffs, NJ, 1986.

[9] Johanna Rothman. “Project Portfolio Management 101.” Business-IT Alignment E-Mail

Advisor, October 2001.

[10] Johanna Rothman. Hiring the Best Knowledge Workers, Techies, and Nerds: The Secrets

and Science of Hiring Technical People. Dorset House, New York, 2004.

[11] Gerald M. Weinberg. Quality Software Management: Volume 1, Systems Thinking. Dorset

House Publishing, Inc., New York, 1992.