11 rzeczy, które każdy PM musi wiedzieć o projektach mobilnych

Jeśli pracujesz w branży internetowej, prędzej czy później przyjdzie Ci poprowadzić projekt budowy aplikacji mobilnej. Warto odpowiednio wcześniej zapoznać się z listą najważniejszych spraw, na które należy zwrócić uwagę podczas projektów tego typu, tak żeby nie popełniać już na starcie najprostszych błędów.

POZIOM TRUDNOŚCI:

Projektowanie aplikacji mobilnych

Pierwszym tematem, który poruszymy jest projektowanie aplikacji mobilnych. Mimo tego, że project manager nie jest odpowiedzialny za stworzenie makiet (a w przypadku produktów mobilnych również szczegółowego flow ekranów), to musi wiedzieć, na co zwracać uwagę przy projektowaniu aplikacji na smartfony.

1. Rozwiązania natywne

Najpopularniejsze platformy mobilne (iOS, Android, Windows Phone) dostarczają bardzo precyzyjnych wytycznych odnośnie budowy UI. Projektant aplikacji mobilnej nie musi, a wręcz nie powinien próbować wymyślać koła na nowo, bo do dyspozycji ma już gotowe elementy interfejsu (mam tu na myśli np. ikony, czy działanie określonych funkcjonalności – np. hamburgera uruchamiającego menu) rekomendowane przez producenta danego systemu operacyjnego. Wiedzę o dobrych praktykach oraz wytycznych powinien mieć projektant, ale to na project managerze często spoczywa odpowiedzialność za tłumaczenie klientowi powodów wyboru konkretnych rozwiązań.

2. Przygotowanie flow ekranów

Drugim aspektem projektowania aplikacji mobilnych jest większy nacisk na flow ekranów. O ile przy makietowaniu produktów webowych często praca kończy się na etapie przygotowania samych ekranów do poszczególnych części produktu, o tyle w przypadku aplikacji mobilnych zaleca się połączenie tych ekranów w jeden flow (z ang. przepływ zdarzeń). Jest to próba oddania tego, w jaki sposób użytkownik będzie wchodził w interakcję z aplikacją. Dobrze zbudowane flow pozwala dosłownie „poczuć” działanie aplikacji jeszcze przed jej zakodowaniem i wyłapać najważniejsze błędy.

Technologia

1. Dostępne platformy

Obecnie rynek aplikacji mobilnych zdominowany został przez dwie platformy – iOS i Android i to im poświęcimy ten podpunkt. Poniższe zasady mają jednak również zastosowanie do pozostałych systemów, np. Windows Phone czy Blackberry OS.

• iOS – Aplikacje na platformę iOS jeszcze do niedawna pisało się w języku Objective-C. Od 8-mej wersji systemu Apple wprowadził nowy język – Swift – i to on powoli przejmuje pałeczkę pierwszeństwa. Sam fakt zmiany obowiązującego języka jest problematyczny, ponieważ generuje wiele błędów po stronie developerskiej (aplikacje pisane w Swift’cie nie są całkowicie kompatybilne ze starszymi wersjami systemu od Apple’a).

  Warto zwrócić uwagę, że developerzy iOSowi, tak samo jak developerzy Androidowi nie mają wyboru w kwestii języka programowania, który chcą wykorzystać. Z jednej strony daje to producentowi systemu operacyjnego większą kontrolę nad aplikacjami w jego sklepie, a z drugiej ułatwia developerom prace nad produktem. Warto dodać, że rynek iOS jest aktualnie bardzo nienasycony programistami – dobrzy fachowcy są na wagę złota. To oczywiście będzie się z czasem zmieniało, w miarę popularyzowania się tej platformy.

• Android – Developerzy piszący aplikacje mobilne na system Android muszą korzystać z odmiany języka Java. Niewątpliwym plusem tej sytuacji (dla pracodawców) jest to, że developerów znających ten język jest znacznie więcej. Na Jave’ie bowiem pisane są aplikacje enterprise’owe, duże portale internetowe i dziesiątki innych produktów (chociażby aplikacje na telewizory). Powszechnym trendem, który obecnie obserwuje się w branży internetowej jest migracja programistów z sektora WWW do sektora mobilnego z uwagi na większe zarobki oraz ciekawsze perspektywy rozwoju.

2. API

Pracując nad projektami mobilnymi bardzo szybko natkniecie się na pojęcie API (Application Programming Interface). Warto już na samym początku dobrze zrozumieć ten koncept, ponieważ świat aplikacji mobilnych bez API praktycznie nie istnieje. API to tzw. serwer aplikacji, czyli byt, który po swojej stronie przechowuje ogromną część informacji widocznych dla zwykłego użytkownika w aplikacji mobilnej. Weźmy na przykład typową aplikację news’ową, która jest mobilną emanacją dużego portalu internetowego. Żeby w aplikacji non stop dostępne były aktualne treści z WWW nie będziemy kazać użytkownikowi codziennie pobierać nowej wersji produktu na jego telefon. Zamiast tego pobierze on aplikację tylko raz, a ona, za pomocą tzw. requestów (zapytań do serwera) uruchamianych w tle na polecenie użytkownika (np. poprzez wejście do jakiejś sekcji tematycznej), będzie zwracała się do API o najnowsze treści.

API wykorzystuje się do najróżniejszych celów. Jest potrzebne na etapie logowania do aplikacji („API daj znać, czy dany użytkownik jest zarejestrowany w bazie, czy nie”), przy procedowaniu płatności („API zapisz informację, że dany użytkownik opłacił dostęp do sekcji specjalnych i zwracaj ją za każdym razem jak będzie się próbował do nich dostać”) czy edycji profilu użytkownika („API pobierz aktualną wartość pól Imię, Nazwisko, Avatar, a potem nadpisz te pola nowymi wartościami podanymi przez użytkownika”).

3. Udostępnianie buildów

W trakcie pracy nad kolejnymi wersjami aplikacji na pewno zajdzie potrzeba jej instalacji w celach testowych na wielu różnych urządzeniach. O ile w przypadku Androida taka instalacja jest bardzo prosta – można na przykład wrzucić paczkę z aplikacją do Google Drive i wysłać linka do niej w mailu – o tyle w przypadku telefonów pracujących na systemie iOS jest to bardziej skomplikowane. Ze względów bezpieczeństwa Apple nie pozwala na instalację tzw. buildów (czyli kolejnych wersji aplikacji) poprzez link. Wymagane jest wcześniejsze skonfigurowanie na telefonie aplikacji służącej do udostępniania buildów na urządzeniu końcowym (np. HockeyApp).

Aplikacja taka wymaga instalacji odpowiedniego certyfikatu, potwierdzającego jej wiarygodność. Zaletą tego drugiego rozwiązania jest przede wszystkim to, że my jako developerzy mamy pełną kontrolę nad tym, kto ma dostęp do najnowszej wersji aplikacji. Musimy wyrazić zgodę na to, żeby ktoś poprzez HockeyApp mógł ją pobrać. Przy dystrybucji za pomocą linka z paczką nie ma mowy o takim zabezpieczeniu.

Aplikacje typu HockeyApp oferują wiele dodatkowych funkcjonalności. Warto m.in. wspomnieć o statystykach oraz raportach o tzw. crashach (czyli niespodziewanych awariach).

4. Prędkość łącza internetowego

W trakcie prac nad aplikacją musimy pamiętać o dużym znaczeniu aktualnie wykorzystywanego łącza internetowego. Nie raz zdarzało nam się wylądować u klienta na testy z użytkownikami i stanąć przed sytuacją, w której u nikogo aplikacja nie działała płynnie (a przecież u nas w biurze wszystko było OK). Powód? Klient ma beznadziejne łącze Wi-Fi i w sytuacji, w której na raz próbuje się za jego pomocą połączyć 30 osób aplikacja działa bardzo wolno lub wcale (bo użytkownik A musi poczekać aż użytkownik B zwolni łącze).

Problemy z łączem pojawiają się jednak również w zwykłych okolicznościach. Np. wsiadając do samolotu musimy przejść w tzw. tryb samolotowy. Mało kto ma świadomość, że jest to związane z wyłączeniem również wszelkich opcji łączenia się z internetem lub siecią telefoniczną. Jako autorzy aplikacji musimy takie sytuacje przewidywać i np. przygotować specjalny ekran w aplikacji informujący użytkownika, że właśnie stracił połączenie z internetem oraz że dopóki go nie przywróci, nie będziemy w stanie serwować mu nowych materiałów (pamiętacie akapit o API?). Jeśli tego nie zrobimy, to możemy np. spotkać się z przytłaczającą ilością negatywnych recenzji w sklepie (“Aplikacja jest do bani, bo nie pobiera nowych treści, zwłaszcza jak jadę pociągiem”). Ludzie niestety wolno łączą fakty i zanim zdadzą sobie sprawę, że niemożność korzystania z aplikacji była związana z utrudnionym dostępem do internetu zdążą zrobić nam czarny PR.

Testowanie aplikacji mobilnych

1. iOS vs. Android

Testowanie aplikacji na iOS i Android to zupełnie inna historia. Trzeba to sobie powiedzieć na starcie. I nie mam tu na myśli testów pod kątem użyteczności aplikacji, czy kwestii wydajnościowych. To są bardzo istotne tematy, ale żaden z nich nie ma takiego znaczenia jak kwestia ilości wersji systemów i urządzeń końcowych.

Polityka Apple, która nie dopuszcza innych producentów telefonów do systemu operacyjnego ma w tym przypadku wiele zalet. Developerzy nie muszą przejmować się dostosowaniem aplikacji do kilku tysięcy modeli telefonów. Uwzględniają tylko ostatnie 3 lub 4 aparaty. Co więcej, telefony Apple mają tylko kilka bardzo konkretnych rozmiarów ekranów. Jeszcze do niedawna Apple produkował jedynie telefony o przekątnej 3,5 cala. Z biegiem czasu uległ naciskowi rynku i zdecydował się na wprowadzenie modeli z 4, 4,7 i 5,5 calowymi ekranami. Te kilka rozmiarów ekranów i rozdzielczości to jednak nic w porównaniu do morza modeli z systemem Android. Google przyznaje, że oficjalnie wspiera ponad 5000 aparatów od kilkudziesięciu różnych producentów. Jak łatwo się domyślić nie ma fizycznej możliwości sprawdzenia działania aplikacji na każdym z nich.

Ostatni punkt przemawiający na korzyść Apple’a to fakt, że kolejne wersje systemu operacyjnego rozpowszechniają się znacznie szybciej niż ma to miejsce w przypadku Androida. Użytkownicy systemu iOS chętniej instalują aktualizacje, co w dużym stopniu stabilizuje środowisko dla developerów (zamiast obsługiwać 8 ostatnich wersji systemu, muszą uwzględnić tylko 2 lub 3 wersje, bo 99% użytkowników korzysta właśnie z nich).

2. Symulator prawdziwemu telefonowi nierówny

Pracując w świecie, w którym potencjalnie trzeba pozyskać kilkadziesiąt modeli telefonów i stale dokupywać nowe (żeby móc przeprowadzać kompleksowe testy aplikacji) można ulec pokusie korzystania z symulatorów. Symulatory to dostępne w ramach danej platformy programy, które pozwalają sprawdzać zachowanie naszej aplikacji na konkretnych modelach telefonów i systemów operacyjnych.

Prawda jest jednak taka, że na symulatorach nie możemy polegać w 100%, a już na pewno nie możemy kwestionować zgłoszeń klienta, który próbuje nam przekazać, że na jego telefonie aplikacja nie działa prawidłowo (mimo tego, że symulator u nas w biurze pokazuje co innego). Dla bezpieczeństwa i komfortu psychicznego traktujmy symulator jako pomoc, a nie wyrocznię.

3. “U mnie działa”

Te kilka słów zapisało się już w kanonie klasycznych powiedzeń programistów (polecam pełną listę przysłów koderskich). W świecie aplikacji mobilnych nabiera ono jednak nowego znaczenia. Brutalna prawda jest taka, że dana aplikacja potrafi działać na tych samych modelach telefonu z tym samym systemem operacyjnym diametralnie różnie. Wpływ na to może mieć bardzo wiele czynników i niestety często ich zdefiniowanie jest bardzo trudne i wymaga “podłączenia” się pod konkretne urządzenie przez programistę (rozumianego, jako spięcie telefonu z komputerem programisty i odpalenie wszystkich procesów w aplikacji z poziomu komputera, aż do momentu wywołania awarii w aplikacji). Taki tryb debuggowania (wykrywania powodów występowania błędów) jest jednak z reguły utrudniony bądź niemożliwy (bo klient pracuje na drugim końcu kraju i telefon, na którym testuje aplikację jest jego prywatną maszyną). Co zrobić w takiej sytuacji?

1. Przede wszystkim uzbroić się w cierpliwość i przyjąć, że klient ma rację.
2. Następnie upewnić się, że ma zainstalowaną aktualną i wspieraną wersję systemu operacyjnego oraz najnowszą wersję aplikacji.
3. W dalszej kolejności wypytujemy go/ją o dokładne kroki, które podejmuje, żeby powtórzyć błąd i próbujemy je wykonać u siebie.
4. Jeśli to nie pomaga konieczne może być spotkanie z klientem.
5. Czasami pomaga (i warto to robić) uświadomienie klienta, że na świecie jest bardzo dużo modeli telefonów i wersji systemu operacyjnego, ale akurat z jego modelu korzysta tylko kilka procent użytkowników i są na to dowody (np. gemiusRanking).

Taka ciekawostka, która dała nam wiele do myślenia, to fakt, że wpływ na działanie aplikacji na telefonie może mieć nawet tzw. nakładka na system operacyjny. Operatorzy sieci komórkowych często dystrybuują telefony ze swoimi “dodatkami” na pokładzie. Są to konkretne aplikacje wgrane na telefon jeszcze przed jego sprzedażą, zmiany w layoutcie, kolorach i ustawieniach telefonu. Mogą one mieć wpływ na to, jak zachowuje sie nasza aplikacja.

Kolejkowanie prac w projektach mobilnych

1. Równoległość prac nad aplikacją i API

Układając harmonogram projektu mobilnego (w przypadku metodyki kaskadowej) lub pracując w timeboxach (w przypadku projektu zwinnego) trzeba pamiętać o (przynajmniej) równoległym rozwijaniu aplikacji mobilnej i API. Czemu przynajmniej? Ponieważ dobrą praktyką jest próba opracowania po stronie API podstawowych zapytań z wyprzedzeniem. W ten sposób programiści mobilni nie będą musieli czekać przy pracach nad każdym z ekranów na prace po stronie zespołu API. Doświadczenie pokazuje, że w praktyce dobrze jest odpowiednio wcześniej przygotować listę zapytań  jakie będą kierowane z aplikacji do API dla każdego z ekranów i wysłać ją do realizacji do zespołu odpowiedzialnego za serwer aplikacji. W ten sposób zespół mobilny po przystąpieniu do pracy będzie mógł od razu zacząć kodować logikę aplikacji, a nie tylko same widoki (czyli np. rozmieszczenie buttonów i elementów interfejsu, kolory, odstępy, itp.).

2. Review w sklepie

No dobrze, napisaliśmy aplikację, przetestowaliśmy ją, zatem możemy wypuszczać ją na zewnątrz! Nie tak szybko. Również w tej kwestii Apple i Google zdecydowały się na inne podejście. Google pozwala udostępnić aplikację użytkownikom jeszcze tego samego dnia, kiedy zgłosimy taką chęć. Zgłoszenie chęci to po prostu wypełnienie profilu aplikacji w sklepie Google Play (z tego profilu będą ją pobierali użytkownicy Androida).

W przypadku Apple’a sprawa jest nieco utrudniona. Firma z Cupertino umieszcza każdą z aplikacji w tzw. review, czyli przeglądzie, kiedy to siada do niej kilku testerów po stronie Apple i sprawdza, czy aplikacja działa prawidłowo, nie jest awaryjna i spełnia wszystkie wytyczne. Taka strategia pozwala uniknąć publikowania bubli w sklepie i, w końcowym rozrachunku, zwiększa postrzeganą jakość tego medium w oczach konsumentów, którzy z czasem nabierają przekonania, że jeżeli już decydują się na zakup/pobranie czegoś z AppStore, to z reguły jest to wysokiej jakości. Google takiej gwarancji nie daje, ale z drugiej strony znacznie upraszcza proces publikacji.

Oba podejścia mają swoje wady i zalety. Niewątpliwą wadą rozwiązania Apple’owskiego jest fakt, że musimy w harmonogramie prac nad aplikacją uwzględnić przynajmniej 10 dni roboczych na jedno review aplikacji i ewentualnie dodatkowe dni na poprawki, jeśli aplikacja zostanie odrzucona. Po poprawkach aplikacja trafia na początek kolejki do przeglądu i znowu musimy czekać. Pewnym wyjściem jest skorzystanie z tzw. expedited review, czyli przyspieszonej weryfikacji. Nie jest jednak jasne, jak często możem z tej opcji  korzystać. Apple nigdzie takiej informacji nie podaje.

Podsumowanie

Na koniec warto dodać, że Polski rynek zdominowany jest przez telefony z Androidem. Niska cena tych urządzeń oraz akceptowalna (w większości wypadków) jakość sprawia, że mało kto decyduje się na kupno telefonu z wyższej półki, jakim niewątpliwie są produkty Apple’a. Co ciekawe nie oznacza to, że aplikacji na system iOS produkuje się mniej. Wiele firm, dążąc do uatrakcyjnienia swojej oferty (np. banki) wypuszcza swoje aplikacje od razu na wszystkie platformy obecne na rynku. Co więcej dostępne są badania, które pokazują, że użytkownicy systemu iOS częściej wydają pieniądze w sklepach z aplikacjami, co czyni ich atrakcyjną grupą docelową, której nie opłaca się pomijać.

Mamy nadzieję, że powyższy tekst przybliżył Wam świat projektów mobilnych. Z uwagi na swoją specyfikę, zastosowanie najnowszych technologii i często konieczność pracy w zwinnych zespołach nie jest to świat projektów prostych, ale zdecydowanie warto się w nim znaleźć, choćby na kilka miesięcy.