scope를 어떻게 관리하고 scope creep을 어떻게 피하나요?

Question

Accepted Answer

**scope(범위)**는 프로젝트가 전달하기로 합의된 작업의 집합입니다. **scope creep**은 그 범위가 점진적이고 통제되지 않은 채 확장되는 것, 즉 슬그머니 일정을 무너뜨리는 "작은 추가"의 끊임없는 흐름입니다. scope를 관리한다는 것은 변경을 거부하는 것이 아니라 *변경을 통제*하는 것입니다.

## 처음에 scope를 명확히 정의하라

```text
✓ 범위에 포함되는 것을 문서화한다
✓ 명시적으로 범위 밖인 것을 문서화한다(덜 쓰이는 나머지 절반)
✓ "완료" / acceptance criteria를 정의한다
✓ 작업 시작 전에 stakeholder의 동의를 받는다
```

문서화되고 합의된 경계가 나중에 증거를 가지고 "그것은 변경입니다"라고 말할 수 있게 합니다.

## 변경을 의도적으로 다뤄라

변경은 나쁘지 않습니다. 통제되지 않은 변경이 나쁩니다. 새 요청이 들어오면 간단한 관문을 통과시키세요.

```text
1. 정말 지금 필요한가, 아니면 "있으면 좋은 것"인가?
2. 일정 / 비용 / 다른 작업에 미치는 영향은 무엇인가?
3. 트레이드오프를 보이게 하라 → "예, 하지만 날짜가 밀리거나 X를 뺍니다"
4. stakeholder가 충분한 정보를 가지고 결정하게 하라
```

핵심 움직임: 절대 추가 작업을 조용히 흡수하지 마세요. 모든 추가를 stakeholder가 책임지는 의식적인 트레이드오프로 만드세요.

## 구체적인 예시

프로젝트 중간에 stakeholder가 "대량 업로드도 지원해 주세요. 금방 될 거예요"라고 요청합니다. 끼워 넣는 대신 이렇게 답하세요. "할 수 있지만, 약 일주일이 더 듭니다. 날짜를 옮길까요, 아니면 분석 기능을 다음 릴리스로 미룰까요?" 이제 비용을 테이블 위에 올려놓은 채 그들의 결정이 됩니다.

## 흔한 함정

도움이 되려고 모든 요청에 예라고 한 뒤 마감을 놓치는 것입니다. 실제로는 조용히 추가 작업을 떠안았는데, 팀이 실패한 것처럼 보이게 됩니다.

## 왜 중요한가

scope creep은 프로젝트가 미끄러지는 가장 흔한 이유입니다. 어느 한 변경이 커서가 아니라, 수십 개가 보이지 않게 쌓이기 때문입니다.

scope 관리는 프로젝트를 정직하게 유지합니다. 변경은 괜찮지만, 그 비용은 항상 명시적으로 만들어지고 그것을 원하는 사람이 책임집니다.