2025년 11월 30일 일요일

번다운 차트가 거짓말하는 이유: 스코프 크립과의 전쟁

번다운 차트가 이렇게 생겼다면 정말 잘 진행되고 있는 걸까요?

남은 작업
100 |\
 80 | \
 60 |  \
 40 |   \
 20 |    \
  0 |_____\
    Day 1 2 3 4 5

완벽해 보이죠? 하지만 현실은...

남은 작업
100 |\___
 80 |     \____
 60 |           ↗️ (갑자기 증가?!)
 40 |         \___💥
 20 |              \____???
  0 |_____________________
    Day 1 2 3 4 5 6 7 8 9 10...

번다운이 안 되고 있습니다. 오히려 번업(Burn-up)이 되고 있네요.

스코프 크립: 프로젝트의 조용한 살인자

스코프 크립(Scope Creep)은 프로젝트 진행 중 요구사항이 슬금슬금 추가되는 현상입니다.

마치 체중계에 올라가 있는데 누군가 계속 추를 올려놓는 것과 같죠.

실제 대화록

Day 1 (킥오프 미팅)

PM: "로그인, 회원가입, 프로필 페이지만 만들면 됩니다."
개발팀: "2주면 충분합니다!"

Day 3

PM: "아, 소셜 로그인도 추가해주세요. 간단하잖아요?"
개발팀: "음... 네..." 
(속마음: 구글, 페이스북, 카카오, 애플... 간단하다고?)

Day 5

CEO: "경쟁사 보니까 다크모드 있던데, 우리도 넣어요."
개발팀: "..." 
(속마음: CSS 다 뜯어고쳐야 하는데...)

Day 7

마케팅: "이메일 인증도 필요할 것 같아요!"
개발팀: "하..." 
(속마음: 메일 서버, 템플릿, 인증 로직...)

Day 10

PM: "왜 아직 안 끝났죠? 2주라고 했잖아요?"
개발팀: "???" 
(속마음: 작업이 2배가 됐는데?)

스코프 크립의 유형별 분석

1. 순진한 크립 (Innocent Creep)

"이것도 간단하니까 추가해주세요~"

# PM의 생각
additional_work = {
    "다크모드": "CSS 몇 줄",  # 실제: 200개 컴포넌트 수정
    "알림 기능": "DB 필드 하나",  # 실제: 푸시, 이메일, 인앱, 설정...
    "다국어": "텍스트 교체"  # 실제: i18n 시스템 구축
}

2. 정치적 크립 (Political Creep)

"CEO가 원하시는데..."

const political_additions = {
    source: "C-Level",
    negotiable: false,
    priority: "URGENT",
    impact: "전체 일정 30% 지연",
    developer_morale: -50
};

3. 완벽주의 크립 (Perfectionist Creep)

"이왕 하는 김에 제대로..."

원래: 기본 검색
├── "이왕이면 자동완성도"
├── "검색 히스토리도 있으면 좋겠네"
├── "필터링 기능도 추가하죠"
├── "AI 추천도 넣어볼까요?"
└── 결과: Elasticsearch + ML 모델 = 3개월 프로젝트

4. 경쟁사 크립 (Competitor Creep)

"경쟁사가 이런 기능을 출시했대요!"

매일 경쟁사 기능이 추가되면, 우리 제품은 언제 완성될까요?

번다운 차트의 진실

이상적인 번다운

작업량
100 |*
 75 |  *
 50 |    *
 25 |      *
  0 |________*
    1  2  3  4  5 (스프린트)

실제 번다운 (스코프 크립 포함)

작업량
100 |*
 75 |  *___
 50 |      *___*  ← 추가 요구사항
 25 |           *___*  ← 또 추가
  0 |________________???
    1  2  3  4  5  6  7  8... (언제 끝?)

정직한 번다운 (번업 차트 병행)

작업량
150 |          ___총 작업량 (계속 증가)
100 |*    ____/
 50 |  *_/  완료 작업
  0 |________________
    1  2  3  4  5  6

Gap = 스코프 크립의 실체

스코프 크립 방어 전략

1. 변경 요청서 의무화

## 변경 요청서 템플릿

### 요청 사항
- 무엇을: 
- 왜: 

### 영향도 분석
- 추가 시간: [ ]시간
- 영향받는 기능: 
- 리스크: 

### 우선순위
- [ ] 필수 (이번 릴리즈)
- [ ] 중요 (다음 릴리즈)
- [ ] 있으면 좋음 (백로그)

### 승인
- PM: [ ]
- 개발 리드: [ ]
- 이해관계자: [ ]

2. 트레이드오프 원칙

"하나를 추가하려면 하나를 빼세요"

def handle_new_request(new_feature, current_sprint):
    """새 기능 요청 처리"""
    
    if new_feature.is_critical():
        # 중요하면 다른 것과 교환
        removed = current_sprint.remove_lowest_priority()
        current_sprint.add(new_feature)
        return f"추가: {new_feature}, 제거: {removed}"
    else:
        # 중요하지 않으면 백로그로
        backlog.add(new_feature)
        return "다음 스프린트에 검토"

3. 스코프 버퍼 확보

const sprint_planning = {
    committed_work: 70,  // 70%만 약속
    buffer: 20,          // 20% 버퍼
    innovation: 10       // 10% 실험
};

// 스코프 크립이 와도 버퍼로 흡수

4. 일일 델타 추적

# 매일 변경사항 추적
daily_delta = {
    "Day1": {
        "added": [],
        "removed": [],
        "modified": ["로그인 UI"],
        "delta": 0
    },
    "Day2": {
        "added": ["소셜 로그인"],  # +8시간
        "removed": [],
        "modified": [],
        "delta": +8
    }
}

# 델타가 양수면 경고!
if sum(daily_delta.values()) > 0:
    alert("스코프 크립 발생!")

실제 사례: 2주 프로젝트가 3개월이 된 이야기

Week 1-2: 순조로운 시작

  • 계획: 기본 CRUD
  • 진행: 50% 완료

Week 3: 첫 번째 크립

  • 추가: "실시간 알림도 있으면 좋겠네요"
  • 영향: WebSocket 서버 구축 필요

Week 4: 두 번째 크립

  • 추가: "모바일 앱도 만들어주세요"
  • 영향: React Native 추가 개발

Week 6: 세 번째 크립

  • 추가: "AI 추천 기능도..."
  • 영향: ML 파이프라인 구축

Week 12: 프로젝트 종료(?)

  • 원래 계획: 2주
  • 실제: 12주
  • 비용: 6배
  • 팀 사기: 바닥

스코프 크립 체크리스트

프로젝트가 스코프 크립에 빠졌는지 확인:

  •  번다운 차트가 평평하거나 올라감
  •  "간단한 추가"라는 말을 자주 들음
  •  원래 요구사항 문서가 어디 갔는지 모름
  •  매주 새로운 기능 요청
  •  팀원들이 "이게 뭐였죠?"라고 자주 물음
  •  완료 기준이 계속 바뀜

3개 이상? 스코프 크립 진행 중!

스코프 크립과 공존하기

완전히 막을 수는 없습니다. 비즈니스는 변하니까요.

건강한 변경 관리

class ChangeManagement:
    def __init__(self):
        self.change_budget = 20  # 전체의 20%까지 변경 허용
        self.used_budget = 0
    
    def request_change(self, change):
        if self.used_budget + change.size <= self.change_budget:
            self.approve(change)
            self.used_budget += change.size
        else:
            self.defer_to_next_sprint(change)

투명한 커뮤니케이션

## 주간 스코프 리포트

### 이번 주 변경사항
- 추가: 다크모드 (8시간)
- 제거: 프로필 편집 (6시간)
- 순 증가: 2시간

### 전체 영향
- 원래 완료일: 3/15
- 새 완료일: 3/17
- 지연: 2일

### 리스크
- 추가 변경 시 3월 내 완료 불가능

번다운 차트 개선안

1. 스코프 라인 추가

작업량
150 |      _____ 스코프 라인 (변경 추적)
100 |*    /
 50 |  *_/  번다운 라인
  0 |________________
    1  2  3  4  5  6

2. 신뢰 구간 표시

작업량
100 |*
 75 |  *±10  ← 불확실성 표시
 50 |    *±15
 25 |      *±20
  0 |________?

3. 번업 차트 병행

완료한 일 vs 전체 일을 동시에 보여주면 스코프 크립이 명확히 보입니다.

마무리: 스코프를 지키는 것도 용기

"아니요"라고 말하는 것은 어렵습니다.

하지만 모든 요청을 받아들이면:

  • 프로젝트는 끝나지 않고
  • 팀은 지치고
  • 제품은 복잡해지고
  • 아무도 만족하지 못합니다

좋은 PM의 조건:

  1. 명확한 스코프 정의
  2. 변경에 대한 영향 분석
  3. 트레이드오프 협상
  4. 투명한 진행 상황 공유

번다운 차트가 거짓말하지 않게 하려면, 우리가 먼저 정직해야 합니다.

"이 기능을 추가하면 2주 늦어집니다. 그래도 하시겠습니까?"

이 질문이 프로젝트를 구합니다.

스코프 관리와 정확한 번다운 추적이 필요하신가요? Plexo를 확인해보세요.

작성자: 시간:
라벨: , , , ,

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)