Jak software house wycenia projekt: estymacja, rezerwa na ryzyko i co sprawdzić w ofercie

Kierownik zakupów w firmie ubezpieczeniowej przedstawia zarządowi ofertę na nowy portal agenta. Wycena: 1,2 miliona złotych, rozbita na moduły, z osobną pozycją „rezerwa na ryzyko: 20%”. Dyrektor finansowy czyta tabelę i zadaje pytanie, które w tej sytuacji zadaje prawie każdy: „Dlaczego mamy płacić za bufor dostawcy? Wykreślmy rezerwę i niech zmieszczą się w miliardzie”.

To pytanie jest zrozumiałe i prawie zawsze prowadzi do gorszej umowy. Rezerwa na ryzyko w rzetelnej wycenie nie jest ukrytą marżą, tylko jawną ceną niepewności, która w projekcie istnieje niezależnie od tego, czy ktoś ją zapisze. Jeśli ją wykreślisz, nie zniknie. Wróci jako zlecenia zmian, przesunięte terminy, okrojony zakres testów albo zespół, który na koniec projektu pracuje pod presją i robi skróty. Paradoksalnie oferta z jawną rezerwą jest często bezpieczniejsza niż tańsza oferta bez niej.

Ten artykuł jest dla osoby, która ocenia wycenę oprogramowania dedykowanego i chce rozumieć, co w niej jest. Pokazujemy, z czego składa się cena projektu w software house, jak dostawcy szacują pracochłonność, ile pracy jest poza samym programowaniem, czym jest rezerwa na ryzyko i ile powinna wynosić, które czynniki najbardziej podnoszą wycenę i jakie pytania zadać, zanim porównasz oferty. Modeli rozliczeń (abonament zespołu, time & materials, fixed price) tu nie powtarzamy, bo szczegółowo omawiamy je w artykule o tym, który model rozliczeń z dostawcą IT naprawdę dzieli ryzyko. Tutaj skupiamy się na tym, jak powstaje liczba w ofercie.

Dlaczego dwie rzetelne wyceny tego samego projektu mogą się różnić dwukrotnie?

Bo na początku projektu nikt nie wie, ile on będzie kosztował, a wycena jest próbą opisania tej niewiedzy liczbą. Zjawisko to ma w inżynierii oprogramowania nazwę: stożek niepewności. Pierwszą wersję tego wykresu przedstawił Barry Boehm w książce „Software Engineering Economics” z 1981 roku, a spopularyzował go Steve McConnell w „Software Estimation: Demystifying the Black Art” z 2006 roku. Według McConnella szacunki tworzone na etapie wstępnej koncepcji mogą być błędne nawet czterokrotnie w górę albo w dół, co daje szesnastokrotną rozpiętość, i to w najlepszym przypadku, w dobrze prowadzonych projektach (Jeff Atwood o stożku niepewności, cytujący McConnella). W miarę jak zakres, wymagania i projekt techniczny się krystalizują, stożek się zwęża.

Warto znać dwa zastrzeżenia. Po pierwsze, liczby w stożku pochodzą z doświadczenia i osądu, a nie z jednego pomiaru na dużej próbie, więc traktuj je jako ilustrację rzędu wielkości. Po drugie, stożek zwęża się tylko w projektach, które aktywnie redukują niepewność: robią analizę, budują prototypy, podejmują decyzje. W projektach źle prowadzonych niepewność nie maleje, tylko trwa do końca.

Drugie źródło rozrzutu to interpretacja luk. Gdy zapytanie ofertowe mówi „integracja z systemem polisowym”, jeden dostawca wycenia odczyt danych przez gotowe API, drugi dwustronną synchronizację z obsługą błędów i kolejką, a trzeci dopisuje wykluczenie „integracja w zakresie do ustalenia”. Każda z tych wycen może być rzetelna. Opisują po prostu różne projekty. O tym, jak napisać zapytanie, które zmniejsza ten rozrzut, piszemy w artykule o zapytaniu ofertowym na oprogramowanie dedykowane.

Trzecie źródło to różna wycena ryzyka. Dostawca, który przejmuje ryzyko zakresu w modelu stałej ceny, dolicza za nie więcej niż dostawca rozliczający się za faktycznie przepracowany czas. Dostawca z doświadczeniem w podobnych projektach zna pułapki i je wycenia; dostawca bez takiego doświadczenia ich nie widzi i wycenia niżej, co nie znaczy, że projekt będzie tańszy.

Wniosek dla kupującego: rozrzut cen nie jest dowodem, że ktoś oszukuje, ale jest sygnałem, że porównujesz różne projekty albo różne założenia. Zanim wybierzesz najniższą liczbę, sprawdź, czy wszyscy wycenili to samo.

Z czego składa się cena projektu w software house?

Każda wycena oprogramowania dedykowanego, niezależnie od formy, składa się z pięciu elementów. Rzetelna oferta pokazuje je osobno albo przynajmniej potrafi je pokazać na prośbę.

1. Pracochłonność wytworzenia. Liczba osobodni potrzebnych na zaprojektowanie i zaprogramowanie funkcji, rozbita na moduły lub etapy i na role: backend, frontend, mobile, architekt. To serce wyceny i tu powstaje większość błędów szacowania.

2. Praca wokół kodu. Analiza biznesowa, projektowanie interfejsu, testy (ręczne i automatyczne), zarządzanie projektem, DevOps i konfiguracja środowisk, wdrożenie, dokumentacja, poprawki po testach akceptacyjnych. Ta część jest często niedoszacowana albo ukryta w stawkach, a w realnym projekcie stanowi istotną część całości.

3. Stawki. Cena osobodnia dla każdej roli i poziomu doświadczenia. Stawki różnią się między dostawcami i krajami, ale same w sobie mówią niewiele: zespół z wyższą stawką i większym doświadczeniem może dostarczyć funkcję w krótszym czasie i z mniejszą liczbą poprawek.

4. Rezerwa na ryzyko. Dodatkowa pracochłonność lub kwota przeznaczona na zdarzenia, które mogą się wydarzyć, ale nie wiadomo, czy się wydarzą: integracja trudniejsza niż zakładano, wydajność wymagająca optymalizacji, zmiana w systemie zewnętrznym. O niej za chwilę osobno.

5. Marża dostawcy. Zysk i koszty ogólne firmy: sprzedaż, administracja, rekrutacja, ławka specjalistów między projektami. W modelu stawek dziennych jest zwykle wliczona w stawkę; w modelu stałej ceny bywa wliczona w cenę całości.

Do tego mogą dochodzić koszty zewnętrzne: licencje na komponenty, usługi chmurowe, narzędzia, certyfikaty, testy penetracyjne wykonywane przez osobny podmiot. Dobrze jest wiedzieć, które z nich są w ofercie, a które zapłacisz osobno.

Dlaczego to rozbicie jest tak ważne? Bo bez niego nie da się odpowiedzieć na podstawowe pytanie: czy ta wycena jest realna. Kwota 800 tysięcy złotych może oznaczać rzetelną wycenę dla mniejszego zakresu albo zaniżoną wycenę dla większego. Dopiero osobodni według ról i modułów pozwalają porównać ofertę z innymi i z własnym rozumieniem projektu.

Jak dostawca szacuje pracochłonność: od dołu, przez analogię czy trzypunktowo?

Software house’y używają kilku technik szacowania, często łącząc je ze sobą. Warto je znać, bo od techniki zależy, jak bardzo możesz ufać wynikowi. Krótkie omówienie metod znajdziesz też w haśle wycena projektu IT.

Szacowanie od dołu (bottom-up). Zakres dzieli się na małe zadania, każde szacuje się osobno, a wyniki sumuje. To najbardziej pracochłonna i zwykle najdokładniejsza metoda, ale tylko wtedy, gdy zakres jest na tyle znany, że da się go rozbić. Jej słabość: pomija zadania, których nikt nie wypisał. Suma szacunków znanych zadań jest systematycznie niższa niż rzeczywisty koszt, bo w realnym projekcie zawsze pojawiają się rzeczy, których nie było na liście.

Szacowanie przez analogię. Dostawca porównuje projekt z podobnymi, które już zrealizował, i koryguje o różnice. Dobra metoda na wczesnym etapie, pod warunkiem że dostawca naprawdę ma dane z podobnych projektów, a nie tylko wrażenie. Zapytaj, do jakich projektów porównywał i jak duże były różnice.

Szacowanie trzypunktowe (PERT). Dla każdego zadania podaje się trzy wartości: optymistyczną (O), najbardziej prawdopodobną (M) i pesymistyczną (P). Wartość oczekiwaną liczy się ze wzoru (O + 4M + P) / 6. Ta metoda ma dużą zaletę dla kupującego: pokazuje niepewność wprost. Zadanie oszacowane na 10, 15 i 40 dni jest zupełnie innym ryzykiem niż zadanie oszacowane na 13, 15 i 18 dni, choć wartość najbardziej prawdopodobna jest identyczna. Jeśli dostawca szacuje trzypunktowo, poproś o te dane. Mówią więcej niż sama suma.

Szacowanie w punktach historyjek i prędkość zespołu. W zwinnych zespołach pracochłonność bywa szacowana w punktach względnych, a koszt wynika z prędkości zespołu w kolejnych sprintach. Działa dobrze do planowania wewnątrz projektu, gorzej jako podstawa wyceny przed startem, bo prędkość nowego zespołu w nowym projekcie nie jest jeszcze znana. Krytyczne spojrzenie na to, jakie decyzje punkty faktycznie wspierają, znajdziesz w artykule estymacja w story points jako teatr decyzyjny.

Przykład: dostawca szacuje moduł raportów na 20 dni w wariancie optymistycznym, 30 w najbardziej prawdopodobnym i 70 w pesymistycznym, bo nie wie, czy dane źródłowe będą wymagały czyszczenia. Wartość oczekiwana to (20 + 120 + 70) / 6, czyli 35 dni, a nie 30. Ta różnica pięciu dni to właśnie cena niepewności, która w szacunku jednopunktowym by zniknęła.

W praktyce rzetelna wycena często łączy dwie metody: szacuje od dołu tam, gdzie zakres jest znany, przez analogię tam, gdzie nie jest, i sprawdza wynik drugą techniką. Jeśli obie dają podobny rząd wielkości, wycena jest bardziej wiarygodna. Jeśli dostawca nie potrafi powiedzieć, jaką metodą szacował, wycena jest najpewniej oparta na wrażeniu.

Ile pracy jest poza programowaniem i dlaczego wycena bez niej jest podejrzana?

To najczęstszy powód, dla którego tania oferta okazuje się droga. Programowanie funkcji to tylko część pracy potrzebnej do dostarczenia działającego systemu. Reszta to:

• analiza i doprecyzowanie wymagań w trakcie projektu, a nie tylko przed nim;
• projektowanie interfejsu i doświadczeń użytkownika, jeśli system ma użytkowników spoza zespołu projektowego;
• testy: pisanie testów automatycznych, testy ręczne, testy regresji przed każdym wydaniem, testy wydajności i bezpieczeństwa;
• zarządzanie projektem i komunikacja: planowanie, spotkania, raportowanie, zarządzanie zmianą;
• DevOps: środowiska, pipeline CI/CD, monitoring, kopie zapasowe;
• wdrożenie i migracja danych;
• poprawki po testach akceptacyjnych i stabilizacja po uruchomieniu.

Jaki udział tej pracy jest rozsądny? Nie znamy wiarygodnego, publicznego badania, które podawałoby jedną liczbę dla wszystkich projektów, i nie chcemy jej wymyślać. Jako orientacyjny szacunek z praktyki rynkowej: w projektach biznesowych praca poza samym programowaniem to zwykle co najmniej jedna trzecia całości, a w projektach z wysokimi wymaganiami jakościowymi, regulacyjnymi lub integracyjnymi więcej. Udział rośnie wraz z liczbą integracji, wymaganiami bezpieczeństwa, liczbą środowisk i tym, ile osób po stronie klienta trzeba zaangażować.

Dlatego sygnałem ostrzegawczym jest oferta, w której programowanie to prawie całość, a testy i zarządzanie są symbolicznymi pozycjami. Ta praca i tak zostanie wykonana, tylko w jednym z trzech trybów: jako zlecenia zmian, jako nieodpłatne nadgodziny zespołu (co zwykle odbija się na jakości) albo wcale, co odkrywasz po wdrożeniu. Porównując oferty, zestaw udział testów, analizy i zarządzania w każdej z nich. Duże różnice są ważniejszym tematem do rozmowy niż różnice w stawkach.

Czym jest rezerwa na ryzyko i ile powinna wynosić?

Rezerwa na ryzyko (contingency) to część budżetu przeznaczona na zdarzenia, które mogą wystąpić w projekcie, ale nie wiadomo, czy wystąpią i w jakim zakresie. W zarządzaniu projektami rozróżnia się dwa rodzaje rezerw, a w ofertach warto je rozróżniać także:

• rezerwa na znane ryzyka dotyczy zidentyfikowanych zdarzeń: integracja z systemem bez dokumentacji, nowa technologia, zależność od dostawcy zewnętrznego. Można ją oszacować, mnożąc prawdopodobieństwo ryzyka przez jego koszt;
• rezerwa zarządcza dotyczy rzeczy, których nikt nie przewidział. Tej nie da się wyliczyć z listy, wynika z doświadczenia i z położenia na stożku niepewności.

Dlaczego rezerwa jest potrzebna, dobrze pokazują dane o projektach IT. Badanie Flyvbjerga i Budziera opublikowane w Harvard Business Review w 2011 roku, obejmujące 1471 projektów IT, wykazało średnie przekroczenie kosztów na poziomie 27%, ale ta średnia ukrywa „gruby ogon”: co szósty projekt przekroczył koszty średnio o 200%, a harmonogram o prawie 70% (HBR, 2011). Wcześniejsze badanie McKinsey i Uniwersytetu Oksfordzkiego z 2012 roku pokazało, że duże projekty IT przekraczały budżet średnio o 45% (McKinsey, 2012). Wycena bez żadnej rezerwy zakłada, że Twój projekt będzie lepszy niż średnia, i nie mówi dlaczego.

Ile powinna wynosić? Nie ma jednej normy rynkowej i każda podana bez kontekstu liczba byłaby wymyślona. Jako orientacyjny szacunek: przy dobrze zdefiniowanym zakresie, znanej technologii i doświadczonym zespole rezerwa rzędu kilkunastu procent jest typowa. Przy zakresie opisanym na kilku stronach, niesprawdzonych integracjach, nowej technologii albo dużej zależności od decyzji klienta uzasadnione bywa 30–40% i więcej. Wysokość powinna wynikać z położenia na stożku niepewności: im wcześniej wyceniasz, tym większa.

Prosty przykład pokazuje, jak taka rezerwa może powstać. Załóżmy, że wycena bazowa portalu to 800 osobodni. Dostawca identyfikuje trzy znane ryzyka: integracja z systemem polisowym może wymagać dodatkowych 60 osobodni (prawdopodobieństwo 50%), migracja danych historycznych może zająć 40 osobodni więcej (prawdopodobieństwo 40%), a wymagania wydajnościowe mogą wymusić optymalizację za 50 osobodni (prawdopodobieństwo 30%). Wartość oczekiwana tych ryzyk to 30 + 16 + 15, czyli 61 osobodni, około 8% bazy. Do tego dochodzi rezerwa zarządcza na rzeczy nieprzewidziane, zależna od tego, jak wcześnie w stożku niepewności jesteś. Tak policzona rezerwa daje się omówić pozycja po pozycji, a gdy któreś ryzyko zostanie wyeliminowane, na przykład przez prototyp integracji, rezerwa powinna spaść.

Ważniejsze od wysokości są trzy pytania:

1. Czy rezerwa jest jawna? Jawna rezerwa pozwala o niej rozmawiać. Ukryta w szacunkach zadań rozmywa się i zwykle zostaje zużyta niezależnie od tego, czy ryzyka się zmaterializowały.
2. Z czego wynika? Dostawca powinien umieć wskazać ryzyka, na które jest przeznaczona. „20%, bo tak zawsze robimy” to słabe uzasadnienie.
3. Kto decyduje o jej użyciu i co się dzieje z niewykorzystaną częścią? W modelu stałej ceny niewykorzystana rezerwa zostaje zwykle u dostawcy, bo to on przejął ryzyko. W modelach z rozliczeniem za czas rezerwa jest budżetem klienta, którego użycie powinno wymagać zgody i raportu.

Wracając do dyrektora finansowego z początku: zamiast wykreślać rezerwę, lepiej zapytać, z czego wynika, i poprosić o mechanizm jej kontroli. Jeśli dostawca pokaże listę ryzyk i zgodzi się, że użycie rezerwy wymaga akceptacji, a niewykorzystana część nie jest fakturowana, rezerwa staje się narzędziem zarządzania, a nie buforem.

Jak stawka, skład zespołu i seniority przekładają się na cenę?

Stawka dzienna jest najbardziej widocznym elementem oferty i najczęściej przecenianym przy porównaniu. Cena projektu to iloczyn stawki i liczby dni, a liczba dni zależy od doświadczenia zespołu.

Dla orientacji w polskim rynku: w naszym cenniku senior developer backendu kosztuje 1440–2080 PLN netto za dzień, co odpowiada benchmarkowi 180–260 zł za godzinę, a architekt lub tech lead 2080–2800 PLN za dzień. Junior developer backendu to 720–1040 PLN za dzień. To nasze stawki, nie średnia rynkowa, ale dają punkt odniesienia do porównania ofert.

Różnica w stawce między juniorem a seniorem jest mniej więcej dwukrotna, ale różnica w produktywności przy złożonych zadaniach bywa większa, zwłaszcza gdy liczyć poprawki, przeglądy kodu i czas seniora poświęcony na pomoc juniorom. Zespół zdominowany przez juniorów ma niską stawkę średnią, ale nie zawsze niski koszt funkcji. Z drugiej strony zespół złożony wyłącznie z architektów jest drogi i niepotrzebny do prostych zadań. Rozsądny skład to mieszanka, w której seniorzy odpowiadają za architekturę, kluczowe moduły i przeglądy, a mniej doświadczeni realizują dobrze zdefiniowane zadania.

Przy porównywaniu ofert zwróć uwagę na trzy rzeczy. Pierwsza to proporcje ról: czy jest architekt lub lider techniczny, czy jest tester, czy jest analityk, czy kierownik projektu ma rozsądny wymiar czasu. Druga to proporcje seniority: ilu seniorów, ilu mid, ilu juniorów i kto pracuje nad czym. Trzecia to stabilność: czy osoby z oferty to te same, które będą pracować w projekcie, i co się dzieje, gdy ktoś odejdzie. Zmiana zespołu w trakcie projektu kosztuje czas wdrożenia nowej osoby, którego wycena zwykle nie uwzględnia.

Dwie oferty z tą samą łączną ceną mogą oznaczać zupełnie różne ryzyka: jedna z mniejszym zespołem seniorów, druga z większym zespołem juniorów i dłuższym harmonogramem. Druga nie jest tańsza, jest tylko inaczej rozłożona w czasie.

Jak model rozliczeń zmienia sposób wyceny?

Szczegółowe porównanie modeli rozliczeń znajdziesz w osobnym artykule, ale jedna rzecz jest ważna dla czytania wyceny: ta sama pracochłonność daje różne ceny w różnych modelach, bo ryzyko leży po różnych stronach.

W modelu time & materials płacisz za faktycznie przepracowany czas po ustalonych stawkach. Wycena jest szacunkiem, nie zobowiązaniem. Rezerwa, jeśli jest, to Twój budżet na niepewność. Dostawca nie musi doliczać premii za ryzyko zakresu, więc szacunek bywa niższy, ale koszt końcowy zależy od tego, jak zarządzasz zakresem.

W modelu fixed price dostawca zobowiązuje się dostarczyć określony zakres za określoną cenę. Przejmuje ryzyko pomyłki w szacunku, więc dolicza za nie premię, i jest to racjonalne. Na papierze fixed price jest zwykle droższy. W praktyce bywa tańszy przy stabilnym, dobrze zdefiniowanym zakresie, a droższy przy niepewnym, bo każda zmiana staje się płatnym zleceniem.

W modelu abonamentu zespołu płacisz stałą miesięczną kwotę za zespół o ustalonym składzie. Wycena projektu zamienia się w pytanie, ile miesięcy pracy zespołu potrzeba na dany zakres, a ryzyko zakresu leży po Twojej stronie, podobnie jak w time & materials.

Jest też wariant mieszany, który dobrze sprawdza się w projektach o średniej niepewności: stała cena za fazę discovery lub pierwszy etap, a potem rozliczenie za czas albo kolejne etapy wyceniane na stałe na podstawie wiedzy zdobytej w poprzednich. Ten wariant przesuwa decyzję o dużych kwotach na moment, w którym stożek niepewności jest już węższy. W tworzeniu oprogramowania na zamówienie wyceniamy w modelu fixed price albo time & materials, zależnie od tego, jak dobrze zdefiniowany jest zakres, i zaczynamy od fazy discovery trwającej zwykle od tygodnia do dwóch.

Które czynniki najbardziej podnoszą wycenę projektu?

Poniższa tabela zbiera czynniki, które w największym stopniu wpływają na wycenę oprogramowania dedykowanego. Kierunek i uzasadnienie wynikają z mechaniki szacowania opisanej wyżej. Nie podajemy procentowego wpływu każdego czynnika, bo zależy on od projektu i każda taka liczba byłaby zgadywaniem. Kolumna „jak go zmniejszyć” jest dla kupującego najważniejsza.

Czynnik	Dlaczego podnosi cenę	Jak go zmniejszyć po stronie zamawiającego
Niejasny zakres	Dostawca dolicza rezerwę albo wycenia najszerszą interpretację	Priorytety MoSCoW, scenariusze, lista „poza zakresem”, faza discovery
Liczba i jakość integracji	Nieudokumentowane API, brak środowisk testowych, zależność od innego dostawcy	Opis każdej integracji, dostęp do dokumentacji i środowiska testowego przed wyceną
Wymagania niefunkcjonalne	Wysoka dostępność, wydajność i bezpieczeństwo wymagają droższej architektury i więcej testów	Liczby zamiast przymiotników, poziom dopasowany do realnej potrzeby biznesu
Migracja danych	Czyszczenie, mapowanie i weryfikacja danych to osobny projekt	Analiza jakości danych przed wyceną, decyzja, które dane migrować
Regulacje i zgodność	Dokumentacja, audyty, testy bezpieczeństwa, rejestry	Wskazanie konkretnych wymagań, a nie ogólne „zgodność z przepisami”
Dostępność decyzyjna klienta	Czekanie na decyzje to ryzyko harmonogramu, które ktoś musi wycenić	Nazwany właściciel produktu z realnym czasem, terminy odpowiedzi w umowie
Agresywny termin	Większy zespół, praca równoległa, więcej koordynacji, wyższe ryzyko	Etapowanie, minimalna wersja na termin, reszta później
Model fixed price przy niepewności	Premia za ryzyko zakresu, które przejmuje dostawca	Fixed price na discovery lub pierwszy etap, reszta w modelu z jawną stawką
Nowa lub niszowa technologia	Brak danych do analogii, wyższe stawki specjalistów	Prototyp techniczny przed wyceną całości
Rygorystyczne warunki umowne	Wysokie kary, nieograniczona odpowiedzialność, długa gwarancja	Kary powiązane z mierzalnymi zdarzeniami i limitem, zob. artykuł o umowie

Ostatni wiersz bywa niedoceniany. Warunki umowne są częścią ceny: dostawca, który musi przyjąć wysokie kary bez limitu, wyceni to ryzyko. Które zapisy chronią Cię naprawdę, a które tylko podnoszą cenę, omawiamy w artykule o klauzulach umowy z software house’em.

Co sprawdzić w ofercie, zanim ją porównasz z innymi?

Poniższe pytania warto zadać każdemu dostawcy, najlepiej w formie formularza dołączonego do zapytania, żeby odpowiedzi były porównywalne.

O pracochłonność:

• Jak wygląda rozbicie na moduły lub etapy i na role, w osobodniach?
• Jaką metodą szacowaliście i czy sprawdzaliście wynik drugą metodą?
• Do jakich wcześniejszych projektów porównywaliście ten zakres?
• Które pozycje mają największą niepewność i jaki jest dla nich szacunek optymistyczny i pesymistyczny?

O pracę wokół kodu:

• Ile osobodni przypada na testy, analizę, zarządzanie projektem, DevOps i wdrożenie?
• Czy wycena obejmuje testy automatyczne, a jeśli tak, na jakim poziomie?
• Czy obejmuje stabilizację po uruchomieniu i ile czasu?

O rezerwę:

• Czy wycena zawiera rezerwę, jaką i na jakie ryzyka?
• Kto decyduje o jej użyciu i co dzieje się z niewykorzystaną częścią?

O założenia i zmiany:

• Jakie założenia przyjęliście, których nie było w zapytaniu?
• Czego nie wyceniliście?
• Jak wygląda procedura zmian i po jakich stawkach są wyceniane?
• Jakie działania i decyzje po naszej stronie zakłada harmonogram?

O zespół:

• Kto konkretnie będzie pracował, w jakich rolach i w jakim wymiarze?
• Co się stanie, jeśli ktoś z zespołu odejdzie?

Odpowiedzi na te pytania są ważniejsze niż kwota końcowa. Dwie oferty z tą samą ceną, ale z różnymi założeniami i wykluczeniami, to dwie różne ceny. Oferta wyższa, ale z jawną rezerwą, pełnym zakresem testów i nazwanym zespołem może okazać się tańsza na końcu projektu niż oferta niższa, która tego wszystkiego nie zawiera.

Jak rozpoznać wycenę, która nie wytrzyma kontaktu z projektem?

Niektóre wyceny wyglądają dobrze w tabeli, a zaczynają się rozpadać w drugim lub trzecim miesiącu. Sześć sygnałów pozwala je rozpoznać wcześniej.

Jedna kwota bez rozbicia. Dostawca, który nie potrafi pokazać, z czego składa się cena, albo nie wie tego sam, albo nie chce, żebyś to wiedział.

Precyzja nieadekwatna do etapu. Wycena „1 247 500 zł” dla systemu opisanego na dziesięciu stronach sugeruje dokładność, której na tym etapie nie ma. Rzetelna wycena wczesna to przedział albo kwota z jawną rezerwą i listą założeń. Paradoksalnie przedział budzi większe zaufanie niż liczba z dokładnością do pięciuset złotych.

Brak ryzyk. Jeśli dostawca nie wskazał żadnego ryzyka w projekcie, który ma kilka integracji i migrację danych, albo nie przeczytał zapytania, albo nie chce Cię martwić przed podpisaniem.

Cena wyraźnie niższa od pozostałych bez wyjaśnienia. Różnica rzędu jednej trzeciej od mediany ofert wymaga rozmowy. Czasem ma dobre wyjaśnienie, na przykład gotowy komponent. Częściej oznacza węższą interpretację zakresu albo pominiętą pracę wokół kodu.

Harmonogram, który nie wynika z pracochłonności. Jeśli 2000 osobodni ma się zmieścić w czterech miesiącach, zespół musi liczyć około 25 osób pracujących od pierwszego dnia z pełną produktywnością. Takiej sytuacji praktycznie nie ma; duże zespoły potrzebują czasu na rozruch i więcej koordynacji. Podziel pracochłonność przez czas i porównaj z deklarowanym składem zespołu.

Brak pierwszego punktu kontrolnego w ciągu kilku tygodni. Jeśli pierwszy działający fragment systemu ma się pojawić po kilku miesiącach, dowiesz się o błędach w wycenie dopiero wtedy, gdy będzie za późno na tanią korektę.

Każdy z tych sygnałów to powód do pytań, a nie automatycznego odrzucenia oferty. Rzetelny dostawca potrafi obronić swoją wycenę. Ten, który na pytanie „dlaczego tak tanio?” odpowiada „bo jesteśmy efektywni”, zwykle odzyska różnicę później.

Jak zmniejszyć niepewność, zanim zapłacisz za cały projekt?

Najskuteczniejszy sposób na lepszą wycenę to nie negocjacje, tylko zwężenie stożka niepewności przed podjęciem dużej decyzji. Cztery techniki działają szczególnie dobrze.

Faza discovery. Kilka tygodni analizy, w trakcie których dostawca razem z Tobą doprecyzowuje zakres, projektuje architekturę, sprawdza integracje i przygotowuje szacunek reszty. Kosztuje ułamek projektu, a jej wynik, czyli dokumentacja i wycena, należy do Ciebie i możesz go użyć także z innym dostawcą. Po discovery szacunek przesuwa się z szerokiego końca stożka w jego węższą część. Jak wygląda cały proces od discovery do utrzymania, opisujemy w przewodniku po oprogramowaniu dedykowanym.

Prototyp techniczny najbardziej ryzykownego elementu. Jeśli największa niepewność dotyczy jednej integracji albo jednej technologii, zbuduj najpierw mały prototyp właśnie tego elementu. Kilka dni lub tygodni pracy zamienia największą pozycję rezerwy w znany koszt.

Etapowanie z ponowną wyceną. Zamiast jednej wyceny na całość, wycena pierwszego etapu na stałe i szacunek reszty, aktualizowany po każdym etapie na podstawie rzeczywistej prędkości zespołu. To uczciwe wobec obu stron: dostawca nie musi wyceniać niewiadomych, a Ty widzisz, czy założenia się sprawdzają, zanim wydasz większość budżetu.

Minimalna wersja na start. Wycena w podziale na „musi” i „powinno” pozwala uruchomić najpierw mniejszą, w pełni działającą wersję i podjąć decyzję o reszcie na podstawie danych z użycia. Przy MVP wstępne widełki daje nasz kalkulator kosztów MVP.

Wszystkie cztery techniki mają wspólną cechę: przenoszą duże decyzje finansowe na moment, w którym wiesz więcej. Zamiast płacić za niepewność w formie rezerwy albo zleceń zmian, płacisz za jej zmniejszenie, a to zwykle jest tańsze.

Jakie są kluczowe wnioski?

Wycena projektu w software house to nie cena produktu z katalogu, tylko liczbowy opis niewiedzy na danym etapie. Im wcześniej wyceniasz, tym szerszy jest rozrzut i tym większa powinna być rezerwa.

Zapamiętaj sześć rzeczy. Po pierwsze, na etapie wstępnej koncepcji szacunki mogą się mylić nawet czterokrotnie w każdą stronę, więc rozrzut ofert jest normalny, a porównanie ma sens dopiero przy tych samych założeniach. Po drugie, cena składa się z pracochłonności, pracy wokół kodu, stawek, rezerwy i marży; poproś o rozbicie, zanim zaczniesz porównywać. Po trzecie, praca poza programowaniem to istotna część każdego projektu, a oferta, w której jej prawie nie ma, podrożeje w trakcie. Po czwarte, jawna rezerwa na ryzyko to zaleta oferty, nie wada; pytaj, z czego wynika i kto decyduje o jej użyciu, zamiast ją wykreślać. Po piąte, stawka dzienna mówi mniej niż skład i stabilność zespołu. Po szóste, najtańszy sposób na lepszą wycenę to zmniejszenie niepewności przed dużą decyzją: discovery, prototyp ryzykownego elementu i etapowanie.

Jeśli masz przed sobą wycenę, której nie potrafisz ocenić, albo kilka ofert, które różnią się bardziej, niż powinny, umów rozmowę. Pomożemy rozłożyć je na składniki i wskazać, gdzie leżą różnice. A jeśli rozważasz projekt w tworzeniu oprogramowania na zamówienie, zaczniemy od fazy discovery, po której wycena reszty opiera się na wiedzy o projekcie, a nie na kilku stronach opisu.