Jak pracować nad projektem, nie mając potrzebnych informacji. Case study
Jednym z projektów Adama Kobusa z intent było stworzenie aplikacji mobilnej, która ma sterować czujnikami zwiększającymi bezpieczeństwo osób wykonujących pracę fizyczną. Nie miał wtedy jeszcze gotowych designów ani dostępu do nawet prototypowej wersji czujników. Żeby nie siedzieć bezczynnie, podjął decyzję, aby jego zespół zaczął pracę nad tymczasową aplikacją. Ale jak to, pracować nad projektem nie posiadając istotnych informacji? Przykład Adama pokazuje, że da się – z korzyścią i dla zespołu, i dla klienta.
Spis treści
Na początek – czym dokładnie zajmujesz się w intent? Za co jesteś odpowiedzialny i na czym polega Twoja praca na obecnym stanowisku?
Zajmuję się głównie tworzeniem aplikacji mobilnych na Androida. Jestem odpowiedzialny również za interpretację wymagań klienta i planowanie rozwiązań.
Jakie były najciekawsze projekty/aplikacje, nad którymi przyszło Ci pracować w intent?
Bardzo lubię projekty, które pozwalają mi poznać nowe technologie lub zobaczyć, jak działają od kuchni różne branże. Przykładem może być integracja aplikacji mobilnej z terminalem płatniczym, która pozwoliła mi na szczegółowe poznanie, jak działają systemy płatności. Inny przykład to integracja aplikacji mobilnej z systemami rozrywki różnych producentów samochodów, gdzie przy okazji zdobyłem sporo wiedzy powiązanej ze światem automotive i audio.
Jednym z Twoich projektów było stworzenie aplikacji mobilnej, która ma sterować czujnikami zwiększającymi bezpieczeństwo osób wykonujących pracę fizyczną. Opowiedz, proszę coś więcej o tej aplikacji.
Jesteśmy wciąż w trakcie jej realizacji, ale póki co również zapowiada się ciekawie. Na ten moment pracujemy nad pierwszym etapem projektu, którego celem jest zaprezentowanie kluczowych funkcjonalności rozwiązania przed udziałowcami oraz weryfikacja założeń klienta. W skład tego rozwiązania wchodzi sensor zbierający informacje na temat tego, czy pracownik wykonuje swoją pracę w bezpieczny sposób, oraz aplikacja mobilna komunikująca się z tym sensorem poprzez Bluetooth Low Energy.
Czasu na realizację tego etapu nie ma zbyt wiele. Klientowi zależy na tym, aby mieć pierwszą wersję aplikacji gotową na początku drugiego kwartału 2022 r., a projekt wystartował w połowie stycznia. Nie mieliśmy wtedy jeszcze gotowych designów ani dostępu do nawet prototypowej wersji czujników.
Zaczęliście więc pracować nad projektem bez informacji? To musiało być dość trudne zadanie.
Trochę tak, tym bardziej, że był to dosyć świeży projekt i nie mieliśmy jeszcze konkretnego planu, jak do niego podejść. Pewne było tylko to, że będziemy łączyć się z jakimś urządzeniem z użyciem Bluetooth Low Energy.
Żeby nie siedzieć bezczynnie, podjąłem decyzję, abyśmy zaczęli pracę nad tymczasową aplikacją, do której UI zaprojektowałem w Miro. Wyszedłem z założenia, że nieważne, z jakim urządzeniem BLE mamy do czynienia, pewne rzeczy zawsze muszą zostać zaimplementowane. Są to rzeczy takie, jak logika wyszukiwania lub dodawania urządzenia, nawiązania i podtrzymania połączenia lub też odczytywania i zapisywania wartości. Wszystkie te rzeczy uwzględniłem przy projektowaniu tej aplikacji. Dodatkowo zaplanowałem ekrany wyświetlające dane diagnostyczne na temat urządzenia. Pozwoliły nam one zweryfikować, czy dostarczona implementacja działa poprawnie.
Jak podzieliliście się zadaniami? Które działania udało się Wam zrealizować bez istotnych informacji od klienta?
Aplikacja tymczasowa została zaimplementowana tak, aby mogła komunikować się z dowolnym urządzeniem BLE, dzięki czemu mogliśmy weryfikować efekty naszej pracy z prawie każdym urządzeniem, które mieliśmy pod ręką, na ręce lub na głowie. Pozwoliło nam to na dostarczanie nowych funkcjonalności bez czekania na materiały od klienta.
Dzięki tej decyzji programiści mieli zapełniony backlog na kolejne 5 tygodni pracy. W międzyczasie designerzy UX i UI mogli odetchnąć z ulgą, gdyż nie byli męczeni przez zniecierpliwiony zespół i mogli skupić się na zbieraniu wymagań. Project manager zaś nie martwił się szukaniem zajęcia dla programistów i mógł skupić się na organizacji pracy z klientem w tym dosyć kluczowym momencie, jakim jest start projektu.
Co pomogło realizować ten projekt na tym etapie?
Głównym celem było przygotowanie jak największej ilości komponentów w sposób pozwalający na ich ponowne użycie w docelowej aplikacji. W osiągnięciu tego celu bardzo pomocne okazało się podzielenie projektu na odpowiednie moduły.
Dzięki odpowiedniej konfiguracji projektu udało nam się użyć w docelowej aplikacji zarówno zaimplementowaną logikę biznesową, jak i część ekranów aplikacji tymczasowej.
Ile udało się Wam zrobić, zanim zaczęliście pracę nad właściwą aplikacją?
Myślę, że dosyć sporo. W momencie, gdy już zaczęliśmy pracę nad docelową aplikacją, gotowa była obsługa połączenia i komunikacji z urządzeniem oraz obsługa błędów. Poza tym w trakcie tych pierwszych tygodni skonfigurowaliśmy projekt i pomocnicze narzędzia. Zgodnie z założeniami udało nam się również użyć części tymczasowej aplikacji jako menu diagnostycznego w aplikacji docelowej.
Głównym celem było dostarczenie jak największej wartości dla klienta mimo dużej liczby niewiadomych i moim zdaniem udało nam się ten cel osiągnąć.
Myślisz, że takie podejście sprawdzi się przy wszystkich projektach? Czy też może wiele zależy od tego, co powstaje?
Sporo zależy od tego, czy jesteśmy w stanie zidentyfikować funkcjonalności, czy też ich elementy nadające się do implementacji, nie mając zbyt dużej wiedzy na temat dotyczących ich wymagań. Nawet w przypadku tego projektu z decyzją o przygotowaniu mocków czekałem, aż klient potwierdzi, czy czujnik bazuje na Bluetooth Low Energy lub Bluetooth Classic. Gdybyśmy od razu zaczęli przygotowywać aplikację pod BLE, a potem by się okazało, że urządzenie go nie wspiera, to zmarnowalibyśmy czas nasz i klienta.
Poza tym myślę, że sporo zależy od klienta i jego skłonności do dostrzeżenia wartości w tym podejściu.
Czy można mówić o jakimkolwiek minimum informacji, które musimy mieć, by rozpocząć pracę dla klienta nad aplikacją?
Tak naprawdę od klienta wystarczy mieć pomysł na biznes, a od zespołu potrzebny jest pomysł, jak go zrealizować w umówionym czasie. Im mniej znamy szczegółów, tym bardziej rośnie ryzyko niepowodzenia projektu i myślę, że decyzja o tym, czy warto rozpocząć pracę zależy w dużej mierze od tolerancji na związany z tym stres, zarówno po stronie klienta, jak i zespołu.
W przypadku tego konkretnego projektu potrzebna była integracja z urządzeniem komunikującym się po Bluetooth. Jest to coś, co robię nie pierwszy raz. Z tego względu wiem, czego się spodziewać i jestem w stanie zaplanować rozwiązanie, mając minimum wiedzy na jego temat. Gdyby projekt opierał się na technologii, z którą nie mam doświadczenia, to myślę, że w podobnej sytuacji miałbym spore opory przed zadeklarowaniem swojej chęci do jego realizacji w tak krótkim terminie.
Jakie korzyści wskazałbyś w takim podejściu do pracy nad projektem?
Myślę, że największą korzyścią płynącą z tego podejścia było odciążenie reszty zespołu. Przygotowanie mocków aplikacji tymczasowej zajęło mi jedynie kilka godzin, a okazały się one wystarczające do tego, aby zapewnić zajęcie programistom na kolejne tygodnie. Przez ten czas programiści nie potrzebowali żadnych dodatkowych informacji od designerów lub klienta i mogli już na samym początku projektu zacząć dostarczać funkcjonalności.
Obecnie, pracując nad docelową aplikacją, korzystamy z wcześniej dostarczonych elementów i robimy dzięki temu szybkie postępy. Gdybyśmy czekali ze startem projektu dodatkowy miesiąc, to myślę, że narzucony termin byłby ciężki do dotrzymania. Poradzenie sobie z tą trudną sytuacją było głównym celem przedstawionego podejścia i na ten moment myślę, że cel ten został osiągnięty.
Adam Kobus. Android app developer w intent od 2013 r. Jego profil na GitHubie: github.com/AdamKobus.
Zdjęcie główne pochodzi z unsplash.com.