„Potrzebuję strony, na której klienci będą się logować, rezerwować sprzęt i widzieć swoje rozliczenia”. To zupełnie wystarczający początek rozmowy. Nie trzeba wiedzieć, czy taki projekt nazwać portalem, systemem czy aplikacją webową. Warto za to wyjaśnić, co użytkownik ma na nim zrobić i co dzieje się po jego kliknięciu.
Podobnie wyglądające ekrany mogą skrywać bardzo różny zakres pracy. Zobaczmy to na przykładzie wypożyczalni, od prostej oferty po narzędzie do codziennej obsługi rezerwacji.
Prosta strona pomaga znaleźć informację i nawiązać kontakt
Strona wypożyczalni pokazuje sprzęt, zasady wynajmu, godziny otwarcia i dane kontaktowe. Klient ogląda ofertę i wysyła zapytanie. Dostępność konkretnego urządzenia sprawdza pracownik, który uzgadnia termin poza stroną.
To nadal pełnoprawny projekt: potrzebuje dobrych treści, czytelnego układu, sprawnego formularza i wygodnej obsługi na telefonie. Może mieć panel do edycji oferty. Określenie „prosta” opisuje ograniczony zakres działania, a nie niską jakość wykonania czy brak potrzeby testów.
Aplikacja webowa wykonuje część procesu
Teraz klient wybiera termin, system sprawdza dostępność sprzętu i zapisuje rezerwację. Pracownik widzi ją w swoim panelu, zmienia status, odnotowuje wydanie i zwrot. Klient po zalogowaniu przegląda własne rezerwacje. Aplikacja przechowuje stan procesu i udostępnia różne działania różnym osobom.
W obu przypadkach korzystasz z przeglądarki. Różnica polega na tym, ile pracy przejmuje oprogramowanie i za jakie decyzje odpowiada. Strona może też zawierać aplikację, a aplikacja mieć publiczną część z ofertą. Nie istnieje jedna liczba podstron, od której projekt staje się webappką.
Jeden przycisk może oznaczać wiele reguł
Na ekranie widnieje „Zarezerwuj”. Żeby ten przycisk działał prawidłowo, trzeba wcześniej odpowiedzieć na kilka pytań:
- Co się stanie, gdy dwie osoby jednocześnie wybiorą ostatnią dostępną sztukę?
- Czy niedokończona rezerwacja blokuje termin, a jeśli tak, to na jak długo?
- Kto może anulować rezerwację i kiedy sprzęt wraca do puli dostępnych?
- Jak obsłużyć opóźniony zwrot, awarię urządzenia lub zmianę terminu?
- Co zobaczy klient, gdy zapis się powiedzie, ale potwierdzenie e-mail nie dotrze?
Każda odpowiedź wpływa na dane, logikę działania, ekran i testy. Dlatego pięć ekranów aplikacji może wymagać więcej pracy niż kilkanaście podstron informacyjnych. Sama liczba widoków jest słabą podstawą porównania ofert.
Skąd bierze się różnica w czasie realizacji
Przy stronie informacyjnej dużą część pracy zajmują materiały, projekt, wdrożenie i dopracowanie szczegółów. Przy rozbudowanej aplikacji dochodzi ustalanie reguł procesu, struktury danych, uprawnień i zachowania integracji. Trzeba też sprawdzić scenariusze, których nie widać w udanej demonstracji.
Na harmonogram wpływa dostępność osób podejmujących decyzje. Jeśli nikt nie potrafi ustalić zasad anulowania rezerwacji, dodatkowe programowanie nie rozwiąże tej niejasności. Podobnie dokumentacja zewnętrznego systemu, dane do przeniesienia i możliwość przeprowadzenia odbioru mogą decydować o tempie pracy.
To nie oznacza, że każda aplikacja powstaje dłużej od każdej strony. Rozbudowany serwis z wieloma wersjami językowymi i migracją treści może być większym przedsięwzięciem niż małe narzędzie wewnętrzne. Liczy się rzeczywisty zakres.
Za co płacisz poza tym, co widać na ekranie
Cena obejmuje czas potrzebny do uzgodnienia, wykonania i sprawdzenia rozwiązania. W aplikacji znaczną częścią tej pracy są zależności między funkcjami. Zmiana sposobu liczenia rezerwacji może dotknąć kalendarza, panelu pracownika, powiadomień i raportów.
Osobno warto porównać koszty dalszej obsługi: hosting, usługi zewnętrzne, aktualizacje, kopie danych, reagowanie na awarie i rozwój. Nie każdy projekt potrzebuje takiego samego poziomu obsługi. Narzędzie używane sporadycznie przez jedną osobę ma inne wymagania niż system, na którym przez cały dzień pracuje firma.
Sama nazwa „aplikacja” nie uzasadnia wyższej wyceny. Poproś o rozpisanie zakresu, założeń i sposobu odbioru. Wtedy można porównać, czy dwie oferty rzeczywiście dotyczą tego samego produktu. Niższa cena nie musi oznaczać gorszej jakości; czasem wynika z gotowego rozwiązania, mniejszego zakresu lub sprawniejszego procesu.
Więcej działania oznacza więcej skutków błędu
Błędny tekst na stronie można poprawić, choć do tego czasu może wprowadzać klientów w błąd. Błąd aplikacji może dodatkowo zapisać nieprawidłowe dane, zablokować pracę albo pokazać komuś cudzą rezerwację. Zakres weryfikacji powinien wynikać z takich możliwych skutków.
Przy odbiorze sprawdza się więc nie tylko poprawny przebieg, lecz również błędne dane, odmowę dostępu i awarie połączeń. Istotne jest ustalenie, jak wykrywa się problem, kto na niego reaguje i jak przywraca się działanie. Kopia danych jest przydatna wtedy, gdy wiadomo również, jak ją odtworzyć.
Podział obowiązków trzeba nazwać w ustaleniach: kto zarządza kontami, utrzymuje integracje, aktualizuje system i zatwierdza zmiany reguł biznesowych. Zlecenie wykonania aplikacji nie oznacza automatycznie całodobowej opieki. Z drugiej strony klient nie powinien dopiero przy awarii odkrywać, że nikt nie zajmuje się utrzymaniem.
Nie zawsze warto od razu budować własną aplikację
Wypożyczalni może wystarczyć strona z formularzem albo połączenie z gotowym systemem rezerwacji. Jeżeli narzędzie dobrze pasuje do sposobu pracy, własna aplikacja nie musi przynieść proporcjonalnej korzyści. Warto ją rozważyć, gdy ograniczenia gotowych rozwiązań rzeczywiście przeszkadzają, a firma potrafi wskazać, co chce robić inaczej.
Można też zacząć od jednego procesu. Najpierw obsłużyć rezerwacje, a raporty i dodatkowe role odłożyć do czasu, aż użytkownicy sprawdzą pierwszą wersję. Ograniczenie zakresu nie powinno jednak usuwać podstaw potrzebnych do poprawnego działania wybranej funkcji. Jeśli klient rezerwuje sprzęt, system musi prawidłowo rozstrzygać jego dostępność już na tym etapie.
Nie musisz umieć nazwać swojego projektu
Wystarczy opowiedzieć: „Teraz robimy to tak, tutaj tracimy czas, a chcielibyśmy, żeby wyglądało to inaczej”. Możesz pokazać arkusz, szkic na kartce albo przejść przez zwykły dzień pracy. To często mówi więcej niż techniczna lista funkcji.
Na początek przydadzą się trzy rzeczy: kto ma korzystać z rozwiązania, co chce załatwić i co dzisiaj mu to utrudnia. Podczas rozmowy można ustalić, czy wystarczy strona, gotowe narzędzie, integracja czy własna aplikacja — oraz które elementy są potrzebne na start.
Jeśli masz taki pomysł, opisz go własnymi słowami. Nie potrzebujesz specyfikacji ani właściwego branżowego określenia. Najpierw porozmawiajmy o tym, co ma działać.