팀이 과부하 상태일 때, 무엇을 먼저 할지 결정하는 데 어떤 기준을 쓰나요?

Question

Accepted Answer

**먼저 저는 과부하를 가시화하고 모든 것이 다 들어맞는 척을 멈춥니다.** 팀이 과부하일 때의 실패 모드는 모든 것을 조금씩 하면서 아무것도 끝내지 못하는 것입니다. 제 일은 명시적 우선순위 결정을 강제하고 팀을 휘둘림으로부터 보호하는 것입니다.

## 제가 적용하는 기준

- **영향 대 노력.** 비용 대비 전달되는 가치로 작업의 순위를 매깁니다. 영향 높고 노력 적은 항목이 먼저; 노력 높고 영향 적은 항목은 공개적으로 잘리거나 미뤄집니다.
- **되돌릴 수 있는가와 긴급성.** 되돌릴 수 없거나 시간이 정해진 것(보안 수정, 계약 마감, 출시 의존성)은 줄을 앞지릅니다.
- **지연 비용.** 어떤 작업은 미룰수록 비싸집니다(누적되는 **tech debt**, 마감 페널티); 어떤 작업은 다음 달에도 똑같습니다. 비용이 얼마나 빨리 커지는지로 우선순위를 정합니다.
- **타인을 막고 있는가.** 다른 사람이나 팀의 막힘을 풀어주는 작업은 그 자체의 가치를 넘어서는 승수를 갖습니다.
- **리스크.** 이것이 틀리거나 늦으면 비용이 얼마인가? 값비싼 실패부터 먼저 방어합니다.

## 간단한 프레임워크

| 버킷 | 예시 | 조치 |
|---|---|---|
| 치명적 + 긴급 | 프로덕션 incident, 보안 구멍 | 지금 하고, 다른 작업 중단 |
| 가치 높음, 긴급 아님 | 핵심 roadmap 기능 | 일정 잡고 보호 |
| 가치 낮음, 긴급 | 시끄럽지만 사소한 요청 | 밀어내거나 위임 |
| 가치 낮음, 긴급 아님 | 있으면 좋은 것 | 명시적으로 거절하고 잘라냄 |

## 어떻게 운영하는가

- 다섯 개의 병렬 1순위가 아니라 **단일 순위 리스트**를 만듭니다. 모든 것이 우선순위라면, 아무것도 우선순위가 아닙니다.
- **stakeholder**에게 트레이드오프를 평범한 말로 소통합니다: "이번 스프린트에 A나 B는 할 수 있지만 둘 다는 안 됩니다. 무엇이 더 중요한가요?"
- 집중을 보호합니다: 진행 중 작업을 제한하고, 컨텍스트 스위칭을 줄이며, 스프린트 중간의 새 인터럽트로부터 팀을 보호합니다.

## 함정

- 데이터 대신 가장 시끄러운 stakeholder가 우선순위를 정하게 두기.
- 모든 것에 예라고 하기 — 이는 사실 "무작위가 결정하게 두겠다"는 뜻입니다.
- 범위를 맞추려고 조용히 품질을 깎기; 그것은 비용을 프로덕션으로 옮길 뿐입니다.

## 왜 중요한가

과부하 상황에서, 무자비하고 투명한 우선순위 결정은 스트레스받고 휘둘리는 팀을 실제로 중요한 것을 출시하는 팀으로 바꿔주며, 모든 것을 조용히 놓치는 대신 트레이드오프에 정직함으로써 stakeholder와의 신뢰를 지켜줍니다.

버킷	예시	조치
치명적 + 긴급	프로덕션 incident, 보안 구멍	지금 하고, 다른 작업 중단
가치 높음, 긴급 아님	핵심 roadmap 기능	일정 잡고 보호
가치 낮음, 긴급	시끄럽지만 사소한 요청	밀어내거나 위임
가치 낮음, 긴급 아님	있으면 좋은 것	명시적으로 거절하고 잘라냄