Jak zarządzasz pełzaniem zakresu na projekcie?

Question

Accepted Answer

**Scope creep**, stałe gromadzenie się "jeszcze jednej rzeczy", to sposób, w jaki projekty na dobrej drodze cicho poślizgują się. Rozwiązanie nie polega na odrzuceniu wszystkiego; chodzi o to, aby **każde dodanie było widocznym, wyraźnym kompromisem** wobec czasu, zamiast cichego wchłonięcia.

## Jak kontrolować zakres

```text
✓ Define DONE up front — written, agreed scope
✓ Make the cost of every addition VISIBLE ("yes, and that pushes us a week")
✓ Track changes — a changelog of what got added/cut
✓ Protect a core MVP — defend the must-haves fiercely
✓ Use a PARKING LOT — capture good ideas for "later," don't reject them
✓ Escalate trade-offs to whoever owns priority — let them choose
```

## Kluczowy ruch

Nie odmów nowych żądań od razu, to cię robi blokerem. Zamiast tego wysuń kompromis na powierzchnię: "Możemy to dodać. Oznacza to, że albo termin przesunie się o tydzień, albo porzucimy funkcję X. Co chcesz?" Teraz to *biznesowa* decyzja, podejmowana przez właściwą osobę, z otwartymi oczami.

## Konkretny przykład

W połowie projektu PM ciągle dodaje "małe" zmiany. Rozpoczynasz wspólny dziennik zmian zakresu. Nagle wszyscy widzą, że oryginalny dwutygodniowy projekt wchłonął trzy tygodnie uzupełnień, a rozmowa o terminie staje się oczywista i łatwa.

## Dlaczego to ważne

Niekontrolowane pełzanie zakresu to cichy zabójca terminów, żadna pojedyncza zmiana nie wydaje się duża, ale łączą się w porażkę.

Udostępnienie kompromisów utrzymuje zespół chroniony, interesariuszy poinformowanych, a winę z inżynierii z dala, gdy przyczyną był zakres, a nie wysiłek.