변화하는 요구사항을 어떻게 다루나요?

Question

Accepted Answer

요구사항은 변합니다. 시장이 바뀌고, 사용자에게서 배우며, 우선순위가 움직입니다. 목표는 변경을 *막는* 것(불가능하고 바람직하지도 않습니다)이 아니라, 변경이 프로젝트를 탈선시키는 대신 프로덕트를 개선하도록 **의도적으로** 다루는 것입니다.

## 변화를 받아들이되, 통제하라

```text
✓ 변화를 예상하라 → 계획에 유연성을 넣어라(먼 미래에 과도하게 약속하지 마라)
✓ 각 변경을 평가하라 → 범위, 일정, 비용, 다른 작업에 미치는 영향
✓ 트레이드오프를 보이게 하라 → "예, 하지만 X가 들거나 Y가 밀립니다"
✓ stakeholder가 충분한 정보를 가지고 결정하게 하라
✓ 새 계획을 영향받는 모두에게 소통하라
```

핵심 규율은 scope 관리와 같습니다. 절대 변경을 조용히 흡수하지 마세요. 모든 변경은 누군가 책임지는 의식적인 트레이드오프입니다.

## 애자일이 도움이 되는 이유

애자일은 변화하는 요구사항을 위해 만들어졌습니다. 짧은 반복은 자주 우선순위를 다시 매긴다는 뜻이라, 변경이 1년짜리 계획을 망치는 대신 길어야 한 sprint를 기다립니다. 작은 단위로 일하면 어떤 단일 변경이 야기할 수 있는 재작업의 양을 제한합니다.

## 발견과 잦은 변동을 구분하라

```text
건강한 변화 → 새로운 배움, 문제에 대한 더 나은 이해
건강하지 않은 잦은 변동(churn) → 우유부단함, 불분명한 목표, 우선순위를 책임지는 사람 없음
```

요구사항이 끊임없이 흔들린다면 진짜 문제는 상류에 있습니다. 모호한 목표나 약한 우선순위 결정이며, 그것이 고쳐야 할 대상입니다.

## 구체적인 예시

sprint 중간에 사용자 리서치가 계획된 흐름이 사람들을 헷갈리게 한다는 것을 드러냅니다. 밀어붙이는 대신 평가합니다. 재작업에 3일이 들고 우선순위 낮은 항목이 밀립니다. 그 트레이드오프를 제시하고, PM이 동의하면 조정합니다. 혼란 없이 처리된, 프로덕트를 *더 낫게* 만든 변경입니다.

## 흔한 함정

모든 변경을 완강히 거부하거나(잘못된 줄 *아는* 것을 출시), 영향 평가 없이 모든 변경을 수용하는 것(만성적 지연과 번아웃)입니다.

## 왜 중요한가

적응 능력은 강점입니다. 변할 수 없는 소프트웨어는 서서히 구식이 되어가는 소프트웨어입니다.

변화를 잘 다루는 것(평가, 트레이드오프 가시화, 소통, 단위로 작업)은 전달의 통제력을 잃지 않으면서 현실에 반응할 수 있게 합니다.