Jak zamówić aplikację dla firmy — krok po kroku

Zamówienie aplikacji dla firmy wygląda groźnie tylko z daleka — zwłaszcza jeśli to Twój pierwszy projekt IT. Z bliska to sześć kroków, z których żaden nie wymaga znajomości programowania: opisujesz problem, rozmawiamy, ustalamy zakres pierwszej wersji i wycenę, budujemy etapami, startujemy, a potem system spokojnie rośnie razem z firmą. Przejdźmy przez tę ścieżkę razem, krok po kroku. Przy każdym zaznaczymy, czego masz prawo oczekiwać od dobrej firmy — a na końcu zbierzemy czerwone flagi, które powinny Cię skłonić do odwrotu, u nas czy u kogokolwiek innego.

Krok 1. Opisz problem, nie rozwiązanie

Wszystko zaczyna się od jednego maila. I tu pierwsza rada, która oszczędzi Ci czasu: opisz problem, a nie wymarzony system. Zamiast „potrzebuję aplikacji z modułem CRM i panelem administracyjnym" napisz „gubimy zlecenia, bo krążą między mailami a trzema arkuszami, a klienci dzwonią z pytaniem, co z ich zamówieniem". Ten drugi opis mówi wykonawcy dużo więcej — i pozwala mu zaproponować rozwiązanie, o którym mogłeś nie wiedzieć.

Wystarczy mniej więcej strona: co boli, kto będzie korzystał, jak proces przebiega dziś, z jakimi programami system ma się łączyć i co jest najpilniejsze. Technologii nie ruszaj — to nasza działka i nasza odpowiedzialność.

Dobry zwyczaj przed wysłaniem: pokaż ten opis dwóm osobom, które w procesie siedzą na co dzień. Handlowiec i magazynier dopiszą po zdaniu, a te zdania bywają ważniejsze niż cała reszta. Właściciel widzi proces z lotu ptaka; oni widzą wyboje.

Czego oczekiwać na tym etapie? Że firma przyjmie opis napisany po ludzku i odpowie pytaniami, nie gotową ceną. Wycena „na sztywno" wysłana dzień po dwuzdaniowym mailu to nie sprawność, tylko strzelanie — a płacić za pudło będziesz Ty.

Krok 2. Rozmowa, po której obie strony wiedzą więcej

Kolejny etap to zwykle godzina rozmowy wideo. My dopytujemy o proces i wyjątki: co się dzieje, gdy klient zmienia zamówienie, kto zatwierdza rabaty, skąd się biorą dane. Ty masz pełne prawo przepytać nas: ile podobnych systemów zbudowaliśmy, kto konkretnie będzie pracował, jak wygląda kontakt w trakcie projektu. Jeśli chcesz wiedzieć, z kim rozmawiasz, zajrzyj na stronę o naszej firmie — w skrócie: w web developmencie pracujemy od ponad 20 lat, w pełni zdalnie, dla klientów z całej Polski i z zagranicy.

Nie przejmuj się, jeśli nie znasz odpowiedzi na wszystkie nasze pytania. Szczere „nie wiem" w niczym nie przeszkadza — gorsze jest „wydaje mi się", bo potrafi poprowadzić projekt w złą stronę. To, czego nie wiesz, po prostu wspólnie sprawdzimy.

Dobra rozmowa kończy się notatką z ustaleniami, którą obie strony widzą na piśmie. I jeszcze jedno, po czym poznasz partnera do współpracy: mówi Ci też to, czego nie chcesz słyszeć. Że dana funkcja jest zbędna na start. Że gotowe narzędzie załatwi połowę tematu taniej. Nam też zdarza się odradzić cały projekt — wolimy stracić zlecenie niż budować coś, w co sami nie wierzymy. Entuzjazm bez jednego „ale" to nie zaangażowanie, tylko sprzedaż.

Krok 3. Zakres pierwszej wersji i wycena

Teraz dzieje się rzecz, która przesądza o powodzeniu projektu: cięcie zakresu. Z całej wizji wybieramy rdzeń — pierwszą wersję (MVP), która obsłuży najważniejszy proces i pozwoli firmie realnie pracować. Reszta pomysłów nie znika; trafia na listę i czeka na swoją kolej. Taki układ oznacza, że efekty zobaczysz w tygodnie, a nie w kwartały, i że pieniądze wydajesz na funkcje sprawdzone potrzebą, nie przeczuciem.

Uprzedzamy: cięcie zakresu trochę boli. Każda funkcja wydaje się niezbędna, dopóki nie padnie pytanie „czy bez tego firma może pracować przez pierwszy miesiąc?". To pytanie działa jak sito — i to ono odróżnia projekty, które startują, od tych, które utykają na etapie planów. Wszystko, co odłożyliśmy, można dodać w drugim miesiącu. O ile pierwszy w ogóle nastąpi.

Wycena u nas stoi na jawnych stawkach: 125 zł netto za godzinę pracy zespołu, miesięczne pakiety od 40 do 240 godzin — od 5000 do 30000 zł netto. Przy aktywnej budowie sensownym minimum jest pakiet 80 godzin, czyli 10000 zł netto miesięcznie. Sam koszt podstawy zależy od zakresu: liczby ról użytkowników, integracji, migracji danych — dlatego zamiast sztywnego cennika dostaniesz od nas widełki godzin z rozpiską, co w nich siedzi. Szczegóły tego, jak liczymy, znajdziesz na stronie wyceny projektu.

Zanim podpiszesz cokolwiek, sprawdź trzy rzeczy w umowie: co dokładnie obejmuje zakres, do kogo należy kod po zakończeniu prac i gdzie stoi serwer. Zdrowy układ wygląda tak, że domena, serwer i kod są na Twoich kontach albo masz do nich zagwarantowany dostęp — wykonawca pracuje na Twojej własności, a nie trzyma jej w zastawie.

Krok 4. Budowa etapami — co kilka tygodni coś widzisz

Od tego miejsca projekt nabiera rytmu. My programujemy, a Ty w regularnych odstępach dostajesz dostęp do wersji testowej: klikasz, sprawdzasz, zgłaszasz uwagi. Nie musisz rozumieć kodu — wystarczy, że wiesz, jak działa Twoja firma. Uwaga „magazynier nie będzie tego wypełniał, ma brudne rękawice i dwie minuty" jest dla projektu cenniejsza niż niejeden przegląd techniczny.

Twoja rola sprowadza się do dwóch rzeczy: testować na bieżąco i podejmować decyzje bez wielotygodniowej zwłoki. Z doświadczenia — tempo projektu częściej zależy od tempa decyzji po stronie klienta niż od tempa pisania kodu. Wyznacz jedną osobę, która trzyma temat, a wszystko pójdzie sprawniej.

Sam kontakt układamy prosto: wspólny kanał do bieżących spraw, podsumowanie po każdym etapie i jedna lista zadań, do której obie strony zaglądają. Żadnych raportów dla samych raportów — szkoda Twoich pieniędzy i naszych godzin.

Nowe pomysły będą przychodzić w trakcie, to naturalne. Zapisujemy je na listę i wyceniamy osobno, zamiast wpychać do bieżącego etapu — dzięki temu pierwsza wersja dojeżdża do mety, zamiast puchnąć w nieskończoność. A jeśli wykonawca na kilka tygodni zapada się pod ziemię i „wszystko pokaże na końcu" — to nie jest styl pracy, to loteria.

Krok 5. Start — mniejszy stres, niż myślisz

Start systemu obrósł legendą wielkiego skoku na głęboką wodę. W praktyce, przy pracy etapami, bywa niemal niezauważalny: aplikację znasz od tygodni, bo ją testowałeś. Zostają rzeczy porządkowe — przeniesienie danych z dotychczasowych arkuszy (robimy to importem, nikt nie przepisuje ręcznie), założenie kont pracownikom i krótkie szkolenie. Podkreślmy: krótkie. Dobra aplikacja firmowa nie wymaga kursu, bo odwzorowuje proces, który zespół już zna.

Dobrą praktyką jest start w spokojniejszym okresie, nie w szczycie sezonu, oraz wyznaczenie jednej osoby, która zbiera uwagi całego zespołu — zamiast dziesięciu maili z tym samym spostrzeżeniem. Przez pierwsze tygodnie firma może też pracować podwójnie ostrożnie: arkusz zostaje jako zabezpieczenie, dopóki wszyscy nie zaufają nowemu narzędziu. W tym okresie wychodzą drobiazgi i to normalne; różnica między dobrą a złą firmą polega na tym, że dobra jest wtedy pod telefonem, a zła właśnie wystawiła fakturę końcową i zmieniła numer.

Krok 6. Rozwój albo spokojne utrzymanie

Po udanym starcie masz wybór. Jeśli pomysłów przybywa — a zwykle przybywa, bo rodzi je codzienna praca na systemie — kontynuujemy rozwój w pakietach godzin: co miesiąc kolejne funkcje z listy, w kolejności, którą ustalasz Ty. Jeśli system robi swoje i niczego więcej nie trzeba, schodzimy do trybu utrzymaniowego: mały pakiet na aktualizacje, kopie zapasowe, monitoring i drobne poprawki. W praktyce oznacza to zwykle najmniejszy pakiet, 40 godzin miesięcznie za 5000 zł netto, a gdy przychodzi czas na kolejny etap rozwoju — po prostu wracamy do większego. Bez martwych abonamentów za nic.

Najlepsze aplikacje firmowe, jakie zbudowaliśmy, rosły właśnie tak: latami, kawałek po kawałku, w rytmie potrzeb. System, który dziś obsługuje zamówienia, za dwa lata potrafi prowadzić także reklamacje, serwis i rozliczenia z podwykonawcami — bo fundament od początku był kładziony pod rozbudowę.

Czerwone flagi, przy których zawróć

Na koniec obiecana lista ostrzegawcza. Zawróć, gdy:

• dostajesz konkretną cenę bez jednego pytania o Twój proces;
• wykonawca chce 100% płatności z góry, przed pokazaniem czegokolwiek;
• kod, serwer i domena mają być wyłącznie na kontach wykonawcy, „bo tak wygodniej";
• w trakcie budowy zapada wielotygodniowa cisza, a postęp „zobaczysz na końcu";
• na każdą Twoją prośbę pada entuzjastyczne „wszystko się da", bez słowa o kosztach i konsekwencjach;
• nikt nie chce rozmawiać o tym, co będzie z systemem po starcie.

Żadna z tych rzeczy nie musi oznaczać katastrofy. Ale każda przenosi ryzyko z wykonawcy na Ciebie — a powinno być dokładnie odwrotnie.

Cała ścieżka zaczyna się od jednego maila, więc jeśli masz problem, który dojrzał do rozwiązania — opisz nam go zwykłymi słowami. Wrócimy z pytaniami i konkretami. Zapraszam do kontaktu, chętnie odpowiem też na pytania, których ten przewodnik nie przewidział.