Dwie oferty na ten sam sklep potrafią różnić się o kilkadziesiąt procent i obie mogą być logiczne. Zwykle nie chodzi o to, że jeden wykonawca jest „drogi”, a drugi „tani”. Po prostu każdy policzył inny rezultat.
Jedna oferta kończy się na napisaniu kodu. Druga obejmuje analizę, UX, migrację, testy, uruchomienie i stabilizację. Dopóki nie rozdzielisz tych elementów, porównujesz sumy, a nie projekty.
Dlaczego ofert nie da się porównać samą kwotą?
Stawka godzinowa i liczba godzin nie pokazują ryzyka. Przed porównaniem budżetów sprowadź zakresy do wspólnego mianownika: ten sam katalog funkcji, integracji, środowisk, odpowiedzialności i kryteriów odbioru.
Ja przy wycenie chcę wiedzieć nie tylko, co ma działać, ale również skąd przychodzą dane, kto podejmuje decyzję i jak rozpoznamy poprawny rezultat. „Integracja z ERP” może oznaczać prosty eksport zamówień albo dwukierunkową synchronizację stanów, cen, klientów, faktur i błędów. Jedno hasło, zupełnie inny budżet.
11 punktów listy kontrolnej budżetu
- Uruchomienie produkcyjne. Czy cena obejmuje plan cut-over, synchronizację danych, przekierowania, konfigurację domeny i monitoring startu?
- Poprawki po UAT. Czy usunięcie błędów znalezionych w odbiorach mieści się w cenie, czy jest rozliczane osobno?
- Analiza i kryteria akceptacji. Kto opisuje procesy, user stories, wyjątki i definicję ukończenia?
- Moduły i rozszerzenia. Czy wycena obejmuje wybór, zakup, konfigurację, dostosowanie i test kompatybilności?
- Licencje i abonamenty. Jakie koszty wrócą co miesiąc lub co rok?
- Zarządzanie i QA. Czy w budżecie są planowanie, przeglądy, testy i raportowanie ryzyka?
- Integracje. Czy cena obejmuje oba końce integracji, mapowanie danych, obsługę błędów i ponawianie komunikatów?
- UX/UI. Czy dostajesz gotowy motyw, adaptację, czy indywidualny system komponentów?
- Warsztaty i spotkania. Ile czasu przewidziano na decyzje, demo i odbiory?
- Hosting i środowiska. Czy są osobne środowiska developerskie, testowe i produkcyjne, backup oraz monitoring?
- Szkolenie i dokumentacja. Kto przygotowuje zespół klienta do obsługi sklepu i integracji?
Jeżeli pozycja nie jest ujęta w ofercie, poproś o jednoznaczne oznaczenie: „poza zakresem”, „po stronie klienta” albo „wyceniane po analizie”. Cisza w dokumencie nie oznacza, że koszt zniknie.
Jak porównać oferty bez arkusza na sto kolumn?
Nie potrzebujesz rozbudowanego modelu zakupowego. Wystarczy tabela z obszarami projektu i trzema pytaniami: czy element jest w cenie, kto za niego odpowiada i jaki jest rezultat odbioru. Dla każdej niejasnej pozycji poproś o krótkie doprecyzowanie.
- Zakres: co dokładnie zostanie dostarczone?
- Założenie: jakie dane, decyzje albo usługi dostarcza klient?
- Wyłączenie: czego oferta świadomie nie obejmuje?
- Odbiór: po czym poznamy, że element działa poprawnie?
- Koszt stały: czy po uruchomieniu wróci abonament lub licencja?
Zwróć uwagę na pozycje opisane jako „standardowe”. Standardowy checkout, migracja czy integracja mogą znaczyć coś innego dla każdej firmy. Jeśli dane hasło ma wpływ na sprzedaż, warto dopisać dwa zdania zamiast zakładać, że wszyscy rozumieją je tak samo.
Rola analizy przedwdrożeniowej
Analiza nie powinna kończyć się ogólną prezentacją. Jej wynikiem ma być lista procesów, integracji, danych, ról, scenariuszy błędów i decyzji architektonicznych. Dopiero taki materiał pozwala zbudować wycenę fixed price albo sensowny limit w modelu Time & Materials.
W bardziej złożonym Magento 2 wolę rozdzielić discovery od implementacji. Po analizie możesz świadomie zmniejszyć zakres startowy, etapować integracje lub zmienić priorytety. To lepsze niż udawanie pewności na początku, a potem finansowanie kolejnych niespodzianek.
Dobre discovery nie polega na dokumentowaniu wszystkiego. Ma zmniejszyć największe ryzyka: niejasne procesy cenowe, jakość danych, ograniczenia systemów zewnętrznych i decyzje, które wpływają na architekturę. Reszta może trafić do uporządkowanego backlogu.
Jakie koszty i zadania zostają po stronie klienta?
Budżet wykonawcy nie obejmuje automatycznie czasu Twojego zespołu. Ktoś musi przygotować dane, zatwierdzić projekt, przetestować procesy i ustalić zasady działania integracji. Jeśli decyzje stoją przez tydzień, harmonogram też stoi — nawet gdy programiści są gotowi.
Po stronie klienta często zostają również treści, zdjęcia, regulaminy, umowy z operatorami płatności, konfiguracja ERP i dostępność osób odpowiedzialnych za księgowość czy logistykę. Warto wpisać te zadania do planu, przypisać właściciela i datę. To koszt organizacyjny, którego nie widać na fakturze za development.
Rezerwa i koszt po starcie
W budżecie pozostaw rezerwę na jakość danych, ograniczenia zewnętrznych API i decyzje odkryte podczas testów. Wielkość rezerwy zależy od poziomu niepewności. Dobrze opisany projekt z przetestowanymi integracjami potrzebuje jej mniej niż migracja z systemu, którego nikt od lat nie rozwija.
Osobno policz pierwszy rok działania: hosting, licencje, monitoring, poprawki bezpieczeństwa, aktualizacje oraz dalszy rozwój. Dodaj także okres stabilizacji po starcie. Wtedy wychodzą problemy, których nie dało się w pełni odtworzyć na środowisku testowym, na przykład nietypowe dane albo szczytowy ruch.
Pełna lista kontrolna nie zagwarantuje braku zmian. Da Ci jednak wspólny język do rozmowy o odpowiedzialności i pozwoli porównywać naprawdę podobne oferty. To dużo ważniejsze niż pozorna precyzja jednej liczby na pierwszej stronie PDF-a.
