Jak planować budżet aplikacji i ile to kosztuje? Od pomysłu do go-live!

Cześć! Witam Was bardzo serdecznie w naszym kolejnym odcinku naszego podcastu Just No-code. Dzisiaj porozmawiamy sobie trochę o budżetowaniu, czyli odpowiemy na pytania, które bardzo często dostajemy i które najczęściej jest zadawane przez różne firmy, organizacje czy osoby. Mianowicie ile taka aplikacja może kosztować? Oczywiście temat jest trochę złożony. Żeby powiedzieć ile taka aplikacja może kosztować, musimy zadać bardzo wiele pytań, Musimy znać wiele odpowiedzi, musimy dużo o takiej aplikacji wiedzieć. Niestety nie zawsze jest to możliwe. Nie zawsze będziemy wszystko wiedzieć na samym początku. Dlatego też jak pewnie wiecie o czym też będziemy rozmawiać w następnych odcinkach podcastu w IT raczej w developmencie stosuje się podejście Agile’owe tzw. zwinne, nie Waterfallowe czyli postępujące po sobie aspekty. Tylko podejście, które gwarantuje nam pewną elastyczność w odniesieniu do tego, co tworzymy. I dzisiaj właśnie sobie na ten temat porozmawiamy. Odpowiemy na takie pytania jak Na czym polega budżetowanie aplikacji? Czym jest fixed price, Czym jest time & material? Co jest wyceniane, czyli co jest brane pod uwagę do wyceny, którą przygotowujemy na przykład my? Co ma wpływ na tę wycenę i dlaczego warto w ogóle mieć to w swojej wycenie, w swoim ofertowaniu?

‍

Na samym końcu odpowiemy na pytanie dlaczego tworzenie aplikacji w no-code / low-code jest tańsze niż w tradycyjnym podejściu? Z czego dokładnie wynika ta różnica i powiemy sobie, od czego de facto zależy ten finalny koszt aplikacji. Mam nadzieję, że ten odcinek będzie dla Was ciekawy. Zaczynamy! Dobrze, więc zacznijmy od tego, na czym polega budżetowanie aplikacji. Po pierwsze, budżetowanie aplikacji polega na tym, że, przychodzi do nas klient. Przychodzicie do nas i zadajecie nam pytanie "Hej, słuchajcie, mamy taki pomysł na aplikację. Ile to by mogło kosztować?" Oczywiście odpowiedź będzie przeważnie brzmiała "to zależy". Odpowiedź typowego konsultanta, którym byłem przez dłuższy czas w swojej karierze. No, bo to zawsze zależy od bardzo wielu czynników. Na początku nigdy nie jesteśmy w stanie odpowiedzieć, ile taka aplikacja będzie kosztowała. De facto brutalna prawda jest taka, że dopóki tej aplikacji nie dowieziemy, to nigdy nie jesteśmy w stanie ze stuprocentową pewnością odpowiedzieć, ile taka aplikacja będzie kosztować. Oczywiście, jeżeli ktoś, jakiś software house działa w podejściu fixed price, o którym sobie porozmawiamy, no to wtedy Wam taką cenę poda ile będzie sobie życzył za stworzenie takiej aplikacji.

‍

Ale wiąże się to z pewnymi ryzykami czy pewnymi kompromisami, na które musicie się zgodzić. Jeżeli ktoś ma Wam dać gwarancję ceny na software, na którego temat jeszcze nie za bardzo wiele wie. Aby wycenić aplikację, po pierwsze musimy jak najwięcej o niej wiedzieć. Musimy wiedzieć jakie ma mieć funkcjonalności, jakie ma spełniać wymagania techniczne, jak podchodzimy do designu, kto będzie odbiorcą tej aplikacji, bo na podstawie tego, kto będzie odbiorcą tej aplikacji, będziemy mogli sobie rozbić trochę jak ona będzie wyglądała, jak będzie funkcjonowała, jaka platforma będzie do tego odpowiednia. Wybór narzędzi do budowy tej platformy również ma wielkie znaczenie, bo w jednych narzędziach buduje się szybciej, w innych trochę wolniej. Jeżeli budujemy wolniej, to znaczy, że potrzebujemy więcej czasu. To znaczy, że jeżeli potrzebujemy więcej czasu, to też finalna cena będzie również większa, bo płacimy za ten czas, który poświęcamy na budowę tego rozwiązania. Finalna cena budżetowania aplikacji również zależy od podejścia budowania tego budżetu, czyli czy to będzie fixed price, to będzie Time & Material, czyli płatność za ilość przepalonych godzin.

‍

Generalnie rzecz biorąc, my jako agencja no-code działamy tak samo jak tradycyjny software house, czyli bierzemy pod uwagę wszystkie aspekty budowy aplikacji. Bierzemy pod uwagę to, że musimy mieć project managera, że musimy zrobić design, że ta aplikacja powinna być przetestowana etc. Omówimy te wszystkie aspekty w dalszej części podcastu. Po prostu różni się u nas stack. Jakie wynikają z tego różnice? To też o tym opowiemy w dalszej części dzisiejszego odcinka. Więc teraz chciałbym przejść do tego, czym są te modele cenowe. Jeżeli podchodzimy do budżetowania aplikacji, to oczywiście z naszej perspektywy wygląda ono tak że dostajemy jakąś listę funkcjonalności, którą chcecie uwzględnić w swojej aplikacji. Wiemy co mamy zrobić z designem, wiemy ile mniej więcej powinniśmy poświęcić na zarządzanie tym projektem, na przetestowanie tego projektu i tak dalej. My bierzemy te funkcjonalności i zakładamy ich złożoność. Oczywiście założenie złożoności i każdej funkcjonalności jest trochę zgadywaniem. Jeżeli mamy być szczerzy, bo nigdy nie znamy złożoności, dopóki de facto nie usiądziemy z Wami, nie zwarsztatujemy każdej pojedynczej funkcjonalności. No ale jeżeli chcecie znać już na samym początku ballpark, gdzie macie naprawdę na początku tylko sam pomysł na funkcjonalności jeszcze nie są opisane, nie mamy żadnych szczegółów dotyczących tej funkcjonalności.

‍

No to my też tak samo jak i Wy trochę zgadujemy i musimy się domyślać jak bardzo złożone te funkcjonalności będą. My siadamy, wyceniamy to i wtedy dostajecie ballpark, czyli tak zwaną wstępną estymacje, która daje Wam jakieś widełki, daje Wam jakiś ogląd na to, ile naszym zdaniem taka aplikacja będzie mniej więcej kosztowała. Oczywiście, w zależności od tego, jak głęboko będziemy wchodzić w dane funkcjonalności, czy będziemy coś dokładali podczas developmentu, czy będziemy, te funkcjonalności, które wstępnie były bardzo proste, według Was powinny być bardziej skomplikowane, będziemy ten czas dokładali to automatycznie, też wiadomo, że ten czas się wydłuży i za tym też zwiększy się wycena czy finalny koszt budowy takiej aplikacji. Więc teraz porozmawiajmy trochę o tym, czym się różni podejście fixed priced od podejścia time and material podejściu fixed price dostawca rozwiązania zakłada, że wie bardzo dużo o tej aplikacji, że mało rzeczy może go teoretycznie zaskoczyć i jest w stanie Wam dostarczyć model ceny właśnie w tym modelu fixed price, czyli cenę jakąś już ustaloną z jakąś prawdopodobnie gwarancją. Zakłada, że nie wydacie więcej i gwarantuje Wam to, że aplikacja będzie tyle kosztowała.

‍

Niestety to podejście ma bardzo wiele minusów. Przede wszystkim jego minusem jest to, że nie zakłada żadnej elastyczności. Umawiacie się z dostawcą na stricte funkcjonalności takie jak dostawca i na obecny czas rozumie wszystkie zmiany, które będziecie chcieli wprowadzać. Będą na nie zakładane tzw. change request, czyli żądania zmian. Wszystkie żądania zmiany oczywiście też będą wpływały na finalną cenę tej aplikacji. To będzie dla was takie tylko fałszywe poczucie na początku, że wiecie ile aplikacja będzie kosztowała. Natomiast z naszego doświadczenia i z doświadczenia chyba wszystkich software house wynika, że to początkowe mniemanie, to początkowe myślenie o aplikacji jest zupełnie inne niż ten finalny produkt. Zupełnie czym innym jest to, jak sobie aplikacje wyobrażamy. Czym innym jest etap tego, jak już ją wizualizujemy chociażby na bardzo wstępnej makiecie, a czym innym jest produkt, który zaczynamy klikać. Zobaczycie, że bardzo wiele rzeczy wtedy w tym projekcie, w tej aplikacji będziecie chcieli po prostu zmieniać, no bo zobaczycie, że o bardzo wielu rzeczach nie jesteście w stanie pomyśleć i bardzo wielu rzeczy nie jesteście w stanie na samym początkowym etapie przewidzieć.

‍

Dlatego ten model, według nas fixed price i według chyba wszystkich software house'u jest po prostu bardzo groźny. Powoduje, że na etapie developmentu zamiast skupiać się na samym developmencie, na wprowadzaniu funkcjonalności, które mają naprawdę znaczenie, skupiamy się bardzo dużo na samej biurokracji, na wprowadzaniu właśnie tych change requestów, potwierdzania ich, scope-owania, wyceniania itd. Bo każdy request nie dość, że musi być jakoś scope'owany, czyli musi być jakoś określony, co ma być dokładnie zrobione. Muszą być określone jakieś ramy tego, co będziemy robili, no bo one muszą być jakoś wycenione. Czyli dostawca musi powiedzieć OK, to ten change request, widzimy tę funkcję, którą chcecie wprowadzić według nas ona będzie kosztowała tyle, no i musicie to potwierdzić. Więc spowalnia to de facto proces i nie daje elastyczności, która de facto w tworzeniu software'u powinna być wzięta bardzo mocno pod uwagę. I tutaj właśnie wchodzi ten drugi model, o którym sobie porozmawiamy i model Time &  Material, czyli de facto mamy jakiś scope. Wiemy mniej więcej, co chcemy budować, mamy jakieś wyobrażenie, ile mniej więcej to może kosztować.

‍

Możemy sobie też coś założyć, że ok, widzimy jakieś ramy tego, co chcemy budować, ale Time & Material jest podejściem typowo godzinowym. Czyli my robimy, realizujemy wszystkie funkcjonalności po kolei. Oczywiście jedne jesteśmy w stanie wycenić bardziej precyzyjnie, inne mniej precyzyjnie. Takie funkcjonalności jak np. logowanie, rejestrację no są to raczej procesy powtarzalne, które jesteśmy w stanie całkiem dokładnie wycenić, określić ile będą kosztowały, więc tutaj możemy sobie założyć jakieś takie sztywniejsze ramy. No ale funkcjonalności takie, które dotyczą już stricte Waszej aplikacji, które są trochę niepowtarzalne w innych aplikacjach są podobne, ale w każdej aplikacji inaczej wyglądają i co innego musi być wzięte pod uwagę. No to tutaj właśnie potrzebujemy tej elastyczności z Waszej strony. My oczywiście też coś zakładamy, że to powinno kosztować mniej więcej tyle, że to mniej więcej tyle powinno zająć, Ale wraz z tym, jak wy będziecie widzieć ten progres budowy aplikacji, będziecie widzieć jak ona zaczyna funkcjonować. Będziecie mogli się przez nią przeklikiwać, zaczną wam przychodzić do głowy nowe pomysły albo małe tweak-y, że hej, Chciałbym tutaj zmienić trochę to, a tutaj chciałbym, żeby to działało jednak troszkę inaczej.

‍

To w tym momencie nie bawimy się w tą całą biurokrację i nie mówimy OK, no to wyceniamy to, usiądźmy do tego, policzcie ile to będzie kosztowało i teraz to potwierdź, ale nie tutaj drogi dostawco się pomyliłeś i trochę chcielibyśmy to jednak inaczej i cały ten proces przechodzimy. Tylko mówimy okej, dobra, to wprowadzamy zmianę, sprawdźcie czy to wam odpowiada i po prostu działamy. Oczywiście z drugiej strony może się dla Was wydawać to podejście bardzo ryzykowne, że teraz to Wy nie wiecie, ile de facto godzin dostawca takiego rozwiązania spędzi, co się za tym będzie kryło, jakie finalne koszta będą dotyczyły tej aplikacji. Natomiast nie jest to do końca prawda, bo tak jak powiedziałem na samym początku określamy sobie trochę te ramy. Wiadomo, że jeżeli będziecie dużo dokładać, będziecie dużo zmieniać, no to ten czas też będzie się wydłużał, on będzie też wpływał na ten finalny koszt. Natomiast tak jak mówiłem, jeżeli określimy sobie te ramy, większość funkcjonalności jesteśmy w stanie wycenić całkiem niezłą precyzją. No to możecie czuć się całkiem bezpiecznie, bo Wy też monitorujecie cały ten proces tworzenia tej aplikacji.

‍

Widzicie na co te godziny są przepalone, jak również z dostawcą bardzo często możecie się umówić. Okej, Słuchajcie, umówmy się na te otwarte godziny, ale proszę, nie używajcie więcej niż np. 100, 160, 200, 300 godzin miesięcznie, bo po prostu taki mamy miesięczny budżet i chcemy go trzymać. Jeżeli będziecie już na przykład w 50% realizacji godzin w danym miesiącu czy w 75%, poinformujcie nas i będziemy podejmować kroki, co powinno mieć większy priorytet i na czym chcemy się skupić. Więc jak widzicie to podejście Time & Material ma większą elastyczność daje bezpieczeństwo dwóm stronom i nie spowalnia samego procesu budowania aplikacji. A de facto w obecnych czasach przeważnie chodzi nam o to, żeby ten proces tworzenie aplikacji, był zwinny, był elastyczny. Żebyśmy mogli na bieżąco odpowiadać na wymagania środowiska biznesowego, które bardzo dynamicznie się zmienia. Dobrze, więc porozmawiajmy sobie w takim razie teraz o tym, co de facto ma wpływ na tą wycenę, bo na wycenę ma oczywiście wpływ bardzo wiele czynników. Tak jak już na początku trochę wspomniałem, oczywiście lista funkcjonalności, jak wiele funkcjonalności będziemy chcieli wprowadzić do aplikacji.

‍

To ma największy wpływ na tą naszą wycenę, no bo musimy je wszystkie uwzględnić, czym tych funkcjonalności więcej, no to wiadomo, że potrzebujemy więcej czasu na tę realizację, ale na wycenę ma wpływ również np. to jak chcemy podejść do designu, czy ma to być prosty design, bo startujemy z MVP i po prostu ma być czysty i czytelny. Czy jesteśmy jakąś firmą, która ma już jakieś swoje guideline dotyczące tego jak aplikacje powinny wyglądać? Czy jesteśmy firmą, która chce bardzo mieć taki wymuskany ten design pixel perfect design, w którym będą dane, będzie wiele wodotrysków, wiele fontann, które będą robiły wielkie wow u użytkowników, no to wiadomo, że wtedy też będziemy musieli poświęcić po prostu więcej czasu na po pierwsze design takiej aplikacji, żeby designerzy przygotowali tą aplikację, to żeby właśnie był ten efekt wow. A z drugiej strony czym bardziej wymuskany design, to tym więcej potrzebujemy czasu na development takiej aplikacji. Kolejną rzeczą, która ma wpływ na wycenę jest mnogość narzędzi czy platform, które biorą udział w przygotowaniu tej aplikacji. Oczywiście jeżeli rozwiązanie budujemy tylko na jednej platformie no-code’owej, to wiadomo, że wtedy ta złożoność jest dużo niższa niż jeżeli byśmy chcieli wziąć pod uwagę zintegrowanie kilku platform w jedno narzędzie, bo np.

‍

będzie taki wymóg technologiczny, to to ma bardzo duży wpływ. Kolejną rzeczą jest oczywiście złożoność, też funkcjonalności, które mamy wylistowane, które, które nam dostarczyliście, no bo wiadomo, że jedne funkcjonalności są prostsze, drugie są trudniejsze. Jeżeli będzie bardzo wiele funkcjonalności, które i dla Was nie do końca są jasne, nie wiecie co ma być finalnym efektem jaki ma on być. Co de facto ta funkcjonalność ma realizować. Nie wiecie, jak do niej podejść, nie wiecie jak powinna być realizowana. To tutaj np. powinniśmy uwzględnić workshopy, na których sobie razem to pracujemy, na których wymyślimy jak dokładnie powinno to funkcjonować, żeby odpowiadało na Wasze potrzeby. Ilość integracji z zewnętrznymi platformami na przykład na platformie powinny być zintegrowane płatności i chcecie skorzystać z Przelewy24 i chcecie skorzystać ze Stripe? Skorzystać z ostatnio bardzo modne i sztucznej inteligencji. Czym więcej takich integracji na platformie będzie, tym więcej dokumentacji dostawca będzie musiał przeczytać, żeby się z nimi zapoznać, żeby je wdrożyć do Waszej platformy. Tym więcej integracji będzie musiał do tej platformy wdrożyć, zintegrować, obsłużyć i zaimplementować, co oczywiście też wydłuża czas.

‍

Natomiast wiadomo, że takie też rozwiązania jak Stripe, przelewy czy te wszystkie najpopularniejsze rozwiązania, z których będziecie chcieli korzystać dostawcy też już dobrze znają. Więc jeżeli dostawca już wcześniej korzystał z takich integracji, wcześniej już gdzieś zaimplementował. Warto o to zawsze zapytać, żeby się dowiedzieć, czy ma Wasz dostawca doświadczenie z daną integracją. To on już wie jak to funkcjonuje. Wie jak to zaimplementować. Wie, jakie niespodzianki mogą go tam czekać. Więc to też będzie wtedy potencjalnie mniej kosztowało. Będzie Wam dostawca w stanie odpowiedzieć, że ok, to będzie kosztowało tyle i będzie w stanie Wam określić po prostu niezbędny budżet. Porozmawialiśmy sobie już o tym, co ma wpływ na wycenę, jakie mamy modele wyceny czy współpracy między dostawcą a Wami jako klientami, na czym polega budżetowanie aplikacji. Więc ja chciałbym teraz trochę powiedzieć o tym, co de facto jest przeważnie wyceniane, co wyceniamy my. Oczywiście nie odpowiadam za inne software house. Myślę, że tam to wygląda podobnie. Bo tak jak już wspomniałem, działamy bardzo podobnie. Znaczy działamy nawet identycznie do tradycyjnych software house po prostu mamy nietradycyjnych stack technologiczny, więc co de facto my uwzględniamy w

‍

 wycenie. Uwzględniamy zawsze workshopy. Bo jeżeli mamy podejście zwinne do tworzenia aplikacji, czyli uznajemy, że czegoś nie wiemy, nie wiemy też, czego nie wiemy, to wiemy, że na pewno będziemy musieli Was wypytać. Będziemy musieli razem porozmawiać o tym, jak chcecie, żeby dane funkcjonalności wyglądały, żebyśmy mieli świadomość tego, jak one będą potencjalnie funkcjonowały, jakie funkcje będą realizowały, jakie cele będą realizowane poprzez te funkcje. Więc do tego zawsze uwzględniamy jakiś czas niezbędny na workshop. Oczywiście ten czas na workshop wyceniamy i określamy w zależności od tego jak dużą platformę będziemy budować. Wiadomo, że czym mniejsza platforma, tym mniej workshopów, im większa platforma, tym więcej potencjalnych workshopów. Przy okazji Workshopów wyceniamy oczywiście również czas niezbędny na cotygodniowe spotkania, na których Wam prezentujemy wyniki naszej pracy. Dzielimy się tym, rozmawiamy o tym, co powinno być priorytetem w nadchodzącym tygodniu, jak to powinno wyglądać i tak dalej, i tak dalej. O prowadzeniu projektów jak dokładnie wygląda współpraca z software house, również będziemy przygotowywali kolejny odcinek w naszym podcaście, więc będziecie mogli usłyszeć o tym, jak dokładnie ta współpraca przebiega.

‍

Następną rzeczą, którą wyceniamy, którą uwzględniamy zawsze, która jest też bardzo ważna, jest sercem aplikacji. To przygotowanie całego środowiska, aplikacji oraz architektury aplikacji. Każda aplikacja ma trochę inną architekturę, inną strukturę bazy danych, inne środowisko. Te wszystkie rzeczy muszą być odpowiednio przygotowane, bo od nich zależy, jak wasza aplikacja finalnie będzie funkcjonowała, czy będzie miała odpowiednią wydajność, czy będzie odpowiednio realizowała Wasze założenia. Czy będzie odpowiednimi danymi dysponowała które na przykład w przyszłości będziecie chcieli sobie wyciągać z tej platformy, to są właśnie takie elementy, które musimy uwzględnić w wycenie, ponieważ jest to serce aplikacji. Więc czas na przygotowanie tego wszystkiego uwzględniamy również w wycenie, jest on odpowiednio takiej wycenie wylistowany. Następną rzeczą, którą uwzględniamy, jest przygotowanie designów, UX, UI, tego wszystkiego, co jest związane z tym jak nasza aplikacja będzie wyglądała oraz trochę jak będzie funkcjonowała, jak się wasi użytkownicy będą w niej po prostu czuli. Tutaj siadają. Do tego nasi designerzy, rozmawiają z Wami, przygotowują moodboard, zbierają od Was informacje na temat tego, jak chcecie, aby aplikacja wyglądała, co Wam się podoba, co Wam się nie podoba.

‍

Uwzględniając te wszystkie informacje, które od Was zbierają na temat tego, jak wygląda współpraca z designerem w aplikacji, co jest ważne do wzięcia pod uwagę, również będziemy przygotowywali taki odcinek i na podstawie tego określamy złożoność czasową. Ile czasu będziemy potrzebowali na przygotowanie właśnie tych designów. Następną rzeczą jest oczywiście development, czyli ile czasu będziemy potrzebowali na poszczególne funkcjonalności. Jakie mniej więcej widełki zakładamy na każdą z pojedynczych funkcjonalności, że nam zajmie? Czym więcej informacji od Was dostajemy na temat każdej pojedynczej funkcjonalności, tym bardziej precyzyjnie jesteśmy w stanie ją wycenić. Czasami będą to duże rozstrzały nawet na poziomie 100-200%. Jeżeli czegoś nie wiemy i coś wydaje się bardzo złożone. Czasami będą to rozstrzały na poziomie kilku procent. Jeżeli funkcjonalność będzie bardzo prosta i raczej nie powinna nas niczym szczególnym zaskoczyć. Następną rzeczą, którą uwzględniamy w wycenie jest QA, czyli Quality Assurance. Każda aplikacja, którą przygotowujemy, którą chcemy Wam oddać, która ma zderzyć się z Waszymi klientami czy z Waszymi użytkownikami, powinna być według nas odpowiednio przetestowana. Za każdym razem, kiedy tworzymy aplikację, jest ona wydevelopowana,

‍

zanim trafi ona w Wasze ręce do Waszych testów jest odpowiednio testowana przez naszych Quality Assurance Engineers, czyli po prostu przez testerów, przez procesy, które mamy wewnętrznie. Firmy wdrożone do tego, aby zapewnić aplikacji jak najwyższą jakość i wolność od dużej ilości błędów. Czyli my staramy się zawsze dostarczyć produkt Wam, który w Waszej opinii będzie produktem już gotowym, przetestowany i oczywiście nadal będziecie mogli w nim znaleźć jakieś drobne błędy, bo do dzisiaj nawet takie firmy jak Facebook czy Google mają przycisk "Report a Bug", bo bugi się zawsze zdarzają. Wraz z tym jak wprowadzamy kolejne nowe funkcjonalności. Nie przewidzimy wszystkiego, nie jesteśmy nigdy w stanie przewidzieć wszystkiego i gdzieś pewne błędy mogą się zdarzyć. Natomiast my testujemy aplikację jak najintensywniej, tak żebyście Wy dostali produkt, który już będzie spełniał Wasze rygorystyczne wymogi. Następną rzeczą, którą też uwzględniamy w wycenie jest to zarządzanie projektem, czyli to, że my będziemy Was trochę ganiać, będziemy od Was zbierać informacje, będziemy od Was wymagali odpowiedzi na wiele pytań, bo wiele rzeczy nie wiemy i nie chcemy zgadywać. To jest Wasza aplikacja.

‍

To Wy macie być z niej na koniec dnia zadowoleni. Więc nasi developerzy podczas developmentu czy designerzy będą mieli do Was wiele pytań. Wiele rzeczy, tak jak np. polityka prywatności, jak np. dostęp do kont, do środowisk pewnych czy do informacji, czy tego typu rzeczy będziecie musieli dostarczyć nam Wy, żebyście wy nam je dostarczyli musicie o tym wiedzieć. I tutaj dba o to właśnie nas nasz project manager, który te wszystkie informacje ze sobą zbiera, ze sobą łączy. Jest takim pośrednikiem między nami a Wami i dba o to, aby cały proces przebiegał sprawnie, bez zakłóceń i żeby ta wymiana informacji przebiegała bardzo sprawnie. Nie znaczy to oczywiście, że my bawimy się jakkolwiek w głuchy telefon i nie macie dostępu do naszych developerów, do naszych testerów czy do naszych designerów. Po to właśnie mamy te spotkania, o których sobie wspomnieliśmy wcześniej, żebyście zawsze mogli porozmawiać z całym zespołem i to zespołowi przekazywali też te wszystkie informacje. Natomiast to zarządzanie pozwala nam usprawnić ten proces i sprawić, żeby był on po prostu smooth. Dobrze, więc dlaczego jeżeli uwzględniamy te wszystkie rzeczy, które uwzględnia też tradycyjny software house, to dlaczego de facto w podejściu no-code jest taniej.

‍

Musicie wziąć pod uwagę to, że oczywiście takie procesy jak workshop, przygotowanie architektury, designu czy testowanie aplikacji czy zarządzanie projektem to tych rzeczy nie jesteśmy w stanie przyspieszyć względem tradycyjnego software house. Rzeczy wyglądają tam dokładnie tak samo. Rozmowy z Wami na szopach wyglądają tak samo jak w tradycyjnym podejściu, tego nie jesteśmy w stanie obejść. Designy wyglądają tak samo jak w tradycyjnym podejściu. Tutaj procedura jest taka sama jak w każdym software house czy w każdej agencji, która zajmuje się przygotowywaniem designu, w każdej agencji UX / UI. Testowanie aplikacji. Żeby przetestować aplikację, przejść po niej również potrzebujemy tyle samo czasu, co w tradycyjnym podejściu. Oczywiście tutaj mamy trochę mniej czasu w testowaniu, poświęcamy na testowanie poszczególnych elementów, ponieważ tworzymy z gotowych klocków, więc one są już odpowiednio przetestowane, mają odpowiednio wysoką jakość, więc tutaj ten czas oszczędzamy. No i oczywiście najwięcej czasu oszczędzamy na samym developmencie, bo jeżeli my tworzymy właśnie z tych predefiniowanych klocków, dodajemy ewentualnie 10%, 20% custom kodu, to tutaj zobaczycie te znaczące różnice w wycenie. Tutaj zobaczycie te znaczące różnice, w czasie którego potrzebujemy, który potrzebujemy poświęcić, żeby stworzyć pewne funkcjonalności.

‍

I to tutaj musicie upatrywać tych różnic właśnie w wycenie. No i de facto ostatni punkt, który chciałem dzisiaj jeszcze przedyskutować to, od czego zależy finalny koszt aplikacji. Tak jak już trochę sobie o tym porozmawialiśmy, oczywiście zależy on bardzo często też od Waszego podejścia. Czym więcej rzeczy będziecie chcieli zmieniać podczas developmentu czy podczas designu, to tym więcej rzeczy będziemy musieli wdrożyć, więc tym więcej czasu na tej aplikacji spędzimy. Jeżeli będziecie chcieli dodawać kolejne nowe rzeczy podczas pierwszej iteracji, to tym więcej czasu ta pierwsza iteracja zajmie. Wszelkie zmiany, które będziecie chcieli wprowadzać, oczywiście mają znaczący wpływ na to, jaki będzie finalny koszt tej aplikacji. Zmiany zawsze mają największy wpływ po prostu na to, ile finalnie taka aplikacja będzie kosztowała. Design im prostszy, tym mniej czasu potrzebujemy na jego stworzenie czy na jego wymyślenie. Oczywiście bardzo często zdarza się tak, że już macie przygotowany design po swojej stronie i to też jest ok, bo wtedy wiadomo, że takiego designu po prostu w wycenie nie uwzględniamy. Jeżeli dostaniemy od Was widok wszystkich ekranów albo ekranów, które też nam pozwolą zaprojektować czy deweloperowi powiedzieć okej, to ten ekran też będzie bardzo podobny do tego tutaj się zmienią, ewentualnie wyświetlane dane na tym ekranie, to wiadomo, że wtedy ten design możemy odpuścić i po prostu postępować zgodnie z dostarczonym przez Was guideline.

‍

Kolejne iteracje, feedback od użytkowników. Jeżeli będziecie chcieli również reagować na niego od razu, to to są również zmiany, które musimy wprowadzać do aplikacji. Również Wasze podejście trochę będzie miało wpływ na ostateczną cenę tej aplikacji, ponieważ czym łatwiej będzie nam się dogadać, czym sprawniej będziemy dostawali od Was odpowiedzi, to tym mniej czasu spędzimy również na czekanie czy pilnowanie Was, przypominanie Wam o tych odpowiedziach, co de facto może wpłynąć na cały proces, na cały projekt i na to, ile czasu projekt manager musi spędzić. Nad tym, aby zebrać wszystkie informacje do tak zwanej kupy, połączyć je ze sobą i powiedzieć deweloperom czy wam hej, potrzebujemy tego i tego? Czy mniej czasu potrzebujemy na tego typu kwestie, tym mniej czasu po prostu spędzamy. To ile czasu będziemy spędzali na dyskusjach cotygodniowych, jak bardzo będziecie dobrze przygotowani na workshopy, na których będziemy dyskutowali funkcjonalności również będzie miało znaczący wpływ na ten finalny koszt aplikacji, ponieważ jeżeli będziecie przychodzili nieprzygotowani na warsztaty, będziecie przychodzili nieprzygotowani na nasze cotygodniowe spotkania, no to będziemy musieli bardzo ten temat drążyć.

‍

Będziecie spędzali czas nad tym, żeby się nad nim zastanawiać, co de facto po prostu na sam koniec dnia ten proces wydłuża. Słuchajcie, ja myślę, że dałem wam taką podstawową wiedzę na temat tego jak wygląda budżetowanie aplikacji. Przeszliśmy sobie de facto po tym, co musimy wiedzieć, aby wycenić. Zrobimy sobie teraz małe podsumowanie. Musimy wiedzieć jak najwięcej na temat Waszej aplikacji. Czym więcej macie szczegółów, czym bardziej szczegółowo macie opisane wszystkie funkcjonalności, Tym lepiej dla Was, tym lepiej dla nas, bo na podstawie tego jesteśmy w stanie określić i wyestymować wszystkie funkcjonalności. Oczywiście nie zawsze będzie to możliwe do określenia precyzyjnie, ale czym więcej wiemy, tym bardziej precyzyjnie jesteśmy w stanie to określić. Wiemy, czym różni się podejście fixed price od podejścia time and material, czyli to podejście elastyczne, to podejście Agile. Jakie ono ma swoje wady, jakie każdy z tych podejść ma zalety. Oczywiście w internecie jest mnóstwo informacji na ten temat. Jak dokładnie i czym dokładnie te modele się różnią. Każdy software house też trochę inaczej podchodzi do budżetowania, ma jakieś swoje modele współpracy.

‍

Więc tutaj powiedziałem Wam ogólnie jak to wygląda. No ale tutaj zawsze też wyjdzie to po prostu we współpracy z danym software house, gdzie opowiedzieliśmy sobie troszkę o tym co ma wpływ na tą wycenę, że ma wpływ mnogość narzędzi, platformy, złożoność funkcjonalności, lista tych funkcjonalności. Czym więcej tym bardziej złożone. Ilość integracji z zewnętrznymi platformami spotkania, Workshopy, to jak bardzo jesteście przygotowani. Te wszystkie rzeczy mają wpływ na tą wycenę. Powiedzieliśmy sobie również o tym, co ma wpływ na tę wycenę i co jest w tej wycenie uwzględniane. Warsztaty, spotkania. Design, Development, Quality Assurance, czyli testy dotyczące platformy i zapewnienie odpowiedniej jakości oraz zarządzanie tym projektem. Więc wydaje mi się, że udało nam się dzisiaj powiedzieć o tym, jak kompleksowo wygląda budżetowanie. Oczywiście jest to tak zwany overview. Jest to coś, co ma dać Wam jakiekolwiek wskazówki czy ogólną wiedzę na temat tego, jak wygląda budżetowanie. Bo musicie też mieć na koniec dzisiejszego odcinka świadomość, że do każdej aplikacji każdy software house podchodzi trochę indywidualnie. Bo po pierwsze ma do czynienia z trochę innym klientem, trochę innym produktem.

‍

Każdy klient chce współpracować inaczej czy na innych zasadach, bo ma też jakieś swoje wymagania, więc tutaj zawsze te kwestie też są dyskutowane indywidualnie. Mam nadzieję, że dzisiejszy odcinek był dla Was ciekawy, dał on wam jakieś wskazówki na temat tego jak wygląda budżetowanie aplikacji, co jest brane pod uwagę i mam nadzieję do usłyszenia w kolejnym odcinku naszego podcastu. OK, dzięki, do usłyszenia.

‍