Mobile dla Menedżerów

Poniżej znajduje się cała treść mojej książki “Mobile dla Menedżerów”. Minęły 3 lata odkąd ją wydałem. Skończyły się już ograniczenia licencyjne, a więc postanowiłem ją otworzyć i udostępnić dla wszystkich chętnych. Wersja PDF znajduje się tutaj.

A tutaj możecie poczytać o tym jak zdobyć ostatnie sztuki papierowego wydania i jednocześnie zrobić coś dobrego.


Wstęp

- Mobile to przyszłość! — otworzył dyskusję prezes — A moją ambicją jest tworzyć przyszłość. Dlatego to właśnie ty zajmiesz się stworzeniem naszej pierwszej aplikacji mobilnej!

Oczywiście, że ja! — powiedziałem sobie w duchu, ale tylko trochę sarkastycznie. Nikomu nie umniejszając, ale to ja wiem o tym najwięcej w naszej firmie — spojrzałem szybko po reszcie zgromadzonych, aby upewnić się, że połowa odpada w przedbiegach, bo nawet nie ma smartfona.

Ale dlaczego ja? Jasne, że mam smartfon, ale dlatego, że mi operator dał w dobrej promocji, a ja lubię gadżety. Tak, korzystam z kilku aplikacji, marzy mi się mój własny startup (i czytam Techcruncha), ale to wszystko w mojej bezpiecznej bańce wyobraźni. Widocznie szef stwierdził, że to sensowny ruch — ktoś, kto ma u nas wprowadzać innowacje, nie może być zachowawczy i konserwatywny.

Teraz, w polskich małych, średnich i dużych firmach, odbywają się na spotkaniach zarządu takie właśnie dyskusje. Setki lub nawet tysiące ambitnych menedżerów wpatrzonych w przyszłość dostaje na barki zupełnie nowe zadanie: stworzyć aplikację mobilną. Ale najpierw muszą wymyśleć plan, obronić go przed zarządem i na końcu wyegzekwować realizację, co ostatecznie ma zaowocować stworzeniem nowego kanału przychodu dla firmy.

Z tym wiąże się zazwyczaj awans, lepsza pensja, większa władza i nowe obowiązki. Początkowa duma jednak powoli zaczyna zmieniać się we frustrację.

Skąd wziąć wiarygodne informacje? Gdzie czerpać wiedzę o rynku, procesach, metrykach? Do kogo się porównywać?

Byłem w tej sytuacji sześć lat temu, gdy rozpoczynałem moją karierę w branży technologicznej. Moją rolą było przeprowadzenie eksperymentalnego projektu mobilnego inspirowanego podobnym, zachodnim rozwiązaniem — zanim pojawi się na polskim rynku.

Miałem minimalne przygotowanie do tej roli, ale zostałem wybrany ze względu na szeroką fascynację Internetem i nowymi mediami. To jednak w żaden sposób nie predestynowało mnie do roli menedżera produktów mobilnych — ale do takich wniosków mogłem dojść dopiero po kilku latach i szczerej analizie własnych błędów.

Frustrowało mnie to, że nie mogłem zdobyć wiarygodnej wiedzy o polskim rynku mobilnym, specyfice projektowej, procesie programowania aplikacji. Nie miałem wystarczającej ilości danych, aby podejmować merytoryczne decyzje.

Dlatego traktuję książkę, którą czytasz, jako podręcznik dla siebie samego sprzed sześciu lat. Opisuję w niej wszystko to, co powinienem wiedzieć wtedy, abym mógł przygotować się na to, co mnie czeka, zrozumieć moją sytuację i zminimalizować liczbę błędów, które popełniłem.

Od tamtej pory miałem przyjemność uczestniczyć w kilkudziesięciu projektach mobilnych; tworzyłem lub współtworzyłem między innymi pierwszy polski system kuponów mobilnych, ogólnopolskie kampanie reklamy mobilnej, najlepiej ocenianą aplikację sieci telekomunikacyjnej i zarządzałem flotą aplikacji mobilnych topowej polskiej grupy internetowej. W ramach własnej firmy odpowiadamy, między innymi, za rozwój aplikacji największego polskiego dostawcy jedzenia na zamówienie, który należy do międzynarodowego rynkowego lidera.

Jak widać, miałem sporo okazji, by popełniać błędy.

Moje podejście i cel

Jeden z moich znajomych inwestorów zapytany, dlaczego swój kapitał i czas poświęca na nowe technologie, odpowiedział, że to jest dziedzina, w której w najkrótszym czasie da się zbudować największą wartość.

Jeśli mielibyśmy spojrzeć do środka tego, co nazywamy „nowoczesnymi technologiami”, i przyjęlibyśmy podobny tok myślenia, to według mnie „mobile” jako zbiór technologii i metod jest na górze listy rzeczy, które w najkrótszym czasie tworzą największą wartość.

Ma to dwa aspekty: makro i mikro.

Makro: z perspektywy firm zainwestowanie w mobile jest prawdopodobnie jednym z najlepszych sposobów na budowanie przewagi konkurencyjnej. Firmy, które wiedzą, jak tworzyć ten kanał przychodów i/lub optymalizować procesy dzięki mobile’owi, są o jeden krok przed konkurencją. Tworzy się też dzięki temu perspektywiczny rynek dla firm usługowych i konsultantów specjalizujących się w tej dziedzinie.

Mikro: znajomość technologii, środowiska, zarządzania projektami mobilnymi to niezwykle pożądana i ceniona rynkowo umiejętność. Nie znam nikogo, kto, zdobywając doświadczenie obok mnie lub ze mną, w mobile’u, miałby problemy ze znalezieniem pracy. Specjaliści w tym zakresie są wyławiani bardzo szybko.

Celem tej książki jest dostarczenie jak najpełniejszej wiedzy o wdrażaniu strategii mobilnej w nowoczesnej firmie. Efektem tej strategii jest zazwyczaj aplikacja mobilna, ale aby do tego mogło dojść, trzeba zrozumieć, jakie kompetencje są potrzebne, jakie są uwarunkowania rynkowe oraz jak przeprowadzić i odebrać projekt mobilny.

Książka jest tak stworzona, aby w dowolnym momencie można było sięgnąć po potrzebny rozdział. Każda jej część może być traktowana jako niezależna całość, choć zalecam czytanie po kolei ze względu na zwiększający się poziom skomplikowania i zależności między fragmentami. Czasami podczas czytania mogą pojawić się niejasne na początku określenia — często są one wyjaśniane w dalszych rozdziałach. Musiałem w tych wypadkach poświęcić łatwość przyswajania treści na rzecz zgodności z merytoryką. Wszystkie ważne skróty są wyjaśnione w słowniku na końcu książki.

Po lekturze będziesz dysponować wystarczają wiedzą, aby przeprowadzić projekt i współtworzyć z zespołem produkt mobilny. Oczywiście każdy projekt jest inny, a wiedza, którą tutaj przekazuję, wynika z subiektywnej interpretacji faktów, ale zauważyłem, że moje wnioski są w miarę uniwersalne i sprawdzały się niezależnie od tego, czy prowadziłem projekt w małej, średniej czy dużej firmie, z branży reklamowej, technologicznej czy usługowej, a także niezależnie od roli, jaką pełniłem w projekcie. Nie mogę jednak powiedzieć, że to, co napisałem, wyczerpuje temat — jest to raczej przewodnik po najważniejszych kwestiach związanych z technologiami i biznesem mobilnym.

Szkicując sobie koncept tej książki, miałem w głowie trzy grupy, do których kieruję jej treść:

- menedżer średniego szczebla spoza branży mobile, który dostał za zadanie zrobić pierwszy krok dla swojej firmy w tym świecie. Uznaje to jednocześnie za wielką szansę dla siebie, ale to także sprawdzian jego umiejętności adaptacyjnych. Chcąc zbudować dobry produkt, czuje presję swoich przełożonych i jednocześnie widzi, jak mało jest wiarygodnych danych i merytorycznych analiz, z których można wyciągnąć racjonalne wnioski,

- właściciel startupu, który czuje podwójną presję, by mądrze zbudować swój produkt mobilny: ze strony rynku i inwestorów. Zaczyna od początku, ma wolność decydowania o swoim produkcie, nie jest obarczony wcześniejszymi rozwiązaniami, może wszystko zrobić lepiej niż konkurencja — pytanie tylko, co to znaczy lepiej? Jak zbudować przewagę konkurencyjną dzięki mobile’owi?

- pracownik, który zdobywa doświadczenie w branży „digitalowej”. Widzi, że wszyscy powoli zaczynają mówić o mobile’u, o tym, że każdy następny rok to właśnie rok mobile’a. Jego klienci też to widzą i coraz częściej pytają o to, co można zrobić w tej przestrzeni. Skąd to wiedzieć? Na co się powołać? Jak nadążyć za tym trendem i mieć realne odpowiedzi na zapytania klientów?

Takie osoby najwięcej skorzystają na mojej książce. Choć staram się pisać treści dla czytelników o różnym poziomie doświadczenia, to pełne zrozumienie idei i procesów tutaj opisanych wymaga przynajmniej minimalnego doświadczenia w zarządzaniu projektami i produktami technologicznymi.

Niemniej uważam, że dużo z tej książki mogą nauczyć się także studenci, którzy chcą wejść na rynek pracy z przygotowaniem merytorycznym — tacy, których pasją od samego początku były smartfony i którzy uwielbiali rozkładać na czynniki pierwsze sposoby działania ulubionych aplikacji.

Gdzie jest to tylko możliwe, bazuję na danych i faktach z własnego doświadczenia w mojej pracy — jako product manager w ArboMedia / Goldbach Interactive, szef LoveMobile, szef produktów mobilnych Grupy o2 i jako członek zarządu Senfino Software House. Wiele z tych informacji było pierwotnie objętych umowami o zachowaniu poufności, ale dostałem zgodę klientów na ich publikację, za co bardzo im dziękuję — przyczyniają się dzięki temu do zwiększania transparentności rynku.

W dalszej kolejności korzystam z wiedzy i doświadczeń zgromadzonych w rozmowach z innymi członkami rynku — zarówno po stronie klientów, jak dostawców rozwiązań technologicznych. Nasza branża jest bardzo mała i osoby, które faktycznie mają doświadczenie i potrafią się nim dzielić, można zmieścić w jednej sali wykładowej, co faktycznie się stało podczas szkolenia AppAcademy — pierwszych w Polsce kursów tworzenia aplikacji mobilnych, których miałem okazję być współorganizatorem.

Następne źródło wiedzy to słuchacze moich warsztatów i wykładów. Ta książka powstała przede wszystkim na kanwie serii prezentacji, które przedstawiałem na przestrzeni ostatnich trzech lat, oraz dyskusji, jakie odbyłem ze słuchaczami.

Następne źródło to badania i raporty oparte na bezpośrednich danych i statystykach rynkowych publikowanych w formie case’ów branżowych w książkach, na blogach firmowych, w raportach i przytaczanych na konferencjach w Polsce i zagranicą. Te dane są trudne do niezależnego osobistego zweryfikowania, dlatego znajdują się niżej na liście wiarygodności źródeł.

Ostatnim i najmniej wiarygodnym źródłem są dla mnie badania deklaratywne. Korzystam z nich tylko po to, aby pokazać kontekst, i zawsze zaznaczam, że te dane mogą nieopatrznie wprowadzać w błąd. Badania deklaratywne są złym rozwiązaniem do opisania polskiego rynku mobilnego z wielu powodów, ale najważniejszym z nich jest niska świadomość technologiczna polskich użytkowników smartfonów. Ich deklaracje bardzo łatwo „odklejają się” od stanu faktycznego — na przykład przy definiowaniu, czy są właścicielami smartfona (dla większości z nich to po prostu telefon z dotykowym ekranem).

Chcę, aby ta książka pomogła budować dobre produkty mobilne, ale znacznie ważniejsze jest dla mnie poczucie, że dzięki niej czytelnik rozszerzy swoją wiedzę i zdobędzie umiejętności, które pomogą mu zawodowo.

Mobile to świeża dziedzina, co oznacza, że szybko można osiągnąć wystarczającą wiedzę, a dostęp do doświadczonych ludzi i dobrych źródeł jest bardzo prosty. Jesteśmy więc w sytuacji, w której już jest duże zapotrzebowanie na usługi specjalistów od mobile’a, a jednocześnie jest jeszcze niska bariera wejścia. Zajęcie się mobile’em profesjonalnie to prawdopodobnie jedna z lepszych decyzji, jakie można zawodowo podjąć.

Rozdział 1 Rynek i mobile

Krajobraz

Nowoczesny rynek mobile rozpoczął się w 2007 roku po premierze pierwszego iPhone’a. Obecnie, osiem lat później, około 22% ludzi na całym świecie ma telefon, który można zdefiniować jako smartfon[1]. W połowie 2012 roku było na świecie więcej smartfonów niż komputerów stacjonarnych.

Zaraz po smartfonach swoją premierę miały tablety (z iPadem na czele) — uznawane za jedną z najszybciej zaadaptowanych technologii: w USA nasycenie rynku do 10% zajęło tabletom 2,5 roku. Dla porównania w wypadku smartfonów trwało to 6 lat, w wypadku internetu — 9 lat, a elekryczności — aż 30 lat[2].

Polska dołączyła do tego trendu z opóźnieniem. Według IAB (Interactive Advertising Bureau — Związek Pracodawców Branży Internetowej — przyp. red.) w pod koniec 2014 roku nasycenie smartfonami w naszym kraju wyniosło 60%. Patrząc na ekran smartfona, spędzamy 90 minut dziennie (dla porównania — w telewizor patrzymy 98 minut dziennie)[3].

W Polsce Android instalowany na urządzeniach mobilnych (czyli smartfonach i tabletach) jest trzecim najpopularniejszym systemem operacyjnym po Windows 7 i Windows XP. W przypadku Apple jego mobilny system operacyjny (iOS — 3,33%) ma trzy razy większy udział rynkowy niż stacjonarny (OSX — 1,14%). Udział Androida w przeciągu 3 ostatnich lat wzrósł dwunastokrotnie, a iOS-a pięciokrotnie — gdy w tym samym momencie rodzina systemów Windows spadła z 96% udziału w rynku do 80%[4].

Co to oznacza? Jesteśmy świadkami niewidzialnej rewolucji. W przeciągu zaledwie kilku lat nastąpiła zmiana tak szybka, że uznaliśmy ją za oczywistość. Jeszcze niedawno posiadanie najnowszego smartfona było snobizmem — obecnie nie da się przejechać komunikacją miejską, aby takiego nie zobaczyć.

W 2013 roku byłem poproszony o stworzenie analizy przyrostu udziału mobilnej konsumpcji treści w kilku największych serwisach contentowych w Polsce należących do jednej grupy mediowej. Ta analiza miała później posłużyć jako podstawa do określenia przyszłościowych trendów i rozwoju segmentu. Mimo że staram się nie ulegać hurraoptymizmowi, to i tak uważałem, że wzrosty będą większe niż średnia rynkowa oraz te odnotowane przez analogiczne serwisy sprzed kilku lat w USA i Wielkiej Brytanii. Mimo to pomyliłem się znacznie, a mój następca do tej pory przypomina mi, jak nisko oceniłem potencjał polskiego rynku.

Kluczowymi graczami na rynku smartfonów są trzy firmy: Apple, Google i Microsoft. Każda z nich ma inną strategię walki o rynek, można je tak uogólnić:

Apple

Smartfon jako oznaka statusu. 
Spójny i kontrolowany przez Apple ekosystem. Użytkownicy o wysokim statusie materialnym.

Google

Smartfon jako wielofunkcyjne narzędzie. Otwartość, uniwersalność, swoboda wyboru. Użytkownicy budżetowi lub bardzo wymagający.

Microsoft

Smartfon jako rozszerzenie istniejącego systemu. Budowanie połączonego środowiska. Użytkownicy w centrum, kraje rozwijające się

Pod względem udziału rynkowego niemal całkowitą dominację ma Android dzięki przyjętej strategii otwartości i uniwersalności. System stworzony przez Google można znaleźć na telefonach Sony, LG, Samsunga, a nawet Amazona, co nie przeszkadza Google sprzedawać telefonów także pod własnym szyldem. Android to jednak system, który do swoich potrzeb może dostosować praktycznie każdy producent sprzętu — od telefonów po lodówki. W 2014 roku odnotowano prawie 19 tysięcy różnych rodzajów urządzeń z Androidem, z czego 43% wyprodukował Samsung, lider rynku[5].

Pracując przy analizie statystyk pewnego portalu przeglądałem najbardziej unikatowe wariacje przeglądarek mobilnych i proporcji ekranów i sprawdzałem je w tzw. „słowniku urządzeń”. Okazało się, że ten portal miał kilkanaście wejść przez czytnik kodów kreskowych z dostępem do Internetu.

Apple ma inne podejście. Przez swoją ścisłą kontrolę nad systemem iOS może sprawniej wprowadzać innowacje bez obaw o zdanie partnerów biznesowych i innych rynkowych graczy. W rezultacie to iPhone’y, których jest na rynku osiem razy mniej niż Androidów, określają od 2007 roku główne trendy rozwoju rynku smartfonów. To użytkownicy iOS więcej kupują na swoich smartfonach, na iOS odbywa się większość transakcji finansowych (podczas Black Friday w 2014 roku w USA około 22% wszystkich zakupów elektronicznych wykonano przez iOS, na Androidzie — około 6%)[6].

Microsoft ze swoim Windows Phone ewidentnie spóźnił się z wejściem na rynek smartfonów i nadrabia to, wchłaniając Nokię, która nie wytrzymała konkurencji Apple’a i Google. Będąc trzecią platformą, może pozwolić sobie na odważniejsze eksperymenty, czego efektem jest rewolucyjny kafelkowy interfejs Windows Phone. Prostota i niezwykła jakość w stosunku do ceny powoduje, że Windows Phone jest bardzo popularny w średnio rozwiniętych gospodarkach. W Polsce sprzedał się już prawdopodobnie 1 milion telefonów z Windows Phone, co efektywnie stawia tę platformę na drugim miejscu pod względem popularności — za Androidem[7]. Szacuje się, że w 2018 roku Windows Phone będzie stanowił 5,6% rynku[8].

Warto zwrócić uwagę na fakt, że platformę Android, dzięki jej otwartości, można podzielić na dwa segmenty: Google Android i Non-Google Android. W tej drugiej kategorii znajdują się specjalne dystrybucje systemu zmodyfikowane przez producentów smartfonów. I tak: Samsung ma swoją wersję Androida z nakładką TouchWiz i listą preinstalowanych aplikacji, jak S Voice, S Note czy AllShare. Analogicznie postępuje HTC ze swoją nakładką Sense oraz prawie każdy inny dostawca smartfonów z Androidem na pokładzie.

Tak samo Google Play nie jest jedynym sklepem z aplikacjami na Androidzie. Na przykład Samsung dysponuje swoim własnym Samsung Apps, który w większości krajów nie jest tak popularny jak oryginał, dzięki czemu pozwala na łatwiejszą promocję ze względu na mniejszą konkurencję aplikacji wewnątrz swojej platformy. Mało osób być może zdaje sobie z tego sprawę, ale także nowsze modele telefonów BlackBerry są w stanie uruchamiać aplikacje napisane dla Androida.

Ogromny popyt na smartfony spowodował zmianę społeczną i rynkową. Zmieniają się nasze przyzwyczajenia, inaczej zaczynamy myśleć o otaczającej nas technologii. To ma wielki wpływ na biznes, który musi dostosowywać się do nowych oczekiwań użytkowników.

Zmiana społeczna

Dlaczego tak bardzo pokochaliśmy nasze smartfony?

Bo stały się najbardziej osobistymi rzeczami, jakie posiadamy — po części dlatego, że mamy pełną władzę nad tym, czym są. Same w sobie są monolitycznymi, neutralnymi i ascetycznymi urządzeniami. Tak pomyślanymi, aby nie wchodzić użytkownikowi w drogę — mają być bowiem kształtowane według jego upodobań i wymagań.

Smartfon staje się dla użytkownika tym, co on widzi na ekranie. W jednym momencie jest aparatem do zdjęć, zaraz potem skrzynką pocztową lub sposobem na usłyszenie znajomej osoby. Dzięki elastyczności i uniwersalności smartfony stały się najbardziej osobistymi urządzeniami, którym powierzamy wszystko, co dla nas ważne. 80% użytkowników nie wyobraża sobie wyjścia z domu bez niego smartfona[9].

Smartfony szybko zmieniają konwenanse. Jeszcze w ciągu kilku lat od ich pojawienia się uznawano za niegrzeczne korzystanie z nich podczas rozmowy.

Abraham-Louis Breguet, jedna z najważniejszych postaci w historii zegarmistrzostwa, stworzył w 1799 roku montre à tact, czyli zegarek, dzięki któremu można było sprawdzić godzinę bez konieczności wyjmowania go z kieszeni. W tamtych czasach uznawano za bardzo nieuprzejme sprawdzanie godziny w obecności innych ludzi.

Obecnie jest już dla nas akceptowalne, że podczas spotkań prowadzimy jednocześnie nie tylko rozmowy z osobami obok nas, ale także z tymi, które „mamy w telefonach”, lub wykorzystujemy smartfony do katalizowania rozmowy, sprawdzając poruszony w konwersacji fakt na Wikipedii bądź wyszukując najbliższe kino.

Krytycy tego trendu ostrzegają, że uzależnienie od smartfonów alienuje nas społecznie. Im więcej patrzymy się w ekrany, tym mniej rozmawiamy z ludźmi dookoła nas i tym bardziej jesteśmy zdystansowani od świata, który nas otacza.

Takie same jednak argumenty podnoszono na przełomie XIX i XX wieku, narzekając na zmiany społeczne wynikające rozwoju telegramów zabijających sztukę pisania listów czy na radio, które miało być nieuczciwą konkurencją dla koncertów symfonicznych na żywo.

Stanley Kubrick w 1946 roku pracował jako fotograf w Nowym Yorku. Jedno ze zdjęć, które wykonał, przedstawia wagon nowojorskiego metra, w którym wszyscy pasażerowie są wpatrzeni w papierowe gazety[10]. Zupełnie tak samo, jak wszyscy podróżni teraz wpatrują się w swoje smartfony.

Stanley Kubrick. Life and Love on the New York City Subway. Passengers reading in a subway car. 1946. Museum of the City of New York. X2011.4.10292.30D

Zawsze włączony, zawsze blisko

Dostęp do szybkiej sieci mobilnej oraz urządzenia wystarczająco szybkie, aby móc pokazywać pełne strony internetowe, streamować treść wideo i zarządzać pocztą powodują, że stało się dla nas naturalne, że zawsze możemy sięgnąć po telefon, aby natychmiast zaspokoić swoją ciekawość. Sam dostęp do internetu mobilnego jest dla nas naturalny tak samo jak elektryczność.

Nasza więź z urządzeniami mobilnymi jest tak mocna, że odczuwamy pustkę i zaniepokojenie, gdy nie możemy z nich korzystać. W 2010 roku UK Post Office zleciło badanie, które wykazało, że 53% badanych Brytyjczyków jest poddenerwowanych, jeśli nie ma pod ręką swojego telefonu, jest on rozładowany bądź brakuje mu zasięgu. Według autorów badania takie zachowanie ma znamiona fobii i zostało nazwane nomophobiaod no-mobile-phone phobia[11].

Boimy się nie tylko tego, że możemy nie mieć dostępu do naszych telefonów, ale także tego, jaki będzie tego efekt. Takie zjawisko określa się jako Fear of Missing Out(FOMO).

FOMO to przeświadczenie, że coś ważnego nas omija, gdy nie jesteśmy online. Im więcej mamy urządzeń podłączonych do Internetu, tym mocniejsze poczucie, że kiedy nie mamy do niego dostępu, dzieje się właśnie coś ważnego, w czym nie bierzemy udziału. Smartfony i tablety spotęgowały FOMO w ironiczny sposób: nasze przyzwyczajenie do byciaalways onlinepowoduje, że czas bez smartfona w ręku lub kieszeni wydaje się anomalią.

Nasze korzystanie ze smartfonów w ciągu dnia to długa seria bardzo krótkich akcji. Średnio 150 razy dziennie zaglądamy do telefonu, sprawdzając ostatnie wiadomości, godzinę, nieodebrane połączenia i maile [12]. Wszystko to jednak robimy bez pełnego skupienia, „jednym okiem i jednym kciukiem”.

Tak o tym zjawisku mówi Luke Wroblewski, autor książki Mobile First[13]. Zauważył on, że większość naszych interakcji ze smartfonem jest „przy okazji” — na przykład podczas czekania na autobus, w przerwie w pracy, w kolejce w sklepie. Do tej czynności nie przykładamy pełnej uwagi tak jak do oglądania telewizji czy prowadzenia samochodu — zamiast tego ze smartfona korzystamy, trzymając go w drugiej (nieaktywnej) ręce i patrzymy na ekran z ograniczoną uwagą. Ma to swoje konsekwencje w podejściu do projektowania aplikacji mobilnych — przyciski powinny być większe, teksty krótsze, a palety barw bardziej kontrastowe.

Prywatność

Nauczyliśmy się, że naszą największą wartością, a w przyszłości walutą, jest prywatność. W dobie serwisów społecznościowych i narzędzi do masowej analizy danych osobowych jest ona z jednej strony na wagę złota, a z drugiej tak prosta do złamania, iż prawie bezwartościowa.

W „dużym” Internecie (tym, który widzimy po włączeniu przeglądarki internetowej na komputerze) mamy świadomość, że to, co ma być prywatne, kiedyś staje się publiczne, to, co ma być ukryte, zostaje pokazane. Dlatego mamy bardzo dużo obiekcji do pozostawiania po sobie śladów w postaci adresów mailowych, numerów telefonów, danych personalnych na stronach internetowych.

Smartfony jednak to zmieniają. To najbardziej osobiste rzeczy, jakie mamy, więc to, co na nich instalujemy, staje się automatycznie zwalidowane jako bezpieczne (przechodzi przecież też przez czujne oko producenta systemu operacyjnego i sprzętu), dlatego nie mamy problemu z dzieleniem się zdjęciami i danymi osobistymi.

Sprzedajemy naszą prywatność za wygodę. I choć brzmi to sarkastycznie, to jednak trzeba pamiętać, że ta wygoda jest realna i wartościowa. Pozwalamy aplikacjom mobilnym zbierać informacje o naszym położeniu geograficznym, aby te mogły zrozumieć kontekst, w którym się znajdują, i serwować lepiej dopasowaną treść, w tym także reklamy. Dzięki temu jednak, że mamy telefony z Androidem i pozwalamy Google na udostępnianie naszego położenia geograficznego, a oprócz nas robią to także miliony innych osób na całym świecie, to mamy coraz bardziej wiarygodne i dokładne dane o korkach i wypadkach na trasach samochodowych.

Zmiana rynkowa

W ślad za zmianą naszych przyzwyczajeń idzie także zmiana rynkowa.

W połowie 2014 roku Apple ogłosiło osiągnięcie 75 miliardów instalacji aplikacji z App Store[14]. Chwilę później Google Play przekroczyło poziom 50 miliardów[15].

Wraz z rozwojem rynku sprzętu i mobilnych systemów operacyjnych powstało pojęcie App Economydefiniowane jako zbiór aktywności ekonomicznych skupionych wokół aplikacji mobilnych.

Biorąc pod uwagę nie tylko bezpośrednie przychody z aplikacji, ale także te generowane przez zlecenia stworzenia aplikacji, m-commerce, inwestycje mobilne Venture Capital i usługi dla developerów, to szacuje się, że cały rynek mobilny był w 2013 roku wart 68 miliardów dolarów i osiągnie 143 miliardy dolarów w 2016 roku. W 2013 roku 1 na 8 developerów zajmował się projektami mobilnymi, co daje 2,3 mln osób[16].

Aby jednak App Economy mogła powstać, musiały zostać spełnione cztery zasadnicze warunki:

- moc obliczeniowa telefonów musiała stać się na tyle duża, aby móc obsłużyć m.in. nowy, o wiele czulszy niż dotychczas system interakcji dotykowej, renderować w wysokiej rozdzielczości pełnoekranowe strony internetowe i animacje 2D i 3D oraz szybko reagować na komendy użytkownika, dzięki czemu mogły rozwinąć się nowoczesne mobilne interfejsy,

- musiały powstać nowoczesne systemy mobilne, które wraz z upowszechnieniem sklepów z aplikacjami i podłączeniem kart kredytowej stworzyły zupełnie nowy, bezproblemowy i niezwykle szybki kanał dystrybucji aplikacji,

- infrastruktura telekomunikacyjna musiała na tyle się rozwinąć, aby móc gwarantować niemal ciągły dostęp do internetu mobilnego,

- smartfony musiały stać się popularne wśród użytkowników telefonów jako takich.

Zmiana rynkowa ma niebagatelny wpływ na sposób organizacji i działanie biznesu. Pojawia się bowiem nowy rodzaj konsumenta ze specyficznym zestawem oczekiwań. Szybkość reakcji i przygotowanie firm do tej zmiany można opisać w dziewięciostopniowej skali:

1. Brak świadomości — smartfony są wykorzystywane w życiu codziennym przez potencjalnych klientów, ale firmy tego nie zauważają.

2. Pierwsze testy- firmy, widząc zagraniczne przypadki wykorzystania mobile’a, starają się je naśladować, przeznaczając na to minimalne budżety (przykład: Frisco w warszawskim metrze[17] inspirowane działaniami Home Plus w Korei Południowej[18]).

3. Ostrożne wejście w rynek- firmy nie są gotowe, aby zainwestować w stworzenie mobilnego odpowiednika swojego produktu, ale zaczynają rozumieć przewagę, jaką może to może za sobą nieść, nawet jeśli konsumenci nie są jeszcze do tego przekonani. Powstają aplikacje „pomocniczne” (przykład: kupony zniżkowe Żabka).

4. Szlifowanie efektów- firmy i menedżerowie wyciągają wnioski z błędów popełnionych w etapach 2 i 3. Bogatsi o te doświadczenia zaczynają planować lepsze procesy i efektywniejsze sposoby monetyzacji klientów. Wersje mobilne serwisów contentowych ku zaskoczeniu wszystkich osiągają 10–15-procentowy udział wejść z urządzeń mobilnych — wciąż jednak nie widać odzwierciedlenia tego w budżecie na rozwój (przykład: polskie portale w latach 2010–2013).

5. Dział mobilny- mobile w firmie zaczyna być na tyle istotny, że powstaje specjalna komórka oddelegowana tylko do pracy nad technologiami mobilnymi. To etap usystematyzowania wiedzy i budowania świadomości rynku. Firmy zauważają, że wartość z nowego kanału sprzedaży jest na tyle wysoka, że mobile przestaje być traktowany jako moda, a zaczyna być uważany za część realnego biznesu (przykład: Allegro 2014).

6. Optymalizacja przez mobile- efekty osiągane przez działy mobilne stają się widoczne. Mobile staje się sposobem na optymalizację procesów, obniżanie kosztów obsługi i pozyskiwanie klientów. Inwestycja w mobile zaczyna się zwracać w innych obszarach działalności firmy, takich jak obsługa klientów, sprzedaż, zarządzanie procesami (przykład: operatorzy telekomunikacyjni w 2014 roku).

7. Konkurencja mobile-first- na rynku pojawiają się konkurencyjne firmy, które dzięki przewadze technologicznej i aplikacjom mobilnym są w stanie oferować usługi i produkty bez wykorzystywania fizycznych placówek i kosztów ludzkich, dzięki czemu są zwinniejsze i efektywniejsze kosztowo (przykład: iTaxi w 2013 roku).

8. Początki rynku mobile-only- przewaga wynikająca ze zbudowania aplikacji jest tak ewidetna, że budżet zaczyna się kierować w stronę logistyki i procesów, a budżety marketingowe i rozwojowe przeznacza się w większości na rozwój technologii mobilnych (przykład: PizzaPortal.pl w 2015 roku),

9. Rynek mobile-only- gdy ponad 80% klientów zaczyna korzystać z kanałów mobilnych do konsumpcji, usług i kupowania produktów, firma zaczyna zamrażać inne cyfrowe kanały, takie jak „duża” strona internetowa (przykład: YoGiYo w 2014 roku, odpowiednik PizzaPortal.pl w Korei Południowej).

Jak duży jest rynek mobilny?

W Polce jest 56,5 miliona kart SIM — na każdego mieszkańca przypada 1,46 karty[19]. Nie mamy jednak pełnych danych, kto nimi dysponuje i w jaki sposób. Nie mówiąc już o tym, że karty SIM są wykorzystywane nie tylko w smartfonach i części tabletów, ale także między innymi w urządzeniach przemysłowych, terminalach płatniczych czy w telemedycynie. Najlepsze dane na ten temat mają operatorzy telekomunikacyjni oraz grupy mediowe posiadające portale internetowe z ogólnokrajowym zasięgiem. Strzegą jednak tych informacji, bo ich upublicznienie może mieć negatywne konsekwencje biznesowe i odsłoniłoby ich przed konkurencją.

Aby samodzielnie estymować te dane, należy wyjaśnić kilka problemów definicyjnych.

Definicja smartfona nie jest idealna. Jeszcze w 2011 roku Instytut GfK Polonia definiował smartfon jako „telefon komórkowy, który spełnia jednocześnie trzy podstawowe warunki — posiada otwarty OS; posiada ekran dotykowy lub/i klawiaturę QWERTY; posiada funkcję organizera, w tym możliwość odbioru e-maili i obsługi aplikacji biurowych”[20].

Według tej definicji iPhone, od którego rozpoczęła się prawdziwa rewolucja smartfonowa, nie zalicza się do smartfonów, bo pierwotnie nie posiadał obsługi aplikacji biurowych[21]. Natomiast wymagania spełniała Nokia e71, która w żaden sposób nie jest obecnie zaliczana do kategorii smartfonów.

W 2012 roku GfK zmieniło definicję i usunęło z niej fragment o funkcji organizera, możliwości odbioru e-maili i obsługi aplikacji biurowych. Niemniej Nokia e71 dalej może być zaliczona do smartfonów.

Oprócz tego używanie smartfona nie oznacza, że się jest jego posiadaczem. Jeden smartfon może posiadać kilku użytkowników (szczególnie, gdy okazuje się, że smartfon jest najtańszą i najlepszą konsolą do gier i sposobem na korzystanie z Facebooka), może być też schowany w szufladzie bądź odsprzedany. Poza tym, smartfony są też kupowane przez firmy dla swoich pracowników, przez co jeden użytkownik może posiadać więcej niż jeden taki telefon. Są też gadżeciarze, którzy kolekcjonują smartfony.

Nie każdy też chce się podzielić informacją o tym, ile ma urządzeń z kartami SIM. Czasami też po prostu tego nie wie. Tutaj pojawia się problem z badaniami ankietowymi. Nie da się z nich wyciągać w pełni merytorycznych wniosków, ponieważ na przeszkodzie stoi subiektywizm ankietowanych.

Przykładem niech będą badania PBI, gdzie użytkownicy, przeglądając strony internetowe, są raczeni raz na jakiś czas wyskakującym okienkiem i pytani o posiadany telefon. Takie badania nie mogą stanowić dobrego źródła danych na temat tego, ilu Polaków ma smartfony, a jedynie informują o tym, ilu Polaków zobaczyło okienko PBI, czyli ilu nie ma blokady wyskakujących okienek w przeglądarce, ilu spośród nich zechciało odpowiedzieć na pytania ankietowe i ilu posiada w swoim mniemaniu smartfona.

W podobny sposób przeprowadzone badanie Generation Mobile z marca 2012 roku wykazało, że na pytanie “Jaki system operacyjny posiada Pan/i w swoim smartfonie?” odpowiedź “iOS” dało 2,1%, podczas gdy “Windows Phone” 9,6%. Dopiero rok później, w marcu 2013 roku, Microsoft przyznał, że osiągnął około 10% udziału w rynku[22]po raporcie IDC[23].

Do tego należy dodać, że nie każdy użytkownik wie, że ma smartfon. Gdy pierwszy raz spotkałem się z tym stwierdzeniem, pracując przy projekcie dla firmy telekomunikacyjnej, nie mogłem uwierzyć, że może to być prawdą. Faktycznie jednak okazuje się, że ze względu na sposób dystrybucji i cykl życia smartfona (wymiana na następny model co dwa lata wraz z nową umową) użytkownicy smartfonów kategoryzują je ze względu na formę, a nie możliwości, jakie dają. Dlatego też smartfony często są opisywane jako telefony z ekranem dotykowym.

Według badań TNS Mobile Life 2013 grupa osób posiadających smartfony to 31%, a deklarujących posiadanie smartfona to 19% — parafrazując: 12% użytkowników telefonów w Polsce w 2013 roku nie wiedziało, że ma smartfon[24]. Rok później, w styczniu 2014 roku, ta różnica zmalała już tylko do 3%[25].

Siły kształtujące rozwój mobile’a

Mobile wprowadza duże zmiany, do których liczne gałęzie gospodarki muszą się dostosowywać. Są jednak siły, które istotnie wpływają na propagację smartfonów i usług mobilnych wśród użytkowników.

Operatorzy telekomunikacyjni

Jedna z najważniejszych sił to operatorzy telekomunikacyjni. To oni wręczają klientom subsydiowane smartfony wraz z kontraktem na dwa lata lub kartą prepaid.

Telekomy znajdują się obecnie przed bardzo ważnym etapem swojego rozwoju. W ciągu ostatnich lat dało się zauważyć coraz wyraźniejszy trend wyhamowywania wzrostu przychodów z obsługi rozmów telefonicznych (Voice) i wiadomości tekstowych (SMS) na rzecz rosnącego znaczenia transferu danych (Data)[26].

Szybkość i limit transferu stają się uniwersalnym elementem walki o klienta w sytuacji, gdy rozmowy i wiadomości tekstowe są coraz częściej darmowe i bez ograniczeń. Dzieje się tak dlatego, że dzięki transferowi danych możemy uzyskać „rozmowy telefoniczne 2.0” oraz „wiadomości tekstowe 2.0” w postaci aplikacji typu Skype, Google Hangouts, Apple FaceTime czy WhatsApp, iMessage i Facebook Messenger. Te usługi są lepsze od standardowych, ponieważ mają liczne dodatkowe funkcje, większą wiarygodność i jakość[27].

Jednak przejęcie przez aplikacje dwóch podstawowych funkcji telefonu powoduje, że nagle z trzech nóg, na których stali operatorzy, tylko jedna gwarantuje dalszy wzrost. Transfer danych w dodatku staje się powoli towarem powszechnym, a więc jego cena będzie zmierzać do zera. W związku z tym operatorzy telekomunikacyjni słusznie boją się, że zostaną zepchnięci do roli anonimowego dostawcy internetu, co będzie oznaczało jeszcze szybsze spadki marż i mniejsze zyski.

Taka sytuacja zaczyna wymuszać na nich zmianę strategii i położenie większego nacisku na rozwój VAS (Value Added Services), czyli usług dodanych.

Praktycznie każdy użytkownik smartfona ma podpisaną jakąś formę umowy ze swoim operatorem. On z kolei dzierży w ręku dane swoich abonentów i co miesiąc wystawia im rachunki. To oznacza, że operatorzy mają dwie przewagi nad innymi podmiotami na rynku mobilnym: ciągły dostęp do klienta i łatwość oferowania mu dodatkowych usług, które zostaną dopisane do comiesięcznego rachunku — takich jak dodatkowy pakiet internetowy czy krótkookresowy roaming.

VAS nie musi być ograniczony tylko do portfolio samego operatora, ale może dotyczyć także firm, z którymi ustalił on warunki rozliczeniowe. W związku z tym użytkownik może w ramach swojego abonamentu uruchomić dodatkową usługę, na przykład słuchania audiobooków przez serwis Audioteka.pl czy dostępu do aktualnych map nawigacyjnych i informacji o korkach NaviExpert. Dla operatora jest to potrójny zysk, bo zwiększa lojalność swoich użytkowników, dostaje udział w zyskach dostawcy usługi oraz zwiększa wykorzystanie transferu danych.

Wraz z coraz mocniejszym otwieraniem się telekomów na VAS można zacząć traktować je zarówno jako platformę dostępu do klientów, jak i operatora płatności specjalnych.

Podpięcie się pod operatora z własnym produktem mobilnym i jego moc marketingowa może mocno zwiększyć zasięg, a prosty system płatności, do którego wszyscy abonenci są przyzwyczajeni, likwiduje jedną z największych barier rozwoju płatności mobilnych.

Banki i systemy płatności

Banki jako jedne z pierwszych zauważyły konieczność inwestowania w aplikacje mobilne. Jest to naturalna konsekwencja bardzo szybkiego upowszechnienia się w Polsce bankowości elektronicznej.

Funkcji aplikacji bankowych przybywa stopniowo — od prostych, podstawowych, jak możliwość sprawdzenia konta i wykonania przelewu, przez wyszukiwarkę bankomatów i oferty zakupowe, po systemy płatności mobilnych.

Bankom zależy na tym, aby wyeliminować obrót gotówką, który odbywa się poza ich systemem. Cały ten ruch ma za zadanie zabić klasyczny portfel z fizycznymi banknotami, monetami, kartami lojalnościowymi, debetowymi i kredytowymi.

„Ostatnią milą” systemu bankowego jest papierowy pieniądz. Banki ani administracja publiczna nie mają wglądu w to, jak on przepływa — po operacjach gotówkowych nie pozostaje ślad w żadnym rejestrze. Jednocześnie gotówka jest wygodna, bo zawsze mamy ją przy sobie. Do tej pory zatem łatwiej było dać komuś kilkadziesiąt złotych w formie banknotów niż siadać do komputera i robić przelew.

Smartfon mamy cały czas przy sobie, jest on więc tak samo dostępny jak gotówka. „Bank w telefonie” jest brakującym elementem w całej układance konwertowania użytkowników na pieniądz elektroniczny.

Aby aplikacje bankowe mogły w pełni zastąpić fizyczny pieniądz, muszą spełniać dwa wymagania:

- proximity payments– smartfon z aplikacją bankową jest narzędziem do autoryzacji operacji fizycznych, na przykład na stacji benzynowej,

- remote payments- smartfon z aplikacją bankową jest narzędziem do płatności na odległość lub w internecie, na przykład w sklepie internetowym lub w aplikacji do zamawiania pizzy.

Aby spełnić pierwsze wymaganie, nie wystarczy sam smartfon z aplikacją bankową — także sprzedawca musi być w stanie przyjąć taką płatność.

Do przyjmowania płatności wykorzystywane są urządzenia POS (Point of Sale). Im nowsza wersja POS, tym większe możliwości przyjmowania płatności — od gotówki, przez karty debetowe, po płatności zbliżeniowe. To właśnie ten ostatni typ pozwala na przyjmowanie i akceptację płatności nie tylko przez karty zbliżeniowe, ale także przez smartfony z aktywnym modułem NFC (Near Field Communication).

Istnieje także rozwiązanie, które nie wymaga NFC, ale potrzebuje dwustronnej komunikacji — zarówno smartfona, jak i POS — z centrum rozliczeniowym. Podczas płatności w sklepie ekspedient nabija na kasę cenę zakupów, POS wysyła do operatora płatności informację o zakupach. Operator przesyła do użytkownika aplikacji informację o transakcji i prosi o autoryzację. Po dokonaniu autoryzacji informacja przesyłana jest w drugą stronę i gdy trafi do POS, dochodzi do finalizacji zakupu.

W przypadku takich operacji wymagane jest bardzo szybkie reagowanie — jeśli przetransferowanie danych i notyfikacji o operacji między stronami będzie trwać dłużej niż kilkanaście sekund, to cały system traci swoją wartość dla użytkownika końcowego.

Na tej zasadzie działa BLIK — produkt Polskiego Standardu Płatności — organizacji powołanej przez największe polskie podmioty rynku płatności. Jest on dostępny w aplikacjach banków założycielskich i pozwala zarówno na wypłatę gotówki z bankomatu, jak i na płatności w sklepach i punktach usługowych bez karty bankomatowej[28].

Wymaganie remote paymentsspełniają rozwiązania programistyczne, bez wykorzystania dodatkowych urządzeń. Cała płatność odbywa się zdalnie — kupujący nie musi być w pobliżu sprzedającego.

Zazwyczaj proces wygląda tak, że kupujący po wybraniu produktów w aplikacji (bądź na stronie) w pewnym momencie widzi ekran wyboru płatności (paywall), gdzie proszony jest o wybranie odpowiadającej mu metody. Do wyboru może mieć: płatność kartą, płatność przez konto bankowe z wyborem swojego banku lub płatność za pomocą przedpłaconej portmonetki. Każda z tych metod doprowadza do sytuacji, w której z konta, które kontroluje kupujący, zostają przelane pieniądze na konto sprzedającego — zupełnie jak w każdym sklepie internetowym.

Różnica jest jednak taka, że w większości przypadków płacenie za pomocą smartfona jest trudniejsze. Podczas wykonywania operacji bankowych na komputerze telefon jest wykorzystywany jako narzędzie do autoryzacji (potwierdzanie przelewu przez kod w SMS-ie). Pojawiają się liczne zastrzeżenia, że urządzenie, na którym wykonuje się operację zakupu, jest jednocześnie urządzeniem do autoryzacji przelewu środków — a więc potencjalny złodziej ma o wiele prostsze zadanie, jeśli chce dostać się do środków na koncie klienta.

Zarówno bankom, jak i telekomom jest coraz bliżej do siebie. Obydwie grupy znalazły się niespodziewanie na jednym rynku — płatności mobilnych. Banki dysponują potencjałem i zezwoleniami na przeprowadzanie operacji finansowanych na smartfonach. Telekomy za to mają wszystkie elementy otoczenia, które do transakcji mobilnych są potrzebne — od klientów, przez urządzenia, po sieć.

Nic więc dziwnego, że obydwie grupy coraz mocniej ze sobą współpracują, a nawet się łączą, szukając synergii.

Startupy i marki

Startupy widzą wartość w mobile’u przy przenoszeniu już istniejących rozwiązań w nowe środowisko. Nowe, charakterystyczne dla mobile’u, płaszczyzny zbierania danych, które startupy mogą wykorzystać do celów marketingowych i zwiększania użyteczności (jak na przykład geolokalizacja czy notyfikacje), stawiają je o jeden stopień wyżej w stosunku do konkurencji internetowej i analogowej.

Startupom także dlatego zależy na zwiększaniu procentowego udziału użytkowników mobilnych, że ci wydają więcej i częściej niż w innych kanałach sprzedaży.

Poza tym marki wiedzą, że aby zdobyć spontaniczną rozpoznawalność, muszą pojawiać się tam, gdzie zwracają się oczy ich potencjalnych klientów. Teraz coraz częściej te oczy wpatrują się w małe ekrany zamiast w billboardy i telewizory.

Ważne jest też to, że smartfony i tablety to miejsce na tworzenie następnego punktu styku. Jeśli użytkownik zainstaluje aplikację danej marki na swoim telefonie, to za każdym razem, jak będzie przeglądał swoje aplikacje, będzie widział jej ikonę. Nawet jeśli nigdy z tej aplikacji nie skorzysta, to przynajmniej przez ułamek sekundy zetknie się z nią, co przyczyni się do utrwalania znaczenia marki.

Twórcy platform mobilnych

Naturalnymi orędownikami rozwoju mobile’a są oczywiście sami producenci urządzeń i właściciele mobilnych systemów operacyjnych. Walka o rynek odbywa się na dwóch płaszczyznach: zwiększania udziału rynkowego oraz powiększania samego rynku.

W tym drugim przypadku producenci widzą, jak urządzenia mobilne zaczynają odgrywać coraz ważniejszą rolę. A im więcej użytkowników smartfonów, tym więcej dodatkowych usług i produktów można im zaproponować. Twórcy sprzętu zauważyli, że smartfon jest doskonałym narzędziem, żeby wprowadzić użytkownika do całego ekosystemu ich produktów. Jest duża szansa, że ktoś, kto kupił i używa iPhone’a, jako swój następny laptop wybierze produkt Apple. Dzieje się tak, ponieważ urządzenia Apple’a są ze sobą coraz mocniej połączone i wspólnie oferują znacznie więcej niż osobno. Tak samo telefony Sony współpracują z konsolą PlayStation (co zwiększa prawdopodobieństwo, że zapalony gracz kupi telefon od tego producenta), smartfony Samsunga z telewizorami Samsunga, smartfony z Windows Phone 8 z komputerami z Windows 8 — i tak dalej…

Producenci harmonizują wygląd interfejsów i sposoby interakcji w swoich produktach i usilnie zwiększają różnice z konkurencją, bo chcą osiągnąć dwa efekty:

- zmniejszyć „krzywą uczenia się” nowego urządzenia (w myśl zasady, że jeśli już wiem, jak działa mój telefon, to będę wiedział, jak działa mój tablet). Dzięki temu zwiększa się szansa, że użytkownik pozostanie wierny platformie, którą już raz wybrał,

- zwiększyć koszt zmiany starej platformy na nową ze względu na zainwestowany czas i fundusze (wymiana smartfona na taki „spoza ekosystemu” spowoduje, że reszta sprzętu nie będzie już tak łatwa w obsłudze jak wcześniej).

Patrząc z tej perspektywy można się spodziewać, że urządzenia mobilne mają lub zaczną mieć ogromne znaczenie przy wybieraniu innych gadżetów, sprzętu RTV, AGD, a nawet samochodów. Dlatego producenci sprzętu uznają rynek mobilny za tak istotny z perspektywy przyszłości swojego biznesu, nawet jeśli obecność na nim nie jest wystarczająco rentowna.

Zalecana dalsza lektura:

- Elektroniczne metody płatności — istota, rozwój, prognozy, Komisja Nadzoru Finansowego

- Internet Trends, Mary Meeker, http://www.kpcb.com/internet-trends

- Mobilne płatności zbliżeniowe — o czym warto wiedzieć, Komisja Nadzoru Finansowego


[1] Emarketer — Smatphone Users Worldwide, http://www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/1010536

[2] Are Smart Phones Spreading Faster than Any Technology in Human History?, http://www.technologyreview.com/news/427787/are-smart-phones-spreading-faster-than-any-technology-in-human-history

[3] Internet Trends 2014 — KPCB, Mary Meeker, http://www.kpcb.com/internet-trends

[4] Gemius Ranking operating systems, http://ranking.pl/pl/rankings/operating-systems.html

[5] OpenSignal Android Fragmentation, http://opensignal.com/reports/2014/android-fragmentation

[6] Apple’s iOS Has Once Again Decimated Android When It Comes To Data That Matters,
http://www.businessinsider.com/ios-android-shopping-data-2014-11

[7] Milion smartfonów z Windows Phone sprzedanych w Polsce, http://www.rp.pl/artykul/1055213.html

[8] Worldwide Smartphone Growth Forecast to Slow from a Boil to a Simmer as Prices Drop and Markets Mature, According to IDC, http://www.idc.com/getdoc.jsp?containerId=prUS25282214

[9] Our Mobile Planet: United States, https://www.thinkwithgoogle.com/research-studies/our-mobile-planet-united-states.html

[10] MCNY Blog: New York Stories, Riding the Subway with Stanley Kubrick, zdjęcie podpisane: Stanley Kubrick. Life and Love on the New York City Subway. Passengers in a subway car. 1946. Museum of the City of New York. X2011.4.10292.26C, http://mcnyblog.org/2012/04/24/a-ride-on-the-subway-in-1946-with-stanley-kubrick

[11] Nomophobia: A Rising Trend in Students, https://www.psychologytoday.com/blog/artificial-maturity/201409/nomophobia-rising-trend-in-students

[12] The next 10 years in mobile, http://www.techcentral.co.za/the-next-10-years-in-mobile/27622

[13] Adres strony internetowej autora i książki Lukew Ideation + Design: http://www.lukew.com/resources/mobile_first.asp

[14] Apple App Store Tops 75 Billion Downloads, http://mashable.com/2014/06/02/apple-app-store-stats-2014

[15]Google Play Passes 50 Billion App Downloads, http://mashable.com/2013/07/18/google-play-50-billion-apps

[16]Sizing the app economy, http://www.developereconomics.com/report/sizing-the-app-economy

[17]Frisco.pl uruchamia wirtualny sklep w metrze, http://nowymarketing.pl/a/2497,frisco-pl-uruchamia-wirtualny-sklep-w-metrze

[18] Tesco builds virtual shops for Korean commuters, http://www.telegraph.co.uk/technology/mobile-phones/8601147/Tesco-builds-virtual-shops-for-Korean-commuters.html

[19] GUS — podsumowanie rynku kart SIM 2013, http://www.rp.pl/artykul/1081802.html

[20] GfK Polonia, styczeń 2011, cytowane przez blog Hatalska.com, http://hatalska.com/2011/02/16/rynek-smartfonow-w-polsce-nie-przekroczy-30-w-2011

[21] To mogło się zmienić dopiero po premierze App Store 1 lipca 2008 roku, ale nawet wtedy jeszcze długo nie było możliwości ściągnięcia z App Store pakietu biurowego.

[22] Wpis z oficjalnego bloga Microsoftu, http://blogs.microsoft.com/blog/2013/03/26/looking-back-and-springing-ahead

[23] Raport sprzedaży IDC, http://www.idc.com/getdoc.jsp?containerId=prUS24442013

[24] Raport TNS Mobile Life 2013 — materiał płatny, http://www.tnsglobal.pl/obszary-dzialania/mobile

[25] Mamy coraz więcej smartfonów i jesteśmy tego coraz bardziej świadomi, http://www.tnsglobal.pl/coslychac/2014/02/04/mamy-coraz-wiecej-smartfonow-i-jestesmy-tego-coraz-bardziej-swiadomi

[26] Rebalancing the value from voice and SMS to data, https://gsmaintelligence.com/research/2014/08/rebalancing-the-value-from-voice-and-sms-to-data/442

[27] Your Text is on Fire: OTT’s to burn 40% SMS revenue by 2015, http://www.telco2research.com/articles/AN_text-sms-on-fire-OTT-burn-revenue_summary

[28] Startuje BLIK — polski system płatności mobilnych, http://www.polskistandardplatnosci.pl/startuje-blik-polski-system-platnosci-mobilnych

Rozdział 2 Menedżer i mobile

Jeśli tutaj dotarłeś, to zapewne jesteś osobą, która została w swojej organizacji wyznaczona do wdrożenia produktu mobilnego. Ta rola została ci przyznana (lub sam się do niej zgłosiłeś), ze względu na wiele czynników, ale prawdopodobnie:

· jesteś osobą, która dała się poznać jako najlepiej rozeznana w nowych technologiach, a więc też potencjalnie najwięcej wiedząca o mobile’u w swoim zawodowym otoczeniu,

· nie było nikogo innego, kto zechciał podjąć się tego wyzwania.

Nie ma w tym nic dziwnego. Mobile jest tak świeżym zagadnieniem, że nie ma jeszcze ludzi, którzy mogą z czystym sumieniem stwierdzić, że znają wszystkie jego najważniejsze mechanizmy. Mobile nie jest jeszcze tak dokładnie zmapowany jak inne popularne gałęzie technologii wykorzystywanych komercyjnie. A bycie terra incognitama swoje plusy i minusy — odkrywanie tego, co działa i nie działa w mobile’u to zadanie dla ludzi, którzy nie boją się wyznaczania nowych ścieżek i chcących ryzykować w imię większej nagrody. Ten rozdział ma na celu określić, czy jesteś osobą, która ma te predyspozycje.

Największy problem niedostosowania organizacji do mobile’a wynika z tego, że zabierają się za niego nie ci ludzie, którzy powinni. Efektem jest zbyt późne zrozumienie wartości biznesowej kanału mobilnego bądź, w drugą stronę, próba zaistnienia w tej przestrzeni bez znajomości jej specyfiki. Aby to zrozumieć, trzeba najpierw wyjaśnić różnicę między myśleniem projektowym, a myśleniem produktowym.

Menedżer o myśleniu projektowym patrzy na swoją pracę, koncentrując się na osiągnięciu jednostkowego celu w określonym czasie i budżecie — jeśli go osiągnie, to jego zadanie jest wykonane i przechodzi do następnego zlecenia.

Produkt natomiast składa się z wielu projektów[1]. Osoba myśląca produktowo musi mieć szeroką wiedzę o biznesie, w jakim działa firma, ale także rozumieć skutki przenoszenia go na rynek mobilny. Gdy produkt już istnieje, to wtedy jest odpowiedzialna za jego nieustający rozwój na płaszczyźnie biznesowej i użytkowej. To oznacza, że wiedza menedżera produktu musi być bardzo szeroka i dotyczyć po trochu każdego aspektu tworzenia produktu mobilnego. Musi on rozumieć najważniejsze ograniczenia i szanse, jakie niesie ze sobą ten kanał, i strategicznie je wykorzystywać dla dobra produktu i firmy.

Aby zbudować dobrą aplikację mobilną, trzeba mieć szeroką wiedzę o procesie produkcji aplikacji, silną inklinację do związywania się z produktem na dłużej i ciągłą potrzebę jego usprawniania na wszystkich płaszczyznach.

Wizja, wiedza i władza

Dobry menedżer produktów mobilnych nie różni się od dobrego menedżera dowolnej innej specjalizacji poza tym, że działa w nowej dziedzinie, gdzie brakuje sprawdzonych rozwiązań i zinstytucjonalizowanej wiedzy. Lubię myśleć o takiej osobie jak o product ownerze, który — jak sama nazwa wskazuje — jest właścicielem i opiekunem produktu. Dobryproduct ownerto osoba, która ma wizję, wiedzę i władzę.

Wizja.To wyobrażenie o tym, jak produkt powinien wyglądać, jakie funkcje ma realizować i jakie wymagania biznesowe spełniać. Wiedza to pełna informacja o produkcie, ale także doświadczenie i wyczucie stylu. Władza to moc sprawcza, ale także odpowiedzialność za swoje decyzje.

Wizja to najmniej uchwytny i definiowalny element. Człowiek z wizją wie, conależy zrobić, ale nie mówi, jaktrzeba to zrobić. Wie, co chce osiągnąć, ale jeszcze nie dobrał sobie narzędzi. Rozumie, jaki ma cel, ale jeszcze nie zdecydował, którą chce iść ścieżką.

Patrzenie na cel pozwala na myślenie o poziom wyżej — ponad ograniczeniami technologicznymi i uwarunkowaniami rynkowymi. To myślenie ideowe, przed rynkową walidacją. Wizja jest subiektywna i przypisana zazwyczaj do jednej osoby. Bardzo trudno ją przekazać innym, bo wraz z wypowiedzeniem zaczyna się zniekształcać i jest reinterpretowana przez odbiorców.

Dlatego osoba z wizją stanowi centrum komunikacyjne i nadaje kształt produktowi. Ta osoba wie, czy projekt faktycznie idzie w dobrym kierunku, zgodnie ze zdefiniowanymi wcześniej zasadami — ale przede wszystkim zgodnie z wizją.

Wiedza.Produkty mobilne mają liczne arbitralne ograniczenia, niespotykane przy analogicznych rozwiązaniach internetowych. Na przykład wszystkie sklepy z aplikacjami mają swoje zestawy wytycznych, które aplikacja musi spełniać, aby zostać wpuszczona do obrotu. Same telefony mają swoje jasne i wyraźne ograniczenia w zakresie sposobu interakcji, wielkości ekranu, dostępnych czujników i podzespołów, dostępnej mocy obliczeniowej. Na poziomie wizualnym każda z platform ma swój własny zestaw zasad i dobrych praktyk tworzenia interfejsów graficznych, których naginanie może skończyć się usunięciem aplikacji. Sprawia to, że świat aplikacji mobilnych, mimo swojego ogromnego wzrostu, jest względnie jednolity i poukładany — właśnie dzięki autorytarnej władzy właścicieli platform.

Znajomość tych zasad to jeden z wielu podstawowych elementów wiedzy, jaką powinien posiadać menedżer produktów mobilnych. Dzięki niej jest w stanie odpowiednio planować swoje działania, rozumieć, co jest możliwe do osiągnięcia, oraz szybciej rozpoznawać potencjalne zagrożenia dla produktu.

Chociaż granice są jasno określone, to już samo tworzenie produktu mobilnego natrafia na takie same problemy, co każda inna działalność biznesowa: zaczynając od walki różnych idei, przez technologiczne ślepe zaułki, błędy komunikacyjne, problemy interpersonalne, stres i spadek motywacji zespołu, a kończąc po prostu na braku szczęścia.

Tworzenie oprogramowania to złożony proces. Próba jego całkowitej kontroli i określenia przewidywalności spełznie na niczym. Istnieje zbyt dużo zmiennych, które wpływają na powodzenie (lub nie) przedsięwzięcia, aby jeden menedżer był w stanie dokładnie je oszacować i określić prawdopodobieństwo wystąpienia różnych czynników. Musimy więc pogodzić się z tym, jak bardzo nie potrafimy szacować. Zmienność jest i będzie naszą codziennością — co zresztą tyczy się nie tylko pracy zawodowej, ale całego życia.

To jednak nie oznacza, że ktoś bez wiedzy ma te same szanse na sukces co doświadczony menedżer. Ten drugi rozpoznaje znajome już wzory zachowań i procesów oraz jest w stanie przewidzieć przybliżone konsekwencje poszczególnych decyzji, gdy początkujący musi odczuć je na własnej skórze.

Wiedza zwiększa szansę na sukces, bo minimalizuje liczbę niewiadomych konsekwencji. I o ile jestem przekonany, że wielu z moich czytelników podejmie decyzje, których negatywne konsekwencje będą skutkować niepowodzeniem, to samo dokonanie świadomego wyboru stanowi przewagę nad konkurencją. A doświadczenie buduje się najszybciej, wyciągając wnioski z niepowodzeń.

Władza, czyli siła sprawcza, jest potrzebna, aby faktycznie doprowadzić zadanie do końca, obronić wizję i zespół przed negatywnymi czynnikami wewnętrznymi i zewnętrznymi oraz umieć przeforsować decyzje oparte na wiedzy i doświadczeniu zespołu. Władza nadana przez zwierzchników pozwala zespołowi czuć się bezpiecznie, a liderowi daje narzędzia potrzebne do wywiązania się z powierzonego zadania.

Wraz z władzą idzie odpowiedzialność za podejmowane decyzje oraz za skuteczność całego zespołu. Władza bez odpowiedzialności prowadzi do wypaczeń i dysfunkcji zespołu, ponieważ decyzje nie są podejmowane ze świadomością ich konsekwencji. Odpowiedzialność pozwala zdecydować, kiedy warto i opłaca się podejmować ryzykowne ruchy (na przykład wejść szybko na rynek, wziąć na siebie ciężar edukacji użytkowników i liczyć na premię z bycia pierwszym) czy też przyjąć bardziej wycofaną strategię, przeczekać pierwszą falę innowacji i wyciągnąć wnioski, co faktycznie przynosi efekt.

Jasne określenie władzy w zespole ustawia hierarchię i przyśpiesza decyzyjność. Spowolnienie w realizacji projektów najczęściej wynika z rozproszonej decyzyjności. Poziom władzy i odpowiedzialności menedżera jest skorelowany z posiadanym wpływem na budżet produktowy.

Moim klientem była raz osoba o niezwykle dużej wiedzy dziedzinowej, ale praktycznie zerowej znajomości technologii. Nasze spotkania, podczas których miały być podejmowane decyzje projektowe, zawsze były odraczane, aż mój klient skonsultuje to ze swoimi przełożonymi. Ostatecznie, po szczerej rozmowie z klientem, jasno postawiliśmy sprawę, że wiemy, że to nie on posiada władzę nad projektem, lecz jego przełożeni. Klient dopiero wtedy zdał sobie sprawę, że bierze odpowiedzialność za projekt, którym nie steruje. Postawił sprawę na ostrzu noża, przejął inicjatywę i odzyskał władzę nad zespołem. Od tej pory nasze spotkania były o wiele produktywniejsze, a decyzje zapadały szybciej, dzięki czemu wzrosła motywacja wszystkich zaangażowanych osób.

Kto nie powinien robić produktów mobilnych

Uważam, że powodem klęski większości projektów mobilnych nie jest wybór złej technologii, ale wybór złego menedżera. Zły menedżer stosuje do produktu mobilnego złe (znane mu z innych dziedzin) kryteria, co prowadzi do złego planowania zasobów i złej realizacji.

Kto jest niewłaściwą osobą do projektu mobilnego? Daleko mi do budowania rysu psychologicznego, ale pewne charakterystyczne cechy są wspólne.

Brak przywiązania do szczegółów objawia się przez brak skrupulatności i uwagi dla detali. Ekran smartfona jak lupa uwypukla niedoskonałości. Małe błędy ulegają wielokrotnemu powiększeniu, czasami wręcz odrzucając użytkowników. Każda platforma mobilna oferuje obecnie przemyślaną wizualnie i spójną stylistycznie paletę rozwiązań, użytkownicy smartfonów przyzwyczaili się więc, że to, co widzą na swoim urządzeniu, jest po prostu ładne. Jedną z przewag konkurencyjnych i sposobem na wyróżnienie się wśród konkurencji jest zachwycenie użytkowników pięknym interfejsem. Nie da się go wykonać, jeśli menedżer nie ma wyczucia stylu i elegancji.

Stworzenie i rozwój produktu to ciągłe i niekończące się testowanie założeń w celu osiągnięcia jak najlepszego dopasowania do potrzeb rynkowych. To dopiero początek ścieżki tworzenia dobrego produktu. Dlatego przytłaczająca większość aplikacji, które były tworzone w ramach jednorazowych kampanii reklamowych, jest bardzo złej jakości.

Niestety popularną praktyką w nowoczesnych firmach jest traktowanie mobile’a jako kompetencji osób odpowiedzialnych za PR lub reklamę zamiast tych odpowiedzialnych za sprzedaż i technologię.

Pewnego dnia napisała do mnie Senior Account Executive z jednej z największych polskich agencji PR w sprawie stworzenia aplikacji dla… jednego z największych serwisów ogłoszeniowych dostępnych w Polsce. Zapytała, ile by kosztowała taka aplikacja i jaki byłby orientacyjny czas realizacji. To, czego brakowało w jej e-mailu, to wymagania, jakie aplikacja ma spełniać. Zazwyczaj na pytanie: Ile kosztuje aplikacja? odpowiadam pytaniem: A ile kosztuje samochód? Wtedy zawsze słyszę: To zależy jaki, na co odpowiadam: No właśnie!

Największym ryzykiem dla projektu są ludzie, którzy dysponują władzą, a nie posiadają wiedzy — i nie chcą jej zdobyć.

Z perspektywy dostawcy technologicznego jest to taki klient, który zleca projekt i nie chce mieć z nim nic wspólnego aż do wyznaczonego etapu lub finiszu projektu.

Z perspektywy projektu wewnętrznego to właściciel biznesowy, który po przydzieleniu budżetu i przekazaniu ogólnej wizji nie ma czasu, aby odpowiadać na pytania dotyczące logicznych sprzeczności w tejże wizji ujawniających się w trakcie pracy zespołu. Jeśli jesteś odpowiedzialny w swojej firmie za mobile i zauważysz u siebie symptomy wycofanego ojca, to możesz być pewny, że twój projekt nie zostanie ukończony z sukcesem w przewidzianym budżecie i czasie.

Zaczynając projekt, musisz być pewny, że masz wizję, władzę i wiedzę. Brak choć jednego z tych elementów nie pozwoli ci zrealizować projektu zgodnie z założeniami.

Pogódź się z tym, że produkty się zmieniają, ewoluują, wychodzą poza budżety lub po prostu się nie udają — szczególnie w dziedzinie tak nowej jak technologie mobilne.

Napisano już dużo książek na temat tego zjawiska, ale w skrócie wniosek jest taki, że projekty programistyczne to nie są mosty, które budujemy od setek lat, ciągle zwiększając wiedzę i udoskonalając narzędzia. Nasze doświadczenie nie jest aż tak długie, abyśmy mogli mieć 100-procentową pewność, że nasze szacunki czasowe i kwotowe będą zgodne z rzeczywistością.

Między innymi dlatego wymyślono metodyki zwinne (Agile) — które dzięki empiryzmowi pozwalają na lepsze zarządzanie pracami zespołów programistycznych. Agilezakłada, że wszystko się ciągle zmienia i że nie da się wszystkiego przewidzieć. Nasze doświadczenia i estymaty możemy czerpać jedynie z przeszłych doświadczeń.

Jeśli więc widzisz swój projekt jako coś niezmiennego, a czas jego wykonania, budżet i zakres uważasz za „zabetonowane”, to spodziewaj się stresu narastającego wraz z postępem prac.

Jaki powinien być menedżer produktów mobilnych

Menedżer produktów mobilnych powinien być „generalistą”- orientować się wystarczająco dobrze w każdym z obszarów rozwoju produktu, aby widzieć potencjalne zagrożenia i móc naprowadzić zespół specjalistów w swoich dziedzinach do wspólnego rozwiązania problemu. Ostatecznie menedżer odpowiada za stworzenie dobrego produktu. Dobry produkt to taki, który spełnia potrzeby klientów, więc korzystają z niego regularnie i mają o nim dobre zdanie. Dzięki temu produkt przynosi zyski. To powoduje, że idealnym kandydatem do tej roli jest osoba, która rozumie, czym jest dobry produkt i wie, jak generować zaangażowanie wśród użytkowników. Pojawia się jednak trudny wybór między wiernością wobec firmy i wobec zadania stworzenia dochodowego produktu, a wiernością wobec użytkownika końcowego.

Naturalną cechą firmy jest nastawienie na zysk. Tak samo, po pierwotnej inwestycji, stanie się z aplikacją mobilną, którą menedżer zarządza. Zazwyczaj naciski z wnętrza organizacji prowadzą do skracania ścieżki budowania przychodu i do jak najszybszego wykazywania zwrotu z inwestycji, nawet jeśli produkt jest nastawiony na budowanie społeczności. Jest to zrozumiałe, gdyż zysk generowany teraz jest więcej warty niż generowany za rok.

Wykazywanie zysku w krótkim okresie niesie też pozytywny komunikat do wszystkich zaagażowanych osób i właścicieli biznesowych. Buduje motywację i może zwiększyć poziom zaufania, bo waliduje „na papierze” kompetencje menedżera w nowym środowisku.

Niestety, budowanie dobrego produktu często stoi w sprzeczności z szybkim zarabianiem na nim, na przykład gdy buduje się produkt, wykorzystujący efekt sieciowości zgodnie z prawem Metcalfe’a[2]. Wtedy (parafrazując) wartość produktu rośnie w oczach użytkownika, jeśli widzi, że coraz więcej innych użytkowników z tego produktu korzysta. Oryginalnie Robert Metcalfe swoje prawo pokazywał na połączonych ze sobą telefonach i faksach, ale szybko odkryto, że sprawdza się też doskonale w przypadku usług i produktów internetowych (takich jak komunikatory czy serwisy społecznościowe).

W tym wypadku najważniejszym biznesowo celem jest stworzenie jak najprostszego mechanizmu rejestracji i używania produktu, a później wytworzenie sposobów na wirusowy rozrost aplikacji, a nie monetyzacja, która może odstraszyć pierwsze grupy użytkowników potrzebne do stworzenia masy krytycznej.

Co powinien więc wybrać menedżer, który po jednej stronie widzi potrzeby biznesowe swojej organizacji, a po drugiej stworzenie dobrego produktu dla użytkownika?

Odpowiedź na takie pytanie jest zawsze trudna, bo nie da się każdego przypadku generalizować. Każde ekstremum jest złe — produkt bez monetyzacji może wpaść w problem „rozpieszczania” użytkownika oferując mu zbyt dużo za darmo. Produkt z szybką monetyzacją odstraszy użytkowników zbyt nachalnym sposobem zarabiania.

Uważam, że menedżer powinien być motywowany przede wszystkim potrzebą stworzenia dobrego produktu z perspektywy użytkownika, ponieważ ostatecznie tam, gdzie jest zadowolony użytkownik, tam także pojawiają się pieniądze.

Trzeba też z jednej strony pamiętać, że zbyt szybko udostępniony produkt prowadzi do długu technologicznego. To metafora, która pokazuje, że jeśli idzie się na skróty — na przykład budując system szybkozamiast dobrze- to zaciąga się dług. Ten dług trzeba będzie spłacić, gdy pojawi się konieczność aktualizacji systemu do nowych warunków. Im większy dług, tym większe odsetki — a więc większy problem z naprawianiem systemu[3].

Z drugiej strony jednak im dłużej trwa praca nad produktem, tym większe prawdopodobieństwo, że nigdy nie zobaczy on światła dziennego. Technologia ma coraz krótsze cykle rynkowe, więc produkt, który został rozpoczęty pół roku temu jako innowacja, po kilku miesiącach może być już normą rynkową, a zanim dojdzie do premiery, zostanie daleko w tyle za konkurencją. Jednocześnie nasza ludzka psychika skłania nas do odsuwania w czasie zetknięcia z rynkiem i walidacji założeń, co z kolei prowadzi do frustracji wynikającej z niekończącej się pracy nad projektem i zmniejszania motywacji w zespole.


[1] Patrząc w większej skali jest też tak, że produkt może być elementem większego projektu.

[2] Metcalfe’s law, http://en.wikipedia.org/wiki/Metcalfe%27s_law

[3] Dług technologiczny, felieton Jana Rychtera, http://antyweb.pl/dlug-technologiczny

Rozdział 3 Firma i mobile

Przed 2007 rokiem technologie mobilne były wykorzystywane jako przyspieszenie komunikacji w dużych korporacjach. Po tym roku, wraz z premierą pierwszego iPhone’a, okazało się, że moc tych urządzeń da się wykorzystać także w prywatnym życiu każdego z nas.

Mobile jako zbiór dobrych praktyk to odpowiedź na prędko zmieniające się środowisko biznesowe. To z jednej strony narzędzie dla firm, które chcą szybko pozyskać przewagę konkurencyjną, na przykład przez zmniejszenie kosztów pozyskania klienta czy zwiększenie wachlarza i dostępności swoich usług. Z drugiej strony odpowiednio przygotowane narzędzia mobilne przyspieszają procesy wewnątrz firmy.

Patrząc na rynek, można podzielić firmy ze względu na wdrażanie rozwiązań mobilnych na cztery grupy:

1. Firma non-mobile- organizacja, która nie jest zainteresowana rozwojem w kanałach mobilnych.

2. Firma mobile-second- organizacja, dla której działania mobilne są drugorzędne i większość swoich zasobów skupia na rozwoju dotychczasowych kanałów sprzedaży.

3. Firma mobile-first- organizacja, która na pierwszym miejscu stawia rozwój kanałów mobilnych, a wszystkie inne kanały pełnią rolę pomocniczą.

4. Firma mobile-only- organizacja, która skupia wszystkie swoje zasoby na rozwoju kanału mobilnego.

W większości przypadków polskie firmy są na etapie pierwszym. Duże polskie firmy oraz międzynarodowe marki widoczne na polskim rynku są na etapie drugim ze względu na standardy i wzory zaczerpnięte za granicą. Młode firmy i startupy coraz częściej przechodzą z etapu drugiego na trzeci, ponieważ nie ponoszą kosztów zmiany architektury i nie mają długów technologicznych. Etap czwarty jest popularny wśród startupów w innowacyjnych gospodarkach (Japonia, Korea Południowa, USA). W Polsce to pojedyncze przypadki ze względu na zbyt mały zasięg i chłonność rynku. Dokładniejsze rozróżnienie między typami firm jest opisane w rozdziale Strategia mobilna.

Przejście z jednego stadium do następnego jest związane z kosztami i wymaga poważnej zmiany organizacyjnej. Zawsze, gdy w organizacji dochodzi do zmiany — na przykład konieczne jest wejście na nowy rynek lub wprowadzenie nowego produktu — istnieje tendencja do określania celów i kryteriów sukcesu na bazie historycznych doświadczeń. Jest to naturalne podejście, bo bezpieczniej jest odwoływać się do sprawdzonych metod niż szukać nowych.

Technologie mobilne jednak powodują, że takie myślenie mija się z celem, gdyż wprowadzenie produktu mobilnego niesie za sobą konieczność tworzenia nowych, odmiennych struktur z zespołem o nowych kompetencjach. Taka strukturalna zmiana często jest szokiem dla organizacji, a jej najprostszą odpowiedzią jest traktowanie nowej jednostki organizacyjnej jak ciała obcego.

Mobile wymaga specyficznego zakresu umiejętności od menedżera. Aby zrozumieć dobre praktyki i zasady tworzenia produktów mobilnych, trzeba zdobyć multidyscyplinarną wiedzę i, co jest trudniejsze, oduczyć się części dotychczasowych praktyk biznesowych i organizacyjnych. Takie kompetencje jest bardzo trudno zdobyć i zaaplikować w już istniejącej strukturze, która ma swoje ustabilizowane procesy i cele.

Rola i rozwój działu mobilnego w organizacji

Od momentu pojawienia się pierwszych polskich aplikacji w App Store minęło już ponad siedem lat. Przez ten czas polskie firmy, które zaczęły budować mobilny kanał przychodów, wykształciły wewnątrz swoich organizacji różne taktyki wytwarzania aplikacji mobilnych.

Wyróżniam pięć podstawowych taktyk:

1. Wewnętrzny zespół mobilny — w pełni skupiony na dostarczaniu wartości biznesowej przez mobile, pracuje ciągle równolegle do innych zespołów produktowych w firmie. Członkowie zespołu mają wypracowane metody i zasady współpracy.

2. Wewnętrzny zespół mobilny ad hoc — członkowie zespołu są w codziennej pracy w różnych działach firmy i w przypadku pojawienia się projektu mobilnego są wyłączani ze swojej dotychczasowej pracy i przenoszeni do projektu mobilnego. Zespół ma już doświadczenie w pracy ze sobą.

3. Kumulowanie zasobów mobilnych ad hoc — formowanie zespołu odbywa się w zależności od bieżącej potrzeby. Członkowie zespołu muszą się szybko nauczyć ze sobą współpracować.

4. Zewnętrzny dostawca z wewnętrznym właścicielem produktu.

5. Pełny outsourcing mobile’a z wewnętrznym właścicielem biznesowym.

Do 2013 roku tworzenie projektów mobilnych w polskich firmach było traktowane po macoszemu. Nawet w największych organizacjach do stworzenia aplikacji wykorzystywano jednego programistę, czasami nawet bez wsparcia grafika — wynikało to zazwyczaj z braku znajomości rynku mobilnego oraz niechęci do „zamrażania” kluczowych zasobów w projektach, które nie mają potwierdzonej wartości dla firmy.

Ponieważ aplikacje mobilne wymagają bardzo dużego zaangażowania ze strony działów technicznych, kierowanie projektami mobilnymi zaczęło przypadać osobom o doświadczeniu programistycznym. Efektem były aplikacje, które, choć spełniały wymagania specyfikacji (jeśli ta istniała), to jednak odbiegały od standardów rynkowych.

Czasami zdarza się, że zarząd firmy decyduje się na formowanie zespołu mobilnego z zewnątrz, motywując to potrzebą wniesienia do organizacji zupełnie nowej wiedzy i szybkości, której nie da się osiągnąć przy obecnych procedurach. W doświadczonych mobilnie firmach dział mobilny przestaje istnieć jako samodzielna grupa. Zamiast tego wszystkie inne działy produktowe zaczynają budować własne kompetencje mobilne na podstawie doświadczeń działu mobilnego.

Najlepszym sposobem na rozpoczęcie propagacji wiedzy o mobile’u w organizacji jest stworzenie niezależnego, agnostycznego działu skupionego tylko na mobile’u, który będzie wykorzystywany projektowo przy tworzeniu wersji mobilnych istniejących produktów firmy bądź konsultował nowe produkty. Dla zarządu dział mobilny stanowi źródło wiedzy o nowych trendach i punktach budowania przewagi konkurencyjnej.

Minusem tego podejścia jest potencjalnie niskie znaczenie działu mobilnego w hierarchii firmy. Na początku zazwyczaj będzie traktowany jako ciało obce, które narzuca nowy zestaw wytycznych do spełnienia przez klasycznie budowany nowy produkt, przez co wydłuża czas jego realizacji.

Zazwyczaj proces formowania się i życie działu mobilnego w organizacji składa się z sześciu etapów:

1. Na samym początku decydenci zaczynają zauważać wzrost znaczenia mobile’a dla organizacji. Wiedza o mobile’u w zespołach produktowych jest rozczłonkowana i incydentalna. Nie ma jednej osoby odpowiedzialnej za działania mobilne, brakuje mocy sprawczej. Pojawia się potrzeba powołania nowego stanowiska i powołania osoby odpowiedzialnej za mobile.

2. W drugim etapie zostaje powołana osoba odpowiedzialna za mobile lub nieformalnie „przesuwa się do mobile’a” osobę, która do tej pory była odpowiedzialna za innowacyjne rozwiązania. Często pełni ona rolę doradcy zarządu. Jej celem jest edukowanie organizacji i audyt dotychczasowych działań mobilnych

3. Następnie powoływana jest osoba na stanowisko head of mobile. Ma dwa cele: stworzyć strategię mobilną spójną z generalną strategią organizacji oraz rozpocząć tworzenie działu mobilnego w organizacji.

4. Head of mobile tworzy dział mobilny, który jest odpowiedzialny za projekty specjalistyczne, poboczne w stosunku do głównych strumieni przychodu organizacji.

5. Dział mobilny zaczyna być dołączany do standardowych projektów firmy. Wraz ze wzrostem znaczenia mobile’a zaczyna być odpowiedzialny przed zarządem za wyniki generowane przez swój kanał.

6. Dział mobilny zostaje rozczłonkowany po działach produktowych, gdyż organizacja dochodzi do wniosku, że kompetencje, którymi dysponuje dział mobilny są potrzebne w każdym dziale produktowym. Head of mobile wraca do roli edukacyjnej. Poza tym synchronizuje działy i dba o realizację strategii mobilnej.

Jak widać, z czasem kompetencje działu mobilnego przejmują menedżerowie i zespoły odpowiedzialne za poszczególne produkty. Sam dział mobilny przestaje odgrywać rolę produktową, a zaczyna mieć funkcję konsultingowo-audytową, a head of mobile zajmuje się synchronizacją i dbaniem o spójność działań przy poszczególnych produktach. Head of mobile staje się agentem zmiany w organizacji. Dział mobilny, który stworzył, początkowo jest niezależnym działem badań i polem doświadczalnym, a potem jego wiedza zostanie rozpropagowana po całej organizacji.

Struktura i komplementarność zespołu

Zespół tworzący aplikację ma większe szanse na powodzenie, jeśli:

- pracował już wcześniej ze sobą,

- osoby odpowiedzialne za poszczególne aspekty produktu (wymagające różnych kompetencji) rozumieją rolę każdego członka zespołu,

- wszyscy jego członkowie pracują w tym samym pomieszczeniu (tzw. war room).

Należy unikać horyzontalnego rozdzielenia zespołu według kompetencji, na przykład na podzespół programistyczny i podzespół graficzny. Strategicznym błędem jest wynajmowanie niezależnego podmiotu do stworzenia projektu graficznego i zaplanowania UX (User Experience– doświadczenie użytkownika) oraz oddzielnego odpowiedzialnego za zakodowanie całości.

Problemy w tym układzie wynikają z kilku przyczyn:

- Firma odpowiedzialna za grafikę i zaprojektowanie UX ma mgliste pojęcie o ograniczeniach technicznych. Po zdaniu projektu do firmy programistycznej uzna, że jej praca jest zakończona i będzie oczekiwać dodatkowej płatności za CR-y (tzw. Change Requesty).

- Firma odpowiedzialna za kodowanie będzie traktowała wizję grafików i specjalistów od UX jako luźną propozycję i wybierze najprostszy sposób implementacji zgodny z dokumentacją i umową.

- Obydwie firmy w minimalnym stopniu będą się ze sobą komunikować, aby nie tracić czasu projektowego — uznając, że druga strona nie rozumie istoty problemu.

Jednym z najpopularniejszych argumentów sprzedażowych takich firm jest podkreślanie swojej specjalizacji. Warto pamiętać, że ostatecznie najważniejszy jest odbiór najlepszej możliwej aplikacji, a jest to możliwe, jeśli pracuje nad nią monolityczny zespół, który wyznaje takie same zasady i ma spójne motywacje. Z mojego doświadczenia wynika, że o wiele łatwiej jest podnieść kompetencje któregoś z członków zespołu niż zsynchronizować 2–3 niezależne firmy odpowiedzialne za dostarczenie produktu.

Jeśli menedżer zdecyduje się na posiadanie wewnętrznego zespołu mobilnego, to ten powinien operować w ramach wspólnej przestrzeni, która symbolicznie oddziela go od reszty zespołów projektowych — zarówno geograficznie (niezależny pokój w biurze), jak i komunikacyjnie (oddzielne narzędzia zarządcze). Dzięki temu swobodnie będzie mógł wymieniać się informacjami ze swojej dziedziny.

Jeśli warunki zewnętrzne bądź twoja decyzja doprowadziła do tworzenia aplikacji wewnątrz organizacji, to ważne, aby zostały stworzone odpowiednie warunki pracy dla zespołu. Prawdopodobnie zespół będzie się zajmował projektem, który nigdy wcześniej nie był realizowany w tej strukturze, co oznacza ciągłe napotykanie na problemy natury formalnej i organizacyjnej.

Byłem świadkiem przypadku, w którym menedżer nie mógł skorzystać z zewnętrznego narzędzia do mierzenia zachowań użytkowników w aplikacji, ponieważ wiązałoby się to jednocześnie z udostępnianiem danych firmy twórcy narzędzia — co było niezgodne z wewnętrzną procedurą bezpieczeństwa.

Centralnym punktem zespołu jest programista (lub programiści). Otaczają go wszyscy inni członkowie zespołu, którzy pozwalają mu pracować, a więc tworzyć kolejne iteracje aplikacji mobilnej. Do tego „otoczenia” zazwyczaj należą: product owner, ux designer, grafik oraz tester.

Product owner jest osobą, która ma wizję, wiedzę i władzę. W większości przypadków to właśnie twoja rola, droga czytelniczko bądź czytelniku. W mniejszych firmach product owner, ze względu na posiadaną władzę, jest także właścicielem biznesowym, który inicjuje i finansuje stworzenie produktu. W innych przypadkach product ownerem staje się menedżer o potencjalnie największej wiedzy dziedzinowej i technologicznej.

Biorąc pod uwagę skomplikowanie projektów mobilnych i konieczność jednoczesnego kontrolowania wielu jego aspektów, nie polecam prowadzenia jednocześnie więcej niż dwóch produktów mobilnych. Pojawia się wtedy problem ograniczonej percepcji i potrzeba zbyt częstych zmian kontekstu pracy, przez co spada jej efektywność.

Jeśli organizacja zaczyna posiadać więcej niż dwa produkty mobilne, menedżer stojący na czele działu mobilnego musi wyznaczyć dodatkowych product ownerów. Wtedy on sam odsuwa się od pracy produktowej i zaczyna zajmować się koordynacją i harmonizacją produktów mobilnych z resztą działań organizacji.

Mobile w startupach

Startupy mobilne widzą swoją wartość tam, gdzie jest wartość samego mobile’a — w przybliżaniu, przyspieszaniu i ułatwianiu. Większość hipotez rynkowych stawianych przez nie polega na przeniesieniu już istniejącego na rynku rozwiązania i ulepszenia go dzięki funkcjom urządzeń mobilnych.

Startupy mają jedną zasadniczą przewagę nad rozwiniętymi firmami: są od nich szybsze i zwinniejsze, bo nie niosą ze sobą bagażu inwestycji w przestarzałe technologie i nieefektywne procesy. Dzięki temu to właśnie one pierwsze adaptują nowe rozwiązania technologiczne.

Startupy mają za zadanie testować nowe hipotezy rynkowe. Udowadnianie ich powoduje, że powstaje stabilny biznes oparty o innowację. Startupy mobilne działają w środowisku zamkniętych platform, które z jednej strony ograniczają, nadając sztywne ramy ustalone przez producentów sprzętu i ich sklepy mobilne, ale z drugiej ułatwiają dystrybucję.

Charakterystyka kanału mobilnego i szybkość adopcji nowych rozwiązań powoduje, że postawione tezy rynkowe można szybciej walidować, a te z nich, które okażą się prawdziwe, skalować wykładniczo, opierając się na dystrybucji zapewnianej przez sklepy mobilne.

Startupy mobilne mają szansę na wygrywanie z wielokrotnie większymi firmami (i ich budżetami) dzięki zasadom teorii „przełomowej innowacji” (disruptive innovation) opisanej przez profesora Claytona M. Christensena w książce o tym samym tytule[1].

Teoria zakłada, że „przełomową innowacją” są produkty zbudowane z już istniejących komponentów, ale mające prostszą architekturę i oferujące mniej. Przez to nie pasują do dojrzałych rynków, ale rozwijają się doskonale na rynkach rozwijających się — tych, które są pomijane przez główny nurt biznesowy[2]. Później następuje ekspansja innowacji na następne rynki. Główni gracze rynkowi, gdy już zauważą nadchodzącą zmianę, nie są w stanie jej zatrzymać i ostatecznie tracą swój rynek.

Christensen wyróżnia dwa typy przełomowej innowacji: low-end disruption i new-market disruption. Pierwsza kierowana jest do użytkowników, którzy nie potrzebują produktu o wysokiej wydajności — zadowala ich produkt dostatecznie dobry o jak najniższej cenie. New-market disruption dotyczy użytkowników, których potrzeby nigdy wcześniej nie były zaspokojone na danym rynku przez obecnych graczy. Urządzenia mobilne katalizują obydwie formy innowacji — obniżając koszty realizacji usług oraz budując nowy rynek konsumentów mobilnych.

Mobile w małych i średnich firmach

Małe i średnie firmy powinny widzieć w mobile’u szansę na stworzenie przewagi konkurencyjnej przez budowanie analogii swojego dotychczasowego biznesu w nowym kanale sprzedaży.

Sposobem na to jest dostarczanie użytkownikowi lepszego doświadczenia z korzystania z produktu oraz łatwiejszego odnalezienia oferowanej usługi. Urządzenia mobilne same ze swojej natury stają się katalizatorem tych zmian i firmy, które pojawią się w tej przestrzeni pierwsze, będą miały przewagę rynkową.

Nie jest prawdą, że wszystkie firmy powinny mieć swoje aplikacje. Inwestycja w aplikację mobilną musi być poparta szczerą analizą kosztów i potencjalnych zysków — z której często będzie wynikało, że koszt stworzenia i utrzymania aplikacji znacznie przewyższa potencjalne zyski sprzedażowe. Taka analiza, nawet na wstępnym etapie, wykaże, czy aplikacja ma faktyczne uzasadnienie biznesowe, czy jest tylko efektem chwilowej mody.

Z jednej strony dostosowanie małej lub średniej firmy do aplikacji mobilnej jest łatwiejsze niż dużej korporacji, ale generuje znacznie większe procentowo koszty w budżecie. W przypadku małych i średnich przedsiębiorstw o wiele częściej zdarza się, że lepszym rozwiązaniem jest poczekać na „technologiczne dorośnięcie” organizacji — zarówno pod względem infrastruktury, jak i doświadczenia zespołu.

Posiadanie aplikacji niesie bowiem za sobą koszty, które przed jej stworzeniem wydają się nieistotne bądź nieistniejące. Aplikacja po swoim publicznym starcie musi być ciągle doglądana, błędy poprawiane, opinie użytkowników wysłuchiwane. Do tego potrzebni są ludzie, którzy mogą potencjalnie przyczyniać się do rozwoju firmy w lepszy sposób niż zajmując się aplikacją mobilną.

Znacznie lepszym rozwiązaniem jest wejście w świat mobile’a za pomocą dobrej strony mobilnej. Bez aplikacji mobilnej firma może się obejść, bez strony mobilnej już nie, szczególnie biorąc pod uwagę nową politykę wyszukiwania stron Google premiującą strony mobilne względem desktopowych[3]. Stworzenie strony mobilnej wymaga mniejszego budżetu, jej utrzymanie jest o wiele prostsze, a jednocześnie pozwala przetestować zasadność tworzenia produktów mobilnych i zdobyć wiedzę przydatną przy tworzeniu aplikacji mobilnej.

Jeśli jednak aplikacja jest potrzebna, to należy ją traktować jako długookresowe działanie — inaczej stanie się ślepym zaułkiem generującym koszty utrzymaniowe i jednocześnie złe opinie wśród użytkowników.

Mobile w agencjach reklamowych

Agencje budują swój wizerunek na byciu nowoczesnymi — dzięki tej nowoczesności przekonują, że wyprzedzają trendy rynkowe, a więc są w stanie doradzić swoim klientom, jak powinni działać, aby przygotować na nie swoją komunikację reklamową. Mobile jest jednym z takich trendów.

W odróżnieniu od social media marketingu, mobile jest bardzo trudnym narzędziem reklamowym. Wymaga posiadania mocnego zaplecza technologicznego i nie obiecuje podobnych zasięgów i szybkich zwrotów jak kampanie na Facebooku. Agencje reklamowe działają projektowo (i w krótkich przedziałach czasu), a to nie sprzyja tworzeniu dobrego produktu mobilnego. Jego budowanie liczy się w kwartałach, a nie dniach jak w przypadku aplikacji reklamowej w sieci społecznościowej.

Zamiast na aplikacjach mobilnych agencje reklamowe powinny zacząć skupiać się na oferowaniu tworzenia stron mobilnych jako ważnego elementu ścieżki użytkownika podczas trwania kampanii mobilnej.

Na takie strony internetowe (nazywa się je landing pages, LP) trafia potencjalny klient po wyszukaniu frazy w Google, tapnięciu w reklamę bądź bezpośrednim wpisaniu adresu strony. Generowanie LP było do tej pory bardzo proste dzięki gotowym wzorom i narzędziom dostępnym dla webmasterów.

Obecnie, przez konieczność tworzenia ich w standardzie RWD (responsive web design), który pozwala na wyświetlanie ich w optymalny sposób na różnej wielkości ekranów, trochę się to komplikuje. Niemniej jest to już wymóg rynkowy i agencja, która nie m w tym zakresie doświadczenia, straci pozycję rynkową, gdyż nie będzie potrafiła zaspokoić potrzeb swoich klientów, którzy już widzą 10–50-procentowy udział ruchu z urządzeń mobilnych na swoich stronach.

Mobile w korporacjach

W dużych firmach wszystko trwa dłużej. Nie zawsze ze względu na bezwładność i niemoc decyzyjną, ale także dlatego, że z natury rzeczy każdy nowy projekt musi być opiniowany i akceptowany na wielu płaszczyznach, musi się wpisywać w budżet i nie może łamać wewnętrznych zasad firmy.

Często okazuje się, że innowacyjny produkt już na wstępnym etapie może być postrzegany jako potencjalna wewnętrzna konkurencja dla istniejących rozwiązań.

W dużych firmach łatwiej jest znaleźć sobie „przechowalnie” i uchronić się przed weryfikacją swoich umiejętności i przydatności. Naturalnie też wtedy jest się przeciwnym wszelkim zmianom, które niesie ze sobą mobile — choć to przypadek każdej nowej technologii.

Jeśli duża organizacja mocą zarządu podejmuje decyzję o rozpoczęciu projektu mobilnego, to w grę wchodzą czynniki, które zazwyczaj nie manifestują się w małych firmach i startupach.

Jednym z najważniejszych jest czynnik ludzki i obawa pracowników przed zmianą. Nowy projekt wymaga nowej wiedzy i uczenia się nowych rzeczy — czasem sprzecznych z dotychczasowymi zasadami. Jednocześnie wymagane są nowe procesy i procedury, co wpływa na postrzeganie nowo powstałego zespołu przez resztę organizacji.

Istnieje duża szansa, że nowy dział stanie się automatycznie konkurencją wewnętrzną walczącą o te same zasoby, co reszta działów. W dodatku z racji tego, że jest jednostką „eksperymentalną” i musi testować nowe podejścia i technologie, wolno mu więcej, co nie jest dobrze widziane przez ustabilizowaną strukturę ze sprawdzonymi zasadami działania.

Prowadzi to do napięć strukturalnych — na przykład, gdy okazuje się, że nowy dział wymaga oprogramowania, które jest niezgodne z zasadami bezpieczeństwa organizacji lub dział analiz nie potrafi obliczyć skuteczności działania, gdyż nie rozumie różnicy definicyjnej między użytkownikiem strony internetowej, a użytkownikiem aplikacji mobilnej.

Pracowałem kiedyś nad aplikacją i stroną mobilną korporacji z bardzo mocnym brandingiem i rozpoznawalnym logotypem. Niestety, w swoim brandbooku firma nie miała rozdziału poświęconego mobile’owi. Ostatecznie z konieczności stworzyliśmy go sami i dodaliśmy do oficjalnego brandbooka. Cała operacja odbyła się bez wielotygodniowego debatowania i sesji kreatywnych ze studiem kreatywnym, które były potrzebne przy każdej innej części dokumentu.

Mobile w grupach mediowych

Postanowiłem wyróżnić grupy mediowe z korporacji ze względu na ich specyficzną rolę i misję, jaką pełnią w społeczeństwie.

Mobile web pożera coraz szybciej desktop web, oferując w zamian lepszą dostępność i wygodę użytkową, ale… znacznie mniej reklamowego real estatewydawcom. Z kolei mobilne aplikacje kontentowe kanibalizują zarówno desktop web, jak i mobile web, wymagając kilkakrotnie więcej czasu i środków do produkcji i dając jeszcze mniej miejsca na monetyzację. To stawia wydawców w trudnej sytuacji: muszą być tam, gdzie ich użytkownicy, ale wiedzą, że koszt dotarcia do nich, jest znacznie wyższy niż dotychczas, a zwrot z inwestycji trudniejszy do osiągnięcia.

To podstawowy problem w rozwoju prasy mobilnej na naszym rynku: świadomość tego, że prawdopodobnie nie da się na nim zarobić tak samo jak kiedyś w tradycyjnym internecie.

Ironią losu jest to, że intencjonalna rezygnacja z mobile’a niczego nie uratuje, nie zwolni też tego trendu. Konsumpcja mobilna rośnie bowiem równie szybko także na stronach ewidentnie desktopowych, ale użytkownicy już zrozumieli, co potrafią ich smartfony i tablety — oczekują więc, że to, co na nich wyświetlają, będzie dostosowane do ich urządzeń. A jeśli nie, to pójdą tam, gdzie jest łatwiej, prościej i „działa”.

Trzeba więc być na tym rynku, wymusić na sobie konieczność zmian i nowego myślenia skoncentrowanego na użytkowniku oraz „otaczania go” swoimi usługami i treścią.

To wiedzą startupy mobile-firsti mobile-only– czas, aby nauczyły się tego również podmioty desktop-firsti desktop-only.

W jednej grupie mediowej spotkałem się z kuriozalną sytuacją: jej dział mobilny, mimo dysponowania ogromnym potencjałem reklamy mobilnej, w ogóle jej nie sprzedawał, przez co placementy reklamowe były zapełniane w 90 procentach o wiele tańszą reklamą z sieci mobilnych bądź reklamą własną. Nawet po przeszkoleniu sprzedawców z powiększonej oferty nic nie drgnęło. Okazało się, że sprzedawcom nie opłacało się praktycznie wdrażać wiedzy o reklamie mobilnej, ponieważ sprzedanie czegoś nowego jest trudniejsze i bardziej nieprzewidywalne niż sprzedanie czegoś wszystkim znanego. Do tego pojawiły się obawy wynikające z niewiedzy — po stronie sprzedawców i klientów. Nie pomogło nawet dwukrotne zwiększenie prowizji w stosunku do standardowych stawek za reklamę desktopową.

Zalecana dalsza lektura

- Przełomowe innowacje. Możliwości rozwoju czy zagrożenia dla przedsiębiorstwa, Clayton M. Christensen


[1]Przełomowe innowacje. Możliwości rozwoju czy zagrożenia dla przedsiębiorstwa, Clayton M. Christensen,Wydawnictwo Naukowe PWN, Warszawa 2010

[2] Disruptive innovation, http://en.wikipedia.org/wiki/Disruptive_innovation

[3] Changes in rankings of smartphone search results, http://googlewebmastercentral.blogspot.com/2013/06/changes-in-rankings-of-smartphone_11.html

Rozdział 4 Strategia mobilna

Na rynku tak świeżym jak mobile najpierw pojawia się ochota organizacji na bezpieczne przetestowanie nowych rozwiązań, a dopiero później, po uzyskaniu wstępnej walidacji, gotowość budowania pełnoprawnego produktu. Takie testowanie głębokości gruntu to rozsądne podejście, ale liderzy rynkowi zazwyczaj wywodzą się z firm, które inwestują w innowacje, a to oznacza, że wstępna walidacja jest jedynie potwierdzeniem kierunku rozwoju, a nie celem samym w sobie.

Istnieje mnóstwo definicji strategii i podręczników, z których można czerpać wiedzę o niej, ale wszystkie z nich zgadzają się, że strategia, w swojej ogólnej formie, to plan stworzony, by osiągnąć najważniejszy cel.

Dobra strategia jasno definiuje wyzwanie i określa kierunek rozwoju oraz zmusza do koncentracji na tym, co pozwala przezwyciężać przeszkody. Dobra strategia zaczyna się od przyznania, że istnieją problemy.

Zła strategia składa się z myślenia życzeniowego i skupia na bliżej nieokreślonych, mglistych celach. Zła strategia zaprzecza istnieniu problemów.

Dobra strategia odpowiada na pytania: dlaczego?, jak?, gdzie?, kiedy?i kto?. Nie buduje na istniejących siłach, ale jest źródłem siły organizacji.

Richard Rumelt za przykład dobrej strategii w swojej książce Dobra i zła strategia[1]podaje DARPA (Defense Advanced Research Projects Agency– Agencja Zaawansowanych Projektów Badawczych w Obszarze Obronności, USA — przyp. red.):

A basic challenge for any military research organization is matching military problems with technological opportunities, including the new operational concepts those technologies make possible. Parts of this challenge are extremely difficult because: (1) some military problems have no easy or obvious technical solutions; and (2) some emerging technologies may have far-reaching military consequences that are still unclear. DARPA focuses its investments on this “DARPA-hard” niche — a set of technical challenges that, if solved, will be of enormous benefit to U.S. national security, even if the risk of technical failure is high[2].

W tym kontekście nowy strategy statement zaprezentowany przez Twittera w 2014 roku brzmi jak zła strategia:

Reach the largest daily audience in the world by connecting everyone to their world via our information sharing and distribution platform products and be one of the top revenue generating Internet companies in the world[3].

Wśród osób zajmujących się zawodowo biznesem technologicznym toczy się spór o to, czy istnieje coś takiego jak strategia mobilna. Podstawowym argumentem przeciwników jest stwierdzenie, że strategia jest jedna i wspólna dla całej firmy. Nie może więc być oddzielnej strategii mobilnej, tak jak oddzielnej strategii internetowej, socialowej czy dowolnej innej. Dobra strategia jest uniwersalna, a jej zasady są aplikowalne na wszystkie dziedziny działania firmy.

Zwolennicy idei startegii mobilnej wskazują, że mnogość dróg prowadzących do osiągnięcia celów strategicznych wymaga kategoryzacji. Dlatego powstają strategie komunikacyjne, strategie sprzedażowe czy strategie mobilne — jako przełożenie ogólnego założenia na konkretne dziedziny funkcjonowania firmy.

Znając oba te stanowiska, postanowiłem pozostać przy pojęciu strategia mobilna, aby zachować spójność i klarowność przekazu.

Obecnie mobile to prawdopodobnie najlepszy sposób na szybkie zbudowanie przewagi strategicznej nad konkurencją dzięki technologii. Pozwala na najszybsze zbudowanie wartości, gdyż ta wartość wypływa z samej specyfiki nowego kanału. Mobile zawsze jest osobisty, zawsze dostępny i pod ręką.

Żeby mobile zaczął przynosić wartość, musi zostać spełnionych wiele warunków — zaczynając od popularności nowych technologii wśród użytkowników, a kończąc na odpowiednio wydajnych telefonach, które umożliwiają obsługę skomplikowanych operacji, jak płatności i odtwarzanie multimediów.

Dopiero na tak użyźnionej glebie mają możliwość kiełkować wartościowe produkty mobilne. Firma mając aplikację mobilną, zyskuje szereg przewag: zwiększa liczbę punktów styku z marką, dodaje nowy kanał komunikacji, buduje intymniejszą relację, zdobywa więcej danych o swoim kliencie. Niewykorzystanie tych przewag może zemścić się w przyszłości.

Podstawowe pytanie, jakie musi sobie zadać menedżer, który chce osiągnąć przewagę dzięki aplikacji, to pytanie o konkretny cel. Cele mogą być różne: od zwiększenia sprzedaży, przez poprawienie zaangażowania i wydłużenie czasu spędzanego z marką, po większą liczbę wyświetleń reklam.

Czasami udostępnienie użytkownikom aplikacji może być celem samym w sobie. Biorąc pod uwagę, jak popularny jest temat aplikacji mobilnych, posiadanie przez firmę koszulki lidera i wypuszczenie notki prasowej z informacją, że to ona w swojej branży jest pierwsza z aplikacją mobilną, może budować na rynku przeświadczenie, że jest innowacyjna i na bieżąco ze światowymi trendami.

Cztery typy taktyk mobilnych

Typ non-mobile

Intencjonalny brak inwestowania w technologie mobline jest najprostszym do wdrożenia typem strategii, bo nie wymaga zbyt dużo aktywności. Takie podejście ma krótkookresowy sens, jeśli wynika z faktycznej i szczerej analizy sytuacji oraz dobrej znajomości swoich klientów.

Atrakcyjność mobile’a jest tak duża, że dobry produkt mobilny spowoduje kanibalizację innych strumieni przychodów. Jest to dobrze widoczne w przypadku grup mediowych, gdzie względnie wolne wdrażanie aplikacji mobilnych wynika z opozycji działów internetowych (strony desktopowe) i papierowych (gazety i magazyny).

Tim Cook, CEO Apple Inc., zapytany, czy nie boi się wzajemnej kanibalizacji swoich produktów, stwierdził, że lepiej kanibalizować własne produkty, niż być zjedzonym przez konkurencję[4].

Argumentami za prowadzeniem strategii non-mobile może być brak przygotowania organizacji do tworzenia nowego kanału. Słabo wyedukowany mobilnie zespół, konieczność wprowadzania nowych procedur i zmiany starych oraz zbyt duża niepewność co do potencjalnych zysków powoduje, że organizacja przyjmuje podejście przeczekania „pierwszej fali” i chce wyciągnąć wnioski, analizując inwestycje konkurencji. Świadome oddanie pola sprowadza się do tego, że to konkurencja, inwestując większe środki, będzie budować rynek i świadomość odbiorców mobilnych, a nasza organizacja — angażować środki w to, co już potrafi (czyli w działania analogowe czy sprzedaż dzięki klasycznej stronie internetowej).

Na podejściu non-mobile mogą korzystać inne podmioty na rynku — nie tylko konkurencyjne. Na przykład, trudno wyobrazić sobie restaurację z własną aplikacją mobilną do zamawiania jedzenia. Rynek jest za mały, aby koszty jej stworzenia i utrzymania się zwróciły. Ale startup, który agreguje oferty restuaracji i pozwala na zamówienie najlepszego dania, będzie zainteresowany tym, aby stworzyć aplikację mobilną z całą swoją ofertą. Zdejmuje w ten sposób z restauracji niepotrzebny koszt, a sam staje się pośrednikiem między usługą a klientem.

Podejście non-mobile może być mądrym podejściem, zakładając, że:

- konkurencji nie uda się stworzyć w pierwszych cyklach produkcyjnych wystarczająco dobrego produktu mobilnego,

- naszej organizacji uda się w przyszłości stworzyć o znacznie lepszy produkt, ucząc się na cudzych błędach.

Typ mobile-second

Podejście mobile-second zakłada, że organizacja zdecydowała o istotności mobile’a w rozwoju, ale najpierw musi skupić się na rozwoju podstawowego kanału przychodów. W międzyczasie zaczynają się pierwsze działania mobile’owe, czyli budowa szkieletu zespołu mobilnego, który początkowo pełni rolę laboratorium eksperymentalnego. Aplikacja bądź strona mobilna stanowi uzupełnienie portfolio kanałów sprzedaży. To metoda „otaczania klienta” i wspierania poczucia bliskości między nim a marką.

W przypadku firm technologicznych podejście mobile-second oznacza dokładniej „web first, mobile second”. Przekłada się to na taktykę, w której największa wartość dla klientów płynie z pełnej strony internetowej, a aplikacja lub strona mobilna jest ograniczona funkcjonalnie[5].

Podejście mobile-second jest dobrym sposobem na zbadanie, czy faktycznie działania w zakresie tworzenia aplikacji mobilnej mają biznesowy sens, czyli czy coraz większe nasycenie smartfonami i tabletami koreluje ze wzrostem przychodów z tego kanału. Jeśli faktycznie ta korelacja następuje, to można spodziewać się, że organizacja wkrótce rozpocznie transformację w stronę bycia mobile-first.

PizzaPortal.pl jest największym w Polsce dostawcą jedzenia na zamówienie przez Internet. Jej pierwsze aplikacje mobilne zostały udostępnione użytkownikom na początku 2013 roku, a pod koniec tego roku zakupy przez aplikacje mobilne stanowiły już 11%, a rok później — 18%. Tak szybki wzrost połączony jest jednocześnie z innymi aspektami: zamawianie za pomocą smartfona jest szybsze i oferuje więcej udogodnień niż strona WWW, a zamówienia generowane w aplikacjach są większe kwotowo. Mobile stanowi więc naturalny kierunek ekspansji biznesowej. Yogiyo, południokoreański odpowiednik PizzaPortal.pl z tej samej grupy kapitałowej, notuje ponad 90% zamówień z urządzeń mobilnych. Z tego powodu firma nie zamierza rozwijać dalej wersji desktopowej swojej strony i skupia się niemal całkowicie na użytkownikach mobilnych.

Typ mobile-first

Podejście mobile-first zakłada, że to kanał mobilny jest najważniejszym sposobem interakcji z użytkownikami z całego portfolio organizacji. Każdy inny sposób ma rolę pomocniczą lub uzupełniającą w stosunku do aplikacji bądź strony mobilnej.

Firmy stają się mobile-first na dwa sposoby: albo od samego początku są tak planowane (Instagram), albo podążają za oczekiwaniami swoich klientów (Audioteka.pl).

Instagram powstał w 2010 roku jako aplikacja na platformę iOS. To jeden z pierwszych przykładów projektu, który swój sukces zawdzięcza skupieniu się na jednej niszy i jednej platformie, a nie na tworzeniu rozwiązań wielokanałowych. Było to intencjonalne, ponieważ tworzenie serwisu, który miałby funkcjonować zarówno jako aplikacja mobilna, jak i jako serwis WWW powodowałby stawanie w szranki z takim gigantem, jak Flickr. Po sukcesie aplikacji na iOS przyszła pora na uruchomienie wersji na platformę Android oraz udostępnienie wersji WWW, która pozwala jedynie na przeglądanie zdjęć zrobionych w aplikacji mobilnej.

Audioteka.pl to polski sklep z książkami w wersji audio. Firma zaczynała od sprzedaży plików dźwiękowych przez stronę WWW, które użytkownik po ściągnięciu mógł nagrać na płytę CD i odsłuchać na przykład w samochodzie. Jednak wraz z upowszechnianiem się telefonów odtwarzających audio okazało się, że produkcje Audioteki.pl coraz częściej słuchane są właśnie w ten sposób. Twórcy sklepu zdecydowali się na stworzenie aplikacji mobilnej, która pełni funkcję zarówno sklepu, jak i odtwarzacza. Teraz można kupić wybrany audiobook od razu w aplikacji i chwilę później zacząć go słuchać.

Typ mobile-only

Takie podejście stosuje się w przypadkach, gdy przewaga usługi lub produktu tkwi właśnie w wykorzystaniu unikatowych funkcji smartfonów i tabletów (na przykład geolokalizacja, dotykowy ekran, notyfikacje) lub gdy strategia rozwoju zakłada skupienie się i inwestowanie tylko w jeden, najbardziej obiecujący kanał, którym okazuje się mobile.

Pierwszy przypadek mobile-only najlepiej obrazuje Uber, czyli aplikacja do zamawiania przewozów indywidualnych (konkurencyjnych do taksówek). Przewaga Ubera polega na tym, że wszystkie operacje związane z rejestracją, zamówieniem przejazdu i płatnością przeprowadza się za pomocą telefonu. Strona WWW istnieje, ale jest statyczną listą funkcji z odnośnikami do sklepów z aplikacjami mobilnymi.

Innym przykładem jest producent gier mobilnych Ketchapp. Gry tego studia charakteryzują się tym, że są bardzo proste. Czas potrzebny na opanowanie zasad każdej z trzydziestu gier jest bardzo krótki, a każda rozgrywka zajmuje od kilku sekund do kilku minut. Taki format gry ma sens w przypadku, gdy urządzenie, na którym jest włączona, pozwala i ułatwia tak szybkie interakcje. Strona internetowa Ketchapp jest jedynie listą odnośników do poszczególnych gier [6].

Wyciąganie wniosków z dostępnych danych

Przy budowaniu strategii mobilnej szczególną uwagę należy zwracać na dane i definicje, którymi się operuje. Na początku książki opisywałem, dlaczego badania deklaratywne pokazują tylko powierzchnię rzeczywistości, na podstawie której łatwo pomylić przyczynę ze skutkiem.

Inny problem to złe definicje. Na przykład: w badaniu gemiusRanking (także cytowanym w tej książce) w przypadku raportowania urządzeń mobilnych pojawia się informacja o zdecydowanej przewadze produktów Apple w ruchu mobilnym na polskich stronach objętych badaniami Gemius.

Spójrzmy na dane gemiusRanking dotyczące urządzeń mobilnych w styczniu 2015 roku:

Tak przedstawione wyniki sugerują, że Apple dominuje ilościowo na polskim rynku ze swoim iPhonem. Co ciekawsze iPad, jedyny tablet w zestawieniu, jest popularniejszy niż cała reszta smartfonów poza iPhonem.

Aby jednak mieć realny obraz, trzeba na zestawienie spojrzeć z trochę innej perspektywy:

GemiusRanking wyświetla dane na podstawie skryptu GemiusTraffic zainstalowanego na stronie internetowej. Z bliżej nieznanego powodu skrypt wrzuca wszystkie iPhone’y do jednego worka, a warto pamiętać, że od premiery pierwszej wersji w 2007 roku mamy w obiegu rynkowym 10 iPhone’ów oraz pięć iPodów touch, które prawdopodobnie w badaniu także są zliczane jako iPhone’y.

W pierwszej dziesiątce najpopularniejszych urządzeń mobilnych pięć miejsc należy do Samsunga. Jeśli zgrupujemy je w podobny sposób jak iPhone’y, to okaże się, że razem generują 11,6% ruchu mobilnego w Polsce.

Jeśli wyjdziemy poza pierwszą dziesiątkę i spojrzymy na „długi ogon”, to okazuje się, że w pierwszej dwudziestce aż dziewięć urządzeń to Samsungi z grupy Galaxy, które w sumie mają 14,9% udziału w generowaniu ruchu mobilnego — czyli więcej niż iPhone. Prawdopodobnie gdybyśmy zanalizowali pierwszą pięćdziesiątkę i setkę urządzeń to te dysproporcje byłyby jeszcze większe.

I faktycznie — gdy spojrzymy w inne badanie gemiusTraffic, to widać, że urządzenia Samsunga generują 33,3% odsłon mobilnych, a Apple’a mniej — bo 26,4%[7].

Nieprecyzyjne wnioski strategiczne można wyciągać także z własnych danych biznesowych. W przypadku czerpania wiedzy na temat udziału rynkowego smartfonów ze statystyk odwiedziń własnej strony pojawia się klasyczny problem jajka i kury. Jeśli nie mamy strony dostosowanej do przeglądarek mobilnych, to będziemy mieć mały procentowy udział odwiedzin ze smartfonów — więc… nie będzie dobrej zachęty do tworzenia strony mobilnej.

Co ciekawe — bardzo korzystają na tym tablety — głównie iPady. Zazwyczaj strony desktopowe wyświetlają się bezproblemowo na tabletach i, aby dostać się do pożądanej treści, użytkownik nie jest zmuszany do nadmiernego wysiłku (jak powiększanie i przewijanie).

W przypadku aplikacji mobilnej jedno ściągnięcie nie oznacza, że mamy jednego użytkownika więcej. Istnieje bowiem duża przepaść między ściągnięciem aplikacji a aktywnym użytkowaniem — sama aplikacja po pobraniu może nie być ani razu włączona. Często użytkownika do pobrania aplikacji przekonuje ładna ikona, chwilowa obniżka ceny, rekomendacja znajomego. Po ściągnięciu ląduje na końcu wszystkich już zainstalowanych aplikacji, co prawie nigdy nie oznacza pierwszego, głównego ekranu telefonu. Przez to użytkownik ma mało sposobności, aby ją zobaczyć i włączyć.

Jeśli jednak nawet to zrobi, to włączona aplikacja nie oznacza jeszcze zarejestrowania użytkownika. Tymczasem większość przynoszących długotrwałą wartość aplikacji wymaga od użytkownika dwóch rzeczy: rejestracji i zezwoleń — dostępu do książki adresowej, pozycji GPS czy zgody na wysyłanie powiadomień push. W przypadku iOS dzieje się to przy pierwszym włączeniu aplikacji (lub przy pierwszym wystąpieniu konieczności skorzystania z danej funkcji), w przypadku Androida użytkownik akceptuje dostępy podczas instalacji aplikacji — czyli jeszcze przed jej włączeniem.

Przy zbyt powierzchownym podejściu może się więc okazać, że mimo osiągnięcia zakładanego celu (na przykład odpowiedniej liczby ściągnięć aplikacji), nie następują oczekiwane pozytywne konsekwencje (na przykład zwiększona sprzedaż).

Aby wypracować dobre cele strategiczne należy operować na najbardziej zbliżonych do rzeczywistości danych. Warto więc do nich podchodzić krytycznie zamiast traktować jako aksjomat.

Jakość kontra ilość

Jednym z podstawowych pytań, przed jakimi staje menedżer, jest: które platformy mobilne należy obsługiwać jako pierwsze? Aby zacząć pracę nad znalezieniem odpowiedzi, należy zmodyfikować pytanie i zamiast: którą platformę obsługiwać jako pierwszą?, zapytać: co organizacja będzie cenić wyżej — jakość czy ilość użytkowników?

Istnieje wiele powodów, aby wyżej cenić ilość zamiast jakości. Na przykład, gdy firmie zależy na jak największym zasięgu, bo zarabia na reklamach w modelu CPM (czyli liczbie wyświetleń reklamy). Wtedy rozróżnienie, czy reklamę widzi prezes spółki giełdowej na iPhonie 6, czy student na pięcioletnim Androidzie ma małe znaczenie. Firmie może zależeć także na jak najszerszym propagowaniu swojego komunikatu, który nie przekłada się bezpośrednio na sprzedaż. Na przykład, w wypadku marek FMCG (fast-moving consumer goods– produkty szybkozbywalne) lepszym narzędziem komunikacji jest aplikacja na Androida, który jest czterokrotnie bardziej popularny niż iOS, mimo że jego użytkownicy znacznie mniej aktywnie korzystają ze swoich telefonów. Innym przykładem jest skorzystanie z efektu sieciowego: im więcej użytkowników, tym wartość systemu w ich oczach się zwiększa (przykład Facebooka, ale także SpeedAlarmu i Yanosika — aplikacji ostrzegających przed radarami i kontrolami policji).

Jeśli jednak celem aplikacji jest dotarcie do użytkowników, którzy identyfikują się ze swoim telefonem i są otwarci na innowacje, to o wiele lepiej jest skupić się na mniejszej, ale znacznie bardziej aktywnej grupie użytkowników iOS. Dzięki większej wiedzy na temat możliwości swoich urządzeń, chętniej wpisują dane swoich kart kredytowych i wykonują więcej operacji finansowych na swoich telefonach i tabletach. Działa tutaj zasada Pareto: choć około 80% telefonów to Androidy, jednak to właśnie pozostałe iOS-y generują większość płatności mobilnych.

Stawianie na ilość ma jeszcze jedną istotną konsekwencję — piractwo. Android, ze względu na przyjętą strategię zasięgową oraz powiązaną z nią otwartość systemową, stał się platformą znaną z omijania praw autorskich i płatności. Producent gry Monument Valley dostępnej na iOS i Android na bazie instalacji na 10 milionach urządzeń ogłosił, że tylko 5% instalacji na Androidzie było płatnych — w odróżnieniu od 40% na iOS[8]. Nawet biorąc pod uwagę akcje promocyjne, twórca gry określa poziom piractwa na platformie Android w okolicach 95%. Podobne efekty potwierdzają także inni producenci gier mobilnych[9].

Ze względu na szerokie spektrum użytkowników Androida producenci sprzętu zaczęli tworzyć urządzenia, które odpowiadają różnym zapotrzebowaniom, co jednocześnie przyniosło silne rozdrobnienie i segmentację rynku. W związku z tym mamy telefony z Androidem, które kosztują z umową 1 zł, ale także takie, które dochodzą do 2 tysięcy zł (i dwa razy więcej bez kontraktu). To oznacza, że zupełnie inni użytkownicy będą mieścić się w tych dwóch skrajnych koszykach. Nie można więc traktować Androida jako jednolitej platformy.

Rozkład użytkowników i ich systemów operacyjnych

Postanowiłem więc podzielić urządzenia z Androidem według podobnej zasady, jaką stosuje się przy segmentowaniu wielkości i rozdzielczości ekranów — gdyż te parametry najlepiej korelują się z kosztem poszczególnych modeli oraz z siłą nabywczą użytkowników. Wyróżniam trzy segmenty:

- Android low-end — to wszystkie „słuchawki z Androidem”, których najważniejszą zaletą jest cena. Szybkość, jakość wykonania, a nawet system operacyjny ma drugorzędne znaczenie,

- Android medium level — to telefony dla osób aspirujących. Rozróżniają już modele i systemy operacyjne, wiedzą, że ich telefon sporo potrafi, ale jeszcze nie stać ich na nic więcej,

- Android hi-end — to modele premium, stworzone, aby ścigać się na jakość i możliwości z iPhone’ami.

Windows Phone w przypadku Polski mieści się w tej układance dokładnie w środku stawki. Pod względem ilości użytkowników przegonił iOS, ale daleko mu do zasięgu Androida. Z drugiej strony to Microsoft najmocniej inwestuje się w budowanie swojej platformy w naszym kraju. Angażuje użytkowników ciągłymi kampaniami reklamowymi i wspólnymi promocjami z operatorami telekomunikacyjnymi. Jednocześnie wzmacnia społeczność twórców aplikacji przez szkolenia, wsparcie infrastrukturalne i specjalne akcje reklamowe oraz ekspozycje polskich produktów w swoim sklepie mobilnym.

Reasumując:

- Jeśli strategicznym celem jest budowanie zasięgu, to najlepiej jest tworzyć aplikacje na wszystkie trzy platformy jednocześnie.

- Jeśli jednak fundusze na to nie pozwalają, to należy skupić się na Androidzie low-end i medium level.

- Jeśli firmie zależy na budowaniu biznesu opartego na zaawansowanych funkcjach telefonu oraz obsłudze płatności, należy skupić się na iOS.

Modele biznesowe

Jeśli aplikacja i/lub strona są tworzone jako jeden z kolejnych kanałów zarabiania, to model biznesowy jest już z góry narzucony przez strategię firmy. Może się jednak okazać, że nowe modele biznesowe wynikające z możliwości technologii mobilnych, spowodują zmianę w całej organizacji bądź stworzą nową silną konkurencję na już zdefiniowanym rynku.

Istnieje pięć podstawowych grup modeli biznesowych opartych na aplikacjach mobilnych. Wyróżnia się je na podstawie mechanizmów płatności (bądź ich braku):

Darmowa aplikacja

Darmowe aplikacje stanowiły w 2013 roku 90% wszystkich dostępnych w Apple App Store[10]. Ta tendencja jest jeszcze wyraźniejsza w Google Play. Użytkownicy nie chcą płacić za aplikacje mobilne.

Najprostszą metodą na monetyzację aplikacji jest więc wyświetlanie reklam mobilnych w bezpłatnych aplikacjach. Jest to przeniesienie modelu znanego z prasy i mediów, gdzie treści są dostępne za darmo, ale przeplatane reklamami. Dlatego naturalne jest, że wszystkie grupy mediowe tworzą wersje mobilne swoich serwisów, licząc na przeniesienie istniejącego już modelu biznesowego do nowego środowiska.

Aplikacje darmowe często są uzupełnieniem już istniejącego biznesu. Wtedy ich rolą jest budowanie przywiązania do marki i nie muszą wprost generować żadnego dochodu. Trakuje się je jako koszt marketingowy, a nie inwestycję technologiczną. Czasami też aplikacja jest darmowa, ale możliwość skorzystania z jej funkcji pojawia się dopiero wtedy, gdy poza sklepem mobilnym zostanie wykonana opłata. Tak działają usługi streamowania muzyki, jak na przykład Spotify.

Darmowa aplikacja z In-App Purchase (Freemium)

Ten model zakłada udostępnienie użytkownikom aplikacji z podstawowymi elementami za darmo, ale w środku programu istnieje możliwość dokupienia dodatkowych funkcji, treści lub usunięcia reklam.

Ten model jest obecnie najpopularniejszym sposobem zarabiania na aplikacjach, gdyż niesie korzyści użytkownikom (mają dostęp do podstawowych funkcji za darmo) i twórcom (mają sposób na pokazanie wartości i obniżenie progu wejścia). W 2013 roku 71% wszystkich dochodów z aplikacji mobilnych pochodziło z płatności In-App w ramach darmowych aplikacji.

Najlepiej do tego modelu zaadaptowały się gry mobilne działające na zasadach free to play. Oznacza to, że gra dostępna jest za darmo w normalnym trybie. Jeśli jednak dokonamy opłaty wewnątrz gry, uzyskujemy dodatkowe moce bądź wewnętrzną wirtualną walutę, dzięki której nasz bohater szybciej zdobywa doświadczenie czy możemy szybciej konstruować budynki.

Ogólna zasada głosi, że 1–5% użytkowników wersji darmowej przeniesie się na wersję płatną — w zależności od tego, jak zoptymalizowana w tym celu jest aplikacja. Estymuje się, że jedna z najpopularniejszych gier tego typu, Clash of Clans, generuje w USA 1,7 mln dolarów dochodu dziennie, mając 5,5 mln aktywnych użytkowników[11].

Ten model, dzięki swojej popularności i ogromnym możliwościom monetyzacji, stał się jednocześnie modelem najbardziej polaryzującym użytkowników. Mówi się, że gry free to playzamieniają się w pay to wini faktycznie dochodzi do segmentowania użytkowników na tych, którzy mają i nie mają skłonności do uzależnień podobnych do hazardu.

Aplikacja płatna jednorazowo

Obok aplikacji darmowych to druga pierwotna kategoria w sklepach mobilnych. Model zakłada, że aplikacja jest płatna jednorazowo — tuż przed instalacją. W 2013 roku 24% dochodów z aplikacji było generowane właśnie w tym modelu.

Większość rynkowych analiz sugeruje, że model jednorazowej płatności za aplikacje staje się coraz mniej popularny. Wśród użytkowników istnieje przekonanie, że aplikacje powinny być darmowe, co ma silne odzwierciedlenie w ekosystemie sklepów mobilnych, w których średnia cena za płatną aplikację maleje z każdym rokiem. Dodatkowo dokonywanie płatności przed skorzystaniem jest zbyt dużą barierą. Z tego powodu lepszym rozwiązaniem jest model freemium opisywany wcześniej.

Problem tego modelu wynika także z tego, że opłata jest jednorazowa. Jeśli aplikacja wymaga komunikacji z zewnętrznymi systemami, które należy niezależnie utrzymywać, to im dłużej użytkownik korzysta z aplikacji, tym bardziej spada zysk. To prowadzi do paradoksalnej sytuacji, gdy najbardziej wartościowymi biznesowo użytkownikami są ci, którzy kupili aplikację i nigdy z niej nie skorzystali.

To jednak nie zmienia faktu, że aplikacje płatne jednorazowo to najprostszy model biznesowy, bo utrwalony wśród użytkowników przez sprzedaż oprogramowania na komputery stacjonarne i gier na konsole. Jednym z największych sukcesów tego modelu jest gra Infinity Blade wydana w grudniu 2010 roku. Wystarczyło sześć miesięcy, aby osiągnęła sprzedaż na poziomie 10 mln dolarów[12]. Tim Sweeney, wydawca gry, stwierdził, że biorąc pod uwagę koszty produkcji i sprzedaż, Infinity Blade jest najbardziej zyskowną grą w historii studia, przebijając pod tym względem flagowy tytuł Gears of War[13].

Górną granicą ceny za aplikację w App Store jest 999 dolarów, w Google Play — 200 dolarów, a w Microsoft Apps+Games — 499,99 dolarów. Istnieje kilka przykładów aplikacji, które dotarły do tej granicy. Są to głównie produkty specjalistyczne, ale największy szum medialny wywołała aplikacja I’m rich za 999 dolarów, która nie robiła nic poza wyświetlaniem tego napisu. Zanim Apple usunęło ją ze swojego sklepu, osiem osób zdążyło ją kupić, w tym jedna przypadkowo[14].

Aplikacja z płatną subskrypcją

To drugi model charakterystyczny dla tradycyjnych mediów. Użytkownik po ściągnięciu aplikacji jest proszony o uzupełnienie swoich danych w celu uruchomienia abonamentu. Wtedy co ustalony okres z jego karty pobierana jest ta sama kwota — jako zapłata za dostęp do funkcji i treści. Wszystko dzieje się bezpośrednio w telefonie, w ramach mechanizmów sklepu mobilnego.

Ten system najczęściej wykorzystują podmioty, które udostępniają dużo treści w stałych odstępach czasu, na przykład dzienniki, tygodniki i miesięczniki. Jednocześnie metodycznie jest on najbliższy internetowemu modelowi SaaS (Software as a Service), gdzie rekurencyjne płatności pozwalają na budowanie trakcji i stabilnego biznesu.

Obecna implementacja subskrypcji w sklepach mobilnych stwarza dużo problemów użytkowych. Żaden ze sklepów mobilnych nie ma jeszcze jasnego i prostego systemu zarządzania abonamentami, co powoduje frustracje użytkowników, którzy chcą na przykład zrezygnować z takiej usługi. Jest to jeden z głównych powodów, dla których model abonamentowy nie jest jeszcze w pełni wykorzystywany przez twórców aplikacji mobilnych. Może on jednak w przyszłości stanowić konkurencyjne rozwiązanie dla In-App Purchase przede wszystkim ze względu na autoodnawialność, która jest stabilnym i skalowalnym sposobem na budowanie biznesu.

Darmowa aplikacja z systemem transakcyjnym

W tym modelu, w przeciwieństwie do In-App Purchase i subskrypcji, metoda płatności została wyniesiona poza mechanizmy sklepów mobilnych, ale z perspektywy użytkownika płatność ciągle odbywa się w ramach aplikacji.

Istnieje wiele powodów, dla których oddzielenie płatności od sklepu jest korzystniejsze, mimo że wymaga od użytkownika dodatkowej aktywności (jak wpisanie numeru karty kredytowej). Jednym z najważniejszych jest zwiększenie kontroli nad procesem sprzedażowym i uniezależnienie się od platformy mobilnej. Trzeba jednak pamiętać, że w większości sklepów nie można korzystać z zewnętrznych systemów płatności, jeśli w aplikacji dochodzi do sprzedaży treści cyfrowych (tzw. virtual goods). Wynika to z polityki sklepów, które pobierają (zazwyczaj) 30-procentową opłatę za treści cyfrowe sprzedawane wewnątrz aplikacji, a pobieranie tych opłat byłoby niemożliwe przy zewnętrznym systemie płatności.

Biznes, który chce rozpocząć pobieranie płatności mobilnych poza sklepem, ma kilka możliwości do wyboru:

- płatności kartą bądź pobieranie opłat z konta bankowego,

- pay-by-link,

- pobieranie opłat przez SMS-y premium,

- direct billing,

- one-click payments,

- przedpłacony e-portfel.

Matryca różnych typów płatności mobilnych

Płatność kartą płatnicząnie jest w Polsce popularna, choć obecnie ta metoda wydaje się najprostsza. Wystarczy raz podać imię i nazwisko, numer karty oraz kod zabezpieczający CVV/CVC. Czasami część tych danych może być zeskanowana dzięki aparatowi w telefonie. Przy kolejnym wykorzystaniu usługi dane karty są już w systemie, więc płatność odbywa się automatycznie.

Pay-by-link, czyli szybki przelew, to alternatywne rozwiązanie, które wymaga współpracy z bankiem. Ten bowiem musi być przygotowany, by odczytać i przenieść informację o transakcji użytkownika do swojego systemu, wyświetlić mu bezpieczną stronę mobilną i dać możliwość autoryzacji za pomocą SMS-a. Ten ostatni element procesu jest według Krajowego Nadzoru Finansowego działaniem potencjalnie niebezpiecznym ze względu na to, że na tym samym urządzeniu odbywa się kupno i potwierdzenie transakcji.

SMS-y premiumdziałają na podstawie umów podpisanych z operatorami telekomunikacyjnymi. Operator udostępnia specjalny numer, na który użytkownik musi wysłać SMS o zwiększonym koszcie. W odpowiedzi otrzymuje wygenerowany dla niego kod, który wpisany w aplikacji daje mu dostęp do nowych funkcji i treści. Koszt SMS-a premium jest dopisywany do rachunku telefonicznego użytkownika. SMS-y premium cieszyły się ogromną popularnością przed 2007 rokiem, gdy pozwalały na kupowanie dzwonków i tapet. Później ich rola zaczęła spadać, ale wciąż jest najprostszą i uniwersalną metodą płatności znaną wszystkim użytkownikom.

Direct billingto usługa polegająca na obciążaniu konta operatora telekomunikacyjnego opłatami wykonywanymi wewnątrz aplikacji lub za kupno aplikacji. Takie rozwiązanie nie zawsze jest możliwe i wymaga indywidualnych negocjacji z firmami telekomunikacyjnymi. Najprzychylniej patrzą one na aplikacje i usługi, które mogą stanowić część ich VAS, czyli Value Added Services — usług dodanych, które zwiększają lojalność i zaangażowanie użytkowników w ramach sieci (na przykład nawigacja samochodowa czy dostęp do treści cyfrowych).

One-click paymentsto wariacja płatności kartą lub pobrania z konta bankowego. Różnica polega na tym, że użytkownik nie musi za każdym razem uzupełniać danych płatności ani potwierdzać operacji. Robi to za niego system, który pamięta dane wprowadzone przy pierwszej płatności. To, co musi zrobić użytkownik, to potwierdzić, że faktycznie chce dokonać zakupu, a system dokonuje reszty procesu. Najlepszymi przykładami takiego rozwiązania są zakupy w sklepie Amazon.com, iTunes bądź w aplikacji Allegro.

Przedpłacony e-portfel- w tym przypadku w niezależnym systemie tworzone jest wirtualne konto zasilane funduszami użytkownika. Jeśli aplikacja obsługuje dany system e-portfelowy, wtedy po zalogowaniu się w aplikacji użytkownik może operować środkami ze swojego wirtualnego konta.

Wybór najlepszej metody płatności ma krytyczne znaczenie dla opłacalności rozwiązania. Przy wyborze należy wziąć pod uwagę cztery najważniejsze elementy: zasięg danego rozwiązania, wysokość prowizji operatora, koszt wdrożenia i utrzymania oraz łatwość obsługi przez użytkownika. Ostateczny wybór zależy jednak od dopasowania między rozwiązaniem a strategią organizacji.

Analiza konkurencji

Wejście na rynek mobilny musi być poprzedzone analizą konkurencyjnych rozwiązań. Jedną z zalet „platformowego rynku”, jaki oferują App Store, Google Play i Windows App+Games, jest dostęp do usystematyzowanych danych dotyczących każdej aplikacji.

O ile nie jest dobrym pomysłem obsesyjne analizowanie ruchów konkurencji (lepiej ten czas przeznaczyć na budowę własnej strategii), to jednak warto mieć świadomość swojego otoczenia. Skoro nas jeszcze na rynku nie ma, to znaczy, że mamy jedną podstawową przewagę: asymetrię informacji. My możemy dowiedzieć się całkiem dużo o konkurencji, ale ona nic o nas nie wie.

Pierwszy i najprostszy sposób to użycie wyszukiwarki w sklepie. Na przykład, jeśli chciałbym oszacować polski rynek aplikacji do zamawiania taksówek, wpisuję po prostu „taxi” w App Store. Po wyeliminowaniu gier i innych nietrafionych wyników zostaje Złap Taxi, Wezwij Taxi, mytaxi, iTaxi, Taxi5, Uber, Taxi Finder, CAB4YOU, NaviTaxi, Wundercar i Taxity. Bardziej zachwaszczone wyniki dostanę przy wyszukiwaniu w Google Play, a najmniej wyników przy szukaniu w Windows Marketplace. Dlatego w szacowaniu aplikacji konkurencji najlepiej brać pod uwagę App Store (co nie oznacza, że przekłada się to na szacowanie wielkości całego rynku).

Czas przyjrzeć się bliżej poszczególnym aplikacjom, dla przykładu skupimy się na iTaxi. Każda aplikacja ma w sklepie swoją stronę z masą przydatnych informacji. W przypadku App Store są to kategorie:

- Details- pozwala dowiedzieć się, kiedy była ostatnia aktualizacja (im mniej aktualizacji, tym większe prawdopodobieństwo, że aplikacja nie jest dla naszego konkurenta ważna lub po prostu nie żyje — łatwiej będzie szukać wskazówek dotyczących budowy przewagi konkurencyjnej),

- Ratings and Reviews- kopalnia wiedzy. Polecam sprawdzić All versions i szukać skrajnych ocen. Czasami pojawiają się jasne komunikaty, co nie działa (możliwość budowania przewagi), a co działa doskonale (możliwość analizy konkurencyjnej),

- Related- pozwala sprawdzić, jakie inne aplikacje kupują użytkownicy programu, któremu się przyglądamy. To niedoceniana funkcja, a pozwala na określenie, czy na przykład użytkownicy iTaxi mają na swoich telefonach także konkurencyjne aplikacje.

Niestety App Store nie udostępnia danych o ściągnięciach aplikacji poza pokazywaniem najpopularniejszych darmowych, płatnych i najlepiej zarabiających, a Google Play pokazuje bardzo ogólne przedziały liczby instalacji.

Obecnie liderem badania rynku aplikacji jest serwis App Annie, który dostarcza bardzo dobrych danych analitycznych o sklepach. Można na przykład sprawdzić, jak wygląda analiza iTaxi. Polecam zakładkę Rank History, na której sprawdzimy, jak plasowała się aplikacja w rankingach najpopularniejszych aplikacji w całym App Store oraz w konkretnej kategorii.

Najtrudniejsze jest określenie, ile razy dana aplikacja została ściągnięta. Idealny byłby dostęp do informacji o liczbie ściągnięć w czasie, co dałoby podstawy do budowania korelacji między trendami rynkowymi i akcjami marketingowymi a popularnością aplikacji. Na przykład w Warszawie przy rondzie ONZ jest wielka reklama mytaxi. Ciekawe, jaki ma wpływ na pobrania w App Store (ciekawe też, czy przypadkiem nie zwiększa ogólnej percepcji podobnych usług i nie pomaga także iTaxi).

Jeśli aplikacja, której szukamy, jest jedną ze 100 najpopularniejszych w danym miesiącu w Polsce, to możemy skorzystać z rankingu AntyApps przygotowywanego wspólnie z Xyo.net. Xyo.net samo w sobie jest ciekawym narzędziem, choć niewiele już ma wartości analitycznej. Można się jednak z niego w przybliżeniu dowiedzieć, ile razy dana aplikacja została ściągnięta. Zalecam podchodzić ostrożnie do tych danych, pozwalają one jednak w miarę ogólnie oszacować skalę rynku.

Jeśli aplikacja jest już gotowa, warto skorzystać z narzędzi analizujących jej pozycję względem konkurencji. Jednym z takich rozwiązań jest AppFigures, które po podłączeniu w kodzie aplikacji sprawdza ciągle jej pozycję w sklepie i wizualizuje dane o ściągnięciach i zmianach pozycji w sklepach mobilnych.

Są jeszcze takie narzędzia, jak Appcodes, które służą do analizy słów kluczowych, na jakie pozycjonuje się konkurencja w sklepach. Jest to bardzo ważny element ASO (App Store Optimization) — odpowiednika SEO w świecie aplikacji mobilnych.

Takie działania warto przeprowadzić w przypadku wszystkich największych konkurencyjnych podmiotów na rynku. Dzięki temu można uzyskać dodatkowe informacje o tym, jak szeroka i głęboka jest nisza oraz gdzie szukać przewagi konkurencyjnej. Taka analiza nie powinna jednak odbywać się w oderwaniu od badania innych aspektów strategii konkurencji. Faktyczna liczba ściągnięć aplikacji jest zawsze efektem przyjętej strategii.

Punkty odniesienia i metryki

W jaki sposób wysyłano tweety, zanim powstał Twitter? Czy SMS-y są tweetami, ale w trochę innej formie?

Każde oprogramowanie powstaje po to, aby usprawnić jakiś proces. Aplikacje mobilne, które faktycznie wnoszą wartość, charakteryzują się tym, że coś przyspieszają, ułatwiają lub przybliżają (najlepiej, aby robiły wszystkie te trzy rzeczy jednocześnie). Aby jednak widzieć, że coś zostało usprawnione, musimy znać dwa stany: przed usprawnieniem (punkt A) i po (punkt B). Jak bardzo udało nam się coś polepszyć, da się ocenić, badając różnicę między B i A.

Można więc powiedzieć, że tweet to usprawniony SMS na płaszczyźnie częstotliwości interakcji, sposobu prezentacji, kosztu komunikacji i tak dalej.

Patrząc w retrospektywie wydaje się to banalne, ale będąc w punkcie A, jak określić, czym jest punkt B i jaka będzie różnica między nimi? Do tego służy badanie punktów odniesienia. Zazwyczaj, gdy mówi się o badaniu konkurencji, buduje się obraz analogicznych produktów i usług podobnych do naszych — to spojrzenie horyzontalne. To jest oczywiście przydatne, ale ja proponuję także spojrzenie historyczne: jak daną potrzebę zaspokajano do tej pory?

„Do tej pory” oznacza, że trzeba spojrzeć także w przeszłość. Można dojść do wniosku, że poprzednikiem SMS-a był telegram, a poprzednikiem telegramu — poczta gołębia. Wszystkie te formy komunikacji są ograniczone długością przekazu, wszystkie wymagają podobnej skrótowej formy, każda kolejna i nowsza usprawniała proces, ale istota usługi i potrzeba pozostaje ta sama.

Ilość naszych potrzeb jest ograniczona — bardzo rzadko zdarza się, że odkrywamy zupełnie nową potrzebę, o której wcześniej nie wiedzieliśmy. Innowacje, które wprowadzamy w życie (i na których chcemy zarabiać), nie wynikają z poszukiwania, odkrywania i zaspokajania nowych potrzeb, ale na szybszym zaspokajaniu obecnych. Czasami wprowadzane są drobne zmiany odzwierciedlające stan i status cywilizacyjny, ale główna idea, główna potrzeba jest niezmienna.

W tym wypadku mówimy o innym rodzaju konkurencji. Nie tylko rynkowej i technologicznej, ale także użytkowej. Weźmy na warsztat przykład, który jest mniej oczywisty niż tweety i SMS-y — telewizję.

Jeśli mamy pomysł, by stworzyć usługę VOD z filmami i serialami na smartfony, to badania powinniśmy zacząć od pytania: jaką potrzebę zaspokaja VOD z filmami i serialami? Doszlibyśmy prawdopodobnie do wniosku, że to potrzeba rozrywki lub, rozszerzając, potrzeba relaksu, odreagowania stresów, przeniesienie się do innej rzeczywistości.

Rozkład usług, które zaspokajają potrzeby analogiczne do VOD

W zależności od dokładności badania i filtrów, jakie zastosujemy, ten wykres może mieć mniej lub więcej pozycji — na przykład takich jak Netflix. Ta usługa jest świetnym przykładem na szybką reakcję na zmianę warunków rynkowych. Netflix zaczynał jako wysyłkowa wypożyczalnia filmów na DVD, a model biznesowy zakładał subskrypcję płatną co miesiąc.

Dlaczego Netflix odnosi sukcesy?

Mając możliwie dokładną wiedzę o punktach odniesienia, można określić wspólny mianownik — metrykę, której wartość (na przykład mniejsza typu krótszy czas realizacji lub większa typu większy koszyk zakupowy) buduje przewagę konkurencyjną.

Jeśli taką metryką okaże się czas potrzebny do rozpoczęcia oglądania filmu to, uogólniając, rozkład będzie wyglądał tak:

Czas potrzebny do zaspokojenia potrzeby

Jest więc oczywiste, że szybsze rozwiązanie będzie w tym wypadku wygrywać. Dokładne zbadanie punktów odniesienia oraz wyciągnięcie na tej podstawie wniosków w postaci metryk daje lepszą odpowiedź na pytanie o sposób wytworzenia przewagi strategicznej, a więc zdobycie przewagi na rynku.

Zalecana dalsza lektura

- Dobra strategia zła strategia. Czym się różnią i jakie to ma znaczenie, Richard P. Rumelt

- How to build a billion dollar app, George Berkowski


[1] Dobra i zła strategia, Richard P. Rumelt, MT Biznes, Warszawa 2013

[2] DARPA Strategic Plan, http://commons.wikimedia.org/wiki/File:DARPA_Strategic_Plan_%282009%29.pdf

[3] Twitter Sharpens Its Strategy to Win Over Investors, http://blogs.wsj.com/digits/2014/11/12/twitter-sharpens-strategy-to-win-over-investors

[4] Apple CEO: Don’t Fear Cannibalization, Embrace It, http://allthingsd.com/20130123/apple-ceo-dont-fear-cannibalization-embrace-it

[5]Zjawisko, gdy na podstawie pierwotnego produktu powstaje następny, o mniejszej funkcjonalności ze względu na ograniczenia technologiczne i biznesowe, nazywa się graceful degradation. Więcej na ten temat w dalszej części książki.

[6] Patrz: www.ketchappstudio.com

[7] gemiusRanking — urządzenia mobilne — producenci, http://ranking.pl/pl/rankings/mobile-devices-producers.html

[8]ustwogames na Twitterze, https://twitter.com/ustwogames/status/552136427904184320

[9]The Android piracy problem, http://www.gamasutra.com/view/news/176214/The_Android_piracy_problem.php

[10]The History of App Pricing, And Why Most Apps Are Free, http://www.flurry.com/bid/99013/The-History-of-App-Pricing-And-Why-Most-Apps-Are-Free#.VQVhZhCG-IA

[11]ThinkGaming: Clash of Clans, https://thinkgaming.com/app-sales-data/1/clash-of-clans

[12]Infinity Blade franchise surpasses $30 million in revenue, http://www.engadget.com/2012/01/05/infinity-blade-franchise-surpasses-30-million-in-revenue

[13] Epic’s Sweeney: Platform convergence, freemium the inevitable future, http://www.gamasutra.com/view/news/173072/Epics_Sweeney_Platform_convergence_freemium_the_inevitable_future.php

[14] I’m Rich, http://en.wikipedia.org/wiki/I_Am_Rich

Rozdział 5 Zespół i organizacja produktu mobilnego

Gdy organizacja podejmie decyzję o tworzeniu produktu mobilnego i zostanie powołana osoba za to odpowiedzialna (czyli ty), to następnym krokiem jest uformowanie zespołu i zdecydowanie, na jakich zasadach będzie on funkcjonował. Stworzenie nowoczesnego produktu wymaga nowoczesnej organizacji. Nie można spodziewać się innowacji w zespole zmuszonym do naśladowania starych struktur i metod.

W tym rozdziale skupiam się na opisaniu najlepszych metod pracy, komunikacji i zarządzania, aby zespół efektywnie wykonał swoją pracę — czyli dostarczył produkt mobilny. Celem jest stworzenie najlepszego środowiska do powstawania produktu mobilnego.

Proces i organizacja

Aplikacja mobilna jest efektem interpretacji całościowej strategii organizacji. Tworzenie aplikacji, która nie jest w niej umocowana, może być co najwyżej nazwane testem rynkowym. Proces powstawania produktu mobilnego zaczyna się od zrozumienia strategii. Strategia pozwala na określenie wymagań biznesowych, a te przekładają się na metryki, które produkt mobilny powinien wypełnić. Mając zebrane te elementy, można przystąpić do konkretyzowania koncepcji aplikacji. Na tym etapie wiele kwestii musi być zwalidowanych ze względu na ograniczenia rynkowe, technologiczne i prawne. Dlatego potrzebne jest dokładne zbadanie rynku mobilnego i zrozumienie jego ograniczeń pod kątem naszych wymagań biznesowych.

Ten proces pozwala w logiczny sposób zdekomponować kolejne fazy działań i wstępnie zwalidować, czy każdy, coraz bardziej szczegółowy element, faktycznie ma sens biznesowy z perspektywy poprzedniej fazy. W efekcie da się prześledzić, z czego wynika kształt produktu mobilnego, analizując wcześniejsze fazy strategiczne.

W szczególnych przypadkach może się okazać, że aplikacja mobilna nie jest najlepszą metodą spełnienia wymagań biznesowych. Wielokrotnie zdarzało się, że po wstępnych warsztatach klienci wychodzili od Senfino z decyzją, że aplikacja mobilna nie jest im jeszcze potrzebna. Zazwyczaj ze względów technologicznych i operacyjnych ich organizacje nie były jeszcze na nią gotowe.

W przypadku aplikacji mobilnej twórcy nie mają pełnej kontroli nad produktem, ponieważ brakuje im władzy nad medium, czyli sposobem dystrybucji. Medium dla aplikacji to sklepy mobilne: App Store, Google Play i Windows App+Games. Każdy z nich ma swoje zasady — bez ich spełnienia aplikacja nie zostanie opublikowana. Sklepy są moderowane i monitorowane przez właścicieli platform w celu eliminacji zagrożeń związanych z łamaniem prawa, propagacją wirusów i wyciekiem danych osobowych. Zwiększanie bezpieczeństwa ma swój koszt w postaci wydłużonego cyklu produkcji i aktualizacji aplikacji — należy bowiem do niego doliczyć czas potrzebny sklepowi na sprawdzenie aplikacji pod kątem zasad i dobrych praktyk. To oznacza, że w odróżnieniu od szybkiego iterowania wersji strony internetowej rozwijanie aplikacji wymaga o wiele dokładniejszego planu rozwoju — a przede wszystkim o wiele dłuższego etapu przygotowawczego przed udostępnieniem pierwszej wersji publicznej. Premiera aplikacji to naturalna klamra procesu developerskiego ze względu na wysiłek wymagany do przejścia procesu akceptacyjnego (którego nie ma na przykład w wypadku produktu SaaS opartego na stronie internetowej).

Jeśli mobile jest jednym z kolejnych dochodzących kanałów przychodu (firma typu mobile-second), to zrównywanie ze sobą funkcji poszczególnych kanałów zazwyczaj powoduje dostosowanie się do najdłuższego cyklu, którym praktycznie zawsze będzie aplikacja mobilna.

Po wprowadzeniu do użycia aplikacji mobilnej o wiele ostrożniej wprowadza się zmiany w produkcie (na przykład aktualizacja API) właśnie ze względu na dłuższy proces reakcji i naprawy błędów w aplikacjach oraz propagacji aplikacji na urządzeniach użytkowników.

Dodatkowo należy doliczyć czas potrzebny na weryfikację aplikacji przez sklep mobilny. W zależności od sklepu może to zająć od kilkunastu godzin do kilkunastu dni — wpływa na to przyjęty sposób testowania (testy ludzkie i automatyczne) oraz liczba aplikacji, które czekają w kolejce do sprawdzenia.

W przypadku App Store w 2014 roku najkrócej czekało się w maju (około 4 dni), a najdłużej w październiku (11 dni)[1]. W przypadku Google Play czas sprawdzenia aplikacji dotychczas wynosił kilka do kilkunastu godzin, choć ogłoszona w marcu 2015 roku strategia poprawy jakości aplikacji przez wprowadzenie testów ludzkich prawdopodobnie wydłuży ten czas.

Sama weryfikacja niekoniecznie musi pójść dobrze za pierwszym razem.

Najczęstszymi przyczynami odrzucania aplikacji w App Store jest niewystarczająca ilość informacji opisowej (14%), błędy uniemożliwiające korzystanie (10%) i zbyt niskiej jakości interfejs użytkownika (4%). W sumie 10 najpopularniejszych powodów odrzucenia składa się na 46% wszystkich odrzuceń[2].

Choć zasady publikacji są przez każdą platformę obszernie opisane, to sposób ich sformułowania jest na tyle elastyczny, aby dawać producentom wolność interpretacji w przypadku zmian rynkowych. Oprócz tego zasady publikacji potrafią się zmieniać kilka razy w roku — na przykład z powodu pojawienia się nowej wersji systemu lub urządzenia w ekosystemie[3].

W przypadku odrzucenia aplikacji autor dostaje infromację o przyczynie i rekomendację, co należy poprawić, aby aplikacja została zweryfikowana pozytywnie. W zależności od sytuacji zmiany mogą oznaczać kilka godzin lub kilkanaście dni dodatkowej pracy. Po ich wprowadzeniu trzeba ponownie przejść weryfikację. Jeśli więc jest planowana publiczna premiera, to mądrze jest założyć, że proces publikowania aplikacji w sklepie powinien rozpocząć się miesiąc wcześniej.

Widziałem kilka bardzo bolesnych przypadków niewliczenia do deadline’u czasu potrzebnego na akceptację bądź poprawki wskazane przez support sklepu. Często jest to wąskie gardło wielokanałowej kampanii reklamowej i w skrajnych przypadkach wymaga jej przesuwania w czasie. To jeden z najpopularniejszych błędów menedżerów, którzy zarządzają powstawaniem aplikacji mobilnych.

Cykl życia i komunikacja

Uogólniając, cykl życia produktu mobilnego można podzielić na pięć faz.:

Cykl życia projektu mobilnego

Pierwszy etap to strategia i wymagania. To na tym etapie dochodzi się do wysokopoziomowych ustaleń, jaki cel i efekty ma osiągnąć aplikacja. Następnie przechodzi się do dyskusji nad sposobami realizacji zamierzonych celów i wizualizacji potencjalnych rozwiązań. Kolejnym krokiem jest praca programistów do momentu uzyskania produktu, który można pokazać na rynku. Po publikacji następuje etap zbierania opinii z przyjęcia produktu przez rynek, sprawdzanie, czy zamierzone efekty i cele zostały osiągnięte, oraz wyciąganie wniosków z całego procesu. Gdy wnioski są uformowane, wraca się do fazy idei, aby usprawniać produkt, mając nową wiedzę i nowe hipotezy. Bardziej szczegółowo etapy są opisane w następnym rozdziale.

W zależności od zaawansowania prac nad produktem zmienia się natężenie komunikacji oraz typy dokumentów przesyłanych między członkami zespołu. Im lepsza komunikacja, tym większa szansa na powodzenie całego przedsięwzięcia.

Podczas fazy przygotowawczej powstaje dużo dokumentów, których celem jest jak najdokładniejsze opisanie produktu. Takie dokumenty nazywa się artefaktami. Artefakty są sposobem na bierne komunikowanie wizji produktu. Każdy członek zespołu podczas swojej pracy powinien mieć możliwość sprawdzenia, czy to, co robi, jest zgodne z dostępnymi materiałami. To może być specyfikacja, notatka projektowa, szkic architektury narysowany podczas spotkania czy makieta aplikacji.

Jednym z największych wrogów pracy nad produktem jest brak spójności między poszczególnymi artefaktami. Podczas pracy zespół natrafia na mnóstwo wewnętrznie sprzecznych ustaleń i musi wybrać jedną z wielu dróg. Podjęta decyzja powinna być odnotowana i naniesiona na artefakty, aby w przyszłości nie wprowadzać szumu informacyjnego.

Brief

Zazwyczaj pierwszym artefaktem jest brief o aplikacji mobilnej, w którym opisane są podstawowe atrybuty projektu i oczekiwany efekt. Idea briefu jest zapożyczona z branży reklamowej. Brief najczęściej skupia się na opisie wizji, kontekstu rynkowego oraz celów do osiągnięcia. Nie jest natomiast dokumentem, na którego podstawie może powstać wycena. Brief odpowiada bowiem na pytanie: co?, zostawia natomiast ogromne pole do interpretacji w zakresie sposobu i kosztowności realizacji.

Specyfikacja

Specyfikacja to dokument, który określa wymagania funkcjonalne (co ma robić aplikacja), niefunkcjonalne (kryteria jakościowe) oraz wymagania ograniczeń (granice rozwiązania). Specyfikacja zazwyczaj tworzona jest przez specjalistów technicznych, aby poinformować dostawcę (niezależnie od tego, czy jest wewnętrzny, czy zewnętrzny) o konkretnych wymaganiach produkcyjnych, które muszą być spełnione, aby projekt został przyjęty. Specyfikacja odpowiada na pytanie: jak?, nie informuje jednak, czy faktycznie to najlepsza decyzja biznesowa.

Pewien znajomy propagator zwinnych metod zarządzania lubi powtarzać, że nie ma takiej specyfikacji, która jest wewnętrznie spójna. Jedyna w pełni zgodna z rzeczywistością specyfikacja może powstać dopiero po stworzeniu produktu.

Wycena

Dostawca technologii, aby oszacować koszt stworzenia produktu mobilnego, musi wiedzieć, ile czasu zajmie mu realizacja wymagań ze specyfikacji — tak, aby produkt był zgodny z briefem. Osiąga się to podczas dyskusji członków zespołu, których kompetencje pozwalają na realizację produktu. Członkowie zespołu szacują na podstawie własnego doświadczenia (odnosząc się do realizacji podobnych projektów w przeszłości), ile czasu zajmie im osiągnięcie założonych wymagań. Sumując czasy, dostawca poznaje pracochłonność, a mnożąc wynik przez swoją stawkę godzinową bądź dzienną (tzw. man-day), dostaje wycenę projektu, zazwyczaj dodając bufor na wypadek poślizgnięć bądź dalszych negocjacji z klientem.

Niestety, taka wycena nigdy nie będzie wiarygodna, bo w przeciwieństwie do budowania fizycznych produktów, tworzenie oprogramowania (a już szczególnie aplikacji mobilnych) jest procesem niezwykle nieprzewidywalnym. Jest to w gruncie rzeczy sprawdzanie, co jest możliwe do stworzenia w ramach projektu, a nie taśmowe produkowanie identycznych rozwiązań.

Definicja wykonania

Definicja wykonania (definition of done) to minimalna lista kryteriów, które muszą być spełnione, aby dana funkcja mogła być uznana za wykonaną. Dlaczego jest to tak ważne? Błędem jest stwierdzenie, że koszt (czasowy lub budżetowy) aplikacji zależy od liczby posiadanych funkcji. To nie jest prawdą z prostego powodu: każdą z funkcji, nieważne jak dużego i skomplikowanego produktu, da się wykonać na nieskończoną ilość sposobów, które różnią się od siebie zaawansowaniem.

To oznacza, że — na przykład — funkcja udostępniania zdjęcia znajomym może być zrealizowana na wiele sposobów, realizacja może trwać od jednego dnia do jednego miesiąca — i ciągle być zgodna z pierwotnym założeniem. Bo w najprostszej postaci funkcja może wykorzystywać natywne możliwości platformy mobilnej i dołączać zdjęcie do nowej wiadomości e-mail. W skrajnym przypadku może się jednak okazać, że zdjęcie powinno być dostępne online, mieć własny łatwy do zapamiętania adres WWW i że powinna być możliwość ograniczenia dostępu osobom spoza grupy znajomych. Między obydwoma skrajnościami jest jeszcze mnóstwo możliwych sposobów realizacji funkcji — każda o różnym koszcie czasowym i finansowym.

Rozpiętość definicji wykonania

Po wybraniu jednego z wielu możliwych rozwiązań i dokładnym opisaniu go powstaje definicja wykonania funkcji. Product owner decyduje na podstawie posiadanego budżetu i czasu, gdzie jest granica między akceptowalnym i nieakceptowalnym biznesowo rozwiązaniem. Musi pamiętać, że tańsze rozwiązanie może wprowadzić go w dług technologiczny, a droższe — narazić na szybsze wyczerpanie budżetu.

Posiadanie definicji wykonania jest bardzo ważne z perspektywy całego zespołu. Minimalizuje poziom niepewności i ogranicza liczbę interpretacji tego, co ma być wykonane. Może się bowiem zdarzyć tak, że różni członkowie zespołu (lub właściciel biznesowy i zespół) różnie definiują sposób i zakres realizacji danej funkcji.

Przykład:

Właściciel biznesowy mówi, że chce, aby aplikacja pozwalała na logowanie za pomocą sieci społecznościowych.

Takie stwierdzenie, jeśli nie zostanie doprecyzowane, daje zespołowi swobodę definiowania, które sieci społecznościowe wybrać z całego szeregu możliwych (zazwyczaj chodzi o Facebook, ale przecież jest też także Google+, Twitter, Instagram, LinkedIn i mnóstwo innych).

Należy też zastanowić się, czy logowanie przez sieci społecznościowe oznacza, że nie bierzemy pod uwagę standardowej metody rejestracji i logowania za pomocą adresu e-mail i hasła? A jeśli bierzemy pod uwagę zarówno logowanie za pomocą konkretnej sieci społecznościowej, jak i logowanie za pomocą e-maila i hasła, to czy te metody są zamienne i wykluczające? To znaczy, czy jeśli użytkownik raz zalogował się za pomocą sieci społecznościowej, a raz za pomocą e-maila — to mamy w bazie danych dwóch użytkowników czy jednego?

Takie doprecyzowywanie ma bardzo dużo wspólnego ze wcześniej omawianym określaniem metryk i wymagań biznesowych. Obydwa działania opierają się na tej samej idei jak najdokładniejszego opisania problemu i rozwiązania, aby usunąć z projektu najwięcej, jak się da, niepewności. Dobrze skodyfikowane definicje wykonania dają klarowny obraz produktu i ograniczają narzut komunikacyjny. Ważne, aby definicje wykonania były znane i zrozumiałe dla każdego członka zespołu produktowego.

Tablica delegacji

Sposobem na eliminowanie niepewności przy pracy nad produktem mobilnym i zwiększaniem samodzielności członków zespołu jest tablica delegacji. Oryginalny pomysł delegation boardzaproponował Jurgen Appello w swojej książce Managment 3.0 Workout[4].

Stworzenie tablicy delegacji polega na wypisaniu obszarów działania zespołu i przydzieleniu każdemu z nich odpowiedniej wartości określającej samodzielność podejmowania decyzji.

Wartości jest siedem:

1. Zakomunikuj (Tell) oznacza, że ty jako decydent podejmujesz decyzje za zespół i możesz, jeśli chcesz, ją wytłumaczyć. Dalsza dyskusja na ten temat nie jest zakładana.

2. Sprzedaj (Sell) oznacza, że ty jako decydent podejmujesz decyzje, ale chcesz przekonać cały zespół, że wybierasz najlepszą możliwość.

3. Skonsultuj (Consult) oznacza, że najpierw pytasz o zdanie, które bierzesz pod uwagę przy podejmowaniu decyzji.

4. Zgódź się (Agree) oznacza, że zespół dyskutuje nad decyzją i jako grupa dochodzicie do porozumienia.

5. Doradź (Advise) oznacza, że oferujesz zespołowi swoją radę i masz nadzieję, że zespół z niej skorzysta, ale to ostatecznie on podejmuje decyzję.

6. Zapytaj (Inquire) oznacza, że zostawiasz decyzję do podjęcia zespołowi i to on, zapytany o efekt, musi cię przekonać o jej słuszności.

7. Zdeleguj (Delegate) oznacza, że zostawiasz podjęcie decyzji w pełni po stronie zespołu i już nie chcesz zaprzątać sobie nią głowy.

Następnym etapem jest wypisanie najważniejszych elementów procesu powstawania produktu i relacji wszystkich zaangażowanych osób.

Przykładowa tablica delegacji w relacji klient — software house

W tym przypadku ustalono, że klient daje sporą wolność w wyborze narzędzi komunikacji, ale chce decydować o częstotliwości kontaktów, aby mieć rękę na pulsie. Pozostawia zespołowi wybór metodyki pracy, ale chce mieć wpływ na to, kto będzie zajmował się jego projektem. Ponieważ istnieje już część infrastruktury, klient narzuca rozwiązania po stronie API i backendu, jego stanowisko nie jest natomiast zbyt usztywnione w zakresie kolorystyki i designu samej aplikacji.

Dobrze zrobiona tablica delegacji to jedno z najlepszych narzędzi do przyśpieszenia pracy zespołu i ograniczenia narzutu komunikacyjnego.


[1] Average App Store Review Times. iOS App Store — Rolling Annual Trend Graph, http://appreviewtimes.com/ios/annual-trend-graph

[2] Common App Rejections, https://developer.apple.com/app-store/review/rejections

[3] Apple Updates App Store Review Guidelines Ahead of iOS 8, http://www.iclarified.com/43568/apple-updates-app-store-review-guidelines-ahead-of-ios-8

[4] Management 3.0 Workout, http://www.management30.com/workouts

Metodyki pracy

Z mojego doświadczenia wynika, że jeśli projekt ma ustalone stałe: budżet, czas realizacji i zakres, to cierpi na tym jakość́ i na koniec ani klient, ani dostawca rozwiązania nie są̨ zadowoleni z efektu. Jednocześnie zmiany w trakcie trwania prac nad produktem są nagminne — to natura projektów technologicznych. Wniosek, jaki się nasuwa, to że należy stosować podejście, w którym zmiany są naturalnym elementem procesu produkcyjnego.

Wyróżniam dwa podejścia do realizacji produktów mobilnych (w gruncie rzeczy wszystkich produktów technologicznych): poziome i pionowe.

Podejście poziome

Najpopularniejsze i najbardziej intuicyjne podejście to podzielenie projektu na etapy i realizacja ich jeden po drugim, zaczynając od tego, który definiuje produkt, a jednocześnie tworzy największe ograniczenia technologiczne na przyszłość. W przypadku aplikacji mobilnych zazwyczaj jest to backend.

Podejście poziome

Podejście poziome jest intuicyjne i jasne do zrozumienia dla wszystkich zaangażowanych w projekt. Problem polega na tym, że takie tworzenie oprogramowania wymaga rzeczy niemal niemożliwych od zespołu, to znaczy:

- wiedzy, ile czasu potrzeba na każdy etap, zanim zacznie się̨ pracę,

- tworzenia kodu idealnego, który nie będzie wymagał poprawek w przyszłości,

- doskonałej znajomości uwarunkowań rynkowych (brak możliwości zmiany kursu, gdy plan zostanie ustalony).

Podejście poziome jest często nazywane Waterfallem bądź́ kaskadą. Gdy jeden element pójdzie w nim nie tak, jak potrzeba, będzie zagrożony każdy następny.

Jeśli klient po ustaleniu planu prac zechce coś w nim zmienić, może poprosić o korektę za pomocą tzw. Change Requestów (CR) — niezależnie wycenianych przez dostawcę technologii. Jedną z negatywnych praktyk rynku oprogramowania jest tworzenie kanału przychodu przez takie sterowanie klientem, aby ostatecznie był zmuszony do akceptacji wysokich cen CR-ów.

Podejście pionowe

Podejście pionowe wychodzi z innego założenia: celem pracy jest jak najszybsze przedstawienie działającego fragmentu oprogramowania. W związku z tym prace całego zespołu skupione są na tworzeniu funkcji na wskroś́ przez wymagane warstwy produktu.

Podejście pionowe

Jeśli więc funkcją wymaganą na ten moment są płatności mobilne, to cały zespół pracuje nad tym, aby jednocześnie były one obsłużone po stronie backendu, aby API przesyłało dane z frontendu do backendu i aby design uwzględniał ekran płatności. W następnym cyklu zespół pracuje nad kolejną potrzebną funkcją.

Podejście pionowe jest mniej intuicyjne od poziomego ponieważ wymaga zmiany paradygmatu związanego z czasem i budżetem projektowym.

Takie podejście wpisuje się w metodyki zwinne (Agile), wywodzące się z empiryzmu. Empiryzm zakłada, że wiedza wynika z doświadczenia, a decyzje są podejmowane na podstawie tego, co poznane.

Scrum jest jedną z metodyk zwinnych. Dokładniej są to ramy postępowania (framework), dzięki którym ludzie mogą̨ z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości[1].

Osobom zainteresowanym dokładniejszym zgłębieniem tematu metodyk zwinnych polecam książkę Agile w praktyce Andy’ego Brandta[2].

User stories, backlog i sprinty

User storyto prosty i krótki opis funkcji z perspektywy osoby, która w jakikolwiek sposób będzie beneficjentem oprogramowania. User storyjest zazwyczaj tworzone według schematu: Jako X chcę Y, aby Z, na przykład: Jako użytkownik chcę zarejestrować́ się̨ w systemie, aby móc obejrzeć́ filmlub Jako właściciel biznesowy chcę wiedzieć, ilu mam zarejestrowanych użytkowników, aby kontrolować, jak rozwija się mój biznes.

Zestaw user storiespoukładanych od najważniejszego do najmniej ważnego z perspektywy biznesowej nazywa się backlogiem. Nad backlogiem pracuje zespół projektowy wspólnie z właścicielem biznesowym.

Backlog przy starcie i po pierwszym sprincie

Backlog to żywy, często zmieniany i uzupełniany dokument. Dbanie o to, żeby pokrywał się z faktycznymi wymaganiami i coraz dokładniejsza dekompozycja wymagań na konkretne zadania to backlog grooming.

Zespół pracuje, zaczynając od najważniejszego user storyw interwałach czasowych — sprintach. Najczęściej sprinty trwaja jeden lub dwa tygodnie. Każdy sprint zaczyna się planningiem, podczas którego określa się to, co ma być zrobione w tym sprincie, oraz review, podczas którego następuje demonstracja postępów po zakończonym sprincie i retrospekcja, kiedy zespół waliduje jakość swojej pracy i stara się ją usprawnić.

Spójność i ciągłość procesu powstawania aplikacji

Po określeniu wizji i podstawowych założeń biznesowych następnym etapem jest przejście do projektowej fazy budowania produktu. Ten etap wygląda różnie w zależności od specyfiki organizacji oraz zastanej sytuacji, ale jego ogólny zarys i etapy są wspólne.

Faktyczne programowanie pojawia się dopiero w drugiej połowie całego procesu. Zanim to nastąpi należy przygotować dużo materiałów (opisywanych wcześniej artefaktów), które wytyczają programistom drogę do realizacji założeń projektu.

Najlepiej jest przedstawić ten proces od końca, czyli od efektu finalnego w postaci aplikacji mobilnej. Mamy aplikację sklepu wielkopowierzchniowego. Dlaczego w naszej aplikacji jest przycisk, który pozwala podzielić się informacją o promocji zakupowej?

Ponieważ:

- Był zawarty w prototypie…

- Ponieważ nasze badania wykazały, że użytkownicy lubią dzielić się promocjami zakupowymi…

- Ponieważ jednym z wymagań biznesowych jest osiągnięcie sytuacji, w której użytkownicy sami propagują wśród znajomych naszą aplikację…

- Ponieważ naszym celem biznesowym jest być w top 10 aplikacji w naszej kategorii, a to oznacza X ściągnięć dziennie…

- Ponieważ nasza strategia zakłada zwiększanie punktów styku z naszymi klientami i aktywizację nowych kanałów sprzedaży poza naszymi fizycznymi sklepami.

Dzięki takiemu podejściu wiadomo, z czego wynika każda decyzja projektowa, a sam proces produkcji staje się bardziej przewidywalny zarówno dla właściciela biznesowego, jak i zespołu produktowego.

Poza tym łatwo jest zrobić drill downi prześledzić decyzje biznesowe i projektowe w przypadku, gdy efekt finalny różni się od pierwotnych założeń — co jest zazwyczaj efektem błędów komunikacyjnych. Dobra aplikacja mobilna wymaga ciągłego inwestowania — praca nad nią nie kończy się wraz z zakończeniem programowania czy opublikowaniem w sklepie mobilnym.

Środowisko mobilne jest niezwykle dynamiczne. Średnio co rok wprowadzana jest nowa wersja systemu operacyjnego, trzeba udostępniać nowe możliwości, jak powiadomienia push czy obsługę mikrolokalizacji. Co dwa-trzy lata uaktualniany jest nowy język komunikacji wizualnej — w przypadku Apple minimalizm połączony z półprzeźroczystością (translucency), a w przypadku Androida material design. Do tego dochodzą także zmiany wielkości ekranów smartfonów i tabletów — zarówno w wypadku konserwatywnego Apple’a, jak i bardzo zdefragmentowanego Androida.

To wszystko oznacza, że aplikacja, jeśli ma nieść wartość dla użytkownika końcowego, musi mieć rozpisany plan aktualizacji na minimum rok do przodu — wtedy jest duża szansa, że w czasie jej obsługi przez developera nastąpi zmiana systemowa.

Od strony biznesowej traktowanie aplikacji jako jednorazowego działania, na przykład przy okazji akcji reklamowej, jest błędem strategicznym. Aplikacja, której rozwój i wsparcie zatrzymuje się kilka tygodni bądź miesięcy po zakończeniu działań marketingowych, stanie się obciążeniem komunikacyjnym i PR-owym. Użytkownicy zaczną narzekać na brak aktualizacji i reagowania na zgłaszane błędy. Pozostawiona sama sobie aplikacja szybko straci na aktualności i zacznie odstawać wizualnie od systemu mobilnego (oraz konkurencyjnych rozwiązań), przez co ściągnie na siebie negatywne komentarze i słabsze oceny użytkowników.

Modele współpracy z dostawcą

Wybór twórcy oprogramowania to bardzo ważna i długoterminowa decyzja. Ze względu na specyfikę projektów technologicznych kooperacja między właścicielem biznesowym a dostawcą musi być ścisła i intensywna. Kluczowe jest dobranie partnera, który najlepiej rozumie biznes zleceniodawcy. Jeśli zleceniodawca z jakiegokolwiek powodu zechce zmienić dostawcę, musi się liczyć ze znacznie wyższymi kosztami realizacji produktu gdyż, nowy kontrahent musi jeszcze raz zapoznać się z kodem, a w skrajnym wypadku zdecydować o konieczności napisania kodu od zera.

Współpraca projektowa

Model współpracy projektowej

To najpopularniejszy, ale jednocześnie najmniej lubiany przez dostawców model współpracy, ponieważ koszt pozyskania takiego zlecenia jest wysoki w stosunku do jego wartości (i tylko nieznacznie niższy od kosztu pozyskania klienta do długotrwałej współpracy). Współpraca między zleceniodawcą a dostawcą zazwyczaj trwa od tygodnia do kilku miesięcy, w trakcie których powstaje produkt i jednocześnie (często w niezależnej umowie) ustalane są warunki wsparcia produktu po jego publikacji.

Ten model sprawdza się przy mało zaawansowanych projektach, gdzie nie jest potrzebna dokładniejsza analiza potrzeb i wymagań biznesowych (nie ma po prostu na to czasu i budżetu) — na przykład przy aplikacjach reklamowych.

Współpraca pulsująca

Model współpracy pulsującej

Przykład na model dłuższej współpracy. Po realizacji projektu dostawca, oprócz wsparcia, aktywnie działa wraz z klientem nad zbieraniem danych o potencjalnych poprawkach i usprawnieniach zgodnie z wymaganiami biznesowymi. Zmiany są pakietowane i po przekroczeniu ustalonego progu następuje realizacja zmian, która kończy się nową wersją aplikacji. Wraz z każdą nową iteracją produktu proces się powtarza.

Współpraca ciągła

Model współpracy ciągłej

To jest najwygodniejszy model współpracy zarówno dla klienta, jak i dla dostawcy, wymaga jednak wysokiego poziomu zaufania między stronami. Po analizie potrzeb dostawca tworzy zespół projektowy. Wykonuje wszystkie działania dla niego — niezależnie czy jest to tworzenie aplikacji, jej rozwój, administracja infrastrukturą czy naprawa błędów. Za to wszystko klient płaci stałą zakontraktowaną stawkę miesięczną odpowiednią za liczbę osób zaangażowanych w realizację produktu.

Model sprawdza się dobrze, gdy aplikacja ma długą listę funkcji do stworzenia/poprawy lub generuje już przychody, które można reinwestować w rozwój. Po udanych projektach realizowanych w modelu pulsującym często następuje przejście na model współpracy ciągłej.

Wymagania biznesowe

Brief odpowiada na pytanie: co?, specyfikacja na pytanie: jak?, ale najważniejsze dla zespołu i dostawcy jest pytanie: dlaczego?. Brief i specyfikacja to w gruncie rzeczy lista założeń́ i hipotez, które dają ogólny obraz rozwiązania. Z perspektywy dostawcy jednak nie wiadomo, jaki jest oryginalny problem, z którym musi zmierzyć się właściciel biznesowy.

Aby zrozumieć dlaczego?, wykorzystuje się metodę budowania wymagań́ biznesowych. Polega ona na bezwględnym dążeniu do wypracowania policzalnych wskaźników na każdej istotnej płaszczyźnie rozwoju produktu. Dzięki temu można określić prawdziwe cele biznesowe spójne ze strategią firmy.

Co to znaczy, że coś jest „proste”? Budowanie wymagania biznesowego powoduje zdekomponowanie wizji i funkcji projektowanego produktu tak, aby każdy jej aspekt był możliwy do policzenia. A da się policzyć wszystko, nawet użyteczność aplikacji.

W jaki sposób? Poprzez redukcję do przykładu.

Załóżmy, że chcemy, żeby coś było „proste”. Co to znaczy? Jak inni to zinterpretują? Jeśli nie określimy tego dokładnie, to możemy spodziewać się problemów komunikacyjnych ze swoim zespołem, bo każdy może mieć zupełnie inną, subiektywną definicję prostoty. Spróbujmy sprecyzować pojęcie „proste”. Proste z perspektywy użytkownika może oznaczać „łatwe w użyciu”. Mamy już dokładniejsze określenie — nie wszystko, co proste, musi być łatwe w użyciu. Niemniej aplikacja „łatwa w użyciu” to ciągle slogan. Jak wywołać w użytkowniku poczucie, że ta konkretna aplikacja naprawdę jest „łatwa w użyciu”?

Patrząc z perspektywy użytkownika, jeśli coś jest dla mnie łatwe w użyciu, to znaczy, że szybko zrozumiałem jak to działa. To znaczy, że rozumiem możliwości działania, które dostrzegam w systemie (tu warto wspomnieć o terminie afordancje, oznaczającym uświadomione, także dzięki doświadczeniu, możliwości działania, opisanym między innymi przez Donalda Normana na podstawie teorii interakcji człowieka z komputerem[3]).

Dochodzimy do sedna. Czy da się określić, jak szybko zrozumiałem, jak aplikacja działa? To może być trudne do zbadania, jeśli użytkownik nie jest podłączony do specjalistycznego sprzętu, ale dzięki rozbudowanej analityce po stronie kodu możemy ten scenariusz opisać dokładniej, na przykład: „Użytkownik tuż po rejestracji doda zdjęcie do aplikacji w ciągu 10 sekund”.

Dochodzenie do wymagania biznesowego

Mając tak skonstruowane wymaganie, zdiagnozowaliśmy kilka płaszczyzn i wiemy, do czego dążymy. Musimy być jednak pewni, że faktycznie dodanie zdjęcia jest jedną z najważniejszych rzeczy w aplikacji. Tak na przykład jest w Instagramie i Facebooku — dlatego doświadczenie użytkownika budowane jest wokół tej fundamentalnej funkcji.

Tworzenie dobrego wymagania jest trudne, ale krytyczne dla powodzenia projektu. Dobre wymaganie wynika z przyjętej strategii i opiera się na podstawach biznesowych. Jednocześnie dzięki zdekomponowaniu na części pierwsze pozwala na racjonalną weryfikację założeń. Aby tworzyć wymagania, musimy bardzo precyzyjnie określić założenia w celu minimalizacji błędów komunikacyjnych.

Inny przykład — popularność aplikacji:

- Aplikacja ma być popularna,

- Aplikacja ma być popularna w Stanach Zjednoczonych,

- Aplikacja ma być popularna wśród amerykańskich nastolatków,

- Aplikacja ma być używana przez 10% amerykańskich użytkowników smartfonów w wieku 14–20 lat.

Zwiększanie przychodów firmy:

- Aplikacja ma zwiększać przychody firmy.

- Aplikacja ma być wyżej marżowym kanałem przychodów.

- Aplikacja ma generować większą średnią wartość koszyka zakupów niż dotychczasowe kanały.

- Aplikacja ma generować o 10% większą wartość koszyka zakupów niż wersja desktop web.

Do naszej ostatecznej listy wymagań biznesowych powinno wejść 10 najważniejszych. To jest arbitralna granica — trudno jest kontrolować projekt jednocześnie na więcej niż dziesięciu różnych płaszczyznach. Ta granica jednocześnie wymusza skupienie się na tym, co faktycznie jest ważne w oczach właścicieli biznesowych projektu, i pozwala optymalizować produkt pod tym kątem. Na jakiej podstawie wybierać najistotniejsze wymagania? Wszystko zależy od strategii.

W jednym przypadku właściciel biznesowy będzie chciał jak najszybciej osiągnąć skalę projektu, liczy na dużą popularność swojego produktu i jest w stanie zrezygnować z pełnej stabilności backendu. Wychodzi z założenia, że jeśli jego aplikacja faktycznie osiągnie dużą popularność, to znajdą się fundusze na polepszanie infrastruktury. Wtedy też będzie czas na szukanie modelu biznesowego i monetyzację.

Inaczej zachowa się właściciel biznesowy taki jak bank. Wtedy z dużym prawdopodobieństwem ciągła dostępność backendu i bezpieczeństwo będą ważniejsze od opcji dzielenia się treścią i powracalności.

Budżet i rodzaje kontraktów

We wcześniejszych rozdziałach opisywałem etapy rozwoju organizacji w zależności od propagacji wiedzy o mobile’u. W zależności od indywidualnej oceny twojej organizacji możesz odpowiednio przewidzieć wielkość budżetu potrzebnego do stworzenia produktu mobilnego.

Przy tworzeniu budżetu aplikacji mobilnej należy patrzeć na nią jak na produkt wraz z otoczeniem. W większości przypadków aplikacja, którą tworzysz, będzie pierwszą w Twojej organizacji. Dlatego należy zakładać, że:

- nie istnieje infrastruktura, która jest w stanie zasilać aplikację danymi,

- nie ma ludzi przeszkolonych w obsłudze nowego kanału sprzedaży,

- nie ma wytworzonych procesów projektowych.

Jeśli planujesz budżet pierwszej aplikacji w twojej organizacji, musisz przewidzieć́ o wiele większe środki na przetestowanie i dostosowanie infrastruktury (API) do wymagań aplikacji mobilnej. Jeśli jest to już któraś z kolejnych aplikacji w portfolio firmy, to nawet jeśli musi być stworzone nowe API, zespół programistyczny ma już doświadczenie w tym zakresie, więc czas realizacji będzie krótszy.

Należy zakładać, że czas przeznaczony na stworzenie pierwszej aplikacji będzie wymagał znacznie większego narzutu niż w wypadku każdej następnej.

Zazwyczaj dochodzi do niedoszacowania kosztów związanych z utrzymaniem i relacjami z użytkownikami. Większość środków jest przeznaczana na sam development kosztem infrastruktury i dostosowania organizacji do nowego kanału sprzedaży.

Przy średniej wielkości produkcie na iOS lub Androida obejmującym roczne wsparcie i infrastrukturę̨ koszty wytworzenia aplikacji to około 36% całego budżetu. Reszta to koszty przygotowawcze (15%) , logistyka (9%) i infrastruktura (40%).

Przy planowaniu aplikacji wydatki związane z otoczeniem traktuje się zazwyczaj jako mniej istotne, co pozwala mentalnie obniżyć koszty i zwiększyć marżowość. Tego typu działania mają jednak bardzo negatywne konsekwencje, które zaczynają być widoczne na etapie migracji projektu poza serwery wewnętrzne dostawcy.

Ze względu na rodzaje umów podpisywanych między klientami a dostawcami aplikacji mobilnych, można wskazać trzy tzw. „usztywnienia”:

- Fixed time oznacza, że właściciel biznesowy ma usztywniony czas, jaki może poświęcić na stworzenie produktu, na przykład: start nowej usługi, koncert czy konferencja. Nie ma sposobu, aby ten termin przesunąć w czasie. Dostawca rozumie, że to, co stworzy, musi być gotowe na ustalony termin,

- Fixed scope oznacza, że zakres realizacji produktu jest z góry ustalony, wszystkie wspólnie określone funkcje są krytyczne i muszą być zrealizowane, aby produkt mógł nadawać się do używania, tak jest na przykład w przypadku aplikacji bankowych czy specjalistycznych aplikacji medycznych,

- Fixed price oznacza, że właściciel biznesowy ma z góry określony budżet, którego nie może przekroczyć́.

Naturalną tendencją (i standardem na polskim rynku) jest chęć usztywniania wszystkich trzech atrybutów kontraktu, czyli sytuacja, w której umawiamy się na dostarczenie produktu ze specyfikacji w z góry narzuconym terminie i ramach zamkniętego budżetu. To jednak najprostszy sposób, by spowodować niepowodzenie projektu.

Trzy rodzaje usztywnień

Doświadczeni dostawcy wiedzą, że nie jest możliwe dostarczenie produktu, gdy zarówno cena, czas, jak i zakres są usztywnione — ze względu na nieprzewidywalność tworzenia (i wyceny) oprogramowania w szybko zmieniającym się środowisku biznesowym. Dlatego zazwyczaj optują o wybór przez klienta maksymalnie dwóch z trzech atrybutów — a najlepiej tylko jednego. Na przykład:

-Fixed time & scope oznacza, że dostawca musi planować, aby na konkretny termin dostarczyć produkt o ściśle określonej specyfikacji. W związku z tym może zarządzać budżetem projektu, dostosowując go w trakcie pracy do potrzeb realizacji założeń,

- Fixed price & time oznacza, że dostawca, wiedząc, jaki budżet i deadline ma właściciel biznesowy, może powiedzieć, że w tej cenie będzie pracować przez dany okres, ale nie może zagwarantować, ile z planowanych funkcji uda się wdrożyć w narzuconym mu czasie,

- Fixed scope oznacza, że klient dokładnie wie, czego chce. Za wszelką cenę chcę to osiągnąć i nie jest ważne, ile to zajmie czasu.

Istnieje jeszcze inny, najbardziej liberalny, rodzaj kontraktu — Time & materials. Ta formuła oznacza, że dostawca, po zielonym świetle od strony klienta, zaczyna pracować nad produktem, raportując w określonych interwałach, jaki budżet został już wykorzystany według wcześniej ustalonej stawki. Najłatwiej sobie to wyobrazić na przykładzie jazdy taksówką: po rozpoczęciu kursu taksometr zaczyna bić i im dalej chcemy dojechać, tym proporcjonalnie więcej zapłacimy. Oczywiście nikt nie ma nieograniczonych budżetów, dlatego stosuje się wariację nazywaną Capped time & materials. To oznacza, że taksometr cały czas bije, ale dojedziemy tak daleko, na ile nam starczy gotówki w portfelu.

Im mniej usztywnień, tym większa transparentność procesu i komunikacji między stronami. Mniej usztywnień wymaga większego doświadczenia i zaufania, ale też generuje znacznie mniej niespodzianek projektowych.

Od czego zależy cena projektu mobilnego?

IKEA ma w swoją filozofię wpisaną zasadę, że projektowanie mebli zaczyna od ceny: „At IKEA we design the price tag first and then develop the product to suit that price”. Mimo to (a może właśnie dzięki temu!) nawet najtańsze produkty z IKEA znane są z jakości. Mamy więc lampki na biurko, których rozpiętość cenowa wynosi od 50 do 250 zł — pięciokrotna różnica! Takie podejście nazywa się design to cost.

Wybraźmy sobie, że tworzenie aplikacji jest jak urządzanie mieszkania. Planując nowe miejsce do życia, zazwyczaj wyznaczamy sobie pewien budżet, szacując nasze możliwości finansowe oraz inne aspekty życiowe (Czy to jest nasz docelowy dom? Czy mieszkanie będzie narażone na niszczący wpływ zwierząt? Czy będą w nim mieszkać małe dzieci? I tak dalej).

Załóżmy więc, że mamy budżet w granicach od 20 to 100 tysięcy złotych. Idąc do IKEA, możemy kupić wszystkie meble spełniające swoje funkcje w pełnym spektrum tej ceny. I wiemy, że zarówno stół za 400 złotych, jak i ten za 2000 złotych będzie wypełniał swoją rolę. Inna będzie jakość materiałów i ich trwałość — pierwszy stół zacznie się zużywać po kilku latach, a ten pięć razy droższy będzie ładniejszy i wytrzymalszy. Pojawia się więc pytanie: na czym nam bardziej zależy? Czy to mieszkanie, w którym chcemy spędzić resztę życia? Czy jedynie na okres przejściowy? Oba podejścia rządzą się swoimi prawami i wymagają innych decyzji.

Tak samo jest z tworzeniem aplikacji. Jeśli chcesz zwalidować rynkowo swoją hipotezę, to nie potrzebujesz dokładnej do ostatniego piksela grafiki i animacji, a jedynie designu i UX, który jest wystarczająco dobry. Jeśli twoja idea faktycznie ma sens i użytkownicy reagują pozytywnie, to wtedy uzupełniamy produkt tam, gdzie wykazuje największe braki.

Zalecana dalsza lektura

- Agile w praktyce, Andy Brandt, https://leanpub.com/Agile_w_Praktyce

- Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage, Tom Gilb

- Design of everyday things, Donald A. Norman,

- Management 3.0, Jurgen Appelo

- Manifest Zwinnego Tworzenia Oprogramowania, http://agilemanifesto.org/iso/pl


[1] Definicja z polskiej wersji Scrum Guide autorstwa Tomasza Włodarka, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-PL.pdf

[2] Agile w praktyce, Andy Brandt, https://leanpub.com/Agile_w_Praktyce

[3] Design of everyday things, Donald A. Norman, http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0465067107

Rozdział 6 Produkt mobilny

Mając odpowiednio przygotowane środowisko pracy, można przystąpić do tworzenia produktu mobilnego. Różni się on na wielu płaszczyznach od innych produktów cyfrowych, co ma także odzwierciedlenie w procesie jego powstawania.

Większość firm z wysokim zapotrzebowaniem na rozwiązania technologiczne istniało na rynku przed pojawieniem się współczesnych rozwiązań mobilnych. Ich usługi lub produkty istnieją już w innej postaci, prawdopodobnie dla klienta widoczne w formie strony WWW dostosowanej do komputerów. Posiadanie przez nie aplikacji mobilnej jest więc traktowane jako jeden z kolejnych etapów rozwoju — są firmami kategorii mobile-second.

Gdy zapada decyzja o stworzeniu wersji mobilnej usługi lub produktu firmy, zazwyczaj mówi się o przeniesieniu wersji desktopowej na mobile — nazywa się to „portowaniem”. Nazwa została przeniesiona z branży gier elektronicznych. Jeśli pierwsza wersja gry była stworzona na komputery PC, odniosła sukces i zostaje przeniesiona na konsole do gier (lub odwrotnie), to taką grę na nowej platfromie nazywa się „portem”.

Portowanie można rozważać w trzech odmianach:

- ze strony destkopowej do strony mobilnej,

- ze strony desktopowej do aplikacji mobilnej,

- z programu komputerowego do aplikacji mobilnej.

Zasady ich przenoszenia są wspólne na poziomie idei, ale różnią się ze względu na możliwości i ograniczenia technologiczne, kontekst użycia i zasady narzucane przez platformy.

Naturalnym pierwszym rozwiązaniem jest próba portowania dotychczasowego sposobu myślenia i funkcjonowania. W tym wypadku pojawiają się dwie grupy problemów: po pierwsze, użytkownik komputera wymaga innego podejścia niż użytkownik smartfona, a po drugie mobile to zupełnie inny kanał komunikacji z innymi możliwościami i ograniczeniami.

Te różnice wynikają z różnego sposobu interakcji między człowiekiem a urządzeniem.

Komputer nie wymusza interakcji. Użytkownik korzysta z niego statycznie, na siedząco, przy dobrych warunkach oświetleniowych. Zazwyczaj ma włączone wiele aplikacji jednocześnie i wszystkie walczą o jego uwagę. Głównym sposobem interakcji jest klawiatura i myszka lub gładzik. Komputer jest podłączony do Internetu wtedy, gdy użytkownik tego zechce. Użytkownik ma niskie zaufanie do swojego komputera. Komputer zazwyczaj nie pobiera informacji o geolokalizacji użytkownika.

Smartfon aktywnie walczy o uwagę, dzwoniąc i wibrując. Użytkownik mobilny korzysta ze swojego urządzenia dynamicznie, w szybko zmieniających się warunkach. Zazwyczaj jedna aplikacja zajmuje cały wyświetlacz. Jedynym sposobem interkacji jest dotykowy ekran, a samo urządzenie jest ciągle podłączone do Internetu. Użytkownik uważa smartfon za najważniejszą rzecz, jaką posiada. Smartfon ma możliwości „zrozumienia” kontekstu wykorzystania i pobiera informacje o otoczeniu użytkownika (geolokalizacja).

Te różnice powodują konieczność zmiany podejścia do projektowania i wdrażania systemów na urządzenia stacjonarne (komputery) i dynamiczne (smartfony) oraz do zależności między nimi.

Przenoszenie usługi między różnymi kanałami

Dobrą praktyką tworzenia produktów na wiele platform jest zaczynanie od „najmniejszej” wersji i rozszerzanie jej funkcjonalności wraz ze zwiększaniem mocy obliczeniowej urządzeń i wielkości ekranów. Dzięki temu projekt zachowuje spójność, a jego rozwój jest cały czas skupiony na najważniejszych funkcjach. To jednak może być trudne, bo zazwyczaj zakłada wyrzucenie do kosza obecnie posiadanego rozwiązania na duże ekrany.

Aby tego nie robić i uzyskać wystarczająco dobry efekt w krótkim czasie i w ramach mniejszego budżetu, wprowadza się zestaw kosmetycznych sztuczek, aby dopasowywać stronę desktopową do warunków mobilnych.

Pierwszy przypadek to taktyka Progressive Enhancement, a drugi — Graceful Degradation.

Przez Graceful Degradation rozumie się podejście obecnie popularne w większości polskich serwisów internetowych. Większość z nich oparta jest na projekcie graficznym i technologii, które pojawiły przed ideą RWD (Responsive Web Design), przez co nie radzą sobie zbyt dobrze z obsługą smartfonów i tabletów.

Schemat Graceful Degradation

Właściciele biznesowi wiedzą, że koszt zamiany obecnej strony na wersję RWD jest duży, więc uciekają się do półśrodka, czyli dostosowywania komputerowej wersji strony do mniejszych, dotykowych ekranów. W takich wypadkach stosuje się arbitralne zasady, które w choć minimalnym stopniu mają poprawić czytelność i ogólną użyteczność strony poprzez:

- powiększanie przycisków i obszarów aktywnych,

- zwiększanie wielkości fontów,

- dodawanie mobilnej nawigacji,

- ukrywanie części treści strony,

- usuwanie treści wykonanych w technologii flash.

W skrajnych przypadkach użytkownik dostaje informację, że dana strona nie jest obsługiwana przez to urządzenie, z prośbą o skorzystanie z niej na komputerze.

Graceful Degradation można traktować jako rozwiązanie tymczasowe, które pozwala szybko i tanio budować inicjalne mobilne doświadczenie dla klientów. Gdy jednak udział wejść na stronę z urządzeń mobilnych będzie większy niż 10%, należy zacząć myśleć o przebudowie całej strony według idei Progressive Enhancement.

Progressive Enhancement to podejście „od małego do dużego”. Projektowanie strony zaczyna się od najmniejszego ekranu, na którym będzie oglądana, i wraz z jego zwiększaniem komplikuje się siatkę witryny i zwiększa natężenie informacji.

Schemat Progressive Enhancement

Z takim podejściem powinno się zaczynać projektowanie każdego nowego serwisu i usługi działającej jako strona internetowa. Nie tylko zmniejsza to chaos projektowy, ale także ułatwia określenie, co jest naprawdę ważne w produkcie, a co stanowi jedynie dodatek.

Metoda Progressive Enhancement polega na wykrystalizowaniu na samym początku najważniejszej funkcji i budowaniu reszty produktu wokół niej. Jeśli podstawowa funkcja jest dobrze realizowana, to wraz ze zwiększaniem się dostępnej powierzchni ekranu powiększają się elementy oraz zmienia siatka strony, aby dać miejsce nowym funkcjom.

Warto wspomnieć, że samo pojęcie Progressive Enhancement może być mylące, bo zakłada, że ogólna użyteczność zwiększa się wraz z rozmiarem ekranu. To jednak nie musi być prawdą ze względu na trzy czynniki:

- Smartfony dysponują dodatkowymi danymi niedostępnymi dla przeglądarek komputerowych. Na przykład zastosowanie geolokalizacji minimalizuje konieczność wpisywanie adresu dostawy.

- Ekrany smartfonów i tabletów są dotykowe. Dotyk jest naturalniejszym sposobem interakcji z technologią niż myszka i klawiatura.

- Mniejszy ekran smartfonów i tabletów wymusza mniejsze natężenie informacji — co prowadzi do mniejszego chaosu komunikacyjnego.

Bezpośrednio z podejścia Progressive Enhancement wynika Responsive Web Design, czyli podejście zapewniające optymalne wyświetlanie stron internetowych na danym ekranie. Silnik strony pobiera od przeglądarki użytkownika informację o parametrach urządzenia i na tej podstawie przyporządkowuje je do jednego z predefiniowanych stylów łamiania strony.

Mechanizm RWD

W efekcie zmieniają się proporcje wielkości zdjęć, fontów czy elementów nawigacyjnych strony, ale w taki sposób, aby zawsze widoczny był najważniejszy element strony, wokół którego budowane jest doświadczenie użytkownika.

Referencyjne modele telefonów

Zanim rozpocznie się proces tworzenia pierwszych szkiców aplikacji, należy przemyśleć kwestię listy urządzeń, na jakich aplikacja lub strona mobilna będzie się wyświetlać.

Aby wybrać grupę tych urządzeń (czyli modeli referencyjnych), trzeba zrozumieć, gdzie w grupie wszystkich użytkowników smartfonów znajdują się klienci firmy oraz jakie ograniczenia implementacyjne pojawiają się przy tworzeniu aplikacji. Część wspólna tych grup stworzy bazę modeli referecyjnych dla przygotowywanej aplikacji.

Referencyjne modele urządzeń mobilnych

W tym momencie istnieje w obiegu 10 modeli iPhone’ów (z czego sześć już nierozwijanych), dziewięć modeli iPadów (cztery nierozwijane) i pięć modeli iPodów touch z przeglądarką i dostępem do App Store (cztery nierozwijane). Wśród aktywnych urządzeń z iOS 64% korzysta z najnowszego systemu iOS 8, 32% z iOS 7 i 4% ze wszystkich wcześniejszych[1].

W wypadku Androida ten podział jest nieskończenie bardziej skomplikowany ze względu na ogromną liczbę producentów urządzeń z tym systemem, zastosowanych komponentów oraz jakości i proporcji ekranów. W tym momencie wyróżnia się prawie 19 tysięcy różnych urządzeń z systemem Android (w stosunku do 24 iOS). Najpopularniejszym i dominującym producentem smartfonów z Androidem jest Samsung (57%), następnie HTC (6%), Sony (5%), Motorola (5%), Asus (2%) i Amazon (1%)[2]. Wśród aktywnych urządzeń z Androidem z najnowszej wersji systemu KitKat (4.4) korzysta 34%, z Jelly Bean (4.1–4.3) — 28%, z Ice Cream Sandwich (4.0.3–4.0.4) — 8%, z Gingerbread (2.3.3–2.3.7) — 9%[3]. Bardzo ważne jest przy Androidzie rozróżnienie wielkości przekątnych ekranów i ich jakości. Aby ułatwić poruszanie się po różnych wariacjach Androida, wyróżnia się sześć kategorii rozdzielczości: ldpi, mdpi, tvdpi, hdpi, xhdpi i xxhdpi oraz cztery kategorie wielkości ekranów: small, normal, large i xlarge. Największe kategorie w tej siatce to: normal hdpi — 37%, normal xhdpi — 19% i normal xxhdpi — 16,3% (co odpowiada smartfonom i phabletom o rozdzielczościach non-retina i retina).

Windows Phone jest najbardziej homogenicznym z systemów: najnowszy system Windows Phone 8.1 ma 24%, Windows Phone 8.0–57%, Windows Phone 7.x — 19%. Najpopularniejszym producentem telefonów z Windows Phone jest Nokia — 94%, następny jest HTC — 4% oraz Samsung 1% i Huawei 1%.

W Polsce najpopularniejszym producentem urządzeń mobilnych jest Samsung z jego rodziną smartfonów Galaxy S (to 33% rynku). Następnie Apple (26% rynku) i Sony (13% rynku).

Aplikacje natywne, HTML5 i hybrydowe

Organizacja, która chce mieć własną aplikację mobilną, stoi przed wyborem sposobu realizacji, a co za tym idzie także grup technologii i języków programowania. Ta decyzja musi być podjęta na podstawie wniosków strategicznych (omawiałem ten temat szczegółowo w rozdziale czwartym, w części Jakość kontra ilość), ale należy także wiedzieć, co niesie ze sobą dany wybór.

Uogólniając, istnieją trzy taktyki realizacji aplikacji mobilnej:

1. Jako oprogramowanie natywne — to oznacza, że na każdej platformie wykorzystywany będzie preferowany przez producenta systemu operacyjnego język programowania (iOS — Objective-C oraz Swift, Android — Java, Windows Phone — C#), co pozwala na bezpośrednie korzystanie z zasobów urządzenia.

2. Jako oprogramowanie uniwersalne — z wykorzystaniem frameworka, który pozwala na przetłumaczenie uniwersalnych komend na takie, które są zrozumiałe dla każdego systemu mobilnego. Oznacza to, że raz napisany program może być uruchomiony na każdej z platform.

3. Jako oprogramowanie hybrydowe, które łączy dwa powyższe podejścia. Podstawowa część kodu jest natywna, specyficzne elementy budowane są natomiast w podejściu uniwersalnym.

Każde z przedstawionych rozwiązań ma swoje plusy i minusy — ich skuteczność zależy od zdefiniowanych wcześniej wymagań biznesowych.

Aplikacje natywne korzystają z dostarczonych przez producenta API (Application Programming Interface), dzięki czemu programiści mogą korzystać bezpośrednio z zasobów, jakie oferuje smartfon bądź tablet. Dzięki temu aplikacje działają sprawniej, bo w najmniejszym stopniu obciążają procesor i pamięć urządzenia. Dodatkowo korzystanie z natywnych rozwiązań skraca czas potrzebny na testowanie aplikacji na faktycznych urządzeniach. Minusem tego podejścia jest konieczność inwestowania w niezależnych programistów specjalizujących się w każdej platformie oddzielnie.

Aplikacje uniwersalne bazują na takich rozwiązaniach, jak na przykład PhoneGap, pozwalający na pisanie kodu HTML5 (w połączeniu z JS i CSS), który później jest tłumaczony na kod zrozumiały dla urządzeń mobilnych niezależnie od platformy. Kod HTML5 powstaje znacznie szybciej niż rozwiązania natywne, ale obarczony jest licznymi problemami związanymi z responsywnością ze względu na to, że wspomniany framework jest warstwą pośrednią, która dodatkowo obciąża procesor i pamięć. Oprócz tego ceną uniwersalności są: pomijanie specyficznych funkcji i możliwości poszczególnych systemów mobilnych, ograniczenia związane z animacjami oraz znacznie dłuższy proces testowania gotowej aplikacji. Te problemy powodują, że ostatecznie jakość aplikacji i doświadczenie użytkownika jest poniżej akceptowalnej normy, dlatego rozwiązania uniwersalne stosuje się jedynie jako prototypy lub pierwsze testy rynkowe — przed przejściem na podejście natywne.

Rozwiązaniem pośrednim jest podejście hybrydowe. Ta taktyka ma łączyć zalety obu pozostałych podejść: jakość natywnego kodu oraz ekonomiczność kodu HTML5. Zazwyczaj takie podejście stosuje się, gdy aplikacja zawiera treści zarówno szybko-, jak i wolnozmienialne. Wtedy główna struktura i nawigacja aplikacji tworzona jest w kodzie natywnym, treści szybkozmienialne powstają natomiast w postaci kodu HTML, który jest zaciągany spoza aplikacji[4]. Dzięki temu, jeśli będzie taka potrzeba, programiści mogą szybko aktualizować kod HTML (w zakresie ustandaryzowanej struktury natywnego kodu) bez konieczności aktualizacji samej aplikacji w sklepie mobilnym. Jest to wygodne, gdy na przykład pojawi się konieczność zmiany procesu zakupowego i potrzebna jest natychmiastowa aktualizacja formularza płatności.

Etapy powstawania produktu

Każdy kolejny etap i forma opisu wizji ma za zadanie nieść większą liczbę informacji i coraz lepiej ilustrować wizualnie i technologicznie zamianę idei w produkt.

Etapy powstawania produktu

Najlepiej przedstawić ideę w formie krótkiego zarysu i szkicu. Celem jest nadać temu, co siedzi w głowie, formę ogólnie zrozumiałą dla innych ludzi, ale bez wskazywania szczegółów. Ideą może być zarówno „nasz sklep internetowy, ale w formie aplikacji mobilnej”, jak i „aplikacja do dzielenia się zdjęciami udostępniająca filtry”. Idea jest statyczna, to znaczy, że opisuje zamierzony stan bez pokazywania procesu, jaki do niego prowadzi. Userflow to schemat przepływu użytkowników, który rozwija ideę o logikę użytkową. Jeśli użytkownicy aplikacji mogą kupować w moim sklepie internetowym, to powinni się najpierw zarejestrować i zalogować. Jeśli w aplikacji można dzielić się zdjęciami, to komu i jak mogę je wysłać? Userflow pokazuje proces i dynamikę.

Makiety Lo-Fi to pierwszy etap faktycznej wizualizacji tego, co w przyszłości będzie widział użytkownik. Lo-Fi oznacza low fidelity,a więc niską wierność. W tej wersji celem jest sprawdzenie najbardziej logicznego rozłożenie elementów (logotypów, przycisków, obrazków, pól tekstowych itp.), więc aby nie rozpraszać przekazu, rezygnuje się z kolorów i faktycznych kształtów. Większość makiet Lo-Fi jest w odcieniach szarości, z wypełniaczami zamiast faktycznych grafik i „lorem ipsum” zamiast faktycznych bloków tekstowych. Ważne, aby makiety lo-fi miały proporcje zgodne z ekranem smartfona.

Gdy makiety lo-fi zostaną zwalidowane pozytywnie, następuje dodanie warstwy graficznej do projektu — w ten sposób powstają makiety high fidelity(Hi-Fi). Na tym etapie dochodzą potencjalne obostrzenia wynikające z konieczności zachowania spójności wizualnej i sposobu prezentowania logotypu. Makiety Hi-Fi można ze sobą połączyć w logiczną całość — w ten sposób powstaje interaktywna makieta, którą wykorzystuje się do szybkiego testowania przez potencjalnych użytkowników.

W odróżnieniu od interaktywnych makiet prototyp zawiera działający fragment kodu. To oznacza, że aplikacja staje się jednym z kilku elementów większego systemu, który pozwala jej działać. Na przykład, w aplikacji sklepowej można dodać wybrany towar do koszyka i jest to widoczne w bazie danych. Gdy wszystkie najważniejsze funkcje zostaną zrealizowane, przychodzi czas na testowanie prototypu w środowisku zbliżonym do publicznego. Zespół, który jest w pełni skupiony na tworzeniu produktu, szybko staje się ślepy na błędy i nielogiczności, które zawsze pojawiają się w tak złożonych projektach. Aby takie błędy wyłapać i zdobyć nową perspektywę, zatrudnia się betatesterów, którzy nie mieli wcześniejszego kontaktu z aplikacją.

Gdy aplikacja osiągnie zadowalający etap rozwoju, następuje wypuszczenie wersji 1.0, czyli wersji publicznej. Nie jest to jednak koniec pracy, a raczej czas na testowanie efektu skali, zbieranie opinii rynkowych i wyciąganie wniosków przed wypuszczeniem nowej wersji.

Zarys

Zarys to ogólny opis idei aplikacji mobilnej. To powinien być bardzo ogólny szkic, który wizualizuje hipotezę. Zarys stanowi punkt odniesienia i sposób na przekazanie kontekstu i najważniejszej funkcji aplikacji. Zazwyczaj taki zarys istnieje w postaci krótkiego opisu (user story) i (lub) szkicu pokazującego ekran z funkcją. Na tym etapie szczegóły nie mają znaczenia — liczy się przekazanie w jak najłatwiejszy sposób idei tak, aby była natychmiast zrozumiała dla postronnych osób.

Aby takie zrozumienie budować, wykorzystuje się analogie, miksując już istniejące mechanizmy (Uber dla X) lub zmieniając ich kontekst (Nauka języka obcego, ale na smartfonie).

Userflow (diagram przepływu użytkowników)

Pierwszym etapem jest stworzenie (zazwyczaj papierowego) diagramu przepływu użytkowników. Takie flow ma za cel zawrzeć w sobie główną i ogólną ideę aplikacji. Robi się to przez wizualizację ścieżki potrzebnej do realizacji głównego zadania aplikacji. Jeżeli jest to aplikacja zakupowa, będzie to ścieżka od włączenia aplikacji do opłacenia zakupów, a jeśli aplikacja randkowa — wysłanie wiadomości do wybranej osoby.

Userflow będzie bardzo szybko się rozrastało, ponieważ zacznie pokrywać funkcje, które w myślach i wyobrażeniach wydają się oczywiste, ale muszą być fizycznie uwzględnione w projekcie, na przykład jeśli w aplikcji jest logowanie, to prawdopodobnie powinna być też rejestracja. Jeśli tak, to należy rozważyć różne formy rejestracji — nie tylko przez e-mail, ale także przez Facebook, Twitter czy LinkedIn. Każdy z tych procesów, choć podobny, wymaga rozdzielnego przedstawienia.

Inny przykład: co dzieje się z użytkownikiem, który wykona zakupy w naszej aplikacji — wraca na ekran główny, do swojego profilu czy do historii zakupów?

Myśląc o tworzeniu userflow, kieruję się następującą kolejnością wizualizacji:

1. Główna funkcja aplikacji (co ma osiągnąć mój użytkownik?).

2. Funkcje ułatwiające realizację głównego zadania aplikacji (historia, profil, rekomendacje itp.).

3. Proces rejestrowania, logowania, zmiany hasła i wylogowywania z aplikacji.

4. Onboarding — przywitanie, samouczek i wdrożenie użytkownika.

5. Funkcje społecznościowe (książka adresowa, dzielenie się treścią).

Na tym etapie kończy się prosty userflow.

6. Funkcje niewidoczne dla użytkownika końcowego (synchronizacja danych, wykorzystanie API, komunikacja z serwerem).

7. Komunikaty potwierdzeń, informacji i błędów.

8. Eliminacja ślepych zaułków w aplikacji (czyli upewnienie się, że z każdego miejsca w aplikacji można dostać się w każde inne).

Z doświadczenia projektowego wiem, że najlepiej jest utrzymywać w projekcie dwa dokumenty userflow — jeden prosty, przedstawiający najważniejsze funkcje aplikacji oraz drugi, rozbudowany, uwzględniający najważniejsze przejścia i zachowania aplikacji.

Są różne narzędzia do userflow — w moim przypadku najlepiej sprawdza się biała tablica i markery, a na późniejszym etapie aplikacje do tworzenia map myśli.

Czasami userflow aplikacji rozszerza się także poza samą aplikację. Na przykład rejestracja połączona jest z koniecznością wejścia na specjalnie przygotowaną stronę mobilną, a dopiero później do aplikacji. Zazwyczaj takie chwilowe odskocznie poza aplikacje także dodaje się do userflow (także prostego), aby uzyskać obraz potrzebnego ekosystemu technologicznego.

Często userflow rośnie wraz z aplikacją, dodaje się do niego ekrany i łączy poszczególne przyciski z ekranami, które wywołują. Wtedy userflow jest żyjącym dokumentem, który daje całościowy obraz projektu i jego postępów.

Przykład: Instagram

Jaką podstawową funkcję spełnia Instagram? Pozwala na publikację upiększonego zdjęcia.

Zacznijmy od celu

Oczywiście to nie wystarczy, żeby stworzyć aplikację. Schemat musi bowiem uwzględniać mnóstwo założeń, wytycznych i warunków. Każda komplikacja userflow pojawia się wtedy, gdy znamy odpowiedź na następne pytanie. Na przykład: skąd bierze się zdjęcie? Mamy dwie możliwości: z już istniejącej galerii lub z aparatu w telefonie.

Pierwsze decyzje

Załóżmy, że udało nam się opublikować zdjęcie. Co się jednak dzieje z użytkownikiem później? Przecież nie zostawimy go bez wyjścia. Gdzie powinniśmy go przenieść? W Instagramie ekranem głównym, który rozprowadza ruch po reszcie serwisu, jest widok strumienia aktywności, gdzie widzimy chronologicznie ustawione zdjęcia nasze i naszych znajomych.

Ekran strumienia aktywności staje się centralnym punktem aplikacji

W każdej aplikacji jest taki ekran, który stanowi „stan początkowy” — to odpowiednik głównej strony portalu bądź spisu treści w książce.

Mamy strumień aktywności i potencjalnie powinniśmy tam widzieć zdjęcia naszych znajomych. Ale jak oni się tam znajdą? Skąd system wie, kto jest moim znajomym? Konieczne jest dodanie rejestracji i logowania.

Podstawowa ścieżka jest gotowa

Mamy więc na ogólnym poziomie szczegółowości pokrytą podstawową ścieżkę: można się zarejestrować, zalogować, wybrać zdjęcie, dodać filtr i opublikować zdjęcie.

Teraz trzeba obudować podstawową ścieżkę elementami, które spełniają dodatkowe funkcje niezbędne do sukcesu aplikacji — zarówno od strony biznesowej, jak i formalnej.

Nowe elementy budują strukturę i nawigację

Mając tak przygotowaną „mapę” aplikacji, wiemy, jak myśleć o aplikacji i co jest jej centralnym punktem. Oczywiście tak przedstawiony Instagram jest niezwykle uproszony. Prawdziwa aplikacja ma o wiele więcej funkcji, od nagrywania filmów po wysyłanie prywatnych wiadomości.

Na tym etapie ominąłem dużo ważnych elementów aplikacji, które wynikają z kwestii prawnych (regulaminy) czy technologicznych (zgody na dostęp do konkretnych funkcji telefonu, jak geolokalizacja czy prywatne dane). Jest jednak jedna część projektu aplikacji, która wymaga dokładniejszego omówienia, bo od niej zależy, jak dużo użytkowników pozostanie w aplikacji po jej pierwszym włączeniu. To onboarding.


[1]Apple Developer — App Store Distribution, dane z 4.01.2015, https://developer.apple.com/support/appstore

[2]Mixpanel Android Manufacturers, https://mixpanel.com/trends/#report/android_manufacturer

[3]Android Developer Dashboard — Platform Versions, https://developer.android.com/about/dashboards/index.html

[4]Hybrid sweet spot: Native navigation, web content, https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native-navigation-web-content

Onboarding

Onboarding to proces przywitania, rejestracji, pierwszego logowania i zaznajomienia użytkownika z aplikacją, którą za chwilę zacznie wykorzystywać. Cały proces ma dwa aspekty:

- administracyjno-technologiczny: aplikacja prosi o udostępnienie danych prywatnych, rejestracja, pierwsze logowanie (jeśli jest to iOS),

- zapoznawczy: buduje dobre pierwsze wrażenie i poczucie bezpieczeństwa.

Ta druga część jest najłatwiejsza do uzyskania dzięki samouczkowi. To kilka statycznych obrazków bądź animacja prezentująca informacje o tym, co aplikacja robi i jak użytkownik powinien jej używać.

Podstawowy schemat rejestracji i logowania

Podstawowy proces onboardingu może składać się z zaproszenia do rejestracji bądź zalogowania do aplikacji. W przypadku braku konta wymagana jest rejestracja, a zaraz po niej weryfikacja konta, najczęściej za pomocą poczty elektronicznej.

Co się dzieje podczas logowania

Po rejestracji i pierwszym zalogowaniu może pojawić się samouczek, który pozwala na zaznajomienie się z najważniejszymi funkcjami aplikacji. Często na tym etapie aplikacja (jeśli jest na iOS) prosi o dostęp do konkretnych możliwości telefonu, jak geolokalizacja, możliwość skorzystania z aparatu czy udostępnienie książki telefonicznej. Po tym etapie następuje przejście do ekranu głównego, a więc klasycznego userflow całego systemu.

Warto pamiętać, że to tylko jeden z wielu przykładów na onboarding. Może zdarzyć się tak, że rejestracja i logowanie jest wymagane dopiero podczas korzystania z konkretnej funkcji wewnątrz aplikacji — wtedy użytkownik jest wpuszczany od razu do systemu, dzięki czemu może się rozejrzeć i przyzwyczajać się do tego, co aplikacja ma mu do zaoferowania. Bywa i tak, że rejestracja w ogóle nie jest wymagana, a samouczek jest pokazywany w częściach na poszczególnych ekranach funkcyjnych. Wszystko to zależy od zrozumienia specyfiki użytkownika.

Makiety Lo-Fi

Następnym etapem jest stworzenie makiet Low Fidelity (Lo-Fi), czyli uogólnionej wizualnej reprezentacji najważniejszych ekranów aplikacji. Podstawowym atrybutem makiet Lo-Fi jest to, że specjalnie pomija się w ich przypadku docelowe kolory i kształty. Celem Lo-Fi jest przedstawienie logicznego układu najważniejszych elementów widocznych dla użytkownika.

Zazwyczaj Lo-Fi to czarno-białe szkice na papierze bądź tablicy. Później przenoszone są do wersji cyfrowej jako zdjęcia bądź dzięki aplikacjom dostosowanych do obsługi makiet Lo-Fi. Odcięcie się z premedytacją od kolorów i kształtów pozwala na skupienie się na najważniejszym — logice procesu, zrozumieniu komunikatu i walidacji sensu aplikacji.

Przykład makiet Lo-Fi

W makietach Lo-Fi najważniejsze jest logiczne umiejscowienie elementów aplikacji na ekranach tak, aby ta spełniała swoją funkcję.

Znajomy projektant użyteczności opowiadał mi, że podczas prezentacji przed klientem makiet Lo-Fi dla jego aplikacji klient popatrzył i stwierdził, że mu się podoba i można zacząć wdrażać, ale prosi, aby następnym razem korzystać z większej palety kolorów niż tylko czarny i biały.

Warto już na tym etapie pokazywać makiety osobom spoza projektu, aby przetestować, czy rozumieją ideę aplikacji, którą tworzymy. Najlepiej jest to robić, korzystając z aplikacji do prezentowania makiet: GetLaunch, Flinto, Marvel lub podobnych. Wystarczy zrobić zdjęcia papierowym makietom, zaznaczyć obczary klikalne na zdjęciu i podłączyć pod następne zdjęcie. Tak połączone ekrany prezentujemy jako klikalną makietę i obserwujemy, jak reaguje potencjalny klient — a przede wszystkim, czy widzi wartość już na tym poziomie abstrakcji

Fold

Nie zdarza się tak, że po włączeniu aplikacji wszystkie informacje, które chcemy uzyskać, są dla nas widoczne od razu. Dostęp do następnych elementów wymaga interakcji — zazwyczaj tapnięcia lub przewinięcia ekranu. Naturalnie więc wszystko, co jest widoczne od razu, zdobywa większą uwagę niż to, co wymaga interakcji. Pierwsza grupa treści nosi nazwę above the fold(ATF), a druga — below the fold(BTF). Pojęcia te zostały zaczerpnięte ze słownictwa używanego w wydawnictwach gazetowych. Dzienniki drukowane na wielkich płachtach papieru były tak łamane, aby uwidocznić to, co znajduje się w górnej połowie głównej strony. Dolna część była natomiast widoczna dopiero po rozłożeniu całej gazety.

Fold — podział na treści ATF i BTF

Z perspektywy biznesowej to, co się dzieje above the fold, jest ważniejsze, bo zyskuje lepszą ekspozycję. Użytkownik zawsze zobaczy reklamę ATF po włączeniu strony internetowej, nie ma natomiast pewności, czy spojrzy na to, co dzieje się w BTF — bo to wymaga od niego interakcji.

Konsekwencją projektowania na urządzenia mobilne jest zmniejszenie objętości ATF i przesuwanie treści do BTF oraz szukanie rozwiązań na sztuczne powiększanie ATF. Stąd, między innymi, taka popularność nawigacji z wykorzystaniem „hamburgera”, która uwalniała mnóstwo przestrzeni przez przesunięcie nawigacji do niezależnego okna lub panelu. Swoją drogą toczy się dyskusja, czy wysuwane menu widoczne po interakcji na pierwszym ekranie należy do ATF czy do BTF, odpowiada bowiem po trosze definicjom obydwu kategorii.

Makietowanie Hi-Fi

Gdy makiety Lo-Fi zostaną zaakceptowane, to następnym etapem jest tworzenie wersji o wysokiej wierności, czyli High Fidelity (Hi-Fi). Tworzy się je na podstawie dwóch grup artefaktów:

- powstałych w trakcie dotychczasowej pracy produktowej: userflow, szkiców, makiety Lo-Fi,

- narzuconych z zewnątrz: identyfikacja wizualna, paleta kolorystyczna, dobre praktyki właściciela platformy mobilnej.

O ile w makietach Lo-Fi zgodność z zasadami projektowymi platform mobilnych nie jest wymagana, to przy makietach Hi-Fi jest traktowana jako dobra praktyka, a czasem konieczność. Z doświadczenia wiem, że zwalidowanie na tym etapie makiet pod względem zgodności z zasadami iOS-a[1], Androida[2] bądź WindowsPhone[3] przyśpiesza tworzenie kodu.

Przykład makiety Hi-Fi

Na etapie makiet Hi-Fi trzeba zacząć testować design pod kątem elastyczności językowej na dwóch polach: różnych wersji językowych (lokalizacji) oraz spójności języka komunikacji z ogólnym przekazem aplikacji. Jeśli aplikacja ma obsługiwać wiele wersji językowych to należy zwrócić uwagę na dobór odpowiedniego fontu tak, aby miał w swojej palecie znaki i litery specjalne. Trzeba też uwzględnić przy projektowaniu makiet Hi-Fi różną długość komunikatów i podpisów przycisków w zależności od wersji językowej.

Wszystkie trzy najważniejsze platformy mają dedykowane fonty dla swoich aplikacji, ale twórcy aplikacji często chcą skorzystać z własnych, które lepiej oddają specyfikę ich produktów. Między innymi z tego powodu, aż do 2015 roku, aplikacja Evernote nie obsługuje dobrze polskich liter na iOS.

Graficy, projektując makiety Hi-Fi, często zatrzymują się na idealnych przypadkach układu elementów i treści. Nie można jednak na tym poprzestać i trzeba testować, czy design obroni się w przypadkach niestandardowych, które okazują się często bardzo życiowe. Jaką bowiem długość nazwiska powinna wyświetlać moja aplikacja? Jak zachowa się design, jeśli trzeba będzie wyświetlić dwuczłonowe nazwisko użytkowniczki? Dobrą zasadą jest wtedy myśleć ekstremami: jaką maksymalną i minimalną długość może mieć login użytkownika, komunikat, lista produktów czy tytuł ekranu.

Makiety Hi-Fi muszą uwzględniać różnice wynikające ze specyfiki poszczególnych systemów mobilnych. Te różnice mogą mieć znaczenie fundamentalne (logika nawigacji w aplikacji), ale także kosmetyczne (zgodność wizualna z resztą systemu).

Ekran główny aplikacji Instagram na Androidzie
Ekran główny aplikacji Instagram na iOS

W naszym przykładzie główny ekran Instagramu na różnych systemach mobilnych niewiele się różni. Widać różnice w zastosowanych fontach oraz proporcjach elementów, wprowadzone, aby zharmonizować aplikację z resztą systemu.

Ekran filtrów aplikacji Instagram na Androidzie
Ekran filtrów aplikacji Instagram na iOS

Podobnie jest na dalszych ekranach aplikacji. Subtelną różnicę widać w górnym nagłówku. W przypadku iOS zdecydowano się rozróżnić strzałkę w lewo i przycisk Next, natomiast na Androidzie występują dwie strzałki. Ten ruch znów ma zapewnić większą spójność z systemem mobilnym, na którym włączona jest aplikacja.

Ikona

Ikona reprezentuje aplikację — w dosłowny bądź metaforyczny sposób komunikuje jej znaczenie i funkcję. W przypadku aplikacji mobilnej ikona pełni taką samą rolę jak front sklepu — ma zachęcać do wejścia i skorzystania. Ikona aplikacja musi być rozpoznawalna wśród innych ikon. Aby to osiągnąć, najlepiej jest zrezygnować ze szczegółów i skupić się na uwypukleniu najważniejszego, unikatowego znaczenia. Najlepsze ikony są zawsze minimalistyczne, pozbawione szumu informacyjnego.

Ikona ma znaczenie na dwóch etapach:

1. Gdy użytkownik przegląda sklep z aplikacjami i poszukuje czegoś nowego. Wtedy będzie zwracał uwagę przede wszystkim na aspekty wizualne, a więc ekrany aplikacji i właśnie jej ikonę.

2. Gdy użytkownik po zainstalowaniu aplikacji chce ją odnaleźć wśród innych ściągniętych programów — wtedy ikona pełni rolę wizualnego wyróżnika, który pozwala szybko ją rozpoznać.

Należy pamiętać, że ikona to nie logo. Ze względu na zasady systemów operacyjnych i spójność wizualną ikony powstają na planie kwadratów (tak, aby mogły się dobrze układać w równomierne siatki). Nie zawsze udaje się zmieścić na ikonie logo firmy bądź marki.

Najgorszym rozwiązaniem w takich sytuacjach jest umieszczanie na ikonie zarówno logo, jak i nazwy marki. Spotykałem propozycje ikon aplikacji, w których nazwa marki była wpisana w ikonę po skosie, aby się zmieściła.

Ikona aplikacji to banner reklamowy, który użytkownik nosi cały czas przy sobie. Za każdym razem, jak przegląda swoje aplikacje, widzi także ją. To powoduje, że marka uzyskuje następny punkt styku z użytkownikiem. To właśnie dlatego ikona jest tak ważna.

Animacje

W 1981 roku Ollie Johnston i Frank Thomas wydali książkę The Illusion of Life: Disney Animation[4], w której określili 12 podstawowych zasad animacji. Każda z zasad ma za zadanie pokazać, w jaki sposób tworzyć animacje, aby wydawały się naturalne i zrozumiałe dla oglądającego. Najważniejszą zasadą jest „ściskanie i rozciąganie”, czyli konieczność nadawania wirtualnym, animowanym przedmiotom ich fizycznej wagi i elastyczności[5].

Interakcja ze smartfonami przez dotyk jest dla nas tak oczywista, ponieważ przypomina interakcję z rzeczywistymi przedmiotami. Aby jednak takie poczucie nie zaginęło, potrzebna jest rzeczywista reakcja elementu, z którym wchodzimy w interakcję na ekranie urządzenia mobilnego.

Do tego właśnie służą animacje. Dają one poczucie, że wirtualne przedmioty mają fizyczne właściwości. Ruch obiektu obserwowany przez ludzkie oko jest analizowany przez mózg, który wyciąga wnioski o właściwościach fizycznych tego obiektu (na przykład, czy coś jest „lekkie” czy „ciężkie”, „twarde” czy „rozciągliwe”). Dzięki temu obiekty na ekranie w większym stopniu przypominają rzeczywistość, co przekłada się na lepsze zrozumienie aplikacji oraz większe poczucie satysfakcji z jej używania.

Tworzenie animacji ma także znaczenie biznesowe. Użytkownicy mobilni są wyczuleni na aspekt wizualny i twórcy aplikacji wiedzą, że sposobem na wywołanie większej satysfakcji z jej używania jest tworzenie bogatych i przyciągających oko animacji. Może to stanowić przewagę biznesową i wyróżnik rynkowy.

W 2013 roku, gdy jeszcze nie istniały narzędzia do szybkiego prototypowania animacji, aby pokazać nasz pomysł na dynamiczne prezentowanie treści w aplikacji, potrafiliśmy w Senfino wykorzystać do tego styropianowe opakowanie po jedzeniu na wynos z wyciętym nożyczkami okienkiem o formacie ekranu iPhone’a. Jedna osoba trzymała opakowanie, a druga przesuwała pod spodem kartkę, prezentując przewijanie, powiększanie i inne gesty na elementach makiety.

Interaktywne makiety

Interaktywne makiety to w gruncie rzeczy makiety Hi-Fi (czasami Lo-Fi), które są połączone ze sobą w taki sposób, że osoba postronna na pierwszy rzut oka sądzi, że ma do czynienia z działającą aplikacją na prawdziwym smartfonie. W praktyce jednak są to statyczne grafiki z zaznaczonymi polami aktywnymi, po tapnięciu których ładowana jest następna grafika.

Interaktywne makiety tworzy się po to, aby móc zacząć testować reakcje na aplikację wśród potencjalnych użytkowników. Dzięki temu można sprawdzić wszystkie wcześniejsze hipotezy: ideę aplikacji (zarys), logikę i kolejność ekranów (userflow), proporcje i umiejscowienie elementów (makiety Lo-Fi) oraz reakcję na kształty, kolory i fonty (makiety Hi-Fi). Taka forma testów daje znacznie więcej niż opisywanie pomysłu czy pokazywanie statycznych ekranów.

Wprowadzanie zmian na podstawie tak zebranych opinii jest o wiele tańsze na tym etapie, gdyż nie wymaga przepisywania i adaptacji kodu, a jedynie poprawek graficznych.

Prototyp

Prototyp różni się od interaktywnych makiet tym, że jest to już prawdziwa, faktycznie działająca na telefonie aplikacja, realnie napisany kod. I choć ten kod może być jeszcze wielokrotnie przepisywany i dostosowywany do zmieniających się warunków rynkowych i projektowych, jest to już programistyczne odzwierciedlenie idei.

Na tym etapie po raz pierwszy dochodzi do walidacji założeń makiet przez programistów, którzy, będąc osobami na wskroś logicznie myślącymi, starają się przewidzieć wszystkie możliwe stany aplikacji. Ich celem jest jak najdokładniejsze przeniesienie tego, co widać, na to, co działa — w ten sposób powstaje logika aplikacji. Stąd należy przygotować na się na pytania typu: jak aplikacja ma się zachować, jeśli ktoś korzystając z niej wejdzie do metra i straci zasięg albo jaka jest maksymalna lub minimalna ilość znaków, jaką można wpisać w tym oknie.

Prototyp to aplikacja, która prawdopodobnie będzie się komunikować z jakimś systemem zewnętrznym. Na przykład, jeśli nasza wizja aplikacji zakłada możliwość przechowywania zrobionego aplikacją zdjęcia na serwerze (tak jak w Instagramie), to prototyp może to uwzględniać.

API

Jeśli twoja firma do tej pory czerpała zyski dzięki stronie WWW (na przykład portal, sklep internetowy), to istnieje duże prawdopodobieństwo, że zostało stworzone API — Application Programming Interface. Nie ma potrzeby wchodzić w szczegóły techniczne — na ten moment wystarczy nam taka definicja: API to zestaw komend, które pozwalają na dostęp do funkcji i (lub) danych systemu bądź aplikacji, to „wspólny język” oprogramowania. API stanowi warstwę pośrednią, która uodparnia aplikację na zmiany po stronie bazy danych i serwera. API to wspólnie ustalony język komunikacji. Jeśli więc część infrastrukturalna musi się zmienić, ale ciągle mówi w tym samym języku, to aplikacja będzie ciągle działać.

Jedno z pierwszych pytań przy tworzeniu aplikacji mobilnych, jakie zadają software house’y, jest właśnie o API. Jeśli istnieje, to ich praca będzie prostsza i szybsza. Jeśli nie, to muszą doliczyć dodatkowy czas na stworzenie go bądź rezygnują z projektu.

API

Jeśli masz sklep internetowy dostępny przez WWW i teraz chcesz mieć aplikację mobilną, która pozwala na przeglądanie twoich produktów, zalogowanie się za pomocą konta ze strony WWW i kupienie produktów, to właśnie dzięki API będzie to możliwe (w uproszczeniu). Dzięki API możliwe jest też tworzenie wielu różnych aplikacji na podstawie wspólnej infrastruktury (serwera i bazy danych).

Jeśli API nie istnieje, to musi być najpierw stworzone, zanim rozpocznie się praca nad aplikacją mobilną — inaczej jej tworzenie jest biznesowo nieuzasadnione.

Zazwyczaj API, które będzie po raz pierwszy wykorzystywane przy aplikacji mobilnej, wymaga modyfikacji i rozwinięcia ze względu na unikatowe możliwości, jakie dają aplikacje mobilne. Jednym z najpopularniejszych przykładów są notyfikacje push, które wykorzystywane są do budowania powracalności do aplikacji. Ta funkcja była do tej pory niespotykana, więc nic dziwnego, że pierwotnie nie myślano o niej przy tworzeniu API. Innym częstym usprawnieniem API wymuszanym przez aplikacje jest obsługa różnych formatów obrazków w zależności od rodzaju urządzenia mobilnego.

Wersja testowa

Wersja testowa to działające oprogramowanie, które można przekazać do użytkowania osobom spoza grupy osób zaangażowanych w produkt od strony zleceniodawcy i kontrahenta. Takie osoby mają za zadanie wychwycić wszystkie usterki technologiczne i niejasności komunikacyjne, których przez przyzwyczajenie i obeznanie z projektem nie zauważyli twórcy. Dlatego brak bezpośredniego zaangażowania w projekt jest bardzo ważną cechą betatesterów — obok dobrego oka do szczegółów i skrupulatności. Zadaniem betatesterów jest wprowadzanie aplikacji we wszystkie możliwe stany i wychwytywanie nieobsługiwanych, ale możliwych do zreplikowania zachowań i sytuacji w naturalnym środowisku standardowego użytkownika.

Podczas testowania aplikacji mobilnych PizzaPortal.pl dostaliśmy kilkadziesiąt kuponów, za które kupowaliśmy jedzenie do firmy — oczywiście aby testować nasze oprogramowanie.

Na tym etapie poprawiane są:

- komunikacja między aplikacją a serwerem,

- szybkość interkacji aplikacji z użytkownikiem,

- graficzna spójność szczegółów aplikacji,

- komunikaty prezentowane użytkownikowi.

Wersje testowych i błędy

Zanim nastąpi publikacja aplikacji w sklepie, należy ją sprawdzić na wyselekcjonowanej grupie betatesterów. Aby to ułatwić, istnieją specjalne systemy dystrybucji i zarządzania niepublicznymi wersjami oprogramowania mobilnego, takie jak Testflight (kupiony przez Apple) czy HockeyApp (kupiony przez Microsoft), które działają obok sklepów mobilnych. Dzięki nim zespół programistyczny ma pełną kontrolę nad tym, kto otrzyma wersję testową aplikacji. Jest ona niedostępna poza wyznaczoną grupą odbiorców, więc nie ma sposobu, aby aplikacja trafiła do obiegu, zanim będzie gotowa.

Wyznaczona osoba z zespołu produktowego podczas konfiguracji systemu dystrybucji tworzy bazę testerów. Każdy z testerów dostaje informację o dodaniu do bazy i dostaje powiadomienie wraz z pojawieniem się nowej wersji do testów. Po potwierdzeniu aplikacja instalowana jest poza obiegiem sklepu mobilnego. Na specjalnie przygotowanej stronie bądź aplikacji tester widzi wszystkie aplikacje, które ma do testowania, oraz historię wersji.

Istnieją też specjalne systemy do wychwytywania niepożądanych zachowań aplikacji, jak zamrożenia i nieoczekiwane wyłączenia. Aby korzystać z takich narzędzi, należy dodać do kodu fragment dostarczany przez twórcę narzędzia (dzięki SDK — Software Development Kit). Jego zadaniem jest monitorowanie i odnotowywanie każdego przypadku nieoczekiwanego wyłączenia aplikacji oraz zapisywanie fragmentu kodu, podczas egzekucji którego nastąpił problem.

Choć to narzędzia czysto programistyczne, to jednak właścicielowi biznesowemu pozwalają na badanie intensywności błędów, a więc określanie, czy ich liczba mieści się w dopuszczalnym poziomie krytycznych błędów na użytkownika. Najpopularniejszym narzędziem do analizy błędów jest Crashlytics (kupiony przez Twittera).

Coraz częściej systemy do raportowania błędów i dystrybucji wersji testowych zaczynają się przenikać funkcjonalnie oferują podobne usługi.

Wersja 1.0

Jeśli aplikacja przeszła pomyślnie przez etap testów i wdrożenia, to następuje jej publikacja. Od teraz będzie dostępna dla każdego zainteresowanego w sklepie mobilnym.

I choć testuje się aplikacje dokładnie podczas tworzenia wersji beta, to dopiero wersja publiczna pozwala na zebranie prawdziwego feedbacku z rynku, gdyż dopiero w tym momencie aplikacja może uzyskać skalę, która może uwidocznić wcześniej niedostrzegane problemy. Jest to szczególnie ważne przy aplikacjach wykorzystujących efekt sieciowy.

Byłem zaangażowany w tworzenie mobilnej aplikacji randkowej losującej dwie osoby, które mogły ze sobą porozmawiać. Niestety, betatesty były bardzo ograniczone, bo nie udało nam się z kilkunastoma testerami uzyskać skali, która byłaby w stanie symulować prawdziwie tętniącą życiem aplikację. To było możliwe dopiero przy znacznie większej liczbie użytkowników.

Bardzo ważne jest, aby na tym etapie gromadzić i analizować zachowania użytkowników — zarówno te widoczne i publiczne (oceny i komentarze w sklepie) jak i „podskórne” (statystyki, konwersja). Na tej podstawie będzie można zebrać dane potrzebne do wyciągnięcia wniosków przy produkcji następnej wersji.

Należy pamiętać, że nawet długi i dokładny proces tworzenia aplikacji nie gwarantuje, że idea i hipoteza, którą mieliśmy na początku, faktycznie sprawdzi się rynkowo. Oczywiście są mechanizmy, które mogą w tym pomóc (o tym w dziale o marketingu mobilnym), ale nawet najlepsze działania reklamowe nie obronią produktu, który nie przynosi wartości użytkownikowi.

Każdy z systemów mobilnych dysponuje funkcją automatycznej aktualizacji aplikacji. Oznacza to, że użytkownik nie musi już samodzielnie wchodzić do sklepu i potwierdzać potrzeby aktualizacji każdej ze swoich aplikacji niezależnie — teraz dzieje się w tle.

Ma to swoje plusy i minusy. Zdecydowanym plusem jest to, że znacznie zwiększa się udział użytkowników, którzy mają najbardziej aktualną wersję aplikacji. Ma to ogromne znaczenie z perspektywy biznesowej, bo ogranicza koszty obsługi historycznych wersji aplikacji i pozwala na o wiele sprawniejsze wprowadzanie nowych funkcji i naprawę błędów.

Z drugiej strony zespół produktowy traci jedną z pośrednich metod komunikacji ze swoimi użytkownikami. Dotychczas każda aktualizacja była okazją do przedstawienia zmian, poprawek błędów i informowania o nowych funkcjach. Przez wprowadzenie automatycznych aktualizacji użytkownicy przestają zauważać, że jakiekolwiek zmiany i poprawki miały miejsce.

W 2012 roku Facebook wprowadził, wtedy uznawaną za niezwykle progresywną, metodę aktualizacji aplikacji w 4–8 tygodniowych cyklach. W 2014 roku jednak, po wprowadzeniu automatycznych aktualizacji w iOS, zdecydowano, że ten cykl można przyśpieszyć, więc teraz nowa wersja Facebooka ukazuje się co dwa tygodnie.

Wokół gotowej aplikacji pojawia się coraz więcej „rozwiązań orbitujących”. Nazywam w ten sposób dodatkowe elementy skupione wokół aplikacji, które korzystają z jej mocy, budując ekosystem i poprawiając użyteczność. Wyróżniam obecnie trzy najważniejsze orbitujące rozwiązania: widgety, deep linking oraz — najważniejsze — notyfikacje.

Widgety to mikroprogramy z minimalną możliwością interakcji pozwalające na wykonanie podstawowych funkcji aplikacji, ale bez konieczności ich włączania. W przypadku iOS widgety są widoczne w Centrum Notyfikacji, Android i Windows Phone pozwalają na umieszczanie ich na ekranie głównym telefonu, pomiędzy ikonami aplikacji. Widgety sprawdzają się doskonale przy mikrooperacjach — takich jak sprawdzenie terminu najbliższego spotkania, stanu giełdy bądź pogody na nadchodzący dzień. Tego typu zadania nie wymagają włączania aplikacji kalendarza, aplikacji z kursami giełdowymi czy pełnej prognozy pogody. Celem widgetów jest udostępnienie prostej informacji, która spełni jedno konkretne zadanie. Jeśli okaże się, że to nie jest wystarczające, użytkownik może szybko z poziomu widgetu uruchomić faktyczną aplikację.

Innym wartym uwagi rozwiązaniem jest deep linking. To metoda na linkowanie ze sobą konkretnych części wewnątrz różnych elementów. Jest to znane podejście w świecie rozwiązań internetowych (na przykład linkowanie do konkretnego śródtytułu wewnątrz artykułu), ale w przypadku aplikacji mobilnych zupełnie nowe ze względu na brak jasnego i uniwersalnego standardu pomiędzy platformami. Dzięki deep linkingowi można zbudować rozwiązanie, w którym nawet jeśli użytkownik przenosi się między różnymi aplikacjami bądź stronami, to nie traci kontekstu, a aplikacja wie, jaki miał zamiar, więc uruchamia się na odpowiednim ekranie. To znacznie poprawia użyteczność aplikacji i ułatwia komunikację między stronami i aplikacjami. Na przykład, gdy kupuję ebook na stronie mobilnej, po naciśnięciu przycisku jestem przenoszony bezpośrednio do czytnika ebooków na moim telefonie. Innym ważnym aspektem deep linkingu jest przenoszenie informacji między różnymi aplikacjami i stronami. Na przykład, wyszukując trasę lotu samolotem, jestem proszony o ściągnięcie aplikacji linii lotniczej. Po ściągnięciu aplikacja wie, jakie było moje ostatnie wyszukiwanie, więc preuzupełnia je automatycznie po włączeniu. Dzięki temu nie muszę powtarzać tej operacji, więc szybciej mogę dokonać zakupu. Swoje standardy deep linkingu w świecie mobilnym mają i promują niezależnie Google (App Indexing[6]), Facebook (App Links[7]) oraz Twitter (App Cards[8]).

Notyfikacje są prawdopodobnie najważniejszym elementem budowania ekosystemu aplikacji. To krótkie wiadomości informujące o zmianie statusu wewnątrz aplikacji. Można założyć, że istnieją trzy typy notyfikacji:

1. Notyfikacje użytkownika — tworzone przez właścicieli urządzeń mobilnych dla innych właścicieli urządzeń mobilnych. Najlepszym przykładem są notyfikacje z serwisów społecznościowych przy komentarzu czy like’u lub nowej wiadomości w komunikatorze.

2. Notyfikacje kontekstowe — generowane przez aplikację za zgodą użytkownika. Są wywoływane przy spełnieniu odpowiednich warunków. Na przykład: alarm ustawiony o konkretnej godzinie, przypomnienie o wydarzeniu w kalendarzu, pojawienie się w odpowiedniej lokalizacji, aktualizacja tematu, który śledzimy.

3. Notyfikacje systemowe — tworzone przez aplikację, aby zwiększać zaangażowanie użytkownika, na przykład powiadomienia o znajomych, którzy także zaczęli korzystać z tej samej usługi, lub o tym, że w ulubionej grze dostępny jest nowy poziom. Takie notyfikacje jednak najczęściej stają się nową metodą na spamowanie użytkowników[9]. Niemniej notyfikacje systemowe niosą ze sobą największą wartość reklamową, stanowią też jedną z podstaw biznesu mobilnych gier freemium. Należy jednak pamiętać, że Apple wręcz zabrania wysyłania notyfikacji push, które są „reklamą, promocją lub jakąkolwiek formą marketingu bezpośredniego[10].

Więcej o wartości notyfikacji — w kolejnym rozdziale zatytułowanym Marketing aplikacji mobilnych.


[1]HIG — Human Interface Guidelines, https://developer.apple.com/design/human-interface-guidelines/

[2] Android Design, https://developer.android.com/design/

[3]MDP — Microsoft Design Principles, https://developer.microsoft.com/en-us/windows/campaigns/windows-dev-essentials-design-principles

[4] The Illusion of Life: Disney Animation, Ollie Johnston, Frank Thomas, http://www.amazon.com/The-ILLUSION-OF-LIFE-ANIMATION/dp/0786860707

[5] Wszystkie 12 podstawowych zasad animacji, http://en.wikipedia.org/wiki/12_basic_principles_of_animation

[6] App Indexing for Google Search, https://developers.google.com/app-indexing

[7]Cross-platform, open source, and simple mobile deep-linking, http://applinks.org

[8] App Card, https://dev.twitter.com/cards/types/app

[9]Apple Push Notification Guidelines, https://developer.apple.com/app-store/review/guidelines/#push-notifications

[10]Apple Push Notification Guidelines, https://developer.apple.com/app-store/review/guidelines/#push-notifications

Analityka i zachowanie użytkownika

Nie da się poprawić tego, czego nie da się policzyć. W związku z tym w aplikacjach mobilnych, tak samo jak na stronach internetowych, stosuje się analitykę i śledzi ruchy użytkownika. Dzięki temu można zmierzyć, jaką skuteczność ma kanał mobilny.

Podstawowym zadaniem analityki jest udostępnianie danych statystycznych o zachowaniu użytkowników. Skąd jednak wiedzieć, które dane są istotne biznesowo? W dużej mierze to zależy od strategii i modelu biznesowego, ale większość wymiarów jest wspólna, czyli:

- średnia długość sesji — czas, w jakim średnio aplikacja jest włączona i aktywna na telefonie,

- powracalność do aplikacji — ile czasu musi minąć, zanim aplikacja znów zostanie włączona,

- liczba nowych użytkowników — instalacje aplikacji na nowych urządzeniach,

- liczba aktywnych użytkowników — liczba włączeń aplikacji po instalacji w czasie (w zależności od systemu analityki znaczenie pojęcia „aktywności” może być różne),

- konwersja — wykonanie przez użytkownika akcji, która skutkuje zakupem (lub innym biznesowo istotnym zdarzeniem).

Na tej podstawie można budować tak zwane lejki konwersji, czyli wizualizacje procesów przepływania użytkowników pomiędzy poszczególnymi ekranami aplikacji — od włączenia aplikacji do zakończenia akcji, która spełnia wymagania biznesowe właściciela (zazwyczaj jest to sprzedaż przez aplikację).

Przepływ użytkownika w aplikacji

Każdy użytkownik będzie miał swoje przyzwyczajenia i sposoby korzystania z aplikacji, ale należy spodziewać się, że będą one spójne z tym, jak został zaprojektowany schemat przepływu użytkowników we wcześniejszych fazach. Każdą z takich ścieżek użytkownika można wyodrębnić w celu dokonania oddzielnej analizy.

Lejek konwersji — pojedyncza ścieżka

Analityka aplikacji pozwala na zdobycie informacji o tym, jak zmienia się procentowy udział użytkowników, którzy zbliżają się do ostatniego ekranu ścieżki.

Lejek konwersji — analiza

Dzięki takiemu podejściu można zbadać, gdzie w aplikacji pojawiają się „wąskie gardła”. Będą one widoczne w sytuacji, gdy któryś z następnych kroków lejka będzie miał nieproporcjonalnie niską konwersję. Może ona wynikać z problemów technicznych aplikacji (ekran nie może być wyświetlony lub ładuje się zbyt długo) bądź złego interfejsu i niejasnej komunikacji (użytkownik nie wie, co musi zrobić, aby przejść dalej)

Zdarzyło mi się widzieć sytuację, w której klient chciał przetestować rynek mobilny i wypuścił bardzo prostą aplikację, aby sprawdzić, czy będzie popularna wśród użytkowników, i zdecydować, czy warto inwestować większy budżet w ten kanał. Mimo że produkt został dostarczony i spotkał się z pozytywnym przyjęciem, to jednak cel strategiczny nie został osiągnięty, bo zapomniano o podłączeniu narzędzi analitycznych. Nie istniała więc realna metoda, aby zdekomponować popularność i wyciągnąć wnioski na przyszłość.

Jeśli aplikacja ma sprzedawać produkty bądź usługi, to lejek konwersji da informację, w jaki sposób aranżować ścieżki użytkownika tak, aby wymagało to najmniej kroków, a do zakupu dochodziło najszybciej. Jeśli aplikacja zarabia na wyświetlaniu reklam, to celem jest wydłużenie średniego czasu spędzonego w aplikacji.

Podczas tworzenia userflow (diagramu przepływu użytkowników) zespół stawia hipotezę, jak zaprojektować optymalną ścieżkę poruszania się po aplikacji. Dopiero jednak po zebraniu danych z analityki i wyciągnięciu wniosków z analizy lejków konwersji można zwalidować faktyczne efekty.

Przy zaawansowanych produktach mobilnych na tym etapie dochodzi jeszcze wykorzystanie testów A/B wewnątrz aplikacji. Ten proces polega na dynamicznym sprawdzaniu skuteczności konkretnych układów ekranu w celu znalezienia takiego, który generuje największą konwersję. W zależności od zaawansowania testy A/B mogą dotyczyć takich elementów, jak kolory przycisków czy kolejność elementów wewnątrz aplikacji.

Testy A/B

Są to jednak rozwiązania, które zaczynają mieć sens w przypadku dużych wolumenów ruchu mobilnego — ze względu na konieczność posiadania dużej próbki testowej oraz dużą inwestycję czasu i energii.

Zalecana dalsza lektura:

- Mobile First, Luke Wroblewski

  • The Illusion of Life: Disney Animation, Ollie Johnston, Frank Thomas

Rozdział 7 Marketing aplikacji mobilnych

W 2013 roku statystyczny użytkownik smartfona na świecie zainstalował 26 aplikacji, w tym sześć płatnych[1]- większość nich to gry, rozrywka i komunikacja[2]. Szansa na to, że w tej grupie znajdzie się akurat stworzona przez nas aplikacja, jest niewielka, jeśli nie zaoferujemy dzięki niej czegoś lepszego niż to, co już istnieje na rynku. Niemniej nawet stworzenie fantastycznej aplikacji mobilnej niewiele da, jeśli nikt się o niej nie dowie.

Marketing i mobile

Marketing to aktywność polegająca na promowaniu i sprzedaży produktów i usług z wykorzystaniem badań rynku i reklamy.

Jest to niezwykle szeroka definicja. Ze względu na obszerność tematu zaczęły powstawać specjalistyczne rodzaje marketingu skupiające się na konkretnych kanałach — takie jak ambient marketing, marketing cyfrowy czy nawet marketing zapachowy. Istnieje też podział dziedzinowy, w którym pojawia się marketing sportowy, polityczny czy marketing miejsc. Dla potrzeb tej książki skupię się na opisaniu wycinka marketingu, który skupia się na rynku mobilnym i wykorzystuje narzędzia, które tylko mobile może dać.

Przecięcie marketingu i mobile’a manifestuje się w dwóch miejscach: marketingu mobilnym i marketingu aplikacji mobilnych.

Marketing mobilny to ogół działań promocyjnych i sprzedażowych wykonywanych za pomocą urządzeń mobilnych. W tym przypadku nie ma znaczenia, co jest podmiotem marketingu, a smartfon i tablet są medium, czyli nośnikiem przekazu.

Marketing aplikacji mobilnych to ogół działań, które mają za zadanie promocję i sprzedaż konkretnego produktu — aplikacji mobilnej. Podmiot jest jasno określony, natomiast liczba i rodzaj nośników przekazu jest zmienna w zależności od sytuacji.

Pierwszy to sposób na monetyzację, drugi to sposób na zdobywanie użytkowników. Choć większa część tego rozdziału dotyczy obydwu sfer, to jednak należy jasno postawić granicę między definicjami i nie powinno się używać tych pojęć zamiennie.

Kanały zdobywania użytkowników

Kanały zdobywania użytkowników można rozważać na dwóch płaszczyznach: własności i kontekstu. Pierwszy podział ma zmapować zależności między kanałami, które się posiada, tymi, które się zdobywa, i tymi, które trzeba kupić. Na tej podstawie lepiej można zrozumieć, które z nich mają optymalną cenę pozyskania użytkownika, ale także jego charakterystykę.

Drugi podział to techniczne rozdzielenie na media i unikatowe możliwości, jakie dają w połączeniu z mobile’em.

Podział ze względu na własność

Wszystkie kanały komunikacji z klientem (bądź potencjalnym klientem) można podzielić na trzy rodzaje mediów: posiadane (owned), zdobyte (earned) i zakupione (paid).

Media posiadane

To kanały komunikacji, które są pod kontrolą firmy: strona WWW, blog, kanał na YouTube, konto na Facebooku. Każde z tych miejsc może prowadzić do aplikacji mobilnej. Posiadane media mają tę przewagę, że firma wykorzystuje je według własnego uznania — jedyne, co ją ogranicza, to ewentualne regulaminy platform społecznościowych.

W przypadku mobilnych stron WWW warto rozważyć wykorzystanie promowanego przez Apple rozwiązania Smart App Banners lub analogii na inne platformy. Smart App Banner to narzędzie, które (w przypadku iOS i przeglądarki Mobile Safari) pobiera informacje o tym, czy użytkownik przeglądający stronę mobilną marki X ma już aplikację marki X. Jeśli tak, to pokaże banner pozwalający na włączenie aplikacji z poziomu przeglądarki. Jeśli nie, to da możliwość włączenia App Store i szybkiej instalacji tejże aplikacji. Dzięki temu rozwiązaniu użytkownicy stron mobilnych dowiadują się, że mogą także skorzystać z aplikacji mobilnej odpowiadającej danej stronie.

Smart App Banner na stronie Allegro.pl

Innym posiadanym medium są wcześniej stworzone aplikacje, które mogą być wykorzystywane jako platforma do promocji nowych produktów mobilnych.

Taką synergię dobrze widać w przypadku aplikacji Facebook i Facebook Messenger. Naciśnięcie dymka rozmów w aplikacji mobilnej Facebook powoduje automatyczne włączenie Messengera. W drugą stronę: jeśli w aplikacji Messenger chcę dowiedzieć się szczegółów o moim rozmówcy, to włącza mi się jego profil w oryginalnej aplikacji Facebooka[3].

W przypadku posiadania więcej niż jednej aplikacji na danej platformie warto traktować je jako ekosystem, który składa się ze współzależnych produktów kładących nacisk na różne, ale zbieżne potrzeby użytkowników.

Media zdobyte

Media zdobyte są poza kontrolą właściciela aplikacji, ale dzięki odpowiednim zabiegom może on zwiększyć szansę na ich zdobycie. Mediami zdobytymi jest na przykład prasa pisząca o nowej aplikacji mobilnej, opinie użytkowników w social media czy mechanizm zapraszania do skorzystania z aplikacji przez znajomych.

W dobie social media każdy użytkownik jest jednocześnie kanałem komunikacji. Dlatego możliwość dzielenia się opinią o aplikacji w sieci znajomych może okazać się łatwym sposobem na informowanie o niej i zwiększanie jej ściągalności.

Czasami taki proces można wspomagać odpowiednimi zachętami — finansowymi i pozafinansowymi. Wtedy następuje połączenie ze sobą mediów zdobytych i kupionych oraz mówi się o sponsorowaniu konsumentów. Przykładem może być oferowanie im kuponów rabatowych do wykorzystania wewnątrz aplikacji. Taki ruch wykonało Allegro — każdy nowy użytkownik aplikacji mobilnej Allegro może w środku odebrać kupon rabatowy na 10 zł na zakupy w ramach tego serwisu. Innym przykładem jest kupon rabatowy o wartości 25 zł w aplikacji PizzaPortal.pl.

Gratyfikacja nie musi być finansowa — w grach mobilnych można otrzymać dodatkowe punkty (lub wirtualną walutę) w zamian za zaproszenie do gry swoich znajomych. W ten sposób buduje się wiralność aplikacji.

Ważne jest, aby maksymalnie uprościć nowym potencjalnym użytkownikom rejestrację w usłudze. Nawet zmotywowany przez nagrody i opinię zaufanych znajomych użytkownik zrezygnuje z podania swoich danych, jeśli proces będzie wymagał od niego zbyt dużo informacji[4].

Media kupione

Ostatnią grupę stanowią media kupione. W przypadku mobile’a mediami kupionymi są wszelkie formy reklamy mobilnej, która po tapnięciu prowadzi użytkownika do strony mobilnej bądź bezpośrednio do sklepu z aplikacją mobilną.

Proces zdobywania użytkownika w kanale mediów kupionych można przedstawić w postaci lejka. Każdy następny element lejka filtruje uczestników rynku ze względu na poziom zaangażowania i bliskość decyzji o zostaniu użytkownikiem aplikacji. Im bliżej konwersji, tym większa wartość, a więc także większy koszt pozyskania.

Typy akcji i rozliczeń reklamowych

CPM to ciągle podstawowy, ale najmniej skoncentrowany na dostarczaniu efektów model rozliczeń reklamowych. CPM (Cost Per Mille) tłumaczy się jako koszt tysiąca wyświetleń reklamy (w tym wypadku mobilnej). Czyli jeśli CPM=30 zł, to oznacza, że budżet 30 złotych wystarczy na pokazanie reklamy tysiąc razy. Pokazanie reklamy nie daje jednak gwarancji, że ktoś w nią kliknie, co więcej — nie daje nawet pewności, że ktoś ją zauważy.

Kontekst, w jakim prezentowana jest reklama mobilna, a szczególnie fakt, że interakcja z nią wymaga dotykania ekranu, a nie klikania kursorem, powoduje, że należy podchodzić krytycznie do oceny jej skuteczności w stosunku do tradycyjnych form. Mniejszy ekran, fakt, że reklama zasłania jego część, i interakcja przez dotyk — to wszystko zwiększa ryzyko przypadkowego tapnięcia na reklamę zamiast na fragment interfejsu aplikacji czy strony. Tak powstał efekt fat finger, czyli nieintecjonalnej interakcji z reklamą zliczanej na poczet zwiększonej skuteczności reklamy mobilnej. Ostatecznie w Google Mobile Display Ads musiał pojawić się system podwójnego tapnięcia, aby zapobiec nieetycznym praktykom u developerów, którzy przebierali reklamy za część interfejsu.

Z tego powodu coraz popularniejsze staje się CPC — czyli Cost Per Click. W tym modelu nie jest ważne, ile razy reklama została wyświetlona, ale ile razy ktoś faktycznie na nią kliknął lub tapnął. Jest to model rozliczeń typu performance, gdzie kupujący reklamę płaci za faktyczne efekty — tak samo jak każdy następny opisany typ.

Między momentem, gdy nasz potencjalny użytkownik tapnie w reklamę, a momentem, gdy ściągnie aplikację może się jeszcze dużo wydarzyć, co odciąga użytkownika od pożądanej akcji. Dlatego eksperymentuje się coraz mocniej z modelem CPD — Cost Per Download. Przy takim podejściu nie jest ważne, ile osób zobaczyło reklamę, ani nawet, ile w nią tąpnęło, a właśnie to, ile nastąpiło ściągnięć.

Ostatecznie najważniejsze i najbardziej wiarygodne dane daje model rozliczeń CPA — Cost Per Acquisition (czasami nazywany Cost Per Action). W tym wypadku mierzony jest całkowity koszt osiągnięcia konwersji na zarejestrowanego użytkownika.

Podział ze względu na kontekst

Stawianie billboardów w centrum miasta to tylko jedna z wielu wariacji procesu zdobywania użytkownika. Zazwyczaj różnią się one od siebie sposobem przyciągania zainteresowanego do sklepu mobilnego, który jest kluczowym sposobem dystrybucji aplikacji mobilnych.

Główne strumienie dotarcia do sklepu mobilnego

Sklep mobilny

Pierwsza grupa strumieni jest powiązana bezpośrednio ze sklepem mobilnym, w którym jest umieszczona aplikacja. Jeśli użytkownik sam z własnej woli otwiera stronę sklepu, to dzieje się jedna z trzech rzeczy: ściąga aplikację z rankingu najpopularniejszych, wyszukuje na podstawie nazwy bądź swobodnie przegląda to, co podrzuca mu sklep. Pierwszy mechanizm powoduje, że znalezienie się na liście najpopularniejszych aplikacji staje się celem samym w sobie. Obecność w TOP powoduje większą ekspozycję wśród użytkowników, a więc dalej umacnia popularność pozycji.

Funkcja wyszukiwania aplikacji wygenerowała całą nową kategorię narzędzi i taktyk, które nazywa się ASO — App Store Optimization. ASO to odpowiednik SEO w świecie WWW i tak samo jak SEO ma za zadanie doprowadzić do jak najczęstszego występowania danej aplikacji podczas wyszukiwania odpowiednich fraz. ASO opiera się na przemyślanym tworzeniu nazwy aplikacji, słów kluczowych i innych fragmentów opisu aplikacji.

Twórcy sklepów mobilnych starają się wzmacniać wśród swoich użytkowników spontaniczne trafianie na nowe i warte uwagi aplikacje przez publikowanie zestawień tematycznych (jak „Aplikacje dla transportu” czy „Made in Poland”) i powiązań między nimi (typu „Najpopularniejsze w tym gatunku” lub „Klienci kupili także”). Takie działania mają na celu zmniejszenie hegemonii aplikacji, które okupują wysokie pozycje w rankingu popularności.

Mobile web

Wyszukiwanie aplikacji nie odbywa się tylko w sklepie mobilnym, ale także podczas standardowego korzystania z internetu w telefonie. Wyszukiwanie nazwy aplikacji w mobilnym Google’u może kierować do sklepu mobilnego, strony twórcy aplikacji bądź innej, na której ta nazwa jest wymieniona w dowolnym kontekście. Warto więc przekierować ten ruch na podstronę sklepu mobilnego z naszą aplikacją.

Jeśli użytkownik wchodzi na stronę WWW, nad którą mamy pełną kontrolę, to warto skorzystać z bannera, który przypomina mu o istnieniu aplikacji (Apple udostępnia swoje natywne rozwiązanie o nazwie Smart App Banner). Podobne rozwiązanie można także wdrożyć samodzielnie na platformę Android i Windows Phone. Sposób działania tego mechanizmu można prześledzić, otwierając na swoim telefonie w przeglądarce mobilną wersję YouTube.com bądź Pinterest.com i obserwując nagłówek.

Inne podejście to wywoływanie już zainstalowanej aplikacji przez stronę WWW. Na stronie Amazon Kindle po kupieniu nowego ebooka użytkownik widzi przycisk powrotu do aplikacji Kindle. Jego tapnięcie powoduje włącznie tejże aplikacji, jeśli wcześniej była zainstalowana na urządzeniu klienta.

Social Media

Social media są najszybszym sposobem na rozpowszechnianie informacji nacechowanej subiektywizmem i emocjami. Wiadomościom i statusom publikowanym na Facebooku, Twitterze i innych portalach social media ufamy bardziej, gdyż to, co się tam znajduje, to treści pochodzące od naszych znajomych. Dzielenie się treściami dzięki smartfonom stało się jeszcze prostsze ze względu na łatwość obsługi, szybki dostęp do zdjęć i geolokalizację.

Aplikacje mobilne wykorzystują nasze obniżone standardy krytycznego spojrzenia ze względu na kontekst społeczny oraz przyzwyczajenie do dzielenia się informacjami wśród znajomych na kilka sposobów.

Przede wszystkim proszą o podzielenie się informacją o skorzystaniu z aplikacji w sieciach społecznościowych. W ten sposób znajomi zobaczą wpis o niej co ma na celu zainteresowanie i instalację. Gdy odpowiednio dużo osób w otoczeniu zacznie korzystać z tej aplikacji, tworzy się bierna presja społeczna („wszyscy już tam są”), która tym mocniej wymusza ściągnięcia.

Jeśli ten mechanizm nie okaże się wystarczająco skuteczny, to można posłużyć się reklamami w kanałach social media. Taka reklama widoczna na mobilnym Facebooku czy Twitterze niemal niczym nie różni się od klasycznego wpisu znajomego (to forma tzw. reklamy natywnej) poza tym, że po kliknięciu prowadzi bezpośrednio do sklepu mobilnego z reklamowaną aplikacją. Skuteczność tej reklamy jest wysoka ze względu na wspomniany już kontekst społeczny oraz łatwość niemal bezpośredniej instalacji.

Dzięki szybkości rozpowszechniania informacji w sieciach społecznościowych narodził się marketing wirusowy, dzięki któremu możliwy był wykładniczy przyrost liczby użytkowników, szczególnie w wypadku komunikatorów i gier.

W większości przypadków mechanizmy wirusowe działają tak, że aplikacja daje użytkownikowi bonus za ściągnięcie do niej kogoś, kto jeszcze z niej nie korzysta. W przypadku gier to dodatkowa wirtualna waluta, a w wypadku komunikatorów — ułatwienia w rozmowie (na przykład brak konieczności płacenia za SMS-y).

Reklama tradycyjna

Do kategorii strumienia reklamy tradycyjnej zaliczam wszystkie metody, które stosowano, zanim pojawiły się nowoczesne smartfony, a więc reklamę telewizyjną i reklamę outdoorową — zarówno w formie analogowej (billboardy, plakaty i ulotki), jak i cyfrowej (ekrany LCD i projektory).

Ich wykorzystanie do promowania aplikacji mobilnych jest działaniem wizerunkowym. Bezpośrednia konwersja na liczbę ściągnięć po rozpoczęciu tradycyjnej kampanii reklamowej jest trudna do określenia ze względu na brak możliwości odseparowania czynnika reklamy tradycyjnej od innych wydarzeń wpływających na liczbę ściągnięć aplikacji. Niemniej większość dostępnych danych pozwala sugerować, że bezpośrednia skuteczność reklamy tradycyjnej ma małe znaczenie przy liczbie ściągnięć aplikacji.

Moc reklamy tradycyjnej leży jednak gdzie indziej — ta forma reklamy buduje spontaniczną rozpoznawalność marki i zwiększa punkty styku potencjalnego użytkownika. Jeśli ten, jadąc do pracy, mija często billboard z logo aplikacji, to później, gdy zobaczy reklamę mobilną tej samej aplikacji, szansa na to, że ją ściągnie, będzie znacznie większa.

Jednak wcześniej wspomniany brak systematycznego obiektywnego sposobu mierzenia skuteczności reklamy tradycyjnej powoduje, że jeśli faktycznie ma ona wpływ na konwersję, to jest on wliczany do statystyk innych kanałów.

Reklama kontekstowa

Największym wyzwaniem reklamy w promowaniu aplikacji mobilnej jest konieczność połączenia dwóch kontekstów: fizycznego świata i świata istniejącego w telefonie. Celem jest danie przynajmniej szczątkowej świadomości kontekstu smartfonowi. Takie połączenie ma mu pozwolić na pokazywanie treści, które są zsynchronizowane z tym, co widzi, słyszy i czego doświadcza użytkownik w fizycznym świecie.

Jednym ze sposobów na takie połączenie są kody QR (Quick Response). To technologia zapisu danych w formie dwuwymiarowego kodu kresowego, która powstała na potrzeby japońskiego przemysłu jako szybki sposób na oznaczanie części samochodowych. Kody QR pozwalają na zapisywanie informacji w formie czarnobiałego kwadratu, który może zostać przyklejony bądź wydrukowany na fizycznym przedmiocie.

Sama technologia szybko wyszła poza logistykę części samochodowych i dotarła do branży reklamowej. Telefony z aparatami fotograficznymi mają odpowiednią moc obliżeniową, aby odtworzyć informacje zapisane w obrazie, co daje szansę na powiązanie fizycznej reklamy outdoorowej z urządzeniem konsumenta.

W reklamie kody QR drukuje się na fizycznych billboardach. Po zeskanowaniu specjalną aplikacją kod kieruje telefon użytkownika na stronę WWW odpowiadającą kampanii billboardowej. Mimo początkowych zachwytów nad tą technologią, nigdy nie przyjęła się ona masowo, gdyż wymaga zbyt dużo początkowego zaangażowania od użytkownika. Musi on bowiem wiedzieć, co oznacza ten monochromatyczny znacznik na reklamie oraz mieć zainstalowaną aplikację, która potrafi rozpoznać zakodowaną w nim treść.

Inne podejście to korzystanie z geolokalizacji. Operatorzy telekomunikacyjni oferują usługę wysyłania SMS-ów i MMS-ów reklamowych w zależności od tego, gdzie znajduje się użytkownik. Operator zna przybliżone położenie telefonu dzięki BTS-om (Base Transceiver Station), czyli stacjom nadawczo-odbiorczym sygnału komórkowego. W dużym skrócie działa to tak, że nawet bez włączonego GPS-a operator telekomunikacyjny wie w przybliżeniu, gdzie znajduje się włączony telefon, ponieważ, żeby działać, musi on zalogować się do jednej ze stacji. Każda stacja obejmuje określony obszar, więc zalogowanie się telefonu pozwala na przybliżone określenie jego lokalizacji. W związku z tym można sobie wyobrazić, że użytkownik smartfona dostanie wiadomość z linkiem do aplikacji mobilnej centrum handlowego, obok którego właśnie przejeżdża.

SMS/MMS marketing jest ograniczony technologicznie, gdyż nie pozwala na osiągnięcie zbyt dużej interakcji z użytkownikiem poza pokazaniem tekstu i linkiem do strony WWW (i dodaniem zdjęcia lub filmu w przypadku MMS-a). Bezsprzecznie jednak jego największą zaletą jest ogromny zasięg — każdy telefon komórkowy (a nie tylko smartfon) może otworzyć SMS-a i potencjalnie MMS-a.

Inną metodą nadawania kontekstu jest oferowanie darmowego dostępu do internetu przez komercyjne hotspoty Wi-Fi w miejscach publicznych. Urządzenie mobilne po podłączeniu do takiego źródła internetu jako pierwszą stronę WWW pokazuje panel logowania do usługi. W zamian za podanie swoich danych użytkownik dostaje możliwość korzystania z darmowego dostępu do sieci.

Obecnie rozwojową technologią jest iBeacons wykorzystujący Bluetooth Low Energy. Dzięki tym urządzeniom nadawczo-odbiorczonym umieszczonym w pomieszczaniach możliwe jest geolokalizowanie telefonu użytkownika (a więc także jego) z dokładnością do kilkunastu centymetrów. To otwiera przed reklamodawcami nowe możliwości analizy zachowania konsumentów i bardzo dokładnego rozeznania kontekstu. Jednym z pierwszych przykładów zastosowania iBeacons jest automatyczne wyświetlanie informacji w aplikacji o produkcie, do którego właśnie zbliżył się użytkownik.


[1]The Average Smartphone User Has Installed 26 Apps, http://www.statista.com/chart/1435/top-10-countries-by-app-usage

[2]Most popular Apple App Store categories in January 2015, by share of available apps, http://www.statista.com/statistics/270291/popular-categories-in-the-app-store

[3]Takie działanie jest przykładem na dobrze przemyślany deep linking, który opisywałem w poprzednim rozdziale pod tytułem Produkt mobilny.

[4]Więcej na ten temat w poprzednim rozdziale pod tytułem Produkt mobilny (podrozdział Onboarding).

Inne aplikacje

Wraz ze zwiększającą się popularnością aplikacji mobilnych rośnie także liczba funkcji, które oferują. Użytkownicy mobilni przyzwyczaili się jednak, że jedna aplikacja służy do jednej czynności, dlatego jednym z zauważalnych trendów w 2013 roku było zwiększanie portfolio aplikacji poprzez rozdzielanie ich funkcji. W ten sposób aplikacja Facebooka została pozbawiona opcji chata, którą przejęła niezależna aplikacja Facebook Messenger, a Google Drive pozbawiona opcji edytowania dokumentów — to jest możliwe w niezależnych aplikacjach Google Docs i Google Sheets.

Tak porozdzielane aplikacje są jednak wewnętrznie od siebie zależne i odwołują się do siebie. W aplikacji Facebooka cały czas jest widoczna ikona chatu, ale po jej kliknięciu włączana jest druga, niezależna aplikacja Facebook Messenger. Jeśli jej nie mamy, to pojawia się prośbą o instalację wraz z przekierowaniem do sklepu mobilnego.

To skomplikowany system zależności, na który mogą pozwolić sobie podmioty o dużych zasięgach, ale pamiętajmy, że istnieje także prostszy, płatny sposób takiego łączenia aplikacji — przez reklamę mobilną w aplikacjach.

Jednym z modeli zarobkowych aplikacji jest wyświetlanie reklam mobilnych w darmowych aplikacjach. Taka reklama, oprócz linkowania do zewnętrznej strony WWW, może także prowadzić do sklepu mobilnego z naszą aplikacją. Biorąc pod uwagę, że użytkownik jest właśnie zaangażowany w interakcję ze swoim telefonem, to poproszenie go o ściągnięcie dodatkowej aplikacji wydaje się łatwiejsze niż w przypadku billboardu w przestrzeni miejskiej, kiedy to trzeba by wyjąć telefon z kieszeni.

Aplikacja mobilna może mieć system powiadamiania użytkownika o zdarzeniach z nią związanych. Takie krótkie wiadomości nazywa się notyfikacjami[1]. Biorąc pod uwagę fakt, że 68% konsumentów zezwala aplikacji na wysyłanie notyfikacji[2], zaczęto myśleć nad wykorzystaniem tego nowopowstałego kanału komunikacji do wysyłania treści reklamowych.

Propagacja kampanii reklamowej opartej na notyfikacjach jest o wiele tańsza w dłuższej perspektywie, gdyż operator komórkowy nie pobiera za nie swojej prowizji.

Z marketingiem notyfikacji związane jest ryzyko złamania zasad ustanowionych przez twórców systemów mobilnych. Notyfikacje powstały jako narzędzie do informowanie o wydarzeniu dotyczącym aplikacji, a nie jako sposób na propagowanie reklam. Ma to też swoje odzwierciedlenie w regulaminach, których muszą przestrzegać twórcy aplikacji mobilnych.

Konwersja

Jeśli prześledzimy, ile operacji musi wykonać właściciel smartfona, aby stać się użytkownikiem naszej aplikacji, okaże się, że to pracochłonne zadanie, podczas którego muszą być spełnione odpowiednie warunki.

Załóżmy, że tworzymy aplikację mobilną do zamawiania taksówek i reklamujemy ją za pomocą billboardów w centrum miasta, bo chcemy dotrzeć do osób, które codziennie podróżują do pracy i z powrotem.

Nasz billboard musi mieć dużą siłę przekonywania, aby spowodować, żeby przechodzień na niego spojrzał, wyciągnął swój telefon, otworzył aplikację z mobilną przeglądarką i wszedł na naszą stronę WWW. Zakładamy już w tym miejscu, że jego telefon ma dostęp do Internetu (a więc że ma jeszcze niewykorzystany pakiet danych lub jest podłączony do wi-fi).

Strona WWW musi być tak stworzona, aby wykryła system operacyjny telefonu naszego przyszłego klienta i przekierowała go jak najszybciej do sklepu mobilnego, gdzie będzie możliwe ściągnięcie aplikacji. Alternatywnie możemy poprosić użytkownika, aby wyszukał aplikację w sklepie, co jest dłuższą operacją, bo wymaga wpisywania nazwy aplikacji i odnalezienia jej w wynikach wyszukiwania.

Zanim jednak dojdzie do ściągnięcia, to użytkownik przeskanuje szybko podstronę aplikacji wewnątrz sklepu mobilnego, zwracając szczególną uwagę na średnią ocen aplikacji oraz screenshoty. Jeśli nic nie wzbudzi jego zastrzeżeń, to po kliknięciu na przycisk ściągania zostanie poproszony o autoryzację i potwierdzenie operacji. W tym miejscu więc zakładamy, że ma założone i aktywne konto w sklepie mobilnym (a w przypadku aplikacji płatnych także to, że podał swoje dane do obciążania opłatami).

Jeśli faktycznie tak jest i użytkownik potwierdzi chęć pobrania aplikacji, rozpocznie się proces jej ściągania na telefon. Teraz musi się okazać, czy użytkownik ma:

- dostęp do Internetu wystarczająco szybki, aby ściągnąć aplikację, zanim straci nią zainteresowanie,

- w telefonie wystarczająco dużo miejsca, aby ściągnąć i zainstalować aplikację.

Udana instalacja to jeszcze nie wszystko. Liczymy na to, że nasz przyszły użytkownik od razu po ściągnięciu i instalacji aplikacji ją otworzy.

Jeśli tak się stanie, to zobaczy ekran powitalny aplikacji, po którym nastąpi najtrudniejszy filtr: proces onboardingu [3]. Od tego, jak dużo będziemy wymagać operacji, zależy, ilu spośród pierwotnie zainteresowanych użytkowników pozostawi swoje dane, rejestrując się i logując w aplikacji.

W większości przypadków rejestracja polega na wpisaniu imienia i nazwiska oraz adresu e-mail. Na ten adres przychodzi link, który otwiera naszą stronę WWW, potwierdzając jednocześnie, że wpisany adres e-mail jest prawdziwy i należy do naszego użytkownika. Alternatywnie podaje się numer telefonu, na który przychodzi kilkucyfrowy kod — należy go wpisać w aplikacji, co potwierdza prawdziwość podanego numeru telefonu.

Oczywiście, na tym etapie zakładamy, że nasz użytkownik nie pomylił się w podawanym adresie e-mail bądź numerze telefonu.

Innym, znacznie szybszym rozwiązaniem jest logowanie za pomocą sieci społecznościowej, takiej jak Facebook, Twitter czy LinkedIn. Wtedy ta sieć zajmuje się uzupełnieniem podstawowych danych, jak imię, nazwisko czy adres e-mail, co znacznie przyspiesza proces. Trzeba jednak pamiętać, że nie wszyscy mają konta w tych serwisach, nie mówiąc już o tym, że nie wszyscy życzą sobie, by sieć społecznościowa „wiedziała”, że logują się do naszej aplikacji.

Warto zwrócić uwagę na to, jak długi jest cały ten proces w porównaniu z otwarciem mobilnej strony WWW. Ta różnica jest jednym z głównych powodów, dla których strony mobilne służą do budowania zasięgu, a aplikacje do wzmacniania lojalności.

Koszt pozyskania i wartość użytkownika

Do określania, jak skuteczny jest kanał pozyskiwania klientów, stosuje się współczynnik CAC — Customer Aquisition Cost. CAC mówi, ile trzeba zainwestować, aby zdobyć następnego użytkownika.

CAC to jest koszt, który w pewnym momencie trzeba zrównoważyć przychodami wygenerowanymi z płacących użytkowników. W większości przypadków da się ustalić średnią sumę, jaką klient zostawia w zamian za możliwość skorzystania z naszej usługi, marżę, jaką mamy ze sprzedanego mu towaru bądź zarobek z tego, że zareaguje na reklamę.

Korzystając z historycznych danych, można obliczyć, ile razy jeden statystyczny użytkownik skorzysta w całym swoim życiu z naszej usługi, powróci do naszego sklepu czy tapnie w reklamę. Mając te dane, możemy obliczyć całościową wartość użytkownika — CLV (Customer Lifetime Value).

CLV obliczane jest na podstawie historycznych danych oraz ogólnych doświadczeń rynkowych. Wartość CLV wzrasta, jeśli:

- wzrasta średnia wartość koszyka zakupowego,

- wzrasta powracalność do aplikacji,

- wzrasta konwersja za zakup,

- wzrasta liczba tapnięć na reklamę,

- wydłuża się średnia długość aktywności konta użytkownika (w przypadku usług abonamentowych),

- obniża się koszt obsługi klienta,

- obniżają się koszty infrastrukturalne.

Dodatkowo ogromne znaczenia dla CLV ma obniżanie tzw. churn rate- czyli liczby użytkowników, którzy rezygnują z usługi. Wysoki churn w przypadku płatności abonamentowych oznacza, że użytkownicy nie otrzymują tego, co zostało im obiecane, i nie mają ochoty dłużej płacić.

Mając w ten sposób obliczony średni koszt pozyskania użytkownika oraz jego wartość, wiemy, jak sterować produktem i wydatkami, aby produkt osiągał zyskowność. Ostatecznie bowiem wszystko sprowadza się do tego, aby fundusze wydawane na badanie rynku i reklamę doprowadziły do zdobycia klientów, którzy wygenerują przychody na tyle wysokie, aby zrównoważyć wszystkie koszty i generować zysk:

CLV>CAC

CAC, czyli średni koszt pozyskania użytkownika, definiuje w gruncie rzeczy budżet marketingowy i reklamowy. Jeśli CLV jest niższe od CAC, to oznacza, że właściciel biznesowy dopłaca do każdego nowego użytkownika. Jest to usprawiedliwione w przypadku nowych produktów i usług, gdzie faktyczne LTV nie jest w pełni znane, a wymagana jest inwestycja w promocję.

W przypadku produktów cyfrowych dodatkowo mówi się o współczynniku wirusowości k. Współczynnik ten określa, jak dużo z już pozyskanych użytkowników będzie „zarażało” i przyciągało następnych. Współczynnik k został zapożyczony z epidemiologii, gdzie służy do określania szybkości rozpowszechniania się wirusów.

Współczynnik k to iloczyn średniej liczby zaproszeń do aplikacji wysłanej przez użytkownika (tzw. „dystrybucja”) oraz średniego procentu skutecznie zrealizowanych zaproszeń (zaraźliwość).

k = i * c

gdzie:

i = średnia liczba zaproszeń do aplikacji wysyłana przez użytkowników (dystrybucja)

c = średni procent konwersji z zaproszenia (zaraźliwość)

Zatem jeśli średnio jeden użytkownik zaprasza sześciu swoich znajomych, a 30% z nich skorzysta z zaproszenia to k = 1,2. To oznacza, że aplikacja będzie rosła wykładniczo. Jeśli k jest równe 1, to rozwój będzie stabilny, a jeśli poniżej 1, to znaczy, że liczba użytkowników będzie maleć wykładniczo.

Każdy produkt cyfrowy, który ma osiągnąć sukces, szczególnie w niezwykle konkurencyjnym i hiperskomunikowanym świecie aplikacji mobilnych, powinien dążyć do osiągnięcia dwóch stanów:

1. CLV > CAC

2. k > 1

Pierwszy punkt oznacza, że średnia wartość całkowita użytkownika naszego systemu jest wyższa niż średni koszt jego pozyskania. Drugi punkt oznacza, że obecni użytkownicy skutecznie doprowadzają do skorzystania z aplikacji swoich znajomych, którzy także stają się użytkownikami.

Zalecana dalsza lektura:

- The Mobile Playbook, Google, http://www.themobileplaybook.com


[1]Więcej o sposobie działania notyfikacji w poprzednim rozdziale zatytułowanym Produkt mobilny.

[2] Give mobile marketing a ‘push’, http://www.responsys.com/blogs/nsm/mobile-marketing/give-mobile-marketing-push-infographic

[3] O tworzeniu dobrego onboardingu — więcej w rozdziale Produkt mobilny.

Zakończenie

Przez całą książkę opisywałem przypadki, które pomagały rozwijać się menedżerom i firmom. Jest jednak jeden aspekt, którego nie można pominąć, wartość, o której nie można zapomnieć.

Mobile to największy obecnie „enabler”, który w czasach cyfrowego wykluczenia niweluje różnice dostępu do usług, produktów i treści.

Sebastiana i Dorotę poznałem przez moją narzeczoną. Umówiliśmy się w centrum Warszawy — my i oni wraz ze swoimi psami. W planach mieliśmy wyjście do pubu na Starym Mieście.

Dorota uwielbia Foursquare’a, a Sebastian cały czas siedzi na Facebooku. Różnica między nami jest taka, że oni są niewidomi, a to, co dzieje się w sieci, wiedzą dzięki temu, że ich telefony mają świetne usprawnienia dla osób niewidzących.

Jeśli chcesz zrozumieć ten świat choć trochę, to wejdź do ustawień ogólnych i panelu Dostępność. Znajdziesz tam mnóstwo możliwości zwiększania użyteczności smartfona dla osób, które nie widzą, nie słyszą lub mają problemy z wykorzystywaniem ekranu dotykowego. Każda z tych opcji to dla mnie drzwi do zupełnie nowego świata — z regułami, które dopiero muszę poznać.

Jest to trudne doświadczenie, ale to nic w porównaniu z życiem w świecie przeznaczonym dla widzącej i słyszącej większości, gdy jednego z tych zmysłów nam brakuje.

Jedna z moich największych osobistych porażek zawodowych spotkała mnie tuż po premierze aplikacji Play24. Byłem wtedy odpowiedzialny za zaoranie starej wersji i wprowadzenie nowego, intuicyjnego i pięknego interfejsu. Osobiście miałem ambitny plan, aby ta aplikacja była najlepiej oceniana w swojej kategorii i stanowiła wzór do naśladowania dla wszystkich innych systemów samodzielnego zarządzania usługami.

Faktycznie tak się stało. Play24 szybko zdobył ogromną popularność i miał praktycznie same pozytywne oceny. Wtedy w Google Play pojawił się jednak komentarz, który mnie zmroził i sprowadził na ziemię.

Któryś z użytkowników poprosił o przywrócenie starej wersji, bo w obecnej przyciski nie są dobrze rozmieszczone i podpisane, przez co osoby niewidome nie mogą z niej korzystać.

W całym moim ślepym zapędzie do tworzenia jak najlepszej aplikacji zapomniałem o tym, po co ją robię i jaki ma cel. Nie zdawałem sobie sprawy, że przez moje skupianie się na wizualnych detalach odciąłem część użytkowników, dla których ta aplikacja jest nawet ważniejsza niż dla całej widzącej reszty. Co więcej! Ja nawet nie wiedziałem, że taka grupa istnieje…

To był dla mnie szok. Irytuje mnie zawsze, gdy widzę urzędy, sklepy czy przejścia podziemne, które nie mają podjazdów dla osób na wózkach, i zastanawiam się, jak nieczułym trzeba być, aby je tak zbudować… A teraz sam się zrobiłem podobnie.

Warto abyś miał także tę perspektywę. Chcę, żeby opisywane w tej książce rady wnosiły wartość na trzech poziomach: podnosiły kompetencje czytelnika, pozwalały firmom tworzyć lepsze produkty, ale także budowały świetne doświadczenia wśród użytkowników, nie wykluczając żadnej z grup społecznych.

Pamiętaj, że to, co tworzysz, nie jest wydmuszką. Robisz aplikację na urządzenie, które jest najbardziej personalną rzeczą, jaką ma twój użytkownik. Bardzo łatwo jest popełnić prosty błąd, który w efekcie może odciąć część użytkowników — przez zwykłą nieuwagę lub brak wiedzy.

I choć brzmi to górnolotnie, to uważam, że technologia zawarta w tych małych urządzeniach, odpowiednio skanalizowana, zmienia nas na lepsze i pozwala na więcej — jednocześnie demokratyzując dostęp do usług, produktów i treści.

A przecież to dopiero początek drogi.

Podziękowania

Traktuję tę książkę jak projekt technologiczny. Zanim wypuściłem wersję publiczną, przeszła przez testy, które pozwoliły dostosować treść do wyników ankiet i reakcji pierwszych czytelników. Testowałem wszystko: od wyglądu okładki, przez układ treści, a kończąc na wykorzystanym foncie.

Wierzę, że istnieje sensowny balans między licentia poetica autora, a jak najszybszą walidacją i wyciąganiem wniosków z reakcji czytelników. To także mój metaeksperyment, który ma sprawdzić, czy faktycznie da się do książki zastosować startupowe podejście. Nie byłby on możliwy, gdyby nie oddana sprawie grupa testerów, których pełna lista jest wymieniona na ostatnich stronach książki. Dziękuję!

Przede wszystkim dziękuję Paulinie, mojej narzeczonej, za cierpliwość i to, że wytrzymała ze mną, gdy każdą wolną chwilę spędzałem na pisaniu. (Dopisek z 2018 roku: Paulina jest już moją żoną. Co więcej! Mamy także 2.5 letniego synka.)

Postanowiłem, zgodnie z zasadami lean startup, jak najszybciej testować, to co napisałem. Do tego zadania udało mi się zebrać niesamowicie wartościową grupę entuzjastów, bez której wiele z tych stron nie wydostałoby się z mojej głowy. To dla Was:

Pierwsza grupa testerów:

Szymon Szymczyk, Zuzanna Stańska, Maciej Wiktorowski, Grzegorz Aksamit, Łukasz Anwajler, Joanna Skorupska, Mateusz Woźniak, Ania Wilma, Michał Kostecki, Michał Antosiewicz, Maciej Łuczak, Kamil Brzeziński, Paweł Sieczkiewicz, Radek Grabarek, Paweł Orzech, Tomek Szulkowski, Piotr Rytel, Łukasz Konior, Marcin Laskowski, Sylwester Madej, Tomek Rutkowski.

Druga grupa testerów:

Tomasz Wesołowski, Paweł Seroczyński, Maciej Mazur, Krzysztof Kobyłecki, Jacek Pistl, Krzysztof Pająk, Arvind Juneja, Piotr Synowiec, Jan Kołodyński, Tomasz Skórski, Tomasz Woźniak, Marcin Szeląg, Mariusz Głuch, Kuba Borkowski, Michał Janiszewski i Paweł Ruszlewski.

Dziękuję Senfino jako organizacji, w której mogłem testować moje idee. Tam nauczyłem się najwięcej.

Słownik pojęć

3G — telefonia komórkowa trzeciej generacji, która umożliwia wprowadzanie dodatkowych usług wykorzystujących trans- misję wideo i transmisję pakietową.

Agile — jedna z metod zarządzania. Charakteryzuje się naci- skiem na szybkie fazy produkcji, częste walidowanie efektów i adaptowanie planu.

Android — mobilny system operacyjny stworzony przez Google.

API — Application Program Interface — zestaw komend, które pozwalają jednej aplikacji na korzystanie z funkcji i zasobów innych aplikacji.

App Economy — szeroki zakres aktywności rynkowych zwią- zanych z aplikacjami mobilnymi.

App Store — sklep z aplikacjami mobilnymi dla systemu ioS stworzony przez Apple.

Artefakt — półprodukt wspomagający prace programistyczne.

ASO — App Store Optimization — grupa działań, której celem jest lepsze wypozycjonowanie aplikacji w wynikach wyszu- kiwania sklepów z aplikacjami mobilnymi.

Autoryzacja SMS — sposób na potwierdzenie tożsamości użytkownika przez wiadomość tekstową.

Backend — warstwa logiki i dostępu do treści; to, czego nie widzi użytkownik.

Backlog — lista funkcji do wykonania, aby oprogramowanie mogło być uznane za kompletne.

Brandbook — dokument opisujący zasady wykorzystywania znaku graficznego (i innych elementów identyfikacji) marki.

Brief — dokument opisujący oczekiwany efekt prac programi- stycznych.

Business owner — właściciel biznesowy. osoba, która inicjuje i finansuje projekt lub produkt, ale nie musi uczestniczyć w tworzeniu.

CAC — Customer Aquisition Cost — współczynnik opisujący średni koszt pozyskania użytkownika.

CI — Corporate Identity — ogólny wizerunek organizacji, zazwy- czaj zwizualizowany dzięki brandbookowi.

CPD — Cost Per Download — uśredniona kwota, jaką trzeba zapłacić, aby uzyskać jedno ściągnięcie aplikacji przez dzia- łania reklamowe.

CPM — Cost Per Mille — współczynnik opisujący koszt, jaki trzeba ponieść, aby wyświetlić 1000 reklam bannerowych.

CR — Change Request — prośba o zmianę w oprogramowaniu po tym, gdy strony zgodziły się na pierwotną wersję.

Deep linking — metoda na uruchamianie aplikacji mobilnej i wymuszenie w niej akcji przez zewnętrzne łącze.

Definition of done — definicja wykonania. Sposób na opisanie różnicy między zrealizowaną a niezrealizowaną funkcją systemu.

Delegation board — metoda na określanie poziomu samodziel- ności zespołu w podejmowaniu decyzji na różnych płasz- czyznach tworzenia produktu.

Design to cost — metoda realizacji projektu, w której zlece- niobiorca ma za zadanie optymalnie wykorzystać z góry określony budżet.

Dług technologiczny — konsekwencja akceptowania do użytku nieskończonego produktu technologicznego — zazwy- czaj przez presję biznesową. Im dłużej produkt jest w użyciu, tym większy dług, a więc tym trudniej jest wprowadzić zmiany na lepsze.

Empiryzm — doktryna głosząca, że źródłem poznania są bodźce zmysłowe.

Facebook login — sposób na autoryzację za pomocą sieci spo- łecznościowej Facebook.

Fixed price — sztywna cena. Sytuacja, gdy projekt ma z góry określony budżet, którego nie da się zmienić.

Fixed scope — sztywny zakres. Sytuacja, gdy projekt ma z góry określony zakres, którego nie da się zmienić.

Fixed time — sztywny czas. Sytuacja, gdy projekt ma z góry określony czas realizacji, którego nie da się przekroczyć.

Flat design — styl graficzny charakteryzujący się minimali- zmem.

Fold — pojęcie określające granicę widoczności treści na ekranie. To, co jest over the fold, jest widoczne od razu, a to, co jest under the fold, wymaga interakcji (zazwyczaj przesu- nięcia ekranu), aby było widoczne.

FOMO — Fear of Missing Out — zjawisko społeczne — strach przed byciem pominiętym.

Freemium — model biznesowy, najczęściej stosowany w grach mobilnych.

Frontend — warstwa prezentacyjna systemu; to, co widzi użyt- kownik.

Geolokalizacja — funkcja smartfonów, dzięki której telefon zna swoje położenie geograficzne.

Google Play — sklep z aplikacjami mobilnymi do systemu Android autorstwa Google.

GPS — Global Positioning System — system namierzania urzą- dzeń.

Graceful degradation — „wdzięczna degradacja”. Strategia zakładająca minimalizowanie funkcji wraz ze zmniejszaniem się wielkości ekranu urządzenia.

HCI — Human Computer Interaction — nauka o interakcji mię- dzy człowiekiem a technologią. W skład HCI wchodzi UX.

Hi-Fi — High Fidelity — wysoka wierność. Makiety, w których zawarte są wysokiej jakości i wierności grafiki odzwierciedla- jące docelowy wygląd aplikacji.

iBeacons — technologia pozwalająca na bardzo dokładną nawigację wewnątrz pomieszczeń.

In-App Purchase — mechanizm pozwalający na zakup dodat- kowych funkcji bądź treści wewnątrz aplikacji.

Interesariusz — osoba, która ma żywotny interes w ramach tworzenia produktu.

iOS — mobilny system operacyjny firmy Apple.

Kody QR — dwuwymiarowy wizualny kod, w którym mogą być zapisane informacje i komendy możliwe do odczytania przez smartfon.

Konwersja — zmiana statusu, na przykład z niepłacącego użyt- kownika na płacącego użytkownika

KPI — Key Performance Indicator — kluczowy wskaźnik efek- tywności.

Landing page — pierwsza strona WWW, jaką zobaczy nasz potencjalny użytkownik po wyszukaniu frazy w wyszuki- warce bądź tapnięciu na reklamę internetową.

Lo-Fi — Low Fidelity — niska wierność. Pojęcie wykorzysty- wane przy tworzeniu pierwszych makiet produktu. Zazwy- czaj są monochromatyczne i bez zachowania proporcji. Ich celem jest przekazanie idei stojącej za produktem.

LTE — Long Term Evolution — standard szybkiej bezprzewo- dowej komunikacji.

LTVC, LVC — Lifetime Value of Customer — średnia zsumowana wartość użytkownika w całym czasie jego korzystania z pro- duktu.

Material Design — język komunikacji wizualnej stosowany w systemie Android od wersji 5.0 (lollipop).

Metcalfe’a, prawo — opisuje tzw. efekt sieciowy. Użyteczność systemu / sieci rośnie proporcjonalnie do kwadratu liczby urządzeń / użytkowników do niej podłączonych.

Notyfikacja — krótka wiadomość generowana przez system mobilny informująca do zdarzeniu.

Onboarding — proces rejestrowania się użytkownika w apli- kacji. Pierwsze, co widzi nowy użytkownik po włączeniu aplikacji.

One-click — rodzaj płatności mobilnych.

Pay-by-link — metoda płatności w bankowości internetowej, która eliminuje potrzebę uzupełniania większości danych do przelewu.

Phablet — smartfon na tyle duży, że blisko mu do tabletu.

Product owner — osoba, która zarządza rozwojem produktu, bo ma potrzebną wizję, wiedzę i władzę.

Progressive enhancement — „progresywne ulepszanie” — stra- tegia zakładająca dokładanie liczby funkcji wraz ze zwięk- szaniem się wielkości ekranu urządzenia.

Prototyp — wczesna i prosta wersja produktu, której celem jest zwalidowanie pierwotnych założeń.

Punkt odniesienia — zarys, szkic, opis idei, który jest bazą dla osób tworzących nową aplikację.

Push — skrót od Push Notification, krótkiej wiadomości wy- syłanej do użytkownika systemu.

RWD — Responsive Web Design — podejście do tworzenia stron internetowych tak, aby umożliwiały optymalnie doświad- czenie dla użytkownika przez dostosowywanie swojego wy- glądu do urządzenia, na którym są wyświetlane.

Scrum — jedna z metodyk zwinnych (Agile).

SDK — Software Development Kit — zestaw narzędzi, które pozwalają na tworzenie aplikacji z wykorzystaniem funkcji danej technologii.

Skeumorfizm — styl graficzny charakteryzujący się imitowa- niem zachowań fizycznych materiałów w aplikacjach (na przykład drewniane półki, szklane powierzchnie).

Specyfikacja — dokument opisujący funkcjonalne i niefunk- cjonalne wymagania, jakie ma spełnić oprogramowanie. Wchodzi w skład artefaktów.

Sprint — cykl tworzenia iteracji oprogramowania o z góry ustalonej długości (najczęściej trwa tydzień lub dwa tygodnie).

Streaming — strumieniowanie treści (audio i wideo). Mecha- nizm pozwalający na konsumpcję treści bez konieczności czekania, aż zostanie w całości ściągnięta na dysk urządzenia.

Testy A/B — test porównawczy dwóch wersji (zazwyczaj strony internetowej), aby wybrać tę, która daje lepszą konwersję.

Thank You Screen — ekran potwierdzający dokonanie transakcji w systemie.

TOS — Terms of Services — warunki świadczenia usług. Forma regulaminu, na który należy się zgodzić w celu korzystania z systemu.

Translucency — „przeświecanie” — ogólna nazwa na styl ko- munikacji wizualnej stosowany w ioS.

User story — metoda na opisanie oczekiwanej interakcji po- między użytkownikiem a produktem.

Userflow — proces przepływu użytkowników w aplikacji bądź na stronie WWW. Stanowi jeden z artefaktów produktu mo- bilnego.

UX — User Experience — ogólne doświadczenie użytkownika z interakcji z technologią (urządzeniami, aplikacjami i stro- nami internetowymi).

Użytkownik — ktoś, kto korzysta z naszego oprogramowania (aplikacji bądź strony WWW).

VAS — Value Added Services — usługi dodane. W przypadku mobile’a najczęściej VAS oznacza usługi dodane oferowane przez operatorów telefonii komórkowej.

Viral — „wirusowość” — sytuacja, gdy informacja rozpowszech- nia się wśród użytkowników sieci bardzo szybko (tak jak wirus).

War room — pomieszczenie, w którym zlokalizowany jest zespół pracujący nad konkretnym produktem.

Waterfall — jedna z metodyk pracy oparta na „schodkowym” realizowaniu etapów pracy.

Widget — mikroprogram z minimalną możliwością interakcji pozwalający na wykonanie podstawowych funkcji aplikacji, ale bez konieczności jej włączania.

Windows Phone — mobilny system operacyjny firmy Microsoft.

Wireframe — makieta produktu, może zawierać interaktywne elementy.

Wymaganie biznesowe — to, co musi być dostarczone, aby wnieść wartość.