Piotr FilipowiczŻeby ocenić wycenę projektu IT przed wyborem dostawcy, trzeba zobaczyć, co policzono, na jakich założeniach i kto ma wykonać tę pracę. Jako kupujący potrzebujesz wiedzieć, czy za proponowaną kwotę i w podanym terminie dostaniesz uzgodniony rezultat oraz co może zmienić te warunki.
Z mojej perspektywy wyceny zawsze były jedną z trudniejszych części pracy developera czy architekta. Na początku projektu poruszamy się w dużej niepewności, natomiast po drugiej stronie ktoś potrzebuje konkretnej kwoty i terminu. Jeśli jako CEO, founder, Product Owner lub CTO wybierasz dostawcę IT, to na podstawie tej odpowiedzi zarezerwujesz budżet, zaangażujesz ludzi i podejmiesz zobowiązania. Za tą liczbą idzie więc odpowiedzialność po obu stronach.
Dlatego uważam, że bez praktyki i porównywania prognoz z wykonaniem trudno robić to dobrze. Dostawca powinien wiedzieć, co naprawdę zajmowało czas w jego poprzednich projektach, które założenia się nie sprawdziły i czego nie uwzględnił. Samo przekonanie zespołu, że potrafi zbudować dany system, jeszcze nie mówi, ile będzie kosztowało jego dostarczenie.
Dzisiaj dochodzi do tego AI. Potrafi pomagać w developmentcie, ale też przygotowywać same wyceny: rozpisywać zakres, założenia, ograniczenia i ryzyka. W mojej ocenie bardzo dobrze radzi sobie z porządkowaniem takiego materiału, więc profesjonalnie wyglądający dokument jest coraz słabszym dowodem na to, że ktoś rzeczywiście dobrze rozpoznał projekt.
Oferta może w ogóle nie wspominać o użyciu AI przez developerów. Jako klient możesz po prostu oczekiwać, że dostawca korzysta z narzędzi usprawniających pracę i uwzględnia je w swojej kalkulacji. Przy ocenie oferty interesowałoby mnie przede wszystkim, czy proponowany termin opiera się na sprawdzonym sposobie pracy zespołu i czy uwzględnia czas potrzebny na weryfikację oraz poprawki.
Dostawca wycenia development, a Ty potrzebujesz działającego rozwiązania
Jedna z tendencji, na które zwracam uwagę, to szacowanie przede wszystkim czystego developmentu. Developer wyobraża sobie sytuację, w której wie, co trzeba zrobić, ma potrzebne dostępy i może spokojnie usiąść do implementacji. W takich warunkach jego ocena może być całkiem rozsądna.
Natomiast w projekcie trzeba jeszcze porozmawiać z klientem, doprecyzować zachowanie systemu i rozstrzygnąć przypadki brzegowe. Czasem odpowiedź zależy od osoby z innego działu, której nie ma na spotkaniu. Czasem klient wróci z decyzją za kilka dni, a bez niej nie da się odpowiedzialnie zakończyć pracy.
Do tego dochodzi cały cykl dostarczania oprogramowania, czyli SDLC: analiza, projektowanie, implementacja, testy, przegląd kodu, integracja, wdrożenie i stabilizacja. Nie wszystko musi być osobnym etapem ani osobnym zespołem. Przed zaakceptowaniem oferty sprawdziłbym, które prace dostawca uwzględnił w swojej cenie, a które mają wykonać ludzie w Twojej firmie.
Warto przy tym oddzielić nakład pracy od czasu kalendarzowego. Dwa dni czekania na decyzję nie muszą oznaczać dwóch dni płatnego developmentu, ale mogą przesunąć wdrożenie. Martin Fowler opisuje podobne rozróżnienie między czasem idealnym, poświęconym bezpośrednio zadaniu, a rzeczywistym upływem czasu. Źródło: Ideal Time.
W tym kontekście myślę również o Pareto, które przypomina mi o nierównomiernym rozkładzie pracy. Konkretne proporcje zależą od projektu. Łatwo pokazać dużą część widocznych funkcji, natomiast pozostałe wyjątki, integracje i warunki działania mogą pochłonąć nieproporcjonalnie dużo wysiłku.
Dlatego jeśli dostawca pokazuje prototyp i mówi „większość już działa”, chciałbym wiedzieć, co dokładnie pozostało i czy uwzględniono to w ofercie. Liczba gotowych ekranów niewiele mówi o terminie, jeśli nadal nie wiadomo, czy system poprawnie rozliczy zamówienie albo poradzi sobie z utratą połączenia.
Niepewne wyceny, opóźnienia i niedowiezione projekty towarzyszyły nam długo przed generatywnym AI. Dzisiaj nowe narzędzia mogą zmieniać tempo pracy, ale przy wyborze dostawcy nadal warto wiedzieć, jak jego prognozy mają się do wykonania. Dlatego ocenę wyceny zacząłbym od sprawdzenia, czy zespół w ogóle zbiera takie dane.
Skąd wiesz, czy dostawca potrafi trafnie wyceniać?
To jest dla mnie jedno z podstawowych pytań do architekta albo osoby odpowiedzialnej za estymację po stronie dostawcy: jeżeli nie mierzy pracy w istniejących projektach i nie wyciąga wniosków, na jakiej podstawie ocenia skuteczność własnych prognoz?
Jørgensen i Sjøberg w opracowaniu o uczeniu się estymacji opisują znaczenie informacji zwrotnej, która pozwala zrozumieć przyczyny odchyleń. Zwracają też uwagę, że ilość doświadczenia bywa słabym wskaźnikiem trafności. Źródło: Expert Estimation of Software Development Work: Learning through Feedback.
W praktyce poprosiłbym dostawcę o omówienie podobnej realizacji: jaki zakres obejmował pierwotny szacunek, jaki był rzeczywisty nakład, ile trwało dostarczenie oraz co wpłynęło na różnicę. Taki przykład może być zanonimizowany. Ważne, żeby pozwalał rozdzielić pominiętą pracę, zmiany wymagań, poprawki i oczekiwanie na decyzje.
Jeżeli szacunek wynosił 40 godzin, a wykonanie 65, sam wynik niewiele jeszcze wyjaśnia. Inaczej ocenię pominiętą obsługę błędów, inaczej dopisanie nowego procesu przez klienta. Wyjaśnienie tej różnicy pomaga ocenić, czy dostawca rozumie przyczyny odchyleń i uwzględnia je w kolejnych ofertach.
Przed rozpoczęciem współpracy ustaliłbym także, jak dostawca będzie aktualizował prognozę i zachowywał jej poprzednie wersje. Aktualizacja planu jest potrzebna, ale jeśli poprzednia liczba znika, tracisz materiał do oceny trafności. Sam fakt, że końcowy plan zgadza się z końcowym wykonaniem, nie mówi, czy dobrze przewidziano projekt na początku.
Kiedyś mnożyliśmy przez 1,3. Teraz pojawia się pytanie, przez ile dzielić
Znam praktykę mnożenia wyceny przez 1,3 albo 1,4, żeby uwzględnić to, czego nie udało się przewidzieć. Taki zapas może pomagać, ale nie zastępuje rozpoznania zakresu. Jeżeli w kalkulacji zabrakło całego obszaru pracy, procent dopisany na końcu niekoniecznie go pokryje.
W dobie AI pojawia się odwrotne oczekiwanie: skoro dostawca wykona część pracy szybciej, to może wcześniejszy szacunek trzeba podzielić. Dla mnie kluczowe pytanie brzmi, skąd firma bierze ten współczynnik. Czy mierzy przyspieszenie, czy zakłada je na podstawie możliwości narzędzia? To odpowiedzialność dostawcy. Na spotkaniu zapytałbym po prostu, na jakich doświadczeniach zespołu opiera proponowany termin i co może utrudnić jego dotrzymanie.
Oddzieliłbym tu oszczędność czasu od rezerwy na ryzyko. AI może zmniejszyć nakład na wybrane zadania, a projekt nadal może potrzebować zapasu na niepewne integracje czy dane. Mnożnik ryzyka i współczynnik produktywności odpowiadają na różne pytania, więc nie wystarczy zastąpić jednego drugim.
Podam hipotetyczny przykład.
Z przewidywanych 100 godzin 40 przypada na pracę, którą AI skraca o połowę. Pozostałe 60 się nie zmienia, więc zostaje 80 godzin. Jeżeli ponad pierwotny plan potrzebujemy jeszcze 10 godzin nadzoru i poprawek, kończymy na 90 godzinach. Dopiero do tak oszacowanej pracy można odnieść nadal aktualne ryzyka.
AI może pomagać na różnych etapach dostarczania oprogramowania, więc chciałbym wiedzieć, które z nich zespół mierzył i czy uwzględnił wynik po weryfikacji. Współczynnik policzony na prototypach nie musi pasować do integracji ze starym ERP, tak jak wynik najlepszego eksperta w firmie nie opisuje automatycznie zespołu przypisanego do Twojego projektu.
Badania nie dają jednego współczynnika przyspieszenia
Trzy eksperymenty terenowe w Microsoft, Accenture i anonimowej firmie z Fortune 100, obejmujące 4867 programistów, dały po połączeniu danych oszacowanie około 26% wzrostu liczby ukończonych zadań przy użyciu asystenta AI. Wyniki poszczególnych eksperymentów były zróżnicowane i obarczone niepewnością. Ich zastosowanie do wyceny wymaga więc sprawdzenia, na ile zadania i warunki pracy badanego zespołu odpowiadają planowanemu projektowi. Źródło: Cui i in..
Z kolei w badaniu METR z początku 2025 roku 16 doświadczonych programistów wykonywało 246 zadań w znanych sobie repozytoriach. Dopuszczenie AI wydłużało pracę średnio o 19%, choć uczestnicy oceniali jego wpływ jako przyspieszenie. Aktualizacja METR z lutego 2026 wskazywała już na prawdopodobną poprawę przy nowszych narzędziach, ale problemy z doborem próby i pomiarem nie pozwalały wiarygodnie określić skali efektu. Źródła: badanie METR z 2025, aktualizacja z 2026.
Z perspektywy kupującego te wyniki pokazują, jak ostrożnie warto traktować ogólną obietnicę, że dzięki AI projekt pójdzie szybciej. Jeśli dostawca w ten sposób uzasadnia krótki termin, poprosiłbym o przykład podobnej pracy wykonanej przez proponowany zespół: co udało się dostarczyć, w jakim czasie i ile wymagało poprawek. Pomiar wpływu narzędzi pozostawiłbym firmie, która na tej podstawie składa ofertę.
Brak ryzyk to dla mnie red flag. Sama lista ryzyk też nie wystarczy
Jeżeli wycena złożonego projektu nie zawiera założeń, ograniczeń ani ryzyk, zapala mi się czerwona lampka. Chciałbym wiedzieć, w jakich warunkach deklarowana kwota i termin mają sens, a co może je zmienić.
Natomiast dzisiaj bardzo łatwo przygotować rozbudowaną listę, na której znajdą się „ryzyka integracyjne”, „dostępność klienta” i „jakość danych”. Sama obecność takich punktów nie mówi, czy ktokolwiek zajrzał do dokumentacji integracji, rozmawiał z osobą decyzyjną albo sprawdził próbkę danych.
Użyteczne założenie mogłoby brzmieć tak:
„Zakładamy, że istniejące API pozwala zarezerwować towar. Potwierdzimy to testem przed budową procesu zamówień. Jeśli funkcji nie ma, trzeba będzie zmienić integrację i ponownie oszacować zależne prace”.
To przykład hipotetyczny, ale widać w nim warunek, sposób weryfikacji i konsekwencję.
Chciałbym dodatkowo wiedzieć, kto odpowiada za sprawdzenie i kiedy wynik będzie potrzebny. Ryzyko opisane na końcu dokumentu, ale nieuwzględnione w harmonogramie i decyzjach, nadal może zaskoczyć projekt.
Takie podejście jest zgodne z zasadami GAO dotyczącymi wiarygodnych wycen: udokumentowane założenia powinny łączyć się z danymi, analizą ryzyka i aktualizacją kosztów. Sam dobrze napisany dokument jest tylko częścią tej pracy. Źródło: GAO Cost Estimating and Assessment Guide.
Jak ocenić wycenę, którą mogło przygotować AI?
Przy wycenie przygotowanej z pomocą AI chciałbym sprawdzić, czy osoba odpowiedzialna potrafi przejść od zapisanej kwoty do danych i założeń, na których ją oparto. To da mi więcej informacji o jakości analizy niż próba odgadnięcia autorstwa po stylu dokumentu. Na spotkaniu z dostawcą, przed zaakceptowaniem oferty, zrobiłbym to w czterech prostych krokach.
Poproś o podstawę kilku istotnych pozycji
Wybrałbym kilka kosztownych albo niepewnych elementów i poprosił o przejście od wymagania do szacunku. Jakie dane wykorzystano? Które porównywalne zadanie jest punktem odniesienia? Co sprawdzono, a co dopiero założono?
Dostawca może podczas rozmowy korzystać z AI i dokumentacji. Chciałbym, żeby pokazał materiał źródłowy i wyjaśnił, jak wykorzystał go do oszacowania pracy.
Zmień jedno założenie i zobacz konsekwencje
Zapytałbym na przykład, co zmieni się, jeśli zamiast gotowego API będziemy mieć pliki wymieniane raz dziennie. Albo jeśli decyzje klienta będą zapadały raz w tygodniu, a nie następnego dnia.
Dobra odpowiedź powinna pokazać, które elementy zakresu, kosztu i harmonogramu wymagają zmiany. Samo przeliczenie może wymagać czasu. Na spotkaniu wystarczy mi spójne wyjaśnienie zależności i wskazanie, co trzeba dodatkowo sprawdzić.
Sprawdź, co w tej wycenie jest specyficzne dla Twojej firmy
Jeżeli po usunięciu nazwy klienta dokument pasuje do dowolnego przedsiębiorstwa, chciałbym zobaczyć więcej konkretu. Jakie wyjątki w procesie rozpoznano? Które systemy sprawdzono? Jakie ograniczenia danych, uprawnień czy organizacji zmieniają sposób realizacji?
Jeśli część informacji wymaga dopiero sprawdzenia, powinna być oznaczona jako założenia. Dzięki temu wiesz, które fragmenty oferty opierają się już na ustaleniach dotyczących Twojej firmy, a gdzie kwota może się jeszcze zmienić.
Porozmawiaj z osobą, która ma wykonać tę pracę
Wybrałbym jedną konkretną pozycję, na przykład integrację z ERP, i poprosił o krótką rozmowę z developerem lub architektem przewidzianym do projektu. Chciałbym usłyszeć, jak zamierza ją zrealizować, czego potrzebuje od klienta i po czym pozna, że jest gotowa do odbioru.
Zapytałbym też, czy uczestniczył w przygotowaniu wyceny i czy podtrzymuje ją przy zapisanych założeniach. Jeśli nie, warto wyjaśnić różnicę przed rozpoczęciem prac. Dla mnie ważne jest, żeby osoba mająca dostarczyć rozwiązanie rozumiała zobowiązanie przedstawione w ofercie.
Taką rozmowę można przeprowadzić na zwykłym spotkaniu. Pozwala wyjaśnić, jak zespół rozumie pracę ujętą w ofercie i gdzie widzi niewiadome, które mogą jeszcze zmienić szacunek.
Kiedy warto zacząć od discovery?
Jeśli cena zależy od niewiadomych, które można sprawdzić przed rozpoczęciem developmentu, rozważyłbym discovery, czyli ograniczony etap rozpoznania projektu. Szczególnie gdy trzeba zrozumieć proces biznesowy, sprawdzić możliwości integracji albo jakość danych. W takiej sytuacji łatwiej mi uzasadnić wydatek na analizę, jeśli wiem, które decyzje pozwoli podjąć przed zaangażowaniem reszty budżetu.
Przed zakupem discovery ustaliłbym jego koszt, czas, potrzebne zaangażowanie ludzi z Twojej firmy i konkretne rezultaty. Chciałbym otrzymać uzgodniony zakres pierwszego etapu, kryteria odbioru, wyniki sprawdzenia najważniejszych założeń oraz zaktualizowaną wycenę z opisem pozostałych ryzyk. Jeśli największą niewiadomą jest integracja z ERP, oczekiwałbym sprawdzenia dokumentacji i, tam gdzie to potrzebne, krótkiego testu technicznego. Sam warsztat może pozostawić tę niewiadomą bez odpowiedzi.
Po discovery powinieneś mieć wystarczająco dużo informacji, żeby zdecydować, czy uruchamiasz projekt, zmniejszasz zakres, czy rezygnujesz z inwestycji. Ustaliłbym też możliwość wykorzystania wyników przy rozmowie z innym dostawcą. Przy małym, dobrze rozpoznanym zakresie osobny etap discovery może być zbędny. Jego sens oceniam po znaczeniu niewiadomych, które ma wyjaśnić.
Wielokrotnie widziałem wyceny szyte pod budżet klienta
Wielokrotnie widziałem wyceny, które były szyte dokładnie pod budżet klienta. Dlatego gdy końcowa kwota idealnie pasuje do podanego limitu, chciałbym wiedzieć, jak do niej doszliśmy. Czy rzeczywiście policzono pracę, czy przede wszystkim przygotowano ofertę, która ma zmieścić się w dostępnej kwocie?
Samo projektowanie rozwiązania pod budżet jest rozsądne. Jeżeli klient ma 300 tysięcy złotych, możemy ograniczyć zakres, uprościć proces albo podzielić inwestycję na etapy. Chciałbym jednak zobaczyć te decyzje w ofercie. Pozostawienie tego samego rezultatu i dopasowanie jedynie liczby godzin wymaga konkretnego uzasadnienia.
Dla mnie „ile kosztuje ten zakres?” i „co możemy zrobić w tym budżecie?” to dwie różne rozmowy. Zgodność końcowej kwoty z oczekiwaniem klienta nie potwierdza jeszcze, że cały deklarowany zakres da się za nią dostarczyć.
Badanie Jørgensena i Sjøberga pokazało, że oczekiwania kosztowe klienta mogły silnie wpływać na eksperckie szacunki nawet wtedy, gdy estymującym przekazano, że nie są one wiarygodną informacją do wyceny. Źródło: The Impact of Customer Expectation on Software Development Effort Estimates.
Dlatego oddzieliłbym prognozę nakładu od negocjacji ceny i zakresu. Dotyczy to również pracy z AI: polecenie przygotowania oferty mieszczącej się w zadanym budżecie nie jest niezależnym sprawdzeniem, czy ten budżet wystarczy.
Sprawdziłbym też, czy niższa cena nie wynika z przeniesienia części pracy na klienta. Przygotowanie danych, testy akceptacyjne czy rozstrzygnięcie reguł biznesowych mogą nie być kosztem dostawcy, a nadal wymagają czasu ludzi w Twojej firmie. Oferta tańsza na pierwszej stronie nie musi więc oznaczać tańszej inwestycji.