Dwie aplikacje mogą mieć po pięć ekranów i wymagać zupełnie innej pracy. Jedna zapisuje zgłoszenie w prostym formularzu. Druga musi sprawdzić dostępność w kilku systemach, rozpoznać uprawnienia użytkownika i wyjaśnić, dlaczego dane nie zgadzają się z wczorajszym raportem. Liczenie ekranów bywa więc równie pomocne jak wycenianie remontu po liczbie drzwi. Coś mówi o budynku, ale niekoniecznie o stanie instalacji.
Rzetelna wycena powinna opisywać, co wykonawca rozumie przez gotowy rezultat. Warto sprawdzić, czy obejmuje projekt, implementację, integracje, testy, wdrożenie i przekazanie systemu. Nie chodzi o to, żeby każda oferta miała identyczne rubryki. Chodzi o możliwość porównania tego samego zakresu. Cena pozbawiona założeń łatwo staje się początkiem kolejnych rozmów o pracach, które jedna strona uważała za oczywiste, a druga za dodatkowe.
Reguły procesu ważą więcej niż liczba pól
Weźmy formularz zamówienia. Sam zapis adresu i listy produktów jest stosunkowo łatwy do opisania. Zakres zmienia się, gdy klient ma własne ceny, różne oddziały dostawy, limit kupiecki i konieczność akceptacji przez przełożonego. Dochodzą warunki, które trzeba zaprojektować oraz sprawdzić. Dlatego przed pytaniem o koszt warto przejść przez opis prawdziwego zadania, łącznie z sytuacjami, w których zwykła ścieżka przestaje wystarczać.
Podobnie działają role użytkowników. Dwie nazwy stanowisk nie zawsze oznaczają dwa poziomy dostępu. Ta sama osoba może pracować dla kilku spółek, zastępować kolegę albo mieć prawo do korekty tylko wybranych dokumentów. Jeżeli te zasady mają wpływ na codzienną pracę, powinny znaleźć się w zakresie. Przy oprogramowaniu na zamówienie model uprawnień jest częścią produktu, a nie technicznym dopiskiem do ekranu logowania.
Integracja ma również drogę powrotną po błędzie
Połączenie z innym programem nie kończy się na wysłaniu poprawnego zapytania. Trzeba uzgodnić, co dzieje się przy niedostępności usługi, powtórzeniu komunikatu i zmianie danych po obu stronach. Jeśli dostawca udostępnia dokumentację, środowisko testowe i stabilne identyfikatory, łatwiej oszacować pracę. Gdy dostęp do tych informacji dopiero trzeba zdobyć, wycena powinna pokazywać tę niewiadomą. Pewna mina wykonawcy nie zastępuje testu połączenia.
W praktyce warto wydzielić krótkie rozpoznanie integracji przed zamknięciem całego kosztorysu. Można sprawdzić dostęp, pobrać próbkę danych i ustalić ograniczenia. W tekście o źródle prawdy w integracji systemów pokazujemy, dlaczego ważny jest również właściciel każdej informacji. Samo API, czyli interfejs wymiany danych, nie rozstrzyga jeszcze, który system powinien wygrywać przy sprzecznych wartościach.
Prace po publikacji też potrzebują zakresu
Aplikacja zaczyna prawdziwe życie wtedy, gdy korzystają z niej ludzie. Kto obserwuje błędy? Kto odtwarza kopię danych? Jak pilna poprawka trafia na produkcję i kto ją odbiera? Utrzymanie nie powinno być tajemniczą pozycją miesięczną. Warto opisać konkretne obowiązki, godziny dostępności i sposób zgłoszenia problemu. Bez tego ta sama kwota może oznaczać bardzo różne wsparcie, od monitorowania systemu po samą gotowość do rozmowy.
Osobną pozycją są koszty usług zewnętrznych: hostingu, poczty, płatności czy narzędzi używanych przez aplikację. Zamiast zgadywać ich przyszłą wysokość, poproś o założenia obciążenia oraz wskazanie właściciela kont. Dobrze znać sposób naliczania opłat i możliwość kontroli zużycia. Przy integracjach systemów i danych te ustalenia pomagają uniknąć sytuacji, w której tania funkcja uruchamia kosztowny, niewidoczny na początku przepływ.
Porównuj warianty decyzji, nie samą końcową kwotę
W ofercie poszukaj również opisu odbioru aplikacji i przekazania systemu po zakończeniu prac. Zrozumiałe warunki zmniejszają ryzyko płacenia za ten sam problem drugi raz. Jeśli cena obejmuje wyłącznie stworzenie kodu, firma musi osobno zaplanować jego uruchomienie, testy oraz obsługę. Taki model może być właściwy, ale powinien wynikać ze świadomego podziału odpowiedzialności, a nie z przeoczenia przy podpisywaniu zamówienia.
Jeżeli budżet nie obejmuje całego pomysłu, warto zapytać, który fragment można uruchomić najpierw. Sensowne MVP aplikacji zmniejsza zakres, zachowując użyteczną ścieżkę pracy. Nie jest to automatycznie tańsza jakość tego samego produktu. Wykonawca powinien wyjaśnić, co zyskujecie, co odkładacie i jakie zależności pozostają. Dzięki temu ograniczenie budżetu prowadzi do świadomego wyboru, a nie do przypadkowego obcięcia testów pod koniec.
Na rozmowę o wycenie z Archifutura przygotuj proces, przykładowe dane i listę obecnych narzędzi. Jeśli czegoś nie wiesz, zaznacz to wprost. Możemy wtedy oddzielić pracę możliwą do oszacowania od rozpoznania, które trzeba wykonać najpierw. Dobra oferta nie obiecuje, że żadna zmiana nigdy się nie pojawi. Pokazuje natomiast, za jaki rezultat płacisz i jak będziecie podejmować decyzje, gdy pojawi się nowa informacja.
