Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jak nie schrzanić aplikacji mobilnej

Poznaj błędy, jakie można popełnić, tworząc aplikację mobilną oraz dowiedz się, jak ich uniknąć.
Jak nie schrzanić aplikacji mobilnej

Jestem prezesem softwarehouse’u Escola i popełniłem mnóstwo błędów przy tworzeniu produktów cyfrowych. To jest moja spowiedź z błędów przy projektowaniu i prowadzeniu projektów. Wynika z nich kilka lekcji, które pozwolą Tobie nie popełnić moich błędów. Mam nadzieję, że skorzystasz z mojego doświadczenia.


Projekt informatyczny to nie seria sprintów. To maraton, w którym trzeba dobrze rozłożyć siły

Wszyscy jesteśmy tacy niesamowici i niepowtarzalni. Nie opuszcza nas duch startupów, wciąż mamy energię hipstera ścigającego się z rowerzystami na elektrycznej hulajnodze. Siedzimy codziennie na ławce w parku, pociągamy sojowe latte i na swoim super hiper Macu kodujemy technologie, które zawładną światem.

Na prelekcjach, konferencjach chwalimy się rewolucyjną technologią, ubraną w setki frameworków. Pitchujemy swoje genialne rozwiązania. Dostajemy mądre pytania od publiczności. Udoskonalamy projekt.

Tworzymy. Robimy daily w słowiańskim przykucu, gramy w rozbierany planning poker, Jira aż musiała dokupić więcej serwerów, tak ją obciążamy. Leje się kawa. Magic keyboard musimy wymieniać, bo nie wytrzymują tak intensywnego używania. Wkrótce prezentacja dla klienta. Chwalimy się, że projekt niemal jest skończony. Jeszcze tylko chwilka i świat będzie odmieniony. 

Tylko że z mojego doświadczenia wynika, że projekt ukończony w 99% to projekt niedokończony. Najczęstszy problem to właśnie końcowy etap projektu. Podobnie jak w maratonie, pierwsze 25-30 kilometrów idzie gładko, potem przychodzi ściana i kolejne 10 kilometrów jest najtrudniejsze! Sam finał często jest przyjemnością - bo widać już metę i można wykrzesać ostatnie siły. Często więc pamiętamy ostatecznie, że „było ciężko, ale daliśmy radę”.


Idealny proces wdrażania projektu

To ideał, do którego dąży każdy zespół developerski. 

Od idei, przez analizy, prototypy i projekty graficzne. Staramy się, aby development nie wyrwał się z nas za szybko. Trzeba przeglądać specyfikację i punkt po punkcie zaplanować projekt. Kodujemy. Idzie szybko. Frontend i backend się dogadują jak w kochającym się małżeństwie. QA, testing znajdują niedociągnięcia, bo przecież można się pomylić. Problemy zostają usunięte. Wdrożenie, kontrola i potem wspaniała współpraca w utrzymaniu oraz rozwoju. Mamy klienta na całe życie. 

Co pójdzie nie tak?


1. Analiza i specyfikacja

Porywa nas wizja, zarówno to, o czym mówi klient, jak i nasza własna wyobraźnia. Zazwyczaj wiele funkcjonalności robimy po raz pierwszy. Trudno wybrać esencję, czyli stworzenie MVP.

Gdy rozum śpi…

Nie zawsze my chcemy się edukować lub rozmawiać z klientem o możliwych ograniczeniach projektu. Mamy podpisaną umowę, terminy lecą, jedziemy z rozwojem produktu. Ruszamy do pracy. Odzywa się w nas zew programisty, emocje startupera, płyniemy jak surfer na fali. I się zaczyna...  


2. Prototypowanie

Czasem sam mam ochotę sobie napisać nad biurkiem: komunikacja, głupcze! 

Gdy omijamy komunikację, wychodzi jedno wielkie… nic. Działa to w obie strony od klienta do nas i od nas do klienta.

Przykład z życia softwarehouse’u.

Światowa instytucja finansowa zamówiła u nas aplikację. Na etapie prototypowania słabym ogniwem okazała się rejestracja. Zaznaczaliśmy, że ta funkcjonalność może być problemem. Nie powstał diagram, bo klient utrzymywał, że ten proces musi tak wyglądać. Klient nasz pan. Aplikację tworzymy już ponad dwa lata. Kuleje rejestracja.

Wniosek

Zazwyczaj wybór, dokonany na etapie prototypowania powoduje nowe podejście w logice aplikacji. W rezultacie problemem było przejście przez review Apple store, co znowu wymusza zmianę logiki. W tym momencie koło się zamyka i mamy nieustający problem.


3. Zespół

Zdradzę pewien sekret. 

Szefowie softwarehouse’ów często pożyczają sobie zespoły. Pomoc koledze po fachu to nic złego. O wiele bardziej niebezpiecznie robi się, gdy ławeczka się powiększa, a firma zaczyna tworzyć łańcuszek podwykonawców. Widziałem konfiguracje 7 firm. Ostatnia, dla cięcia kosztów, wynajęła freelancerów na zaniżoną cenę. 

Czy może to tworzyć problemy?

Przykład to aplikacja do maratonu. 

Wszyscy nasi developerzy byli obciążeni, do projektu zastali wynajęci zewnętrzni programiści. Niestety nie mieli oni dostatecznego doświadczenia w technologii. Jedynym skutecznym rozwiązaniem było zabranie PM i zrobienie pracy na nowo. Czas to pieniądz. 

W tym wypadku było mało czasu i dużo pieniędzy. Te środki były przeznaczone na projekt i szły jak woda. Niestety nie do kasy firmy.


4. Agile i Scrum

W projektach widzę pewną prawidłowość. 

Agile i Scrum świetnie brzmią. 

Agile i Scrum to zwinność, umiejętność, kreatywność. Gdy popłyniemy na fali Agile i Scruma, zakładamy, że wszystko dopracujemy po drodze. 

Ogromnym błędem projektów jest brak świętej trójcy dokumentów biznesowych: BRD, FRD, TRD. Dopracowanie projektu po drodze wymaga niemal tyle samo pracy, co tworzenie dokumentacji.

Wniosek

Solidne zespoły developerskie doradzają już na wczesnym etapie, co jest do osiągnięcia, a co będzie wymagać większych nakładów. Dopracowanie dokumentacji na wczesnym etapie daje nam większe pole do popisu w czasie realizacji zadań. Jednocześnie nie tworzymy rozwiązań na kolanie i wiemy, w którą stronę mamy iść.


5. Kodujemy

Zaczynamy development! Od razu pojawia się kwestia terminów i czasu. Stworzone testy pokazują wymarzone rezultaty. Czasem aż za dobre. 

No właśnie, czas.

Projekt, który rozwijaliśmy, był przeznaczony do użytku na innym kontynencie. Polegaliśmy na czasie serwera, a trzeba było ustawić odpowiednią strefę czasową. Po odpaleniu aplikacji kilka tysięcy osób weszło jednocześnie na stronę. Odświeżało ją co chwila. Z powodu błędnego czasu witryna nie wystartowała. Z kim rozmawiać o setupie projektu i jak to rozwiązać? Z devami, z PM? 

Kto ma mieć zadanie rozwiązania problemu?


6. Mistrzowie Jiry

Gdy projekt jest omówiony, zaczyna się przydzielanie zadań. Wykorzystujemy Confluence lub Jirę. Zazwyczaj mamy w firmie osoby, które umieją to robić na poziomie ninja.

Mam wgląd w każde zadanie, które przechodzi przez naszą aplikację do wykonywania zadań. Powstaje forward loop.

I oto historia:

Za tydzień w piątek (sic!) mamy mieć środowisko produkcyjne w aplikacji. Zadanie bierze na siebie programista. W Jirze to zadanie przypisuje koledze, który realizuje inny projekt. Jeszcze nie oceniajmy. Kolega nie daje rady, prosi kolejną osobę o pomoc. Mamy już trzech w łańcuszku. 

Za pięć dwunasta okazuje się, że jesteśmy w proszku. Projekt leży. Pada hasło: wszystkie ręce na pokład! Dochodzą kolejne osoby, a zadanie powraca do programisty, który zaczął zadanie w poprzednim tygodniu. 

Forward loop czystej wody. Niezwykle stresujące doświadczenie, wynikające z braku trzymania się ustaleń. Jak dziś wspominam, to wciąż czuję ciężar w żołądku. Bo wszystko ma ograniczenia.


7. To nie działa i nie będzie

Wiemy, że ustalając założenia technologiczne, napotkamy trudności. W dużych projektach nierzadko uzyskujemy odpowiednie wymagania techniczne. W rzeczywistości twórcy dokumentów nie znają wszystkich technologii. 

Nie zawsze twórca przeszedł przez wszystkie problemy i ograniczenia technologii. W rezultacie założenia stają się koncertem życzeń, tworzonym nieświadomie. W dokumentach pojawiają się założenia nie do spełnienia. 

Przykładem są rozwiązania WCAG 2.1 i tworzona hipermultimedialna gra, dostosowana dla osób niewidomych, niesłyszących lub niepełnosprawnych ruchowo. W rezultacie tworzymy na przykład szczegółowe mapy, nie znając terenu.

Inny przykład: beacony. Cała aplikacja oparta była o te czujniki. 

Pierwszym problemem było legalne i bezpieczne włączenie Bluetootha. Jeszcze większym problemem okazały się zabezpieczenia iOS. Przeszliśmy to wyzwanie. 

Następnym krokiem było rozmieszczenie beaconów. Po testach okazało się, że fale czujników odbijają się od elementów w pomieszczeniu i wskazują zupełnie inne miejsca. 

Pomysł był świetny. Realizację położyła fizyka. I komunikacja.


8. Komunikacja Backendu z Frontendem

To moja ulubiona kategoria schrzanionych projektów. Najczęściej kuleje przekazywanie informacji. Prowadzimy projekty, w których my zajmujemy się obiema stronami, albo klient dostarcza API, a my pracujemy nad aplikacją mobilną.

Problem zaczyna się, gdy backend od klienta zwraca error 500. Klient zgłasza, że aplikacja nie działa. Fakt niezaprzeczalny. A naszym ogromnym wyzwaniem jest omówić i rozwiązać sytuację tak, aby aplikacja pobierała odpowiednie informacje i była podpięta w odpowiednim miejscu w kodzie. 

I tu pojawia się wspomniana aplikacja maratonowa. Prawo dużych imprez mówi, że podczas podobnych biegów kilka osób może mieć problemy ze zdrowiem. Aplikacja umożliwiała lokalizację uczestnika i wezwanie pomocy. Bezpieczeństwo przede wszystkim. Po naciśnięciu przycisku pojawiała się informacja, że pogotowie już jedzie. 

Problem polegał na tym, że w tym miejscu nie było API i dyspozytor nie miał informacji o potrzebie wysłania karetki. Błąd udało się zlokalizować chwilę przed opublikowaniem aplikacji. Strach pomyśleć, co byłoby, gdybyśmy nie znaleźli powodu.


9. Implementacja testów

U mnie działa. Przynajmniej na naszych serwerach wszystko OK. Przechodzimy na produkcję. I zabawa się zaczyna.

W projekcie dla sieci sklepów stworzyliśmy aplikację promocyjną. Klienci dostawali naklejki, które odczytywali telefonem. Problemem okazała się jakość aparatów w smartfonach. Ten problem przewidzieliśmy, nie każdy ma najnowszego iPhone’a. Pracowaliśmy nad alternatywnymi rozwiązaniami w razie, gdyby główny system nie zadziałał. 

Kusiło pisanie odpowiednich testów, a nawet ich brak. Wybraliśmy inne rozwiązanie: stworzyliśmy alternatywny algorytm, który działał w przypadku słabego oświetlenia i niedobrej jakości obrazu. 

W efekcie algorytmy zaczęły wzajemnie się uzupełniać, jednak efektem było odblokowanie wszystkich poziomów w grze promocyjnej. Nawet bez skanowania naklejek.


10. Wdrożenie

Najciekawszy problem, z jakim się spotkaliśmy, dotyczył skali. Gdy aplikacja jest typu standalone, problemów jest mało. W przypadku rozwoju aplikacji, częstego pobierania wielu informacji, pojawiają się wyzwania. 

Relatywnie mała aplikacja pobierała informacje, wysyłała pushe z pomocą serwera. Aby wysłać wiadomość z pomocą pusha, używaliśmy unikatowych identyfikatorów urządzeń. Dostaliśmy dowolność wyboru technologii. Bajka. Wybraliśmy CRON. Rozwiązanie, które wysyła paczki danych w określonych interwałach. Na przykład 25 wiadomości co minutę. 

Komunikacja działała znakomicie. Aplikacja rosła. A skala przygniotła realizację projektu. Gdy dobiliśmy do 50 tyś. urządzeń, wysłanie powiadomień zajmowało ponad 33 godziny. Klient potrafił wysłać 3 powiadomienia na dobę. Na domiar złego serwer się zapychał i nie realizował pozostałych zadań. A aplikacja rosła.

Klienci, widząc, że aplikacja nie działa, na nowo ją otwierali, resetowali. Aplikacja wzbudzała emocje, a użytkownicy na nowo chcieli się dostać do aplikacji. Musieliśmy przepisać backend, aby nie udusić serwera. Czas, nerwy, ale i brak umiejętności jasnowidzenia.


Wnioski

Praca developera to ciąg problemów do rozwiązania. Jeśli wdrażamy innowacje, tworzymy architekturę, robimy nowe rzeczy - problemy zawsze będą się zdarzać. Na wszelkim polu. 

Aplikacja musi zarabiać. Mieć bardzo dużo klientów, aby zarabiała. Wciąż wielu z nas daje się porwać wizji.


Jak zarządzać kryzysem

Problemem jest nierzadko brak zauważania problemów. Czasem korporacje udają, że nie ma nic strasznego. Nie robi się testów, nie sprawdza się aplikacji na każdy możliwy sposób. Jeśli chcemy robić duże aplikacje, nie ulegajmy tym pokusom. Trwałość aplikacji będzie krótka, jeśli będziemy patrzeć przez palce na problemy. Jeszcze gorzej będzie, jesli nie zasugerujemy klientowi, że coś nie będzie działać. 

A co robić, gdy problem się pojawi?

Jeśli mam przekazać jedną myśl z tej wypowiedzi, to zapamiętajmy jedno: Fuckupy będą się zdarzały. Przygotujmy procedury.

Wróćmy do sytuacji mBanku i powiadomień z „ęśąćż”. Firma zauważyła sytuację bardzo szybko i momentalnie wdrożyła procedury. Bank słusznie wyszedł z założenia, że fuckupy będą. Rozróżnia małe i wielkie problemy. Powiadomienia na produkcji okazały się na szczęście tym małym. Mało który użytkownik obraził się, że dostał push o dziwnej treści. Nie było wycieku, nie ginęły pieniądze. 

Zarządzenie problemem było na tyle efektywne, że kolejna sytuacja sprawiła, że użytkownicy nie byli bardzo wzburzeni, bo przygotowano ich do sytuacji kryzysowej. Zarządzenie PR pomogło dodatkowo ograniczyć ilość osób logujących się i jednocześnie zmniejszenie obciążenia serwera.

Im większy błąd, tym większa nauka. Włączmy retrospekcje do naszych procedur. Na zimno, po jakimś czasie. Wyjaśnianie na gorąco to nie jest dobry moment, odetchnijmy i wtedy porozmawiajmy. 

Koniec końców problemy należą do szefów, którzy będą odpowiadać za zaistniałą sytuację :)

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej