Zrealizuj swój projekt dziś

Co wpływa na koszt aplikacji mobilnej i webowej?

Co wpływa na koszt aplikacji mobilnej i webowej?
img
Ilona LeoniewskaStyczeń, 2021

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

 

Czy wiemy, czego chcemy

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

Drzewo sukcesu planowania aplikacji mobilnej i webowejPlan aplikacji mobilnej. Składowe sukcesu.

  • obsługa klienta to zbyt duży koszt
  • nasze zamówienia są zbyt wolno obsługiwane
  • chcemy dać naszym klientom nową jakość obsługi
  • nasi klienci nie mają jednego miejsca, w którym znajdą nasze promocje i aktualne oferty
  • nasze usługi są trudno dostępne dla naszego klienta
  • nie docieramy do naszych klientów z naszym komunikatem

 

Dla większości firm będą to problemy, które w ostatecznym rozrachunku odbijają się na wyniku finansowym. 

 

Kolejnym etapem określania potrzeb jest precyzyjne wskazanie celów, które pozwolą odpowiedzieć na potrzeby biznesowe. Aby inwestycja w aplikację webową lub mobilną zwróciła się w krótkiej (bądź długiej) perspektywie musisz wskazywać cele biznesowe, które będą posiadały pewne konkretne cechy charakterystyczne.

 

Cel powinien być:

  • mierzalny tj. wskazany przy pomocy liczby, 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 mu oferty itd

 

Kiedy już masz określone 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 te elementy (potrzeby biznesowe, cele biznesowe i Definition of done – DoD) jesteś w stanie przystąpić do współ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 mają doprowadzić do ich osiągnięcia.

 

Technologia

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).

Aplikacja mobilna schematAplikacja mobilna wybór technologii

Szczegółowo na ten temat opowiedział CEO Escola S.A. Krzysztof Wojewodzic na 4Developers Wrocław 2019

 

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. nasze 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

Komunikacja aplikacja mobilna i webowaKomunikacja przy tworzeniu aplikacji mobilnej i webowej

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 budżet przeznaczony na inwestycję w aplikację może zostać nadszarpnięty. 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.

 

Liczba widoków w aplikacji mobilnej i webowej

Ekran aplikacji mobilnejWidok rejestracji w aplikacji mobilnej

 

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.

 

Integracje

W punkcie z liczbą widoku oraz we wcześniejszym punkcie z potencjalnymi wyzwaniami w obszarze komunikacji wspominałam o potencjalnych integracjach (system płatności, system ERP, CRM lub podobne).

 

Dlaczego integracje mogą mieć znaczący wpływ na koszt realizacji projektu aplikacji mobilnej i 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

Koszt realizacji 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 powoduje, że z reguły dostawcy doliczają do pierwotnej estymacji pewną wartość % (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.

Lista celów w tworzeniu aplikacji mobilnej i webowejKoszt aplikacji mobilnej i webowej

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

 

Jak wybrać nasz model, aby z jednej strony nie przepłacić, a z drugiej — uzyskać projekt, którego oczekujemy? 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 realizacji 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óre będzie nas chroniło przed niepotrzebnymi kosztami i wyższym ryzykiem w realizacji projektu 

Wróć

Przeczytaj również