Co potrzebuję, żeby stworzyć aplikację mobilną?
Zaplanuj sukces Twojego produktu.

icon
Spotify
icon
Apple Podcasts
icon
RSS Feed
icon
Youtube
Uczestnicy
Piotr Lewandowski
CEO ImpiCode
Grzegorz Papaj
VP of Business ImpiCode
Opis odcinka
W dzisiejszym odcinku podcastu omówimy proces planowania i specyfikowania nowej aplikacji mobilnej. Omówimy różne podejścia do tworzeni nowej aplikacji oraz doradzimy, jak zacząć i czym się kierować podczas całego procesu.

Wytłumaczymy, co powinna zawierać dobra specyfikacja, by uniknąć zbędnych kosztów. Oraz które elementy można/należy pominąć na wczesnym etapie planowania, by nie zaciemniały głównej wizji produktu.

Omówimy kiedy specyfikowanie własnego rozwiązania na podstawie różnic w gotowych aplikacjach ma sens. Pokażemy, jak unikalność i dostosowanie do potrzeb użytkowników mogą przeważyć nad gotowymi rozwiązaniami.

Odpowiemy na pytanie, na jakie platformy tworzyć aplikacje mobilne oraz o ile droższe jest stworzenie aplikacji na obie platformy w porównaniu do jednej aplikacji.

Zapraszamy do wysłuchania naszych rad, które są efektem zaprojektowania i zbudowania ponad 20 aplikacji mobilnych dla naszych klientów.
POZOSTAŁE ODCINKI
Transkrypcja
[ 00:00:34] Piotr Lewandowski: Zaczynamy kolejny odcinek naszego podcastu. Moim gościem jest Grzegorz Papaj VP of Business w ImiCode. Ja nazywam się Piotr Lewandowski, jestem CEO w ImiCode.
[ 00:00:46] Dzisiaj będziemy rozmawiać o tym, czego potrzebujemy, żeby stworzyć aplikację mobilną. I od razu zaczniemy z grubej rury. Czy taka specyfikacja na zasadzie:
[ 00:01:01] Dzień dobry, Chciałbym stworzyć klona Allegro, ale na przykład dla branży futerowej to jest idealna specyfikacja, z jaką możemy się zgłosić.
[ 00:01:12] Grzegorz Papaj: Czy jest idealna? To na pewno nie.
[ 00:01:16] Czy jest dobra? Czasem tak, czasem nie. To zależy.
[ 00:01:21] Tutaj nie ma prostych odpowiedzi. Na pewno można powiedzieć, że jakąś część, funkcjonalności tego typu definicja określa.
[ 00:01:32] Chce zrobić allegro, to każdy wie co to jest Allegro. Każdy jakieś tam wyobrażenie ma. Natomiast trzeba wziąć pod uwagę, że osoba, zwłaszcza nie techniczna, nie do końca musi wiedzieć co się dzieje pod spodem. Jakie funkcjonalności tak naprawdę to Allegro realizuje. Zwłaszcza jeśli patrzy na to tylko z punktu widzenia kupującego, a nie sprzedającego.
[ 00:01:57] No bo sprzedający ma dostęp do wielu innych funkcjonalności, innych niż kupujący. Zaś żadnych z nich nie ma dostępu do tych funkcjonalności, do których mają pracownicy Allegro dokonujący różnego rodzaju analiz, badań, zestawień. Więc to jest jakaś część, o której tak naprawdę nikt nie ma pojęcia.
[ 00:02:18] Więc definiowanie jakiejś aplikacji na zasadzie zróbcie coś dokładnie tak jak Allegro to na pewno nie jest dobry pomysł. Bo to nigdy nie jest dokładnie tak jak ma Allegro czy jakaś inna duża aplikacja.
[ 00:02:34] Co więcej, to trochę wygląda tak jak by ktoś, kto w te sposób definiuje specyfikację, nie odrobił swojej pracy domowej.
[ 00:02:47] Nie jest w stanie przemyśleć, spisać tego, co chce zrobić i posługuje się jakimś pierwszym z brzegu przekładem, który jest podobny.
[ 00:02:56] No bo jak by tak zacząć zadawać pytania szczegółowe.
[ 00:03:00] Przychodzi klient, mówi chcę zrobić Allegro dla takiej czy innej branży i zaczniemy go pytać: Czy Ty potrzebujesz teraz mieć obsługę własnych wysyłek i paczkomatów?
[ 00:03:09] I tutaj pewnie odpowiedź brzmi nie. Pewnie jest więcej takich rzeczy, których na początek nie potrzeba.
[ 00:03:18] Jeżeli już idziemy w stronę takich rozwiązań typu Marketplace, a które Allegro ma i udostępnia.
[ 00:03:26] Z tego wielkiego systemu. Tego wielkiego bytu jakim jest Allegro można sporo wyciąć i to nie będzie ze stratą dla klienta. Jednocześnie, samo określenie co można wyciąć już jest jakimś konkretną pracą, którą trzeba wykonać i to my tego nie wykonamy za klienta.
[ 00:03:50] My nie wiemy czego klient tak naprawdę potrzebuje.
[ 00:03:54] Ale z drugiej strony. Specyfikacja, która podaje aplikację na wzór czasem bywa bardzo dobrą specyfikacją.
[ 00:04:03] Mamy takich klientów, którzy przychodzą do nas i mówią: Korzystamy od lat z takiego i takiego rozwiązania. Ono jest prawie idealne albo dobre, działa jako tako, ale są rzeczy, których nie da się w nim zrobić.
[ 00:04:18] I w tym przypadku klient nam definiuje.
[ 00:04:20] Mam aplikację X, robi to czy tamto i potrzebuję do niej dodatkowe funkcjonalności. I to zupełnie inaczej wygląda.
[ 00:04:30] Często się okazuje, że ta aplikacja wzorcowa, dana np. nie tylko w niej czegoś brakuje, ale też czasem ma wręcz za dużo funkcji, których klient nie potrzebuje, albo które wręcz mu przeszkadzają, bo ma dużo opcji, w których musi się poruszać, co tylko utrudnia zadanie.
[ 00:04:47] Wracając do tego pytania początkowego, specyfikacja na zasadzie chce zrobić coś takiego jak aplikacja X. Ma swoje wady, ma swoje zalety, natomiast na pewno ograniczenie się tylko do takiego opisania nie jest dobrym pomysłem. Trzeba jeszcze tam coś od siebie włożyć, podać trochę więcej informacji.
[ 00:05:11] Piotr Lewandowski: Jak powinienem do tego w takim razie podejść bardziej konstruktywnie?
[ 00:05:15] Czyli wiem, że chcę coś takiego jak Allegro. Mogę sobie coś spisać, mogę coś narysować, co powinienem przemyśleć, zanim się do Was zgłoszę?
[ 00:05:25] Albo czy wszystko zostawić sobie na potem i najpierw się zgłosić i porozmawiać.
[ 00:05:32] Grzegorz Papaj: Na pewno zgłoszenie się i porozmawianie nie jest złym pierwszym krokiem. Natomiast dobrze jest mieć parę kwestii przemyślanych.
[ 00:05:39] Są takie stałe elementy, o które pytamy np. Kto będzie z tej aplikacji korzystał i po co? Jaki jest właściwie jej cel i sens? W jakim otoczeniu będzie ta aplikacja wykorzystywana? Jaki jest jej cel dla właściciela przyszłego biznesu, a jakie korzyści z niej będą odnosić użytkownicy?
[ 00:06:02] Więc to są te rzeczy, o które my zawsze pytamy. I jeżeli już mamy tę otoczkę, rozumiemy kontekst, wiemy do czego ta aplikacja będzie służyć, jakie problemy będzie rozwiązywać, to wtedy zdecydowanie łatwiej nam się rozmawia.
[ 00:06:16] Jeśli ktoś mówi nam, że tutaj widzi, dajmy na to w branży transportowej duże zapotrzebowanie na sprawną obsługę zleceń transportowych i wie, że są dostawcy usług transportowych - właściciele ciężarówek, jednocześnie są firmy logistyczne / przewozowe, które mają zlecenia.
[ 00:06:36] I w tym kontekście chcielibyśmy zrobić coś takiego jak Allegro, to jest to zupełnie inna rozmowa. To nie jest Allegro dla branży transportowej. To jest rozwiązanie, które najpierw zostało osadzone w jakimś tam problemie. Które ma dużo analogii do rozwiązań takich jak Allegro. Nie jest to w żadnym wypadku Allegro, ale możemy się domyślać, że są oferenci i kupujący. Tak można by do tego podejść.
[ 00:07:05] Piotr Lewandowski: Częsty przykład, który ja podaję to taki model myślowy, który dobrze sobie przemyśleć to: Pomyśleć o najmniejszej liczbie użytkowników, dla których to byłoby już przydatne.
[ 00:07:16] Czyli jeżeli mamy np. kilku kierowców tirów, to już możemy sobie myśleć o nich i w tym kontekście czego oni potrzebują niezbędnego, żeby im już to pomogło w używaniu tej aplikacji.
[ 00:07:27] I tak samo z tej drugiej strony mamy kogoś, kto zleca jaki jest taki minimalny zbiór użytkowników, który poczułby wartość zlecając coś w naszej aplikacji.
[ 00:07:39] I wtedy już możemy sobie z siekierką podejść i do funkcjonalności i do gadżetów, i do tego jak duży to ma być system.
[ 00:07:48] Grzegorz Papaj: Podsumowując. Aplikacje najlepiej się definiuje przez problemy jakie mają rozwiązywać. I przez wartości dodane.
[ 00:07:59] Wartości dodane względem tego co aktualnie jest dostępne na rynku albo w jakimś tam powiedzmy przestrzeni.
[ 00:08:06] Piotr Lewandowski: Czym według Ciebie jest ta mityczna wartość dodana, którą może dać aplikacja. Jak byś mógł przybliżyć pojęcia albo dać jakiś przykład?
[ 00:08:13] Grzegorz Papaj: Pytasz mnie o konkrety?
[ 00:08:15] Np. wróćmy do tego przykładu aplikacji logistycznej. Tutaj temat powiedzmy jakoś tam mam rozpoznane, ale ekspertem nie jestem. Jestem sobie w stanie wyobrazić, że np. wartością dodaną jest błyskawiczne zlecanie i przyjmowanie zleceń, szybsze niż do tej pory to jest realizowane.
[ 00:08:37] Piotr Lewandowski: Wracając może do podstaw, żeby przybliżyć pojęcie.
[ 00:08:41] To wartość dodana to jest coś, co człowiek dostaje używając naszej aplikacji, korzyść, którą dostaje, którą normalnie by nie miał np. postępując w tradycyjny sposób.
[ 00:08:53] Np. dostaje szybkość dostępu dzięki temu, że ma to na aplikacji.
[ 00:08:57] Grzegorz Papaj: Tą wartością dodaną może być wygoda, może być oszczędność czasu, może być oszczędność pieniędzy w pewnych sytuacjach, być może jakieś inne czynniki typu prestiż. Wiele rzeczy tutaj może wchodzić w grę. Wiele elementów może być wartością dodaną.
[ 00:09:13] Natomiast ta wartość dodana powinna być zdefiniowana.
[ 00:09:17] Przy czym to też nie zawsze jest tak, że wartość dodana jest najważniejszym i kluczowym elementem. To ma prawdopodobnie trochę większe znaczenie, kiedy wchodzimy w taką sferę start-up ową, kiedy faktycznie chcemy zrobić coś takiego bardziej nowatorskiego.
[ 00:09:38] Czasem ta wartość dodana jest troszkę trudniej uchwytna.
[ 00:09:47] Piotr Lewandowski: W dużych organizacjach wartością dodaną często jest możliwość ogarnięcia złożoności.
[ 00:09:53] Mamy jakiś proces. On w wersji papierowej nie działa, bo tego papieru jest dużo. Oddziałów w firmie też jest dużo, pracowników jest dużo i sama digitalizacja pozwala zarządzać złożonością i zmniejszyć jakiś tam stopniu złożoności. To jest taka mniej oczywista dla niektórych być może wartość.
[ 00:10:11] Grzegorz Papaj: Pytanie też, dla kogo ta wartość dodana. Bo jeśli zmuszamy pracownika do korzystania z systemu, to on musi ponieść jakiś wysiłek. To nie jest proste. Natomiast wartość dodana może być dla zarządu firmy, bo dostarcza to jakiś danych, raportów bardzo cennych.
[ 00:10:28] Więc ta wartość dodana nie zawsze jest oczywista i nie zawsze dla każdego. Natomiast dobrze, żeby była.
[ 00:10:33] Piotr Lewandowski: Nie zawsze jest oczywisty beneficjent takiego systemu.
[ 00:10:36] Grzegorz Papaj: Tak naprawdę najistotniejsze w każdej definicji każdej aplikacji jest nakreślenie jakiegoś problemu, który chcemy rozwiązać.
[ 00:10:45] No chyba, że mówimy o aplikacji typowo rozrywkowej. To trochę inna przestrzeń. Tutaj powiedzmy rozwiązywanie problemów to raczej byłoby trochę definiowanie na siłę.
[ 00:10:59] Siedzę sobie, myślę o tej aplikacji mobilnej. Nadal jestem taki niepewny co do swojego pomysłu. Boję się do was odezwać.
[ 00:11:09] Czy powinienem najpierw może usiąść, zrobić mockupy? Mockupy, czyli takie projekty ekranów albo projekty tego, jak to miałoby wyglądać na telefonie, zanim się do was odezwę.
[ 00:11:19] Może to by pomogło trochę, bo cały czas jestem taki niepewny, czy już mogę się do was zgłosić i porozmawiać o pomyśle, czy jeszcze nie.
[ 00:11:28] Grzegorz Papaj: To może zacznę od tego, że mockupy w tej chwili są dosyć popularne.
[ 00:11:34] Jest cała masa narzędzi typu Figma, które pozwalają na tworzenie mocków dosyć łatwo.
[ 00:11:40] Piotr Lewandowski: Osobom, które nawet nie są zaawansowane techniczne. Nie trzeba być magikiem Photoshopa, żeby coś takiego wyklikać.
[ 00:11:47] Grzegorz Papaj: Dokładnie tak.
[ 00:11:48] I w związku z tym wiele osób z tego korzysta.
[ 00:11:52] Czy to jest konieczne? Na pewno nie. Czasem wystarczy porozmawiać. Na mockupy przyjdzie czas trochę później.
[ 00:12:00] Czy to jest pomocne? Bywa. Bywa, ale nie zawsze.
[ 00:12:05] To znaczy zdarzają się sytuacje. Mamy takich potencjalnych klientów czy klientów, z którymi rozmawiamy, którzy przychodzą do nas z tym mockupem, czasem bardzo rozbudowanym, dopracowanym w szczegółach, z pięknymi czcionkami, obrazkami.
[ 00:12:20] Natomiast w tym wszystkim czasem ginie sedno, czyli to, o czym mówiliśmy przed chwilą. Czyli ja patrzę sobie na taki mockupy i mam się domyślić, o co chodzi. W jakimś zakresie pewnie się mogę domyślać, ale nie zawsze to jest oczywiste.
[ 00:12:35] Jednocześnie ten, kto przyszedł do nas z mockupem, ma takie poczucie, że się napracował, często zasadne. Zrobił dobrą robotę, coś nam pokazał.
[ 00:12:43] Natomiast do czego zmierzam? Mockup na pewno nie jest wystarczający, żeby zdefiniować aplikację.
[ 00:12:52] O tym trzeba jeszcze porozmawiać, zrozumieć o co chodzi. I znów wracamy do tych problemów, do kontekstu itd.
[ 00:12:59] Może przesadzam, może są sytuacje w przypadku prostych aplikacji mockup może mówić sam za siebie, może nie wymagać jakiś dodatkowych szczegółów. Widząc mockup kalkulatora możemy się domyślić o co chodzi.
[ 00:13:11] Po prostu mockup jest tak jak każde inne narzędzie może być przydatne, ale pod warunkiem, że się z niego dobrze korzysta.
[ 00:13:20] No bo tak jak mówię, widzieliśmy masę mocków, które czasem nawet wręcz zaciemniają obraz. Były dziesiątki ekranów, które przedstawiały logowanie, zmiany haseł. Takie, powiedzmy, podstawowe funkcjonalności, które są w każdej aplikacji.
[ 00:13:36] I w tym wszystkim, w gąszczu tych dziesiątków screenów mieliśmy sobie znaleźć ten właściwy element, tą właściwą funkcjonalność.
[ 00:13:44] Piotr Lewandowski: Tutaj ja na pewno miałbym wiele przykładów, kiedy na pewno taką złotą radą jest to, żeby nie myśleć zbyt wiele o logowaniu i rejestracji. To jest problem, który dawno został rozwiązany.
[ 00:13:57] Ludzie bardzo często lubią nad tym spędzać trochę czasu, żeby to projektować. To już warto zostawić w firmie programistycznej, żeby się tym zajęła. Ameryki tutaj nie odkryjemy. Możemy tylko poświęcić zbyt wiele czasu.
[ 00:14:13] I to, co powiedziałeś, że warto do tych mocków podejść tak, że tworzymy, ale też nie prze inwestować czasu na nie.
[ 00:14:24] Trzeba poświęcić ten czas na pomyślenie o procesach, które mają być w aplikacji. Co i jak mają działać pod spodem rzeczy. Jak wygląda sam proces biznesowy, czyli jakie dane zbieramy?
[ 00:14:37] Różne rzeczy związane z działaniem aplikacji, a nie tylko związane z wyglądem.
[ 00:14:44] Na pewno na pewnym etapie, dobrze zachować zdrowe proporcje przy projektowaniu.
[ 00:14:50] Grzegorz Papaj: To ja uzupełnię, że my stosujemy nierzadko mockupy podczas analizy, sami je robimy, bo to jest super użyteczne narzędzie w rozmowie z klientem. Pokazujemy naszą wizję produktu, to nam pomaga uzyskać tą pewność, że klient myśli dokładnie o tym samym.
[ 00:15:08] Natomiast są osoby, które zaczynają z mockupem i to ich po prostu wciąga, zaczynają dopracowywać to poświęcają masę czasu na detale.
[ 00:15:19] Spoko, to jest fajne. Natomiast. To nie zbliża nas tak naprawdę do rozwiązania.
[ 00:15:26] Najpierw aplikacja musi działać, a potem może być piękna. Chyba tak bym to podsumował.
[ 00:15:32] Piotr Lewandowski: Też też się z tym zgadzam. Na początek najtrudniejsze problemy, a potem sobie jedziemy z przyjemnościami.
[ 00:15:40] Tak jak już mówiłeś o tym, że wy tworzyć trochę tych mockupów na etapie analizy.
[ 00:15:45] To właśnie taki problem. Czy ja muszę tę specyfikacje sam wytworzyć? Czy wy pomagacie w czymś takim? W tym procesie tworzenia specyfikacji.
[ 00:16:00] Grzegorz Papaj: Pomagamy. To chyba taka najkrótsza odpowiedź.
[ 00:16:04] Oczywiście, jeśli ktoś jest w stanie coś samemu stworzyć, ma chęci i możliwości, umiejętności, to jak najbardziej. Chętnie się zapoznamy z taką specyfikacją.
[ 00:16:16] Często wręcz doradzamy klientom, którzy do nas dzwonią i mają jakiś taki bardzo niejasno określony pomysł, żeby usiedli sobie, spisali jak oni to widzą i nam wysłali.
[ 00:16:26] Czasem w rozmowie widać po prostu, że dany klient jeszcze nie do końca ma dopracowaną wizję produktu i w momencie, kiedy siada do tego, zaczyna sobie spisywać wszystkie funkcjonalności i sposób działania, pewne kwestie zaczynają się wyjaśniać.
[ 00:16:48] Podczas rozmowy widać, że klient nie zawsze potrafi jasno określić wszystkie swoje potrzeby i pomysły. Także spisanie przez klienta jakiejś formy specyfikacji nie musi być długa.
[ 00:17:01] Nawet w kilku zdaniach pomaga klientowi sobie ułożyć temat w głowie.
[ 00:17:05] Jeżeli coś takiego dostajemy, to może być proste. To może być krótkie. Nawet wolimy, żeby było proste i krótkie, ale przedstawiało te najważniejsze elementy, czyli problem i jakieś podejście do jego rozwiązania plus całą otoczkę, kontekst.
[ 00:17:18] My wtedy jesteśmy w stanie sobie wytworzyć jakąś wizję roboczą, rozwiązania, którą potem sobie z klientem rozbudowujemy już podczas rozmów.
[ 00:17:28] Na początku są takie wstępne rozmowy, które prowadzą do tego, że gdzieś tam podajemy mniej lub bardziej dokładne oszacowanie.
[ 00:17:35] A później, jak już przychodzi do takiej właściwej analizy, powstaje z tego zwykle jakiś dokument analityczny.
[ 00:17:42] Tak więc taka prawdziwa specyfikacja powstaje w momencie, kiedy klient już zaczyna współpracę z nami.
[ 00:17:48] Natomiast na wcześniejszych etapach ta specyfikacja w postaci dokumentu jest pożyteczna, jest pomocna, ale nie jest wymagana.
[ 00:17:57] W związku z tym nie wymagamy od klientów, żeby tworzyli długie, rozbudowane dokumenty. Nam wystarczy krótki, krótki opis.
[ 00:18:07] Piotr Lewandowski: Teraz takie pytanie, które do mnie często przychodzi jako działu technicznego. I się często zdarza.
[ 00:18:13] Skąd mam wiedzieć, czy mój pomysł da się w ogóle zrealizować?
[ 00:18:19] Grzegorz Papaj: Najlepiej nas o to zapytać. To jest dobry sposób.
[ 00:18:27] Dlaczego warto o to pytać?
[ 00:18:29] Pewne klasy rozwiązań są dosyć proste. To znaczy są pewne grupy, aplikacji, co do których wiadomo, nie ma wątpliwości, że można je zrobić od strony technicznej.
[ 00:18:42] W tej chwili pomijam aspekty finansowe, ale od strony technicznej wiele rzeczy da się zrobić. Jeżeli coś jest podobne do Allegro, to znaczy, że można to zrobić tak w pewnym przybliżeniu.
[ 00:18:52] Piotr Lewandowski: Jak tutaj zlokalizować takie rzeczy, którymi warto się podzielić i o które dopytać.
[ 00:18:58] Gdzie szukać tych trudniejszych, problemów?
[ 00:19:04] Grzegorz Papaj: Może powiem gdzie są właśnie te trudności, czego się nie da zrobić?
[ 00:19:14] Zdarza się, że są klienci, którzy przychodzą do nas i chcą rozwiązywać problemy, o których wiemy, że są nierozwiązywalne.
[ 00:19:22] Jako przykład mogę podać aplikację do przewidywania kursów giełdowych. Myślę, że co kilka, kilkanaście miesięcy dostajemy tego typu zapytania.
[ 00:19:36] Są też aplikacje, co do których wiadomo, że nie możemy zagwarantować optymalnego rozwiązania, bo to, że się powiedzmy rozwiązuje dobrze problem heurystyki. Tam w 99% przypadków oznacza, że ten 1% może być zupełnie z kosmosu. Ale to jakieś tam kwestie.
[ 00:19:55] Zdarzają się też inne ograniczenia narzucone przez platformy, na których mamy pracować. Jeżeli mówimy o aplikacjach mobilnych, to zwykle to jest Android i iOS i ograniczenia narzucone przez Google i Apple powodują, że pewnych rzeczy nie da się zrealizować.
[ 00:20:14] A przynajmniej nie da się. Jeśli się zrealizuje, nie da się tego puścić do dystrybucji przez sklepy.
[ 00:20:21] I to są wszelkie np. wszelkiego rodzaju funkcjonalności związane z potencjalnym naruszeniem prywatności, czyli np. tematy do kontroli rodzicielskiej.
[ 00:20:33] Takie tematy co jakiś czas wracają i w pewnym zakresie da się to zrobić w ramach polityki AppStore czy Google Play, ale z reguły klienci pytają o funkcjonalności, które daleko przekraczają to, na co te polityki pozwalają.
[ 00:20:50] Piotr Lewandowski: Które być może da się zrobić, ale tylko jeżeli mamy jakąś większą relację partnerską z Googlem czy Applem.
[ 00:20:55] Drugi przykład to jest temat, który u nas ostatnio cały czas powraca. Google i Apple coraz mocniej domykają politykę jeżeli chodzi o jakieś wybudzanie aplikacji, jeżeli chodzi o jakieś alarmy, jeżeli jesteśmy w trybie wyciszonym.
[ 00:21:10] Jest tam pewne pole, pewne rzeczy da się zrobić, ale też jest coraz więcej funkcjonalności, które się zamykają, których nie da się zrobić bez jakiegoś statusu partnerskiego z tymi korporacjami.
[ 00:21:23] To się cały czas zmienia i trochę dostajemy takich zapytań, że ktoś miał jakąś aplikację, ona do którejś wersji Androida/iOS działała i teraz zaczyna się coraz więcej problemów z nią.
[ 00:21:35] Grzegorz Papaj: No i oczywiście definiując to, co jest możliwe, a co nie jest możliwe. Trzeba wziąć pod uwagę również budżet.
[ 00:21:44] Bo są pewne kwestie, które są możliwe, ale wymagają bardzo dużych nakładów finansowych.
[ 00:21:48] Czyli mówiąc krótko: w małym budżecie nie jest możliwe zrobienie dużej aplikacji. To są już powiedzmy, kwestie, które dyskutujemy indywidualnie z klientami.
[ 00:22:00] Piotr Lewandowski: Jeszcze inna kategoria to są właśnie takie wyzwania naukowo technologiczne, bym powiedział, których po prostu pewnego pewnemu profilowi klientów bym nie polecił.
[ 00:22:12] Np. nie poleciłbym zakładać kolejnego Googla, jeżeli nie jestem osobą techniczną, matematyczną, programistyczną, a jedynie biznesową.
[ 00:22:23] Grzegorz Papaj: To jak już w tym kierunku idziemy, to w ogóle mamy klasę projektów. Trochę też tego robiliśmy, które z definicji są po prostu projektami badawczymi, których celem nie jest stworzenie czegoś, jakiejś funkcjonalności, jakiejś aplikacji. Na pewnym poziomie jest natomiast, ale wszyscy z góry wiedzą, że to się może nie udać.
[ 00:22:45] Piotr Lewandowski: Studium wykonalności.
[ 00:22:47] Grzegorz Papaj: Studium wykonalności. Albo osiągnięcie pewnych konkretnych pułapów skuteczności w jakiejś dziedzinie.
[ 00:22:55] To są te aspekty, co do których wiadomo, że nie możemy dawać gwarancji. Często jest tak, że wiadomo, że można coś usprawniać, ale nie wiadomo jak bardzo i nie wiadomo jakim nakładem czasu i kosztów.
[ 00:23:10] Piotr Lewandowski: OK, to jak już chcieliśmy zakładać Google, to teraz zejdźmy może trochę bardziej na ziemię do przyziemnych spraw.
[ 00:23:17] Jakie platformy? Android, iPhone? Na jakie dzisiaj z tych dwóch platform pisać aplikacje według Ciebie.
[ 00:23:26] Grzegorz Papaj: Najlepiej na obie. To wygląda w ten sposób, że aktualnie chyba każdy, kto chce stworzyć jakąś liczącą się aplikację zakłada stworzenie wersji na obie platformy.
[ 00:23:43] No chyba, że mówimy o jakichś sytuacjach wyjątkowych. Ktoś celuje w użytkowników Appla, to nie będzie tworzył wersji Android owej. Albo mówimy o rozwiązaniu korporacyjnym, gdzie firma po prostu dostarcza wszystkim swoim pracownikom telefony z tej czy innej półki. No to w takiej sytuacji to są wyjątki.
[ 00:24:02] Natomiast aktualnie sytuacja wygląda tak, że tak naprawdę stworzenie aplikacji na dwie platformy, czyli na iOS i Android, te dwie dominujące na rynku, nie jest dużo droższe niż stworzenie aplikacji na jedną z nich.
[ 00:24:18] Tz. jakby to tak porównać to jest powiedzmy 10, 20, może 30% drożej zrobić aplikację korzystając z technologii React Native czy Flutter i ona działa od razu na obu platformach.
[ 00:24:35] Jest o 30 maksymalnie procent drożej niż stworzenie aplikacji na jedną platformę. Patrząc na to z drugiej strony, mamy tu oszczędność gdybyśmy mieli zrobić aplikację niezależnie w technologiach natywnych na obie platformy, to wchodząc do React Native czy Flutter czy innych rozwiązań, zyskujemy 70-80% czasu i kosztów na realizacji.
[ 00:25:14] Piotr Lewandowski: Czy poza tymi dwoma platformami widzisz ostatnio na rynku coś wartego uwagi?
[ 00:25:21] Grzegorz Papaj: Inne niż iOS i Android?
[ 00:25:23] Piotr Lewandowski: Tak.
[ 00:25:26] Grzegorz Papaj: Jest cała masa różnych platform.
[ 00:25:31] Piotr Lewandowski: Są to są, ale czy są jakieś…
[ 00:25:33] Grzegorz Papaj: Realnie rzecz biorąc nie ma na rynku nic wartego uwagi z biznesowego punktu widzenia. Tak bym to chyba podsumował.
[ 00:25:42] Są pewne projekty, które mogą być ciekawe z różnych względów, czy to ideowych, czy technologicznych. Ale tak naprawdę już od wielu lat nikt nie jest w stanie się przebić.
[ 00:25:53] Były próby, Microsoft próbował wychodzić ze swoją platformą.
[ 00:25:58] BlackBerry, działało w niszy przez długi czas, ale w zasadzie zniknęło.
[ 00:26:05] Ostatnia próba, którą pamiętam, wśród takich większych graczy to Huawei próbował wypromować swoją platformę Harmony OS. To też nie spotykało się z jakimś większym pozytywnym odbiorem.
[ 00:26:25] Był taki moment, że przychodzili do nas klienci i pytali nas, czy my robimy też aplikacje na platformę Huawei. To się nazywało AppGallery, ale to w zasadzie jest po prostu sklep alternatywny do Google Play, w którym są aplikacje Androida.
[ 00:26:44] To była jakaś tam powiedzmy koncepcja.
[ 00:26:48] Piotr Lewandowski: Czyli to technologicznie się mocno nie różniło. Bardziej był to po prostu inny sklep.
[ 00:26:54] Grzegorz Papaj: Inny sklep. Dokładnie tak.
[ 00:26:58] Piotr Lewandowski: Dziękuję za dzisiaj. Kończymy już.
[ 00:27:03] Do zobaczenia następnym razem.
[ 00:27:06] Grzegorz Papaj: Dziękuję.
Rozwiń całość