// aplikacja mobilna kupowana w przetargu

Specyfikacja techniczna aplikacji mobilnej do przetargu: co zwykle pomijają

Specyfikacja techniczna aplikacji mobilnej do przetargu najczęściej opisuje system z kontem użytkownika, powiadomieniami, czasem płatnością i mapą — na iOS i Android jednocześnie. Zamawiającym jest urząd lub firma, która ma już stronę albo back-office, a aplikacja mobilna ma być dodatkowym kanałem dla klientów lub pracowników.

Taka specyfikacja wygląda na kompletną: wymienione są ekrany, funkcje, platformy. Ale aplikacja mobilna to nie samodzielny program, tylko klient działający na warstwie serwerowej, publikowany przez cudze sklepy z aplikacjami i żyjący dłużej niż jedno wydanie. Jeśli specyfikacja nie opisuje tych warstw, wykonawca fizycznie nie może wycenić projektu dokładnie — a różnica wychodzi albo w kosztorysie, albo przy odbiorze.

Sprawdzamy, które punkty typowej specyfikacji technicznej aplikacji mobilnej najczęściej zostają niedopowiedziane i co z tym zrobić na etapie zakupu.

Co zwykle pomija się w specyfikacji

Nie wskazano, na czyje konto dewelopera w App Store i Google Play publikowana jest aplikacja i kto ją publikuje

Czym to grozi. Bez jasności, na jaki podmiot zarejestrowane jest konto, po odbiorze pojawia się spór: wykonawca publikuje pod swoim kontem — i zamawiający jest od niego zależny przy każdej aktualizacji, albo publikacja się opóźnia, bo konto zamawiającego nie zostało założone i zweryfikowane przed startem prac.

Jak napisać to dobrze. W specyfikacji zapisuje się, że konta w App Store Connect i Google Play Console zakłada się na podmiot zamawiającego przed rozpoczęciem prac, a wykonawca otrzymuje dostęp jako członek zespołu z prawem publikacji.

Nie określono minimalnych wspieranych wersji iOS i Android

Czym to grozi. Bez podanego zakresu wersji wykonawca albo zakłada wsparcie przestarzałych systemów „na wszelki wypadek”, co podnosi koszt prac, albo celuje w najnowsze wersje — i część użytkowników ze starszymi telefonami nie zainstaluje aplikacji.

Jak napisać to dobrze. Specyfikacja ustala minimalną wersję iOS i Android oraz listę typów urządzeń (telefon, tablet), na których interfejs musi wyświetlać się poprawnie.

Brak wymagań dotyczących warstwy serwerowej i API

Czym to grozi. Aplikacja opisana jest tak, jakby istniała sama z siebie: ekrany, funkcje, ale skąd biorą się dane i jak są przechowywane — nie powiedziano. W efekcie wykonawca albo zakłada budowę backendu od zera, albo na starcie okazuje się, że API trzeba integrować z istniejącym systemem zamawiającego, co zmienia zakres i terminy kontraktu.

Jak napisać to dobrze. W specyfikacji osobny rozdział opisuje, czy istnieje gotowe API czy backend trzeba zbudować, jakie dane i w jakim formacie są przesyłane, kto odpowiada za serwer po uruchomieniu — wykonawca aplikacji mobilnej czy inny zespół.

Brak scenariuszy odbioru na realnych urządzeniach

Czym to grozi. Bez listy modeli i scenariuszy testowych odbiór zamienia się w dowolną kontrolę: zamawiający znajduje błąd na swoim telefonie, którego nie było w zestawie testowym wykonawcy, i odmawia podpisania protokołu, choć funkcje formalnie działają.

Jak napisać to dobrze. Specyfikacja zawiera listę modeli urządzeń i wersji systemów do testowania oraz scenariusze odbioru — co dokładnie jest sprawdzane: rejestracja, powiadomienia, płatność, działanie przy słabym internecie i offline.

Nie uzgodniono wsparcia po publikacji i aktualizacji pod nowe wersje systemów

Czym to grozi. Po zakończeniu projektu Apple i Google okresowo zmieniają wymagania wobec aplikacji, a nowe wersje iOS i Android czasem psują działanie starego kodu. Jeśli wsparcie nie jest zapisane osobno, zamawiający zostaje z aplikacją, która po kilku aktualizacjach systemów przestaje się uruchamiać, a wykonawca nie jest już zobowiązany tego naprawiać.

Jak napisać to dobrze. W specyfikacji lub umowie osobno wskazuje się okres wsparcia technicznego po publikacji, czy obejmuje on adaptację pod nowe wersje iOS i Android, oraz jak rozliczane są dalsze prace poza okresem gwarancyjnym.

Płatność i mapa w aplikacji opisane jednym zdaniem bez szczegółów

Czym to grozi. Sformułowanie „integracja płatności” albo „mapa z geolokalizacją” nic nie mówi o tym, jaki dostawca płatności jest potrzebny, jaka mapa — Google Maps, Yandex Maps czy lokalny serwis, i jakie dane mają wyświetlać. Wykonawca zakłada wariant minimalny, a zamawiający przy odbiorze oczekuje więcej — stąd dodatkowe prace, których specyfikacja nie przewidywała.

Jak napisać to dobrze. Specyfikacja wskazuje konkretnego dostawcę płatności, konkretny serwis map i listę danych, które mają być widoczne na mapie, zamiast ogólnego opisu funkcji.

Co daje dobra specyfikacja

Dobra specyfikacja techniczna aplikacji mobilnej opisuje nie tylko ekrany, ale też warstwę serwerową, publikację i życie aplikacji po pierwszym wydaniu.

Zamawiającemu daje to porównywalne oferty od wykonawców i jasne kryteria odbioru zamiast sporu na ostatnim etapie.

Wykonawcy — dokładną wycenę zakresu prac i ochronę przed dodatkowymi pracami, które w rzeczywistości nie były częścią specyfikacji.

Projekt, który zamawiający może sam utrzymywać i aktualizować, zamiast być bezterminowo zależnym od jednego wykonawcy.

Cena i czas realizacji

Specyfikacja techniczna: od $400, 1-4 tygodnie; cena zależy od złożoności systemu, architektury, stosu technologicznego i integracji. Realizacja w podwykonawstwie: wycena według zakresu kontraktu, przed złożeniem oferty.

Specyfikacja do przetargu lub podwykonawstwo: szczegóły →

Nie podajemy zamawiających ani przetargów: analizujemy typową specyfikację, a nie czyjeś zamówienie.

Przygotowujesz zamówienie albo już wygrałeś przetarg?

Omów przetarg