Co wpływa na koszt aplikacji mobilnej?

Co wpływa na koszt aplikacji mobilnej?
img
AutorIlona LeoniewskaStyczeń, 2021

7 czynników, które wpływają na koszt stworzenia aplikacji mobilnej i webowej. Praktyczne wskazówki jak ograniczyć wydatki. Co wpływa na wartość inwestycji w aplikację? W artykule wskazuję najważniejsze elementy, które trzeba uwzględnić przy planowaniu wdrożenia.

Realizacja potrzeb a koszt stworzenia aplikacji mobilnej

Projekt aplikacji zaczynaj od planu, a najlepiej określenia potrzeb biznesowych. Na tym etapie najpewniej wiesz, czego brakuje Twojej organizacji. Na przykład:

  • obsługa klienta to zbyt duży koszt,
  • zamówienia są zbyt wolno obsługiwane,
  • chcesz dać klientom nową jakość obsługi,
  • klienci nie mają jednego miejsca, w którym znajdą promocje i aktualne oferty,
  • usługi są trudno dostępne dla klienta,
  • nieskutecznie docierasz do klientów z komunikacją.

Dla większości firm będą to problemy, które w ostatecznym rozrachunku odbijają się na wyniku finansowym. Dzięki odpowiednio przygotowanej aplikacji poprawa wyników finansowych będzie znacznie wyższa niż koszt stworzenia aplikacji mobilnej lub webowej. Co zrobić, aby aplikacja sprawnie realizowała założony przez Ciebie plan?

Określenie celów aplikacji

Kolejnym etapem określania potrzeb jest precyzyjne wskazanie celów, które będą odpowiedzią na potrzeby biznesowe. Aby koszt aplikacji mobilnej, czy też webowej, zwrócił się w zakładanym czasie, musisz wskazać cele biznesowe, które będą posiadały pewne konkretne cechy charakterystyczne.

Cel powinien być:

  • mierzalny tj. wskazany przy pomocy liczby, jak np. redukcja kosztów w dziale obsługi klienta o 20%, zwiększenie szybkości realizacji zamówień o 30% w określonym czasie,
  • osiągalny — łatwiej jest pracować z projektem, którego efekt jest w zasięgu tj. nie mówimy o wzroście 3000% wartości przychodu w ciągu 6 miesięcy,
  • konkretny — odnoszący się do jasno sprecyzowanego obszaru biznesu np. czas udostępnienia usługi SaaS klientowi biznesowemu, czas obsługi leada od zapytania do wysłania oferty.

Kiedy już określisz potrzeby oraz powiązane z nimi cele biznesowe — łatwo jest określić tzw. Definition of done.

Jest to informacja o tym, czy dany cel został zrealizowany. Definition of done odnosi się do konkretnej wybranej funkcjonalności systemu (np. uruchomienie funkcji chatbota, która odciąży obsługę klienta), a także do osiągnięcia wskazanego wcześniej celu. Mając przygotowane te elementy jesteś w stanie przystąpić do pracy z dostawcą IT nad dokumentacją projektu. Im cele do osiągnięcia będą precyzyjniej opisane, tym łatwiej będzie znaleźć rozwiązania technologiczne, które doprowadzą do ich osiągnięcia.

Jak wybór technologii wpływa na koszt aplikacji mobilnej?

Dobór technologii wpływa znacząco na koszt aplikacji mobilnej i webowej. Szczególne znaczenie ma to w przypadku technologii mobilnych. Tańszym rozwiązaniem będzie wykorzystanie technologii hybrydowej niż realizacja projektu w oparciu o natywne języki (Swift dla iOS i Kotlin dla Androida).

Jeśli wiedza na temat języków programowania i ich możliwości nie jest Twoją mocną stroną, posłuchaj rekomendacji ze strony software house, z którym będziesz pracować przy projekcie. Taką rekomendację zawsze warto skonsultować. Pamiętaj jednak, aby przekazywać pełnię wiedzy, tj. cele i potrzeby biznesowe. 
Dlaczego to takie ważne? Oto przykładowe powody:

  • rozwiązania natywne charakteryzują się większym poziomem bezpieczeństwa (niż np. PWA), stąd, jeśli np. prowadzimy usługi bankowe lub zależy nam ze szczególnego powodu na bezpieczeństwie naszych użytkowników to rekomendacja technologii natywnej jest jak najbardziej na miejscu
  • jeżeli chcesz stworzyć aplikację, która będzie miała funkcjonalności oparte o np. położeniu telefonu (np. obracanie) to efekt najwyższego wykorzystania funkcji telefonu będzie miała miejsce przy rozwiązaniach natywnych
  • jeśli chcesz przetestować pomysł i na samym początku nie inwestować zbyt dużo — tutaj PWA może się okazać dobrym rozwiązaniem

O wyborze technologii mogą przesądzić czynniki, takie jak:

  • zestaw celów i potrzeb biznesowych z pierwszej części artykułu
  • środki na projekt
  • wymogi bezpieczeństwa
  • model biznesowy
  • wykorzystanie funkcji telefonu

Pamiętaj zatem, aby na chłodno przyjmować argumenty typu: „panie, po co wydawać jak tu można PWA zrobić 3 razy taniej?” lub „co pan chcesz maluchem jeździć czy mercedesem?”.

Komunikacja i system zarządzania w kontekście kosztu aplikacji

Masz już wspaniały plan oraz wybraną technologię, która optymalnie pokrywa potrzeby i cele w założonym budżecie. Wydawać by się mogło, że od tego momentu jest już z górki, bo reszta to przecież sprawy techniczne. Wystarczy sprawdzić, wszystkie przyciski działają, a sama aplikacja ładnie wygląda. 

Otóż nie. 

Komunikacja i przyjęty system zarządzania projektem (albo jego braku) mogą zdecydowanie przyczynić się do realizacji nadprogramowych godzin w przykładowo takich sytuacjach:

  • wskazany Product Owner po Twojej stronie jest całkowicie zależny od prezesa i jego humorów, któremu raz się projekt graficzny podoba, a raz nie w związku z czym kilkakrotnie wracamy w trakcie projektu do już zrealizowanych (i teoretycznie zamkniętych) sprintów, aby dokonać zmian (które z kolei mogą implikować kolejne, np. zmiana układu interfejsu)
  • w trakcie developmentu aplikacji okazało się, że w firmie pojawił się nowy system, z którym tworzona aplikacja musi komunikować, aby wymienić pewne dane. Product Owner dowiaduje się o tym za późno. Team pracujący nad aplikacją ma mniej czasu na analizę dokumentacji nowego systemu oraz wdrożenie niezbędnych zmian
  • brakuje wskazanego Product Ownera, w którego miejsce masz do czynienia z kolektywnym zespołem projektowym bez wyraźnego lidera. W takiej sytuacji programiści mogą otrzymywać w skrajnych przypadkach nawet wykluczające się wzajemnie komunikaty. Może częściej dochodzić do powracania do zamkniętych już etapów, wprowadzanie zmian, które z kolei mogą mieć wpływ na kolejne fazy

Wymienione wyżej sytuacje powodują, że koszt stworzenia aplikacji mobilnej może znacznie wzrosnąć. W każdym z tych przypadków będziemy mieć do czynienia ze zwiększonym nakładem roboczogodzin (lub roboczodni) pracy programistów i całego zespołu. 

W dalszej części artykułu opowiem o ważnym aspekcie — systemie rozliczania się z wykonawcą:

  • Time & Material (rozliczanie w oparciu o naliczane godziny)
  • Fixed price (rozliczanie w oparciu o z góry ustaloną kwotę)

Na ten moment warto pamiętać, że bez względu na wybrany model, w przypadku zmian opisanych jako przykładowe — wykonawca będzie naliczał dodatkowe godziny pracy. Podstawą w takiej sytuacji będzie specyfikacja zmieniana w trakcie trwania projektu. Duże znaczenie ma też moment, w którym dokonamy zmiany specyfikacji. Jeżeli będzie stosunkowo wczesny etap, pewnie będzie to mniej kosztogenne niż na samym jego końcu.

Czy liczba widoków ma znaczny wpływ na koszt aplikacji?

Kiedy spisałeś już listę funkcjonalności w aplikacji lub serwisie webowym (wymagania funkcjonalne), warto wykonać pewne ćwiczenie. 

Spróbuj narysować ekrany aplikacji na kartce. Ołówkiem. Na przykład: jesteś dostawcą Internetu. Chcesz uruchomić aplikację mobilną dla abonentów. W aplikacji użytkownik może:

  • zalogować się na swoje konto abonenta
  • przeglądać dane swojego profilu oraz historię swoich rachunków
  • opłacić rachunek
  • zgłosić się z pytaniem (formularz)
  • przejrzeć aktualnie dostępne oferty modyfikacji swojego planu

Pięć punktów, z których powstanie ok. 15-20 ekranów. Przykładowo – schemat ekranu rejestracji użytkownika. Stworzenie każdego ekranu to czas pracy zespołu, a to ma bezpośrednie przełożenie na koszt stworzenia aplikacji.

Wpływ integracji aplikacji na jej koszt

W punkcie z liczbą widoków oraz we wcześniejszym punkcie z potencjalnymi wyzwaniami w obszarze komunikacji wspominałam o potencjalnych integracjach, na przykład z system płatności, system ERP, CRM lub innymi.

Dlaczego integracje mogą mieć znaczący wpływ na koszt stworzenia aplikacji mobilnej lub webowej?

Każdy z potencjalnych systemów ma kilka elementów, na które trzeba zwrócić uwagę:

  • czy system jest to system zewnętrzny, czy utworzony na wewnętrzne potrzeby bez określonego standardu integracji (np. w przypadku systemu płatności Przelewy24),
  • czy do systemu istnieje odpowiednio przygotowana dokumentacja (bądź jest osoba, która zna ten system od strony technicznej i jest w stanie współpracować w zakresie integracji z dostawcą),
  • zakres integracji tj. czy aplikacja ma pobierać ze wskazanego systemu jedną wartość, czy też dokonywać bardziej złożonych operacji z odświeżanymi na bieżąco danymi.

Innymi słowy:

  • im mniejszy zakres integracji,
  • im lepsza jest dokumentacja projektu,
  • im lepiej określone wymagania co do zakresu,

tym mniej nakładu godzin prac programistycznych będzie wymagał ten element. 

Model realizacji projektu a koszt aplikacji

Koszt stworzenia aplikacji zależy także od tego, jaki przyjmiemy model realizacji naszego pomysłu. Cały proces może potoczyć się w dwóch kierunkach (jest pomiędzy wiele odcieni szarości, ale skupmy się na przypadkach skrajnych):

  • Nasza firma, np. sieć stacji paliw, chce udostępnić klientom aplikację, za pomocą której klient będzie mógł zapłacić za paliwo przy dystrybutorze.
  • Nasza firma to startup, który chce przetestować genialny pomysł.
  • Sprawdzamy, czy rzeczywiście zostanie tak pozytywnie odebrany przez rynek, jak tego oczekujemy.

W pierwszej sytuacji aplikacja powinna być zrealizowana od początku do końca, tj. jej najważniejsza funkcja — płatność przy dystrybutorze — powinna zostać zrealizowana. Projekt aplikacji powinien mieć dobrą dokumentację, określającą wymagania biznesowe, a sam użytkownik powinien móc swobodnie zapłacić przy pomocy aplikacji (integracja z systemem płatności, z systemem kasowym). W tym przypadku inwestycja w aplikację będzie wyższa niż w drugim przypadku.

W drugim przypadku wystarczy, że przygotujemy bazową funkcjonalność w oparciu o model MVP — produkt w minimalnej wersji, spełniającej absolutnie podstawowe wymagania. Na tej podstawie organizacja powinna zebrać wśród użytkowników wiedzę czy nasz pomysł ma przyszłość i warto inwestować w rozwój aplikacji, czy też odwrotnie i nie powinniśmy ryzykować (ewentualnie zmienić nasze pierwotne założenia). Opracowując MVP, nie inwestujemy dużych środków, tylko weryfikujemy swój pomysł w oparciu o narzędzie niekoniecznie dopracowane w 100%.

T&M czy Fixed price: wybierz odpowiedni sposób rozliczeń

Współpraca między dostawcą IT a zleceniodawcą opiera się z reguły o dwa modele rozliczeń:

  • Fixed Price — ustalenie z góry określonego zakresu prac w zamian za jednoznacznie określoną kwotę. Kluczowe jest tutaj możliwie najbardziej szczegółowe opracowanie specyfikacji projektu, bo nie ma dużej przestrzeni na potencjalne zmiany. Mniejsza elastyczność i jednocześnie większe ryzyko powodują, że z reguły dostawcy doliczają do pierwotnej estymacji pewną wartość procentową (zazwyczaj od 20 do 40%), która powyższe ryzyko ma zmitygować. Koszt aplikacji mobilnej i webowej może po prostu wzrosnąć.
  • Time & Material — tutaj opieramy się na ustalonej stawce za roboczogodzinę, na podstawie której będzie rozliczany projekt. Na koniec ustalonego okresu rozliczeniowego (np. miesiąc) wykonawca generuje z systemu projektowego (np. Jiry) raport pracy programistów w podziale na godziny i zadania. Takie podejście pozwala na bardziej elastyczne podejście do specyfikacji projektu (nie musi być ona określona z góry z detalami), a sam wykonawca płaci za realnie przepracowane godziny pracy zespołu.

Pewnym kompromisem jest podejście mix, gdzie pewien określony zestaw funkcjonalności projektu opieramy o fixed price, a kolejne jego etapy rozliczane są już w T&M.

Jak wybrać nasz model, aby z jednej strony nie przepłacić, a z drugiej — uzyskać projekt, którego oczekujesz? To oczywiście zależy:

  • czy mamy z góry określony budżet, którego nie możemy w żaden sposób przekroczyć
  • czy zależy nam na elastyczności zespołu deweloperskiego
  • czy oczekujemy dokładnego raportowania czasu pracy programistów, jak ma to miejsce w raportach T&M?

Podsumowanie: koszt aplikacji mobilnej i webowej

Jest wiele czynników, które wpływają na koszt stworzenia aplikacji. Nie dotyczy aspektu stricte technicznego, ale zależy w dużej mierze od nas, zlecających projekt. Jeżeli już na samym początku jasno określamy nasze potrzeby i cele zostawiamy mniej miejsca na potencjalne ryzyka w komunikacji czy zakresie funkcjonalnym. W takiej sytuacji wybór rozliczania T&M może się okazać zwyczajnie tańszy w realizacji. 

Analogicznie — jeśli jasno określimy kompetencje w naszym zespole, tj. wskażemy Product Ownera, ponoszącego pełną odpowiedzialność oraz podejmującego niezależne decyzje co do projektu — mitygujemy ryzyko, które może generować zbędne koszty na niekończących się zmianach i poprawkach.

Jeszcze jednym istotnym kosztogennym czynnikiem jest czas realizacji. Wszystkim znane jest powiedzenie „Co nagle to po diable”, a i w realizacji projektów IT warto czasem sięgać do mądrości ludowych i zapobiegać, niż później płacić za kosztowne leczenie. Dlatego nie zawsze musimy realizować wszystkie funkcjonalności już teraz, zaraz, w pierwszej fazie. Model MoSCoW, pozwalający określić priorytet danej funkcjonalności (must, should, could, would) może być naszym własnym buforem bezpieczeństwa, który będzie chroniło Ciebie przed niepotrzebnymi kosztami i wyższym ryzykiem w realizacji projektu 

Wróć