Manage it 최신 기법으로 배우는

실용주의 프로젝트 관리

iv

•목 차•

01장 프로젝트 시작하기 11.1 프로젝트, 프로젝트 관리자란 무엇인가 .....................................1

1.2 견인인자, 제한인자, 변동인자 관리하기 ....................................4

1.3 고객이나 후원자와 함께 프로젝트 제한인자에 대해

이야기하기 .....................................................................................8

1.4 프로젝트에 있는 견인인자 결정하기 ..........................................9

1.5 프로젝트에서 원하는 게 많은 후원자 관리하기 ......................11

1.6 프로젝트 헌장을 작성해서 의사결정 내용 공유하기 ...............14

1.7 프로젝트에서 품질이 뜻하는 바를 파악하라 ...........................18

02장 프로젝트 계획하기 212.1 시작하기 .......................................................................................21

2.2 시작하기에 적당한 정도로만 계획하기 ....................................22

2.3 프로젝트 계획 양식 만들기 ........................................................24

2.4 출시 기준 정의하기 .....................................................................31

1. 프로젝트에서 무엇이 중요한지 정의하기 ............................32

2. 출시 기준의 초안 잡기 ............................................................33

3. SMART한 출시 기준 작성하기 ..............................................36

4. 출시 기준에 대한 관련자들의 승인 얻어내기 ......................36

2.5 출시 기준 사용하기 .....................................................................37

v

03장 생애주기를 사용해서 프로젝트 설계하기 413.1 프로젝트 생애주기 이해하기 .....................................................41

3.2 생애주기 개요 ..............................................................................43

3.3 프로젝트에서 피드백 받아보기 .................................................48

3.4 대규모 프로젝트에서는 다양한 방식으로

생애주기를 조합할 수 있다. .......................................................49

3.5 아키텍처 위험 관리하기 .............................................................52

3.6 폭포수 생애주기를 유용하게 하는 방법 ...................................54

3.7 내가 가장 좋아하는 생애주기 ....................................................55

04장 프로젝트 일정잡기 574.1 프로젝트 일정을 수립하는 실용적인 접근방법 .......................57

4.2 일정잡기 방법 선택하기 .............................................................60

4.3 사무용품을 활용해서 일정잡기 시작하기 ................................63

05장 작업량 예측하기 735.1 프로젝트를 예측하는 실용적인 접근방법 ................................73

5.2 마일스톤은 프로젝트 범위를 정의한다 ....................................86

5.3 얼마나 적게 일할 수 있을까? .....................................................88

5.4 멀티태스킹 상황에서 예측하기 .................................................89

5.5 고의적으로 멀티태스킹을 하도록 일정 수립하기 ........................90

5.6 ‘연동 계획하기’ 사용하기 ...........................................................91

5.7 반복주기 기간을 정하기 .............................................................93

5.8 가능하다면 인치페블을 사용해서 예측하기 ............................94

vi

06장 일정 게임을 파악하고 막아내기 996.1 일정을 다시 작성하게! ................................................................99

6.2 희망만이 살길이다! .................................................................. 102

6.3 현실부정의 관리자 ................................................................... 105

6.4 눈 가리고 아웅 ......................................................................... 107

6.5 운 좋은 완료일 .......................................................................... 109

6.6 불붙은 엉덩이 ........................................................................... 112

6.7 쪼개진 과녁 ............................................................................... 114

6.8 일정은 판결문이다 ................................................................... 117

6.9 거기로 갈까? 아니면 저기? ...................................................... 119

6.10 일정 관리도구는 항상 옳다. 혹은 꿈 같은 일정 .................... 121

6.11 구현하거나 죽거나 ................................................................... 123

6.12 ‘아니요’는 죽어도 안되죠. ....................................................... 126

6.13 치킨 게임 ................................................................................... 128

6.14 90퍼센트 완료 .......................................................................... 129

6.15 내일은 더 괜찮아질 거야 ......................................................... 131

6.16 일정에 최면이 걸리다 .............................................................. 133

07장 탁월한 팀 만들기 1357.1 팀원 고용하기 ........................................................................... 135

7.2 팀원들이 단합하도록 돕기 ...................................................... 137

7.3 회사 지원 얻어내기 .................................................................. 141

7.4 필요한 팀의 규모를 파악하라 ................................................. 144

7.5 인원을 추가할 시점을 파악하라 ............................................. 146

7.6 위대한 프로젝트 관리자로 거듭나기 ..................................... 147

7.7 떠나야 할 때를 알아라 ............................................................. 151

vii

08장 프로젝트 조정하기 1598.1 프로젝트 리듬을 사용해서 프로젝트를 조정하라................. 159

8.2 임시 회고 사용하기 .................................................................. 161

8.3 요구사항에 우선순위 부여하기 .............................................. 162

8.4 요구사항 작업에 타임박스를 적용하라 ................................. 166

8.5 반복주기에 4주나 4주 이하의 타임박스 적용하기 ............................169

8.6 연동 계획하기와 연동 일정잡기 사용하기 ............................ 171

8.7 교차 기능 프로젝트 팀 만들기 ................................................ 174

8.8 프로젝트의 위험을 근거로 생애 주기를 선택하라................ 176

8.9 적당한 근무시간을 지켜라 ...................................................... 177

8.10 인치페블을 사용하라 ............................................................... 179

8.11 작업 훼방 관리하기 .................................................................. 180

8.12 프로젝트 초기에 발생하는 결함 관리하기 ............................ 182

09장 프로젝트 리듬 유지하기 1899.1 프로젝트에 지속적인 통합 적용/변형하기 ............................ 189

9.2 빌드 작업에 자동화된 스모크 테스트 만들기 ....................... 191

9.3 아키텍처 수준이 아니라 기능 단위로 구현하라 ................... 193

9.4 제품을 철저히 검토하자 .......................................................... 198

9.5 리팩터링을 계획하라 ............................................................... 200

9.6 유스 케이스, 사용자 스토리, 페르소나, 시나리오를 활용해서

요구사항을 정의하라 ............................................................... 202

9.7 요구사항에서 GUI 설계를 분리하라 ..................................... 203

9.8 가능한 오랫동안 엉성한 프로토타이핑을 사용하라 ............. 204

viii

10장 회의 관리하기 20710.1 이런 회의라면 취소하라 .......................................................... 208

10.2 이런 회의를 실행하라 .............................................................. 211

10.3 프로젝트 킥오프 회의 .............................................................. 211

10.4 출시 계획하기 회의 .................................................................. 212

10.5 진행 상황 보고 회의 ................................................................. 212

10.6 경영층에게 진행 상황 보고하기 ............................................. 218

10.7 프로젝트 팀 회의 ...................................................................... 219

10.8 반복주기 검토 회의 .................................................................. 220

10.9 회의에서 문제점 해결하기 ...................................................... 221

10.10 전화회의 관리하기 ................................................................... 223

11장 프로젝트 대시보드를 만들고 사용하기 22911.1 측정은 위험할 수 있다 ............................................................. 230

11.2 프로젝트 완료를 향한 진척도 측정하기 ................................ 232

11.3 후원자를 위한 프로젝트 대시보드 꾸미기 ............................ 256

11.4 프로젝트 날씨 보고서를 사용하라 ......................................... 258

12장 멀티사이트 프로젝트 관리하기 26512.1 질문을 하면 손실이 발생한다고요?........................................ 266

12.2 프로젝트에 존재하는 문화적 차이를 찾아내라 ................... 267

12.3 팀 사이에서 신뢰 구축하기 ..................................................... 268

12.4 팀 단위로 서로 보완하는 실천방법을 사용하세요. ...........................272

12.5 잠재적인 다문화 문제를 찾아라 ............................................. 281

12.6 아웃소싱할 때 피해야 할 실수 ................................................ 283

ix

13장 프로젝트에 테스트 통합하기 28713.1 팀원들이 기술 빚을 줄이려는 마음으로 시작하게 하라 ....... 287

13.2 간단한 테스트를 사용해서 위험을 줄여라 ............................ 288

13.3 TDD는 프로젝트에 테스트를 도입하는 가장 쉬운 방법이다 290

13.4 다양한 종류의 테스트 기술을 사용하라 ................................ 293

13.5 팀원마다 테스트 역할을 정의하자 ......................................... 296

13.6 적당한 개발자와 테스트 비율은? ........................................... 301

13.7 개발과 테스트를 동시에 진행하라 ......................................... 307

13.8 프로젝트에 적합한 테스트 전략을 정의하라 ........................ 307

13.9 시스템 테스트 전략 템플릿 ..................................................... 307

13.10 QA와 테스트의 차이 ................................................................ 310

14장 프로그램 관리하기 31314.1 프로젝트가 프로그램일 때 ..................................................... 313

14.2 서로 관련된 여러 프로젝트를 하나의 출시로 구성하기 ....... 315

14.3 프로그램을 진행하면서 관련된 프로젝트들 정리하기 ......... 317

14.4 프로젝트 관리자 관리하기 ...................................................... 321

14.5 프로그램 대시보드 만들기 ...................................................... 323

15장 프로젝트 완료하기 32715.1 출시를 앞당겨 달라는 요청을 관리하라 ................................ 327

15.2 베타 출시 관리하기 .................................................................. 328

15.3 출시일을 준수하지 못한다는 것을 알았을 때 ....................... 330

15.4 프로젝트 완료하기 ................................................................... 338

15.5 프로젝트 취소하기 ................................................................... 344

x

16장 프로젝트 포트폴리오 관리하기 34716.1 전체 프로젝트를 담은 포트폴리오를 만들어라 .................... 348

16.2 프로젝트를 평가하라 ............................................................... 349

16.3 당장에 자금을 지원할 프로젝트를 결정하라 ........................ 350

16.4 포트폴리오에 순서를 매겨라 .................................................. 351

16.5 프로젝트 더 일찍 시작하라 ..................................................... 352

16.6 제품 백로그를 사용해서 새로운 기능에 대한

요구를 관리하라 ....................................................................... 354

16.7 포트폴리오 관리 문제점 해결하기 ......................................... 357

부록 A 연속적인 생애주기: 폭포수 방법 또는 단계-게이트 방법 365A.1 연속적인 생애주기: 폭포수 방법 또는 단계-게이트 방법 .... 365

A.2 반복적인 생애주기: 나선형, 점진적인 프로토타이핑,

유니파이드 프로세스 ............................................................... 370

A.3 점진적인 생애주기: 단계별 인도, 디자인-스케줄 ..................... 373

A.4 애자일 생애주기 ....................................................................... 374

부록 B 용어 정리 379

부록 C 참고 자료 383

xi

제가 아는 한 관리자로서 처음으로 타임박스와 증분을 사용한,

일세 로스먼에게 고마움을 전합니다.

그리고 제가 몰입해서 글을 쓸 때마다 도움을 준,

나오미, 샤이나, 마크에게도 감사의 말을 전합니다.

xii

역 자 서 문

프로젝트 관리란 무엇일까요?

이 질문에 대한 제 대답은, 프로젝트 관리자(Project Manager, PM)로서 프로젝트를

하나씩 끝낼 때마다 조금씩 바뀌는 듯합니다. 제일 처음 프로젝트를 맡았을 때는 프로젝

트를 끝내는 데 초점을 맞췄죠. 따라서 프로젝트 내에서 개발할 기능을 개발하는 게 중요

했으므로 ‘기능 개발관리’=’프로젝트 관리’라고 생각했습니다.

시간이 흘러 회사에서 PMBOK 1 * 형태의 프로젝트 관리 체계를 강조했을 때는 정해진

절차에 따라서 계획을 세우고 관리하는 게 매우 중요해졌습니다. 따라서 기능 개발보다

프로젝트 계획을 준수하려고 노력했습니다.

프로젝트라는 게 변화무쌍한 유기체 비슷해서, 장기 계획의 정확성이 낮다는 것을 깨

달았을 때는 변화를 관리하는 게 중요해서 애자일 실천방법을 프로젝트에 적용하는 것

에 중점을 두었죠.

그리고 최근에 드는 생각은, 특히 SI 프로젝트라면, 다양한 이해당사자(stakeholder)들

의 힘 벡터가 평형을 이루는 지점에 시스템이 완성된다는 것입니다. 즉 프로젝트의 자금

을 대는 스폰서의 벡터가 크다면 시스템은 최종 사용자 쓰기 어려운 거만한 소프트웨어

가 되거나, 프로젝트 팀원들의 벡터가 지나치게 크다면 그들만의 잔치로 끝나는 경우가

있죠.

결국 이해당사자들의 요구사항을 잘 파악하는 것에 덧붙여서 프로젝트의 주변환경을

정확하게 파악하는 것이 프로젝트 성공에 핵심이죠. 즉 프로젝트를 성공으로 이끌려면

흔히들 말하는 프로젝트의 맥락(context)를 파악하는 작업이 무척 중요하다는 게 요즘

드는 생각입니다.

1 　 PMBOK(Project Management Body Of Knowledge): 프로젝트 관리에 필요한 지식을 체계적으로 정리한 것

xiii

이 책은 다른 프로젝트 관리 서적에서 소홀히 다루었던 프로젝트의 맥락을 파악하는

데서 프로젝트를 시작하라고 충고하죠. 그리고 프로젝트의 맥락을 충분하게 살피고, 프

로젝트를 성공으로 이끄는 관리방법을 선택해서 적용하는 방법을 알려줍니다.

아울러, 정형화된 프로젝트 관리방법을 적용하면서 염증을 느끼신 분들이나, 애자일

실천방법을 알지만 현실에 적용하면서 적당한 지침이 없어서 곤란했던 분들에게, 실용적

인 프로젝트 관리 지침으로서 이 책이 유용할 것입니다.

아무쪼록 이 책에 있는 지식들이 함정과 암초가 똬리를 트고 있는 험난한 프로젝트 던

전에서 독자 여러분들을 가슴뭉클한 엔딩으로 안내해주길 바라겠습니다. 감사합니다.

- 신승환

xiv

추 천 의 글

안녕하세요! 요한나의 최신 책을 읽게 된 걸 축하 드립니다. 저는 현재 (버클리) 야후에서

일하고 있습니다. 그리고 수십 년간 소프트웨어 비즈니스에 종사했죠. 아마도 여러분은

Digital Equipment Corporation(초기 인터넷의 기반을 닦음)과 이 회사에서 만든 알파

시스템(Alpha system)이란 걸 들어 보셨을 겁니다. 알파 시스템은 제게 정말로 중요한 프로

젝트였죠.

저는 알파 소프트웨어를 만드는 데 중요한 역할을 맡았습니다. 이 일은 엄청난 작업이

었죠. 전 세계 곳곳에 있는 엔지니어 2,000명이 시스템의 다양한 부분을 나누어서 작업

했죠. 철저한 계획과 프로젝트 관리가 필요했고, 프로젝트 일정은 4년이었으며 목표로 삼

았던 출시일보다 1달 정도만 지연됐죠. 여러분은 어떠실지 모르지만 이 정도라면 전 제 자

신이 꽤 괜찮은 관리자라고 생각했습니다. 하지만 전 훌륭한 관리자란 어떤 사람이라는

것 정도만 파악한 것이었습니다.

1996년 5월, 전 DEC를 떠나기로 결심했습니다. 그리고 보스턴에 있는 제법 규모가 큰

소프트웨어 회사에 자리가 있다는 것을 들었죠. 그 자리는 제가 즐기는 모험과 비슷했는

데요, ‘혼돈 속에 빠진 팀’을 구해내는 관리자 자리였습니다. 제 생각에 정말 멋졌습니다!

그리고 그런 일이 제가 하는 업무였죠. 즉 혼돈에서 잠재력을 이끌어내서, 정말로 동작하

는 제품을 만들도록 도와주는 일 말이죠. 이 부서는 어떻게 됐을까요?

저는 베타 출시 개발에 우선순위를 부여하는 작업을 하려고 컨설턴트가 고용되었다는

소식을 들었습니다. 이 소식 때문에 저는 그들이 애타게 기다렸던 영웅(바로 접니다)을 곧

찾게 될 것이라고 확신했습니다.

하지만 제 기대와 달리, 저는 곧 겸손해졌고 깊은 인상을 받았습니다(그리고 시간이 흐

를수록 더욱 겸손해져야 했죠). 저는 컨설턴트들이 해야 하는 작업을 잘 알고 있었지만,

컨설턴트들이 정말로 상황을 명확하게 하고 실천할 수 있는 방법을 만드는 경우가 있나

xv

요? 하지만 그 회사에 고용된 컨설턴트는 그런 식으로 일을 했죠. 그리고 몇 달 후, 그녀는

모든 것이 제자리를 찾도록 관리했습니다. 즉 프로젝트 헌장, 프로그램 계획, 프로젝트 계

획 그리고 역할과 책임 정의, 개발 프로세스 정의, 적절한 평가지표, 출시 기준, 베타 고객

그리고 프로젝트 성공에 필수적인 것들을 모두 관리했습니다.

하지만 대개 이렇게 제자리를 찾게 하려면 시간이 많이 들죠. 특히 불리한 처지에서 일

을 시작한 경우엔 그렇습니다. 여러분은 지금쯤이면 이 컨설턴트가 요한나 로스먼이라는

것을 아셨을 겁니다(요한나가 그녀의 웹사이트에 프로젝트 경험담을 올려 두었습니다. 문

제 소지를 없애려고 단지 이름만 바꿨습니다)

제가 요한나를 처음 만나고 나서 몇 년 동안, 저는 크고 작은 회사에서 소프트웨어 개

발 조직을 운영했죠. 그리고 여러 번 제가 맡은 팀을 한 단계 도약시키기 위해서 요한나의

도움을 받았습니다. 그녀의 평가 프로세스는 철저하고 효과적인 프로젝트 관리에 꼭 필

요한 명확한 근거를 제공합니다. 그녀는 저를 위해서 다양한 주제를 다루는 워크숍을 효

과적으로 운영하고, 반복적인 프로젝트 요구사항, 프로젝트 관리, QA를 실시하죠. 요한

나를 임시 프로젝트 관리직으로 고용한 적도 있고 능력이 다양한 사람들에게 일대일 코

칭을 하기 위해서 고용한 적도 있습니다. 요한나는 여러 직위와 회사에서 얻은 다양한 경

험을 잘 살리고, 항상 실용적이고 실질적인 해결책을 제공합니다(이런 해결책은 중요한

문제를 해결하기 위해서 실제로 실행할 수 있습니다).

그리고 이 책은 요한나가 선사하는 선물입니다.

요한나는 현장에서 일한 수년간의 경험에서 지식을 엄선해서 읽기 쉽도록 정리했습니

다. 이 책은 여러분이 놓인 상황을 분석하고, 프레임워크와 합리적인 계획을 세우며, 실

행하는 데 꼭 필요한 도구를 제공합니다. 요한나는 다양한 팁, 어떤 경우에 되고 어떤 경

우에 잘 되지 않는지 보여주는 예제와 위험 요소를 어떻게 회피하는지에 대한 조언을 해

xvi

주죠. 저는 수년간 프로젝트 관리와 프로그램 관리를 했지만, 이 책을 검토하면서 새로운

것들을 배웠습니다. 그리고 제가 새로운 자리와 어려움에 처했을 때 아니면 골치 아픈 문

제를 명확하게 보도록 제 이야기를 들어줄 사람이 필요할 때면, 저는 요한나에게 전화를

걸 겁니다.

그리고 제가 요한나를 처음 만났던 프로젝트는 어떻게 됐을까요? 우리는 베타 고객에

제품을 출시했고, 이 제품은 성공적으로 작동했죠.

요한나의 책은 여러분이 성공하는 데 도움을 줄 것입니다.

- 엘렌 샐리스베리(관리자, 야후! 리서치 버클리)

xvii

서 문

수많은 기법, 실천방법, 듣고 싶지 않은 충고들이 프로젝트 관리란 이렇게 저렇게 하라고

여러분을 괴롭힙니다. 그리고 이것들은 이렇게 말하죠. “잘 들어봐! 내 말이 맞거든!”

물론, 그런 이야기 중에 맞는 것도 있습니다. 즉 조건만 맞는다면 말이죠. 하지만 프로젝

트마다 특징이 다르기 때문에, 여러분이 놓인 맥락(프로젝트, 팀, 회사)을 반드시 평가하

고 나서 어떤 방법이 효과가 있고 어떤 방법이 소용 없는지 실용적인 선택을 해야 합니다.

점점 프로젝트 기간은 단축되고 고객은 참을성이 없어집니다. 따라서 품질이 낮은 제

품을 꾹 참고 쓰지 못하게 되었습니다. 여러분은 프로젝트에서 예전에 사용했던 방법 덕

분에 지금의 자리에 있지만, 미래에도 그럴 것이라는 보장은 없습니다. 다양한 실천방법

과 기술의 장점을 활용해서 프로젝트의 위험을 줄여야 합니다. 여기에는 애자일 기술을

적용하는 것도 포함됩니다.

이 책은 프로젝트를 계획하고 운영할 때 뛰어난 결정을 내리도록 프로젝트 위험을 기

반으로 한 가이드를 제공합니다. 이 책은 소프트웨어 프로젝트 관리자, 팀원, 중간 관리

자들이 성공하도록 도와줄 것입니다. 또한 집이나 전기회로처럼 유형의 제품을 만들 때,

혹은 서비스 프로젝트를 관리하는 경우에도 이 책에서 소개하는 대부분의 지식을 적용

할 수 있습니다.

예상컨대, 여러분은 적어도 소프트웨어 컴포넌트가 관련되는 하이테크 프로젝트를 관

리할 겁니다. 제가 경험했던 것과 비슷한 프로젝트를 여러분들도 한 번씩 경험했을 겁니

다. 즉 대부분은 소프트웨어 개발 프로젝트고, 일부는 하드웨어와 소프트웨어가 통합되

는 프로젝트죠. 저는 서비스 프로젝트(컨퍼런스 기획/주관)를 관리했고, 심지어는 건축

프로젝트(신축, 소규모 리모델링, 대규모 리모델링)의 일부를 맡았던 적도 있습니다. 하지

만 제가 관리했던 프로젝트는 대부분 소프트웨어나 하드웨어/소프트웨어와 관련된 작업

이었습니다.

xviii

확실히 손으로 만질 수 있는 제품을 만드는 프로젝트보다 소프트웨어를 만드는 프로

젝트가 관리하기 어렵습니다. 소프트웨어는 구체적이지도 않고, 물질도 아니고, 원재료

를 사용해서 만들지 않는, 즉 추상적인 것이죠. 따라서 우리들은 소프트웨어를 손으로 만

질 수도, 직접 측정할 수도, 심지어 볼 수도 없습니다. 제품이 만들어지는 과정을 볼 수 없

기 때문에 위험을 예측하고 평가하기 어렵습니다. 따라서 위험을 관리하기가 더욱 어려워

집니다. 소프트웨어 제품을 만들려고 우리가 사용하는 실천방법들은 프로젝트가 제대로

진행하고 있는지 파악하도록 항상 도와주지 못하죠.

손으로 만질 수 있는 제품을 만드는 프로젝트를 관리한다면, 여러분은 제품이 형태를

갖춰가는 과정을 볼 수 있습니다. 빌딩 외형이 만들어지고, 벽의 마감 공사가 끝나고, 사

이사이에 계단이 세워지는 것을 지켜볼 수 있습니다. 손에 만질 수 있는 결과를 내놓는 서

비스 프로젝트의 경우, 예를 들어 컨퍼런스나 회의 주관 프로젝트인 경우라면 보고서 초

안이나 회의록 같은 중간 산출물이 있을 때 프로젝트에 대한 통찰력을 얻을 수 있습니다.

손으로 만질 수 있는 제품을 만드는 프로젝트나 서비스를 제공하는 프로젝트는 모두 종

료하기 전에 진행상황을 살펴볼 수 있습니다.

자, 그렇다면 프로젝트 진행상황을 직접 살펴볼 수 없다면 어떻게 하시겠습니까? 프로

젝트가 어처구니 없이 돌아간다는 의심이 들고, 프로젝트가 파국을 향해서 나아가고 있

다는 생각이 든다면, 어떻게 하시겠습니까? 여러분이 프로젝트를 성공적으로 끝내도록

결정을 내리지 않는 이해당사자를 어떻게 다루시겠습니까?

이 책은 소프트웨어 프로젝트란 무엇이며, 프로젝트에서 발생하는 위험과, 프로젝트를

시작하면서 동반하는 위험을 관리하는 통찰력을 제공해줍니다. 프로젝트 헌장 작성에서

출시까지, 각 장마다 여러분이 소프트웨어 개발 프로젝트에서 접할 수 있는 방법을 알려

줍니다. 이런 방법들을 평가하고, 느끼고, 음미하고 즐기길 바라겠습니다.

이 책에서는 프로젝트를 관리하는 ‘만병 통치약’ 같은 방법은 알려 드릴 수 없습니다. 모

든 프로젝트에 적용되는 ‘만병 통치약’ 같은 방법은 존재하지 않습니다. 아울러 ‘무작정

따라하기’ 같은 최고의 실천방법(Best practice)도 없습니다. 단지 여러분과 팀이 목표를

달성하게 도와주는 생애주기에 적절한 실천방법들만을 알려드릴 겁니다.

xix

이 책에서 설명한 템플릿은 모두 이 책의 홈페이지에서 제공됩니다

(http://pragmaticprogrammer.com/titles/jrpm).

제가 말씀 드리는 이야기는 모두 사실입니다. 단지 이름, 회사, 상세한 설명만 선의의 피

해를 막으려고 바꿨습니다.

자, 그럼 시작해볼까요?

- 요한나 로스먼

xx

1

01프로젝트 시작하기

프로젝트를 그릇되게 시작하는 가장 쉬운 방법은 무턱대고 시작하는 것입니다. 프로젝

트가 성공하리라는 상식적인 희망이라도 품길 원하시나요? 그렇다면 조금 더 조직적으로

구성하고 계획하는 데 공을 들여야 합니다. 어떤 요소가 프로젝트를 이끌고 프로젝트 내

에서 ‘완료’란 무엇을 뜻하는지 알아내야 합니다. 그러고 나서 이런 의사결정을 프로젝트

헌장(project charter)에 기록해서 팀원들과 공유하세요.

1.1 프로젝트,프로젝트관리자란무엇인가

우선, 프로젝트란 무엇인지 확실히 해두죠.

프로젝트:

새로운 제품이나 서비스를 만들기 위해 완전히 새롭게 시도되는 일 또는 체

계적인 프로세스로서, 완성된 것을 인도하면 끝난다. 프로젝트에는 위험이

반드시 존재하고 한정된 자원 때문에 일반적으로 제한을 받는다. 1

프로젝트 관리자는 위험과 자원을 관리합니다. 프로젝트 전반에 걸쳐서 위험이 존재할

때, 프로젝트 관리를 해야 합니다. 즉 일정은 촉박하고, 기술적인 목표를 달성할지 명확하

1 　 승인을 받고 실음, 저작권 2007년 R. 맥스 와이드먼, http://www.maxwideman.com

2 l Manage it

지 않으며, 품질에 문제가 생길지도 모르고, 경비도 제한적이며, 팀원이 필요할 때 적합한

사람이 없을지도 모릅니다.

프로젝트마다 중요한 게 다르기 때문에 각 프로젝트는 유일하죠. 프로젝트에 있는 고유

한 특성은 프로젝트에 적합한 방식으로 프로젝트를 계획하고 관리해야 한다는 것을 뜻

합니다. 프로젝트를 시작하기 전에 프로젝트에서 무엇을 달성해야 하는지 정보를 모으는

것부터 시작하세요.

우리는 뭘 만들죠?

-프로젝트관리자크리스

저는 대기업에서 근무하는 프로젝트 관리자입니다. 소프트웨어/하드웨어

통합 프로젝트를 관리하죠. 제 동료인 니키는 이벤트를 주관합니다. 제가 관

리하는 팀이 서버를 구축하면 니키의 팀에서 이벤트를 준비하죠. 비록 니키

와 제가 내놓는 산출물이 모든 면에서 다르지만, 우리는 프로젝트 관리자입

니다.

우리가 경험하는 위험은 완전히 다릅니다. 니키와 제가 내놓아야 하는 산출

물도 완전히 다르죠. 저는 소프트웨어, 하드웨어, 그리고 문서가 필요합니다.

니키는 전시용 부스, 다과나 이벤트를 성공적으로 개최하는 데 필요한 것들

이 필요합니다.

프로젝트를 시작할 때 니키와 저는 똑같이 프로젝트의 핵심이 무엇인지 알

아냅니다. 이렇게 해서 우리는 무엇을 만드는지 재빨리 정의하죠. 프로젝트

에서 우리가 무엇을 만드는지 알고, 완료란 무엇을 의미하는지 안다면 프로

젝트 관리가 쉬워집니다.

프로젝트는 모두 독특합니다. 프로젝트마다 규모도 다르고 프로젝트에서 필요한 능력

도 다릅니다. 내부 고객이 있는 프로젝트도 있고, 외부 고객이 있는 프로젝트도 있습니다.

시간이 촉박하게 주어진 작업이 있고, 작업을 완수하는 데 전혀 다른 위험이 있는 작업도

있습니다. 이런 다른 상황에서도 프로젝트에서는 제품을 다룬다는 공통점이 있습니다.

한 번 더 정의를 내리겠습니다.

01 프로젝트 시작하기 l 3

제품:

프로젝트에서 얻는 산출물의 집합

여러분은 성공적인 프로젝트 관리자입니다. 아니라면 그렇게 되고 싶겠죠. 이번 프로젝

트에서 고유한 것이 무엇인지 알아내는 데 시간을 할애하세요. 이런 식으로 프로젝트를

시작하고, 프로젝트를 관리해서 성공적으로 프로젝트를 끝낼 수 있습니다.

프로젝트와 제품의 정의를 내렸으므로, 이번에는 프로젝트 관리란 무엇인지 명확하게

정의하겠습니다. 와이드먼은 프로젝트 관리자를 이렇게 정의했습니다. “프로젝트 관리자

는 팀을 이끌고, 프로젝트 관리 방법을 사용해서 프로젝트를 수행하고 프로젝트 목적을

달성하는 데 필요한 권한과 책임이 있다.” 2 이것은 형식적인 정의로는 훌륭합니다. 조금

애매하지만 더욱 정확하다고 느낄 만한 실질적인 정의는 다음과 같습니다.

프로젝트 관리자:

‘완료’란 무엇인지 명확하게 정의하고, 완료란 무엇인지 의사소통하면서 팀

을 완료로 이끄는 사람. 여기서 말하는 ‘완료’는 회사에서 제품을 개발하는

목적을 달성하고 고객이 제품을 사용하면서 만족하는 것입니다.

완료라는 말 속에는 상당한 위험이 숨어 있습니다. 여러분이 맡은 프로젝트에는 십중

팔구 위험이 존재합니다. 위험을 어떻게 식별하고 분류하는지 살펴볼 것입니다. 이런 작

업들을 시작하기 전에 우선 프로젝트를 이끄는 힘이 무엇인지 이해해야 합니다.

프로젝트는 작든 크든 위험이 존재한다.

-중견프로젝트관리자에릭

큰 프로젝트 몇 개(프로젝트는 여러 해 동안 진행됐고 팀원들은 수백 명이

나 됐죠)와 작은 프로젝트 몇 개를(2-3명의 팀원으로 3달 동안 직원이 2-3명

이 있는 고객과 작업했죠) 관리했습니다. 프로젝트에서 최종 산출물을 얻는

데 항상 위험이 존재한다는 것이 제가 깨달은 사실입니다.

위험은 팀에 따라 달라질 때도 있습니다. 집에서 침대를 만드는 일처럼 간

단한 것을 생각해보죠. 제 경우, 침대 만들기란 체크리스트의 항목 정도에

2 　 승인을 받고 실음, 저작권 2007년 R. 맥스 와이드먼, http://www.maxwideman.com

4 l Manage it

해당하는 쉬운 일입니다. 하지만 제 아이들의 경우, 침대 만들기는 위험이

가득한 프로젝트죠. 아이들이 잠자리에 들기 전에 끝내지 못한다는 게 가

장 큰 위험입니다.

1.2 견인인자,제한인자,변동인자관리하기

프로젝트를 끝내는 데 가장 위험한 일은 프로젝트의 맥락(context)을 제대로 파악하는 것

입니다. 3

프로젝트의 맥락이란 조직 관점에서 무엇이 중요한지를 판단하는 것입니다. 프로젝트

를 이끄는 것은 무엇인가요? 프로젝트에 제한인자(constraint)가 있나요? 여러분은 제한인

자와 견인인자(driver) 사이에서 절충안을 찾거나 여유 자원을 더 확보할 수 있나요?

프로젝트에 따라서 견인인자가 달라진다

-프로젝트관리자스튜어트

전 두 번째 프로젝트를 관리하고 있습니다. 첫 번째 프로젝트에서는 회사의

주력 제품에 있는 버그를 수정한 버전을 출시했습니다. 첫 번째 프로젝트에

서 어렵지 않게 어디에 집중해야 하는지 알아냈습니다. 즉 새로운 기능 몇

개를 추가하고 많은 결함을 수정하는 데 집중했습니다.

이번에 맡은 두 번째 프로젝트는 달라도 정말 다릅니다. 이번 프로젝트에서

는 회사가 신규 시장에 진입할 필요가 있는지 살펴보는 실험과 비슷합니다.

따라서 기능을 많이 추가해야 했습니다. 프로젝트 팀에서는 새로운 기능이

작동하게 해야 했지만, 결함을 수정하는 데 집중하지 못했습니다. 어느새

마감일이 코앞까지 다가왔습니다. 비용 문제가 있었기 때문에 제 상관은 팀

원을 두 명 더 추가할 수 있지만 외부 협력업체를 이용하지 말라고 지시했습

니다.

3 　 (옮긴이) 여기서 말하는 맥락은 이 절에서 이야기하는 견인인자, 변동인자, 제한인자를 파악하는 겁니다. 즉 이런

인자를 잘못 파악하면 프로젝트를 운영하는 방향이 완전히 달라지기 때문에 프로젝트의 맥락을 제대로 파악하는

게 매우 중요하다는 의미입니다. 아울러 이런 맥락을 잘못 파악하면 프로젝트를 망칠 수도 있기 때문에 가장 큰 위

험이라고 얘기하고 있습니다.

01 프로젝트 시작하기 l 5

이런 힘든 상황에서 프로젝트를 이끄는 것이 무엇인지 분석하고 나서 전 한

숨 돌렸습니다. 첫째 우선순위는 기능개발이었습니다. 둘째 우선순위는 마

감일이었으며, 셋째 우선수위는 프로젝트 인원이었습니다. 결함 그리고 출

시 비용에는 여유가 있었죠.

여러분은 프로젝트를 수행하면서 ‘철의 삼각(iron triangle)’이라는 개념을 들어봤을 겁니

다. 삼각형의 세 변 가운데 두 개는 비용과 일정입니다. 일반적으로 세 번째 변은 품질이나

범위죠(그림 1.1 참고). 이 철의 삼각은 지나치게 단순합니다. 스튜어트 씨가 맡았던 프로젝

트를 살펴보더라도, 철의 삼각과 비교했을 때 프로젝트의 견인인자가 매우 달랐습니다.

스튜어트씨와 같은 성공적인 프로젝트 관리자는 철의 삼각 구성 요소보다 더 많은 인

자들을 조절합니다. 여러분은 고객에게 철의 삼각의 변 가운데 두 개만을 선택할 수 있

고, 고객이 그렇게 한다면 고객이 원하는 것을 인도할 수 있다고 말하지 못합니다. 프로젝

트가 모두 이런 식이라면, 누구나 프로젝트 관리자가 될 수 있겠죠.

우선 고객의 기대를 적어보세요. 다시 말하자면, 고객의 관점에서 프로젝트를 이끄

는 것을 적습니다.[Rot98] 여러분이 작성한 목록에는 고객이 원하는 것(기능), 고객이 제

품을 언제 받을지(출시일), 그리고 제품이 얼마나 좋아야 하는지(결함 수준)를 담습니

다.[Gra92]

다음으로, 여러분에게 주어진 제한조건을 적어보세요. 여러분이 처한 현재 상황은 어

떤가요? 여러분에게 팀을 배치할 권한이 있나요? 지켜야 하는 프로세스가 있나요? 여러

비용 품질

일정 일정

비용 자원

그림 1.1 | 전통적인 철의 삼각

6 l Manage it

분과 함께 일할 사람이 있나요? 이 사람들이 어떤 일을 할 수 있죠? 예산은 얼마나 되나

요? 여러분은 이런 제한인자를 바꿀 수 있습니다(프로젝트가 난관에 부딪혔을 때 이런

일은 자주 일어납니다). 제한인자는 여러분이 맡은 프로젝트의 규모(혹은 기간이나 품

질)를 결정합니다.

여러분이 작성한 고객의 기대와 프로젝트 제한조건 목록을 살펴보세요. 여러분이 프로

젝트를 성공적으로 끝내려면 무엇이 필요할까요?

한 항목을 선택하세요. 예를 들어 출시라는 항목을 선택했다고 가정하죠. 여러분은 출

시를 견인인자로서 식별했습니다.

작성한 목록에는 무엇이 남았나요? 기능 집합, 낮은 결함, 출시 비용과 같은 것들이

보일 겁니다. 프로젝트를 성공적으로 끝내려면 남은 항목 가운데 어떤 것을 관리해야

할까요? 견인인자보다 프로젝트 성공에 영향을 덜 미치는 항목들을 사용해서 계층도

(hierarchy)를 작성하세요. 고객이 품는 기대나 후원자가 원하는 결과가 프로젝트를 제한

할 수도 있는데, 남은 항목 가운데 몇 가지와 관련되죠. 즉 고객의 기대와 후원자의 관심

과 관련된 항목 두세 가지를 고르세요. 우리는 방금 고른 것을 프로젝트의 제한인자라고

부를 겁니다.

한 번 더 남은 항목들을 살펴보세요. 프로젝트에서 일부 항목은 중요하지만, 그래도 여

러분은 남은 항목을 관리하면서 융통성을 발휘할 수 있습니다. 이것들을 변동인자(�oat)

라고 부르겠습니다. 이 프로젝트의 경우, 여러분에게 적어도 변동인자 3개가 있겠죠.

마지막으로, 선택하지 않은 항목들로 되돌아가겠습니다. 일부는 선택한 것들보다 더 중

요하지 않나요? 더 중요하다면 덜 중요한 항목을 중요한 항목으로 바꿔도 괜찮습니다. 항

목을 바꿀 필요가 없다면 여러분이 관리하는 프로젝트에서 견인인자, 제한인자, 변동인

자를 식별했습니다.

저는 3개가 넘는 제한인자가 있는 프로젝트가 성공하는 것을 가끔 목격하지만, 프로젝

트 팀원들은 제한인자 이외의 것에 엄청난 노력을 쏟아야 했습니다. 제 경험으로 볼 때 견

인인자 1개, 제한인자 2개, 변동인자 3개가 있을 때 프로젝트를 성공으로 이끌 가능성이

있습니다. 변동인자가 많을수록 프로젝트를 더 쉽게 구성할 수 있습니다.

01 프로젝트 시작하기 l 7

단 하나의 견인인자와 제한인자, 그리고 4개의 변동인자가 있을 때가 이상적입니다. 대

부분은 이상적인 프로젝트가 아니지만, 견인인자가 1개, 제한인자는 2개, 변동인자가 3개

라면 여전히 성공할 수 있습니다. 견인인자와 제한인자가 많아질수록 프로젝트에는 지나

치게 제약이 많아집니다. 이런 경우에도 성공할지 모르지만, 여러분과 팀은 성공에 한 걸

음 더 다가가도록 돕는 프로젝트 구성과 실천방법(practice)을 선택해야 합니다. 이런 조치

를 취해도 완벽하게 성공하지 못할 수 있음을 깨달아야 합니다.

견인인자와 제한인자가 많지만 프로젝트를 시작해야 한다면, 여러분이 취할 수 있는 최

선의 선택은 무엇을 견인인자로 선택하고, 프로젝트 후원자가 무엇을 원하는지 결정하도

록 프로젝트 산출물을 자주 인도하는 것입니다. 프로젝트를 시작하고 나서, 프로젝트 맥

락에 독립적인 질문을 계속해서 프로젝트 성공기준(success criteria)을 발굴하세요(13쪽

의 ‘맥락에 독립적인 질문을 해서 프로젝트 견인인자를 식별하기’ 참조). 아울러, 출시 기

준을 정해놓으면 프로젝트가 끝났을 때를 파악할 수 있습니다(26쪽의 ‘출시 기준’ 참조).

.

제한조건이 너무 많을 때, 결정해야 한다면

프로젝트에 제약이 지나치게 많으면 실패하기 마련입니다. 견인인자가 지나치게 많은

상황은 누구도 성공기준이 무엇인지 모른다는 뜻입니다. 제한인자가 넘친다는 것은

회사 내에서 누구도 우선 순위를 정하길 꺼려한다는 의미죠.

필요하다면 관리자들을 압박해서 무엇이 프로젝트를 이끌고, 제한인자는 무엇인지,

여러분에게 어떤 융통성이 있는지 결정하게 하세요. 이 방법이 먹히지 않는다면 스스

로 결정하세요. 결국, 팀원과 회사는 여러분에게 고마워할 겁니다

프로젝트 제한인자를 넘어서는 프로젝트 요구사항을 받아들일 수 없습니다. 시도해 볼

수 있지만, 3리터짜리 프로젝트 가방 안에 6리터짜리 프로젝트를 넣는 문제와 같은 상황

을 겪습니다. 제한인자가 많은 프로젝트를 어떻게든 꾸려나가려고 시도하겠지만, 경영층

이 원하는 시점에 경영층이 원하는 기능을 구현하면서 결함도 많지 않은 제품을 출시하

는 데 사람도, 시간도, 도구도 충분하지 않습니다.

8 l Manage it

1.3 고객이나후원자와함께프로젝트제한인자에대해이야기하기

후원자가 무엇을 원하는지 파악할 때 마음 편하게 주도권을 잡으세요. 다음은 제가 최근

에 수행한 프로젝트에서 후원자와 나눴던 대화입니다.

요한나: 클라이드, 이번 프로젝트에서 견인인자가 무엇인지 이야기 좀 하죠.

클라이드: 이런, 또 하자고요? 지난번에 했잖아요.

요한나: 그래요. 다른 기능을 추가하고 싶다고 말한 것 기억하시죠? 클라이

드가 출시일 전에 최대한 많은 기능을 짜내길 바란다고 말했기 때문

에, 기능을 추가할 수 있었죠. 우리가 프로젝트를 구성하는 방식이

그렇기 때문이에요. 쉽지 않지만 가능하죠.

클라이드: 그래요. 깜박했어요. 알았어요. 하지만 이번 프로젝트는 달라요.

요한나: 그래요? 뭐가 다르죠?

클라이드: 보세요! 요한나는 사람을 관리하죠. 그리고 프로젝트를 관리하

는 것도 요한나가 맡은 업무죠. 이번 프로젝트에서 돈이 들어가는

장비도 필요하지 않기 때문에, 비용은 신경 쓰지 않아도 돼요. 비

용은 모두 인건비이기 때문이죠.

요한나: 소프트웨어가 필요할지도 몰라요.

클라이드: 까다롭게 굴지 마세요. 알았어요. 필요한 소프트웨어가 있다면,

알려줘요. 그렇더라도, 실질적인 비용은 인건비입니다. 인건비는

제가 신경 쓸 필요가 없습니다. 정말로 중요한 것은 프로젝트 기

간이에요.

요한나: 기능은요? 아니면 품질은 어떻죠? 이번 프로젝트는 재무부서에 사

용할 작은 프로그램이잖아요. 알다시피 그쪽 사람들이 얼마나 깐깐

한데요. 프로그램을 완벽하게 만들지 않는다면 레슬리가 무척 화낼

걸요.

01 프로젝트 시작하기 l 9

클라이드: 그래서 신경 쓰고 있어요. 잘 작동하는 최소한의 기능이 있는 프

로그램을 재무부서에 넘겨주고 싶어요. 최소한의 기능을 만든다

면 아마도 10주 안에 끝낼 수 있겠죠.

�요한나: 지금이 8주째고 기능도 완성되지 않았고 결함도 많다고 해보죠, 그

렇다면 어떻게 할 거죠?

클라이드: 요한나, 왜 그래요? 완벽해야 해요. 그전에도 요한나와 팀원들은

성공적으로 끝냈잖아요. 이번에도 할 수 있어요.

요한나: 클라이드, 프로젝트 팀과 내가 모든 노력을 다할 걸 알잖아요, 그러니

까 클라이드가 정말로 원하는 것을 제가 이해한다고 가정해 보죠.

클라이드: 좋아요. 기능은 완벽해야 해요. 레슬리가 좋아하게 만드세요. 그

렇지 않으면, 레슬리가 절 가만두지 않을 거에요. 그리고 프로젝

트 팀과 당신은 나중에 빈스가 관리할 큰 프로젝트에 참여해야

해요. 빈스가 10주 후에 팀원들이 준비된다고 말했어요. 그 시간

이면 레슬리에게 적당한 프로그램을 만들어주기 충분하겠죠.

1.4 프로젝트에있는견인인자결정하기

클라이드와 제가 나눈 대화에서 저는 클라이드에게 가장 중요한 것을 알아내려고 질문

했습니다. 클라이드가 큰 프로젝트가 10주 후에 시작할 거라고 말했을 때 날짜가 견인인

자라는 것이 명확해졌습니다.

프로젝트 초반에는 모든 것이 가능해 보입니다. 특히 누구도 예측해 보지 않았을 때 더

그렇습니다. 후원자는 이렇게 말할지도 모릅니다. “이번 프로젝트에서는 기능 다섯 가지

가 필요하고, 심각한 결함이 없도록 8월 1일까지 끝내야 해. 예산은 10억 이하로 맞추길

바라네. 그리고 팀원은 6명 주겠네. 어때, 충분하지?”

“문제 없습니다.”라고 대답하지 마세요.

업무량을 산출하고 나면 여섯 명으로 주어진 시간과 예산 안에서 그 일을 실제로 끝낼

지 알 수 있습니다. 팀원들이 해낼 수 있다면 훌륭합니다! 하지만 대개 주어진 시간, 예산,

10 l Manage it

할당된 사람, 후원자가 원하는 품질 기준을 만족하면서, 여러분이 처한 작업 환경에서 후

원자가 원하는 것을 모두 실행하기란 불가능합니다. 실행하기 어려운 경우라면 후원자는

힘든 결정을 내려야 합니다. 회사를 위해 프로젝트의 견인인자를 토대로 결정해야 합니

다. 이런 견인인자로는 출시일, 기능, 비용, 누가 참여하고 언제 참여할지, 그리고 마지막으

로 여러분이 사용할 실천방법과 기술이 있습니다.

프로젝트의 견인인자를 결정하지 못하는 후원자는 프로젝트 관리자에게 결정을 미룹

니다. 프로젝트 관리자가 결정하지 못한다면 프로젝트 팀이 결정하게 되죠. 팀은 같은 생

각으로 결정하지 않습니다. 아울러 팀원들은 후원자가 팀원이 해주길 바라는 결정을 선

택하지 않을 겁니다. 그 대신, 팀원은 프로젝트에서 자신이 맡은 역할에 관계없이 개인적

인 결정을 내릴 겁니다. 결함을 줄이는 데 관심을 기울이지 않고, 출시일만을 최적화하는

팀원도 있습니다. 단지 기능 하나만을(완벽한 회귀 테스트를 지닌 완전한 기능) 구현해서

일정을 지키고 다른 기능들은 완성되지 않은 채로 두는 팀원도 있습니다. 기능에 초점을

맞추는데, 시간이 바닥날 때까지 가능한 많은 토막 코드를 구현하고 테스터가 발견할 문

제를 가득 채워 놓는 팀원도 있습니다. 팀원마다 자신이 옳다고 믿는 것을 할 겁니다. 프

로젝트 후원자(혹은 프로젝트 관리자)가 결정을 내리지 않는다면 팀원마다 다른 결정을

내릴 겁니다.

한 가지 접근방법은 우선순위가 적힌 목록을 만드는 거죠. 말하자면, 스도쿠(Sudoku)

와 비슷합니다. 왼쪽에는 가능한 견인인자를 모두 나열하고 숫자를 채우려고 오른쪽 공

간을 비워둡니다.

행렬을 사용해서 프로젝트 우선순위를 명확하게 정의하기

다음은 클라이드가 우선순위를 적어놓은 표입니다.

프로젝트 우선사항 순위

출시하는데드는비용 5

출시일 1

기능집합 2

낮은결함 3

팀원 4

작업환경 6

01 프로젝트 시작하기 l 11

클라이드가 맡은 프로젝트에서는 출시일 우선순위가 가장 높은 견인인자입니다. 우리

가 출시일을 올해로 맞추지 못했다면, 우리는 프로젝트에서 얻는 가치를 모두 잃어버렸을

겁니다.

하지만 기능도 중요합니다. 즉 기능이 충분하지 않은 채 출시일을 맞추는 것도 가치가

없습니다. 제품이 규제를 받는다면, 결함이 낮아야 합니다. 팀원은 다음 프로젝트에 투입

되기 전까지 10주 동안 프로젝트에 참여할 수 있기 때문에 사람에 대한 우선순위는 그다

음이었죠. 프로젝트의 비용은 그다지 중요하지 않습니다. 즉 프로젝트에서 얻는 가치가

매우 크기 때문이죠. 작업 환경은 마지막인데, 저는 제때에 프로젝트를 끝내도록 작업환

경을 바꾸는 융통성을 발휘했기 때문입니다.

제가 우선순위를 부여했지만, 우리에게는 융통성이 그다지 많지 않았습니다. 하지만

프로젝트의 견인인자를 아는 것만으로도 성공기준을 정의하고 생애주기(life cycle)를 선

택할 때 도움을 얻었습니다. 프로젝트 팀은 업무를 합리적으로 선택하도록 출시 기준을

만들었으며 정리된 견인인자를 사용할 수 있었습니다. 게다가, 우리는 제때에 결과를 내

놓았습니다.

1.5 프로젝트에서원하는게많은후원자관리하기

대개 프로젝트의 성공을 어떻게 정의할지 이야기하는 것은 쉽지 않습니다. 여러분은 제

가 클라이드가 결정하도록 밀어붙여야 했다는 것을 봤을 겁니다. 이런 대화가 흔하죠.

장담하건대 여러분은 기능 집합(feature set), 낮은 결함, 일정이 모두 우선순위가 같다

(우선순위 1번)는 프로젝트에서 일했거나 프로젝트 관리를 맡은 경험이 있을 겁니다. 프

로젝트에서 모든 것을 개발할 수는 없습니다. 아울러 예산은 고정되어 있죠. 아니면 여러

분은 회사에서 지시하는 프로세스, 사무실, 사무용 가구를 사용해야 하거나, 프로젝트

수행을 어렵게 하는 환경적인 이슈가 있습니다. 기술 위험이나 일정 위험이 존재한다면,

프로젝트에 제약이 지나치게 많을 때 누구도 프로젝트를 성공적으로 마칠 수 없습니다.

하지만 잠재적으로 고정된 제한인자를 명확하게 정의하는 데 도움이 되는 접근방법이 있

습니다.

여러분은 10쪽에 있는 ‘행렬을 사용해서 프로젝트 우선순위를 명확하게 정의하기’에서

12 l Manage it

프로젝트 견인인자를 적어놓은 행렬을 살펴봤습니다. 후원자가 결정할 준비가 되었다면

이런 접근방법은 가장 적절합니다. 어쩌면 이런 접근방법은 우유부단한 후원자가 결정을

잘 내리도록 도울 수 있습니다. 하지만 대략 순위를 매기고 나서 결과를 후원자에게 보여

주어야 합니다. 예를 들자면, 상대적인 순위에 동의하지 못하는 후원자가 대여섯 명 있거

나, 결정하는 데 미적거리는 후원자가 있다고 가정해보죠. 이런 경우라면, 결정을 내려서

후원자에게 결과를 보여주세요. 후원자는 스스로 순위를 부여하지 않고 기꺼이 여러분

이 작성한 순위를 고치거나 승인할 겁니다.

다른 접근방법이 두 가지 정도 더 있습니다. 즉 미래를 상상하거나 맥락에 독립적인 질

문을 해서 프로젝트의 견인인자를 도출하는 겁니다.

미래를 상상하라

프로젝트 완료까지 3주 남았다는 상상을 해보라고 후원자에게 말합니다. 기능이 모두 구

현된 건 아닙니다(후원자가 필요한 한두 가지 기능을 구체적으로 제시하세요). 설상가상

으로, 심각한 결함이 여전히 남았으며 결함도 정말로 많습니다. 후원자가 원하는 출시일

전까지 기능을 완성하고 결함을 제거할 수 없다는 건 뻔하죠. 후원자가 무슨 말을 할까

요?

후원자가 “짐 쌀 준비해!”하고 말한다면 회사를 떠날 때가 된 거죠. 이런 경우라면 151

쪽 ‘떠나야 할 때를 알아라’를 읽어보세요.

후원자는 대개 “빌어먹을 프로젝트를 끝내란 말이야, 사람이 더 필요해?”라고 말할 겁

니다. 이런 대답이 나오면 “기능이나 결함 가운데서 어떤 것을 마무리 지어야 할까요?”하

고 물어보세요. 후원자는 일반적으로 “이 기능 두 가지하고, 이 결함들을 끝내.”하고 말

할 겁니다. “어떤 것이 우선순위가 더 높죠?”하고 물어보세요. 어떤 제한조건이 진짜 제

한인자인지, 어떤 제한조건이 후원자의 바람인지 명확하게 정의하도록 후원자를 도와야

합니다.

맥락에 독립적인 질문을 포함해서 대화를 나누면 여러분과 후원자는 프로젝트의 견인

인자, 제한인자 그리고 자유로움의 정도를 식별하는 데 도움이 됩니다.

01 프로젝트 시작하기 l 13

맥락에 자유로운 질문을 해서 프로젝트 견인인자를 식별하기

프로젝트 관리자는 프로젝트 견인인자를 결정할 때 프로젝트 요구사항을 식별할 수 있습

니다. 맥락에 자유로운 질문(context-free question)은 요구사항을 도출하는 데 효과적입

니다. 다른 사람들이 프로젝트를 두고 암묵적으로 판단하는 가정들을 끄집어내는 데 맥

락에 자유로운 질문이 상당히 효과적입니다. 다음의 질문으로 시작하세요.

성공이 뭐죠? ▒

이 결과들을 왜 원하시죠? ▒

부장님에게 가치 있는 해결책이 뭔지 말씀해주세요. ▒

이 시스템을 사용하면 어떤 문제를 해결할 수 있죠? ▒

이 시스템 때문에 발생할 수 있는 문제는 무엇인가 ▒ 요?

‘왜’라는 질문을 사용하는 대신 이런 질문을 사용하세요. ‘왜’라는 질문을 적게 할수록

비즈니스 요구를 더욱 잘 파악할 수 있습니다(그리고 여러분을 코흘리개 두 살배기처럼

보이지 않게 합니다). ‘왜’라는 질문을 하면 다른 사람을 방어적으로 만들기 쉽습니다. ‘어

떻게’란 질문도 삼가야 합니다. ‘어떻게’란 질문은 후원자에게 시스템을 설계해 달라고 부

탁하는 것처럼 들립니다.

프로젝트를 파악하려는 순수한 마음에서 우러나오는 질문을 던지세요. 아울러 이런

질문은 누구도 방어적으로 만들지 않습니다. 후원자와 껄끄러운 관계를 만들지 않고 좋

은 협력관계를 다지는 데 이런 질문을 사용할 수 있습니다.

이런 질문은 시스템의 가치를 말해줍니다. 후원자에게 이런 질문을 할 때는 서로 책임

을 나누는 분위기 속에서 이야기하세요. 컴퓨터가 아닌 종이에 기록하세요. 이렇게 하면

여러분과 후원자는 서로에게 마음의 벽을 쌓지 않습니다. 대화를 시작하는 계기로 이런

질문을 활용하세요. 후원자에게 프로젝트가 어떤 가치가 있는지 초반에 정보를 많이 모

을수록 프로젝트를 어떻게 꾸려나갈지 더 많이 이해할 겁니다.

성공이 뭘까요?

-프로젝트관리자저스틴

2-3년짜리 프로젝트를 맡고 나서 두 달쯤 지났을 때 상관은 제게 와서 기능

하나를 추가하고 싶다고 말했습니다. 제 마음속에서는 이렇게 말했습니다.

14 l Manage it

“와! 이 독특한 기능을 추가하면 멋질 거야.” 한편 마음속에는 이런 목소리

도 있었습니다. “젠장, 프로젝트를 시작한 지 두 달 지났잖아. 기능을 더 많

이 추가해도 괜찮다는 식으로 이 양반을 길들이면 우리가 일하는 방식을 바

꾸지 않으면 곤란하겠는걸.” 그래서 전 이렇게 물었습니다. “성공을 어떻게

정의 내리세요?”

상관이 완전히 변경할 수 있는 프로젝트를 성공이라고 생각한다는 것을 알

았을 때 어찌나 당황스럽던지요. 상관은 요구사항이란 마지막까지 바뀐다고

확신했습니다. 아마도 출시까지 일주일이 남았을 때도 바뀐다고 확신하는

듯했습니다. 예전에는 이런 식으로 프로젝트를 관리하지 않았습니다! 하지

만 이제 상관이 원하는 것을 알기 때문에 변하는 요구사항을 관리하는 방법

을 찾아낼 수 있습니다.

1.6 프로젝트헌장을작성해서의사결정내용공유하기

프로젝트 헌장을 작성하면 프로젝트의 요구사항과 제한조건을 파악하고, 프로젝트 관리

자가 프로젝트를 어떻게 꾸려나갈지 결정하는 데 도움을 얻죠. 팀원들과 후원자는 프로

젝트 헌장을 참조해서 프로젝트와 관련된 의사결정을 할 때 의견일치를 볼 수 있습니다.

프로젝트 헌장을 작성하는 데서 프로젝트를 시작하세요. 이렇게 하면 프로젝트에서 끝

내야 하는 것이 무엇인지 파악하고, 프로젝트가 진행되기를 원하는 사람에게서 프로젝트

에 있는 제한인자가 무엇인지 알아낼 수 있습니다. 프로젝트에 대해 알아야 하는 것을 모

두 알아내지 못하더라도, 프로젝트 헌장을 작성하면서 프로젝트에 있는 이슈들을 파악

할 수 있습니다. 프로젝트 헌장을 작성하면서 여러분과 팀원들은 어떤 위험이 존재하는

지, 성공이란 무엇인지, 프로젝트를 조직하고 운영하는 방법을 이해할 수 있습니다.

애자일 프로젝트를 관리한다면(374쪽 ‘애자일 생애주기’), 여러분이 작성하는 프로젝트

헌장은 무척이나 짧을 겁니다. 프로젝트 비전(프로젝트와 관련된 사람들이 적당한 의사

결정을 내릴 정도)과 출시 기준(쓸데없이 요구사항을 늘리지 않아서 프로젝트를 끝낼 수

있습니다) 정도만 필요할지도 모릅니다.

01 프로젝트 시작하기 l 15

다음은 제가 사용하는 프로젝트 헌장 양식입니다.

비전 ▒

요구사항 ▒

목표 ▒

성공기준 ▒

ROI ▒ 예측

프로젝트 헌장은 의도적으로 짧게 작성합니다. 헌장은 프로젝트를 시작하도록 도와줍

니다. 팀원들이 프로젝트가 끝났다는 것을 프로젝트 헌장을 본다고 알 수 없습니다. 아울

러 팀이 프로젝트를 어떻게 조직할지 알려주지도 않습니다. 하지만 프로젝트를 시작할 수

있다면, 그걸로 됐습니다.

비전

프로젝트를 하는 이유는 두세 가지 정도 있습니다. 이 프로젝트를 하는 이유는 무엇인가

요? 비전 선언문(vision statement)을 사용해서 프로젝트에서 무엇이 가치 있는지 알려 주

세요. 프로젝트 초기에 프로젝트의 가치를 명확하게 정의할수록, 팀원들은 프로젝트가

정상적인 상태이거나, 성공할 수 없는 프로젝트를 시작하려고 하는지 여러분에게 알려줄

가능성이 큽니다. 비전을 명확하게 정의할 수 없다면 불가능한 프로젝트를 시작할 가능

성이 매우 커집니다(비전이 없는 프로젝트를 끝낼 방법은 존재하지 않기 때문이죠). 유용

한 비전은 팀원들이 따르죠.

요구사항

프로젝트의 유일한 요구사항이 특정 시점까지 무언가를 출시하는 것일 때도 있습니다.

다음처럼 다양한 요구사항이 혼재한 경우가 더 흔합니다. 즉, “우리는 2월 20일에 있을 메

이저 출시에 OO 기능을 구현해야 해.” 이런 경우엔, 제품의 기능목록이 아닌 프로젝트의

견인인자를 생각해 보세요.

목표

프로젝트 목표는 여러분이 프로젝트에서 완수하고 싶은 것이지만, 고객이나 후원자가 기

대하는 것은 아닐 수도 있습니다(27쪽 ‘목표’ 참조).

16 l Manage it

누가 프로젝트 헌장을 작성하나요?

헌장을 작성하면 팀이 하나로 뭉치도록 도와줍니다. 프로젝트 헌장을 작성할 때 가능

한 팀원이 많이 참석하게 하세요. 팀원이 프로젝트 팀에 아직 배정되지 않았다면 여러

분 혼자서 작성하세요. 팀원이 있다면 팀원과 함께 작성하세요. 프로젝트 킥오프 회의

를 진행하면서(211쪽 ‘프로젝트 킥오프 회의’) 프로젝트 헌장을 검토하고 참석자들에

게 프로젝트 헌장의 내용과 프로젝트를 수행하는 이유를 알려 주세요.

목표는 요구사항과 같지 않습니다[DeM97]. 프로젝트 목표는 결과로서 나오는 것이 아

닙니다. 여러분이 전통적인 단계별 개발이나 폭포수 개발을 사용한다면 여러분이 만드는

제품에는 상당한 기술 빚(technical debt, 381쪽 ‘용어 정리’ 참조)이 존재할 수 있습니다.

다시 설계하거나 자동화된 테스트를 추가하거나 스모크 테스트(smoke test)를 개발하는

방식으로 기술 빚을 제거하는 것이 프로젝트 목표의 한 가지 예입니다.

고객이 구체적으로 무언가를 요구할 때도 있습니다. 즉 “전자 서명을 추가하고 싶은데

요. 현재 일정에서 공짜로 추가할 수 있다면 말이죠.” 실용주의 프로젝트 관리자로서 여

러분은 이렇게 말할 수 있습니다. “네, 우선 말씀하신 것을 목표에 추가해 두죠. 이렇게 하

면 셜리나 제인이 시간이 날 때 전자 서명 기능을 개발할 수 있습니다.”

성공기준

성공기준이란 프로젝트가 끝났을 때 고객이 제품을 사용해서 무엇을 할 수 있을지를 정

의한 것입니다. 성공기준은 결함에 관한 것이 아니죠. 즉 결함은 성능에 관한 것입니다

([Rpt02b]와 [Wie05] 참조).

성공기준의 예는 다음과 같습니다.

특정 시장에 제품을 판매할 수 있도록 기능 1, 2, 3을 포함한다. ▒

성능을 측정하고 개선해서 경쟁사 제품과 회사의 제품을 비교하는 마케팅 자료를 ▒

만들 수 있다.

회사 사이트에 어떻게 접속하는지 몰라도 고객들이 패키지를 풀고 소프트웨어를 ▒

구동할 수 있다.

1분기에 출시한다. ▒

01 프로젝트 시작하기 l 17

프로젝트는 여러분이 생각하기도 전에 시작합니다.

공식적인 일정을 시작하기도 전에 프로젝트가 시작될 때가 흔합니다. 프로토타이핑을

끝낸 사람이 있을지도 모르고, 기능에 대한 예측을 한 사람이 있을지도 모릅니다. 상

위 관리자는 수석 아키텍트와 무엇이 가능하고 무엇이 불가능한지 이야기를 끝냈을지

모릅니다. 이런 것들을 프로젝트 일부라고 여기지 않더라도, 이것들은 프로젝트 일부

입니다.

여러분이 프로젝트를 시작한다고 생각하기 전에 프로젝트가 시작되기 때문에, 프로젝

트 헌장이나, 프로젝트 계획, 프로젝트 일정을 반복해서 수정하는 것을 걱정하지 마세

요. 여러분은 실용주의 프로젝트 관리자로서 이미 시작된 프로젝트를 파악하는 데 전

념합니다. 프로젝트 중반쯤에 프로젝트의 진척도와 위험을 다시 평가해서 프로젝트의

방향을 조절합니다. 실용주의 노선을 걸어왔다면, 프로젝트가 끝날쯤에는 걱정거리가

없을 겁니다.

팀원들에게는 성공 기준에 대한 통제권이 있습니다. 여러분은 프로젝트 관리자로서 팀

외부에 있는 사람만이 성취할 수 있는 성공 기준을 경계해야 합니다. 예를 들자면 ‘제품 5

만 개 판매’와 같은 것 말이죠. 여러분과 팀원들에게는 다른 사람이 하는 일을 통제할 수

없습니다. 말하자면, 프로젝트에서 수행하는 일만을 통제할 수 있죠. 여러분이 통제할 수

있는 범위 안에서 성공 기준을 정하세요.

ROI

제 고객들은 투자회수율(ROI, return of investment)을 거의 측정하지 않습니다. 투자회

수율을 조작하기는 정말로 쉽습니다. 하지만 경영진에서 투자회수율을 원하고, 여러분이

프로젝트에서 얻는 이익을 예측할 수 있다면 ROI를 계산해 보세요. 아울러 프로젝트가

끝나고 ROI를 확인해서 목표로 삼은 ROI를 달성했는지 확인해 보세요.

18 l Manage it

1.7 프로젝트에서품질이뜻하는바를파악하라

프로젝트 견인인자, 제한인자, 변동인자를 이해하는 일은 후원자와 고객이 품질을 어떻

게 정의하는지 이해하는 첫 번째 단계입니다. 후원자는 프로젝트에 돈을 대는 사람입니

다. 고객은 제품을 사용하는 사람이죠. 후원자와 고객은 같지 않아도 됩니다. 아울러 후

원자나 고객은 모두 품질이란 무엇인지 정의하지 않습니다. 품질을 정의하지 못한다면 프

로젝트는 더욱 힘들어질 겁니다. 하지만 완료가 뜻하는 바를 어느 정도 파악해도 프로젝

트에서 품질이란 무엇을 의미하는지 이해하는 데 도움을 얻습니다.

초기시장

고객 숫자

시간

캐즘

주류 시장

혁신 수용자

제품 철수

선각 수용자 전기 다수 수용자 후기 다수 수용자 지각 수용자

그림 1.2 | 무어의 캐즘(Moore's chasm)

와인버그(Weinberg)는 “품질은 다른 사람에게 주는 가치다”하고 말했습니다[Wei92].

여러분은 와인버그의 정의를 토대로 기능을 더 많이 추가하고 기능 한 개가 얼마나 많은

‘누군가’의 관심을 끌지 그리고 어떤 ‘누군가’의 관심을 끌지 알 수 있습니다. 출시를 앞당기

거나 뒤로 미루는 것은 ‘누군가’의 관심을 끌거나 그렇지 못할 수도 있습니다. 후원자와 고

객에 대해 생각할 때 후원자와 고객이 프로젝트에서 무엇을 좋아할지 고민해보세요. 이

런 고민을 하면 여러분에게 출시까지 시간을 앞당기거나 연기하고, 프로젝트 비용이나 팀

원을 늘리는 선택을 할 수 있고, ‘누군가’가 어떤 기능을 원하는지 생각해 볼 수 있습니다.

‘누군가’가 무엇을 품질로서 받아들일지 안다면 ‘누군가’가 마음을 바꿀 때에도 계속해서

프로젝트를 꾸려갈 수 있습니다. 즉 이런 상황이 벌어져도 여전히 성공할 수 있습니다.

01 프로젝트 시작하기 l 19

그림 1.2에서 보는 것처럼 여러분이 만든 제품이 수용 곡선에서[Moo91] 어디에 있느냐

에 따라 여러분의 고객은 품질에 따라 다른 정의를 내립니다.

제품의 생명이 시작할 때 고객의 숫자는 적습니다. 하지만 혁신 수용자(technology

enthusiast)는 여러분에게 어떤 제품이 있는지 보길 원하죠. 따라서 출시하라고 심하게 압

박합니다. 제품에는 기능이 많지 않거나 제품이 견고하지 않더라도, 고객을 더 많이 끌어

모으려면 잘 작동하는 기능이 존재해야 합니다.

얼리 어댑터(early adopter) 시장에 들어서면 고객의 숫자에 관계없이, 고객마다 다른 요

구사항을 내놓을 겁니다.

고객 그룹마다 여러분이 만든 제품이 다른 고객이 원하는 기능이 아닌 다른 기능을 갖

추길 원합니다. 그리고 고객은 모두 자신이 원하는 기능이 있는 제품이 하루빨리 출시되

길 원합니다. 여러분이 만든 제품은 사용하는 데 불편하지 않을 정도면 충분합니다. 하지

만 이런 고객에게 여러분이 만든 제품만이 해결할 수 있는 문제가 있기 때문에 결함이 있

어도 제품을 판매하는 데 문제가 없습니다.

하지만 여러분이 만든 제품이나 제품과 비슷한 것이 주류 시장에 진입하면, 전기 다수

수용자(pragmatist)는 제품에 있는 결함을 수정하는 데 관심을 보이죠. 앞에 출시한 제품

에서 기술 빚(381쪽 부록 B)이 있다면 지금이 바로 기술 빚을 갚을 시간입니다. 전기 다수

수용자에게 엄청난 구매력이 있기 때문에 전기 다수 수용자는 고객이 모두 새로운 출시

를 설치하길 원하지 않더라도 더 자주 출시하도록 경영층을 압박할 겁니다. 출시할 때 기

능을 많이 추가할 필요는 없지만, 소프트웨어를 더욱 안정적으로 만드는 것만 신경 쓰지

못합니다.

후기 다수 수용자(conservative)는 어쩔 수 없이 제품을 구매합니다. 제품이 알려진 것

대로 작동하지 않거나 결함이 많다면 만나는 사람마다 제품에 대해서 불평할 겁니다. 후

기 다수 수용자는 기능이 많기를 바라지 않습니다. 그들은 약속한 기능이 작동하길 바라

죠. 바로 이때가 여러분이 결함만 수정하거나 더욱 신뢰하고 성능이 더 우수하며 훨씬 견

고한 제품을 출시할 수 있는 시점입니다.

느림보 사용자나 지각 수용자(skeptic)는 제품을 구매하거나 구매하지 않을 수도 있습

니다. 회사에서 이런 영역에 있는 제품을 캐시 카우(cash cow)라고 부를 때도 있습니다. 회

20 l Manage it

사에서 고객 지원에 들이는 비용보다 고객 지원 계약에서 더 많은 돈을 벌어들이기 때문

이죠.

물론 제품이 출시되었을 때부터 더 자주 출시하라고 압박을 심하게 받을지라도, 제품

이 성숙한 후에 더 많은 고객은 결함을 더욱 낮추라고 압박할 수 있습니다.

☞ 이것만은기억하자!

프로젝트를 시작하면서 반드시 프로젝트 헌장을 작성하세요. ▒

프로젝트 헌장을 반복해서 수정할 것을 예상하세요. 헌장은 완벽하지 않아도 됩 ▒

니다. 즉 헌장이 존재하는 것만으로 프로젝트 팀 전체가 계획을 세울 때 도움을

얻습니다.

프로젝트에서 품질이란 무엇인지 프로젝트를 이끄는 것은 무엇인지 알아두세요. ▒

이렇게 하면 프로젝트를 수행하면서 괜찮은 결정을 내릴 수 있습니다.

21

02프로젝트 계획하기

드디어 프로젝트 헌장이 생겼습니다. 프로젝트 헌장을 작성할 여유가 없었다면 프로젝트

킥오프 회의를 진행하면서 프로젝트 헌장을 함께 작성하세요(211쪽 ‘프로젝트 킥오프 회

의’ 참조). 일단 팀이 프로젝트 헌장에 익숙해지면 여러분과 팀원들은 계획하기(planning)

와 약간의 일정잡기(scheduling)를 할 준비를 끝낸 셈입니다.

계획하기와 일정잡기는 서로 다른 활동입니다. 계획하기란 출시 기준을 포함한 프로젝

트 계획을 작성하는 것입니다. 일정잡기란 업무의 윤곽을 잡고 순서를 부여하는 것이죠.

2.1 시작하기

프로젝트 관계자들은 프로젝트 헌장을 참고해서 올바른 방향으로 나아가도록 가까운 미

래를 계획하거나, 그릇된 방향으로 가는 것이 아닌지 판단할 수 있습니다. 팀원들은 프로

젝트 계획을 참고해서 바람직한 프로젝트 결과를 얻도록 집중하죠.

팀이 작다면(예를 들어 열 명 이하인 경우), 팀원들과 함께 프로젝트 계획을 작성하세

요. 며칠이나 몇 주 동안 어떤 일을 할지 팀원들과 이야기를 나누고, 팀원들이 프로젝트의

산출물이 무엇인지 정확히 파악하세요. 요구사항이 있다면 팀원들은 프로토타입을 만들

거나 첫 번째 반복주기(iteration)를 시작할 수 있습니다. 애자일 생애주기(agile life cycle)

를 사용한다면 프로젝트 계획을 출시 계획(release plan)처럼 사용하세요.

22 l Manage it

팀원이 필요한 인원보다 적거나, 프로토타입을 만들 때 사람이 너무 많거나, 아니면 무

엇을 해야 할지 정말로 모르는 경우가 더 흔하죠. 이런 경우라면 앞서 출시했던 버전에 있

는 결함을 수정하는 것부터 시작하자고 팀원들에게 말하세요(287쪽 ‘팀원들이 기술 빚

을 줄이려는 마음으로 시작하게 하라’ 참조).

2.2 시작하기에적당한정도로만계획하기

프로젝트 헌장이 있습니다. 하지만 계획도 있나요? 관리자들은 여러분이 어떤 기능을 코

드로 구현해서 언제 인도할지 항상 알고 싶어합니다. 진척도를 어떻게 측정할 건가요? 프

로젝트는 언제 끝나죠?

계획은 완전하지 않아도 괜찮습니다. 사실, 계획은 완벽할 수 없습니다. 여러분이 세우

는 계획은 성공할 가능성이 있고 프로젝트를 시작하기에 적당한 정도면 충분합니다. 시

간이 촉박한 프로젝트를 수행한다면(제 경우엔 대부분 그랬습니다), 계획하기 활동에 타

임박스(timebox)를 사용하세요. 다시 계획을 세울 것이라면 초기에 계획을 완벽하게 세우

는 것을 심각하게 고민할 필요가 없습니다.

타임박스는 정해진 기간을 의미하며 개인이나 팀은 타임박스 안에서 특정 작업을 달성

하려고 노력합니다. 개인이나 팀이 타임박스 동안 완성한 결과만큼만 프로젝트의 나머지

기간에서 인도하게 됩니다. 따라서 필요한 경우 개인이나 팀은 타임박스 안에 일을 끝내

도록 범위를 줄입니다.

초기 계획을 세울 때 타임박스를 적용하죠.

-프로젝트포트폴리오관리담당전무이사스티브

우리는 동시에 규모가 큰 프로젝트를 2-5개 그리고 규모가 작고 기간이 짧

은 프로젝트 15개를 수행합니다. 대부분의 프로젝트에서 팀원이 몇 명이나

필요하고 프로젝트가 얼마나 걸릴지 파악하려면 일단 시작해야 합니다. 프

로젝트를 시작하면서 초기 계획을 세울 때에도 초기 계획을 세우는 데 시간

을 오래 할애하지 않습니다.

최근에 시작한 규모가 큰 프로젝트에서 대여섯 번 출시하고 2년 정도 걸릴

02 프로젝트 계획하기 l 23

것으로 예상했죠. 우리는 초기 계획을 세우는 데에 단지 3일짜리 타임박스

를 사용했습니다. 타임박스 마지막 날 우리는 프로젝트 헌장, 최초 출시에 대

한 출시 기준을 정의한 프로젝트 계획, 그리고 처음 3주 동안 일정을 얻었습

니다. 이것들이 전부였지만 프로젝트를 시작하는 데 충분했습니다.

우리가 수행했던 단기 프로젝트 2개의 기간이 6개월 미만이었는데, 초기 계

획을 세우는 데 하루짜리 타임박스를 사용했고, 여기에서도 2주간의 일정

을 뽑았습니다. 팀원들이 프로젝트를 수행하면서, 필요할 때마다 계획을 상

세하게 세울 때 초기 계획하기를 수행하면서 얻은 피드백을 사용합니다.

프로젝트에서 특정한 기능이 언제 완성될지 예측해야 한다면 처음 몇 주 동

안 처음으로 예측하는 데 시간을 쓰고, 다음 몇 주 동안 이 예측을 갱신합니

다. 8주나 12주가 될 때쯤, 어떤 기능이 언제 완성될지 감을 얻습니다. 우리

는 완전하지 않지만, 데이터 없이 계획을 세우는 데 시간을 허비하지 않습니

다. 계획을 세우고, 데이터를 얻은 다음, 다시 계획을 세웁니다. 이 방법이 효

과적이죠.

프로젝트의 기간에 여유가 있더라도, ‘정확한’ 계획을 세우려고 지나치게 많은 시간을

쏟으면 프로젝트는 시간 압박에 시달리게 됩니다.

예언이 아니라 경험을 바탕으로 계획하라

경험적인 계획하기란 계획을 조금 세우고 나서, 실제로 계획이 얼마나 진척되었는지

정보를 모아서 새로운 계획을 세울 때 활용합니다. 경험적인 계획하기는 효과적입니

다. 예언적인 계획하기는 미래를 예측하려고 시도하는 것으로서 요술구슬이 없다면

잘 맞지 않습니다. 프로젝트를 수행할 때 가능하다면 경험적인 계획하기와 일정잡기

를 사용하세요.

“계획은 쓸모없지만, 계획하기는 가장 중요하다.”라는 아이젠하워가 말한 유명한 이야

기를 들어봤을 겁니다. 1 프로젝트에서 모든 것을 미리 계획할 때 이런 계획하기를 방해하

1 　1957년 11월 14일, 워싱턴 주, 미 안보위원 준비회의의 (National Defense Executive Reserve Conference) 연설에서

24 l Manage it

는 불확실성과 위험이 정말로 많습니다. 91쪽 ‘연동 계획 사용하기’에서처럼 프로젝트를

시작할 정도로만 계획을 세우고 나서 매주 계획을 다시 세우세요. 어떤 생애주기를 사용

하더라도, 다시 계획을 세울 것이라고 가정하세요. 완벽한 계획은 세우지 마세요. 완벽한

계획 대신 계획을 변경하기 전까지 유효한 계획을 작성하세요.

완료를 염두에 두고 시작하기[Cov91]

계획하기를 시작하면서 얼마나 상세하게 작성해야 할지 생각해 보세요. 출시 기준(31

쪽 ‘출시 기준 정의하기’ 참조) 덕분에 후원자와 프로젝트 팀원들은 집중할 수 있습니

다. 계획을 작성하는 시간을 줄이려면 반드시 출시 기준과 위험목록이 있어야 합니다.

필요하다면 계획을 작성하는 작업을 반복하세요. 애자일 생애주기를 사용하는 프로젝

트를 맡았다면 모든 계획을 프로젝트 초반에 작성하지 않아도 됩니다.

2.3 프로젝트계획양식만들기

프로젝트 계획을 사용해서 생각을 정리하세요. 이때 사용하는 프로젝트 계획은 여러분

의 회사에서 수행하는 다른 프로젝트에서 재사용할 수 있는 형식이면 더 좋습니다. 다음

은 제가 사용하는 프로젝트 계획 양식입니다.

제품 목적 ▒

이력 ▒

출시 기준 ▒

목표 ▒

프로젝트 구성 ▒

일정 개요 ▒

프로젝트 인력 투입(인력 투입 곡선) ▒

목표 일정 ▒

위험목록 ▒

02 프로젝트 계획하기 l 25

프로젝트 목적

제품을 간략하게 설명합니다. 여기에는 회사에서 이 제품을 생산하려는 이유, 회사에 어

떤 이익이 돌아가는지 등을 포함합니다. 후속 출시가 있다면, (3~4개의 문장으로) 이번

출시는 어떤 가치가 있나요? 프로젝트 헌장에 비전을 적어두었다면, 프로젝트 목적에 비

전을 인용해도 괜찮습니다.

프로젝트 헌장에 있는 비전이 프로젝트에 적당하지 않을 때도 있습니다. 아니면, 비전

이 프로그램 2 (313쪽 ‘프로젝트가 프로그램일 때’ 참조)에 적합할 때도 있죠. 두 가지 경우,

프로젝트에 대한 목적을 명확하게 해야 합니다.

몇 년 전(TCP/IP가 운영체제에 포함되기 전), 저는 하드웨어와 소프트웨어가 통합된

제품을 만드는 프로그램을 관리했습니다. 다양한 기능을 구현했는데, 각 기능이 하나의

프로젝트였습니다. 저는 이 프로그램의 헌장을 작성했는데, “OOO 전시회에 맞춰 이 제

품을 출시한다.”가 프로그램 헌장의 비전이었습니다. 프로젝트 팀이 6개가 있었으며, 이

가운데 네트워킹 팀이었습니다. 네트워킹 팀의 목표는 다음과 같았습니다. “첫 번째 통합

시점에 TCP/IP가 작동해야 하고, 프로젝트 기간에도 계속해서 작동해야 한다.” 네트워킹

팀의 목표는 명확했고 프로그램의 비전과 관련되었지만 훨씬 더 구체적이었죠.

프로젝트(혹은 프로그램)의 크기와 기간에 따라서, 프로젝트 팀마다(혹은 하위 프로

젝트 팀) 고유한 목표가 있습니다. 프로젝트 팀의 목표는 프로그램 헌장의 비전과 동일

선상에 위치하지만, 동일하지 않습니다.

이력

후속 출시(4.2 버전을 출시한 다음 4.3 버전을 출시한다면)도 관리한다면, 이전 출시나 관

련된 출시의 이력을 검토하세요. 이력을 살펴보면 기술 빚이 명백해집니다. 여러분이 검토

할 수 있는 데이터는 다음과 같습니다. 얼마나 자주 출시했는가, 출시에 있는 결함 개수,

고객이 알려준 문제, 품질을 정의하고 프로젝트를 어떻게 관리할지 결정하는 데 영향을

끼치는 것.

2 　 (옮긴이) 여기서 말하는 프로그램은 컴퓨터 프로그램을 의미하는 것이 아니라, 프로젝트 몇 개를 묶어놓은 것이다.

26 l Manage it

적게 알수록...

프로젝트의 개별적인 내용을 완벽하게 파악하지 못할수록 여러분에게 다급한 일이 생

길 가능성이 커집니다. 이런 상황은 기술 빚, 새로운 아키텍처, 개발 혹은 테스트 위험

이나 계획을 작성할 때도 일어납니다. 예전에 지금과 비슷한 프로젝트를 경험하지 못

했다면 더 다급한 일이 벌어질 겁니다. 이런 상황에서도 조금 계획하고 나중에 다시

계획할 것을 계획하는 게 좋습니다.

고객이 일 년에 한 번 출시하는 데 익숙하고, 그 이상 자주 출시하라고 요구하지 않는

다면(18쪽 그림 1.2에서 표시된 것처럼, 무어의 용어로 표현하자면 주류 고객에 해당합니

다), 대안이 몇 가지 있습니다. 첫 번째 대안은 상위 경영층이 자주 출시하라는 지시를 받

아들이지 않는 것입니다. 지시를 거절하는 대신, 다른 대안을 고려해보세요. 즉 출시 기차

(release train, 318쪽 ‘다수의 제품 출시를 출시 기차로 구성하라’ 참조)를 사용하거나 애

자일 생애주기를 사용해서 더 자주 출시하는 방법이 있습니다. 새로운 시장을 창출하거

나 새로운 시장에 참여하려는 단계라면 자주 출시하도록 프로젝트를 구성하세요.

기존 출시에 포함된 결함의 개수와 종류를 검토하세요. 이렇게 하면 여러분은 이번 프

로젝트에서 작업할 소스 코드에 포함된 기술 빚의 수준과 종류를 이해할 수 있습니다.

고객이 출시한 제품 가운데 특정 부분에서 문제가 많다고 알려준다면, 문제가 문서에

있는지 아니면 코드에 있는지 (그리고 어떤 종류의 이슈인지) 검토하세요. 여러분은 고

객이 알려주는 기술 빚을 더 파악할수록 이른 시기에 기술 빚을 처리할 기회를 얻게 됩

니다.

출시 기준

프로젝트에서 나오는 핵심 산출물을 항목별로 나누세요. 이런 항목을 식별하는 괜찮은

방법은 “산출물이 완성되지도 않았는데, 출시해도 괜찮을까요?”하고 묻는 것입니다. 기

능성, 성능, 품질 요구사항을 포함하세요(31쪽 ‘출시 기준 정의하기’ 참조).

02 프로젝트 계획하기 l 27

목표

프로젝트 헌장을 작성하면서 목표를 파악했을지도 모릅니다. 프로젝트 계획을 작성할 시

점에 목표를 더욱 자세하게 알게 될 겁니다. 프로젝트 헌장을 작성할 때 목표를 파악하지

못했다면 지금이 목표를 고민할 적당한 시점입니다.

프로젝트에는 제품 목표, 프로젝트 목표, 팀 목표, 회사 목표 가운데 하나에 해당하는

목표가 있을지도 모릅니다.

제품 목표는 순위가 매겨진 요구사항으로서 이번 출시에서 출시하지 못할지도 모 ▒

릅니다. 이 목록을 제품 백로그(product backlog)에 보관하세요(354쪽 ‘제품 백로

그를 사용해서 새로운 기능에 대한 요구를 관리하라’ 참조).

프로젝트 목표는 요구사항이라기보다 성능기준과 비슷할 것입니다. 아니면 “미해 ▒

결 결함 목록을 출시할 때 50개에서 40개로 줄이자.”라는 것과 비슷합니다. 특히

프로그램을 운영하고 있다면 각 하위 프로젝트의 목표는 프로젝트 영역으로 한정

될 겁니다. 팀원들이 해결하고 싶은 특정 기술 빚이 있을 수도 있습니다.

팀 목표는 “제품에 대한 자동화된 ▒ 스모크 테스트 비율을 향상시켜라.”라는 게 될

수 있습니다. 팀은 특정 기능의 성능이나 안정성을 개선하길 원할지도 모릅니다.

회사 목표는 “회사의 ▒ 기민성(agility)을 높이도록 프로젝트의 전반적인 기간을 줄

이자.”라는 게 될 수 있습니다.

목표를 프로젝트 헌장 문서 안에 상세하게 기록했다면 프로젝트 계획에 포함하지 않아

도 괜찮습니다. 두 문서 가운데 하나를 선택해서 목표를 설정하세요.

프로젝트 구성

프로젝트에서 팀원들이 어떻게 작업하기를 바라는지 명확하게 정의하세요. 어떤 생애주

기와 핵심적인 실천방법을 사용해서 프로젝트 업무를 구성할 것인지, 프로젝트에서 결정

을 내릴 수 있는 의사결정자가 있는지 언급하세요. 프로토타이핑이 필요하다면(혹은 필

요하다고 생각한다면), 이렇게 설명하세요. “스티브와 제니가 기능을 검증하려고 아키텍

처 프로토타입을 만들 것이다. 빌이 동시에 테스트할 것이다. 여유가 없어서, 팀원들은 코

드를 지속적으로 검토할 수 있는 방법을 선택할 것이다.”

28 l Manage it

프로젝트를 운용하는 일반적인 접근방법을 기록하세요. 프로젝트를 시작할 때 전체

프로젝트 팀이 구성되어야 한다는 것, 새로운 직원을 뽑는 것, 코드와 문서를 포함하는

완전한 기능을 개발하는 것, 코드를 작성하고 코드를 작성하는 동안 문서로 작성할 수 있

는 게 무엇이 있는지 살펴보는 것과 같은 이슈를 포함합니다.

프로젝트 구성에 얼마나 상세하게 기록할지는 팀이 사용하는 생애주기와 팀의 구조에

따라서 다릅니다. 제품에 대한 모든 결정을 내리는 제품 소유자(product owner)가 한 명

이라면, 제품 소유자의 이름을 적을 필요가 있는지 결정하세요. 기능과 절충안에 대한

결정을 내리는 사람이 여러 명이라면 의사결정자와 그들이 맡은 책임이 무엇인지 적어

두세요.

타임박스를 적용한 반복주기를 사용한다면 타임박스의 기간을 기록하세요. 출시 기차

를 사용한다면 각 기차의 기간을 적어두세요.

일정 개요

주요한 마일스톤과 마일스톤마다 관련자들이 원하는 것을 기록한 일정 개요를 작성하세

요. 반복주기나 증분(increment)을 사용한다면, 각 반복주기(혹은 증분)의 기간과 반복주

기 완료 시점에 산출물을 적어두세요. WBS(work breakdown structure) 형식으로 작성하

지 않아도 되지만 WBS가 있는 경우라면 상세한 내용을 살펴보길 원하는 사람들을 위해

WBS의 링크를 포함하세요. 사용하는 생애주기에 상관없이, 베타 테스트를 수행하거나

고객에게 조기에 출시한다면 이런 마일스톤을 기록하세요.

WBS는 작업을 구성해 놓은 것으로, 작업 사이에 의존 관계, 기간, 담당자를 알려줍니

다. WBS의 상위 단계일수록(그리고 프로젝트 초기라면), WBS를 잘 알 수 없습니다. 즉

진행하면서 WBS를 수정할 것을 예상하세요.

일정 개요 덕분에 관리자들이 프로젝트의 현황을 잘 알게 되었습니다.

-프로젝트관리자테리

전 지금 두 번째 프로젝트를 관리하는 중입니다. 관리자들은 제가 맡았던

이전 프로젝트보다 고객과 대화를 더 많이 나눠야 한다는 것을 믿지 않았습

니다. 관리자들에게 이 사실을 설명하려고 마일스톤이 담긴 프로젝트 개요

를 작성했습니다. 작성한 프로젝트 개요는 다음과 같습니다.

02 프로젝트 계획하기 l 29

일정 마일스톤

7월 1일 프로젝트 시작

7월 15일 웹 인터페이스의 프로토타입을 루신다에게 선보임

7월 30일 루신다와 조리부 직원에게 주방 인터페이스를 선보임

8월 15일 내부적으로 웹과 주방 인터페이스를 인도

8월 30일 루신다가 엄선한 다섯 명의 고객에게 일찍 출시를 함(베타 테스트)

9월 1일 베타 테스트를 시작

9월 30일 베타 테스트를 완료

10월 30일 전체 고객의 주문과 주방 인터페이스를 포함한 사이트를 론칭

관리자들은 제 업무를 파악하자, 제가 요청했던 기간이나 팀원 그리고 고객

과 대화가 왜 필요한지 깨달았습니다.

프로젝트가 훨씬 복잡하고 시작하기 전에 일정을 잡는 게 위험한 것 같다면 후원자에

게 프로젝트에 대한 대안 몇 가지를 제안해서 대안을 살펴보게 하세요. 다음 페이지 그림

2.1은 매트릭스 조직형태로 프로젝트를 운영하는 회사의 경우를 보여줍니다.

여러분은 대안을 실행할 때 필요한 비용이 아니라, 대안이 주는 가치를 확실하게 이해

해야 합니다. 여러분이 출시 기준에 미치지 못하는 제품을 인도한다면 가치가 충분한 대

안이 아닙니다.

프로젝트 인력투입

프로젝트 관리자들은 자신이 관리하는 프로젝트에 투입할 인원을 정하지 못합니다. 프로

젝트 첫째 날 팀원들이 모두 투입된다면 인력투입 곡선을 두고 고민하지 마세요. 다른 부

서나 팀에서 팀원을 요청해야 한다면 프로젝트 인력투입에 언제 어떤 팀원이 몇 명이나

필요한지 적어두세요(135쪽 7장 ‘탁월한 팀 만들기’ 참조).

30 l Manage it

목표 일정

주요 마일스톤의 윤곽을 잡아보세요. 주요 마일스톤의 수준은 여러분이 이해한 정도면

충분합니다. 최초에 잡은 일정을 반영하는 간트 차트(Gantt chart)가 있다면, 목표 일정란

에 파일의 링크를 걸어두세요. 물론 계획을 다시 세울 때마다 간트 차트는 현재 상황을 보

여주도록 수정해야 합니다. 간트 차트를 갱신하기 쉽도록 프로젝트 계획과 분리해서 관리

하세요.

저는 포스트잇을 사용해서 일정을 잡기 때문에 제가 관리하는 프로젝트에서 완전한

간트 차트를 찾아볼 수 없습니다. 저는 이렇게 말할 때가 있습니다. “최신 WBS를 알고 싶

다면 프로젝트 룸의 벽을 보세요.”(간트 차트를 붙여놓은 프로젝트 룸이 없다면, 모든 사

람이 일정을 볼 수 있도록 공공장소를 사용하세요. 이런 식으로 팀원들은 프로젝트 초기

에 일정에서 일어나는 문제를 여러분에게 알려줄 수 있습니다)

대안 기간 아키텍처

단계

개발단계 테스트

단계

문서작업

단계

기능1,2 2달 월1명 월6명 월6명 월2명

기능1,2,3 4달 월2명 월10명 월10명 월3명

기능1,2,3,

4,5,6

12달 월6명 월60명 월50명 월8명

그림 2.1 | 매트릭스 조직을 사용하는 프로젝트에서 가능한 대안

연동 계획하기(rolling-wave planning)를 자주 사용한다면(91쪽 ‘연동 계획 사용하기’ 참

조), 지난 계획에 상세하게 추가할 게 많지 않습니다.

프로젝트 초반에 너무 상세하게 일정을 잡지 마세요.

프로젝트를 진행하면서 일정을 자세하게 작성하고, 이런 과정을 반복하세요(57쪽 4

장 ‘프로젝트 일정잡기’ 참조). 프로젝트 초기에 후원자에게 상세한 일정을 제공한다

면, 후원자가 프로젝트에 위험이 거의 없다고 생각할 가능성이 큽니다. 후원자는 일정

에 적힌 완료 날짜를 보고, 이 날짜가 프로젝트의 진짜 완료 날짜라고 생각할 겁니다.

02 프로젝트 계획하기 l 31

프로젝트 위험목록 만들기

프로젝트 계획에 적어도 10대 위험목록을 작성하세요. 위험목록을 자주 모니터링하고,

적절한 시기에 목록을 수정하세요. 프로젝트에 10대 위험이 있는지 잘 모르겠다면 팀원

들과 함께 위험에 대해 브레인스토밍하세요.[DL03] 위험을 식별하고 관리하는 일은 빨리

시작할수록 좋습니다. 그림 2.2는 프로젝트를 시작할 때 사용하는 위험목록의 양식으로

서 실제 프로젝트에서 위험목록을 가져왔습니다. 프로젝트를 수행하면서, 위험목록을 갱

신하세요. 위험을 줄이는 데 8장(159쪽), 9장(189쪽)에 있는 실천방법을 사용하세요.

위험번호 위험설명 발생확률 치명도 위험도 조치예정일 완화계획

위험에

번호를

부여

위험을

설명

위험이

발생할

확률

위험이

발생할

때심각

한정도

발생확률

X치명도

조치가필

요한날짜

위험을

처리할

계획

1 프로젝트

에영향

을주기

전까지

알고리즘

이빨라

질지모

르겠음

중간 심각 (중간,심

각)

7월14일 알고리즘

만테스

트하도록

테스트

개발자를

추가해서

알고리즘

개발자와

함께일

하게함

2 부팅시

간이2분

이상걸

림

낮음 심각 (낮음,심

각)

8월21일 빌드할

때마다

부팅시간

을모니

터링함

2.4 출시기준정의하기

출시 기준은 완료를 정의합니다([Rot02a]와 [BWe01]). 상관이 출시하라고 지시하거나,

테스터가 출시를 승인하거나 아니면 팀원들이 출시해도 괜찮을 것 같다고 생각할 때 소

프트웨어를 출시하는 관리자도 있습니다. 하지만 프로젝트 관계자마다 완료를 다르게 정

의하는 데 문제가 있습니다.

32 l Manage it

출시 기준은 비난을 서로 떠넘기는 데 사용하는 게 아닙니다. 제품을 출시할 준비가 되

었을 때 출시 기준은 객관적인 측정지표를 제공하죠. 후원자나 고객은 출시 기준 때문에

제품의 품질 그리고 위험과 관련된 비즈니스 결정을 합리적으로 내릴 수 있습니다.

출시 기준을 작성할 때 맨 먼저 프로젝트에서 가장 중요한 것이 무엇인지 결정하세요.

예를 들자면 다음과 같은 질문을 해봅니다. 프로젝트를 수행하려는 이유는 무엇인가요?

고객은 무엇 때문에 제품을 사려고 할까요?

출시 기준 덕분에 여러분은 관련자들이 맡은 역할을 제품에 반영할 수 있습니다. 즉 영

업사원은 출시 기준에 맞는 제품을 판매할 수 있나요? 지원부서에서 제품을 지원할 수

있나요? 교육담당이 교육과정을 개발하고 실행할 수 있나요? 프로젝트의 성공을 정의하

려고 동료들과 작업할 때 동료들은 자신이 맡은 역할에서 책임감을 느끼고 프로젝트가

성공하도록 노력합니다.

일단 프로젝트 성공의 정의를 알게 되면 여러분은 출시 기준, 즉 프로젝트에서 가장 중

요한 것이 무엇인지 정의할 수 있습니다.

다음 절차를 밟아서 출시 기준을 정의하고 활용하세요.

이번 출시에서 무엇이 중요한지 정의하세요. 이렇게 하면 프로젝트 기간에 출시 기1.

준을 모니터링할 수 있습니다.

출시 기준의 초안을 세우세요.2.

출시 기준을 3. SMART 원칙에 따라 작성하세요. 즉 명확하고(Speci�c), 측정 가능

하며(Measurable), 달성할 수 있고(Attainable), 적절하며(Relevant), 추적할 수 있어

야(Trackable) 합니다(36쪽 ‘SMART한 출시 기준 작성하기’ 참조).

팀원들과 상관들에게서 출시 기준에 대한 동의를 이끌어내세요.4.

1. 프로젝트에서 무엇이 중요한지 정의하기

회사에서 필요한 것과 고객이 필요한 것을 조합하는 것은 프로젝트에서 매우 중요한 작업

입니다. 고객은 결함 개수가 적다고 제품을 구매하지 않습니다. 고객은 제품을 활용해서

자신이 해결하고 싶은 문제를 해결할 수 있기 때문에 구매합니다. 출시 기준을 작성할 때

결함과 결함이 얼마나 심각한지 주의해야 하지만, 출시 기준이란 결함 이외의 것을 다룬

02 프로젝트 계획하기 l 33

다는 것을 명심하세요. 고객을 위해 해결해야 하는 문제를 고민하세요. 아울러 이런 고객

이 회사 안에 있는지 밖에 있는지도 고민하세요.

출시일이 가장 중요할 때도 있습니다. 기능 목록이나 특정한 기능이 중요할 때도 있죠.

일정, 기능, 낮은 결함의 조합일 때가 더 흔합니다. 즉, 출시 기준은 여러분의 고객과 고객

이 생각하는 기대에 따라 전적으로 달라집니다(4쪽 견인인자, 제한인자, 변동인자 관리하

기 참조).

리타는 현금 흐름이 매우 중요한 벤처기업에 근무했습니다. 회사는 투자를 충분히 받

지 못했기 때문에 회사를 유지하는 데 필요한 현금 흐름을 충분하게 유지하려면 제품을

일찍 출시하는 게 매우 중요했습니다. 처음 3번 출시할 때 유일한 출시 기준은 고객에게

제품을 출시하는 날짜였는데, 그 이유는 출시를 해야지만 회사가 수익을 얻을 수 있기 때

문이었죠. 회사에서는 경영이 안정화되고 투자를 적당히 받자, 결함 개수, 테스트 진행률,

코드 고정 상태(제품을 출시하기 위해서 개발자가 작업을 중지하는 시점)를 포함하는 다

른 출시 기준을 만들었습니다.

리타는 당시를 이렇게 회상했습니다. “회사를 처음 시작했을 때 생존하려고 어떻게든

출시해야 했습니다. 초기 고객은 우리가 제공하는 제품 가운데 많은 것을 원했지만, 우리

와 기꺼이 함께 작업하길 바랬죠. 하지만 우리는 작년에 한 출시 때문에 큰 타격을 입었습

니다. 고객들은 이전에 기능에만 관심을 보였지만 갑자기 결함에 신경 쓰기 시작했습니

다. 상관은 제가 어떤 형태의 테스트 그룹을 운영했는지 알고 싶어했습니다. 상관의 지시

를 듣고 전 불안했습니다. 하지만 회사 내에서 선택했던 출시 기준이 우리에게 정말로 필

요한 것인지 알아보려고, 팀원들 그리고 상위 관리자들과 함께 출시 기준을 검토했다는

사실이 기억났기 때문에 안정을 찾을 수 있었습니다. 불행하게도 이번 프로젝트에서 요구

사항이 어떻게 되는지 깨닫지 못했지만, 이제는 출시 여부를 평가하려고 출시일이나 결함

혹은 테스트 개수만 사용하지 못한다는 것을 알게 되었죠. 즉 소프트웨어를 출시할 준비

를 끝마쳤을 때를 알려면 더욱 큰 그림이 필요했습니다.

2. 출시 기준의 초안 잡기

출시 기준을 잡는 실마리로서 가상의 출시 기준 몇 개를 잡아보는 작업이 유용합니다(프

로젝트에서 여러분과 함께 일하는 테스트 관리자가 있다면 테스트 관리자와 함께 작업하

34 l Manage it

거나 테스트 관리자에게 가상의 출시 기준을 잡아달라고 부탁할 수 있습니다). 적시에 시

장에 출시하는 것과 고객이 원하는 것 사이에서 균형 잡힌 표현을 반드시 사용하고 아울

러 결함, 성능, 신뢰성이 어느 정도 되는지도 살펴야 합니다. 처음부터 출시 기준을 모두

올바르게 예측하지 않아도 됩니다. 즉 관련자들과 함께 이야기를 시작할 정도면 충분합

니다.

출시 기준의 초안을 잡는다면 출시 기준을 적어놓은 종이 어딘가에 ‘초안’이라는 것을

표시해 두세요. 이런 출시 기준이 누군가와 한 약속이 아니라 논의하는 데 필요한 초안이

라는 사실을 프로젝트 팀원들과 후원자가 알아차려야 합니다.

리타는 프로젝트 관리자, 프로젝트 팀원들과 출시 기준을 이야기하는 시발점으로서

사용하려고 초안 몇 가지를 잡았습니다. 다음은 리타가 만든 초안입니다.

모든 플랫폼에서 전체 코드는 컴파일되고 빌드되어야 한다. ▒

우선순위가 높은 ▒ 버그는 없어야 한다.

해결되지 않은 버그, 버그를 우회하는 방법은 모두 출시 노트에 기록한다. ▒

계획된 테스트는 모두 수행하고, 적어도 98퍼센트 통과되어야 한다. ▒

지난 3주 동안 줄어든 미해결 결함의 개수. ▒

출시하기 전에 개발자가 기능 X에 대한 단위 테스트를 했고, 테스트 그룹에서 시 ▒

스템 테스트를 하고, 고객 A와 B가 확인을 해야 한다.

6월 1일까지 출시할 준비를 마쳐야 한다. ▒

▒ 교차 기능 팀(cross-functional team)이 미해결 결함을 모두 확인해야 한다.

하지만 리타는 프로젝트 관리자와 이야기를 하면서, 자신이 세운 초기 기준이 고객이

나 회사에서 필요한 것과 정확하게 일치하지 않는다는 사실을 깨달았습니다. 그렇습니다,

고객은 결함에 대해 신경을 썼지만, 리타가 고민하는 수준이 아니었습니다. 사실, 주요 고

객 몇 군데서 이번 출시에 만족한다면 다른 고객들도 만족할 가능성이 꽤 컸습니다 .

리타가 고객의 관점에서 출시를 바라보면서 나무랄 데 없이 괜찮은 출시를 하려면 어떻

게 해야 하는지에 대해서도 아이디어를 제안하려고 노력했기 때문에 리타의 프로젝트 관

02 프로젝트 계획하기 l 35

리자는 처음에 당황했습니다. 프로젝트 관리자는 리타가 전통적인 테스트 관리자의 관

점에서 심도 있게 고민하길 바랬습니다. 즉 결함을 낮추는 일 말이죠. 하지만 리타는 다른

프로젝트를 수행한 경험을 통해서 출시 여부를 판단할 때 결함이 적다는 사실이 전부가

아니라는 것을 깨달았습니다.

리타는 프로젝트 관리자, 프로젝트 팀원들과 함께 출시 기준을 수정했습니다.

모든 플랫폼에서 모든 코드는 컴파일되고 빌드되어야 한다. ▒

우선순위가 높은 버그는 없어야 한다. ▒

처리되지 않은 버그의 경우, 버그를 우회하는 방법을 모두 출시 노트에 기록한다. ▒

계획된 테스트는 모두 실행하고, 적어도 90퍼센트 통과되어야 한다. ▒

출시하기 전에 개발자가 기능 X에 대한 단위 테스트를 했고, 테스트 그룹에서 시 ▒

스템 테스트를 하며, 고객 A와 B가 확인을 해야 한다.

6월 1일까지 출시할 준비를 마쳐야 한다. ▒

이런 기준은 리타가 담당하는 출시와 관련된 모든 것을 알려주지 않습니다. 하지만, 이

런 기준에는 이번 출시에서 정말로 중요한 것들이 포함되어 있습니다. 즉 출시일이 언제이

고, 소프트웨어 품질이 우수하며, 고객 회사 2곳에서 특정 기능을 테스트했고 작동하는

것을 확인했습니다. 하지만 리타는 테스트 그룹에서 시행한 테스트 가운데 90퍼센트만

이 통과했다는 사실에 실망했습니다. 90퍼센트 통과라는 낮은 수치로는 위험이 상당히

크다고 생각했기 때문입니다. 하지만 다른 사람들이 말하는 것을 듣고 나서, 출시일이 매

우 중요했기 때문에 테스트를 100퍼센트 통과하지 못해도 괜찮다는 것을 깨달았습니다.

리타는 출시 마지막 단계에 교차 기능 팀이 미해결 결함을 평가하자는 출시 기준을 제거

할 것을 고민했습니다. 하지만, 제품 관리자(product manager)가 리타를 안심시켰습니다.

즉 제품 관리자는 교차 기능 팀이 관여하는 이슈를 프로젝트 관리자와 이야기하고 프로

젝트 관리자가 마케팅과 지원부서 사람들을 만나서 의견을 전달하게 지시하겠다고 말했

기 때문입니다.

36 l Manage it

3. SMART한 출시 기준 작성하기

출시 기준의 초안을 잡을 때 팀원이라면 누구라도 출시 기준을 동일한 형태로 대답할 수

있게 작성하세요. 저는 출시 기준이 합당하고 객관적인지 테스트하도록 SMART의 약어

를 수정했습니다. 즉 명확하고, 측정 가능하며, 달성 가능하고, 적절하며, 추적 가능하다

는 것으로 수정했습니다. 프로젝트 팀원 전체는 ‘추적 가능하다’라는 말 덕분에 출시 기

준을 작성할 때 프로젝트를 진행하면서 출시 기준을 평가할 수 있어야 한다는 사실을 깨

닫습니다.

각 기준은 프로젝트에서 만드는 제품을 명확하게 정의해야 합니다. 여러분이 기준을

측정 가능하게 할 때 이 기준에 따라서 소프트웨어를 평가할 수 있다고 확신해야 합니다.

출시 기준은 도전적인 목표를 적어 놓는 게 아니므로, 기준마다 달성 가능하도록 작성해

야 합니다. 고객과 경영층이 원하는 것을 기준으로 제품을 평가함으로써 기준을 적절하

게 작성해야 합니다. 기준을 추적 가능하게 작성한다면 지난주의 프로젝트 상태만이 아

니라 프로젝트 전반에 걸친 출시 기준의 상태를 평가할 수 있습니다.

“검색은 5초 안에 최초 결과를 반환해야 한다.”라는 기준은 객관적이고 측정 가능합니

다. 이 기준을 테스트할 수 있습니다. “미해결 결함은 모두 교차 기능 팀이 검토한다.”라는

기준은 객관적이고 측정 가능한 기준의 또 다른 예입니다. 교차 기능 팀이 미해결 결함을

검토했거나 검토하지 않기 때문입니다.

‘빠른 성능’은 모호한 기준입니다. 이 기준을 객관적이고 측정 가능한 기준으로 고치려

면, “(유스 케이스 A와 관련된) 성능 시나리오 A는 10초 안에 끝나야 한다.”라는 내용으

로 수정합니다. 특정 시나리오에 이름을 부여하기 때문에 사람들은 시나리오를 참조할

수 있고, 프로젝트 팀이 그 성능을 달성했는지를 판단하는 기준을 제공합니다.

4. 출시 기준에 대한 관련자들의 승인 얻어내기

일단 합리적인 출시 기준을 작성했다면, 여러분이 작성한 출시 기준에서 관련자들의 동의

를 얻어내야 합니다. 사람들이 기준 초안에 대해 부정적으로 반응한다면(“말도 안 돼요.

우리는 출시 기준을 달성할 수 없어요.”), 사람들이 왜 그렇게 생각하는지 알아보세요. 출

시 기준을 작성하면 프로젝트와 제품에 대해 사람들이 품었던 가정과 걱정이 드러납니다.

출시 기준에 대한 동의를 이끌어 내거나 구할 때 다음과 같은 질문을 사용하세요.

02 프로젝트 계획하기 l 37

우리는 출시일 전까지 이 기준을 반드시 달성해야 하나요? ▒

출시일 전까지 이 기준을 달성하지 못한다면 무슨 일이 생길까요? ▒

우리가 이 기준을 달성하지 못해서 회사나 제품을 위험에 노출해야 하나요? 우리 ▒

가 이 기준을 달성하지 못한다면 직원들을 위험에 빠트리나요?

이 질문 덕분에 프로젝트 팀 전체가 현재 출시에서 필요한 작업에 집중할 수 있습니다.

다음에서 설명하는 세 가지 방법을 사용해서 출시 기준에 대한 관련자들의 동의를 얻

어 내세요. 첫 번째 방법은 출시 기준의 초안을 잡고, 이 초안을 두고 의논한 다음, 프로젝

트 팀 회의에서 동의를 구하는 것입니다. 다른 방법은 팀 전체와 함께 기준의 초안을 잡

는 것입니다. 아니면, 매트릭스 조직의 관리자와 프로젝트 팀과 함께 기준의 초안을 잡으

세요. 일단 기준의 초안을 잡았다면 프로젝트 팀 회의에서 출시 기준 초안을 토의 주제로

잡으세요. 저는 프로젝트 팀 전체와 출시 기준을 작성하는 것을 선호합니다. 그렇게 하면

관리자나 제가 출시 기준을 만드는 게 아니라 팀원들이 출시 기준을 작성하고 자신의 것

으로 받아들이기 때문입니다. 하지만 여러분이 규모가 큰 프로젝트에 참여하거나, 이전에

출시 기준을 사용해보지 않았지만 사람들이 스스로 어떤 일을 하는지 이해하길 바란다

면 프로젝트 팀 회의에서 먼저 가상의 출시 기준을 작성해 보세요.

동의를 얻어냈다면 출시 기준을 사용해서 프로젝트를 모니터링할 수 있습니다.

2.5 출시기준사용하기

출시 기준은 달성하거나 달성하지 못합니다. 반쯤 기준을 만족시킬 수 없습니다. 반쯤 달

성하는 것은 실패한 것이죠. 상위 관리자와 소프트웨어의 상태에 대해서 이야기 나눌 때

이런 이진법적인 접근방법은 도움을 많이 줍니다. 상위 관리자와의 회의 자리에서 절반

을 끝냈다고 보고한다면 상위 관리자는 여러분이 끝냈다고 생각합니다. 기준을 달성하지

못했다고 말한다면 상위 관리자는 아직 작업 중이라고 생각하죠.

프로젝트 팀 회의를 하면서 팀원들과 함께 출시 기준의 진척도에 대해 이야기하세요.

이때 프로젝트 대시보드(project dashboard)를 함께 살펴보면(229쪽 11장 ‘프로젝트 대시

보드를 만들고 사용하기’ 참조) 팀원들은 프로젝트 기간에 완료 상태를 평가하게 됩니

38 l Manage it

다. 정식 시스템 테스트 기간이 있다면 테스트 상태 보고서의 일부 항목을 출시 기준으

로 사용하세요.

프로젝트 팀이 약속된 출시를 하지 못할 것을 알려주는 경고 신호로서 출시 기준이 효

과적일 때도 있습니다. 프로젝트 관리자인 메니가 맡은 6개월짜리 프로젝트가 절반 정도

진행되었습니다. 메니는 출시일까지 진척도를 점검해보니 팀이 출시하지 못할 것 같다는

걱정이 들었습니다. 메니는 출시 기준을 프로젝트 팀원과 함께 다시 작성해서 출시 일정

을 현실적으로 조정해야겠다고 결심했습니다.

메니는 프로젝트 팀 회의를 하면서 매주 출시 기준을 사용해서 프로젝트가 제대로 진

행되는지 검증했습니다. 엔지니어 한 명이 이렇게 말하기 전까지 이 방법은 매주 효과적

이었습니다. “출시 기준을 맞추지 못하겠어요. 온 힘을 다했지만 출시 날짜에 맞춰서 출시

기준을 맞추지 못할 거에요.” 메니는 이렇게 말했습니다. “좋아요. 관리자들을 만나서 어

떤 조치를 취해야 하는지 살펴봐야겠네요. 그러기 전에 출시 기준을 달성하는 게 어렵다

고 생각하시는 분이 또 있나요?” 다른 엔지니어가 이렇게 말했습니다. “출시 시점까지 성

능을 맞추지 못할 것 같습니다. 출시 기준을 이야기했을 때 전 성능을 맞출 수 있다고 생

각했는데, 이제야 불가능하다는 것을 깨달았습니다.”

메니는 출시 기준을 활용해서 프로젝트의 진척도의 초기 데이터를 확인할 수 있었습니

다. 메니가 관리하는 팀에서는 프로젝트 끝 무렵이 아니라 70퍼센트가 진행되었을 때 출

시 기준을 맞추지 못할 것을 알아차리고 안심했습니다. PM은 프로젝트 현실을 직시했고

경영층과 공동으로 어떤 절충안이 가장 합리적인지 살펴봤습니다. 메니의 경우, 출시일을

다시 협상해서 제품이 출시 기준을 맞출 수 있었습니다.

모든 게 잘된다면, 프로젝트를 진행하면서 출시 기준을 평가하고, 프로젝트를 끝내기

로 한 시점에 출시 기준을 달성할 겁니다. 하지만 프로젝트가 잘 진행되지 않는다면 출시

기준을 항상 달성할 수 없을 겁니다. 출시 기준을 달성하지 못할 때 그 상황을 솔직하게

받아들여야 합니다.

필요할 때 출시 기준 변경하기

출시 기준 덕분에 완료라는 움직이는 목표가 일으키는 문제를 회피할 수 있습니다. 하지

만, 출시 기준 변경을 고려할 수 있는 상황이 생깁니다. 즉 프로젝트에서 완료라는 것이 무

02 프로젝트 계획하기 l 39

엇을 의미하는지 조금 더 알게 되고 출시일에 맞추어서 출시 기준을 모두 달성할 수 없다

는 것을 깨달았다면 말이죠.

완료가 무엇을 의미하는지 조금 더 알게 되었다면 처음에 출시 기준을 작성하면서 던

졌던 질문을 자신에게 해보세요. 예를 들자면, 이 기준을 만족시켜야 합니까? 이 출시 기

준을 만족시키지 못한다면 무슨 일이 일어날까요?(36쪽 ‘출시 기준에 대한 관련자들의

승인 얻어내기’ 참조)

여러분이 참여하는 프로젝트에서 출시 기준을 달성하지 못한다면 다음처럼 해보세요.

첫째, 그 기준을 왜 달성할 수 없는지 팀원들과 함께 검증하세요. 다음으로, 경영진에게

가서 그 기준을 달성하지 못하는 이유를 설명하세요. 경영진은 팀원들에게 다음처럼 상

황을 설명해야 합니다. “우리는 다른 기준이 중요하다고 생각했죠. 하지만 우리가 생각했

던 것보다 출시일이 더 중요하다는 것을 이제야 깨달았어요. 우리는 제품을 출시할 예정

입니다. 다른 출시 기준을 달성하지 못했더라도요.” 이 이야기가 사실이라면 이렇게 이야

기하세요. “이번 출시를 하면서 출시 기준을 달성하는 것을 방해한 장애물이 무엇이었는

지 알아보겠습니다. 그리고 새로운 프로젝트를 구성해서 출시 기준을 달성하겠습니다.”

여러분이 팀원들에게 이유를 설명하지 않는다면 팀원들은 99쪽 ‘일정을 다시 작성하게!’

에서 이야기하는 일정 게임에 빠졌다고 느낄 겁니다.

☞ 이것만은기억하자!

프로젝트 계획을 수립하는 일은 진행형입니다. 프로젝트 계획하기는 프로젝트를 ▒

시작하는 방법입니다.

프로젝트 팀원, 후원자, 여러분을 위해 완료의 의미를 정의하는 출시 기준을 만드 ▒

세요.

여러분이 작성한 프로젝트 계획은 완벽하지 않아도 됩니다. 있는 것만으로도 충 ▒

분합니다.

40 l Manage it

41

03생애주기를 사용해서 프로젝트 설계하기

여러분은 동창회에 참석하려고 하루짜리 자동차 여행을 떠나려고 합니다. 우선 계획을

세우면서, 지도 위에 목적지를 표시했습니다. 하지만 차에 오르자 친구가 전화를 걸어서

여러분이 지나갈 도로가 유실되어 공사 중이라는 사실을 알려줍니다. 비록 도로가 유실

됐어도 여러분은 저녁 시간에 맞춰 안전하게 목적지에 도착하죠. 다른 경로를 이용했기

때문입니다.

동창회에 가는 길을 선택하는 방법을 생애주기를 선택할 때도 적용할 수 있습니다. 어

떤 생애주기라도 그것을 선택해서 프로젝트에 적용한 순간 완벽하지 않습니다. 생애주기

를 늘리거나 생애주기의 곳곳을 수정할지도 모릅니다. 생애주기란 프로젝트를 구성하는

이상적인 접근방법입니다. 따라서 유독 여러분의 팀에(그리고 프로젝트에) 잘 맞는 생애

주기가 있습니다. 도로가 사라져버렸거나 장애물을 만났을 때 여러분이 선택한 생애주기

는 프로젝트의 진로를 쉽게 변경하게 도와야 합니다.

3.1 프로젝트생애주기이해하기

생애주기는 여러분과 팀원들이 제품 개발과 관련된 작업을(요구사항을 정의하고, 설계,

개발, 테스트하고, 어느 정도로 동시에 진행할지 선택할 때) 구성하는 방법입니다. 여러분

은 게이트(gate)를 사용하는 단계(phase)나 반복주기가 있는 생애주기를 사용할지도 모릅

니다. 형식을 갖춘 설계 단계를 진행하기로 계획하거나 아키텍처와 상위 수준 설계를 점

42 l Manage it

진적으로 개선하도록 선택할 수 있습니다. 프로젝트를 진행하면서 테스트를 통합할 것을

선택했거나 마지막에 전체를 테스트하도록 선택할 수 있습니다. 잠깐 프로토타입을 만들

고 나서 기능을 설계하는 것을 선택하거나, 기능을 구현해서 아키텍처가 어떻게 발전하

는지 살펴볼 수도 있습니다.

프로젝트를 전체적으로 구성할 때 프로젝트의 상황을 이상화하지 마세요. 이전에 수행

한 프로젝트에서 요구사항이 완벽하지 않은 이슈를 경험했다면, 이번 프로젝트에서는 요

구사항을 초기에 완벽하게 정의하려는 식으로 계획을 세우지 마세요. 프로젝트를 진행하

면서 요구사항을 파악하도록 도움을 주는 생애주기를 선택하세요. 실용적으로 행동하세

요. 즉 프로젝트에 있는 위험을 인식하고, 프로젝트에 존재하는 위험을 해결하며 제품을

성공적으로 인도하도록 도와주는 생애주기를 선택하세요.

프로젝트는 요구사항에서 출시까지 한방에 진행되지 않습니다. 프로젝트는 일정대로

진행되지 않는 경향이 있습니다. 여러분은 스테이지-게이트(stage-gate) 1 그리고 폭포수 생

애주기에 가장 익숙할지 모르지만, 이런 방법은 프로젝트를 구성하는 유일한 접근방법이

아닙니다. 프로젝트 계획을 작성하면서 여러분이 선택한 생애주기가 프로젝트에 있는 위

험을 식별해내는지 살펴보세요. 프로젝트 위험과 생애주기가 맞지 않는다면 프로젝트를

생애주기에 맞추려는 노력을 그만두고 다른 생애주기를 선택하세요.

생애주기를 고려하면서 프로젝트 내부에 있는 위험만 고민할 수 없습니다. 고객과 고

객이 품는 기대도 여러분이 고민하는 위험 가운데 하나입니다. 프로젝트를 어떻게 구성

할지 고민하면서 고객에 대해서도 고민해야 합니다. 고객의 니즈는 무엇인가요? 고객이

기대하는 것은 무엇일까요? 고객은 어느 정도로 여러분과 기꺼이 함께 작업하길 원할까

요?(18쪽 ‘프로젝트에서 품질이 뜻하는 바를 파악하라’ 참조)

품질에 대한 견인인자가 하나뿐인 고객을 두고 계획을 세울 수 있다면 기분 좋겠죠. 하

지만 이런 경우는 드물죠. 고객 처지에서 가장 중요한 위험이 무엇인지 알아내야 합니다.

고객에게 가장 중요한 위험이 출시일이나, 결함, 기능, 비용이 되었든 이 위험을 최적화하

는 생애주기를 선택하세요. 그리고 여러분이 프로젝트에서 선택한 실천방법과 팀원들을

활용해서 다른 위험을 관리하세요.

1 　 (옮긴이) 스테이지-게이트 모델은 로버트 쿠퍼(Robert G. Cooper)가 제안한 제품 개발 프로세스로서, 제품 개발을

위한 단계(stage)와 다음 단계로 넘어가기 위해 경영진의 승인을 얻는 게이트(gate)로 구성된다.

03 생애주기를 사용해서 프로젝트 설계하기 l 43

3.2 생애주기개요

생애주기마다 위험을 최적화하는 방법이 다르죠. 대표적인 생애주기는 4가지가 있습니

다. 연속적(serial), 반복적(iterative), 점진적(incremental), 그리고 제가 지금부터 애자일이

라고 부르는 반복적/점진적(iterative/incremental) 생애주기가 있습니다(사실 반복적/점진

적 생애주기를 사용하려고 애자일 선언(Agile Manifesto) 2 에 적힌 애자일 가치를 따르지

않아도 됩니다. 하지만 애자일 가치를 따르지 않는다면 애자일 생애주기를 적용하는 게

불가능하죠). 생애주기마다 프로젝트에 존재하는 위험을 관리하는 방법을 살펴보려면,

그림 3.1을 살펴보세요.

생애주기 종류

생애주기 예제

강점과 성공하는데 필요한 조건 프로젝트 우선순위 성공을 위한 예후

연속적

폭포수, 스테이지-게이트

1. 기능 목록2. 낮은 결함

3. 적시에 출시

피드백이 있다면 성공적이다

반복적

기술적인 위험을 관리한다

요구사항이 항상 변한다

1. 기능 목록

2. 낮은 결함3. 적시에 출시

최종 소프트웨어가계획대로 만들어진다고 가정하면 성공적이다

점진적

디자인-스케줄 (Design to schedule)

일정 위험을 관리한다

작은 요구사항 변경도 받아들일 수 있지만, 아키텍처에 영향을 주는 변경은 받아들이지 못한다

1. 적시에 출시2. 낮은 결함3. 기능 목록

성공적이다

반복적/점진적

(스크럼이나 XP와 같은) 애자일

일정과 기술적인 위험을 동시에 관리한다

같은 공간에서 함께 작업하는 팀이 아니라면잘해내기가 어렵다

1. 적시에 출시2. 기능 집합3. 낮은 결함

성공적이다

혼돈

코딩하고 수정하기 (code and fix)

1. 적시에 출시2. 기능 목록3. 낮은 결함

성공적이지 않다

디자인-스케줄(Design to schedule)*, 단계별 인도

[*주] 디자인-스케줄은 일정이 정해지면 정해진 일정 동안 구현된 부분까지 출시하는 생애주기다.

(경영층이 게이트 절차를 사용한다면) 비용 위험을 관리한다요구사항을 잘 파악하고 합의한다시스템 아키텍처를 깊게 이해한다프로젝트 기간에 요구사항은 안정적이다프로젝트 기간에 프로젝트 팀은 안정적이다

그림 3.1 | 생애주기에서 위험을 관리하는 방법

2 　http://www.agilemanifesto.org 참조

44 l Manage it

생애주기에 익숙하지 않은 경우, 그림 3.2를 살펴보면 서로 다른 생애주기가 어떻게 생

겼는지 알 수 있습니다.

연속적 생애주기에서는 팀이 프로젝트 초기에 요구사항을 전부 받아낼 수 있다고 가정

합니다. 이런 요구사항을 기초로 삼아서 팀은 시스템의 큰 그림을 정하려고 분석과 설계

로 넘어가죠. 관련자들이 큰 그림에 동의하면, 팀은 개발을 시작합니다. 개발을 끝마치고

서 팀은 개발한 것을 모두 통합해서 최종 테스트를 시작합니다. 현실에서 어떤 단계가 끝

나지 않아도 다음 단계를 시작하지만, 연속적 생애주기에서는 한 번에 하나의 단계만 존

재한다는 심리적인 상태가 있습니다.

연속적 생애주기는 오래 걸립니다. 왜냐하면 기능을 구현하거나 결함을 발견해서 수정

하거나 시스템 모듈을 통합하거나 요구사항 변경을 관리하는 데 얼마나 오래 걸릴지 예

상할 수 있다고 가정하기 때문입니다. 하지만 이런 작업은 기간이 얼마나 될지 예측할 수

없습니다. 요술구슬이 없다면 미래에 대해 알아야만 하는 모든 것을 예측하기란 불가능

합니다. 연속적인 생애주기에서는 프로젝트 동안 여러분이 알아낼 수 없던 위험과 문제

를 해결하려면 프로젝트 막판에 최종 시스템 테스트와 같은 시간을 별도로 할애해야 합

니다.

반복적 생애주기에서는 팀원들이 프로토타입을 만들면서 시스템 일부를 살펴볼 수 있

기 때문에 연속적 생애주기에 있는 예측 문제를 관리하려고 합니다. 반복적 생애주기에

서는 각 단계(반복주기)에서 제품 일부를 만듭니다. 대부분의 반복적 생애주기에서는 각

반복주기가 끝날 때 만들던 일부 기능을 완성하지 않아도 괜찮습니다. 반복적 생애주기

에서는 테스트와 통합을 동시에 진행하지 않아도 됩니다(아키텍처 프로토타입을 만든다

면, 기능을 만들고 통합을 시작하기 전까지 미래를 잘 예측할 수 없습니다).

점진적 생애주기를 사용해도 요구사항과 분석 단계는 연속적 생애주기와 비슷하게 진

행되는데, 성공적으로 프로젝트를 진행하는 팀에서 요구사항과 분석 단계에 타임박스를

적용하는 경우에도 연속적 생애주기와 비슷하게 진행됩니다. 점진적 생애주기에서는 요

구사항과 분석을 마치면 기능 구현을 중심으로 팀들을 구성합니다. 팀은 기능 하나를 개

발, 테스트, 통합하고 나서 다른 기능을 만듭니다. 점진적 생애주기를 사용하는 팀에서는

다음 증분으로 넘어가기 전까지 예측할 때 어려움을 겪습니다. 일단 팀이 다음 증분으로

03 생애주기를 사용해서 프로젝트 설계하기 l 45

넘어가면 팀은 기능을 만들면서 얻은 피드백을 사용해서 프로젝트의 진행 방향을 결정

할 수 있습니다.

애자일 생애주기는 반복적 생애주기와 점진적 생애주기를 섞어 놓은 것이지만, 소규모

반복주기와 소규모 증분을 활용합니다. 애자일 생애주기는 조금 계획하고 나서 프로젝트

를 시작합니다. 즉 계획의 수준은 일을 시작하고 아울러 제품 소유자(product owner)가

이번 출시에서 끝내고 싶어하는 것이 무엇인지 알아내는 정도면 충분합니다. 제품 소유자

는 자신이 원하는 기능을 어느 반복주기에 끼워 넣을지 정할 수도 있습니다. 하지만 팀은

출시 계획을 작성하는 데 시간을 많이 쓰지 않습니다. 그 대신에, 프로젝트 팀은 타임박스

를 적용한 반복주기(1주에서 4주 사이)를 계획하는 단계로 넘어갑니다. 팀원들은 타임박

스 기간에 작업하면서 가장 중요한 기능을 먼저 개발하고 나서, 자신들이 얼마나 빨리 작

업할 수 있는지 데이터를 모으고, 문제를 해결하고, 요구사항을 이해하는 등의 작업을 합

니다. 프로젝트를 진행하면서, 팀에서는 제품 소유자에게 기능이 제대로 갖춰졌는지 올바

르게 동작하는지 피드백을 요청합니다. 팀은 변하는 환경과 팀의 속도를 기초로 다음 반

연속적 요구사항 분석 설계 코딩 통합 테스트

반복적 요구사항프로토타입:분석, 설계, 코딩

프로토타입:분석, 설계, 코딩

프로토타입:분석, 설계, 코딩

통합 테스트

점진적약간의요구사항

전체적인 아키텍처를 선택하기 위한 분석

설계, 코딩, 통합& 테스트

설계, 코딩, 통합 & 테스트

설계, 코딩, 통합 & 테스트

설계, 코딩, 통합 & 테스트

최종 통합

최종테스트

애자일

요구사항 일부/계획하기 게임

타임박스 타임박스타임박스타임박스타임박스필요한 만큼 반복

각 타임박스가 끝나면 테스된 기능들이 작동한다

그림 3.2 | 간트 차트처럼 표현한 생애주기

46 l Manage it

복주기를 다시 계획합니다. 팀은 능동적으로 자신들이 수행한 작업과 작업 프로세스에

대한 피드백을 구하기 때문에, 애자일 생애주기에서는 프로젝트 상태에 대한 피드백, 개

발 속도, 결함을 발견하고 수정하는 속도, 팀에서 내리는 가정을 생애주기 일부로서 인정

합니다.

프로젝트 팀에서 기능 단위로 개발하고 테스트하며 통합하는 것을 능동적으로 계획하

지 않는다면(동시 공학이나 애자일에서 작업하는 방법을 따르지 않는다면요), 팀원들은

그림 3.4처럼 설계-코딩-테스트-디버그 루프(loop)를 사용합니다. 우선 개발자는 제품을

코딩하고 수정하기는 결코 효과적이지 않다!

절대로 ‘코딩하고 수정하기’는 생애주기로 선택하지 마세요. 프로젝트가 망하는 한이

있어도 절대로 안 됩니다! 선의의 사람들이 ‘코딩하고 수정하기’ 생애주기를 사용해서

프로젝트를 시작하는데, 이 사람들은 플래닝 게임(planning game)을 해보거나, 팀

에서 무엇을 만들 수 있는지 알아보려고 프로토타입을 만들어 보거나, 요구사항을 조

금 모아보는 것보다 ‘코딩하고 수정하기’가 훨씬 빠르다고 생각하기 때문입니다. 그

러나 현실은 그렇지 않습니다. 어떤 생애주기를 선택하든지, 프로젝트 초기에 반드시

조금이라도 계획을 세워야 합니다. 만화 딜버트에서는 ‘코딩하고 수정하기’ 생애주기

를 다음처럼 깔끔하게 정리했습니다. 딜버트 만화에 나오는 머리가 뾰족한 상관은 만

화에서 이렇게 말했습니다. “어이, 일단 코딩부터 시작해, 그러면 요구사항을 넘겨 줄

게.” 여러분은 프로젝트를 시작하기 위해 전체 요구사항을 알 필요는 없습니다. 고객

과 함께 작업해서 기능 단위로 구현하고, 반복주기에 타임박스를 적용하고, 고객이 원

하는 것을 개발하는지 확인하세요. 고객이 없어도 개발을 시작할 수 있거나, 계획을

세우지 않고도 프로젝트를 시작할 수 있다고 착각하지 마세요. 물론 이렇게 프로젝트

를 시작할 수도 있지만, 프로젝트가 성공하기는 쉽지 않을 겁니다.

우리가 아는 것을 프로토타입으로 만들기. 피드백 받기. 아키텍처 선택하기.

요구사항에 대한 첫 번째 단계

기능 3개를 완전히 구현하고, 진행하면서 통합하기

아키텍처 테스트하기. 개발한 것 데모하기.

진행하면서 계속해서 구현하고 통합하기.

최종 테스트 하기

그림 3.3 | 반복적 그리고 점진적 생애주기를 결합한 모습

03 생애주기를 사용해서 프로젝트 설계하기 l 47

설계하고 나서 코딩하고, 코드를 테스트하며, 디버깅합니다. 이런 작업은 몇 주 혹은 몇 달

이나 걸릴 수 있습니다. 동일한 제품에서 개발자 여러 명이 작업하게 한다면, 코드를 통합

해서 테스트하기 전까지 얼마나 오래 걸릴 수 있는지 알 수 있습니다.

생애주기는 프로젝트를 구성하는 이상적인 접근 방법입니다. 하지만 생애주기를 선택

했다고 이 생애주기를 맹목적으로 따라야 한다는 것을 뜻하지 않습니다. 프로젝트에 있

는 위험을 처리하려고 다른 생애주기의 부분을 활용할 수 있습니다.

예를 들어 프로젝트를 시작하면서 아키텍처를 선택해야 하는 위험을 늘 관리해야 하

고, 전체 요구사항을 알지 못한다는 점을 파악하고 있을 때 (그리고 프로젝트에서 애자일

생애주기를 사용할 수 없다면), 그림 3.3처럼 생애주기를 혼용해서 사용하는 게 도움이

될 수도 있습니다. 이렇게 두 가지 생애주기를 같이 사용하면 프로젝트에서는 반복주기

를 사용해서 간단한 프로토타입을 만들어 볼 수 있습니다. 팀원들이 요구사항을 조금 더

파악하면, 프로젝트를 진행하면서 점진적으로 개발, 테스트, 통합합니다.

그림 3.3에서는 몇 가지 생애주기를 조합해 놓았는데, 이 조합된 생애주기에서는 반복

적 생애주기의 일부(프로토타이핑), 점진적 생애주기의 일부(기능 세 개를 완전히 구현하

고 나서 개발하는 것), 애자일 커뮤니티에서 나온 몇 가지 아이디어(요구사항에 대한 초

기 단계를 수행하고 프로젝트를 진행하면서 요구사항을 반복), 그리고 프로젝트가 끝날

때 위험을 관리하려고 최종 테스트를 사용합니다.

설 계

코딩

테스트

디버깅

그림 3.4 | 설계-코딩-테스트-디버깅 루프

48 l Manage it

3.3 프로젝트에서피드백받아보기

개발자가 자신이 짠 코드를 테스트할 때 처음으로 피드백을 받습니다. 그래서 프로젝트

동안 테스트를 하지 않는다면 코드에 대한 피드백은 프로젝트 끝에서나 얻게 됩니다.

개발자가 피드백을 받지 못한다면 남아 있는 프로젝트 위험을 쉽게 평가할 수 없고, 프

로젝트의 상태나 팀원들이 실제로 사용할 수 있는 소프트웨어를 얼마나 재빨리 만들 수

있을지 평가할 수 없습니다. 작업이 실제로 완료되었는지도 알 수 없습니다. 연속적 생애

주기가 미래를 예상하는 방식의 생애주기이기 때문에 이처럼 피드백이 부족합니다. 현재

작업을 기초로 앞으로의 작업을 완료할 수 있을지 검토하는 경우 데이터가 충분하지도

않은 채, 연속적 생애주기는 미래를 예측합니다. 프로젝트 초기에 팀원들이 제품에서 얻

는 피드백은 어떤 식으로든 예측을 쉽게 하도록 도와줍니다(제품에 대한 설명은 도움이

되지만, 제품 설명은 피드백에 포함되지 않습니다).

애자일 생애주기를 간트 차트와 비슷하게 나타낸 그림을 보면 애자일 생애주기에서 제

공하는 피드백 루프를 볼 수 없습니다. 각 타임박스 동안에는 피드백 루프가 두 가지씩 있

습니다. 지속적인 피드백은 그림 3.5와 같습니다. 개발자가 코딩하면서 테스트를 하기 때

문에 피드백은 즉각적입니다. 날마다 받는 피드백 혹은 반복주기 기반의 피드백은 그림

3.6과 같습니다. 개발자나 프로젝트 관리자에게 들어가는 지속적인 피드백은 애자일 생

애주기의 작동방식을 보여주는 핵심입니다.

기능을 시작함

테스트

코딩

리팩터링

(적어도 하루에 한번) 빌드

그림3.5 | 테스트-코딩-리팩터링 루프

03 생애주기를 사용해서 프로젝트 설계하기 l 49

3.4 대규모프로젝트에서는다양한방식으로생애주기를조합할수있다.

어떤 생애주기도 모든 사람의 니즈를 만족하게 하지 못합니다. 규모가 큰 프로젝트나 멀

티사이트 프로젝트에서는 팀마다 서로 다른 생애주기를 사용하는 것을 볼 수도 있습니

다(265쪽 12장 ‘멀티사이트 프로젝트 관리하기’ 참조). 60명의 개발자와 테스터 20명으로

구성된 프로젝트에서 사용하는 생애주기는 다음 페이지 그림 3.7과 같았습니다.

개발자들은 점진적 생애주기를 사용했습니다. 테스터들은 반복적 생애주기를 이용했

죠. 테스터는 시스템의 상태를 평가하려고 너비 우선(breadth �rst) 방식으로 작업했기 때

문에 반복적 생애주기를 사용해서 테스트를 만들었습니다. 개발자는 기능 개발을 끝내

고, 프로젝트를 진행하면서 경영층이 출시일을 앞당기라고 지시할 경우 각 기능을 통합

했습니다.

출시

타임박스가 끝날 때마다 시스템 데모

(적어도 날마다) 빌드

그림 3.6 | 애자일 생애주기가 피드백과 결합하는 방법을 보여줌

50 l Manage it

저는 생애주기를 조합해서 사용하는 멀티사이트 프로젝트도 봤습니다. 이런 경우가 있

었죠. 한 사이트에 있는 개발자는 점진적인 프로토타이핑(evolutionary prototyping)을 사

용했지만, 다른 사이트에 있는 개발자는 단계별 인도(staged delivery)를 사용했습니다. 프

로젝트 팀원들은 초기에 그리고 프로젝트 기간에 분기마다 산출물이 무엇이고 산출물의

기준이 무엇인지 합의를 봤습니다.

세 나라에서 참여한 프로젝트도 있었습니다. 첫 번째 사이트에 있는 개발자는 2주 단

위의 반복주기를 사용했으며, 두 번째 사이트에 있는 개발자는 단계별 인도를 사용했고,

세 번째 사이트에 있는 개발자는 4주 단위의 반복주기를 사용했습니다. 프로젝트 팀원들

도 프로젝트 초반과 월마다 산출물과 기준을 정의했습니다. 멀티사이트 프로젝트에서 핵

심은 무엇을 인도할지 그리고 언제 이런 것들이 필요할지 정의하는 것입니다(272쪽 ‘팀 단

위로 서로 보완하는 실천방법을 사용하세요’ 참조).

개발자 생애주기 (단계별 인도)

테스터 생애주기는 디자인-스케줄

(Design to Schedule)과 유사함

요구사항을 최초로 정의하기

아키텍처 프로토타입을 만들고

제품 아키텍처를 선택하기

설계, 코딩, 통합하고, 기능 A, B, C 테스트하기, 적절한 스모크 테스트 추가하기

설계, 코딩, 통합하고, 기능 D, E, F, G, H 테스트하기

최종 통합

최종 테스트

설계, 코딩, 통합, 테스트하기(스모크 테스트 추가하는 것을 포함)를 반복함

테스트아키텍처 선택하기

전체 제품에 대해서 스모크 테스트 개발하기

출시 기준을 검증하기 위해 시스템 테스트 실시

기능 A, B, C를 깊이 있게 테스트하려는 목적으로 시스템 테스트 진행하기

상세한 시스템 테스트를 추가하는 것을 반복. 출시 기준을 검증하기 위해서 더 많은 테스트 추가하기

그림 3.7 | 대규모 프로젝트의 생애주기: 생애주기를 조합함

03 생애주기를 사용해서 프로젝트 설계하기 l 51

하드웨어를 포함하는 프로젝트

여러분이 맡은 프로젝트에서 새로운 종류의 칩이나 보드(새로운 제품 개발)를 만든다면,

하드웨어 팀에서 할당된 시간 안에 끝낼 수 없을지도 모르는 야심만만한 요구사항이 몇

가지 있을 겁니다. 하드웨어 팀이 제작에 착수해서 하드웨어에서 가능한 것과 소프트웨

어가 처리해야 할 게 뭔지 알아낼 때까지 여러분은 기다려야 할 것입니다. 소프트웨어 업

데이트를 사용해서 소프트웨어에 있는 작은 문제를 수정할 수 있는 경우가 흔하죠. 하드

웨어는 이런 사치를 누르지 못하기 때문에, 시간과 비용 측면에서 제약이 다를지도 모르

고 하드웨어를 인도하고 나서 하드웨어를 수정할 때 들어가는 비용 때문에 소프트웨어

가 하드웨어의 일정을 보충해야 할지도 모릅니다. 단계별 인도나 애자일 생애주기를 적용

하고 스텁(stub)을 사용하면서 하드웨어 팀의 결과를 기다리는 동안 기능단위로 구현할

수 있습니다. 하드웨어에서 가능한 것과 불가능한 것을 파악하면 지금까지 사용했던 스

텁 가운데 일부를 하드웨어/드라이버 호출이나 소프트웨어로 바꾸어야 할지도 모릅니

다. 여러분은 하드웨어가 완료될 때까지 기다리지 않지만, 낮은 수준의 기능 가운데 어떤

기능이 어디에 구현될지 파악할 정도로 하드웨어가 완성될 때까지는 프로젝트에 ‘순차성

(serialness)’이 존재할 것입니다. 하드웨어와 소프트웨어가 성공적으로 조합해야 하는 프

로젝트에서는 생애주기를 조합하는 작업이 필요합니다.

펌웨어를 상황에 따라 소프트웨어나 하드웨어로 다룰 수 있습니다. 펌웨어를 시스템

외부에서 삽입하거나/다운로드하는 것으로 만든다면 펌웨어를 소프트웨어로서 다룰 수

있을 것입니다. 시스템에 삽입하는 형태로 펌웨어를 만들어 펌웨어를 쉽게 바꾸지 못한

다면 펌웨어를 하드웨어로 다루는 셈입니다.

업체에서 제공하는 컴포넌트를 포함하는 시스템을 통합한다면, 프로젝트를 진행하면

서 위험을 관리하는 일반적인 방법과 생애주기를 조합하는 것이 무척 필요합니다. 예를

들어서 여러분은 온라인으로 식료품을 주문하고 쉽게 상하는 식품 상태를 평가하는 최

신형 냉장고를 만들고 싶습니다.

신선우유 분석회사에서 우유 분석기를 구입하고, 생생쇠고기 회사에서 고기 분석기

를, 싱싱채소 회사에서 채소 분석기를 구입합니다. 등급이 낮은 냉장고에는 우유 분석기

만을 장착합니다. 그리고 등급이 높은 냉장고에는 고기와 야채 분석기도 장착합니다. 서

52 l Manage it

로 다른 등급의 냉장고를 제작하기 위해, 여러분은 프로그램 안에 다른 프로젝트들을 운

영합니다.

업체에서 부품을 받을 날짜를 합의하거나 생애주기를 고민하기 전에 업체에서 받는 중

간 산출물이 무엇일지 협상하세요. 다양한 업체에서 얻은 부품으로 시스템 통합을 하는

것은 상당히 위험합니다. 단순히 생애주기를 선택하는 것만으로 위험을 관리하지 못합니

다. 즉 프로젝트를 진행하면서 어떻게 통합할지 계획을 세워야 합니다. 분석기 업체가 매

월 출시해야 한다면(업체에서 제공한 부품으로 고객에게 새로운 제품을 출시할 수 없어

도), 위험을 관리하기 위해 반복주기와 애자일 접근방법을 쉽게 사용할 수 있습니다.

여러분이 시스템을 통합하는 프로젝트를 관리하고 회사에서 업체와 중간 산출물이 무

엇인지 협상하지 않았다는 것을 파악했다면, 당장 중간 산출물이 무엇인지 협상할 수 있

습니다. 하지만 업체에서 중간 산출물에 대한 합의 이끌어내지 못해도, 여전히 프로젝트

에서 점진적이고 반복적인 접근 방법을 사용할 수 있습니다.

통합할 때 까다로운 부분을 관리하려면 375쪽 그림 A.6과 같은 타임박스를 적용한 반

복주기(위험을 관리하는 최선의 방법)나 373쪽 그림 A.5와 같은 점진적 생애주기를 사용

해서 점진적으로 구축하는 방법을 전 강력하게 추천합니다. 연속적 생애주기는 사용하

지 마세요. 프로젝트를 진행하면서 기술 빚을 확인하지 못하기 때문입니다. 연속적 생애

주기를 사용한다면 프로젝트 끝 무렵에서야 문제를 확인할 수 있습니다.

3.5 아키텍처위험관리하기

어떤 생애주기를 사용해도 제품 아키텍처에 있는 위험을 완벽하게 알려주지 못합니다.

즉 프로젝트 팀에서 선택한 아키텍처가 프로젝트 니즈에 적당할 것이라고 가정했기 때문

에 이런 위험이 생기죠. 아키텍처를 대표하는 코드를 작성하고 통합하기 전까지 아키텍

처가 작동할지 확인하는 것은 불가능합니다. 연속적 생애주기를 사용하면 아키텍처 위

험을 파악할 수 있다는 확신 때문에 연속적(폭포수 혹은 단계-게이트) 생애주기를 선택

하는 팀원들과 일을 많이 해봤습니다. 하지만 불행하게도 팀원들이 생각한 것만큼 효과

적이지 못했죠. 폭포수 생애주기에서는 최종 통합과 테스트를 프로젝트 끝에서 수행하기

03 생애주기를 사용해서 프로젝트 설계하기 l 53

때문에 아키텍처 위험을 관리하려고 폭포수 혹은 단계-게이트 생애주기를 사용하는 것

은 상당히 위험한 일입니다.

프로젝트 초기에 아키텍처 위험을 정말로 파악하고 싶지만, 연속적 생애주기를 사용해

야 한다면 선택사항이 몇 가지 있습니다.

가능하다면 프로젝트 초기에 ‘최종’ 아키텍처에 근접한 프로토타입을 반복해서 ▒

만들어 봅니다. 여기에는 프로토타입을 테스트하는 작업도 포함합니다(나선형 생

애주기에서처럼). 재빨리 대충 만들어보는 프로토타입만을 사용한다면 제안한

아키텍처의 성능과 신뢰성이 충분한지 알지 못하죠.

전체 아키텍처를 파악하는 작업에 타임박스를 적용하세요. 적어도 아키텍처에 대 ▒

한 선택사항 3가지를 마련하도록 개발자에게 도전목표를 제시하세요. 그리고 팀

원들이 각 선택사항이 어떻게 작동하고 각 선택사항에 어떤 위험이 여전히 존재

하는지 프로젝트 관리자인 여러분에게 알려주게 하세요.

아키텍처 위험을 실제로 관리하는 유일한 방법은 무언가를 구현하고 테스트해 보는 것

입니다. 마이크로소프트 파워포인트 아키텍처[SH06b](파워포인트에서만 구현됩니다)는

호감만을 심어주는 겉치레일 뿐 이 아키텍처에 시간을 쏟을 가치가 없습니다.

프로젝트를 시작하기 전이나 아키텍처를 검토하지 않으면 발생할 위험이 지나치게 크

기 때문에 후원자, 관리자들, PMO 3 가 아키텍처(아키텍처의 그림)를 훑어보고 싶어하는

회사에서 여러분은 근무할 수도 있습니다. 이런 경우에도, 기능 몇 가지에 대해 프로토타

입을 완전하게 끝낼 것을 추천합니다. 이렇게 하면 프로젝트의 행운을 아키텍처에 걸기

전에 아키텍처를 사용하면서 경험을 얻기 때문이죠.

프로젝트를 진행하면서 아키텍처가 프로젝트의 니즈를 달성하지 못하는 위험에 대처

해야 합니다. 즉 3프로젝트가 끝날 시점이 아닌 시작 시점에 이 작업을 수행하길 바랍니

다. 이 작업을 하지 않는다면 프로젝트 전체를 늪에 빠트릴 수 있습니다.

3 　 (옮긴이) PMO(Project Management Officer)는 PM과 별도로 회사차원에 프로젝트를 관리하는 조직.

54 l Manage it

3.6 폭포수생애주기를유용하게하는방법

연속적 생애주기를 따라야 한다면 연속적 생애주기를 폭포수 형태와 다르게 만들고 더

욱 유연하게 하는 방법을 소개하겠습니다. 이렇게 하면 여러분은 현실에 적응할 수 있습

니다.

계획 작성하기, 요구사항, 프로토타이핑을 포함한 모든 것을 반복하도록 계획하 ▒

세요.

여러분의 능력이 되는 한 프로젝트를 시작할 때 가능한 많은 것을 고객이나 고객 ▒

대리인에게 보여주거나 프로토타입을 만들어서 보여주세요. 고객이나 고객 대리

인에게서 피드백을 많이 받는다면 프로젝트의 상태가 더 좋아집니다.

프로젝트를 시작하면서 테스트를 시작하세요. 시스템 전체를 사용하기 전부터 피 ▒

드백을 얻기 위해서 테스터와 함께 작업하세요.

프로젝트를 진행하면서 기능 단위로 구현하고, 통합하고 테스트하세요. ▒

문서를 반드시 고객에게 인도해야 한다면(문서 인도는 연속적 생애주기의 각 단계 ▒

마지막에 있는 전형적인 마일스톤입니다), 문서만이 고객에게 인도해야 하는 유일

한 산출물이 되지 않게 하세요. 고객과 함께 프로토타입을 살펴보고 고객에게 작

동하는 제품을 넘겨주면, 팀원들은 유용한 피드백을 얻을 겁니다.

이런 접근 방법은 전통적인 형태의 연속적 접근 방법이 아닙니다. 하지만 효과적입니다.

후원자에게 프로젝트를 관리하는 방법을 속이지 마세요. 다양한 위험을 관리한다고 후

원자에게 알려주세요. 여러분은 프로젝트 내부 사정을 소시지 제조업자처럼 다룰 수 있

습니다. 프로젝트의 내부 사정을 끔찍할 정도로 자세하게 알려주지 않아도 됩니다. 소시

지 제조업자는 소시지 제조법을 여러분에게 알려주지 않죠.

03 생애주기를 사용해서 프로젝트 설계하기 l 55

3.7 내가가장좋아하는생애주기

저는 가능하다면 프로젝트 초기에 기능들을 코드로 구현하는 것을 선호합니다. 제 경험

에서 볼 때, 프로젝트 팀원들이 기능 몇 가지를 구현하고 테스트하고 나서 통합하지 않으

면 명확한 아키텍처를 설계하는 게 어렵습니다. 저는 스크럼(Scrum)이 제공하는 가시성,

검사, 적응이라는 장점을 활용하려고, 아키텍처를 개선하고 기능을 인도하는 데 프로젝

트 관리 프레임워크로서 스크럼[Sch04]을 사용하는 것을 좋아합니다. 가능하다면 저는

스크럼에 익스트림 프로그래밍(eXtreme Programming, XP : [BF01]과 [JAH02]을 참조

하세요) 실천방법을 추가하거나, 단계적 인도와 같은 점진적 생애주기를 사용해서 기능

을 인도하거나 아키텍처를 평가합니다.

팀원들이 애자일 프로젝트에서 요구하는 방식으로 협업 4 할 수 있고 이런 방식으로 협

업하는 데 관심이 있다면 저는 애자일 생애주기를 우선 선택합니다. 하지만 팀원들이 고

객에게서 충분한 관심을 이끌어내지 못하거나 애자일 프로젝트에서 요구하는 방식으로

협업하는 데 흥미가 없다면 저는 단계별로 인도하는 생애주기를 선택하는 편이고, 요구사

항과 아키텍처 단계에 타임박스를 적용합니다(고객이 충분히 참여하지 않는다면 어떤 프

로젝트라도 어려움을 겪게 됩니다. 애자일 생애주기를 사용하면 다른 생애주기를 사용하

는 것보다 프로젝트 초기에 문제가 드러나게 하죠).

프로젝트의 기간이 짧고 간단하더라도, 저는 폭포수 생애주기를 거의 사용하지 않습

니다. 나선형 생애주기를 사용한다면 저는 팀원들이 단계별로 산출물을 인도하는 방식

으로 일하도록 격려하는데, 이렇게 하면 저는 반쯤 완성된 기능을 얻는 대신 일을 끝마칠

수 있죠.

4 　 http://www.stsc.hill.af.mil/crosstalk/2007/04/0704Derby.html와 http://alistair.cockburn.us/index.php/Agile_

software_development:_the_people_factor 참고.

56 l Manage it

☞ 이것만은기억하자!

프로젝트가 성공하기 위해서 생애주기 몇 가지를 조합하거나 생애주기 한 가지를 ▒

사용해서 프로젝트를 설계하세요.

프로젝트 현실을 반영하기 위해서 프로젝트에 적당한 생애주기를 만드는 것을 두 ▒

려워하지 마세요. ‘완벽한’ 생애주기는 하나의 모델입니다. 그 반면에 여러분은 진

짜 세상에 살고 있죠.

스테이지-게이트나 폭포수 생애주기로 성공할 수 있다고 생각할 때만 이 생애주기 ▒

를 사용하세요. 아무 생각 없이 이런 생애주기를 선택하지 마세요.

57

04프로젝트 일정잡기

계획하기(planning)와 일정잡기(scheduling)는 서로 다른 활동입니다. 21쪽 2장 ‘프로젝트

계획하기’에서, 프로젝트 계획을 수립하기 시작했죠. 이번 장에서는 일정을 수립하는 방

법과 프로젝트에서 예측(estimation)하는 방법을 배울 겁니다. 일정을 작성하면서(그리고

작업량을 다시 예측할 때), 앞서 세운 계획을 수정할 수도 있습니다. 계획을 변경해도 괜

찮습니다. 처음에 세운 계획은 프로젝트를 시작할 정도면 충분했기 때문입니다. 일정을

세우면서(그리고 일정을 다시 잡으면서) 계획을 상세하게 세울 것을 예상하세요. 아울러

계획을 다시 세우면서 일정을 다듬는 것에 부담을 느끼지 마세요.

4.1 프로젝트일정을수립하는실용적인접근방법

프로젝트를 시작할 수 있을 정도로 이미 계획을 세웠습니다. 이제는 프로젝트를 시작할

수 있는 수준으로 일정을 잡아야 합니다. 프로젝트의 상황이 시시각각으로 변한다는 것

을 파악했다면 전체 프로젝트의 일정을 잡을 이유는 없습니다. 따라서 계약서에 서명하

기 전에 프로젝트 일정을 보고 싶어하는 고객과 일한다면 처음에 수립하는 일정은 최선

을 다해 내놓은 예측치라는 사실을 정확하게 알려 주세요. 이 일정은 변할 겁니다. 아울

러 고객에게 81쪽 팁 ‘예측에서 필요한 것은 정밀함(precision)이 아니라 정확함(accuracy)

이다’에서 다룬 정확도와 정밀도의 개념을 설명하세요.

58 l Manage it

몇 년 전에 저는 회의석상에서 프로젝트 관리자와 이야기했습니다. 저는 프로젝트 일

정을 잡는 데 반나절에서 이틀 정도가 걸린다고 말했습니다. 그리고 이틀을 반나절로 줄

이고 싶다고 말했죠

제 이야기를 들은 프로젝트 관리자가 입을 다물지 못하더군요. 프로젝트 관리자는 제

가 반나절 만에 프로젝트 일정을 잡을 수 있다고 말한 것을 전혀 믿지 못했습니다. 저는

모든 것에 대한 일정을 잡으려고 시도하지 않는다고 설명했습니다. 단지 프로젝트를 시작

하고 나서 몇 주 정도의 일정을 잡는다고 말했습니다. 그러고 나서 저는 주요한 마일스톤

을 수립하고 몇 주간의 연동 계획(380쪽 용어 정리 참조)을 세운다고 알려줬습니다.

“프로젝트 완료일을 어떻게 알죠?” 프로젝트 관리자 물었습니다.

“ 잘 모르겠지만 데이터도 없이 프로젝트 초기에 완료일이 언제일지 알아내려고 앞으로

할 일들을 애써서 계획하려고 시도한다면 아마도 틀릴 겁니다. 자신이 틀릴 것을 뻔히

아는데 상세하게 일정을 세우는 데 시간을 왜 들여야 하죠?”

프로젝트 관리자가 말했습니다. “그렇군요. 그런 식으로 생각해 본 적이 없네요.”

프로젝트 일정을 세우는 방법은 다양합니다. 저는 하향식으로 생각하죠. 즉 프로젝트

계획의 초안을 먼저 세우는데, 이렇게 하면 일정을 수립할 때 도움을 얻습니다. 다른 프로

젝트 관리자는 일정의 초안을 잡는 일부터 시작하죠. 여러분에게 가장 편안하고 프로젝

트에 적당한 방법을 선택하세요. 하지만 계획, 일정, 어느 하나도 소홀하게 다루어서는 안

됩니다. 모든 프로젝트에서는 두 가지가 필요합니다.

프로젝트에서는 계획과 일정이 필요하다

실용적인 프로젝트 관리자인 여러분이 맡은 임무는 프로젝트를 시작할 정도로 계획을

세우고 나서, 프로젝트를 수행하면서 계획을 지속적으로 세우고 수정하는 것입니다.

여러분이 무엇을 하든지, 계획이나(특히 출시 기준) 일정을 무시해서는 안 됩니다. 일

정을 수립할 때 멋진 간트 차트가 필요하지 않습니다. 많은 프로젝트에서는 벽에 붙이

는 노란색 포스트잇이면 충분합니다. 물론 포스트잇을 활용해도 계획과 일정이 모두

필요합니다.

04 프로젝트 일정잡기 l 59

여러분이 세운 일정은 여러분이 선택한 생애주기와 유사한 점이 있을 겁니다. 하지만

생애주기란 프로젝트가 어떤 식으로 표현되는지 보여주는 모델이라는 점을 명심하세요.

일정을 수립할 시점이 되면, 생애주기를 지침으로써 사용하고 생애주기에 내재한 위험을

반드시 밝혀 두세요. 단계-게이트를 사용하는 프로젝트의 일정에 타임박스를 적용한 반

복주기와 증분을 추가할 수 있는데(아울러 계획을 수립하는 작업과 계획을 수정하는 작

업도 추가할 수 있습니다), 단계-게이트를 사용하는 프로젝트에서 이런 활동을 하지 않

지만, 특정 프로젝트에서는 이런 활동이 의미가 있기 때문입니다. 생애주기는 제한조건이

아니라 지침이라는 점을 명심하세요.

일정잡기와 예측은 서로 다른 활동입니다. 일정잡기는 작업에 순서를 부여하고 작업

사이에 독립성을 보여주는 일이죠. 예측은 특정 작업을 처리하는 데 시간이 얼마나 걸릴

지 추측하는 것입니다. 일정잡기와 예측은 서로 연관되어 있습니다. 일정을 잡는 방법은

주어진 작업을 수행하는 시간과 그 작업에 필요한 사람을 예측하는 것에 의존하기 때문

입니다.

전 마술 지팡이를 흔들면서 이렇게 말할 수 있기를 바랍니다. “프로젝트를 예측하고 일

정을 수립하는 방법은 단 한 가지뿐이다!” 하지만 저는 이렇게 말할 수 없습니다. 일반적

으로 우리는 경험하지 못했던 것을 예측해야 하기 때문입니다.

미지의 것을 예측하는 일은 아직 일종의 기술이죠. 반면에 여러분이 사용할 생애주기

를 잘 파악했다면 일정을 세우는 일은 더욱 쉬워집니다.

초기 계획하기에 타임박스 적용하기

프로젝트 초기에 계획을 세울 때 가능한 시간을 적게 들이세요. 특히 팀원들이 프로젝

트에 이미 할당된 상태라면 말이죠. 팀원들이 프로젝트를 시작할 정도로 계획을 작성

하는 데 시간을 할애하세요. 프로젝트 헌장을 작성할 때 1시간의 타임박스를 적용하

세요. 프로젝트 계획을 세우는 데도 1시간의 타임박스를 사용하세요. 아울러 일정 초

안을 잡을 때에도 1시간의 타임박스를 적용하세요. 팀원들은 타임박스를 적용한 덕분

에 시작하는 데 꼭 필요한 몇 가지에 집중할 수 있습니다. 일단 팀원들이 다음 1-2주

동안 자신들이 할 일을 알고 나면 여러분은 계획과 일정을 다시 살펴보면서 여러분이

덧붙여 작성할 게 있는지 살펴볼 수 있습니다.

60 l Manage it

4.2 일정잡기방법선택하기

저는 프로젝트의 일정을 잡을 때 다음의 방법 중에서 하나를 사용합니다. 제가 선택하는

방법으로는 하향식, 상향식, 인사이드 아웃(inside out), 허드슨 만 시작(Hudson Bay Start),

짧은 반복주기(short iteration)가 있습니다.

하향식 일정잡기

하향식 일정잡기는 일반적으로 마일스톤에서 시작합니다. 연속적 생애주기에서는 하향

식 일정잡기로 시작하는 경향이 있습니다. 단계가 매우 명확하기 때문입니다(힌트: 연속

적 생애주기를 반드시 사용해야 한다면, 70쪽 ‘산출물 기준으로 계획하기’에 다루었듯이

마일스톤을 작성하기 위해서 산출물을 기반으로 계획을 작성하는 방법을 사용해야 합니

다).

프로젝트 일정을 단계나, 반복주기 혹은 단위로 묶어서 구성하세요. 벽에 포스트잇을

붙이거나 화이트보드에 프로젝트 일정을 배치하세요. 드웨인 필립스(Dwayne Phillips)는

사무용품을 활용한 일정잡기 기술로서 카드를 벽에 붙이는 방법을 추천했습니다. 카드

를 벽에 붙이는 방법을 사용해서 일정을 작성할 때 팀원들은 자신이 처리해야 한다고 생

각하는 작업을 카드에 기록합니다. 그러고 나서 선을 그어서 카드를 연결합니다[Phi04].

이 기술은 여러분이 어디서부터 시작해야 할지 모를 때 특히 유용합니다.

팀원들이 최상위 마일스톤에서 일정을 작성하고 나서 이 마일스톤을 지원하는 작업을

작성합니다. 팀원들이 마일스톤마다 무엇을 의미하는지 잘 이해했다면, 팀원들은 마일스

톤을 작업 수준으로 분해합니다.

하위 수준에 있는 작업이 더 작을수록 작업이 얼마나 걸릴지 예측하기가 더 쉬워지죠.

상향식 일정잡기

상향식 일정잡기는 특정 작업에서 시작합니다. 점진적 생애주기를 사용한다면, 상향식

으로 일정을 수립하는 게 이치에 맞을지도 모릅니다. “우선 이 기능에서 시작해야 한다는

것을 알죠. 그러고 나서 이 기능들을 개발해야 하고, 계속 진행할지 중단할지 결정을 내립

시다……”

팀원들은 혼자 작업하거나 교차 기능 팀원으로서 작업해서 하위 작업에서 마일스톤을

04 프로젝트 일정잡기 l 61

작성하죠. 프로젝트 관리자로서 여러분은 작업과 마일스톤이 잘 맞는지 물어볼 수 있습

니다(여러분이 기술에 밝을수록 팀원들을 더욱 잘 도와줄 수 있습니다. 하지만 제품에 대

한 전문지식이 없다면 팀원들을 방해하지 마세요).

안사이드-아웃 일정잡기

인사이드-아웃 일정잡기는 융통성이 상당히 필요하다고 생각하는 팀원과 함께 작업할

때 효과적입니다. 제가 주관하는 프로젝트 관리 워크숍에서 프로젝트 관리자가 이렇게

말했습니다. “저는 우선 프로젝트에 대해서 아는 것을 전부 마인드맵으로[BB96] 작성합

니다. 저는 프로젝트 진행 여부를 판단할 시점을 알지도 모릅니다. 어떤 기능에 대해서도

잘 알 가능성도 있습니다. 하지만 저는 모든 것을 비슷한 수준으로 알지 못하기 때문에

일정잡기를 시작하기 전에 모든 것을 살펴보길 원하죠.”

여러분이 작성한 마인드맵은 여러분에게 명명백백하게 보일지도 모릅니다. 하지만 프

로젝트에 참여한 다른 사람에게 그렇지 않을 수도 있죠. 나중에 마인드맵의 결과만을 보

여준 사람보다 마인드맵을 만드는 과정을 보여준 사람들과 의사소통이 더욱 잘 됩니다.

여러분과 팀이 인사이드-아웃 일정잡기를 사용한다면 반드시 팀원들과 함께 작업과 마

일스톤을 작성해야 합니다.

허드슨 만 시작하기

여러분이나 팀원들은 이번에 모두 생소한 형태의 프로젝트에 참여합니다. 여러분이 처한

환경과 도구가 잘 맞을지도 잘 모르죠. 프로젝트를 어떻게 예측해야 하는지도 모릅니다.

이런 경우라면 짧은 반복주기, 즉 허드슨 만 시작을 고려해 보세요.

허드슨 만 시작 방법은 1600-1700년 사이에 캐나다 북동 지역에 있는 허드슨 만 회사

에서 유래했습니다. 허드슨 만 회사는 모피 무역상의 탐험을 도왔습니다. 무역상은 필요

한 것을 잊어버리지 않으려고, 허드슨 만에서 몇 마일 떨어진 곳에 캠프를 차립니다. 무역

상은 몇 마일 밖에 캠프를 세워봄으로써 도구나 보급품을 잊지 않았다는 것을 확인했습

니다. 즉 마을을 완전히 떠나기 전에 말이죠. 무역상은 시험 삼아 캠프를 차려봄으로써 겨

울을 나는 데 필요한 더 좋은 아이디어를 얻었습니다.

팀원들은 허드슨 만 시작을 사용해서 실제 프로젝트 환경에서 무언가를 시험해 볼 수

있습니다. 여러분은 이 작업을 가능한 작은 범위에서 해보길 원하죠(“Hello World” 프로

62 l Manage it

그램이 적당할 겁니다). 프로젝트 팀원들은 허드슨 만 시작을 사용해서 제품 도메인이 속

한 환경에서 제대로 돌아가는 것이 어떤 형태인지 살펴볼 수 있습니다.

여러분을 포함한 팀원들이 예측하는 작업이 얼마나 걸릴지 잘 알지 못한다면 허드슨

만 시작 방법에 타임박스를 적용하세요. 4시간 안으로 완성할 수 있는 프로그램을 시작

하세요(실제 기능을 개발하지 않아도 괜찮습니다). 팀원들이 무언가를 만들어낸 다음,

활동 내역을 간략하게 살펴봅니다. 이 작업을 경험해보면 팀원들은 필요한 작업을 예측

하는 방법을 더욱 잘 알게 되죠. 팀원들이 조금밖에 알아내지 못했다면 짧은 반복주기를

시작하고 나서 어떤 일을 할지 결정하세요.

허드슨 만 시작은 몇 가지 측면에서 효과적입니다. 우선 팀원들은 자신들이 무언가를

완성했다는 자신감이 생깁니다. 팀원들은 무언가를 완료했다는 경험 덕분에 예측하는 상

황에서 통찰력을 발휘합니다. 게다가, 팀원들은 작업을 구성하는 방법에 대한 통찰력도

조금 얻습니다. “그래, 이 기능들을 동시에 개발하려면 다른 브랜치(branch)를 만든 다음

다시 합쳐야(merge) 해. 이런, 단계별 통합을 해야 한다는 뜻인데. 브랜치에서 수행하는

작업이 메인라인(mainline)에서 하는 작업보다 더 오래 걸리겠는걸.”

팀원들이 이런 대화를 나눈다면 팀원들이 위험을 정의하는 순간이죠. 이때 여러분은

팀원들의 대화를 주차창(379쪽 참조)에 기록해서 나중에 다시 살펴볼 수 있습니다.

짧은 반복주기를 사용해서 시작하기

팀원들이 환경을 이해했지만 작업을 예측하는 방법을 잘 모르는 경우, 타임박스를 적용

한 짧은 반복주기를 사용하세요. 팀원들은 짧은 반복주기를 사용하면서 1-2주 안에 어느

정도 끝낼 수 있는지 파악하기 때문에 팀원들이 내놓는 후속 예측은 더욱 정확해집니다.

허드슨 만 시작을 사용해서 프로젝트를 시작하고 나서 짧은 반복주기를 사용할 수 있는

데, 팀원들이 허드슨만 시작을 수행하면서 작업 환경을 파악했기 때문이죠.

짧은 반복주기에 타임박스를 적용하고(기간은 2주 정도로 잡습니다. 하지만 1주가 더

적당합니다), 팀원들이 그 기간에 무엇을 끝낼 수 있는지 알아보세요. 반복주기가 끝날

때쯤, 여러분과 팀원들은 요구사항, 위험 그리고 팀원들이 몰랐던 것이 무엇인지 더욱 잘

알게 되죠.

짧은 반복주기에 짧은 회고(retrospective)를 결합하면, 전체 팀원들은 프로젝트의 기간

을 더 잘 파악할 것입니다.

04 프로젝트 일정잡기 l 63

4.3 사무용품을활용해서일정잡기시작하기

제가 프로젝트 관리자로서 걸음마를 떼었던 구석기 시대에는 일정관리 소프트웨어가 없

었습니다. 당시에는 칠판, 종이, 플로차트 템플릿이 있었습니다. 저는 프로젝트의 일정을

수립할 때 칠판을 사용했습니다. 칠판은 쓸만했습니다. 즉 실수를 하면, 칠판에 적은 내

용을 지우고 그 위에 다시 적었죠.

글씨를 지우고 쓰기를 반복하면 칠판은 깨끗이 지워지지 않은 글씨 때문에 지저분해

졌죠. 신석기 시대가 되어 화이트보드로 바꿨지만, 화이트보드도 적은 내용을 확인하기

가 어려웠습니다. 새롭게 적은 내용 아래로 예전에 적은 글씨가 보일 때가 잦았기 때문

이죠.

현대가 되어 포스트잇이 출현했을 때 포스트잇으로 바꿨습니다. 1 포스트잇에 작업을

기록하고 벽에 붙이고 나서, 큰 목소리로 작업 순서가 어떻게 되는지 작업 담당자를 누구

로 정할지 그리고 어떤 위험이 있는지 팀원들과 쉽게 토론할 수 있습니다. 작업을 잘못된

곳에 붙였다면 포스트잇을 다른 곳으로 쉽게 옮길 수 있습니다(팀원들이 프로젝트를 다

른 방식으로 구성할 수 있는지 살펴보기 위해서 잘못된 곳에 포스트잇을 붙인 것입니다).

포스트잇은 전체 팀원들이 일정잡기에 관여하게 합니다. 팀원들은 일정잡기를 진행하

면서 위험을 설명하기 때문에 프로젝트의 방향을 잡는 데 활용할 수 있는 유용한 정보를

여러분에게 제공합니다.

일정잡기 소프트웨어 vs. 사무용품으로 일정잡기

-노련한프로젝트관리자샌디

저는 지난 15년 동안 프로젝트를 관리했습니다. 프로젝트 관리자로 처음

프로젝트에 참여했을 때 일정 관리 도구가 있었죠. 그리고 저는 잘 알려진

일정 관리 도구의 전문가가 되었습니다. 물론 일정 관리 도구에는 하위 프로

젝트를 취합할 때 몇 가지 문제가 있었지만, 전 그 문제들을 해결하는 방법

을 알았죠. 그리고 상세한 내용을 추적하려고 시도할 때 곤란을 겪었지만,

1 　 제가 일정관리 소프트웨어로 왜 바꾸지 않는지 궁금해하시는 분이 있을 겁니다. 답은 간단합니다. 제가 사용하는

운영체제에는 MS 프로젝트가 없습니다. MS 프로젝트가 없으니까, 당연히 MS 프로젝트를 사용할 수 없죠.

64 l Manage it

일정 관리 도구를 속이는 방법을 알아내는 데 도가 텄습니다. 물론 획득 가

치 계산(earned value calculation)하는 데도 문제가 약간 있었지만, 우리는

기능 단위로 개발하기로 결정했고, 그 덕분에 문제를 해결했습니다(235쪽).

전 2년 전에 무척 큰 프로그램을 관리하는 역할을 맡았죠. 이 프로그램은 6

개 사이트로 구성됐고 300명이 참여했습니다. 전 바보가 아니었기 때문에

초기 계획을 수립하는 회의에 프로젝트 관리자를 모두 불렀습니다. 저는 컴

퓨터를 프로젝터에 연결하고 일정을 수립하기 시작했습니다.

모든 사람이 제게 고함을 질러 댔는데, 어떤 작업이 있는지 알려주려고 했

기 때문입니다. 전 스트레스를 받았지만 어쨌든 작업을 했죠. 그때 갑자기

전기가 끊겼습니다. 하위 프로젝트 관리자 가운데 한 사람인 밥이 말했습니

다. “모두들 아무 데도 가지 마세요. 제가 돌아오는 대로 계속 진행할 수 있

을 겁니다.” 밥이 5분 후에 노란 포스트잇과 펜 한 묶음을 가지고 돌아왔습

니다. 밥은 일정을 어떻게 잡을지 설명했고 참석자들이 모두 포스트잇에 적

기 시작했습니다. 우리는 10분 후에 포스트잇을 벽에 붙이기 시작했고 각

포스트잇이 무엇을 뜻하는지 토론하고 어디에 이슈가 있을지 이야기 나누

었습니다.

한 시간이 지나기 전에 초기 일정을 세웠습니다. 벽에 붙은 포스트잇을 사진

으로 남겼습니다. 전기가 들어오지 않고 제 노트북의 배터리가 다되었을 경

우를 대비해서 말이죠.

회의가 끝났을 때, 하위 프로젝트 관리자들은 모두 제 덕분에 일정을 무척

빨리 세웠다고 칭찬했습니다. 제가 잘했다고요? 천만에요 모든 영광을 밥에

게 돌립니다. 그때 세운 일정은 몇 달 동안 유효했습니다. 그리고 일정을 갱

신해야 했을 때 우리는 하위 프로젝트 관리자들을 모아서 똑같은 작업을 했

습니다.

저는 이 방법이 효과적이라는 사실에 놀랐습니다. 그리고 저는 여전히 일정

관리 도구를 사용하지만, 사무용품을 사용해서 일정을 수립하는 방법으로

프로젝트를 항상 시작합니다. 그리고 대규모로 계획을 다시 잡아야 한다면

지금도 사무용품을 사용한 일정잡기를 사용합니다.

04 프로젝트 일정잡기 l 65

일정관리 소프트웨어를 사용해서 일정을 수립하는 방법을 선호하는 프로젝트 관리자

가 많습니다. 한꺼번에 많은 작업을 배치하고 이런 작업 사이에서 순서가 변하지 않을 것

으로 생각한다면 프로젝트 초반에 일정관리 소프트웨어를 사용하는 것은 효과적일지도

모릅니다. 하지만 일정관리 소프트웨어를 사용하면 전체 팀원들이 일정잡기 활동에 적극

적으로 참여하게 하지 못합니다. 일정을 작성하려고 도구를 사용하면 토론을 줄이고 보

이지 않는 의존관계와 위험을 노출하지 못합니다.

프로젝트 관리자는 한 번에 작업 한 가지만을 입력할 수 있고, 프로젝트 관리자만이 작

업을 작성할 수 있습니다. 또한 일정관리 도구는 한 번에 한 페이지의 정보만을 보여줄 수

있습니다. 그리고 팀원들이 전체 일정을 볼 수 없다면 맥락을 놓칠지도 모릅니다.

연동 계획을 사용하지 않는다면, 초기 프로젝트 일정을 작성할 때 일정관리 소프트

웨어도 괜찮을지도 모릅니다(하지만 크고 눈에 띄는 차트나 정보 방열기(Information

Radiator)를 사용할 때 얻는 이득을 놓칠 겁니다. 하지만 일정관리 소프트웨어를 사용해

서 프로젝트 일정을 수립하면 팀원들에게 이렇게 말하는 셈이죠. “어이, 자네들이 아니라,

내가 일정을 책임진다네.”

팀원들에게 일정에 대한 소유권이 있다면, 일정을 지킬 것입니다. 프로젝트 관리자 일

정을 소유한다면 여러분은 작업 사이에 존재하는 상호의존성을 관리하는 게 아니라 팀

원들을 깐깐하게 관리하려고 들 겁니다.

제 이야기를 듣고 여러분들이 벽에 포스트잇이나 카드를 붙여서 일정을 작성해 보겠다

는 결심을 하셨기를 바랍니다. 이 작업을 어떻게 수행하는지 잘 모르시겠다면 제가 다른

프로젝트에서 활용했던 몇 가지 방법을 참고하시길 바랍니다.

포스트잇 일정잡기 기초

팀원들이 모두 넓은 벽이나 큰 화이트보드가 있는 방에 모이게 하세요. 모인 사람들에게

포스트잇 한 묶음과 중간 크기의 굵은 검은색 펜을 나눠 주세요(저는 검은색 펠트펜과

너비 13센티미터 높이 8센티미터의 포스트잇을 선호하는데 이 크기면 커서 눈에 잘 들어

옵니다). 2 연속적, 반복적, 점진적 생애주기를 사용한다면, 팀원들이 프로젝트의 구조를

살펴보도록 벽에 주요한 마일스톤을 붙여 둡니다. 팀원들에게 자신들이 처리할 작업을

2 　 (옮긴이) 펠트펜은 알루미늄이나 유리 같은 용기 속에 휘발성 잉크를 적신 펠트를 넣어 만든 필기구다.

66 l Manage it

포스트잇에 전부 적게 하세요. 포스트잇 한 개에 하나의 작업만을 기록합니다. 팀원이 작

업을 기록하고 나면 벽에 포스트잇을 붙이게 합니다(그림 4.1과 그림 4.2에서 이 예제를

볼 수 있습니다).

벽의 일부는 주차장으로 활용합니다. 팀원들은 이곳에 질문과 가정을 붙여두는데, 이

질문과 가정은 일정을 작성하면서 해결해야 합니다. 저는 플립 차트를 주차장으로 사용

합니다. 사무실로 주차장을 옮겨서 해결할 필요가 있을 때 쉽게 옮길 수 있기 때문이죠.

자, 이제 멀찍이 물러서서 방해하지 마세요. 팀원들은 이벤트 사이에서 순서, 전제조건,

가정 그리고 질문을 두고 협업을 하기 시작할 겁니다.

개발자는 자신들이 수행할 작업을 작성하면서 요구사항 분석가, 기술문서 작성자, 테

스터에게 질문할 겁니다. 반대로 다른 사람들도 개발자에게 질문합니다. 팀원들은 프로젝

트가 ‘시작하기’ 전에 교차 기능 팀으로 활동하기 시작합니다(실제로는 프로젝트가 이미

시작됐습니다, 17쪽의 사이드바 ‘프로젝트는 여러분이 생각하기도 전에 시작합니다’를 참

조하세요. 하지만 지금까지는 어떤 산출물도 작성하지 않았습니다). 그림 4.1에서 단기 프

로젝트에서 작성한 일정의 한 예를 확인할 수 있습니다.

팀원들이 이슈를 해결할 정도로 일정을 상세하게 작성했다면 이제는 여러분이 관여할

시간입니다. 다음과 같은 이슈가 일정에 존재할 것입니다.

팀원들은 자신들이 수행할 작업 가운데 초기 몇 주의 일정만 세웠습니다. 팀원들 ▒

은 몇 주 뒤의 일을 자세하게 상상할 수 없어서, 초기 몇 주의 일정만을 세웠죠. 그

렇더라도 괜찮습니다. 왜냐하면 연동 계획하기를 사용해서 일정을 반복해서 수정

하기 때문입니다. 여러분은 팀원들이 현실에 기초하지 않은 상세한 일정을 작성하

지 않기를 바라기 때문이기도 하죠. 이런 상황에서 상세하게 일정을 작성하는 것

은 시간낭비입니다.

작업들이 꼬리에 꼬리를 물고 길게 나열된 상황을 볼지도 모릅니다. 연속적 생애 ▒

주기에서 이런 형태의 일정을 볼 수 있습니다. 하지만 반복적이나 점진적 생애주기

에서 이런 상황을 접한다면, 평행하게 작업하는 것을 방해하는 장애물이 있는지

팀원들에게 물어보세요. 그림 4.2를 보세요. 이 그림은 그림 4.1과 동일한 프로젝

트지만, 훨씬 연속적인 방식으로 일정이 작성됐습니다.

04 프로젝트 일정잡기 l 67

다수의 평행 작업이 일렬로 나열된 것을 볼지도 모릅니다. 연속적 생애주기에서는 ▒

이런 현상을 걱정하지 않아도 됩니다. 연속적 생애주기에서는 생애주기의 특성 때

문에 평행선을 허용하지 않죠. 하지만 이런 상황은 애자일과 같은 생애주기를 사

용하는 프로젝트에서 위험합니다. 사람들은 동기화하는 데 실패하고 여러분이 핵

심 경로(critical path)가 존재할 것이라고 예상하지 못했던 곳에서 핵심 경로를 만

날 위험이 있습니다.

팀원들이 일정을 작성하고 나면 팀원들은 각 작업의 처리시간을 예측할 준비를 마쳤습

니다.

그림 4.1 | 단기 프로젝트에서 작성한 포스트잇을 활용한 일정잡기

68 l Manage it

그림 4.2 | 다른 프로젝트에서 포스트잇을 활용해서 작성한 일정

포스트잇 일정잡기에 화살표 사용하기

포스트잇 일정잡기를 다른 형태로 사용하는 고객도 있습니다. 일단 일정을 수립하고 나

면, 고객은 작업을 담은 포스트잇들 사이에 화살표를 그립니다. 화살표를 사용함으로써

몇 가지 도움을 받습니다. 포스트잇이 떨어졌을 때 고객은 어디에서 떨어졌는지 쉽게 알

수 있습니다. 다음으로 고객은 처음으로 포스트잇 일정잡기를 끝마친 후, 일정관리 소프

트웨어로 이 일정을 옮깁니다. 프로젝트 책임자가 프로그램에 포스트잇을 작업으로 입력

할 때, 프로젝트 책임자는 화살표를 보고 상관관계를 추적할 수 있습니다.

그룹별로 포스트잇 일정잡기

단계-게이트 일정을 반드시 사용해야 하고 기능 단위로 개발하기 위해 교차 기능 팀을 구

성할 수 없다면 다른 선택사항도 존재한다는 것을 경영층에게 납득시키는 데 일정을 활

용할 필요가 있습니다. 저는 기능 팀을 사용해서 팀을 구성하면 프로젝트 진행속도가 더

디어진다는 것을 경영층이 깨닫도록 포스트잇을 사용해서 일주일 단위로 일정을 작성했

습니다.

커다란 화이트보드 위나 종이를 두른 벽에 한 주를 나타내는 수직선들을 긋습니다. 서

로 다른 기능조직에서 프로젝트에 참여하는 것을 나타내려고 다른 색상의 포스트잇을

사용했습니다.

프로젝트가 끝나는 것을 보여주는 것을 잊지 마세요. 기능 팀으로 구성한 프로젝트의

완료는 쉽지 않습니다. 경영층은 개발자가 한가해졌기 때문에 개발자를 다른 프로젝트에

04 프로젝트 일정잡기 l 69

투입할 수 있다고 생각합니다. 이렇게 되면 프로젝트에서 개발자가 가장 필요할 시기, 즉

결함을 수정해야 하는 시기에 개발자는 프로젝트에 거의 기여하지 못하죠.

기능별로 포스트잇 일정잡기

저는 최근에 각 기능이 다른 기능과 어떻게 통합되는지 보여주는 데 포스트잇 일정잡기

를 사용하기 시작했습니다. 프로젝트를 진행하면서 통합하는 데 의존 관계가 존재하는

복잡한 프로젝트를 관리한다면 포스트잇을 사용해서 일할 분량만큼의 반복주기를 계획

하는 게 유용하다는 것을 알게 될 겁니다.

산출물마다 대응하는 포스트잇을 작성합니다. 기능 한 개에 중간 산출물이 여러 개 붙

을 때도 있습니다. 이런 포스트잇을 벽에 붙이세요. 팀원들이 언제 산출물이 필요하고 어

떤 산출물이 코드로 구현되어야 하는지 작성하게 하세요. 팀원들이 기간이 촉박한 완료

일도 작성하도록 다음처럼 이야기하세요. “이 산출물을 끝내지 못한다면 우리는 반복주

기가 끝나기 전까지 끝낼 수 없습니다.”

특히 짧은 반복주기를 사용해서 진행한다면 포스트잇을 간트 차트로 옮길 필요가 없

습니다. 점진적인 생애주기에서 작업한다면 여러분은 길어지는 프로젝트 기간에 대비해

서 포스트잇에 테이프를 붙이거나 의존 관계를 관리하는 데 간트 차트를 사용해야 할 겁

니다.

포스트잇 일정잡기를 사용해서 얻는 장점

포스트잇 일정잡기를 사용한다면 핵심 경로를 살펴볼 수 있는 아름다운 간트 차트를 얻

지 못할 겁니다. 하지만 괜찮습니다. 소프트웨어를 만드는 프로젝트에서는 핵심 경로 때

문에 작업이나 인력, 가끔은 장비를 낭비합니다. 그리고 장담하건대 핵심 경로는 팀원들

이 무엇을 끝냈는지에 따라서 날마다 바뀝니다. 여러분의 프로젝트에서 핵심 경로가 날

마다 바뀌지 않는다고 해도, 적어도 일주일마다 바뀝니다. 간트 차트의 목적이 핵심 경로

를 보여주는 것이라는 사실을 몰랐다면, 이 사실을 고민해 봐야 합니다. 팀원들이 간트 차

트의 목적을 숙고해 본다면 핵심 경로를 관리할 수 있습니다.

게다가 포스트잇 일정잡기는 프로젝트 완료일을 알려주지 않습니다. 왜냐하면 여러분

이 정확한 완료일을 전혀 예측하지 않았기 때문입니다[DL03]. 하지만 일정관리 도구는

완료일을 계산해주죠(이 완료일은 가장 이른 완료일이며, 프로젝트가 그때까지 끝나지 않

70 l Manage it

을 것을 증명할 수는 없습니다). 하지만 사람들은, 특히 상위 관리자는 일정관리 도구 알

려주는 완료일을 믿습니다.

멀티사이트 프로젝트를 운영해도, 포스트잇 일정잡기를 사용할 수 있습니다. 팀마다

완전한 산출물을 책임진다면(268쪽 ‘각 사이트에서 프로젝트에 넘겨주기로 한 인도산출

물을 반드시 완료하게 하라’ 참조), 각 팀은 날마다 자신들만의 일정잡기를 수행합니다.

팀 리더나 프로젝트 관리자를 모아서 누가 무엇을 누구에게 언제까지 인도하는지 확실히

이해하게 합니다. 주요한 마일스톤을 다루기 때문에, 포스트잇 일정잡기와 비슷한 것을

수행하려고 비디오 컨퍼런스나 웹 컨퍼런스를 사용할 수 있습니다.

산출물 기준으로 계획하기

포스트잇 일정잡기는 산출물 기반의 계획을 세우는 데도 사용할 수 있습니다. 팀원들은

남은 기간에 무엇을 인도해야 하는지 고민하면서, 단계를 끝내는 것을 기준으로 삼는 게

아니라 산출물을 기준으로 마일스톤을 세웁니다.

단계나 기능을 기준으로 계획을 세우는 것은 각 기능조직에서 온 팀원들이 프로젝트

의 특정 산출물을 책임진다는 것을 가정합니다. 아울러 이런 팀원들이 작업을 끝냈다고

말할 때 여러분은 그 단계가 완료되었다고 가정할 수 있습니다. ‘요구사항 확정’이나 ‘코드

확정’과 같은 마일스톤이 있는 프로젝트에서 작업해 본 경험이 있다면, 단계별로 계획을

세운 프로젝트에 참여한 셈입니다.

기능조직에서 온 팀원들이 자신이 맡은 산출물을 완성하려고 열심히 노력해도, 요구사

항과 코드는 확정되지 않을 때가 잦고 끝난 것이 거의 없다는 게 문제입니다. 결국 어정쩡

하게 마일스톤을 완료한 셈입니다. 마일스톤을 어정쩡하게 마무리 짓는 것을 피하려면 마

일스톤을 끝내기 전에 작업을 정리하는 것을 계획하세요. 요구사항이 몇 가지 분야로 나

뉜다면 ‘요구사항1을 작성하고 검토하는 것’의 정리, ‘요구사항2를 작성하고 검토하는 것’

의 정리, ‘요구사항3을 작성하고 검토하는 것’의 정리 등으로 모든 요구사항을 정리할 것을

‘요구사항 확정’ 마일스톤으로 구성합니다.

여러분은 산출물 기준으로 계획하는 방법을 어떤 생애주기에도 사용할 수 있습니다.

특히 연속적 생애주기를 사용해야 한다면, 프로젝트의 진행률에 대한 피드백을 일찍 얻

04 프로젝트 일정잡기 l 71

으려면 산출물 기준으로 계획하는 방법을 사용하세요. 요구사항을 확정할 수 없다면, 요

구사항 확정 이후의 다른 마일스톤들을 어떻게 달성할 수 있을까요?

지연된 프로젝트를 시간을 벌충하지 못합니다. 항상 더 지연되기 때문이죠.

프로젝트 초기에 여러분이 원하는 수준으로 프로젝트가 진행되지 못했다는 것을 파악

했다면, 다른 방식으로 작업하도록 결정해야 합니다. 프로젝트가 지연되면 시간을 만

회하지 못합니다. 프로젝트는 늦어지고 점점 더 늦어집니다......

팀원들이 시간을 만회할 것으로 생각한다면 여러분은 131쪽 ‘내일은 더 괜찮아질 거

야’에서 다루는 일정 게임에 빠진 셈입니다.

☞ 이것만은기억하자!

사무용품을 사용한 일정잡기로 시작하세요. 일정관리 소프트웨어가 정말로 필요 ▒

하다면 나중에 일정을 소프트웨어에 입력하세요. 크고 눈에 띄는 차트나 정보 방

열기를 사용하지 못해서 발생하는 손실을 경계해야 합니다.

기능조직에 따라서 일정을 수립하는 게 아니라, 산출물을 기준으로 일정을 세우 ▒

세요.

일정을 반복해서 작성할 것을 계획하세요. 한번 작성하고 끝내는 일정은 정말로 ▒

시간 낭비한 셈이죠.

72 l Manage it

73

05작업량 예측하기

지금까지 프로젝트 일정을 정리했습니다. 지금부터는 각 작업의 소요시간을 예측할 시간

입니다. 이제 감으로 추측하는 방법만을 사용하지 않아도 됩니다. 여러분에게 다른 선택

사항이 있기 때문이죠. 가장 정확한 예측치가 아닌 여러분에게 꼭 필요한 최선의 예측치

를 구하는 방법을 선택하세요.

5.1 프로젝트를예측하는실용적인접근방법

저는 다음과 같은 예측 기술을 성공적으로 사용했습니다. 즉 예측 작업을 수행하기 전

에 데이터를 모으려고 스파이크(spike) 방법을 사용했으며, 이력 정보, 델파이 방법, 와

이드밴드 델파이 방법(wideband Delphi), 상대적인 순위 매기기와 상대적인 규모 예측을

사용했습니다. 전 컴퓨터 기술이나 계측 방법을 제대로 사용한 경험이 없습니다. 컴퓨터

기술이나 계측 방법에 대한 자세한 정보는 맥코넬(McConnell)의 책[McC06]을 참조하

세요.

이력을 비교해서 예측하기

예전에 수행한 프로젝트와 비슷한 후속 프로젝트를 관리한다면, 프로젝트의 기간을 예

측할 수 있습니다. “음, 지난번 프로젝트에서 6개월 동안 8명이 투입됐네. 이번 프로젝트

도 비슷한 규모인 듯하니까, 첫 번째 예측치를 6개월 동안 8명이라 가정할 수 있겠지.” 프

74 l Manage it

로젝트는 선형적이지 않다는 점을 명심하세요. 이번 프로젝트의 규모가 지난 프로젝트보

다 약간 더 커 보여도, 이력 비교는 틀릴 수 있습니다. 이력을 비교하는 방법은 델파이 기

법이나 와이드밴드 델파이 기법보다 훨씬 유용합니다.

델파이와 와이드밴드 델파이 예측

델파이 예측을 사용한다면 프로젝트 관리자는 팀원들을 회의실로 불러 모아서 프로젝트

를 설명합니다. 팀원들은 궁금한 것을 질문하고 나서 사무실로 돌아가서 작업 목록과 예

측치를 작성하고, 이 과정에서 팀원들이 가정한 것도 기록합니다[Wie00].

팀원들은 다시 모여서 작업 목록을 검토하며, 어떤 작업을 동시에 수행할 수 있을지 살

펴봅니다. 프로젝트 관리자가 예측치를 합산하면 이 합한 값이 프로젝트의 예측치가 됩

니다.

예측을 할 사람들을 모을 수 없다면(실제로 프로젝트에 참여할 사람들), 와이드밴드 델

파이 기술을 사용하면 유용합니다. 전문가로 구성된 작은 그룹이 프로젝트 팀을 대신합

니다 . 이 그룹이 작업 목록과 예측치를 작성합니다. 전문가들이 예측치를 만들고 나서 자

신들이 작성한 작업 목록, 가정, 위험을 구체화합니다.

이 두 가지 델파이 방법은 모두 프로젝트 관리자가 혼자서 프로젝트를 예측하려고 시

도하는 것보다 더 낫습니다. 하지만 두 방법에는 비슷한 문제가 있습니다. 델파이 방법을

수행하는 사람마다 프로젝트의 한 부분씩을 책임지죠. 그리고 대부분의 경우 아키텍처

를 기준으로 예측합니다. 제가 델파이 방법들을 사용하면서 겪었던 문제를 여러분도 마

주칠 겁니다. 바로 과소평가해서 예측을 한다는 것입니다. 예측치를 낮게 잡는 문제를 해

결하는 방법은 예측하는 동안 규모(sizing)와 기간(duration)을 분리하는 것입니다(82쪽

‘예측할 때 규모와 기간을 분리하기’ 참조).

팀원들이 산출한 예측치를 신뢰하지 못할 때

모든 사람이 예측을 잘하는 건 아닙니다. 지나치게 낙관적이어서[Bro95] 어떤 작업이라

도 50퍼센트 정도 낮추어서 예측하는 팀원도 있습니다. 지나치게 비관적이어서 작업마다

버퍼를 추가하는 팀원도 있죠. 사나흘이 걸리는 작은 작업을 잘 예측하지만 일주일 넘게

걸리는 작업을 잘 예측하지 못하는 팀원도 있습니다. 이런 상황에서 프로젝트 관리자는

어떻게 해야 할까요?

05 작업량 예측하기 l 75

우선 팀원들을 잘 파악해야 합니다. 프로젝트를 수행하면서 팀원들이 내놓는 예측치에

대해서 어느 수준으로 피드백을 줄지 결정하세요. 프로젝트를 시작한 첫 주에 예측 문제

를 모두 해결하지 않아도 괜찮습니다.

다음으로는 작업에 포함된 시간 버퍼를 제거하세요. 팀원들에게 예측치에 버퍼를 추가

했는지 확인하세요. 작업 시간을 줄이려는 게 아니라 가장 정확한 예측치를 얻으려고 물

어보는 것임을 설명합니다.

연속적인 혹은 반복적인 생애 주기를 사용한다면 예측을 하는 데 제약이론(�eory

of Constraints, TOC)을[Gol04] 사용할 것을 고려해보세요. TOC에서는 팀원들이 합리

적으로 작업을 예측해서 여러분에게 제공해야 합니다. 예측치의 50퍼센트를 선택해서

50퍼센트 기간만 간트 차트에 표시하고, 최초 예측치 가운데 25퍼센트를 버퍼에 추가합

니다[Gol97]. 핵심 경로상의 작업에서 시간이 더 필요하다면 버퍼에서 시간을 꺼내 시

간이 추가로 필요한 작업에 보탭니다. 그러고 나서 버퍼를 관리하기 시작합니다. 팀원들

이 작업을 완료할 때 버퍼를 측정함으로써 전체 예측치에 문제가 없는지 파악할 수 있

습니다.

점진적인 생애 주기나 애자일 생애 주기를 사용한다면, 작업을 완료하기 위해서 얼마나

걸릴지 알려주는 데이터를 모을 겁니다. 실제 데이터를 예측치와 비교해서 진행하면서 상

황을 파악할 수 있습니다.

일반적으로 작업을 예측할 때 작업 예측치에 여유 시간을 많이 할당하지 마세요. 차라

리 범위를 사용하는 예측치(80쪽 ‘예측치에 날짜 범위 사용하기’ 참조), 퍼센트 신뢰도(78

쪽 ‘예측치에 신뢰 구간 사용하기’ 참조), 또는 가장 빠른 완료일, 끝낼 확률이 높은 완료

일, 최악의 완료일(Best Case, Likely, Murphy’s Date)과 같은 3개의 날짜(80쪽 참조)를 작성

하세요.

연속적인 생애 주기에 존재하는 예측 함정 피하기

연속적인 생애 주기를 사용하는 프로젝트 관리자는 프로젝트 초기에 전체 프로젝트의

예측과 일정을 작성하려는 경우가 흔합니다. 프로젝트 관리자가 합리적으로 예측하려고

요구사항과 시스템 아키텍처를 충분하게 이해하는 데 몇 주가 필요합니다(아울러 프로젝

트에 참여하는 팀원들도 합리적으로 예측하는 데 몇 주가 걸립니다). 회사에서 이것과 비

76 l Manage it

슷한 프로젝트를 경험해 봤느냐에 따라서, 회사에서 내놓는 예측치가 틀릴 수 있습니다.

전 예측치가 100퍼센트에서 400퍼센트까지 차이 나는 것도 목격했습니다.

프로젝트 초반에 전체 프로젝트를 예측하려고 시도하는 데 함정이 도사립니다. 연속적

생애 주기를 사용해야 한다면, 프로젝트를 정확하게 예측할 수 없습니다. 여러분이 취할

수 있는 조치는 프로젝트를 시작하고 나서 작업을 완료하는 기간을 측정하고 남은 작업

가운데 비슷한 것이 얼마나 있는지 살펴보고 예측을 반복하는 것입니다.

특히 연속적 생애 주기에서 작업한다면 신뢰 범위(78쪽 참조)와 날짜 범위(80쪽 참조)

를 사용해서 다른 사람들이 여러분이 내놓은 예측치가 얼마나 확실하지 않은지 이해하

게 하세요.

예측치에 여유 시간을 언제 추가해야 할까요?

사람들은 낙관적이어서 작업을 끝내는 시간을 과소평가하는 경향이 있습니다. 이 문

제를 해결하는 가장 좋은 방법은 습관적으로 예측치를 부풀리는 것인 듯합니다. 예측

치를 부풀리면서 생기는 문제로는 파킨슨 법칙(Parkinson’s law)이 있습니다. 파킨

슨 법칙이라는 할당된 시간을 채우도록 일을 늘리는 것입니다.

선임 개발자가 매우 낙관적이라고 가정하죠. 선임 개발자는 16시간을 예측치로 내놓

았습니다. 이 작업은 30시간도 아니고 20시간도 아니지만, 20시간에서 30시간 사이

의 시간이 필요합니다. 이 상황에서 어떻게 하시겠습니까?

우선은 선임 개발자가 예측할 때 기간과 규모를 분리하도록 도와주세요(82쪽 참조).

선임 개발자가 예측하는 작업 크기가 크다면 작업을 인치페블(inch-pebble, 379쪽

용어 정리 참조)로 분할하도록 요청합니다. 선임 개발자가 이렇게 말할지도 모릅니다.

“아니에요. 이 작업은 16시간 걸리기 때문에 이틀짜리 작업이에요.” 선임 개발자가

실제로 하루에 8시간씩 일한다면 그 말이 사실일지도 모르죠. 하지만 팀원들이 선임

개발자의 작업을 방해하기 때문에 그는 하루에 자신의 업무를 처리하는 데 8시간을

할애하지 못합니다. 제 경험상 보면 선임 개발자는 기술적인 업무를 처리하는 데 하루

에 4~5시간 정도 할당할 수 있습니다. 물론 이 숫자는 환경에 따라서 달라집니다. 이

런 이유로 선임 개발자가 예측한 16시간짜리 작업은 근무일을 기준으로 3~4일이 걸

립니다.

인치페블이 효과가 없다면 스파이크를 시도해 보세요(83쪽 참조). 팀원들은 모두 스

파이크 덕분에 실제로 작업이 얼마나 걸릴지 볼 수 있습니다.

05 작업량 예측하기 l 77

프로젝트는 일정대로 진행되지 않을 겁니다.

팀원들이 협력해서 일정을 세웠습니다. 팀원들이 모두 일정에 확신을 보였죠. 그때 일

이 생겼습니다.

걱정하지 마세요. 일정은 프로젝트가 어떻게 진행될지 팀원들이 오늘 내리는 최고의

추측입니다. 문제가 발생하면 일반적으로 일정보다 하루나 이틀 늦게 끝나죠. 원래 계

획은 엉망이 되어버리죠. 이것 때문에 저는 적당한 수준에서 일정잡기를 하고 연동 계

획하기를 사용할 것을 예상합니다. 따라서 주위 환경이 변하면 일정을 쉽게 갱신할 수

있습니다.

예측치에 여유 시간을 언제 추가해야 할까요? (계속)

예측치를 적게 내놓는 팀원에게 3가지 날짜를(80쪽 참조) 사용해서 예측치를 계산하

도록 지시합니다. 이 방법을 사용하면 여러분이 팀원에게 예측치에 대해서 피드백하

지 않아도 팀원은 자신이 내놓은 예측에 대해서 피드백을 받습니다.

상습적으로 예측치를 적게 내놓는 팀원과 이야기해서 예측한 기간에 실제로 더 적게

달성했다는 것을 깨닫게 도와줍니다. 프로젝트가 제대로 진행되게 하기 위해서 버퍼

를 사용하거나 반복주기로 변경할 것을 고민해 보세요.

반복주기는 기간이 짧기 때문에 팀원들은 모두 예측을 한 몇 주 동안 자신이 내놓은

예측에 대한 피드백을 얻습니다. 프로젝트 팀원들은 다른 팀원들이 내놓은 예측을 수

정할 겁니다. “지난 반복주기에서 이 기능은 크기가 3이라고 말했지만. 크기가 8이라

고 밝혀졌잖아. 이 기능이 어떤 점에서 지난 번에 크기가 3이라고 말한 기능과 비슷하

지?”

예측치를 늘리는 것은 마지막 방법입니다. 팀원들과 함께 EQF(예측 품질 지수,

Estimation Quality Factor, 237쪽 참조)를 작성하고, 팀원들이 수행하는 작업을

EQF를 사용해서 모니터링하세요. 타임박스를 적용한 반복주기로 변경하면 팀원들이

예측하는 작업을 줄이고 작업 크기가 줄어듭니다. 여러분이나 팀원들이 내놓은 예측

에 관계없이 예측치에 대해서 피드백합니다. 하지만 여러분이 예측치를 늘린다면, 프

로젝트에 파킨슨 법칙이나 학생 신드롬(Student Syndrome)* 1 을 불러일으키는 위험을

초래합니다. 팀원들이 예측을 무시하면서 한없이 행복하게만 지낸다면 팀원들이 예측

하는 능력은 늘지 않습니다.

*1 　 (옮긴이) 학생 신드롬은 숙제를 미루다가 마지막 순간에 하는 것처럼, 작업이 주어졌을 때 최대한 미루다가

완료일이 다가왔을 때 처리하는 현상.

78 l Manage it

예측치에 신뢰 구간 사용하기

여러분이 내놓은 예측치를 얼마나 신뢰하시나요? 저는 프로젝트 초반에 전혀 신뢰하지

않습니다. 우리가 세운 일정대로 프로젝트가 진행되지 않을 것만은 확실합니다. 문제란

생기기 마련입니다. 그리고 이 문제 때문에 예측치가 변경됩니다. 완료일에 한 가지 예측

치를 사용하는 대신, 신뢰 구간을 사용해 보세요.

신뢰 구간 차트는 그림 5.1과 같습니다. 확률 범위는 신뢰 수준에 대한 정보를 제공합니

다. 프로젝트 초기에는 프로젝트가 끝날 확률은 0입니다.

확률이 60퍼센트인 7월 1일이 프로젝트가 끝날 가능성이 있는 첫째 날입니다. 여러분

은 끝날 가능성이 있는 첫째 날에 프로젝트가 끝나지 않는다는 것을 증명할 수 없습니다.

7월 중순에는 확률이 80퍼센트가 되는데, 프로젝트 초반에 이 날에 끝날 것으로 예상

했죠. 곡선의 기울기가 점점 완만해지는 것에 주목하세요. 따라서 프로젝트 초반에 확실

한 출시일을 선택하는 것은 불가능에 가깝습니다. 왜냐하면 9월, 10월, 11월에 가서야 확

률이 90~100퍼센트가 되기 때문입니다.

하지만 여러분은 이런 차트를 사용하는 덕분에 후원자와 이야기를 나눌 수 있습니다.

“출시일을 6월 15일에 맞출 수 있는 확률은 단지 50퍼센트입니다. 6월 15일에 출시하길 원

확률

1월 1일 2월 1일 3월 1일 4월 1일 5월 1일 6월 1일 7월 1일 8월 1일 9월 1일 10월 1일 11월 1일

완료일

그림 5.1 | 신뢰 구간 차트

05 작업량 예측하기 l 79

하시는 것을 알지만, 끝낼 가능성이 있는 가장 빠른 날인 7월 1일에도 끝낼 수 있을지 장

담하지 못하겠습니다.” 그러고 나서 6월 15일의 신뢰도가 그렇게 낮은 이유를 설명할 수

있습니다.

특히 연속적인 생애 주기를 사용한다면 그림 5.2의 불확실성의 원추(Cone of Uncertainty)

를 사용할 것을 고려해보세요. 불확실성의 원추는 프로젝트 초반에 여러분이 내린 예측

치가 왜 정확하지 않으며 언제 예측치를 조금 더 정확하게 수정할 수 있는지 설명합니다.

불확실성의 원추를 다시 예측하는 것과 정확성이 향상되는 것은 프로젝트 팀원들이 따

로 떨어져 있는 단계 마일스톤을 달성하는 능력에 달렸습니다.

요구사항 확정, 설계 확정, 코드 확정을 동시에 하는 초기 마일스톤이 있다면 여러분이

불확실성의 원추를 평가할 수 있는 최초 시점은 코드 확정입니다. 이것보다 일찍 예측치

를 갱신할 수 없을 겁니다.

반복적인 혹은 점진적인 생애주기를 사용한다면 불확실성의 원추도 사용할 수 있습니

다. 사용하는 생애 주기가 점진적일수록 실제 데이터가 있기 때문에 이것을 활용하여 예

400퍼센트

설계 완료

코드 확정

시스템 테스트

25퍼센트

프로젝트 헌장 승인

요구사항 베이스라인

아키텍처 정의

그림 5.2 | 불확실성의 원추

80 l Manage it

측치를 갱신함으로 더욱 정확하고 빠르게 예측치를 내놓을 수 있습니다.

애자일 생애 주기를 사용한다면 불확실성의 원추가 필요 없습니다. 출시일을 예측하는

데 개발 속도와 요구사항 변경률만 측정하면 되기 때문이죠.

예측치에 날짜 범위 사용하기

프로젝트에 대한 전체 예측치를 작성해달라고 요청받았지만 팀원 누구도 여러분이 예측

하는 작업을 도와줄 수 없다면, 날짜 범위를 사용하면서 여러분이 언제 예측치를 다시 수

정할 수 있는지 설명하세요. 다음은 제가 프로젝트에서 사용한 날짜 범위입니다. “이번

프로젝트에 대해 3분 동안 설명하신 것을 토대로 보면 3분기에 무언가를 인도할 수 있을

듯합니다. 지금이 1월 10일이고 다음 주에도 팀원을 소집하지 못하기 때문에, 팀원들과

반복주기와 계획하기를 몇 번 수행한 다음 2월 1일에 예측치를 갱신해서 알려 드리겠습

니다.”

팀원들이 프로젝트를 시작하고 나서 2주 동안의 반복주기에서 무엇을 끝낼 수 있는지

알게 되자, 정보를 더 많이 얻었습니다. 저는 상관에게 보고했습니다. “3분기는 지나치게

낙관적인 예측이라는 것을 알게 됐습니다. 하지만 9월초나 10월 사이쯤에 출시할 수 있을

것 같습니다.” 4월에 다시 보고했습니다. “11월말에서 12월초쯤이면 출시할 수 있습니다.

두 달이 지나고 나서 더욱 정확하게 보고 드리겠습니다.” 6월에는 이렇게 보고했습니다.

“11월 15일에서 12월 1일 사이에 출시할 것 같습니다. 언제 정확한 날짜가 필요하시죠?”

날짜 범위를 사용하는 덕분에 지나치게 일찍 불가능한 완료일을 공표하는 데서 탈출할

수 있었습니다. 하지만 여러분이 “10월에서 12월 사이에 출시할 수 있습니다.”라고 보고하

지만 상관이 “10월에 출시하겠습니다.”라고 이해한다면, 신뢰 수준을 이용해서 설명하는

편이 낫습니다. 아니면 애자일 생애 주기를 사용한다면 백로그를 지속적으로 관리하기

때문에 경영층이 원하는 이른 시간에 출시할 수 있습니다.

3개의 날짜 사용하기: 가장 빠른 완료일, 끝낼 확률이 높은 완료일,

최악의 완료일

프로젝트 관리자에게서 완료일이 바뀐다는 이야기를 듣는 것을 좋아하지 않는 상관도

있습니다. 여러분은 이 경우에 3개의 날짜를[DL03] 사용할 수 있습니다. 즉 가장 빠른 완

료일, 끝낼 확률이 높은 완료일, 최악의 완료일입니다.

05 작업량 예측하기 l 81

가장 빠른 완료일이란 프로젝트가 끝날 것이라고 보장하지 못하는 첫째 날입니다. 간트

차트를 작성한다면 일정 관리 프로그램이 알려주는 완료일이 가장 빠른 완료일입니다. 버

퍼를 관리하거나 비상 계획이 있어도, 가장 빠른 완료일을 지키지 못하게 할 문제가 생길

것을 예상해야 합니다. 하지만 가장 빠른 완료일을 지키지 못한다는 것을 증명할 수 없습

니다. 그렇기 때문에 그 날짜가 가장 빠른 완료일이 됩니다.

여러분이 예측치를 늘리거나 아니면 버퍼나 오차를 추가함으로써 산출한 것이 끝낼 확

률이 높은 완료일입니다. 여러분은 끝낼 확률이 높은 완료일을 더욱 신뢰하지만, 이 날짜

도 80~90퍼센트 정도만 확실할 수 있습니다. 최악의 완료일은 머피의 법칙이 프로젝트에

끊임없이 일어나는 경우 완료일입니다. 이상한 눈보라가 플로리다를 강타하고 태풍이 동

남아시아에 있는 데이터 센터를 파괴하거나 전력회사에 있는 변압기가 사람들이 모두 휴

가 떠나기 직전인 지난주 중간에 녹아버릴 때 최악의 완료일이 실제 완료일이 되죠. 이런

문제는 며칠에서 일주일 사이에 모두 고칠 수 있습니다. 소스를 모두 날려버리거나 프로

젝트 팀원들이 같은 날 모두 관두는 것과 같은 절박한 재난이 벌어졌을 때는 최악의 완료

일이 아닙니다.

최악의 완료일을 산출하려면 끝낼 확률이 높은 완료일에 오차를 더합니다. 여러분만이

오차를 얼마나 더할지 알고 있습니다.

예측에서 필요한 것은 정밀함(precision)이 아니라 정확함(accuracy)이다

지금까지 설명한 예측 방법은 예측이 얼마나 정밀하지 않은지 보여줌으로써 예측의

정확함을 강조했습니다. 프로젝트 초기에는 출시를 언제 할지 아는 것은 불가능합니

다. 즉 프로젝트 팀이 출시 내용과 품질 수준을 정의할 권한이 없다면 불가능하죠.

정밀함(Precision)은 측정의 엄밀함으로서 소수점 자릿수를 뜻합니다.* 1 정확함

(Accuracy)은 예측치에 얼마나 가까운지를 나타냅니다. 일정잡기를 할 때 여러분이

고민하는 것이 바로 정확함이죠. 작업 기간이나 일정을 얼마나 가깝게 예측했는지를

고민하지, 작업이 어떤 날 몇 시에 끝날지 프로젝트가 언제 끝날지 고민하지 않습니다.

예측의 정밀성에 대해서 걱정하지 마세요. 차라리 예측치가 얼마나 정확한지 고민하

세요 .

*1　http://www.ayeconference.com/Articles/Estimateprecisionaccuracy.html 참조

82 l Manage it

예측할 때 규모와 기간을 분리하기

사람들은 작업을 끝내기 전까지 작업을 예측하는 데 익숙하지 않습니다. 어떻게 하면 팀

원들이 예측하는 데 익숙해질까요? 만성적으로 과소하게 예측하는 문제를 관리하려면

작업 기간과 작업 규모를 분리해야 합니다.

규모를 예측하는 것은 작업이 얼마나 큰지 보는 것입니다. 개략적으로 규모를 예측하는

방법은 작업량이 적다, 보통이다, 많다는 것으로 분류하는 것입니다. 하지만 개략적으로

규모를 예측하는 것은 대부분의 프로젝트에서 맞지 않습니다. 예측치를 더욱 세밀하게

내놓아야 합니다. 또한 개략적으로 예측한 것을 작업 기간으로 바꿔야 합니다.

콘(Cohn)은 작업에 대한 개략적인 예측치를 작성하는 데 피보나치 수열을 사용할 것을

제안했습니다[Coh06]. 즉 작업 크기를 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 등으로 나타냅니다.

팀에서 예측한 것이 잘 맞았다면, 수열을 21까지 사용하고 여기에 40, 60, 80이나 100을

추가합니다. 팀원들은 실제 규모를 산출하기 위해 사전 작업(380쪽 ‘스파이크’ 참조)을 일

정에 추가해야 합니다(팀원들이 작업의 크기가 큰 경우 크기를 예측하는 데 어려움을 겪

는다면, 21, 40, 100을 사용하고 중간 숫자는 사용하지 않습니다. 그러고 나서 작업을 더

작은 조각으로 나누는 데에는 스파이크를 사용하세요).

피보나치 수열을 사용해서(아니면 다른 방법을 사용해서라도) 상대적인 규모를 산출하

고, 어떤 작업을 규모 ‘2’라고 예측했다고 하죠. 규모 ‘2’의 작업이 모두 동일한 규모인 것처

럼 보이시나요? 그렇게 보인다면 규모 ‘2’의 작업 기간을 예측하세요. 규모 ‘2’의 작업을 처

리하는 데 1시간 동안 10사람이 필요하다고 생각된다면, 규모 ‘2’의 작업 기간을 파악한

것입니다. 규모 ‘2’의 작업 기간을 2로 나눠서 규모 ‘1’의 작업 기간을 구하세요. 앞의 예에

서는 규모 ‘1’의 작업은 5시간이 걸릴 것입니다. 이렇게 산출한 값이 맞는지 자신에게 물

어보세요. 이렇게 구한 값이 맞는다면 , 여러분은 상대적으로 규모를 예측한 다른 작업에

곱해서 사용할 수 있는 인자(factor)를 구했습니다.

팀원들이 상대적인 규모를 사용해서 큰 작업을 예측할 때 확신하지 못한다면, 기간과

일정에서도 불확실함이 얼마나 큰지 알 겁니다(작업이 클수록 불확실성은 커집니다). 그

리고 팀원들이 모든 작업을 규모 ‘13’보다 더 크게 예측했다면, 팀원들은 작업들을 더 잘

게 나누지 않은 셈입니다. 전체적인 일정이 상당히 위험합니다.

여기에서 제안하는 시간당 필요한 인원은 이상적인 하루를 기준으로 삼은 게 아니라는

05 작업량 예측하기 l 83

것을 파악하셨을 겁니다. 이상적인 하루는 사람마다 다르기 때문입니다. 다른 사람을 코

칭하는 데 시간을 많이 쓰는 선임 팀원은 시스템에서 자신이 맡은 부분을 이해하는 데 집

중하지만 방해를 덜 받는 새내기 개발자보다 (개별적으로) 개발실적이 좋지 않습니다.

플래닝 포커

여러분은 팀원들이 전부 예측하기에 참여하기를 원합니다. 하지만 팀원들은 자신이 수립

한 예측치에 대해서 피드백을 한 번도 받지 못했습니다. 이런 상황이라면 여러분은 어떻

게 시작할까요? 바로 플래닝 포커가 출발점입니다.[Coh06]

팀원들이 모두 참여해서 백로그에 있는 기능의 상대적인 규모를 결정합니다(354쪽 ‘제

품 백로그를 구축하라’ 참조). 여러분은 이렇게 말할 것입니다. “자, 이번 기능은 주문할

때 보안을 추가하는 기능입니다.” 참석자들이 몇 초 동안 생각하고 나서 종이에 적힌 숫

자를 들어서 기능을 구현하는 작업의 규모를 예측합니다. 프로젝트 팀원이 6명이고 팀원

들이 모두 5라고 생각한다면, 좋습니다. 여러분은 기능 크기를 ‘5’라고 적습니다. 팀원 1명

만이 ‘13’이라는 숫자를 들었다고 가정하죠. 이때 평균을 내지 말고, 팀원에게 왜 그렇게

추정했는지 물어보세요. 팀원이 이렇게 말할지도 모릅니다. “지난번에 비슷한 기능을 구

현했을 때, 초기에 이해하지 못했던 여러 가지 예외사항을 발견했습니다.” 팀원들에게 숫

자가 적힌 카드를 다시 보여달라고 요청해서, 부분적인 합의를 이뤘는지 살펴보세요(완벽

한 합의를 달성하는 게 목적이 아니라, 팀원들이 그 숫자를 받아들일 수 있는지 봐야 합

니다). 몇 명이 ‘8’이라고 생각하고 나머지는 ‘13’이라고 생각한다면, 전원이 ‘8’을 받아들일

수 있는지 물어 보세요. 동의를 이끌어내지 못한다면 해당 작업에 스파이크를 적용하고

다시 예측해 보세요.

플래닝 포커(Planning Poker)는 델파이 기법과 상대적인 규모 예측하기의 장점을 섞어

놓았습니다. 플래닝 포커는 팀원들이 모두 참여하게 하고 백로그의 상대적인 규모를 신

속하게 예측하게 합니다.

예측하기 전에 데이터를 모으는 용도로서 스파이크 사용하기

작업 규모가 크다는 것을 알지만 어느 정도 큰지 잘 모를 때가 있습니다. 아울러 이 작업

을 어떻게 예측할지도 정말로 모릅니다. ‘큰 작업’은 잘 예측하기 어렵습니다. 이런 경우라

면 스파이크를 사용하세요(380쪽 용어 정리 참조).

84 l Manage it

스파이크를 사용한 예는 다음과 같습니다. 제품 일부의 성능을 향상시키는 팀에서 작

업한다고 가정하죠. 팀원 가운데 누구도 무엇을 할지 정확히 모르기 때문에 누구도 여러

분에게 작업 기간이 얼마인지 알려 줄 수 없습니다.

팀원들은 실제 필요한 작업을 알아보는 데 짧은 타임박스(아마도 하루 정도)를 사용할

수 있습니다. 타임박스가 끝날 무렵, 팀원들은 성능 향상에 필요한 첫 번째 작업에 대한

아이디어를 얻을 겁니다. 팀원들은 성능 향상과 관련된 모든 작업을 알지 못할 것입니다.

따라서 팀원들은 나머지 작업에 대해서 스파이크 작업을 한 번 더 수행해야 할 것입니다.

스파이크는 짧게 운영할 수 있습니다. 팀원이 60시간 정도 걸릴 것으로 예측한다면 이

팀원은 (어쩌면 다른 팀원과 함께) 2~3시간 정도를 들여서 규모가 큰 작업을 정리해서 4

시간에서 6시간 정도의 더 작은 단위로 60시간짜리 작업을 나눌 수 있습니다.

팀원이 작은 단위로 생각하는 게 익숙하지 않다면 스파이크를 사용해서 작업을 더 작

고 실행할 수 있는 단위로 나누는 방법을 배울 겁니다.

시간당 필요한 인원이나 하루당 필요한 인원 가운데 어떤 것으로 예측해야 할까요?

대부분이 시간당 필요한 인원(Persons-Hours)이 아닌 하루당 필요한 인원

(Person-Days)를 선호합니다. 하루당 필요한 인원은 이상적인 하루(ideal days)라

고도 부릅니다.

하지만 사람들은 평소에 8시간 동안 일하지 못합니다. 제 경험상 기껏해야 평소에는

기술적인 업무를 하는 데 6시간을 씁니다. 제 동료는 회의와 방해 때문에 최대 4시간

정도 일할 수 있다고 말했습니다. 이것도 운이 좋은 날에 말인 경우에 말이죠. 의자에

기대서 여러분의 프로젝트와 환경을 생각해 보세요. 프로젝트에서는 하루에 기술적인

업무를 처리하는 데 2~3시간 정도를 보낼지도 모릅니다.

프로젝트에서는 이상적인 하루 분위기에서 예측할 때가 흔하기 때문에 여러분이 실제

로 활용할 수 있는 시간 이상으로 시간이 있다고 가정하면 예측이 실패합니다.

쉽게 예측하는 팁

예측하기와 예측치를 쉽게 보고하도록 도와주는 방법을 소개합니다.

05 작업량 예측하기 l 85

예측치는 근사값, 즉 추측이라는 것을 명심하세요. 추측을 성기게 할수록 에러가 ▒

생길 가능성이 큽니다. 프로젝트 완료 ‘일자’에 대한 예측치를 말할 때 날짜 범위

로 정보를 제공해서 사람들이 예측치는 일종의 추측이라는 것을 이해하게 도와

주세요.

소프트웨어 분야에서 일하는 사람들은 낙천적입니다. 소프트웨어 종사자들은 학 ▒

교에서 낙관적이어야 한다고 배웠습니다. 하지만 학교에서 모든 프로젝트는 한 학

기에 끝날 수 있습니다(밤을 몇 번 새며 되죠). 그렇게 배운 사람들은 작은 단위로

예측하는 것을 배우고 자신들이 한 예측에 대한 피드백을 받기 전까지 낙천적인

자세를 유지할 겁니다.

여러분이 생각한 것보다 작업은 오랜 걸리는 경향이 있습니다. ▒

작업을 더 작게 예측하는 것이 더 쉽습니다. ▒

팀원이 어떤 방식으로 예측할지 결정하세요. 하루당 필요한 사람 혹은 시간당 필 ▒

요한 사람 가운데 하나를 결정하세요. 저는 시간당 필요한 사람을 추천합니다.

팀원들은 예측하는 방법을 연습하고 산출한 예측이 잘되었는지 피드백을 받아야 ▒

합니다. 피드백이 없는 예측은 헛된 예측일 뿐입니다. 이런 예측은 기분 좋게 하지

만, 결국 장기적인 이득이 없으며 결국에 가서 쓸모없게 됩니다.

예측하기를 반복할 것을 계획하세요. 프로젝트가 중반쯤 진행됐을 때 여러분이 ▒

한 예측치가 지나치게 낙관적이라는 것을 깨달았다면, 다시 예측할 시간을 갖고

프로젝트의 나머지 기간을 다시 계획하세요. 늦은 프로젝트에서는 시간을 벌충하

지 못합니다. 프로젝트가 더 지연되기 때문입니다. 프로젝트가 지연된 것처럼 보이

지 않더라도, 다시 예측하는 데 시간을 할애하세요.

▒ 프로젝트 데드라인이 정해졌다면 아무것도 예측할 필요가 없습니다. 기능에 우선

순위를 부여해서 우선순위에 따라서 기능을 구현하세요. 저는 이런 경우에 애자

일 생애 주기를 사용할 것을 강력하게 주장하는데, 기능을 구현해서 쉽게 피드백

을 받기 때문입니다. 애자일 생애 주기를 사용하지 못한다면, 점진적인 생애 주기

를 고려하고, 진행하면서 기능 단위로 구현하세요.

과도하게 제한된 프로젝트라면 단계와 작업에 ▒ 타임박스를 적용하세요.

작업이 커서(혹은 기술 위험이 지나 ▒ 치게 많아서) 잘 예측하지 못한다면 스파이크

를 고려하세요.

86 l Manage it

5.2 마일스톤은프로젝트범위를정의한다

팀원 몇 명이 투입되어 2주 이상 걸리는 프로젝트보다 규모가 더 큰 프로젝트를 예측하려

고 시도한다면, 마일스톤을 정의해서 여러분과 팀원들이 무엇을 예측하려고 시도하는지

파악하세요. 이런 마일스톤으로는 개발 활동을 끝내는 게 아니라 산출물을 완성하는 것

을 사용하세요.

데드라인이 촉박하다면 예측하는 데 시간을 허비하지 마세요.

CIO인 댄은 명확하게 말했습니다. “이 프로젝트는 4월 11일까지 끝내야 합니다.” 4

월 12일은 대규모 데모가 잡혔기 때문에, 댄은 자랑스러운 프로젝트를 뽐내고 싶었습

니다. 프로젝트 관리자인 세실은 시간에 제약을 받지 않았지만 출시 전에 기능 몇 개

를 반드시 끝내야 하는 프로젝트에 익숙했습니다. 일반적인 경우 세실은 프로토타입

을 구축하는 시간을 예측하고 결과를 피드백 받아 프로젝트를 시작했습니다. 세실은

이번 경우에 이 방법이 효과적이지 않을 거라고 확신했습니다.

세실은 이렇게 결정했습니다. 프로젝트에서는 기능 단위로 여전히 구현할 수 있지만

각 기능이 얼마나 오래 걸릴지 예측을 하지 않기로 마음을 정했습니다. 세실에게 정말

로 필요한 것은 기능을 어떤 순서로 구현할지 알려 주는 것이었는데 이렇게 하면 중요

한 데모 때까지 모든 것을 끝내지 못할지라도, 팀원들은 가장 중요한 기능을 인도할

수 있기 때문이죠.

세실과 팀원들은 각 기능을 개략적으로 예측했지만 상세한 예측치를 얻으려고 세부

적인 것을 분석하지 않았습니다. 팀원들은 댄이 원한 4월 11일까지 모든 것을 끝내지

못했지만, 대부분의 기능을 끝냈죠. 팀원들은 개발한 기능을 전부 끝냈습니다. 반쯤

완성된 기능이 없었고 대부분의 기능이 완성됐죠.

세실과 팀원들은 자신들이 예측해야 하는 것 이외에 다른 것을 예측하느라고 시간을

낭비하지 않았습니다. 팀원들은 한 시간 동안 전체 기능 목록을 예측했습니다. 세실은

각 기능을 끝내는 데 실제로 얼마나 걸렸는지 추적해서 기록했고, 이것 덕분에 팀원들

이 4월 11일 전까지 얼마나 끝낼지 예측할 수 있었습니다. 하지만 세실은 데드라인을

바꿀 수 없다는 것을 알았기 때문에, 프로젝트가 얼마나 걸릴지 예측하는 데 시간을

허비하지 않았습니다.

05 작업량 예측하기 l 87

연속적인 생애 주기를 사용한다면 단계가 끝날 때 그 단계에서 넘겨주기로 약속한 산

출물을 모두 정리해야 한다는 것을 명심하세요.

프로젝트 일정 작성을 시작하는 데 사무용품을 사용한 방법을 사용하세요. 특히 프로

젝트 기간이 짧아 보이는 프로젝트를 관리할 때 이 방법을 고려해보세요. 프로젝트에 시

간 제약이 많을수록 팀원들이 스스로 일정을 작성하고 일정을 받아들이고 지키도록 노

력해야 합니다.

팀원들은 회의실에서 몇 시간 동안 함께 포스트잇을 사용해서 일정을 수립한 덕분에

암묵적인 제약조건을 볼 수 있습니다.

작업을 계획할 때 산출물 기준으로 계획을 세워라

산출물을 기준으로 계획을 수립한다는 것은 여러분과 팀원들이 개발 활동이 아니라

산출물을 중심으로 일정을 수립해야 한다는 것을 뜻합니다. 아키텍처 프로토타입이

필요한 시스템을 개발한다면 다음과 같이 산출물을 기준으로 한 마일스톤이 있을 것

입니다. 아키텍처에 대한 3가지 후보를 만들고 나서, 각 후보를 검토하고, 후보 하나

를 선택해서 프로토타입을 만든 다음, (최종 마일스톤으로서) 아키텍처 프로토타입을

완료합니다. 다른 계획으로는 기능1을 구현하고, 기능2를 구현하며, 기능3을 구현하

고 나서, 현재 아키텍처를 평가하고 프로젝트에서 이 아키텍처를 사용할지 결정한 다

음, 아키텍처 프로토타입을 완료합니다. 두 가지 계획은 모두 프로젝트 팀 안에서 다

른 사람들에게 넘겨주는 산출물을 기준으로 ‘아키텍처 프로토타입을 완료’하는 마일

스톤이 존재합니다.

언제 단계나 작업이 끝나나요? 팀원들은 ‘아키텍처 프로토타입 완료’를 끝내는 방법

을 이해하는 데 참고할 만한 산출물이 없는 경우 ‘아키텍처 프로토타입 완료’ 마일스

톤에서 산출물을 인도할 수 없습니다. 앞에서 살펴본 대안들은 팀원들이 ‘아키텍처 프

로토타입 완료’를 끝내도록 도와주지만, 다른 방식으로 마일스톤을 달성합니다(첫 번

째 계획은 반복적인 생애 주기를 사용했습니다. 두 번째 계획은 점진적인 생애 주기를

사용했습니다. 애자일 생애 주기에서 ‘최종’ 아키텍처를 결정하기 전에 기능 몇 가지

를 구현할 것입니다).

88 l Manage it

5.3 얼마나적게일할수있을까?

팀원들은 흔히 자신들이 얼마나 많은 일을 할 수 있을까에 대해 생각합니다. 팀원들은

“이번 프로젝트에서 얼마나 많이 개발할 수 있을까?”라는 마음가짐으로 프로젝트를 수행

해야 한다고 생각합니다. 이런 생각을 버리고 “얼마나 적게 개발할 수 있을까?”라는 마인

일정 마일스톤(혹은 반복주기) 완료를 주중에 잡기

보통은 주요 (그리고 상세) 마일스톤을 금요일에 완료하도록 정리하고 싶어합니다. 이

런 식으로 일정을 잡으면, 팀원들은 자신들이 맡은 작업 가운데 중요한 것을 완료했다

는 것을 확인하고 집에 갈 수 있기 때문입니다. 하지만 어찌된 일인지 인생은 그런 식

으로 흘러가지 않습니다.

연속적인 생애 주기일수록, 월요일에 시작해서 금요일에 끝나는 데 위험이 더 많이 존

재하죠. 금요일에 끝내면 아무도 결과를 검토하지 않기 때문에 작업이 월요일 아침까

지 이어집니다. 이렇기 때문에 팀원들은 금요일 일정을 지키려고 주말 동안 미친 듯이

일할 시간을 얻습니다. 그리고 연속적인 생애 주기일수록 여러분(혹은 팀원들)은 일이

실제로 끝났는지 파악하기가 곤란해지죠. 말하자면 프로젝트 마지막 단계인 테스트

단계에 가서야 실제로 일이 끝났는지 압니다.

반복주기에서도 비슷한 문제가 있습니다. 반복주기를 금요일 오후에 끝내는 것으로

결정했다면, 제품 데모는 월요일 아침까지 실시하지 않기 때문에, 팀원들은 흔히 이렇

게 생각합니다. “야호! 주말 동안 이 기능을 완성할(혹은 수정할) 수 있잖아.” 특히 애

자일 개발방법으로 변경하는 중이라면, 예측이 정확하지 않기 때문에 프로젝트에는

초기 반복주기를 끝냈을 시점에 끝내지 못한 작업이 존재할 것입니다. 여러분은 팀이

적당한 시간 동안 어떤 작업을 끝낼 수 있는지 알고 싶습니다. 초과 근무를 하지 않고

말이죠. 금요일에 반복주기를 끝낸다면 여러분은 의식하지도 못한 채 팀원들이 주말

동안 작업을 끝내도록 허용한 셈입니다.

마일스톤이나 반복주기를 주중에 끝나도록 일정을 잡는다면 끝내지 못한 작업량이 명

확해집니다(여러분은 이런 상황을 원하죠). 여러분은 프로젝트의 방향을 조정할 수 있

는데 무엇이 끝나고 어떤 일이 끝나지 않았는지 알 수 있기 때문입니다. 어떤 일이 끝

나지 않았는지 알 수 없다면 프로젝트의 방향을 정하는 데 선택사항이 적어집니다.

주요한 마일스톤이나 반복주기의 시작과 끝을 화요일이나 수요일로 정하세요. 실제

진척도(혹은 진척되지 않은 이유)를 알고 초과 근무를 줄이거나 프로젝트 방향을 조정

하고 프로젝트가 끝날 무렵 발생한 재앙 때문에 당황하지 않을 겁니다.

05 작업량 예측하기 l 89

드가 있어야 합니다.

‘얼마나 많이’라는 사고방식은 다음처럼 가정을 합니다.

사람은 희소한 자원이 아니다. 따라서 가용한 사람들을 즉시 활용해서 미친 듯이 ▒

프로젝트에 몰입해야 해.

일정은 정말로 중요하지 않다. ▒

개발 비용은 견인인자가 아니다. ▒

‘얼마나 적게’라는 사고방식은 다음처럼 가정합니다 .

요구사항을 이해하는 것은 매우 어렵다. 엔지니어가 산출물을 인도하는 데 집중 ▒

하게 해야 한다. 이런 산출물은 우리가 특정 요구사항과 요구사항이 고객에게 주

는 가치를 이해한다는 것을 보여준다.

일정은 매우 중요하고, 일정을 다시 수립하거나 기술 빚을 쌓을 시간적인 여유가 ▒

없다.

프로젝트 비용은 중요하다. 따라서 비용을 관리해야 한다. ▒

프로젝트 관리자(아울러 프로젝트 관리자를 관리하는 상위 관리자)는 흔히 ‘얼마나 적

게’라는 사고방식의 특징들이 중요하다고 말하지만, ‘얼마나 많이’라는 사고방식에 따라

서 관리합니다. 상위 관리자가 ‘얼마나 많이’라는 식으로 물어볼 때, 여러분은 ‘얼마나 적

게’라는 방식으로 볼 수도 있습니다. 적어도 여러분은 사람들이 생각하는 가정을 명확하

게 정의하도록 도울 수 있습니다.

5.4 멀티태스킹상황에서예측하기

몇몇 팀원은 여러분의 프로젝트뿐만 아니라 다른 프로젝트에도 참여합니다. 이 팀원들이

맡은 작업이 얼마나 걸릴지 어떻게 예측하나요?

예측하지도, 예측할 수도, 예측하려고도 하지 마세요.

멀티태스킹 때문에 여러분이 관리하는 프로젝트는 반드시 지연될 겁니다. 팀원 전원이

프로젝트에 얼마나 참여할지 알 수 없기 때문에 프로젝트가 얼마나 지연될 것인지 말하

90 l Manage it

지 못합니다. 아울러 프로젝트에서 팀원이 필요할 때 팀원이 정말로 참여할지도 장담하

지 못합니다.

함께 일하는 팀원이 동시에 여러 프로젝트에 참여하고 멀티태스킹도 한다면 일정을 예

측할 수 없습니다(멀티태스킹 때문에 업무 시간 가운데 20~90퍼센트 정도를 낭비합니

다. [RG05]와 [Wei92]를 보세요). 제가 수행한 연구에 따르면 1 팀원들이 인도해야 하는

산출물을 넘겨주지 못하고 처리해야 하는 만큼의 일을 못하는, 즉 프로젝트가 지연되는

가장 큰 원인은 멀티태스킹이었습니다.

여러분이 취할 수 있는 조치는 후원자와 이야기하는 것입니다. 이렇게 설명하세요. “필

요한 팀원을 제때에 활용하지 못한다면, 원하시는 것을 바라는 시점에 원하시는 품질로

인도할 수 없습니다. 프로젝트 범위를 최소한으로 줄여 보는 게 어떨까요?”

후원자가 예산이 없다면(후원자는 돈도 지급하지 않고 당장 모든 것을 완벽하게 원합

니다), 거절의 뜻을 명확하게 전달하세요. 정치적으로도 합당한 처사입니다.

5.5 고의적으로멀티태스킹을하도록일정수립하기

프로젝트에서 꼭 필요하지만 상근 멤버로서 참여하지 못하는 팀원이 있을지도 모릅니다.

혹은 DBA나 GUI 설계자나, 프로젝트 중간에 잠깐 참여해야 하는 팀원이 있을 수도 있

죠. 아니면 개발자와 테스터가 필요한 소규모 프로젝트 몇 개를 관리할지도 모르지만, 이

모든 프로젝트에도 개발자나 테스터가 실제로 상근 멤버로서 참여하지 않습니다. 그렇다

면 어떻게 하시겠습니까?

고의적으로 팀원들을 멀티태스킹하도록 배치할 수 있습니다. 프로젝트 중간에 잠깐

필요한 팀원이 있다면, 주 단위로 프로젝트를 바꿔가면서 팀원을 할당합니다. 아니면 프

로젝트 팀원을 짝을 지을 수도 있습니다. 이렇게 짝지은 팀원을 프로젝트 2곳에 배치할

수 있습니다. 이제 팀원들을 일주일 단위의 반복주기로 일하게 합니다. 월요일에서 시작

해서 금요일에 끝나는 반복주기에서 일하게 합니다. 맞습니다! 이렇게 하면 주중에 마일

스톤을 완료하는 식으로 일정을 수립하는 방법을 어기죠(88쪽 사이드바 참조). 팀원들

1 　 http://www.umich.edu/~bcalab/multitasking.html에서 비용에 관한 이야기를 살펴보세요.

05 작업량 예측하기 l 91

이 모두 주말을 쉬어서 모든 사람에게 필요한 휴식을 주고 어쩔 수 없는 콘텍스트 스위칭

(context switching)해야 할 때에만, 이 방법은 효과적입니다.

멀티태스킹 때문에 비용을 지불할 겁니다. 고의적으로 멀티태스킹하는 팀원들은 작업

을 마치는 데 시간이 더 필요하기 때문이죠. 직원을 더 많이 고용하는 것보다 이 방법이

더 저렴할지도 모릅니다. 고의적으로 멀티태스킹하는 팀원들은 반드시 주중이 아니라 주

말에 다른 프로젝트로 갈아타게 하세요.

5.6 ‘연동계획하기’사용하기

프로젝트를 시작하면서 프로젝트에 대한 전체 계획을 세우려고 시도하지 마세요. 머지않

아 계획은 현실과 달라질 겁니다. 그리고 프로젝트가 본궤도에 오르도록 장애물을 제가

하는 데 사용할 수 있는 시간을 낭비하게 되죠. 프로젝트 초기에 일정을 수립하고서 지속

되는 일정잡기 그리고 다시 계획을 수립하는 활동에 연동 계획하기(380쪽 용어 정리 참

조)를 사용하세요.

전체 프로젝트의 일정을 수립하는 데에 익숙해졌다면, 연동 계획하기(rolling-wave

scheduling)는 다소 낯설게 느껴질 겁니다. 완전한 간트 차트를 작성하지 않거나 여러분

은 지금부터 3개월 간 무슨 일을 할지 정확하게 알지 못할 겁니다. 여러분은 솔직하게 3개

월치 일정을 얼마나 잘 예측하시나요? 저는 잘 예측하지 못합니다. 예상하지 못했던 일들

이 프로젝트에서 일어나기 마련이기 때문이죠. 마일스톤이 먼 장래일수록 마일스톤을 어

떻게 달성할지 잘 알지 못하죠. 팀원들이 예측을 잘하는 것과 상관없이, 팀원들이 초기에

예측한 방식대로 프로젝트를 완료하지 못하게 하는 사건이 일어날 것입니다.

연동 계획하기란 지속적으로 상세한 일정을 수립하는 방법으로서 단지 몇 주만을 예측

합니다. 상세하게 수립한 일정 중에 1주를 끝내고 나서, 상세한 일정 뒤에 새로운 1주를 추

가합니다. 4주의 연동 계획하기로 일정을 세웠다면 상세한 일정은 4주보다 짧아져서는 안

되고 4주보다 길어져서도 안 됩니다. 자세하게 알지 못하는 것에 대해서 일정을 수립하려

고 시간을 낭비하지 마세요.

4주의 연동 계획하기를 사용하는 데 2가지 이유가 있습니다. 2주 길이의 반복주기를

사용하는 프로젝트를 관리하지 않는다면, 2주 미만의 일정은 위험을 예견할 만큼 충분하

92 l Manage it

게 상세하지 않습니다. 일정이 4주보다 길어지면 4주 이상을 넘어서 계획한 것은 어긋나

는 경향이 있습니다. 따라서 저는 굳이 4주 이상을 예측하려고 시도하지 않습니다. 여러

분은 예측 능력이 4주에 미치지 못한다는 것을 알게 될지도 모르죠. 그렇더라도 괜찮습

니다. 여러분이 잘 아는 것부터 상세하게 작업을 계획하세요. 그리고 그 이상으로 일정을

수립하려고 고생하지 마세요.

연동 계획하기를 한 번도 사용해본 적이 없다면, 이렇게 시작하세요. 넓은 벽이나 화이

트보드에 일정을 작성할 수 있는 회의실을 준비하세요. 포스트잇에 주요한 마일스톤을

기록하고, 왼쪽에서 오른쪽으로 포스트잇을 붙입니다. 즉 시간이 왼쪽에서 오른쪽을 흐

르기 때문이죠. 그러고 나서 팀원들이 회의실에 들어오게 합니다.

단번에 프로젝트 전체 일정을 상세하게 작성하려고 시도하는 대신, 포스트잇을 벽에

붙이면서 여러분이 언제 주요한 마일스톤을 달성하길 바라는지 팀원들에게 알려주세요.

첫 번째 마일스톤에 대해서 이렇게 질문을 하세요. “이 마일스톤을 달성하려면 어떻게

해야 되죠?” 그러고 나서 프로젝트 팀원에게 팀원이 수행할 작업과 이 작업 사이에 존재

하는 상호의존성을 포스트잇에 적게 하세요. 포스트잇 하나에는 작업 하나만을 적게 합

니다.

팀원들에게 인치페블(379쪽 용어 정리 참조) 형태로 계획을 세우게 하세요. 프로젝트

관리자가 팀원들에게 인치페블을 할당하지 않기 때문에 팀원들은 자신이 수행할 작업을

상세하게 이해하고 이런 작업을 완료하도록 인치페블을 작성해야 합니다.

프로젝트 팀원들이 인치페블 형태로 계획을 작성할 수 없다면, 팀원들의 진척도를 파

악할 방법이 무엇인지 물어보세요. 인치페블 수준에서 생각하는 게 쉽지 않은 팀원도

있으며, 이런 사람은 자신이 수행할 작업을 더 작은 수준으로 나누는 방법을 배워야 합

니다.

간트 차트를 작성해야 한다면 여러분이 가장 좋아하는 프로젝트 일정 관리 도구에 포

스트잇에 적힌 내용을 입력하세요. 매주 팀원을 개별적으로 만나서, 팀원들에게 다음 작

업이 무엇인지 묻고, 일정을 갱신할 수 있습니다. 팀원들이 자신이 수행하는 작업에 존재

하는 상호의존성 때문에 도움이 필요하다면, 팀원들을 모두 다시 한 번 모이게 하세요.

프로젝트를 진행하면서 각 마일스톤을 확실하게 기억하고만 있다면 일정을 최신 상태

05 작업량 예측하기 l 93

로 유지하기가 쉽습니다. 아울러 일정 관리에 시간이 많이 필요하지 않다는 걸 알게 되고,

팀원들과 시간을 더 길게 보낼 수 있으며, 팀원들의 진척도를 확인하고 팀원들이 겪는 어

려움을 해결하죠.

연동 계획하기는 프로젝트의 진짜 상태를 이해하고 다음번 마일스톤의 달성 방법을 계

획할 때 쓰는 만병통치약이 아니지만, 시작할 때에 사용하기에 더할 나위 없이 좋은 방법

입니다.

5.7 반복주기기간을정하기

타임박스를 적용한 반복주기를 사용해서 프로젝트를 관리하기로 결심했습니다. 하지만

반복주기의 기간을 얼마간으로 결정하셨나요?

우선 충분한 여유가 있도록 반복주기의 기간을 결정하세요. 프로젝트 기간에 여유가

충분하다면 연속적인 생애 주기를 사용할 수 있습니다. 여유가 없다면 1주에서 4주 사이

의 반복주기를 선택하세요. 반복주기가 짧을수록 요구사항의 우선순위를 다시 매기고

변화가 일어났을 때 이에 대응하기가 더욱 쉬워집니다. 반복주기가 길어질수록 팀원들이

끝내야 하는 작업량이 더욱 많아지죠.

반복주기의 기간이 4주보다 길어지는 것을 추천하지 않습니다. 팀원들이 학생 신드롬

에 걸릴 가능성이 높아지고(180쪽 팁 ‘팀원들을 학생 증후군으로부터 보호하라’ 참조),

팀원들이 큰 작업을 끝내지 못할 가능성도 높아지는데, 이 작업은 팀원들이 쉽게 예측할

수 없거나 인도할 수 있는 분량의 더 작은 작업으로 쪼갤 수 없습니다. 팀원들은 반복주기

가 4주보다 길어지면 지속적인 통합을 피하려고 합니다(189쪽 ‘프로젝트에 지속적인 통

합 적용/변형하기’ 참조). 프로젝트를 진행하면서 지속적으로 통합하지 않으면 완료된 작

업을 확인하기가 어려워집니다.

반복주기에서는 최소한의 기간이 필요합니다. 2일 안쪽으로 반복주기를 계획할 수 없

다면, 반복주기를 3주 안으로 작성하려고 노력하지 마세요. 계획하기에 지나치게 많은 시

간을 보내면 일을 하는 데 시간이 충분하지 않습니다. 반복주기 동안 계획하기에 시간을

지나치게 허비하지 마세요.

94 l Manage it

5.8 가능하다면인치페블을사용해서예측하기

인치페블은 작업을 작게 나눈 것으로서, 이틀을 넘지 않고 대개 하루 정도의 작업입니다

([Rot99]와 [McC96]을 살펴보세요). 여러분이 XP에 익숙하다면 인치페블은 사용자 스

토리(user story)에 해당합니다. 인치페블의 상태는 완료되거나 완료되지 않은 것으로 나

타냅니다. 즉 인치페블에서 10퍼센트 완료, 혹은 50퍼센트 완료처럼 어정쩡하게 완료를

표시하는 퍼센트 완료를 사용하지 않습니다. 인치페블을 모으면 며칠 혹은 몇 주의 작업

이 되는데, 이런 작업은 대개 팀원이 일정을 작성할 때 만드는 작업에 해당합니다. 하루나

이틀 정도의 작은 타임박스를 사용하는 작업을 정의하는 방법이 인치페블입니다.

모든 프로젝트에서 작업을 예측하고 진척도를 모니터링하는 데 어느 정도 인치페블을

사용할 수 있습니다. 예측한 작업을 잊어버리는 팀원이 있다면 인치페블이 특히 유용합

니다. 인치페블을 작성하면 팀원이 맡아서 처리해야 하는 모든 단계를 기억하게 합니다.

큰 작업을 짧은 반복주기에 맞추는 방법을 알려주세요.

복잡한 프로젝트에는 규모가 큰 작업들이 있습니다. 이런 작업을 작게 쪼개서 팀원들

이 4주 안쪽으로 끝내게 인도하는 것은 도전거리입니다. 하지만 그럴 만한 가치가 있

습니다.

팀원이 작업을 끝내는 데 며칠이 걸릴 것 같다고 말할 때, 저는 어떤 기능이 코드로 구

현되는지 물어봅니다. 저는 팀원이 설계할 때 어느 정도 걸릴지, 계획을 세웠는지, 아

니면 팀원이 프로토타입을 만들지 알고 싶습니다. 팀원인 에릭이 설계할 것을 먼저 계

획했다면 에릭이 설계를 마쳤다는 것을 어떻게 파악하는지 묻습니다. 에릭이 프로토

타입을 만든다면 에릭이 프로토타입 평가 계획을 어떻게 계획했는지 물어보죠.

팀원들이 결과로서 코드를 많이 작성한다고 알려 주는 경우가 흔합니다. 이런 경우라

면 간단합니다. 팀원들은 기능단위로 코드를 인도할 것이기 때문에 팀원들이 전체 기

능 가운데 어떤 것을 먼저 인도할지 이야기하죠.

프로젝트에서 아키텍처 인프라스트럭처를 변경한다면, 프로젝트를 진행하면서 지속

적으로 통합하게 하고, 특정 반복주기를 선택해서 팀원들이 아키텍처 요소들을 전체

적으로 통합하는 작업을 수행합니다. 팀원들이 코드를 통합하기 전까지 프로젝트의

일정이 더디게 진행되는 것처럼 보인다는 걸 명심하세요(236쪽 사이드바 참조).

05 작업량 예측하기 l 95

일반적으로 가장 많이 잊어버리는 작업은 소프트웨어 형상 관리 시스템을 관리하고 갱신

하는 것입니다.

특히 연속적인 생애 주기에서는 필요한 재작업의 양을 과소평가하기 쉬워지죠. 아니면

감으로 예측을 한 경우에 개발자들은 자신들이 테스트한다는 것을 잊어버릴지도 모릅니

다. 아니면 테스트 환경을 설정하는 데 필요한 시간을 잊어버릴 수 있습니다.

앞에서 이야기한 것 가운데 하나라도 놓치면 출시일이 지연되거나 결함 수준이 높아지

거나 출시를 하면서 필요한 기능 몇 개를 빼먹을 수 있습니다. 인치페블을 사용하면 이런

문제를 방지하는 데 도움을 받을 수 있습니다.

인치페블은 애자일 생애 주기에서 일반적으로 사용합니다(다른 방법을 사용해서 프로

젝트에서 1주일 안에 실질적인 작업을 완료할 방법이 있나요?). 하지만 다른 프로젝트에

서, 특히 연속적 생애 주기 프로젝트에서는 일반적으로 인치페블을 사용하지 않습니다.

프로젝트 초반에 전체 프로젝트에 대한 인치페블을 작성하는 것이 이치에 맞지 않기 때

문이죠. 매일 혹은 주마다 계획하기를 하면서 인치페블을 사용하는 게 이치에 맞습니다.

즉 프로젝트 전체 계획을 수립하는 경우에 적당하지 않습니다.

작업 내용을 제대로 파악했을 때 인치페블은 유용하죠. 프로젝트에서 처리해야 하는

대부분의 작업을 파악했습니다. 하지만 어떻게 할지 모를 때는 어떻게 하죠? 아직 잘 모른

다면 어떻게 하실 건가요?

작업을 제대로 파악하지 못했을 때 인치페블을 작성하고 사용하기

새로운 제품(예전에는 어떤 형태로든 존재하지 않았던 제품)을 개발하거나 연구 프로젝

트를 관리한다면, 인치페블을 사용하는 방법을 변경해야 할 겁니다.

타임박스를 적용하는 대신, 작업의 종료 시점을 파악하기 위해서 질문하세요. 연구 프

로젝트를 수행하거나 새로운 제품을 개발하든지, 프로젝트 종류별로 반드시 물어봐야

하는 질문이 있습니다. 명확하지 않은 작업을 담당하는 프로젝트 팀이나 팀원들은 특정

질문을 생각해서 이 질문에 답을 어떻게 찾아낼지 알아야 합니다. 팀원들이 이런 질문에

답할 수 있으면 문제는 ‘무슨 일을 하지’가 아니라 ‘어떻게 끝내지’가 됩니다. 그러고 나서

팀원들은 남은 작업에 대해 인치페블을 작성할 수 있습니다.

96 l Manage it

인치페블을 정의하는 방법

팀원마다 인치페블을 정의하는 방법이 있습니다. 각 팀원은 프로젝트에 기여해야 하는 개

인적인 책임이 있습니다. 프로젝트 관리자는 인치페블을 정의하지 않습니다. 기술 리더도

인치페블을 정의하지 않습니다. 프로젝트 관리자, 기술 리더, 아키텍트가 인치페블을 정

의하려고 시도한다면, 기술 업무를 맡은 팀원들은 인치페블을 사용하길 거부할 겁니다.

다른 사람이 사용할 인치페블을 정의하는 것이 바로 깐깐한 관리이기 때문이죠. 사람들

을 깐깐하게 관리하는 것은 적절하지 않습니다. 팀원들이 인치페블 작성 방법을 모를 때

팀원들을 코칭하는 것은 괜찮습니다. 하지만 팀원들에게 일하는 방법을 알려주는 것은

좋지 않습니다.

인치페블을 사용한 깐깐한 관리 피하기

깐깐하게 관리받는 것을 좋아하는 사람은 없습니다. 즉 우리는 모두 전문가이기 때문

입니다. 처음에 믿기 어렵지만, 인치페블을 사용하면 여러분은 깐깐한 관리를 피할 수

있습니다. 팀원들은 작은 증분을 사용해서 자신들의 작업을 정의하기 때문에 작업은

완료되거나 완료되지 않은 상태죠. 따라서 지속적으로 상태나 작업을 점검할 필요가

없습니다. 바로 깐깐하게 관리할 필요가 없죠. 프로젝트 기간 동안 프로젝트 상태는

언제라도 명확합니다(괴로움을 주는 프로젝트 관리자나 선배 관리자와 일한다면, 인

치페블은 여러분을 구원하지 못합니다. 물론 어떤 것도 여러분을 구원하지 못하죠).

인치페블을 왜 사용해야죠?

여러분이 사용하는 생애 주기가 훨씬 연속적이거나 작업이 길수록, 인치페블은 효과적입

니다. 팀원들에게 인치페블을 사용해서 일정을 세우라고 지시하면 팀원들은 모두 작업과

작업 사이에 있는 상호의존성을 이해합니다. 게다가 인치페블은 의존성도 드러낼 수 있

습니다. 팀원들이 인치페블을 사용할 때, 팀원들은 일정잡기의 장점을 활용할 수 있는데,

드물게도 작업을 일찍 끝내는 사람들도 있죠.

아울러 인치페블은 일정을 더욱 정확하게 작성하도록 도와줍니다. 적어도 팀원들이 일

정을 수립하려고 인치페블을 사용하는 동안에는 말이죠. 이런 혜택 덕분에 일정 위험이

줄어듭니다.

05 작업량 예측하기 l 97

☞ 이것만은기억하자!

프로젝트 완료일로서 달력에 있는 특정 날짜를 알려주지 마세요 . ▒

작업이 작아질수록, 작업을 예측하기 더 쉬워집니다. ▒

예측의 정밀도가 아닌, 예측의 정확도를 추구하세요. ▒