Jak porównać oferty wykonania aplikacji, gdy każda opisuje inny zakres

Trzy oferty, różny zakres

Dostajesz trzy oferty wykonania aplikacji. Jedna obiecuje portal klienta, druga panel z integracją, trzecia warsztat i późniejszą wycenę. Kwoty wyglądają jak liczby, które można od razu porównać. Trudniej porównać to, co się za nimi kryje. Zanim wybierzesz wykonawcę, sprowadź propozycje do wspólnych pytań o rezultat, zakres, założenia i dalsze utrzymanie.

Nie chodzi o to, aby wszyscy oferenci zaproponowali identyczne rozwiązanie. Różne podejścia mogą ujawnić lepszy sposób osiągnięcia celu. Powinno być jednak jasne, co użytkownik będzie mógł zrobić po zakończeniu pracy, co pozostaje poza propozycją i jakie informacje mogą zmienić plan. Bez tego najniższa cena może oznaczać po prostu najwęższy zakres.

Brytyjski Digital, Data and Technology Playbook zaleca ocenę propozycji z uwzględnieniem jakości, kosztów oraz rezultatów. Materiał dotyczy zamówień publicznych w Wielkiej Brytanii; tutaj traktujemy go jako inspirację do uporządkowania prywatnego wyboru wykonawcy, nie jako instrukcję polskiego postępowania przetargowego.

Dobrze jest także określić, kto oceni poszczególne części propozycji. Osoba znająca proces wychwyci brakujący krok, specjalista od systemów zwróci uwagę na dostęp do danych, a osoba odpowiedzialna za budżet porówna warunki finansowe. W niewielkiej firmie jedna osoba może pełnić kilka ról, ale nadal warto przejść przez każde z tych pytań osobno.

Zacznij od wspólnego zadania

Wybierz jeden przebieg istotny dla firmy: od przyjęcia zgłoszenia do przekazania go osobie odpowiedzialnej, od zamówienia do potwierdzenia ceny albo od zebrania danych do przygotowania raportu. Opisz, kto wykonuje każdy krok i czego potrzebuje. Jeśli wykonawcy dostali różne wersje tego opisu, przekaż im ujednolicony materiał i poproś o wskazanie różnic w ofertach.

W przykładowym, fikcyjnym projekcie firma chce pokazać klientom status zgłoszenia. Oferta A obejmuje zalogowanie i podgląd statusu, oferta B dodaje możliwość odpowiedzi na zgłoszenie, a oferta C zakłada jedynie przygotowanie projektu ekranów. Każda może odpowiadać innej potrzebie. Nie można jednak wybrać na podstawie ceny, zanim wiadomo, który rezultat jest konieczny.

Nie pomijaj punktu końcowego zadania. Jeśli klient prześle odpowiedź, kto ją przeczyta i jak dowie się o niej właściwy pracownik? Gdy proces dotyczy firmy usługowej, podobny przepływ opisujemy w artykule o obsłudze zleceń od zgłoszenia do rozliczenia. Porównanie ofert zacznij od tego, czy dana propozycja obejmuje cały wybrany przebieg.

Wspólny opis może zawierać przykładowe dane wejściowe oraz oczekiwany wynik, bez ujawniania danych klientów. Dla zgłoszenia może to być fikcyjny numer sprawy, rodzaj problemu i status, który ma zobaczyć uprawniona osoba. Dla raportu wskaż pytanie, na które ma odpowiadać, oraz źródło informacji. Taki materiał pozwala porównać podejście wykonawców na tym samym przykładzie.

Zapisz także potrzeby mniej widoczne w prezentacji. Osoba przeglądająca zgłoszenia może potrzebować wyszukania starszej sprawy, a kierownik informacji o zadaniach bez przypisanego właściciela. Zapytaj, czy te czynności mieszczą się w propozycji, czy wymagają kolejnego etapu. Jeśli nie są potrzebne na początku, zaznacz to świadomie zamiast zakładać, że zostały uwzględnione.

Zakres i rzeczy pozostawione poza ofertą

Poproś wykonawców, aby wskazali wprost, co obejmuje propozycja, a czego nie obejmuje. Osobno zapisz projektowanie, programowanie, testy, wdrożenie, przygotowanie dokumentacji i szkolenie osób korzystających z aplikacji. Jeżeli element został nazwany ogólnie, dopytaj o rezultat. „Testy” mogą oznaczać sprawdzenie kilku widoków albo wspólny odbiór uzgodnionych scenariuszy.

Przy każdym zadaniu zaznacz stan odpowiedzi: potwierdzone w ofercie, wyłączone albo wymagające wyjaśnienia. Trzecia kategoria jest ważna. Brak informacji nie jest dowodem ani na uwzględnienie, ani na wyłączenie pracy. Wyślij te same pytania do wykonawców i zachowaj odpowiedzi razem z propozycjami.

Zwróć uwagę na uprawnienia, bezpieczeństwo, dostępność oraz sposób obsługi błędów. Liczba ekranów nie opisuje, kto może zobaczyć dane i co dzieje się przy niedostępności usługi. W projekcie integracji warto osobno ustalić, który system odpowiada za dane i jak będą rozpoznawane rozbieżności.

Ustal również, które obowiązki spoczywają na Twoim zespole. Dostarczenie opisów procesu, przygotowanie przykładowych danych lub udział w odbiorze wymagają czasu. Jeśli jedna oferta zakłada samodzielne przygotowanie integracji przez firmę, a druga przewiduje tę pracę po stronie wykonawcy, porównaj te założenia przed wyborem.

Przy projektowaniu interfejsu dopytaj, czy oferta obejmuje rozmowy z użytkownikami, makiety, test prototypu oraz liczbę uzgodnionych rund uwag. Nie chodzi o porównywanie samych liczb rund, lecz o zrozumienie, kiedy możesz zobaczyć projekt i jak zgłosisz zastrzeżenia. Ustal również, kto podejmie ostateczną decyzję po stronie firmy, gdy opinie uczestników będą się różnić.

Warto sprawdzić też sposób przygotowania danych początkowych. Czy aplikacja startuje z pustą bazą, czy przewidziano import istniejących rekordów? Czy ktoś oceni jakość danych i wskaże przypadki wymagające poprawy? Przy migracji cena importu bez opisu źródeł, mapowania i sprawdzenia wyniku niewiele mówi o rzeczywistej pracy. Poproś wykonawcę o nazwanie założeń i zależności.

Integracja i niewiadome

Nazwa systemu zewnętrznego nie wystarcza do potwierdzenia integracji. Zapytaj, jakie informacje mają być pobierane lub zapisywane, skąd pochodzi opis interfejsu i czy dostęp został już sprawdzony. Ustal, co stanie się, jeśli potrzebna operacja nie jest dostępna albo wymaga dodatkowej usługi dostawcy.

Przydatne jest rozróżnienie między potwierdzonym faktem a założeniem. „Posiadamy dokumentację API” nie oznacza jeszcze, że konkretne konto pozwala wykonać każdą potrzebną operację. Warto poprosić o osobny etap sprawdzenia, jeżeli odpowiedź może istotnie zmienić zakres. Sposób wymiany informacji opisujemy w artykule o API i webhookach w automatyzacji.

Zapytaj również o obsługę niepowodzeń. Kto zauważy, że aktualizacja nie dotarła? Czy pracownik może sprawdzić status sprawy i bezpiecznie wznowić działanie? Odpowiedź na te pytania wpływa na codzienną pracę, choć nie zawsze mieści się w haśle „integracja w cenie”.

Jeżeli integracja ma przekazywać status, dopytaj, czy aktualizacja następuje automatycznie i z jaką częstotliwością. Jeśli wymiana ma przebiegać przez plik, ustal kto go przygotuje i co stanie się po zmianie formatu. Nie każdy proces potrzebuje połączenia działającego bez przerwy. Potrzebuje natomiast jasnej odpowiedzi, jak szybko informacja musi dotrzeć i kto reaguje na brak aktualizacji.

W porównaniu uwzględnij koszty usług zewnętrznych, jeśli są znane, oraz sposób ich ustalania, gdy nie można ich jeszcze policzyć. Zapytaj, na kogo będą założone konta, kto otrzyma dostęp do rozliczeń i czy można zmienić dostawcę. Jeśli propozycja zakłada narzędzie wymagające osobnej umowy, poproś o wskazanie tej zależności. Nie musisz zgadywać ceny, żeby zauważyć, że koszt istnieje.

Odbiór, termin i utrzymanie

Porównaj warunki odbioru. Poproś o listę zadań, które będzie można wykonać przed akceptacją, oraz zasady zgłaszania błędów. Sprawdź, kto przygotuje dane do testów i kto po stronie firmy potwierdzi wynik. W tekście o kryteriach odbioru aplikacji pokazujemy, jak opisać sprawdzalne scenariusze. Jeśli propozycje różnią się także sposobem rozliczenia, sprawdź, jak zestawić stałą cenę i rozliczenie za czas w odniesieniu do konkretnego zakresu.

Termin ma sens dopiero wraz z założeniami. Jedna propozycja może liczyć czas od podpisania umowy, inna od dostarczenia materiałów i dostępów. Zapytaj o zależności, dostępność osób decyzyjnych oraz sposób postępowania, gdy zewnętrzny dostawca nie odpowie w planowanym czasie. Nie porównuj samych dat bez sprawdzenia punktu startu i zakresu.

Sprawdź, co dzieje się po uruchomieniu. Kto odpowiada za aktualizacje, kopie, zgłoszenia błędów oraz dostęp do kont? Czy późniejsze utrzymanie jest częścią propozycji czy osobnym zakresem? Porównaj koszty i obowiązki w okresie, który ma znaczenie dla Twojej decyzji, bez dopisywania kwot, których oferty nie podają.

Poproś też o opis przekazania kodu, dokumentacji i kont. Nie zakładaj, że samo przekazanie plików wystarczy do dalszego utrzymania systemu. O tym, jakie pytania warto zadać przy przejmowaniu aplikacji, piszemy w osobnym materiale.

Przy odbiorze poproś o przykład scenariusza, który obejmuje również odmowę lub błąd. Dla rejestracji zgłoszenia może to być brak wymaganego pola, dla panelu klienta próba dostępu do cudzej sprawy. Ważne, aby oczekiwany rezultat był opisany tak, by osoba znająca proces potrafiła go potwierdzić. Uzgodnijcie sposób zapisywania uwag i termin ponownego sprawdzenia po poprawkach.

W temacie utrzymania dopytaj o kanał zgłaszania problemu, godziny dostępności oraz sposób ustalenia pilności. Jeżeli propozycja zawiera czasy reakcji, upewnij się, co oznacza reakcja i od kiedy liczy się czas. Potwierdzenie przyjęcia zgłoszenia oraz usunięcie przyczyny są różnymi działaniami. Warunki powinny wskazywać, za które z nich odpowiada wykonawca.

Jak zadawać pytania, żeby dostać porównywalne odpowiedzi

Przygotuj krótką tabelę z wierszami dotyczącymi potrzebnego rezultatu, zakresu, wyłączeń, integracji, odbioru i utrzymania. W kolumnach umieść odpowiedzi wykonawców oraz miejsce na źródło informacji: numer strony oferty albo datę odpowiedzi. Nie musisz sprowadzać wszystkiego do jednego wyniku punktowego. Tabela ma pokazać różnice, które wpływają na wybór.

Zadawaj pytania o konkretną sytuację: „Co zobaczy pracownik, gdy system magazynowy nie odpowie?” zamiast „Czy rozwiązanie jest niezawodne?”. Pytaj również o granice odpowiedzi: czy dostawca opiera się na sprawdzonej dokumentacji, rozmowie z właścicielem systemu czy własnym założeniu? Wtedy wiesz, które kwestie wymagają osobnej weryfikacji.

Jeśli odpowiedź zmienia zakres, poproś o zaktualizowaną propozycję albo pisemne doprecyzowanie. Zachowaj informację, która wersja jest aktualna. To ważne szczególnie wtedy, gdy kilka osób prowadzi rozmowy i każda dysponuje inną wersją dokumentu. Decyzja powinna opierać się na tych samych ustaleniach, które później trafią do umowy i planu prac.

Jeśli dopiero przygotowujesz wymagania, pomocny będzie tekst o tym, jak zamówić aplikację dla firmy. Możesz również zapoznać się z ofertą oprogramowania na zamówienie i skontaktować się z Archifutura. W briefie opisz wybrany proces, oczekiwany rezultat, systemy i kwestie, które chcesz porównać. Nie musisz z góry rozstrzygać każdego szczegółu technicznego.

Przed końcowym wyborem omów rozbieżności z osobami, które będą korzystać z aplikacji i ją utrzymywać. Ich pytania mogą ujawnić koszt pracy przeniesiony na zespół albo brak funkcji potrzebnej do zakończenia zadania. Jeżeli istotna odpowiedź nadal zależy od sprawdzenia integracji, zapisz tę niepewność przy decyzji. Nie zamieniaj jej na pewnik tylko dlatego, że tabela wyglądałaby wtedy schludniej.

Po podjęciu decyzji zachowaj porównanie razem z aktualną ofertą i odpowiedziami wykonawcy. Gdy rozpocznie się projekt, łatwiej będzie sprawdzić, z jakich założeń wynikł wybrany zakres. Jeśli później pojawi się nowa potrzeba, można ją omówić w odniesieniu do tych ustaleń i świadomie zdecydować o kolejnym etapie.