Co musimy wiedzieć przed stworzeniem aplikacji?

Na Mobile Trends Conference, Kamil Grzejek porównał projekt do wyprawy statkiem. Celem tej podróży jest bezpieczne dotarcie do celu, czyli wdrożenie aplikacji realizującej cele klienta. Aby to osiągnąć, potrzebny jest odpowiedni kapitan, mapa, dobra załoga, statek oraz cel podróży, ale po kolei!

Rejs potrzebuje kapitana

Odpowiedzialność w projekcie często jest rozproszona, co może doprowadzić do problemów w realizacji. Mamy Project Managera, mamy Product Ownera i inne osoby, które są odpowiedzialne za realizację. Takie rozproszenie może w pewnym momencie pchać działania w różnych kierunkach. Równie problematyczne mogą być zmieniające się w projekcie osoby oraz okoliczności, co wcale nie jest rzadką sytuacją. W IT jest to wręcz typowe. Dlatego, według przedstawiciela Escola, mądrym podejściem jest wyznaczenie stałego kapitana na czele zespołu.

Aktualizacja mapy podróży jest kluczowa

Często zdarza się, iż klienci mają różne podejścia do wymagań aplikacji. Projektanci muszą dokładnie zrozumieć cele klientów i stale je monitorować, aby uniknąć rozjechania się projektu. Jednak proces koncepcyjny i badawczy mogą trwać bardzo długo. Nie wspominając o samym tworzeniu i wdrażaniu aplikacji. Historia pokazuje, iż projekty mogą trwać miesiącami, a choćby latami. Wizja, którą mają w głowie managerowie może być i zwykle będzie już zdezaktualizowana. Prelegent zauważa, iż konieczna jest aktualizacja strategii do bieżącej sytuacji rynkowej. jeżeli nikt tego nie zrobi, może okazać się, iż realizowany projekt już na starcie stoi na przegranej pozycji. Opiera się na nieaktualnych założeniach. Zderzenie z rzeczywistością nadejdzie w momencie wdrożenia aplikacji. Wtedy może okazać się, iż cały projekt został zmarnowany i nie osiągnie założonych wcześniej celów biznesowych.

Jeśli chcesz wypłynąć, musisz mieć okręt!

Z perspektywy przygotowania do prac nad aplikacją, ważnym punktem jest wybór technologii. Firma nie powinna podchodzić do tego ze swojej perspektywy. Powinna podejść do tego z perspektywy projektu. Zespół może mieć wiele zrealizowanych projektów w konkretnej technologii i może pokusić się o jej wybór przy następnym. Jednak nie musi być to najlepsze rozwiązanie dla następnej aplikacji. Konsultant z Escola zwraca uwagę na to, iż to technologia powinna być dobrana do projektu, nie odwrotnie. W innym przypadku zaczynamy ograniczać projekt już na starcie. – Na koniec dnia, ten projekt nie będzie spełniał swojej roli, jeżeli wybraliśmy złą technologię. Możemy mieć interesariuszy, analizy i badania, ale jeżeli sami włożymy się w takie wąskie ramy to umrzemy śmiercią naturalną. Bo nie będziemy w stanie realizować długoterminowo całej wizji produktowej – tłumaczy ekspert.

Ważne są długoterminowe cele

Bez odpowiedniej technologii, może się zdarzyć, iż dany projekt stanie się trudny do rozbudowywania lub utrzymywania w przyszłości. Warto korzystać z bardziej innowacyjnych rozwiązań niż oklepanych schematów. W przeciwnym wypadku, może okazać się, iż technologia, w której dobrze się czujemy, za dwa lata będzie archaiczna. Każda zmiana w takim projekcie może prowadzić do o wiele większych kosztów niż zakładano. Może nie być to opłacalne dla żadnej ze stron. Dlatego warto starannie wybierać technologie, aby nie musieć modyfikować zrealizowanych już modułów. Działania nastawione na innowacyjność pozwolą na zabezpieczenie jakości i zminimalizowanie kosztów w dłuższej perspektywie.

Analiza potrzeb użytkowników, czyli o szukaniu skarbu

Jeśli okręt dopływa do wyspy, załoga może zacząć szukać skarbu. zwykle znajdzie na niej jakichś mieszkańców, którzy mogą wiedzieć więcej o topografii danego regionu. Każdy z tych mieszkańców ma jakieś swoje potrzeby, problemy i motywacje do ich rozwiązania. Na podstawie informacji od nich możemy stworzyć mapę, która przybliży nas do celu. W biznesie jest podobnie. jeżeli nie mamy sprofilowanych person, tak naprawdę nie wiemy kto będzie odbiorcą produktu. Skąd mamy wiedzieć w jaki sposób aplikacja ma realizować cele tych ludzi? Grzejek tłumaczy, iż choćby jeżeli aplikacja ma duży sens z perspektywy klienta, to nie do końca może mieć taki sam sens dla końcowych użytkowników. Bo nie sprawdzono jak użytkownicy chcieliby z niej korzystać. Nie pozwoli to też wymyślić optymalnego modelu monetyzacyjnego. – Możemy zrobić na przykład aplikację FMCG z kuponami. Ona może mieć różne fajne rzeczy, ale w szczegółach nie zbadaliśmy tego, iż matki z dziećmi mogą potrzebować dodatkowych funkcjonalności. Z naszej perspektywy, aplikacja może być bardzo funkcjonalna. Są kupony, są gazetki, są listy promocyjne, jest program lojalnościowy. Ale zapomnieliśmy o jednej z grup docelowych, która skorzystałaby na innym spojrzeniu – zauważa konsultant z Escola.

Nie zespół decyduje o celu podróży

Zespół często skupia się na funkcjonalności modułu. – Skupiliśmy się na kuponach, skupiliśmy się na liście i ta aplikacja może prezentować się świetnie. Tylko zapomnieliśmy o tym, iż Ci wszyscy ludzie mają jeden wspólny cel. Chcą wejść w aplikację, kupić czego potrzebują i wyjść. Nie potrzebują setek funkcjonalności. – mówi Grzejek.

Konsultant zauważa tu problem, który Don Norman w Dizajnie na co dzień nazwał “funkcjozą”. To określenie na chorobę wszystkich rozwijanych produktów. Często podmiot działający w ściśle konkurencyjnym rynku determinuje skupienie się na funkcjonalnościach, żeby wybić się na tle konkurencji. Może zapomnieć przy tym, iż użytkownicy w większości nie skorzystają choćby z tych opcji. Ba! Mogą one choćby wywoływać ich irytację i niechęć. Zwłaszcza, jeżeli odbiorą użytkownikowi kontrolę nad sytuacją używania produktu. Konsultant z Escola radzi, aby znaleźć złoty środek. Nie powinno opierać się tylko na ogólnych funkcjonalnościach, gdyż prawdopodobnie poprowadzi to do powstawania miałkiego produktu. Jednak zbyt duża ich ilość może oddalić użytkowników od realizacji swoich celów, czego przecież jako twórcy aplikacji nie chcemy.

Obserwuj morze, żeby nie zboczyć z kursu

Burzy no morzu nie zawsze da się uniknąć, ale można obserwować otoczenie, by ograniczyć niebezpieczeństwo. Nawigacja jest kluczowa. W przypadku aplikacji, służą do tego badania. Badania są podstawą aplikacją. jeżeli podstawa będzie słaba, niezweryfikowana lub nieaktualna, może się okazać, iż rozwiązujemy nierealne problemy. Widać to szczególnie w wieloletnich procesach wdrożeniowych. Proces powstawania aplikacji ma swoje fazy. W ramach procesu, te fazy powinny płynąć obok siebie.W trakcie realizacji projektu przez zespół deweloperski, można równolegle prowadzić badania rynku i konsultacje z użytkownikami, aby na bieżąco udoskonalać wizję produktową. Rynek się zmienia, zmieniają się upodobania użytkowników, którzy uczą się na rozwiązaniach konkurencji. Warto mieć to na uwadze, jednak wciąż potrzeby będą potrzebami. Aplikacja musi skupiać się na swoim trzonie, czyli rozwiązaniu problemów swoich klientów. o ile klient nie będzie miał problemu do rozwiązania, to nikt z takiej aplikacji nie będzie chciał korzystać. Aby pomóc zespołowi zrozumieć wszystkie bolączki osób, dla których tworzą program, Kamil zaleca wykorzystanie user stories, czyli wizualizacji wykorzystania danego produktu. Pobudza to kreatywność zespołu oraz pozwala empatyzować z użytkownikami.

Rejs bez dobrej załogi nie ma sensu

Załoga na statku jest kluczowa, tak samo jak kapitan. W końcu jego zadaniem jest dbanie o realizację zadań, ale sam nie jest w stanie ich wykonać. Załogę tworzą wszyscy zaangażowani w projekt. Gdy pracujemy nad projektem, istnieje wiele czynników, które mogą wpłynąć na jego przebieg. Dlatego ważne jest, aby zawsze zwracać uwagę na oczekiwania interesariuszy biznesowych, ponieważ ich wymagania mogą ulec zmianie w trakcie projektu. jeżeli tak się stanie, powinniśmy dopasować odpowiednio zespół, aby mieć zapewnioną najlepszą jakość pracy i efektywność działania.

Komunikacja kapitana ma wpływ na kurs

Komunikacja jest kluczowa dla wszystkich etapu procesu projektowego. Według Kamila Grzejka szczególnie ważne jest komunikowanie wizji projektu. Manager powinien być ewangelistą celów projektowych i przekazywać zespołowi wizję projektu w sposób zrozumiały i inspirujący. Według konsultanta deweloperzy czasem nie do końca rozumieją całą wizję projektową i skupiają się jedynie na realizacji konkretnych zadań z backlogu. Może to prowadzić do sytuacji, w której programiści wykonają niektóre rzeczy bardzo dobrze, a inne zaniedbają lub pominą, uważając je za nieistotne. – PM może mieć wszystko świetnie rozplanowane, ale zespół może nie chcieć tego realizować. Może się okazać, iż po zakończeniu sprintów i zamykaniu zadań, projekt nie spełnia oczekiwań klienta, ponieważ deweloperzy poszli na skróty i zrealizowali wizję w sposób niedostateczny, co może przykładowo utrudniać korzystanie z interfejsu. W takiej sytuacji odkręcenie tych wszystkich godzin pracy programistów nie jest takie proste. Poprawa projektu jest bardzo trudna i wymaga czasu oraz dodatkowych nakładów pracy – mówi Kamil. Dlatego tak ważne jest, aby zespół deweloperów znał całą wizję projektową, Musi wiedzieć, jakie cele projekt ma osiągnąć. Komunikacja między zespołem a PM-em oraz zespołem a klientem jest kluczowa, aby projekt mógł być zrealizowany w sposób efektywny i zgodny z oczekiwaniami wszystkich zainteresowanych stron.

Dobry kapitan ma dobry kontakt z załogą

Współpraca między ludźmi to klucz do sukcesu projektu. jeżeli nie będziemy umieli się porozumiewać i przekazywać informacji, nie osiągniemy dobrych wyników. Dlatego ważne jest, aby budować komunikację opartą na otwartości i wspieraniu. Zwłaszcza, iż w trakcie projektu pojawią się trudne momenty. Nigdy nie ma sytuacji, w której wszystko jest idealne. Warto więc zwracać uwagę na relacje między członkami zespołu. Warto z nimi porozmawiać nie tylko o projekcie oraz spotkać się poza pracą, aby lepiej ich poznać i zbudować silniejsze relacje. Jest to kluczowe, gdy popełniamy błędy. Łatwiej jest komunikować się z ludźmi, których znamy na temat trudności. Tyczy się to także środowiska zawodowego. Przyjazna atmosfera pozwala też na efektywniejszą naukę na błędach, co pozwoli unikać powtarzania ich w przyszłości. – Pracownicy są ważni. Czasem warto się z nimi spotkać i porozmawiać o błahostkach. To pomaga budować relacje. W takiej sytuacji osoby te są w stanie wychwycić, iż druga osoba czegoś nie lubi lub jest w stanie szczerze porozmawiać. Ułatwia to rozmowę o złym rozwiązaniu, które zostało wcześniej zaproponowane. A jest to trudne dla deweloperów, ponieważ często zdarza się, iż zaplanowali coś i nie chcą tego zmieniać. choćby jeżeli w trakcie projektu pojawiają się problemy. Należy zrozumieć, jakie były powody tych problemów, jak je rozwiązano, i jak tego uniknąć w przyszłości – podsumowuje.

Sukces to skomplikowana układanka

Podsumowując, najważniejsze dla powodzenia projektu jest określenie decydenta, kontrola kosztów oraz odpowiednia wycena produktu. Pamiętajcie, iż podejście do projektu musi być elastyczne i dostosowane do zmieniających się potrzeb użytkowników oraz rynku. Analiza narzędzi i elementów projektowych to tylko jedna z wielu rzeczy, które mają wpływ na sukces projektu. Project Manager powinien mieć na uwadze nie tylko swoje doświadczenie w branży, ale również perspektywę klienta i użytkowników produktu. Nie powinien on też zapominać o swoim okręcie. Projekt musi być napisany w dobrze rokującej technologii, a PM musi budować relacje poprzez regularne rozmowy i wychwytywanie potencjalnych problemów. Zespół złożony choćby z największych ekspertów może, (a choćby ma prawo!) popełniać błędy. Ale powinien wyciągać z nich wnioski. Przykład jednak idzie z góry. To rolą managerów jest wypracowanie takiej kultury organizacyjnej. – PM to nie tylko kontrola budżetu i zbieranie wymagań. To przede wszystkim realizacja misji projektu, która opiera się na ciągłej współpracy i skutecznej komunikacji w zespole – kwituje Consultant z Escola.