W dobie cyfrowej transformacji, gdzie smartfony stały się nieodłącznym elementem naszej codzienności, aplikacje mobilne zyskują na znaczeniu jak nigdy dotąd. Nie chodzi już tylko o to, by "mieć aplikację", ale o to, by dostarczyć użytkownikom wartość, która wyróżni się na tle konkurencji i zaspokoi ich potrzeby. Za sukcesem każdej aplikacji stoi zespół - grupa ludzi o różnych umiejętnościach i specjalizacjach, którzy wspólnie dążą do jednego celu. W tym artykule chciałbym przedstawić moją wizję idealnego zespołu tworzącego aplikacje mobilną, opartą na wieloletnim doświadczeniu i obserwacjach rynku. Wierzę, że kluczem do sukcesu jest nie tylko technologia, ale przede wszystkim ludzie, ich pasja, zaangażowanie i wzajemna współpraca.

W tym artykule pragnę zaznaczyć, że moje rozumienie zespołu deweloperskiego nie kończy się na programistach. Dla mnie zespół deweloperski tworzą ludzie, którzy mają wkład w rozwój aplikacji. Jest to rozumienie jest zapożyczone z metodologi Scrum do której będę się w tym artykule jeszcze odwoływał. To podejście daje "bird eye view" na poszczególnych członków zespołu i ich wkład w rozwój aplikacji. Uwypukla poszczególne odpowiedzialności i problemy, które naturalnie pojawiają podczas rozwoju aplikacji.

Zasadniczy podział jako można zastosować dzieląc członów zespołu na poszczególne obszary swojego działania t.j:

1. Obszar biznesowy - Product Owner
2. Obszar wizualny - Product Designers
3. Obszar techniczny - Software Engineers

Zagwarantowanie odpowiednich jakości w tych trzech obszarach daje rezultat dobrze skrojonego rozwiązania technicznego i wizualnego do wymagań biznesowych i potrzeb użytkownika.

Odpowiedzialność

Niezaopiekowanie jakiegokolwiek obszaru skutkuje straszliwymi konsekwencjami. Niektóre widać od razu, inne są obecne po czasie, a ich naprawa jest niezwykle kosztowna.

Zbagatelizowanie zdefiniowania dobrego jakościowo celu biznesowego stawia pod znakiem zapytania jakikolwiek sens finansowy całego przedsięwzięcia. Brak dobrego jakościowo UX/UI doprowadza do złej komunikacji z użytkownikiem i sumarycznie niespełnienia podstawowych założeń biznesowych projektu. Brak odpowiednich jakości w obszarze technicznym potrafi zrujnować finansowo projekt dusząc go w powtarzających się ciągłych poprawkach na błędy i kiepskiej wydajności.

Nie ulega wiec wątpliwości, że każdy z tych obszarów musi być z odpowiednią troską zaopiekowany. Konieczna jest więc znajomość poszczególnych odpowiedzialności w zespole. Kto jaką ma odpowiedzialność i jak należy adresować i rozwiązywać problemy. Zastanówmy się nad jakościami jakie powinien dostarczyć poszczególny członek zespołu.

Product Owner

1. Definiowanie Wizji Produktu: PO musi mieć jasną wizję tego, czym ma być aplikacja, jakie problemy ma rozwiązywać i dla kogo jest przeznaczona.
2. Tworzenie i Prioritetyzacja Backlogu Produktu: PO jest odpowiedzialny za tworzenie, utrzymanie i pioretyzację backlogu produktu, który zawiera wszystkie funkcje, poprawki i inne zadania związane z produktem.
3. Określanie Kryteriów Akceptacji: Dla każdego zadania lub funkcji w backlogu, PO powinien określić kryteria akceptacji, które wskazują, kiedy zadanie jest uważane za zakończone.
4. Uczestnictwo w Ceremoniach Scrum: W metodologii Scrum, PO uczestniczy w ceremoniach takich jak planowanie sprintu, przegląd sprintu i retrospekcja sprintu.
5. Zbieranie Feedbacku od Użytkowników: PO powinien regularnie zbierać opinie od użytkowników i interesariuszy, aby lepiej zrozumieć ich potrzeby i dostosować produkt.
6. Monitorowanie Postępów: PO monitoruje postępy w tworzeniu aplikacji i podejmuje decyzje dotyczące kierunku rozwoju produktu.
7. Zarządzanie Interesariuszami: PO komunikuje się z interesariuszami, informuje ich o postępach i zbiera od nich opinie.
8. Zrozumienie Rynku i Konkurencji: PO powinien być na bieżąco z trendami rynkowymi, konkurencją i ewolucją technologii mobilnych.
9. Zarządzanie Budżetem: W zależności od organizacji, PO może być odpowiedzialny za zarządzanie budżetem projektu.

Product Designers

1. Zrozumienie Użytkowników: Przeprowadzanie badań, takich jak wywiady z użytkownikami, ankiety czy testy użyteczności, aby zrozumieć potrzeby i zachowania użytkowników.
2. Tworzenie Person: Na podstawie zebranych danych, tworzenie reprezentatywnych profili użytkowników, które pomogą w projektowaniu interfejsu dostosowanego do ich potrzeb.
3. Mapowanie Ścieżek Użytkownika: Tworzenie map ścieżek użytkownika, które przedstawiają, jak użytkownicy poruszają się przez aplikację i jakie kroki podejmują w celu osiągnięcia określonych celów.
4. Wireframing: Tworzenie szkiców strukturalnych aplikacji, które pokazują główne elementy interfejsu i ich rozmieszczenie.
5. Prototypowanie: Tworzenie interaktywnych prototypów, które symulują działanie aplikacji i pozwalają na testowanie koncepcji przed jej implementacją.
6. Projektowanie Interfejsu: Opracowywanie szczegółowych projektów interfejsu, w tym wybór kolorów, typografii i elementów graficznych.
7. Zapewnienie Spójności: Utrzymywanie spójności projektu na różnych ekranach i platformach, zapewniając jednolite doświadczenie użytkownika.
8. Przeprowadzanie Testów Użyteczności: Organizowanie i przeprowadzanie testów użyteczności z rzeczywistymi użytkownikami, aby zidentyfikować problemy i obszary do poprawy.
9. Iteracja: Na podstawie feedbacku i wyników testów, wprowadzanie poprawek i ulepszeń w projekcie.
10. Zapewnienie Zgodności z Wytycznymi: Upewnienie się, że projekt jest zgodny z wytycznymi dla konkretnych platform (np. Material Design dla Androida, Human Interface Guidelines dla iOS).
11. Utrzymywanie Aktualności: Śledzenie najnowszych trendów w dziedzinie UX/UI, aby projekt był nowoczesny i spełniał oczekiwania użytkowników.
12. Dostarczanie Zasobów: Przygotowywanie i dostarczanie zasobów graficznych dla zespołu programistów, takich jak ikony, grafiki czy specyfikacje.

Software Engineers

1. Analiza Wymagań: Zrozumienie i analiza wymagań biznesowych i technicznych przed rozpoczęciem projektowania i kodowania.
2. Projektowanie Systemu: Tworzenie architektury oprogramowania i projektowania systemu na podstawie analizy wymagań.
3. Kodowanie: Pisanie, testowanie i debugowanie kodu w wybranym języku programowania.
4. Integracja: Łączenie różnych części oprogramowania i zapewnienie, że działają one razem jako spójny system.
5. Testowanie: Sprawdzanie oprogramowania pod kątem błędów i niedoskonałości. To może obejmować testy jednostkowe, testy integracyjne, testy systemowe i testy akceptacyjne.
6. Dokumentacja: Tworzenie dokumentacji technicznej opisującej funkcje, architekturę i działanie oprogramowania.
7. Utrzymanie: Naprawianie błędów, aktualizacja oprogramowania w odpowiedzi na zmieniające się wymagania i optymalizacja wydajności.
8. Szkolenie i Rozwój: Utrzymywanie aktualności w zakresie najnowszych technologii, narzędzi i praktyk w dziedzinie inżynierii oprogramowania.
9. Zapewnienie Bezpieczeństwa: Projektowanie i implementacja zabezpieczeń w oprogramowaniu, aby chronić je przed potencjalnymi zagrożeniami.
10. Optymalizacja Wydajności: Analiza i modyfikacja oprogramowania w celu poprawy jego wydajności i efektywności.
11. Przestrzeganie Standardów: Zapewnienie, że oprogramowanie jest tworzone zgodnie z ustalonymi standardami i wytycznymi.
12. Przegląd Kodu: Sprawdzanie kodu napisanego przez innych członków zespołu w celu zapewnienia jego jakości i zgodności ze standardami.
13. Wsparcie: Udzielanie wsparcia użytkownikom i działowi wsparcia technicznego w rozwiązywaniu problemów z oprogramowaniem.

Cyrkulacja idei

Warto mieć na uwadze, że wiele problemów które mogą wystąpić w projekcie mimo, że na pierwszy rzut oka maja naturę na przykład biznesową mogą być tak naprawdę naturę technologiczną albo projektową.

Potencjalny problem może wynikać poniekąd braku wiedzy o możliwościach technicznych wśród nietechnicznych osób na stanowisku PO (co jest rzeczą naturalną) lub złego dopasowania projektu do wymagań biznesowych. Ważna jest cyrkulacja idei - swobodny kontakt między wszystkimi członkami w zespole deweloperskim i wzajemne wymienianie się wiedzą.

Świadomość odpowiedzialności za jakość w poszczególnych obszarach - jeśli jest dobrze rozumiana u każdego członka zespołu deweloperskiego daje solidne podstawy by tworzyć szereg wartościowych rzeczy. Żeby relacja między na przykład Product Owner'em, a Inżynierami Oprogramowania przebiegała dobrze potrzebne są procesy. Takich procesów dostarcza między innymi metodologia wytwarzania oprogramowania SCRUM. Daje ona zestaw narzędzi w postaci gotowych definicji spotkań i ich założeń, które swobodnie można zastosować w zespole deweloperskim.

Home | Scrum Guides

Navigate to Home Page

Do przekazywania wiedzy przez PO do zespołu programistów może następować na drodze refirement'u podczas którego omawiane są gotowe zadania. Oprócz tego ważne jest tworzenie warsztatów na temat funkcjonalności gdzie już na samym początku definiowania funkcjonalności zespół programistów widzi jaka jest intencja biznesowa i przed samym procesem "rozpisywania zadań" jest w stanie znaleź ryzyka i zaproponować lepsze do możliwości technologicznych rozwiązanie. Znajomość celu biznesowego i historii definiowania nowej funkcjonalności daje również kontekst i tło wszystkich podjętych decyzji co pomaga później w wycenie zakresów pracy. Warsztaty są świetnym sposobem komunikacji między Product Ownerem, a resztą zespołu deweloperskiego (inżynierami i projektantami). Świętnie sprawdzają się do przekazywania celów biznesowych i dbania o obszar biznesowy przedsięwzięcia. Obecność na warsztatach zespołu inżynierów i projektantów pozwala lepiej zrozumieć biznes i dostarczać bardziej dopasowania rozwiązania technologiczne i projektowe.

Innym sposobem komunikacji i dostarczania odpowiedniej cyrkulacji idei jest Design System, gdzie na jednej płaszczyźnie łączy zespół programistów i designerów. Design System to zestaw wzorców, praktyk, zasobów i komponentów UI, które mają swoje odzwierciedlenie w kodzie aplikacji. Dzięki temu tworzenie szablonów, makiet i rozwiązań wizualnych jest łatwiejsza, szybsze i bardziej przewidywalne po stornie zespołu projektowego jak i inżynierskiego. Design system jest wspólnym językiem komunikowania się z użytkownikiem co jednoznacznie wspiera cele biznesowe projektu.

Lepsza technologia

W przypadku zespołów tworzących aplikacje mobilne (Android i iOS) ważne żeby zadbać o jakość techniczną projektu. Odpowiedni dobór architektury, narzędzi oraz zapewnienie odpowiednich testów to niektóre z tematów które mogą być tematem dyskusji w zespołach inżynierskich. Ważne żeby każdy członek tych zespołów był świadom zmian, wymagań i podejść zastosowanych w projekcie. Dlatego ważne jest żeby regularnie aktualizować listę tematów do przedyskutowania, które mogą mieć wpływ na projekt. Aktywnie tworzyć zadania technologiczne, które mają za zadanie dostarczyć odpowiednią jakość w projekcie i regularnie organizować spotkania na których będą podejmowane decyzje odnośnie prac i obranych kierunków.

Użytkownik na początku i końcu oprogramowania

W dziedzinie tworzenie oprogramowania osiągnęliśmy bardzo wysoki poziom. Nowoczesne języki programistyczne całkowicie zdominowały rynek tworzenia nowych produktów, a problemy takie jak zarządzanie pamięcią w programach, albo implementacja prymitywnych algorytmów ustąpiła miejsca myśleniu nad realizacją celu biznesowego. Oczywiście systemy operacyjne oraz środowiska, ze względu na swoją naturę, wciąż korzystają z prymitywnych

Rafał GawlikRafał Gawlik

Podsumowanie

Tworzenie aplikacji mobilnych to nie tylko technologia, ale przede wszystkim ludzie. Kluczem do sukcesu jest zrozumienie odpowiedzialności każdego członka zespołu i zapewnienie efektywnej komunikacji. Współpraca, zaangażowanie i pasja są niezbędne do osiągnięcia sukcesu w dzisiejszym konkurencyjnym świecie aplikacji mobilnych.