Transparentność kosztów w projekcie software. Czego dostawca nie chce ci pokazać

Budżet w projekcie IT rzadko wybucha z dnia na dzień – problem zwykle rośnie po cichu. Dlatego o kosztach trzeba rozmawiać już w pierwszym tygodniu, a nie po pierwszej fakturze.

Dobry dostawca nie kończy na „pracujemy zgodnie z ustaleniami”. Powie wprost, na czym dziś stoi budżet, co się zmieniło od startu i jakie decyzje trzeba podjąć – zanim zrobi się z tego problem.

W tym artykule wyjaśniamy:

• jakich informacji dot. stanu projektu powinieneś oczekiwać od uczciwego dostawcy software’u,
• jakich informacji powinieneś oczekiwać od pierwszego tygodnia współpracy.

Transparentność kosztów to nie faktura z liczbą godzin

W wielu projektach „transparentność” jest sprowadzana do tabeli:

• kto pracował,
• ile godzin pracował,
• nad jakim zadaniem pracował,
• Jaką stawkę została naliczona.

To jest widoczność księgowa. Potrzebna, ale niewystarczająca.

Z perspektywy CFO lub CTO albo właściciela budżetu ważniejsze są inne pytania:

• Czy wydajemy pieniądze na najważniejsze rzeczy?
• Czy zespół robi to, co było ustalone, czy przy okazji płacisz za naprawianie rzeczy, które się sypią po drodze?
• Czy zmiany zakresu prac są świadomie zatwierdzane?
• Czy mamy wczesny sygnał, że aktualny budżet nie wystarczy?
• Czy raport pokazuje postęp biznesowy, czy tylko aktywność zespołu?

Jeżeli dostawca nie potrafi odpowiedzieć na te pytania od pierwszego tygodnia, problem polega na braku modelu zarządzania kosztem.

Pierwszy tydzień: dostawca powinien ustalić, co właściwie kupujesz

Współpraca software’owa często zaczyna się od ogólnego hasła: „Potrzebujemy zespołu do rozwoju produktu”. Brzmi prosto. W praktyce pod tym zdaniem mogą kryć się zupełnie różne rzeczy.

Możesz kupować:

• rozwój nowych funkcjonalności,
• utrzymanie istniejącego systemu,
• obsługę incydentów produkcyjnych,
• przejęcie projektu po poprzednim dostawcy,
• audyt techniczny,
• stabilizację systemu,
• discovery produktowe,
• refaktoryzację,
• DevOps 
• inne

Jeżeli tego nie rozdzielisz, każdy raport kosztowy będzie później niejednoznaczny.

Typowa sytuacja: dostawca ma dostarczyć konkretne funkcje, a oprócz tego co miesiąc dostaje budżet na bieżące poprawki i utrzymanie. Część zespołu pracuje nad nowymi rzeczami, część naprawia to, co wymaga bieżących prac. Jeśli nikt tego nie rozpisze osobno, klient szybko zaczyna się zastanawiać: „chwila, czy ja nie płacę dwa razy za to samo?”.

Czasem odpowiedź brzmi: nie, to są dwie różne rzeczy. Ale jeśli klient sam musi się tego domyślać, to znaczy, że dostawca źle to wytłumaczył.

Od pierwszego tygodnia powinny istnieć minimum trzy koszyki:

1. Zakres zakontraktowany – prace, które wynikają z ustalonego zakres prac, celu albo umowy fixed price.
2. Bieżące utrzymanie – prace finansowane z miesięcznej puli godzin zespołu.
3. Prace nieplanowane – incydenty, awarie, hotfixy, pilne zgłoszenia, wrzutki biznesowe, prace ad hoc.

To proste rozdzielenie często zapobiega pojawieniu się napięć finansowych.

Dobry dostawca pokazuje koszt decyzji, nie tylko koszt pracy

Największe przepalenia budżetu nie biorą się stąd, że programista zrobił coś w 6 godzin zamiast w 4. Biorą się z decyzji, których nikt nie nazwał decyzjami o pieniądzach.

• „Dodajmy jeszcze ten mały filtr.”
• „Nie naprawiajmy teraz długu technicznego, skupmy się na funkcjach.”
• „Nie róbmy środowiska testowego, przetestujemy na produkcji.”
• „Nie traćmy czasu na opisanie procesu, zespół sobie poradzi.”
• „To tylko jedna integracja.”

Każde z tych zdań może być rozsądne. Każde z nich może też być początkiem kosztownego problemu.

Transparentny dostawca nie powinien blokować decyzji biznesowych. Powinien pokazać ich konsekwencje.

Przykład dobrej komunikacji:

Możemy zrealizować tę zmianę w tym sprincie, ale wtedy wypada z niego praca nad stabilizacją importu. To zwiększa ryzyko kolejnych incydentów operacyjnych. Rekomendujemy jedną z dwóch decyzji: albo przesuwamy funkcję, albo świadomie akceptujemy ryzyko i zapisujemy je w risk logu.

To jest transparentność.

Przykład słabej komunikacji:

Jasne, dodamy.

Taka odpowiedź jest wygodna przez 10 minut. Potem klient płaci za konsekwencje, których nikt nie nazwał.

Od pierwszego tygodnia musisz widzieć nie tylko, co zespół zrobił, ale też jakie decyzje masz teraz podjąć

„Zielony status” nic nie znaczy, jeśli nie wiadomo, co właściwie pokazuje.

Dobry przegląd kosztów to nie tylko godziny – pokazuje, jak koszt ma się do zakresu i do tego, co naprawdę zrobione. Na start wystarczy odpowiedź a na sześć pytań:

1. Jaki jest budżet na dany miesiąc, etap albo zakres prac?
2. Ile już wykorzystano?
3. Ile zostało?
4. Na co poszedł koszt: funkcje, utrzymanie, incydenty, discovery, DevOps, testy, zarządzanie?
5. Co zostało dostarczone i zaakceptowane?
6. Jakie ryzyka mogą zmienić prognozę kosztu?

Jeżeli projekt jest prowadzony w modelu time and material, dashboard powinien pokazywać burn rate i prognozę kosztów. Jeśli to fixed price – ile funkcji jest już zrobionych, a ile jeszcze zostało do zrobienia, jakie są ryzyka i co się zmieniło względem pierwotnych ustaleń. Jeżeli model jest mieszany, rozdzielenie musi być jeszcze bardziej precyzyjne. Dowiedz się więcej o różnicy między fixed price i time and material.

To ważne, bo wiele konfliktów nie wynika z samego kosztu. Wynika z braku wspólnego obrazu sytuacji.

Klient myśli: „płacę za efekt”. Dostawca myśli: „pracujemy tyle, ile było zamówione”. Zespół myśli: „robimy to, co najpilniejsze”.

Wszyscy mogą mieć rację. I właśnie dlatego potrzebny jest jeden model rozmowy o kosztach.

Awarie na produkcji muszą być osobno widoczne w kosztach

Jeżeli system działa stabilnie, budżet może iść głównie na rozwój. Jeżeli system jest niestabilny, budżet zaczyna iść na naprawy.

To ważne: każda godzina spędzona na hotfixie, awarii albo ręcznym odkręcaniu błędu to godzina, która nie poszła na realizację założonych celów. W praktyce klient nie płaci wtedy za rozwój produktu. Płaci za odzyskanie zdolności do normalnej pracy.

Dlatego dobry dostawca powinien od pierwszego tygodnia osobno pokazywać:

• ile czasu zespół poświęcił na planowany rozwój,
• ile na utrzymanie systemu,
• ile na incydenty,
• ile na analizę przyczyn źródłowych,
• ile na działania zapobiegawcze.

Bez tego klient widzi tylko fakturę. Nie widzi, żepostęp prac zwalnia, bo system wymaga stabilizacji. A wtedy bardzo łatwo o zły wniosek: „zespół dowozi za mało”.

Czasem prawdziwy wniosek brzmi inaczej: „zespół dowozi mało nowych funkcji, bo budżet idzie na stabilizację systemu”.

Dług techniczny też trzeba umieć opisać w kategoriach pieniędzy

Dług techniczny często jest przedstawiany jako problem zespołu deweloperskiego. To błąd. Dług techniczny jest problemem biznesowym, bo wpływa na koszt każdej kolejnej zmiany.

Jeżeli system ma rozproszoną logikę, brak testów, słabą dokumentację, niejasne zależności między serwisami albo niestabilne środowiska, to każda funkcja kosztuje więcej. Nie dlatego, że zespół pracuje wolniej z własnej winy. Dlatego, że system wymusza więcej analizy, testów, obejść i ręcznej walidacji.

Transparentny dostawca powinien umieć przełożyć dług techniczny na prosty język:

• ta część systemu wydłuża development,

• ta zależność zwiększa ryzyko regresji,

• ten brak automatyzacji podnosi koszt wdrożeń,

• ten brak testów zwiększa koszt ręcznej walidacji,

• ta architektura utrudnia skalowanie,

• ta decyzja obniży koszt przyszłych zmian, ale nie da natychmiastowej funkcji biznesowej.

Klient nie musi znać wszystkich szczegółów implementacyjnych. Musi rozumieć konsekwencje finansowe.

Najgorszy scenariusz to taki, w którym dług techniczny jest ukrywany do momentu, aż zaczyna blokować delivery. Wtedy rozmowa o koszcie jest już spóźniona.

Definition of Done też jest narzędziem kontroli kosztów

W projektach software często mówi się o Definition of Done jako o praktyce jakościowej. Słusznie. Ale to również narzędzie finansowe.

Jeżeli „done” oznacza „developer skończył kod”, klient płaci później drugi raz: za poprawki, testy, integrację, dopięcie środowisk, deploy, regresję, naprawę danych albo wyjaśnianie, czemu funkcja nie działa tam, gdzie powinna.

Jeżeli „done” oznacza „funkcja jest wdrożona, przetestowana i zaakceptowana”, koszt jest bardziej uczciwy, nawet jeśli początkowo wygląda na wyższy.

Transparentny dostawca powinien więc ustalić w pierwszym tygodniu, co dokładnie oznacza zakończenie pracy.

Minimalna definicja powinna obejmować:

• kod po review,
• testy adekwatne do ryzyka,
• wdrożenie na właściwe środowisko,
• walidację przez zespół,
• akceptację biznesową, jeśli jest wymagana,
• aktualizację dokumentacji lub notatki technicznej,
• brak otwartych blockerów,
• Jasną informację, czy funkcja jest na produkcji, czy tylko „gotowa do wdrożenia”.

Bez tego raport „zrobione” bywa jedną z najdroższych iluzji w projekcie.

Czego konkretnie wymagać od dostawcy w pierwszym tygodniu?

Nie musisz od razu budować ciężkiej maszynki do raportowania. Wystarczy kilka prostych dokumentów, które porządkują rozmowę o pieniądzach.

1. Mapa strumieni pracy

Dostawca powinien pokazać, jakie typy pracy będą wykonywane z jego budżetu. 

Przykład:

• Roadmapa produktowa – finansowana z budżetu rozwojowego.
• Utrzymanie – finansowane z budżetu na utrzymanie .
• Incydenty – trackowane osobno.
• Discovery – rozliczane jako aktywność lub element pracy Product Ownera/Product Managera.
• Dług techniczny – widoczny jako inwestycja w obniżenie przyszłego kosztu.
• Prace poza zakresem – wymagają decyzji.

2. Prosty model budżetu

Klient powinien wiedzieć:

• jaki jest limit miesięczny,
• jaka jest dostępnośc zespołu,
• jaka część budżetu jest już „zarezerwowana”,
• jaka część jest elastyczna,
• co się stanie po przekroczeniu progu,
• kto podejmuje decyzję o zwiększeniu zakresu lub budżetu.

Dobry dostawca nie czeka, aż budżet się skończy. Dobry dostawca mówi wcześniej: „przy obecnym tempie i zakresie mamy ryzyko przekroczenia”.

3. Zasady zmian zakresu

Każda zmiana powinna mieć jedną z trzech etykiet:

• mieści się w uzgodnionym zakresie,
• zastępuje inną pracę,
• zwiększa koszt lub przesuwa termin.

To brutalnie proste i bardzo skuteczne.

Najgorsza kategoria to „dodajmy, zobaczymy później”. W software „później” zwykle oznacza niejasną fakturę, napięcie i spotkanie wyjaśniające.

4. Raport postępu oparty na wartości

Raport powinien pokazywać:

• co zostało dowiezione,
• co jest nadal w toku,
• co jest zablokowane,
• jakie decyzje są potrzebne,
• co zmieniło prognozę,
• jakie ryzyka wpływają na koszt.

Nie wystarczy lista zamkniętych ticketów. Ticket może być zamknięty, a wartość biznesowa nadal wynosić zero.

5. Zasady raportowania kosztów administracyjnych

Jeżeli klient wymaga szczegółowych opisów, komentarzy, codziennych raportów i ręcznego logowania, to powinno być jasne, że to też jest praca.

Dojrzały dostawca powinien umieć powiedzieć:

Możemy raportować bardzo szczegółowo, ale to zużyje część dostępności zespołu. Rekomendujemy taki poziom szczegółowości przez pierwsze tygodnie, a później przejście na automatyczne raporty plus komentarz do wyjątków.

To nie jest unikanie transparentności. To jest uczciwość wobec budżetu.

Czerwone flagi: kiedy dostawca nie jest transparentny kosztowo

Zwróć uwagę, jeśli w pierwszych tygodniach słyszysz:

• „To się zobaczy po drodze.”
• „Nie ma sensu teraz tego rozdzielać.”
• „Wszystko jest w ramach prac zespołu.”
• „Nie wiemy dokładnie, ile poszło na incydenty.”
• „Nie ma potrzeby dawać klientowi dostępu do backlogu.”
• „Raport przygotujemy pod koniec miesiąca.”
• „To techniczne, nie ma sensu tego tłumaczyć biznesowi.”
• „Nie da się powiedzieć, czy to było w zakresie.”
• „Zespół był zajęty, ale trudno powiedzieć czym dokładnie.”
• „Faktura wszystko pokaże.”

Faktura pokazuje koszt. Nie pokazuje jakości decyzji, które do niego doprowadziły.

Jeśli któreś z tych zdań słyszysz u siebie częściej niż raz w miesiącu, sprawdź swój projekt w naszej autodiagnozie Czy Twój projekt płonie?.

Transparentność kosztów działa w obie strony

Warto powiedzieć też o drugiej stronie: klient również ma odpowiedzialność.

Dostawca może stworzyć najlepszy system raportowania, ale jeśli każda decyzja biznesowa jest pilna, każdy zakres jest krytyczny, każdy stakeholder może wrzucić nowy temat, a priorytety zmieniają się bez konsekwencji, to budżet i tak popłynie.

Transparentność kosztów wymaga dyscypliny po obu stronach:

• dostawca pokazuje konsekwencje,
• klient podejmuje decyzje,
• zespół pracuje według ustalonych priorytetów,
• nowe tematy nie wchodzą bokiem do zakresu prac,
• incydenty nie są przedstawiane jako normalny rozwój,
• dług techniczny nie jest zamiatany pod dywan,
• raporty nie służą do uspokajania ludzi, tylko do podejmowania decyzji.

Najlepsze projekty nie są transparentne dlatego, że wszyscy sobie ufają. Są transparentne dlatego, że mają mechanizmy, które pozwalają ufać bez zgadywania.

Pytania, które warto zadać dostawcy przed startem

Przed podpisaniem umowy albo w pierwszym tygodniu współpracy zapytaj:

1. Jak rozdzielacie koszt rozwoju, utrzymania, incydentów i prac ad hoc?
2. Czy będziemy widzieć backlog i status prac na bieżąco?
3. Jak pokażecie burn rate budżetu?
4. Kiedy dostaniemy pierwszy sygnał, że budżet lub zakres są zagrożone?
5. Jak rozliczacie zmiany zakresu?
6. Co oznacza u was „done”?
7. Jaki jest koszt administracyjny raportowania?
8. Jak mierzycie koszt jednej funkcjonalności lub jednego typu pracy?
9. Czy osobno pokazujecie czas poświęcony na awarie produkcyjne?
10. Jak wygląda decyzja o tym, że coś wchodzi do sprintu kosztem czegoś innego?

Jeżeli dostawca odpowiada konkretnie, to dobry znak. Jeżeli odpowiada ogólnikami, prawdopodobnie po pierwszej fakturze będziesz miał więcej pytań niż odpowiedzi.

Podsumowanie: pierwszy tydzień ustawia cały model zaufania

Transparentność kosztów w software nie polega na tym, że klient dostaje więcej danych. Polega na tym, że dostaje właściwe dane wystarczająco wcześnie, aby podejmować decyzje.

Od pierwszego tygodnia powinieneś wiedzieć:

• co kupujesz,
• z którego budżetu finansowany jest dany typ pracy,
• co jest w zakresie,
• co jest poza zakresem,
• ile kosztuje utrzymanie transparentności,
• jakie ryzyka mogą zwiększyć koszt,
• co zostało realnie dowiezione,
• kiedy potrzebna jest decyzja biznesowa.

Dobry dostawca nie chroni klienta przed trudną informacją. Dobry dostawca podaje ją wcześnie, jasno i w formie, która pozwala działać.

W projekcie IT najdroższe nie są same zmiany. Najdroższe są zmiany, których nikt na czas nie nazwał decyzją budżetową.

Nie jesteś pewien, czy Twój dostawca pokazuje Ci to, co powinien?

Robimy krótkie audyty projektów IT – przeglądamy raporty, sposób rozliczeń i to, jak dostawca komunikuje koszt decyzji. Po dwóch tygodniach wiesz, gdzie tracisz pieniądze i co dokładnie zmienić w modelu współpracy.

Umów 30 minut rozmowy – bez prezentacji, bez slajdów. Opowiesz, jak wygląda u Ciebie pierwszy tydzień z dostawcą, my powiemy, czego brakuje.

Podsumuj ten artykuł za pomocą sztucznej inteligencji

ChatGPT

Claude

Perplexity