Jak wycenić zmianę zakresu (change request) krok po kroku

Klient w trakcie projektu prosi o zmianę: „dodajmy logowanie przez Google", „zróbmy jeszcze panel raportów". Pytanie nie brzmi „czy się da", tylko „ile to kosztuje i o ile przesuwa termin" – i jak policzyć to szybko, nie przeliczając całego projektu od nowa.

Zasada: licz różnicę, nie cały projekt

Nie wracaj do pełnej wyceny od zera. Policz tylko różnicę: co zmiana dodaje do zakresu, a co z niego zabiera. Różnica policzona tą samą metodą co pierwotna wycena jest spójna – Klient widzi ten sam sposób liczenia, zastosowany do jednej zmiany.

Krok po kroku

• 1. Weź pierwotny zakres prac (SOW) albo wcześniejszą wycenę – to punkt odniesienia, względem którego liczysz.
• 2. Wypisz, co dochodzi i co znika. Konkretne funkcje albo moduły, nie ogólniki w stylu „usprawnienia".
• 3. Policz różnicę w roboczodniach tą samą metodą co pierwotna wycena. Pamiętaj, że nowa funkcja podbija nie tylko samo programowanie, ale też pracę operacyjną (zarządzanie, testy, wdrożenie).
• 4. Uwzględnij redukcję. Jeśli coś z zakresu wypada, różnica bywa ujemna – zmiana potrafi też obniżyć budżet.
• 5. Pokaż „przed i po". Budżet i czas sprzed zmiany obok budżetu i czasu po zmianie – nie samą dopłatę.

Najczęstsze błędy

• Przeliczanie całego projektu od nowa – wolne i niepotrzebnie miesza w liczbach, które były już ustalone.
• Liczenie samego kodu, bez pracy operacyjnej – ta sama pułapka co przy pierwszej wycenie.
• Liczenie „na oko" – albo zaniżasz, albo nowa wycena nie spina się z pierwotną.
• Pokazanie samej kwoty dopłaty, bez kontekstu przed/po – brzmi jak doliczanie, nie jak decyzja.

Policz różnicę automatycznie

Zamiast liczyć ręcznie, możesz wkleić pierwotny zakres i opis zmiany do wyceny zmiany zakresu – dostaniesz różnicę w roboczodniach i kartę „przed/po" do wysłania Klientowi. Narzędzie liczy ją tą samą metodą co pełna wycena z briefu. A skąd biorą się straty, gdy zmian się nie wycenia, opisałem w tekście o koszcie scope creep.