10 najczęstszych błędów przy zamawianiu aplikacji webowej

Pierwszym błędem jest rozpoczęcie od listy funkcji bez wskazania użytkownika, zadania, przeszkody i oczekiwanego rezultatu. Wykonawca może wtedy wycenić poprawnie opisane ekrany, które nie rozwiązują źródła opóźnienia ani kosztu.

Opisz przypadek w czterech punktach: kto wykonuje zadanie, co chce osiągnąć, co mu przeszkadza i po czym firma rozpozna poprawę. Przykład: pracownik przepisuje zgłoszenia z formularza do CRM, przez co część trafia do obsługi z opóźnieniem; oczekiwanym rezultatem jest przekazanie kompletnego zgłoszenia do właściwego zespołu.

Oddziel problem od proponowanej funkcji. Zapis "potrzebujemy dashboardu" nie określa, jakie decyzje użytkownik ma podejmować ani jakie dane powinien zobaczyć. Zapis "kierownik sprawdza zgłoszenia bez przypisanego opiekuna i przydziela je do zespołu" wskazuje użytkownika, zadanie i efekt, który można uwzględnić w zakresie.

Jeśli potrzeba dotyczy prezentacji firmy i pozyskiwania zapytań, a nie procesu pracy użytkowników, zakres może odpowiadać stronie internetowej dla firmy. Poradnik jak założyć stronę internetową krok po kroku pomaga rozdzielić projekt strony od projektu aplikacji.

Drugim błędem jest próba wdrożenia wszystkich pomysłów w pierwszej wersji, zanim firma sprawdzi główny proces. Pierwsza wersja powinna pozwalać wykonać zasadnicze zadanie oraz obsługiwać błędy i uprawnienia, które mogłyby zatrzymać pracę lub narazić dane.

Oceń każdą funkcję według wartości dla użytkownika, zależności technicznych i skutku jej braku. Tabela pokazuje przykładowy podział zakresu między pierwszą wersję a dalszy etap.

Funkcja należy do pierwszej wersji, gdy jej brak blokuje główne zadanie albo uniemożliwia bezpieczną obsługę procesu. Nie oceniaj priorytetu samą liczbą głosów w zespole; ustal, jakie ryzyko lub koszt pozostaje, jeśli funkcja nie powstanie.

Zalecamy rozdzielić wymagania na trzy grupy: niezbędne do uruchomienia procesu, potrzebne po pierwszych testach z użytkownikami oraz pomysły do późniejszej oceny. Wpisanie funkcji do backlogu nie oznacza, że prace są objęte bieżącą wyceną.

Trzecim błędem jest opisanie wyłącznie prawidłowej ścieżki bez określenia uprawnień, wyjątków i reakcji na błędne dane. Aplikacja powinna jasno wskazywać, co może zrobić administrator, pracownik, przełożony i użytkownik klienta.

Sprawdź, kto może przeglądać, tworzyć, zmieniać, zatwierdzać lub usuwać rekordy. Sama nazwa roli nie określa dostępu do konkretnych danych i czynności. Dla każdej roli warto zapisać zakres widoczności danych, dostępne działania oraz sytuacje wymagające akceptacji innej osoby.

Pytania kontrolne ujawniają pominięte zachowania:

• Co dzieje się, gdy wymagane pole jest puste albo ma błędną wartość?
• Kto może poprawić zgłoszenie po wysłaniu i czy zmiana zostaje w historii?
• Kto może anulować sprawę albo przywrócić ją do obsługi?
• Co widzi użytkownik bez dostępu do danego rekordu?
• Jak aplikacja informuje o niedostępności systemu zewnętrznego?

Testowalne wymaganie brzmi: "Jeśli pole NIP jest puste, aplikacja nie wysyła rekordu do ERP i wskazuje brakujące pole". Zapis "aplikacja ma obsługiwać błędy" nie definiuje zachowania, które można odebrać.

Zapisz również przypadki brzegowe, które zdarzają się w realnej pracy: duplikat zgłoszenia, zmiana opiekuna w trakcie obsługi, cofnięcie zatwierdzenia albo próba edycji rekordu przez dwie osoby. Nie każdy przypadek musi trafić do pierwszej wersji, ale decyzja o jego obsłudze powinna być świadoma.

Czwartym błędem jest zamówienie integracji bez potwierdzenia dostępnych operacji, danych, dostępów i ograniczeń systemu zewnętrznego. Sam zapis "integracja z ERP" nie określa kierunku wymiany danych ani tego, kto zapewnia dokumentację i środowisko testowe.

API to interfejs, przez który systemy wymieniają dane; dostępne funkcje i warunki użycia określa dostawca danego systemu. Dla każdej integracji przygotuj nazwę i wersję systemu, właściciela po stronie firmy, dokumentację API, środowisko testowe oraz listę danych do odczytu i zapisu.

Przed wyceną zbierz informacje potrzebne do oceny zakresu. Tabela wskazuje, kto lub jaki materiał powinien potwierdzić dany obszar.

Ustal, który system jest źródłem prawdy dla każdego pola. Jeśli dane klienta zmieniają się w CRM, a aplikacja przechowuje ich kopię, wymaganie powinno określać kierunek synchronizacji, częstotliwość i sposób rozstrzygania konfliktu.

Gdy dostawca nie potwierdzi API lub środowiska testowego, oferta powinna wskazać to jako założenie i opisać wpływ na zakres. Dostępy techniczne przekazuj bezpiecznym kanałem, a nie w treści briefu. Przed podpisaniem ustal również, kto opłaca dostęp do dokumentacji, konta developerskie lub licencję integracyjną.

Piątym błędem jest wybór oferty wyłącznie według ceny, mimo że propozycje obejmują różne funkcje, integracje lub odpowiedzialność za utrzymanie. Cena pozwala porównać wykonawców dopiero wtedy, gdy opisują ten sam proces i warunki realizacji.

Poproś o wskazanie zakresu, wyłączeń i założeń dla każdej pozycji. W tabeli zestawisz elementy, które powinny mieć jednoznaczny status w każdej ofercie.

Zestawienie ujawnia różnice, zanim firma porówna ceny i terminy. Sprawdź też, kto po zakończeniu projektu otrzyma kod, dokumentację, dane i dostępy oraz czy oferta obejmuje szkolenie osób obsługujących aplikację.

Poproś o wyjaśnienie, co stanie się z wyceną, gdy okaże się, że API ma ograniczenia albo dane źródłowe wymagają dodatkowego oczyszczenia. Oferta oparta na założeniach może być poprawna, jeśli wskazuje warunki ich potwierdzenia i sposób rozliczenia zmiany. Przy zamawianiu firmowego serwisu dodatkowe pytania opisuje poradnik na co uważać, zamawiając stronę internetową.

Szóstym błędem jest odbiór aplikacji na podstawie nieprecyzyjnych określeń, takich jak "działa poprawnie" lub "jest intuicyjna". Kryterium odbioru powinno opisywać warunek początkowy, czynność i wynik możliwy do zaobserwowania.

Zamiast "użytkownik może dodać zgłoszenie" zapisz: "Użytkownik z rolą pracownika tworzy zgłoszenie z wymaganymi polami, aplikacja zapisuje rekord, nadaje mu numer i pokazuje go na liście zgłoszeń tej jednostki". Takie kryterium określa rolę, dane, wynik i miejsce, w którym można sprawdzić rezultat.

Dla integracji określ, jakie dane są wysyłane, jaka odpowiedź oznacza powodzenie i co ma się stać przy braku odpowiedzi. Przykładowy warunek może opisywać, że rekord z poprawnym identyfikatorem trafia do CRM, a odrzucenie przez API zapisuje komunikat błędu dostępny administratorowi.

Przed startem ustal, kto testuje funkcje, na jakim środowisku i danych odbywa się odbiór oraz gdzie zgłasza się usterki. Uzgodnij także termin na sprawdzenie etapu i sposób potwierdzania poprawek.

Rozróżnij usterkę od nowego wymagania. Jeśli funkcja zachowuje się inaczej niż uzgodnione kryterium, wykonawca powinien móc odtworzyć błąd na danych testowych; jeśli firma oczekuje nowej ścieżki lub zmienia proces, strony powinny najpierw ustalić wpływ na zakres i termin.

Siódmym błędem jest zaplanowanie budżetu tylko na wykonanie aplikacji, bez oszacowania kosztów jej działania i zmian po uruchomieniu. Koszt zależy od rozwiązania, więc w planie oddziel prace jednorazowe od cyklicznych opłat i usług.

Sprawdź, które pozycje dotyczą planowanego rozwiązania:

• hosting, środowisko testowe i kopie zapasowe;
• licencje oraz opłaty za systemy zewnętrzne;
• monitoring dostępności i błędów;
• aktualizacje zależności oraz poprawki bezpieczeństwa;
• obsługa awarii i dalszy rozwój funkcji.

Utrzymanie dotyczy działania i bezpieczeństwa istniejącej wersji, a rozwój zmienia zakres lub zachowanie aplikacji. Umowa powinna osobno opisywać sposób zgłaszania i rozliczania tych prac.

Zapytaj, co obejmuje reakcja na awarię: przyjęcie zgłoszenia, diagnozę, naprawę czy także odtworzenie danych. Ustal, kto monitoruje integracje i jak firma dowie się, że synchronizacja przestała działać. Brak takiego ustalenia może sprawić, że aplikacja działa poprawnie, ale po cichu przestaje pobierać dane z systemu zewnętrznego.

Zaplanuj również przekazanie wiedzy osobom, które będą zarządzać kontami, użytkownikami i treścią. Szkolenie, dokumentacja operacyjna i dostęp do repozytorium powinny mieć jasny status w ofercie, nawet gdy firma nie potrzebuje ich w pierwszym etapie.

Ósmym błędem jest brak osoby, która zatwierdza wymagania, priorytety i odbiór w imieniu firmy. Rozproszone uwagi bez jednej decyzji zwiększają ryzyko sprzecznych ustaleń i blokują pracę zespołu.

Klient wyznacza właściciela procesu, który zbiera potrzeby działów, udostępnia dane i zatwierdza priorytety. Wykonawca odpowiada za realizację uzgodnionego zakresu, wskazywanie ryzyk i zgłaszanie zależności technicznych.

Ustal kanał decyzji, osobę zastępującą i czas, w którym zespół klienta odpowie na pytania projektowe. Jeśli ważne decyzje mają akceptować różne działy, wskaż jedną osobę, która zbierze ich stanowiska i przekaże wykonawcy spójne rozstrzygnięcie.

Przy integracji wskaż też osobę kontaktową u dostawcy systemu, która może potwierdzić API i warunki dostępu. Zapisz, kto po stronie firmy zatwierdza próbki danych, treść komunikatów i reguły procesu. Właściciel decyzji nie musi znać technologii, ale powinien znać cel biznesowy i mieć uprawnienie do ustalania priorytetów.

Dziewiątym błędem jest nieustalenie, kto dostarcza dane, nadaje dostępy i zatwierdza zasady ich użycia. Bez wskazanych właścicieli wykonawca może czekać na materiały albo przygotować rozwiązanie na niepełnych założeniach.

Dla każdego systemu i zbioru danych zapisz osobę odpowiedzialną, sposób przekazania, wymagany format i termin dostępności. Ustal, kto tworzy konta techniczne i nadaje im minimalne uprawnienia potrzebne do pracy.

Sprawdź, czy dane testowe są dostępne i czy można ich używać w środowisku testowym. Dane produkcyjne nie powinny automatycznie trafiać do testów; firma powinna określić, kto zatwierdza zakres danych i sposób ich zabezpieczenia. Jeśli system zewnętrzny wymaga zgody administratora lub dostawcy, przypisz to zadanie konkretnej osobie.

Uzgodnij również, kto odpowiada za jakość danych wejściowych. Przykładowo, jeśli aplikacja ma importować listę kontrahentów, brief powinien wskazywać wymagany format, sposób rozpoznawania duplikatów i reakcję na brak obowiązkowego pola. Te ustalenia wpływają na walidację i testy, więc powinny trafić do zakresu przed wyceną.

Dziesiątym błędem jest podpisanie umowy, zanim brief, oferta i załączniki opisują ten sam zakres. Rozbieżne nazwy funkcji lub nieopisane wyłączenia pozostawiają pole do różnych interpretacji.

Przed podpisaniem sprawdź, czy dokumenty określają:

• problem, użytkowników, proces i istotne wyjątki;
• funkcje pierwszej wersji oraz elementy odłożone na później;
• źródła danych, integracje i potwierdzone dostępy;
• testowalne kryteria odbioru dla głównych funkcji;
• etapy, harmonogram, koszty po uruchomieniu i wyłączenia;
• osoby odpowiedzialne za decyzje, dane i akceptację zmian.

Oznacz niepotwierdzone elementy jako założenia i przypisz im właściciela oraz termin decyzji. Porównaj nazwy funkcji w umowie z ofertą i briefem; jeśli ta sama funkcja występuje pod różnymi nazwami, dopisz wspólną definicję.

Ustal także, jak strony obsłużą zmianę zakresu: kto ją zgłasza, kto ocenia wpływ i kto zatwierdza dodatkowe prace. Zapisz, jakie materiały firma otrzyma po zakończeniu projektu, w tym kod, dokumentację, konta i instrukcję wdrożenia.

Jeśli potrzebujesz wykonawcy strony firmowej, oferta stron internetowych dla firm dotyczy właśnie tego zakresu. Projekt aplikacji wymaga osobnego potwierdzenia kompetencji, integracji i zakresu usługi.

• Brief strony internetowej - jak go przygotować, by ułatwić realizację projektu
• Proces projektowania strony internetowej: etapy, decyzje i odbiory
• Jak przygotować stronę internetową, która skutecznie sprzedaje usługi
• Makieta strony internetowej: jak zaprojektować ją krok po kroku