Ile naprawdę kosztuje aplikacja na zamówienie: uczciwe, przejrzyste zestawienie

Niech Państwo zapytają trzy agencje, ile kosztuje aplikacja na zamówienie, a otrzymają trzy liczby, które nie mają ze sobą nawet jednej wspólnej cyfry. Jedna powie cztery tysiące, druga czterdzieści, a trzecia po cichu stwierdzi, że to zależy, i umówi kolejne spotkanie. Żadna z nich nie kłamie, ściśle rzecz biorąc — ale żadna nie mówi Państwu tego, co naprawdę trzeba wiedzieć: dokąd idą pieniądze i dlaczego właśnie ta aplikacja kosztuje tyle, ile kosztuje. Otwórzmy więc maskę.

Napisałem więcej wycen aplikacji, niż jestem w stanie zliczyć — dla firm od jednoosobowego zakładu rzemieślniczego po regionalną sieć. Najczęstszą reakcją na cenę nie jest szok z powodu sumy, lecz dezorientacja co do rozrzutu. Jak ten sam trzywyrazowy brief ("aplikacja do rezerwacji") może dać wyceny różniące się dziesięciokrotnie? Uczciwa odpowiedź brzmi: "aplikacja do rezerwacji" to nie brief. To życzenie. Cena tkwi w stu drobnych decyzjach ukrytych pod spodem.

Ten tekst to zestawienie, które chciałbym, aby każdy właściciel firmy miał przed pierwszą rozmową z programistą. Bez wypełniaczy, bez straszenia, bez naciągania. Po prostu realne składniki kosztów, rzeczy, które po cichu podwajają budżet, i kilka uczciwych sposobów, by wydać mniej, nie kończąc z czymś, czego się Państwo będą żałować.

Dlaczego dwie wyceny "tej samej aplikacji" różnią się 10-krotnie

Oprogramowanie to nie produkt, który zdejmuje się z półki — to praca mierzona w godzinach wykwalifikowanych ludzi. Cena aplikacji na zamówienie to więc w istocie po prostu zakres × stawka godzinowa × ryzyko. Wszystko inne to przypis do tych trzech rzeczy. Gdy dwie wyceny mocno się rozjeżdżają, jedna z tych trzech liczb jest czytana zupełnie inaczej — i zwykle nikt nie powiedział tego wprost.

Zakres to oczywista sprawa. "Aplikacja do rezerwacji" może oznaczać pojedynczy ekran, na którym klienci wybierają termin — albo kalendarze pracowników, płatności, przypomnienia, logowanie klienta, panel administracyjny, zwroty i raport, który właściciel czyta w poniedziałek. Te same trzy słowa, dziesięciokrotnie więcej pracy. Tania wycena często zakłada małą wersję; droga po cichu przyjmuje dużą. Żadna nie zapytała, którą Państwo mieli na myśli.

Jest jeszcze ryzyko, część, której nikt nie lubi wyceniać. Niejasny brief, klient, który nie zdecydował, czego chce, integracja z chwiejnym, przestarzałym systemem — to nie tylko dodaje godzin, ale i niepewności. Doświadczone zespoły zakładają margines na niepewność, bo już się na niej sparzyły. Tańsza wycena często w ogóle nie wyceniła ryzyka — i dlatego właśnie czasem puchnie w połowie drogi.

Dokąd naprawdę idą pieniądze

Gdy ludzie wyobrażają sobie tworzenie aplikacji, widzą programowanie. Programowanie jest realne, ale rzadko stanowi choćby połowę rachunku. Aplikacja na zamówienie jest bliższa budowie małego domu niż napisaniu dokumentu — wokół widocznej części są projekt, instalacje, odbiory i papierkowa robota. Oto jak rozkłada się typowy budżet, gdy uwzględnić wszystko.

Dwie rzeczy w tej tabeli zwykle zaskakują. Po pierwsze, jak duża część budżetu dzieje się zanim zostanie napisana jedna linia kodu funkcji — analiza i projekt to nie luksus, to najtańsze miejsce na naprawienie błędu. Zmiana ekranu w szkicu kosztuje minuty; zmiana po jego zbudowaniu kosztuje dni. Po drugie, jak realna jest pozycja na testy. Pominięcie ich nie oszczędza pieniędzy — jedynie przenosi koszt na tydzień startu, z odsetkami.

Analiza i projekt: część, którą każdy chce pominąć

Analiza to moment, w którym zamieniają Państwo "aplikację do rezerwacji" w precyzyjną listę ekranów i reguł. Wydaje się narzutem, bo nic jeszcze nie powstaje. Ale każda godzina tutaj oszczędza kilka dalej, bo właśnie tu eliminuje się niejednoznaczność, póki jest tania. Zespół, który wycenia bez fazy analizy, albo zgaduje, albo planuje policzyć ją Państwu później pod inną nazwą.

Rdzeń aplikacji: widoczny silnik

To kod, który sprawia, że Państwa pomysł działa — ekrany, które ludzie dotykają, logika za nimi i baza danych po cichu pamiętająca wszystko. To największa pojedyncza część i skaluje się niemal wprost z zakresem. Każda dodana funkcja to więcej do zbudowania, więcej do przetestowania i więcej do utrzymania na zawsze. To pozycja, na której "a fajnie byłoby, gdyby" szybko robi się drogie.

Integracje: zwodniczo kosztowny kawałek

Połączenie aplikacji z innymi systemami — przyjęcie płatności kartą, wysłanie przypomnienia SMS, synchronizacja kalendarza, pobranie danych z programu księgowego, którego już Państwo używają — wygląda drobno na liście funkcji, a na fakturze waży zaskakująco dużo. Każde połączenie to mały projekt sam w sobie, z własnymi dziwactwami i sposobami awarii. Jedna grzeczna integracja płatności jest w porządku. Pięć splątanych integracji z leciwym systemem wewnętrznym to miejsce, gdzie budżety umierają.

Koszty, których nikt nie wpisuje do wyceny

Tu wielu właścicieli czeka przykra niespodzianka po dwunastu miesiącach. Budowa to jednorazowa liczba; aplikacja nie jest rzeczą jednorazową. Oprogramowanie żyje — telefony się aktualizują, przepisy się zmieniają, firma rośnie — a coś żywego trzeba karmić. Wycena, którą Państwo podpisują, to cena narodzin, nie cena posiadania.

Nic z tego nie jest oszustwem ani ukrytą pułapką — to po prostu część, która nie mieści się zgrabnie na jednostronicowej wycenie, więc słabsi partnerzy ją pomijają, by wyglądać taniej. Dobry mówi o tym z góry, choć przez to jego pierwsza liczba wygląda na większą. Niech Państwo zapytają wprost: ile będzie mnie kosztować roczne utrzymanie po starcie? Jakość odpowiedzi wiele mówi o tym, z kim mają Państwo do czynienia.

Co po cichu podwaja cenę

Niektóre rzeczy dodają koszt proporcjonalnie do wartości, jaką wnoszą — i słusznie. Inne dodają koszt zupełnie nieproporcjonalnie, zwykle z powodu tego, jak zorganizowana jest praca, a nie tego, co aplikacja robi. To dźwignie warte zrozumienia, bo kilka z nich leży całkowicie w Państwa rękach.

• Dwie platformy zamiast jednej. Natywna aplikacja na iPhone'a i natywna na Androida to z grubsza dwie budowy. Narzędzia wieloplatformowe lub aplikacja webowa potrafią sprowadzić to z powrotem do jednej. Ten jeden wybór potrafi przesunąć sumę bardziej niż jakakolwiek funkcja.
• Projekt na zamówienie zamiast sensownych standardów. Dopracowany co do piksela, w pełni indywidualny interfejs kosztuje realne pieniądze w projektowaniu i budowie. Czysty, konwencjonalny, oparty na sprawdzonych wzorcach jest szybszy, tańszy i często łatwiejszy w obsłudze dla klientów.
• Zmiana zdania po rozpoczęciu budowy. Decyzje są tanie na tablicy i drogie w kodzie. Najczęstsze przekroczenie budżetu to nie złe szacowanie — to zakres, który wciąż rósł, bo nic nie zostało przygwożdżone.
• Działanie w czasie rzeczywistym, offline lub ciężkie dane. "Ma działać bez zasięgu" albo "aktualizacje muszą pojawiać się natychmiast u wszystkich" to rozsądne prośby, które po cichu zwielokrotniają inżynierię pod spodem.
• Integracja z czymś starym i nieudokumentowanym. Połączenie z nowoczesnym, dobrze zbudowanym systemem to rutyna. Połączenie z piętnastoletnim narzędziem wewnętrznym bez dokumentacji to archeologia — i rozlicza się ją według godzin.

Realny przykład: wycena 60 tys. €, która stała się aplikacją za 14 tys. €

Kilka szczegółów zmieniono ze względu na prywatność, ale kształt tej historii jest prawdziwy i całkowicie typowy. Regionalna firma usługowa — wyobraźmy sobie kilkunastu pracowników w terenie i zapracowane biuro — przyszła do nas sfrustrowana. Chcieli aplikacji na zamówienie, by ich klienci mogli zamawiać usługi, śledzić postęp i płacić. Mieli już gdzie indziej wycenę na około 60 000 € plus solidną opłatę miesięczną, i to zniechęciło ich do całego pomysłu na niemal rok.

Gdy faktycznie zmapowaliśmy, czego potrzebują — a nie co im wyceniono — obraz wyglądał zupełnie inaczej. Pierwsza wycena zakładała dwie w pełni natywne aplikacje, projekt na zamówienie od zera, system dyspozytorski w czasie rzeczywistym i indywidualną platformę administracyjną, mającą zastąpić narzędzia, które już mieli i z których po cichu byli zadowoleni. Technicznie była to całkiem dobra aplikacja. Była też odpowiedzią na pytanie, którego nie zadali.

Co właściwie zrobiliśmy

Pierwsze sesje poświęciliśmy wyłącznie analizie — rozkładając życzenie na "bez tego firma staje" kontra "to byłoby fajne kiedyś". Rzeczy niezbędne okazały się węższe, niż ktokolwiek się spodziewał: czysty sposób, by klient zlecił usługę i śledził jej postęp, automatyczne przypomnienia oraz płatność online. Dyspozytor w czasie rzeczywistym i indywidualne zaplecze okazały się rozwiązaniami problemów, które ich obecne oprogramowanie już obsługiwało dobrze.

1. 1
   Ograniczyliśmy zakres do prawdziwego zadania

   Odrzuciliśmy funkcje rozwiązujące problemy, których nie mieli, i zostawiliśmy zwięzłą listę tego, bez czego firma naprawdę nie może działać.
2. 2
   Wybraliśmy jedną budowę wieloplatformową

   Zamiast dwóch osobnych aplikacji natywnych jedna aplikacja wieloplatformowa objęła zarówno iPhone'a, jak i Androida — z grubsza o połowę mniej rdzenia.
3. 3
   Użyliśmy sprawdzonych wzorców projektowych

   Czysty, konwencjonalny interfejs zamiast indywidualnego. Klientom łatwiej było z niego korzystać, a harmonogram skrócił się o tygodnie.
4. 4
   Połączyliśmy, nie zastąpiliśmy

   Powiązaliśmy aplikację z oprogramowaniem biurowym, za które już płacili, zamiast budować je od nowa. Kosztowna 'indywidualna platforma administracyjna' po prostu zniknęła z zakresu.

W efekcie powstała budowa za około 14 000 €, gotowa w kilka miesięcy, z przewidywalnymi kosztami bieżącymi. Nie jest tak rozbudowana jak wersja za 60 tys. € — i nie musi być. Robi to, czego firma rzeczywiście potrzebowała. Rok później dołożyli dwie drobne funkcje, opłacone z pieniędzy, które oszczędziła im pierwsza wersja. To cały wzorzec: zacznij od prawdziwego zadania, zasłuż na dodatki wynikami.

Jak utrzymać koszt w ryzach bez chodzenia na skróty

Wydanie mniej na aplikację na zamówienie nie polega na zbijaniu stawki godzinowej ani znalezieniu najtańszego zespołu, jaki się da. Tak płaci się dwa razy. Polega na świadomym podejściu do zakresu, kolejności i decyzji — trzech rzeczy, które naprawdę ruszają liczbę. Oto gdzie kryją się realne oszczędności.

Po pierwsze, niech Państwo zbudują najmniejszą wersję, która faktycznie jest użyteczna, a potem ją rozwijają. Skupione pierwsze wydanie, które dobrze robi jedną rzecz, szybciej wprowadza Państwa na rynek, kosztuje ułamek marzenia o aplikacji wszystko-w-jednym i — co kluczowe — uczy, co budować dalej, na podstawie prawdziwych klientów, a nie domysłów. Po drugie, niech Państwo podejmą decyzje, zanim zacznie się budowa; niezdecydowanie to najdroższa rzecz, jaką można wnieść do projektu. Po trzecie, niech Państwo łączą się z tym, co już mają, zamiast wymieniać działające narzędzia, i przebudowują coś dopiero wtedy, gdy naprawdę ich hamuje.

Częste pytania