Zanim zamówisz aplikację lub system: pytania, na które warto znać odpowiedź

Dlaczego rozmowa, a nie gotowa specyfikacja

Długa specyfikacja pisana samodzielnie, zanim ktokolwiek zobaczył jeden działający ekran, zwykle zamraża decyzje, które łatwiej byłoby zmienić na początku rozmowy niż poprawiać w trakcie budowy. Krótka, ustrukturyzowana rozmowa pozwala wychwycić nieporozumienia (np. że „panel klienta” znaczy dla Ciebie coś innego niż dla wykonawcy), zanim staną się kosztowną poprawką na późniejszym etapie projektu.

Cel i użytkownicy

1. Jaki problem rozwiązuje aplikacja? Jedno zdanie, np. „Klienci dzwonią, żeby zapytać o status zamówienia, i zajmuje to dwie godziny dziennie”. To zdanie będzie potem miarą, czy projekt się udał.
2. Kto będzie z niej korzystał? Klienci, pracownicy w biurze, pracownicy w terenie? Na telefonie czy komputerze? Z dobrym internetem czy bez?
3. Jak to działa dzisiaj? Arkusz, papier, telefon, inny program. Obecny sposób pracy pokazuje, co jest naprawdę potrzebne.

Zakres pierwszej wersji

1. Bez czego aplikacja nie ma sensu? Wypisz wszystkie pomysły, a potem zaznacz te, bez których nie da się jej uruchomić. Reszta trafia do kolejnych etapów.
2. Kto będzie zarządzał treścią i danymi? Jeśli ktoś w firmie ma dodawać produkty, zmieniać ceny albo odpowiadać na zgłoszenia, potrzebny jest panel. To on bywa największą częścią pracy.

Pierwsza wersja, która robi jedną rzecz dobrze i trafia do użytkowników po kilku tygodniach, daje więcej informacji niż pełny system po roku. Dlatego wyceniamy i realizujemy projekty etapami.

Dane i integracje

1. Skąd pochodzą dane? Program księgowy, sklep internetowy, system magazynowy, pliki od dostawcy, urządzenia. Czy te systemy mają API, czy tylko eksport do pliku?
2. Jakie dane osobowe będą przetwarzane? Od tego zależą wymagania RODO: umowa powierzenia, miejsce przechowywania danych, uprawnienia i dziennik zmian.
3. Czy potrzebne są płatności, logowanie, powiadomienia? Każda z tych rzeczy to osobny element z własnymi kosztami i formalnościami.

Po uruchomieniu

1. Kto będzie utrzymywał aplikację? Serwer, aktualizacje bezpieczeństwa, kopie zapasowe, nowe wersje systemów w telefonach. Aplikacja bez opieki po roku zaczyna sprawiać problemy.
2. Gdzie ma działać? Na serwerze wykonawcy, w chmurze, na serwerze w firmie? Kto płaci za hosting i na czyje konto jest zarejestrowany?

Formalności, o które warto zapytać od razu

• Prawa autorskie do kodu. Przeniesienie autorskich praw majątkowych wymaga formy pisemnej i wymienienia pól eksploatacji. Jeśli umowa tego nie zawiera, prawa zostają przy wykonawcy, a Ty masz tylko licencję.
• Kod źródłowy i dokumentacja. Ustal, że kod jest w repozytorium, do którego masz dostęp, i że dostajesz instrukcję uruchomienia.
• Konta na firmę. Domena, konta deweloperskie Google Play i App Store, hosting, konta usług zewnętrznych: wszystko zarejestrowane na Twoją firmę. Wykonawca dostaje dostęp, nie własność.

Budżet i termin

Nie musisz znać kwoty, ale warto znać rząd wielkości i to, czy termin wynika z czegoś konkretnego (sezon, targi, koniec dofinansowania). Bez tej informacji wykonawca może zaproponować rozwiązanie za duże albo za małe. Poprawianie zakresu projektu w połowie realizacji kosztuje więcej czasu, niż zajęłoby ustalenie tych dwóch rzeczy na starcie. Z tą informacją da się dobrać zakres pierwszego etapu tak, żeby zmieścił się w obu ograniczeniach, zamiast odkrywać niezgodność tuż przed planowanym terminem.

Co przejmujemy

Po pierwszej rozmowie dostajesz krótkie podsumowanie tego, co zrozumieliśmy, propozycję technologii, podział na etapy z wyceną każdego z nich i harmonogram. Jeśli coś da się zrobić prościej albo taniej gotowym narzędziem, też to napiszemy. Dalej budujemy i utrzymujemy całość w ramach systemów i integracji: systemy webowe na zamówienie, panele administracyjne z rolami i historią zmian, REST API z dokumentacją oraz integracje z innymi systemami, które dziś obsługuje ktoś ręcznie. Zadzwoń pod 697 004 905 albo napisz na kontakt@apkarze.pl. Przygotuj odpowiedzi na pytania wyżej, a resztę ustalimy na rozmowie.