Najtańsza oferta software house’u: dlaczego kosztuje najwięcej

Najtańsza oferta software house’u zwykle kosztuje najwięcej, bo jest tania kosztem tego, czego w niej nie ma: analizy, testów, obsługi błędów, dokumentacji i czasu na zmiany. Te elementy i tak trzeba będzie zrobić, tylko później, drożej i pod presją terminu. Nie każda niska cena jest pułapką, ale prawie każda pułapka zaczyna się od niskiej ceny. Poniżej piszę, co najczęściej wypada z wyceny, jakie koszty spadają potem na zamawiającego i jak porównać oferty tak, żeby porównywać to samo.

Dlaczego najtańsza oferta software house’u rzadko jest najtańsza

Bo cena w ofercie to tylko pierwsza rata kosztu systemu. Prawdziwy rachunek obejmuje budowę, zmiany w trakcie projektu, poprawki po starcie, utrzymanie, czas Twoich ludzi i koszt opóźnienia. Oferta pokazuje zwykle tylko budowę.

Kiedy rozmawiam z firmami, które wybierają wykonawcę, proszę, żeby patrzyły na system jak na samochód firmowy. Cena zakupu jest ważna, ale o tym, ile naprawdę wydasz, decydują serwis, awaryjność i to, czy po trzech latach da się go jeszcze sprzedać. Z oprogramowaniem jest podobnie: tani system, którego nikt poza autorem nie umie rozwijać, nie ma wartości odsprzedaży, a każda zmiana jest droga.

Tania wycena ma też drugą stronę. Wykonawca, który wycenił projekt zbyt nisko, w pewnym momencie zaczyna tracić. Wtedy ma trzy wyjścia: ciąć jakość, szukać pieniędzy w zmianach albo odejść od projektu. Żadne z nich nie jest dobre dla zamawiającego.

Co najczęściej wypada z niskiej wyceny

Z niskiej wyceny najczęściej wypada praca, której nie widać na pokazie: przygotowanie, zabezpieczenia i to, co dzieje się po starcie. Przy porównywaniu ofert szukam przede wszystkim tych pozycji:

• Analiza i projekt. Bez kilku warsztatów i makiet programiści zgadują, jak ma działać proces. Zgadywanie wychodzi na jaw przy odbiorze.
• Testy. Testy automatyczne i testy regresji, czyli sprawdzenie, czy nowa funkcja nie zepsuła starej. W tanich ofertach testuje zwykle klient, na produkcji.
• Obsługa błędów w integracjach. Integracja z ERP, płatnościami czy kurierem działa w prezentacji. Pytanie, co się dzieje, gdy zewnętrzny system nie odpowiada albo zwraca dane w złym formacie.
• Środowiska i wdrożenia. Serwer testowy, automatyczne wdrażanie, monitoring i kopie zapasowe. Bez nich każda aktualizacja to ryzyko.
• Migracja danych. Przeniesienie klientów, produktów i historii zamówień ze starego systemu bywa osobnym projektem, a w ofercie zajmuje jedną linijkę albo nie ma jej wcale.
• Bezpieczeństwo i wydajność. Uprawnienia, ochrona danych osobowych, zachowanie systemu przy większym ruchu.
• Dokumentacja i przekazanie. Opis architektury, instrukcja uruchomienia, dostęp do repozytorium. To od tego zależy, czy kiedyś zmienisz wykonawcę bez budowania wszystkiego od nowa.
• Zarządzanie projektem. Ktoś musi planować, pilnować priorytetów i odpowiadać na pytania. Jeśli w ofercie nie ma na to czasu, tę rolę przejmuje ktoś z Twojej firmy.

Każda z tych pozycji może być zrobiona skromniej, jeśli projekt na to pozwala. Problem zaczyna się wtedy, gdy znika bez słowa, a zamawiający dowiaduje się o tym dopiero przy pierwszej awarii.

Ukryte koszty, które płaci zamawiający

Ukryte koszty, jakie niesie najtańsza oferta software house’u, nie są ukryte w umowie, tylko w tym, czego umowa nie opisuje. Wychodzą w trakcie projektu i po jego zakończeniu, często w innym budżecie niż ten, z którego płacono za budowę.

Zmiany, które nie były zmianami

Jeśli zakres jest opisany ogólnie, wykonawca z niską ceną ma interes, żeby czytać go wąsko. Funkcja, którą uważałeś za oczywistą, staje się zleceniem dodatkowym. Przy wycenie w modelu stałej ceny to częsty mechanizm odzyskiwania marży. O tym, jak dobrać model rozliczeń do projektu, piszę w tekście o wyborze między modelem fixed price i time and materials.

Czas Twojego zespołu

Gdy wykonawca nie testuje, testują Twoi pracownicy. Gdy nie ma analityka, kierownik działu tłumaczy proces programistom po raz trzeci. Ten czas nie pojawia się w żadnej fakturze, ale jest realnym kosztem i odciąga ludzi od ich pracy.

Opóźnienie

System, który miał ruszyć przed sezonem, a rusza po nim, kosztuje utracone zamówienia i pracę ręczną, którą miał zastąpić. Przy ocenie ofert pytam więc zawsze, co się stanie z biznesem, jeśli start przesunie się o kwartał.

Utrzymanie i uzależnienie od wykonawcy

Tani projekt często ma drogie utrzymanie. Kod bez testów i dokumentacji umie bezpiecznie zmieniać tylko jego autor, więc stawki za rozwój dyktuje on. Jeśli umowa nie przenosi praw do kodu albo nie daje dostępu do repozytorium, zmiana wykonawcy oznacza w praktyce budowę od nowa.

Skąd biorą się tak różne wyceny tego samego systemu

Najczęściej z różnych założeń, a nie z różnej uczciwości. Dwie firmy czytają ten sam opis i wyobrażają sobie dwa różne systemy. Jedna zakłada import zamówień z pliku raz dziennie, druga dwukierunkową integrację w czasie rzeczywistym. Obie wyceny mogą być rzetelne, tylko dotyczą czegoś innego, więc najtańsza oferta software house’u nie musi świadczyć o złej woli.

Inne źródła rozrzutu to skład zespołu, bufor na ryzyko i strategia handlowa. Doświadczony zespół jest droższy za godzinę, ale często potrzebuje mniej godzin i popełnia mniej kosztownych błędów. Wykonawca, który bierze na siebie ryzyko stałej ceny, dolicza do niej bufor. Zdarza się też świadome wejście niską ceną, z planem odrobienia marży na zmianach i utrzymaniu. Szczegółowo o tym, od czego zależy koszt systemu, piszę w osobnym tekście.

Jak uczciwie porównać oferty software house’ów

Porównuj oferty dopiero wtedy, gdy wiesz, że dotyczą tego samego zakresu, i patrz na całkowity koszt w kilku latach, a nie na jedną kwotę. W praktyce sprowadza się to do kilku kroków:

1. Daj wszystkim ten sam opis. Cele, procesy, użytkownicy, integracje i to, czego na pewno nie potrzebujesz. Pytania od jednego wykonawcy przekaż pozostałym wraz z odpowiedziami.
2. Poproś o rozbicie wyceny. Moduły lub etapy, role w zespole, szacowany nakład pracy. Jedna kwota na cały system nie mówi nic.
3. Poproś o listę założeń i wyłączeń. To najcenniejsza część oferty. Jeśli jej nie ma, wykonawca zostawił sobie swobodę interpretacji.
4. Zapytaj, kto będzie pracował. Konkretne role i doświadczenie, a nie portfolio całej firmy.
5. Sprawdź proces zmian i stawki. Jak zgłasza się zmianę, kto ją wycenia, ile kosztuje godzina pracy poza zakresem.
6. Policz utrzymanie. Abonament, czasy reakcji, aktualizacje, hosting. Dodaj to do ceny budowy.
7. Zapytaj o prawa i przekazanie. Własność kodu, dostęp do repozytorium, dokumentacja na koniec projektu.

Pomaga prosta tabela, w której zestawiasz odpowiedzi wszystkich wykonawców obok siebie:

Obszar	Co powinno być w ofercie	Sygnał ostrzegawczy
Zakres	Lista funkcji, założenia, wyłączenia	Ogólnik typu „system zgodny z potrzebami klienta”
Testy	Opis, co i jak jest testowane	Testy po stronie zamawiającego
Zespół	Role, doświadczenie, osoba kontaktowa	Brak informacji, kto pisze kod
Zmiany	Procedura i stawka	„Ustalimy w trakcie”
Utrzymanie	Abonament, czasy reakcji, aktualizacje	Brak tematu w ofercie
Prawa do kodu	Przeniesienie lub licencja, dostęp do repozytorium	Kod zostaje u wykonawcy

Więcej pytań, które warto zadać przed podpisaniem umowy, zebrałem w tekście o tym, jak wybrać software house. Z mojego doświadczenia najwięcej mówi to, jak wykonawca reaguje na pytanie o wyłączenia: konkretna lista jest dobrym znakiem, wymijająca odpowiedź złym.

Kiedy tania oferta jest w porządku

Najtańsza oferta software house’u jest w porządku, gdy jest tania z jasnego powodu, który wykonawca potrafi nazwać. Mniejszy zakres, gotowe narzędzie zamiast budowy od zera, świadomie uproszczony pierwszy etap.

Dobry przykład to MVP, czyli pierwsza wersja z jednym procesem od początku do końca, która ma sprawdzić pomysł, zanim firma zainwestuje w pełny system. Tu cięcie zakresu jest celem, a nie oszczędnością na jakości. Różnica polega na tym, że obie strony wiedzą, co wycięto i dlaczego. Jak to zrobić rozsądnie, opisuję w tekście o tym, jak zaplanować MVP bez przepalania budżetu.

Niska cena bywa też uczciwa, gdy wykonawca ma gotowe moduły, które zna i utrzymuje, albo gdy proponuje skonfigurowanie istniejącego narzędzia zamiast budowy. Zawsze wtedy pytam, co się stanie, gdy potrzeby firmy wyjdą poza to, co daje gotowiec.

Moja zasada przy wyborze oferty

Wybieram ofertę, której założenia rozumiem i z którą zgadza się mój własny szacunek ryzyka, a nie tę z najniższą kwotą. Jeśli jedna oferta jest wyraźnie tańsza od pozostałych, traktuję to jako pytanie, a nie jako okazję: czego w niej brakuje albo co ten wykonawca wie, czego nie wiedzą inni.

Zanim podpiszesz umowę, położysz obok siebie dwie lub trzy oferty i przejdziesz przez tabelę z tego tekstu, zobaczysz, że najtańsza oferta software house’u często przestaje być najtańsza. Jeśli chcesz to zrobić z kimś, kto od lat przygotowuje takie wyceny po stronie wykonawcy, zobacz, jak wygląda współpraca ze mną.