Jak czytać wycenę software house'u i na co uważać

Masz przed sobą trzy oferty na ten sam sklep internetowy i trzy kwoty, które do siebie nie pasują. Zanim porównasz liczby, sprawdź, czy porównujesz ten sam projekt, bo najczęściej każda firma wyceniła trochę inny.

Ten poradnik przeprowadza przez wycenę w kolejności, w jakiej najłatwiej ją czytać: od zakresu, przez model rozliczenia i płatności, po prawa do kodu, koszty poza ofertą i to, co dzieje się po wdrożeniu. Na końcu jest lista pytań do zadania przed podpisaniem umowy. Możesz ją wysłać każdemu wykonawcy, także nam.

Zanim spojrzysz na kwotę, sprawdź, co zostało wycenione

Najczęstszy błąd przy porównywaniu ofert to ułożenie ich od najtańszej do najdroższej. Kwota ma sens dopiero wtedy, gdy wiesz, za co jest. Oferta na sklep, która zawiera integrację z programem do faktur, import produktów z hurtowni i testy na urządzeniach mobilnych, nie jest droższą wersją oferty bez tych elementów. Jest wyceną innego projektu.

Metoda porównania jest żmudna, ale prosta. Weź wszystkie oferty i wypisz z nich każdą pozycję zakresu do jednej wspólnej listy. Potem przy każdej pozycji zaznacz, czy dana oferta ją obejmuje, czy wprost wyklucza, czy w ogóle o niej nie wspomina. Trzecia kategoria jest najważniejsza, bo to w niej siedzą przyszłe nieporozumienia.

Tabela z przykładu nie wskazuje zwycięzcy, tylko pytania. Do oferty A trzeba dopytać o faktury i wersję angielską, do oferty B o projekt graficzny i import, do C o wdrożenie. Dopiero po odpowiedziach kwoty stają się porównywalne, a często okazuje się, że najtańsza oferta po dopisaniu brakujących elementów przestaje być najtańsza.

Jeśli wysyłałeś zapytanie do kilku firm, pomaga też sprawdzenie, czy wszystkie dostały ten sam opis. Wykonawca, który zadał dziesięć pytań i dostał odpowiedzi, wycenia pełniejszy zakres niż ten, który wycenił na podstawie dwóch zdań. Odpowiedzi udzielone jednej firmie przekaż pozostałym, żeby wyceny opierały się na tych samych informacjach.

Zakres opisany funkcjami, a nie hasłami

Hasło w wycenie brzmi konkretnie, ale nic nie zobowiązuje. "Panel administracyjny", "integracja z płatnościami", "responsywność", "optymalizacja SEO" mogą oznaczać zarówno dwa dni pracy, jak i kilka tygodni. Jeśli w umowie jest tylko hasło, obie strony mogą uczciwie uważać, że mają rację, gdy przy odbiorze okaże się, że każda rozumiała je inaczej.

Pozycja zakresu jest opisana dobrze, gdy da się na jej podstawie sprawdzić, czy została zrobiona. Porównaj dwa sposoby zapisania tej samej rzeczy:

Druga kolumna jest dłuższa, ale tylko ona chroni obie strony. Wykonawca wie, co dokładnie ma dostarczyć, a Ty wiesz, co masz prawo odebrać. Jeśli oferta zawiera same hasła, poproś o ich rozpisanie przed podpisaniem umowy. Wykonawca, który wycenił projekt rzetelnie, ma już tę listę w swoich notatkach, bo bez niej nie dałoby się policzyć kwoty.

Druga część dobrego zakresu to lista rzeczy wyłączonych. Teksty na stronę, zdjęcia, tłumaczenia, migracja danych ze starego systemu, szkolenie zespołu, opłaty za zewnętrzne usługi: każda z nich może być w projekcie albo poza nim. Wycena, która nie mówi nic o wyłączeniach, zostawia te decyzje na moment, w którym będą najtrudniejsze do rozmowy, czyli na środek projektu.

Stała cena czy rozliczenie za godziny

Wyceny w branży IT zwykle opierają się na jednym z dwóch modeli. W modelu stałej ceny (fixed price) wykonawca bierze na siebie ryzyko, że projekt zajmie więcej czasu niż zakładał, a Ty znasz kwotę z góry. W modelu czasu i materiałów (time and materials) płacisz za faktycznie przepracowane godziny według ustalonej stawki, a ryzyko przekroczenia estymacji jest po Twojej stronie.

Żaden z modeli nie jest z definicji tańszy. Wykonawca przy stałej cenie dolicza zapas na ryzyko, bo to on zapłaci za niedoszacowanie. Przy rozliczeniu godzinowym tego zapasu nie ma, ale nie ma też górnej granicy. Uczciwie wyceniony projekt w obu modelach powinien kosztować podobnie, a różnica leży w tym, kto ponosi ryzyko pomyłki.

Przy rozliczeniu godzinowym zapytaj o dwie rzeczy. Po pierwsze, o maksymalny budżet, po którego przekroczeniu wykonawca zatrzymuje pracę i pyta o zgodę na dalsze godziny. Po drugie, o formę raportowania: jak często dostajesz zestawienie godzin i jak szczegółowo są opisane. Zestawienie "40 godzin: rozwój aplikacji" nie pozwala niczego skontrolować.

Często spotykany jest też model mieszany: stała cena za dobrze opisany pierwszy etap i rozliczenie godzinowe za dalszy rozwój po starcie. To rozsądne rozwiązanie, gdy pierwsza wersja ma jasny zakres, a kolejne funkcje zależą od tego, jak użytkownicy przyjmą produkt.

Estymacja godzin: jak sprawdzić, czy liczby są realne

Jeśli wycena zawiera rozbicie na godziny, to jest to najcenniejsza jej część, nawet przy stałej cenie. Nie chodzi o to, żeby samodzielnie oceniać, czy formularz kontaktowy zajmie cztery czy sześć godzin. Chodzi o to, żeby zobaczyć, jakie rodzaje pracy wykonawca w ogóle przewidział.

Sprawdź, czy w rozbiciu są pozycje, o których łatwo zapomnieć, bo nie widać ich na gotowym produkcie:

• Testy. Jeśli testy mają zero godzin albo nie ma ich wcale, to albo nie zostaną zrobione, albo są ukryte w innych pozycjach. W obu przypadkach zapytaj, jak wyglądają.
• Wdrożenie. Konfiguracja serwera, domeny, certyfikatu, poczty i przeniesienie projektu na produkcję to realna praca.
• Komunikacja i prowadzenie projektu. Spotkania, raporty i odpowiedzi na pytania zajmują czas niezależnie od tego, czy są w wycenie.
• Poprawki po odbiorze. Czas zarezerwowany na korekty, które wyjdą w pierwszym kontakcie z użytkownikami.
• Dokumentacja. Opis tego, jak uruchomić i rozwijać projekt, bez którego trudno go przekazać komuś innemu.

Jedna pozycja na sto godzin, na przykład "frontend", nie jest estymacją, tylko kwotą przeliczoną na godziny. Poproś o rozbicie na mniejsze części, choćby na główne ekrany albo moduły. Jeśli wykonawca nie potrafi go podać, to znaczy, że nie rozpisał projektu, a kwota pochodzi z porównania do podobnego zlecenia, a nie z analizy Twojego.

Stawka godzinowa i liczba godzin mają znaczenie tylko razem. Niska stawka przy dużej liczbie godzin może dać tę samą kwotę co wysoka stawka przy małej liczbie. Jeśli dwie oferty różnią się liczbą godzin na tę samą funkcję kilkukrotnie, zapytaj obie firmy, jak zamierzają ją zrealizować. Różnica często wynika z innego rozwiązania technicznego, na przykład gotowego komponentu kontra budowy od zera, a to wpływa na późniejsze koszty zmian.

Harmonogram płatności i to, za co płacisz z góry

Harmonogram płatności mówi o tym, jak rozłożone jest ryzyko między stronami. Płatność całości z góry przenosi całe ryzyko na zamawiającego, płatność całości po odbiorze na wykonawcę. Większość rozsądnych umów leży pomiędzy: zaliczka na start, kolejne raty po zakończeniu etapów i ostatnia część po odbiorze.

Każda rata powinna być przypięta do czegoś, co da się sprawdzić. "Druga rata w połowie projektu" nie mówi, co jest połową. "Druga rata po akceptacji prototypu i udostępnieniu stagingu z działającym koszykiem" mówi to jednoznacznie. Jeśli etapy w harmonogramie płatności nie mają opisu tego, co musi być gotowe, dopytaj o to przed podpisaniem.

Sygnały w harmonogramie, które wymagają dopytania:

• Całość albo prawie całość płatna z góry przy projekcie trwającym tygodnie albo miesiące.
• Ostatnia rata wymagalna przed odbiorem, na przykład "po zakończeniu prac programistycznych", zanim miałeś szansę sprawdzić wynik.
• Brak procedury odbioru, czyli zapisu, ile masz czasu na testy i co się dzieje, gdy zgłosisz błędy.
• Terminy płatności bez terminów wykonania po drugiej stronie umowy.

Sprawdź też, czy kwota w wycenie jest netto, czy brutto. Usługi programistyczne w Polsce co do zasady podlegają stawce VAT 23%, więc różnica jest istotna przy porównywaniu ofert. Wykonawca, który korzysta ze zwolnienia z VAT, poda kwotę bez podatku, i wtedy netto oznacza to samo co brutto. Jeśli jedna oferta jest podana netto, a druga brutto, porównanie bez przeliczenia jest błędne.

Poprawki, zmiany zakresu i termin

Wycena powinna odpowiadać na pytanie, co się dzieje, gdy po zobaczeniu efektów chcesz coś zmienić. Spotyka się trzy podejścia: określoną liczbę rund poprawek, zapas czasu na poprawki oraz zasadę, że każda zmiana jest płatna osobno. Każde z nich działa, jeśli jest opisane. Problem pojawia się, gdy wycena milczy.

Najwięcej zależy od definicji poprawki. Poprawka to doprowadzenie czegoś do stanu, który był ustalony: błąd, literówka, element działający inaczej niż w opisie zakresu. Zmiana zakresu to coś nowego: dodatkowa funkcja, nowy widok, przebudowa zaakceptowanego układu. Jeśli wycena mówi o "poprawkach" bez tej granicy, to przy pierwszej większej prośbie obie strony będą ją interpretować na swoją korzyść.

Przy zmianach zakresu zapytaj o procedurę. Dobra praktyka wygląda tak: zgłaszasz zmianę, wykonawca opisuje jej wpływ na termin i kwotę, a prace ruszają dopiero po Twojej akceptacji. Jeśli wycena lub umowa tego nie opisuje, może się okazać, że zmiany realizowane w trakcie na bieżąco pojawią się dopiero na końcowej fakturze.

Sprawdź też, od czego liczy się termin. "Realizacja w 6 tygodni" może oznaczać sześć tygodni od podpisania umowy, od wpłaty zaliczki albo od dostarczenia wszystkich materiałów przez zamawiającego. Ta ostatnia wersja jest uczciwa, bo wykonawca nie zbuduje strony bez tekstów, ale musisz o niej wiedzieć, żeby zaplanować przygotowanie materiałów. Jeśli umowa przewiduje kary umowne za opóźnienie tylko po jednej stronie, zapytaj, jak rozliczane są opóźnienia wynikające z czekania na Twoje decyzje.

Prawa autorskie do kodu i dostęp do repozytorium

To część wyceny, którą najłatwiej pominąć, bo nie wpływa na nic w dniu startu. Ma za to znaczenie za rok albo dwa, gdy zechcesz rozwijać system z innym wykonawcą, sprzedać firmę albo pozyskać inwestora, który zapyta, czy kod na pewno należy do spółki.

Program komputerowy jest w polskim prawie utworem chronionym prawem autorskim. Z ustawy o prawie autorskim i prawach pokrewnych wynikają dwie rzeczy, które trzeba znać przy czytaniu umowy. Umowa przenosząca autorskie prawa majątkowe wymaga formy pisemnej pod rygorem nieważności (art. 53). Obejmuje też tylko pola eksploatacji, które są w niej wyraźnie wymienione (art. 41 ust. 2). Ogólne zdanie "prawa do kodu przechodzą na zamawiającego" bez listy pól eksploatacji może nie dać Ci tego, czego się spodziewasz.

Przy czytaniu wyceny i umowy zwróć uwagę na te elementy:

• Przeniesienie praw czy licencja. Przeniesienie oznacza, że prawa majątkowe należą do Ciebie. Licencja oznacza, że możesz korzystać z kodu na określonych warunkach, a prawa zostają u wykonawcy.
• Pola eksploatacji. Lista powinna obejmować co najmniej utrwalanie i zwielokrotnianie kodu, jego modyfikowanie oraz wprowadzanie do obrotu i udostępnianie.
• Moment przejścia praw. Często jest to chwila zapłaty ostatniej raty. To uczciwe rozwiązanie, ale musisz o nim wiedzieć.
• Elementy, do których praw nie dostaniesz. Biblioteki open source zostają na swoich licencjach, a płatne komponenty i motywy na licencjach ich producentów. Dobra umowa to wyjaśnia.
• Własny framework albo CMS wykonawcy. Jeśli projekt jest zbudowany na zamkniętym narzędziu wykonawcy, zapytaj, czy po zakończeniu współpracy możesz go dalej używać i rozwijać z kimś innym.

Prawa to jedno, a praktyczny dostęp to drugie. Zapytaj, czy w trakcie projektu masz wgląd do repozytorium, czy dostaniesz kod z pełną historią zmian, czy powstanie dokumentacja pozwalająca uruchomić projekt komuś innemu i na kogo zarejestrowane będą domena, serwer i konta w usługach zewnętrznych. Prawa autorskie do kodu, którego fizycznie nie masz, niewiele pomagają w dniu, w którym wykonawca przestaje odpowiadać.

Ta sekcja nie zastępuje porady prawnej. Przy dużym projekcie albo nietypowej umowie daj ją do przeczytania prawnikowi, zanim ją podpiszesz, a nie wtedy, gdy pojawi się spór.

Koszty, których nie ma w kwocie projektu

Kwota w wycenie to koszt wykonania. Koszt posiadania systemu jest wyższy, bo składają się na niego opłaty cykliczne i usługi, których wykonawca nie wlicza, ponieważ płacisz za nie bezpośrednio dostawcom albo pojawiają się dopiero po starcie. Dobra wycena je wymienia, nawet jeśli nie może podać ich dokładnej wysokości.

Ostatni wiersz tabeli jest pozycją, która najczęściej zaskakuje. Kod, który nie jest aktualizowany, z czasem staje się podatny na znane luki bezpieczeństwa, a biblioteki przestają być wspierane. To nie znaczy, że każda strona wymaga płatnej opieki co miesiąc. Znaczy tyle, że ktoś powinien za to odpowiadać, i dobrze, żeby wycena mówiła, czy to wykonawca, czy Ty.

Zestawienie takich kosztów najłatwiej zrobić w podziale na pierwszy rok i kolejne lata. W pierwszym roku dochodzą opłaty jednorazowe, na przykład licencje i przygotowanie treści, a w kolejnych zostają tylko pozycje cykliczne. Jeśli dwie oferty proponują różne rozwiązania techniczne, na przykład jedna płatny system sklepowy w abonamencie, a druga własny kod na zwykłym serwerze, porównanie samych kwot za wykonanie jest mylące. Porównuj koszt w horyzoncie kilku lat, bo niższa cena wdrożenia bywa odrabiana w abonamencie.

Przy aplikacjach mobilnych dochodzą jeszcze wymagania sklepów. Apple i Google regularnie aktualizują zasady publikacji i wymagania dotyczące wersji systemów, więc aplikacja, która nie jest rozwijana, po pewnym czasie może wymagać aktualizacji tylko po to, żeby pozostać w sklepie. Zapytaj, jak wykonawca to uwzględnia.

Testy, odbiór i to, co dzieje się po wdrożeniu

Wycena powinna mówić, jak projekt zostanie przetestowany i jak wygląda jego odbiór. "Testy" jako jedno słowo w zakresie nie mówią nic. Zapytaj, co jest sprawdzane: czy ścieżki takie jak rejestracja, płatność i wysyłka formularza są przeklikiwane ręcznie, na jakich szerokościach ekranu i przeglądarkach sprawdzany jest projekt, czy mierzona jest wydajność i czy ktoś sprawdza, co widzi użytkownik, gdy coś pójdzie nie tak.

Odbiór to moment, od którego zwykle liczy się ostatnia płatność, przejście praw i okres gwarancji, więc powinien mieć opisaną procedurę. Ile masz dni na sprawdzenie projektu, w jakiej formie zgłaszasz błędy, co się dzieje, jeśli błędów jest dużo, i kiedy odbiór uznaje się za dokonany, jeśli nie zgłosisz uwag. Brak tych zapisów oznacza, że moment odbioru ustali się w praktyce, czasem wbrew Twojej intencji.

Po odbiorze zapytaj o trzy rzeczy. Po pierwsze, jak długo wykonawca bezpłatnie usuwa błędy, które wyjdą po starcie, i jak szybko reaguje. Po drugie, czy projekt jest monitorowany, czyli czy ktoś wie, że strona przestała działać, zanim napisze o tym klient. Po trzecie, ile kosztuje dalsza opieka i rozwój po zakończeniu okresu gwarancyjnego i czy te warunki są zapisane, czy dopiero będą ustalane.

Dobrym testem jest konkretne pytanie: "co się stanie, jeśli za dwa miesiące po starcie przestanie działać formularz kontaktowy". Odpowiedź pokaże, czy wykonawca ma na to procedurę, czy dopiero będzie się zastanawiać.

Czerwone flagi w wycenie

Poniższe sygnały nie oznaczają automatycznie nieuczciwego wykonawcy. Część z nich wynika z pośpiechu albo braku doświadczenia w pisaniu ofert. Każdy jest jednak powodem do zadania pytania, zanim podpiszesz umowę, a nie po fakcie.

Zwróć też uwagę na to, jak wykonawca reaguje na pytania z tej tabeli. Odpowiedź z konkretem, nawet jeśli brzmi "tego nie robimy", jest dobrym sygnałem, bo pokazuje, że firma zna swój zakres. Odpowiedź ogólna albo zmiana tematu na rabat to sygnał, że podobnie będą wyglądały rozmowy w trakcie projektu, gdy stawką będzie termin, a nie podpis pod umową.

Ostatni wiersz jest ważny w obie strony. Niska cena nie musi oznaczać złej jakości. Może wynikać z tego, że wykonawca proponuje gotowe rozwiązanie tam, gdzie inni wycenili budowę od zera, albo z tego, że dobrze zna podobne projekty. Jedynym sposobem, żeby to odróżnić, jest zapytanie, skąd bierze się różnica, i sprawdzenie odpowiedzi w tabeli zakresu z pierwszej sekcji.

Odwrotna sytuacja też się zdarza: oferta wyraźnie droższa od pozostałych nie musi oznaczać zawyżonej ceny. Czasem jest jedyną, która uwzględnia migrację danych, testy albo okres poprawek, a pozostałe po prostu o nich milczą. Tabela zakresu działa w obu kierunkach i pokazuje, czy wyższa kwota kupuje coś konkretnego.

Pytania do zadania przed podpisaniem umowy

Poniższą listę możesz skopiować i wysłać każdemu wykonawcy, z którym rozmawiasz. Odpowiedzi na piśmie są przy okazji dobrym materiałem do porównania ofert, bo pokazują, jak dana firma komunikuje się jeszcze przed rozpoczęciem pracy.

1. Które elementy zakresu są w cenie, a które są z niej wprost wyłączone?
2. Czy cena jest stała, czy zależy od przepracowanych godzin, a jeśli od godzin, jaki jest maksymalny budżet?
3. Czy kwota jest podana netto, czy brutto?
4. Do jakich etapów przypięte są płatności i co musi być gotowe przed każdą z nich?
5. Od jakiego zdarzenia liczy się termin realizacji i co się dzieje, gdy materiały z mojej strony przyjdą później?
6. Co jest poprawką, a co zmianą zakresu, i jak wygląda procedura wyceny zmian?
7. Czy mam dostęp do repozytorium i wersji testowej w trakcie projektu?
8. Czy autorskie prawa majątkowe do kodu przechodzą na mnie, na jakich polach eksploatacji i w którym momencie?
9. Czy dostanę dokumentację, która pozwoli przejąć projekt innemu zespołowi?
10. Na kogo zarejestrowane będą domena, serwer i konta w usługach zewnętrznych?
11. Jakie koszty cykliczne będę ponosić po starcie i kto odpowiada za aktualizacje?
12. Jak długo po starcie bezpłatnie usuwacie błędy i czy projekt jest monitorowany?
13. Czy mogę rozmawiać bezpośrednio z osobą, która będzie pisać kod?

Nasze odpowiedzi na część tych pytań są stałe dla każdego projektu VulCode. Przy ogólnym zarysie projektu podajemy widełki, a konkretną kwotę po ustaleniu zakresu, terminu i wymagań. Rozliczenie dzielimy najczęściej na trzy równe części 33/33/33, w cenie jest zapas na poprawki równy 15% czasu projektu, a do repozytorium i stagingu masz dostęp w trakcie prac. Po zakończeniu dostajesz pełne prawa do kodu i dokumentację do przejęcia, a projekt jest monitorowany bezpłatnie, najczęściej przez 90 dni. NDA podpisujemy na życzenie, raporty postępu wysyłamy bez proszenia, a rozmawiasz z osobą, która pisze kod.

Nie publikujemy pakietów, tylko ceny "od" dla poszczególnych rodzajów projektów, na przykład Strona Firmowa od 1 199 zł albo Sklepy i E-commerce od 1 699 zł. Pełną listę znajdziesz na stronie z ofertami, a przebieg współpracy etap po etapie na stronie Jak pracujemy. Jeśli masz już wyceny od innych firm i chcesz, żebyśmy spojrzeli na nie z tej listy, napisz przez formularz kontaktowy. Wycena i porady są bezpłatne, odpowiadamy w godzinę, a jeśli uznamy, że któraś z ofert, które masz, lepiej pasuje do Twojego projektu, powiemy to wprost.