W wielu projektach IT pojawia się pytanie: „Dlaczego każda dodatkowa poprawka lub modyfikacja jest uznawana za pracę rozwojową i musi być dodatkowo rozliczana? Przecież to błąd!”. W praktyce istnieje jednak cienka granica pomiędzy błędem (bugiem) a zmianą (change requestem). Poniżej wyjaśniamy podstawowe różnice i przedstawiamy, dlaczego ma to tak duże znaczenie w rozliczeniach w modelu “Time & Material” (T&M).

Czym jest błąd (bug)?

Błąd to niezamierzone, nieprawidłowe działanie aplikacji lub jej funkcjonalności, wynikające z niewłaściwej implementacji wymagań opisanych w specyfikacji. Mówiąc prościej: coś miało działać w określony sposób (zapisany w dokumentacji czy ustaleniach), ale działa niepoprawnie.

Przykłady błędów:

• Formularz miał zapisywać dane do bazy, ale tego nie robi.
• Strona logowania nie wyświetla komunikatu o błędnym haśle, mimo że była to część ustalonych wymagań.
• Przy wprowadzaniu liczby do koszyka pojawia się błędny wynik obliczeń, choć w dokumentacji opisano właściwą logikę.

W modelu T&M, jeżeli dana funkcjonalność jest wyraźnie zapisana w ustaleniach, a jej realizacja jest niezgodna z tymi ustaleniami z winy wykonawcy, można to rozważać jako błąd do poprawy w ramach standardów jakości projektu.

Czym jest zmiana (change request)?

“Zmiana” to “dodanie nowej funkcjonalności” lub “modyfikacja istniejącej”, która nie była pierwotnie określona w ustaleniach projektowych lub specyfikacji. Zdarza się, że w trakcie trwania projektu pojawiają się nowe pomysły lub potrzeby biznesowe, o których nie było mowy na początku.

Przykłady zmian:

• Klient życzy sobie dodatkowego e-maila z potwierdzeniem zakupu, którego wcześniej nie przewidziano w projekcie.
• Nagle okazuje się, że potrzebna jest integracja z zewnętrznym systemem, bo pojawiły się nowe okoliczności biznesowe.
• Konieczne staje się dostosowanie projektu do nowych przepisów prawnych, nieznanych na etapie startu.

Każda tego rodzaju modyfikacja stanowi dodatkową pracę, którą należy odpowiednio zaplanować i “rozliczyć w modelu T&M”.

„Krzyżowe” zależności i ich wpływ na rozliczenia

Wielu konfliktów i nieporozumień w projektach IT wynika z tzw. „krzyżowych” zależności. Są to sytuacje, w których wprowadzenie nowej funkcjonalności lub modyfikacja istniejącej wpływa na działanie innych elementów systemu.

Przykładowy scenariusz

1. “Klient zgłasza prośbę o zmianę” – na przykład: „Chcemy dodać nową sekcję na stronie głównej, która będzie prezentowała wyróżnione produkty. Nie mieliśmy tego w pierwotnym zakresie, ale pomyśleliśmy, że będzie to świetny dodatek marketingowy.”
2. “Programista wprowadza nową sekcję” – aby to zrobić, często trzeba dodać nowe pola w bazie danych, zmodyfikować szablon strony, zmienić układ CSS itd.
3. “Konsekwencje w innych miejscach” – okazuje się, że zmiana układu strony powoduje przesunięcia w istniejących sekcjach (np. dział z rekomendacjami produktów się „rozjechał”), a odświeżanie listy wyróżnionych produktów koliduje z wcześniej wdrożonym mechanizmem sortowania.
4. “Klient przesyła zgłoszenie” – klient zauważa, że „w innym miejscu strony coś się rozjechało” i „sortowanie przestało działać poprawnie”. Z perspektywy klienta wygląda to na błąd (bo coś nie działa tak, jak działało wcześniej).
5. “Rzeczywistość” – to nie błąd pierwotnej funkcji, lecz “konsekwencja nowej zmiany”, czyli rozwojowego requestu (dodania nowej sekcji).

W opisanym przykładzie klient może powiedzieć:
„Skoro to się popsuło przez nową sekcję, to jest błąd, który powinniście naprawić w ramach poprzedniej pracy!”

Natomiast w praktyce jest to “dodatkowa praca rozwojowa” – należało uwzględnić te zależności i je zaimplementować. Podobnie jak w przypadku każdej nowej funkcjonalności, czas, który zespół spędza na dostosowaniu całego systemu, jest normalną częścią pracy rozwojowej i w modelu T&M musi zostać rozliczony. Nie ma znaczenia czy programista w całości zrobił to w pierwszym podejściu (z) czy najpierw zrobił 80% pracy (x) i potem 20% w wyniku pracy po interwencji klienta (y). W całości jest to praca nad projektem w wyniki zleconej żądanej zmiany.

Model T&M (Time & Material) – dlaczego każda godzina ma znaczenie i dlaczego to się opłaca?

W modelu “Time & Material” rozliczamy się za “rzeczywisty czas pracy” poświęcony na rozwój projektu. Oznacza to, że:

• Gdy wprowadzamy nową funkcjonalność, wyceniamy czas potrzebny na analizę, implementację i testy.
• Jeżeli w trakcie wychodzą dodatkowe prace (np. krzyżowe konsekwencje w innych miejscach, które trzeba poprawić), to również jest to czas, który należy rozliczyć.
• Nie ma tzw. „bezpłatnych poprawek”, ponieważ każda godzina specjalisty jest realnym kosztem a model Time & Material nie zakłada wkalkulowania ryzyka projektowego jak w przypadku ryczałtu.

Praktyczny przykład z rozliczeniem czasowym

Załóżmy, że implementacja nowej sekcji mogłaby pierwotnie zająć 10 godzin, ale:

• Programista ją wykonał w 7 godzin i praca po testach wyglądała na skończoną.
• Po wdrożeniu okazało się, że sekcja wpływa na inne elementy systemu, co wymaga dodatkowych 3 godzin pracy aby to dostosować.

“Łącznie” i tak wychodzi 10 godzin, które należy zafakturować. Problem pojawia się, gdy po pierwszych 7 godzinach klient stwierdza, że kolejne 3 godziny to już „błędy w waszej poprzedniej pracy” i powinny być zrobione w ramach tamtego czasu. Jednak w rzeczywistości to nie błąd, tylko naturalna konsekwencja wdrożenia “nowej” (nieprzewidzianej wcześniej) funkcjonalności, która wymaga dodatkowych prac i często pojawia się w wyniku testowania przez klienta na innych urządzeniach i rozdzielczościach. Istotne jest rozumienie, że to cały czas praca nad tym samym żądaniem zmiany i nie było by pewnie problemu, gdyby za pierwszym podejściem programista wykonał wszystko w 10 godzin, jednak praca nad produktami jest często pracą obu stron zaangażowanych w projekt i jest to proces który zakłada iteracje.

A co z rozliczeniem ryczałtowym?

W przypadku “ryczałtu” sprawa wygląda nieco inaczej. Jeśli w umowie określono jedną kwotę za realizację całości, to:

• Ustalany jest “zakres” obowiązków i funkcjonalności, które mają zostać wdrożone.
• Najczęściej w ryczałcie jest wkalkulowany “bufor” na ewentualne nieprzewidziane sytuacje projektowe (ale do określonego limitu).

Jeśli w trakcie projektu pojawiają się nowe życzenia czy rozszerzenia zakresu, zwykle podpisuje się “aneks” lub nową umowę na prace wykraczające poza pierwotnie uzgodniony zakres.

Dlaczego tak ważne jest precyzyjne określanie funkcjonalności?

Wiele nieporozumień wynika z rozbieżności między tym, “co uznawaliśmy za gotową funkcję”, a tym, “co naprawdę klient chciał otrzymać”. Im dokładniej są opisane wymagania i wyobrażenia o ostatecznym produkcie:

• Tym mniejsze ryzyko, że coś zostanie uznane za błąd, a w istocie będzie konsekwencją nieprzewidzianej zmiany.
• Tym łatwiej jest rozliczać faktyczną liczbę godzin przepracowanych w projekcie.

Podsumowanie i rekomendacje

1. Od początku rozróżniaj błąd od zmiany:
– Błąd: niezgodność z jasno określonym, istniejącym wymaganiem pierwotnym.
– Zmiana: nowa funkcjonalność, modyfikacja wymagań przekraczająca ustalenia lub uwzględnienie uwag w ramach opracowywanego żądania zmian.

2. “Pamiętaj o krzyżowych zależnościach”:
– Gdy nowa funkcja wpływa na inne obszary systemu, prace nad nią często wymagają dodatkowych korekt w tych obszarach.
– To normalny element rozwoju oprogramowania, a nie błąd, który „należy się w gratisie”.

3. Każda godzina w modelu T&M podlega rozliczeniu:
– Nie ma „bezpłatnych” poprawek, ponieważ każda kolejna godzina specjalisty to realny koszt.
– Jeśli w trakcie okaże się, że potrzebne są dodatkowe godziny (przy czym to nie jest ewidentny błąd w stosunku do wcześniej ustalonych wymagań), rozlicza się je dodatkowo.

4. Ryczałt a T&M:
– Ryczałt: jeden koszt za całość, ale z góry ustalony zakres i bufor. Zmiany przekraczające ustalenia często wymagają aneksów.
– T&M: płacisz za rzeczywisty czas i materiały. Każda nowa potrzeba czy modyfikacja zwiększa nakład pracy i jest dodatkowo rozliczana.

5. “Dbaj o precyzyjną komunikację”:
– Jasno wyjaśniaj różnice między błędem a zmianą.
– Wskazuj, że krzyżowe konsekwencje nowej funkcji to wciąż część prac rozwojowych.

Dzięki rzetelnemu podejściu i jasnemu rozróżnianiu błędu od zmiany, współpraca między agencją a klientem staje się klarowniejsza. Pamiętajmy, że w projektach IT wiele funkcjonalności się przenika, a wprowadzanie nowej często pociąga za sobą konieczność dostosowania istniejących elementów systemu. To “nie” błąd, ale “naturalna część” rozwoju produktu, która w modelu T&M powinna zostać odpowiednio rozliczona.