W tym artykule

Problem priorytetyzacji i inflacji wymagań (ang. scope creep, requirement inflation) to dziś jedno z największych wyzwań inżynierii oprogramowania i zarządzania produktem. Zjawisko polega na gwałtownym, często niekontrolowanym wzroście liczby i złożoności funkcji, które system zdaniem interesariuszy „powinien” mieć, i to tylko dlatego, że narzędzia AI ułatwiły ich generowanie i wdrażanie.

Scope creep oznaczał kiedyś powolne rozrastanie się zakresu projektu: tu dodatkowy raport, tam jeszcze jedno pole w formularzu. Z AI ten proces przyspiesza, bo zniknął jego hamulec. Dawniej każdy pomysł trzeba było wycenić w tygodniach pracy programistów i już ta cena odsiewała część próśb. Dziś pierwsza wersja funkcji powstaje w godzinę, a koszt, który naprawdę się liczy, pojawia się później i trudniej go zauważyć.

Inflacja wymagań to jeden ze skutków szerszej zmiany, którą opisujemy we wpisie o zarządzaniu projektami w dobie agentów AI: wykonanie zadań się skraca, a ciężar projektu przesuwa się na definicję problemu i sprawdzanie wyniku.

Dlaczego AI napędza inflację wymagań

Prototyp za darmo, czyli złudzenie taniej funkcji

Asystent AI w kilka minut napisze kod formularza, raportu czy integracji. Działający prototyp przekonuje bardziej niż slajd, więc łatwo uznać, że skoro coś da się szybko zbudować, to warto to mieć. Tymczasem napisanie kodu to niewielka część kosztu funkcji. Resztę płaci się latami: za testy, poprawki, aktualizacje, wsparcie użytkowników i bezpieczeństwo.

Wymagania, które piszą się same

AI generuje nie tylko kod, ale też specyfikacje. Wystarczy poprosić o „historyjki użytkownika dla modułu rozliczeń”, a po minucie jest ich czterdzieści, każda sensowna i porządnie opisana. Lista wymagań, która dawniej powstawała przez tydzień warsztatów, rośnie w jedno popołudnie. Zdolność zespołu do oceny, które z nich są naprawdę potrzebne, nie rośnie w tym samym tempie.

Każdy ma swój prototyp

Pomysły nie przychodzą już tylko jako zgłoszenia w systemie. Coraz częściej ktoś ze sprzedaży czy z księgowości przynosi gotowy prototyp, który sam zbudował z pomocą AI: „to już prawie działa, wystarczy podpiąć”. Trudno odmówić czemuś, co wygląda na skończone, choć do wersji produkcyjnej brakuje mu uprawnień, obsługi błędów, danych z prawdziwych systemów i testów.

Presja, żeby „mieć AI”

Część wymagań nie wynika z problemu użytkownika, tylko z technologii: „konkurencja ma asystenta, my też powinniśmy”. Taka funkcja zaczyna się od rozwiązania, a problem dopisuje się do niej później. Do tego funkcje oparte na modelach językowych mają własną, ukrytą złożoność. Ich odpowiedzi nie są w pełni przewidywalne, więc trzeba je oceniać i monitorować, a ktoś musi pilnować, do jakich danych model ma dostęp.

Efekt demo

Efektowny pokaz zbudowany w dwa dni łatwo zamienia się w obietnicę dla klienta albo zarządu. Demo pokazuje jednak najlepszy scenariusz. Przypadki brzegowe, wydajność na prawdziwych danych, uprawnienia i zgodność z przepisami zostają poza kadrem, ale nie poza zakresem projektu.

Konsekwencje inflacji wymagań

Skutki nie pojawiają się od razu i właśnie dlatego są groźne. Każda pojedyncza funkcja wygląda niewinnie, problemem jest ich suma.

  • Rosnący koszt utrzymania. Każda funkcja to kod do testowania, aktualizowania i zabezpieczania, dokumentacja do napisania i pytania użytkowników, na które ktoś musi odpowiedzieć. Kod wygenerowany przez AI też trzeba zrozumieć, zanim się go poprawi, a zrozumienie cudzego kodu, nawet napisanego przez maszynę, zajmuje czas.
  • Rozmyty produkt. Im więcej opcji, tym trudniej znaleźć tych kilka, po które użytkownik przyszedł. Wdrożenie nowych osób trwa dłużej, przybywa pomyłek i zgłoszeń do pomocy technicznej.
  • Wartość dociera wolniej. Paradoks polega na tym, że kod powstaje szybciej, a ważne zmiany docierają do użytkowników wolniej. Zespół rozdziela uwagę między dziesiątki drobnych funkcji, a każda wymaga przeglądu, testów i integracji.
  • Dług techniczny i jakościowy. Funkcje dodane „przy okazji” rzadko mają porządne testy i właściciela. Po kilku miesiącach nikt nie wie, kto z nich korzysta i czy można je bezpiecznie zmienić.
  • Większa powierzchnia ataku. Każdy nowy formularz, integracja czy asystent AI to kolejne miejsce, przez które przechodzą dane firmy. Trzeba ustalić, kto ma do nich dostęp, w czyim imieniu działa system i gdzie zostaje ślad jego działań.
  • Koszty, które rosną z użyciem. Za funkcje oparte na AI często płaci się od każdego wywołania modelu. Pilotaż na dziesięciu osobach wygląda tanio, a rachunek dla całej firmy może wyglądać zupełnie inaczej.
  • Priorytetyzacja zamienia się w teatr. Backlog z kilkuset pozycji przestaje być narzędziem do podejmowania decyzji. Wszystko jest „ważne”, więc w praktyce o kolejności decyduje ten, kto głośniej prosi.

Jak sobie z tym radzić: nowe podejście do priorytetyzacji w dobie AI

Skoro koszt zbudowania funkcji przestał być naturalnym filtrem, filtr trzeba zbudować świadomie. Pomagają w tym trzy narzędzia: całkowity koszt posiadania (TCO), dobrze zdefiniowane MVP i testowanie najbardziej ryzykownego założenia (RAT).

TCO: licz koszt posiadania, nie koszt napisania

Całkowity koszt posiadania (ang. Total Cost of Ownership, TCO) to wszystko, co funkcja kosztuje przez cały okres życia, a nie tylko w chwili budowy. Zanim padnie decyzja „robimy”, warto przejść przez krótką listę:

  1. Budowa: z AI często najtańsza pozycja.
  2. Weryfikacja: przegląd kodu, testy, sprawdzenie wyników AI.
  3. Utrzymanie: aktualizacje zależności, poprawki, zmiany w integracjach.
  4. Bezpieczeństwo i zgodność: uprawnienia, ochrona danych, audyty.
  5. Eksploatacja: infrastruktura i koszt wywołań modeli przy pełnym użyciu.
  6. Ludzie: dokumentacja, szkolenia, wsparcie użytkowników.
  7. Wycofanie: ile będzie kosztowało usunięcie funkcji, gdy przestanie być potrzebna.

Popularne metody oceny, takie jak RICE czy WSJF, dzielą wartość przez nakład pracy. Z AI szacowany nakład na budowę spada, więc nagle każda funkcja wygląda na opłacalną. Wystarczy w miejsce nakładu wstawić TCO, żeby ranking znów odpowiadał rzeczywistości. Proste pytanie kontrolne: kto za dwa lata będzie odpowiadał za tę funkcję i ile go to będzie kosztowało?

MVP: zacznij od problemu, nie od listy funkcji

MVP (ang. Minimum Viable Product) to najmniejsza wersja produktu, która pozwala sprawdzić, czy rozwiązujemy prawdziwy problem prawdziwych użytkowników. Z AI łatwo o pokusę, żeby „minimum” rozumieć jako „wszystko, co zdążymy wygenerować przed terminem”. Tymczasem „minimum” dotyczy zakresu, a nie wysiłku.

Dobrze zdefiniowane MVP zaczyna się od kilku zapisanych odpowiedzi:

  • Jaki problem rozwiązujemy i dla kogo? Jedno, dwa zdania, bez nazw funkcji.
  • Po czym poznamy sukces? Mierzalny wynik, na przykład krótszy czas obsługi sprawy albo mniej błędów, a nie „wdrożenie modułu”.
  • Co jest poza zakresem? Lista rzeczy, których świadomie nie robimy w tej wersji. To często najważniejsza część dokumentu, bo właśnie ona chroni projekt przed inflacją.
  • Kto decyduje o zmianie zakresu? Każde nowe wymaganie trafia do jednej osoby albo zespołu, który zna cel MVP.

Taka definicja to w dużej mierze praca, którą wykonuje się w analizie przedwdrożeniowej. Gdy AI skraca budowę, dobra analiza na starcie zyskuje na znaczeniu, bo błąd w zakresie szybciej niż kiedykolwiek zamienia się w gotowy kod.

RAT: najpierw przetestuj najbardziej ryzykowne założenie

RAT (ang. Riskiest Assumption Test) odwraca kolejność myślenia. Zamiast pytać „co zbudować w pierwszej wersji?”, pyta „które założenie, jeśli okaże się fałszywe, pogrzebie cały pomysł?” i szuka najtańszego sposobu, żeby je sprawdzić. Często nie trzeba do tego w ogóle budować produktu.

Z AI to podejście nabiera nowego sensu. Tani prototyp przestaje być zobowiązaniem i staje się narzędziem eksperymentu, które po teście można wyrzucić. Przykładowy przebieg:

  1. Wypisz założenia. Że użytkownicy mają ten problem, że zechcą zmienić sposób pracy, że dane są dostępne i wystarczająco dobre, że koszty eksploatacji się zepną.
  2. Wybierz najbardziej ryzykowne. To, które jest jednocześnie najmniej pewne i najważniejsze dla powodzenia.
  3. Zaprojektuj najtańszy test. Rozmowy z pięcioma użytkownikami, makieta, prototyp zbudowany z AI w jeden dzień albo ręczne wykonanie usługi „za kulisami”.
  4. Ustal kryterium z góry. Zanim zobaczysz wyniki, zapisz, jaki wynik oznacza „idziemy dalej”, jaki „zmieniamy kierunek”, a jaki „rezygnujemy”.
  5. Podejmij decyzję i ją zapisz. Po teście prototyp trafia do kosza albo do zaplanowanej, porządnej realizacji. Nigdy prosto na produkcję.

Zasady na co dzień

TCO, MVP i RAT działają najlepiej, gdy wspiera je kilka prostych nawyków zespołu:

  • Każde wymaganie zaczyna się od problemu. Zgłoszenie „chcemy asystenta AI w module X” wraca z pytaniem: jaki problem ma rozwiązać i jak zmierzymy, że go rozwiązał?
  • Budżet złożoności. Ustal, ile nowych funkcji produkt może przyjąć w danym okresie. Gdy budżet jest wyczerpany, nowa funkcja wchodzi tylko w miejsce innej.
  • Prototyp to nie obietnica. Oznaczaj prototypy jako jednorazowe i nie pokazuj ich klientom jako zapowiedzi produktu bez decyzji zespołu.
  • Regularne porządki. Raz na kwartał sprawdź, z których funkcji nikt nie korzysta, i zaplanuj ich wycofanie. Usunięta funkcja nie generuje już kosztów.
  • Ślad decyzji. Zapisuj, kto ustalił priorytet, kiedy i na jakiej podstawie. Za pół roku pozwoli to odróżnić świadome decyzje od tych, które „same się podjęły”.

Podsumowanie

Sztuczna inteligencja nie wymyśliła inflacji wymagań, ale zwolniła jej hamulec. Gdy zbudowanie funkcji zajmuje godzinę, pytanie „czy da się to zrobić?” traci sens. Liczy się pytanie „czy warto to mieć i utrzymywać?”. Zespoły, które liczą całkowity koszt posiadania, trzymają się wąsko zdefiniowanego MVP i najpierw testują najbardziej ryzykowne założenia, wykorzystują AI do szybszego uczenia się, a nie do szybszego puchnięcia produktu.

Chcesz uporządkować zakres swojego projektu? Napisz do nas.