번다운 차트가 거짓말하는 이유
스코프 크립과의 전쟁
이상적인 번다운 차트를 상상해보세요.
남은 작업이 100에서 80, 60, 40, 20, 0으로 완벽하게 내려가는 모습입니다.
완벽해 보이죠? 하지만 현실은...
남은 작업이 100에서 80으로 내려가다가 60에서 갑자기 증가하고, 40에서 또 증가하며, 20에서 계속 증가하는 번업(Burn-up) 현상이 발생합니다.
번다운이 안 되고 있습니다. 오히려 번업이 되고 있네요.
스코프 크립: 프로젝트의 조용한 살인자
스코프 크립(Scope Creep)은 프로젝트 진행 중 요구사항이 슬금슬금 추가되는 현상입니다.
마치 체중계에 올라가 있는데 누군가 계속 추를 올려놓는 것과 같죠.
실제 대화록
Day 1(킥오프 미팅)에 PM이 "로그인, 회원가입, 프로필 페이지만 만들면 됩니다."라고 하고, 개발팀이 "2주면 충분합니다!"라고 했습니다.
Day 3에 PM이 "아, 소셜 로그인도 추가해주세요. 간단하잖아요?"라고 하면, 개발팀은 "음... 네..."라고 하지만 속마음은 구글, 페이스북, 카카오, 애플... 간단하다고?입니다.
Day 5에 CEO가 "경쟁사 보니까 다크모드 있던데, 우리도 넣어요."라고 하면, 개발팀은 "..."라고 하지만 속마음은 CSS 다 뜯어고쳐야 하는데...입니다.
Day 7에 마케팅이 "이메일 인증도 필요할 것 같아요!"라고 하면, 개발팀은 "하..."라고 하지만 속마음은 메일 서버, 템플릿, 인증 로직...입니다.
Day 10에 PM이 "왜 아직 안 끝났죠? 2주라고 했잖아요?"라고 하면, 개발팀은 "???"라고 하지만 속마음은 작업이 2배가 됐는데?입니다.
스코프 크립의 유형별 분석
첫 번째는 순진한 크립(Innocent Creep)입니다. "이것도 간단하니까 추가해주세요~"라고 하지만, PM의 생각과 실제는 다릅니다. 다크모드는 "CSS 몇 줄"이라고 생각하지만 실제는 200개 컴포넌트 수정이고, 알림 기능은 "DB 필드 하나"라고 생각하지만 실제는 푸시, 이메일, 인앱, 설정...이고, 다국어는 "텍스트 교체"라고 생각하지만 실제는 i18n 시스템 구축입니다.
두 번째는 정치적 크립(Political Creep)입니다. "CEO가 원하시는데..."라고 하면 source는 C-Level, negotiable은 false, priority는 URGENT, impact는 전체 일정 30% 지연, developer_morale은 -50입니다.
세 번째는 완벽주의 크립(Perfectionist Creep)입니다. "이왕 하는 김에 제대로..."라고 하면 원래 기본 검색에서 "이왕이면 자동완성도", "검색 히스토리도 있으면 좋겠네", "필터링 기능도 추가하죠", "AI 추천도 넣어볼까요?"로 결과는 Elasticsearch + ML 모델 = 3개월 프로젝트입니다.
네 번째는 경쟁사 크립(Competitor Creep)입니다. "경쟁사가 이런 기능을 출시했대요!"라고 하면 매일 경쟁사 기능이 추가되어 우리 제품은 언제 완성될까요?
번다운 차트의 진실
이상적인 번다운은 작업량이 100에서 75, 50, 25, 0으로 완벽하게 내려가는 차트입니다.
실제 번다운(스코프 크립 포함)은 작업량이 100에서 75로 내려가다가 50에서 추가 요구사항으로 증가하고, 25에서 또 추가로 증가하며, 0에 도달하지 못하는 차트입니다.
정직한 번다운(번업 차트 병행)은 총 작업량이 계속 증가하고, 완료 작업은 점점 늘어나지만, Gap이 스코프 크립의 실체입니다.
스코프 크립 방어 전략
첫 번째는 변경 요청서 의무화입니다. 변경 요청서 템플릿으로 요청 사항(무엇을, 왜), 영향도 분석(추가 시간, 영향받는 기능, 리스크), 우선순위(필수 이번 릴리즈, 중요 다음 릴리즈, 있으면 좋음 백로그), 승인(PM, 개발 리드, 이해관계자)을 명시합니다.
두 번째는 트레이드오프 원칙입니다. "하나를 추가하려면 하나를 빼세요"라는 원칙으로 새 기능 요청 처리 시 중요하면 다른 것과 교환하고, 중요하지 않으면 백로그로 보냅니다.
세 번째는 스코프 버퍼 확보입니다. 스프린트 계획으로 확정 작업 70%, 버퍼 20%, 혁신 10%로 구성하면 스코프 크립이 와도 버퍼로 흡수할 수 있습니다.
네 번째는 일일 델타 추적입니다. 매일 변경사항을 추적하여 추가된 작업, 제거된 작업, 수정된 작업, 델타를 기록하고, 델타가 양수면 경고합니다.
실제 사례: 2주 프로젝트가 3개월이 된 이야기
Week 1-2는 순조로운 시작으로 계획 기본 CRUD, 진행 50% 완료였습니다.
Week 3은 첫 번째 크립으로 "실시간 알림도 있으면 좋겠네요"를 추가하여 WebSocket 서버 구축이 필요했습니다.
Week 4는 두 번째 크립으로 "모바일 앱도 만들어주세요"를 추가하여 React Native 추가 개발이 필요했습니다.
Week 6은 세 번째 크립으로 "AI 추천 기능도..."를 추가하여 ML 파이프라인 구축이 필요했습니다.
Week 12에 프로젝트 종료(?)로 원래 계획 2주, 실제 12주, 비용 6배, 팀 사기 바닥이었습니다.
스코프 크립 체크리스트
프로젝트가 스코프 크립에 빠졌는지 확인합니다. 번다운 차트가 평평하거나 올라감, "간단한 추가"라는 말을 자주 들음, 원래 요구사항 문서가 어디 갔는지 모름, 매주 새로운 기능 요청, 팀원들이 "이게 뭐였죠?"라고 자주 물음, 완료 기준이 계속 바뀜 중 3개 이상 해당하면 스코프 크립 진행 중입니다.
스코프 크립과 공존하기
완전히 막을 수는 없습니다. 비즈니스는 변하니까요.
건강한 변경 관리로 ChangeManagement 클래스를 만들어 전체의 20%까지 변경을 허용하고, 사용된 버퍼를 추적하며, 버퍼를 초과하면 다음 스프린트로 미룹니다.
투명한 커뮤니케이션으로 주간 스코프 리포트를 작성합니다. 이번 주 변경사항으로 추가 다크모드 8시간, 제거 프로필 편집 6시간, 순 증가 2시간을 기록하고, 전체 영향으로 원래 완료일 3/15, 새 완료일 3/17, 지연 2일을 명시하며, 리스크로 추가 변경 시 3월 내 완료 불가능을 경고합니다.
번다운 차트 개선안
첫 번째는 스코프 라인 추가입니다. 작업량 차트에 스코프 라인(변경 추적)을 추가하여 번다운 라인과 비교합니다.
두 번째는 신뢰 구간 표시입니다. 작업량 차트에 불확실성을 표시하여 ±10, ±15, ±20으로 표시합니다.
세 번째는 번업 차트 병행입니다. 완료한 일 vs 전체 일을 동시에 보여주면 스코프 크립이 명확히 보입니다.
마무리: 스코프를 지키는 것도 용기
"아니요"라고 말하는 것은 어렵습니다.
하지만 모든 요청을 받아들이면 프로젝트는 끝나지 않고, 팀은 지치고, 제품은 복잡해지고, 아무도 만족하지 못합니다.
좋은 PM의 조건:
명확한 스코프 정의, 변경에 대한 영향 분석, 트레이드오프 협상, 투명한 진행 상황 공유입니다.
번다운 차트가 거짓말하지 않게 하려면, 우리가 먼저 정직해야 합니다.
"이 기능을 추가하면 2주 늦어집니다. 그래도 하시겠습니까?"
이 질문이 프로젝트를 구합니다.
스코프 관리와 정확한 번다운 추적이 필요하신가요? Plexo를 확인해보세요.
