Rola UX w procesie SCRUM
W Monogo obserwujemy wzrost zainteresowania tematami związanymi z User Experience. Większość klientów chce inwestować w kreację idealnych doświadczeń użytkownika. Bardzo często okazuje się jednak, że jedynie liderzy mają świadomość tego, jak powinien funkcjonować zespół projektowy, aby wykorzystać pełen potencjał specjalistów UX. Co różni liderów branż od firm aspirujących do tego miana jeśli chodzi o proces dostarczania produktu? W jaki sposób dołączyć UX do procesu scrum w Twojej organizacji? I wreszcie - co zyskam dodając UX na stałe do procesu scrum? Na te pytania odpowiem w treści poniższego artykułu.
Projektowanie makiet funkcjonalności
Obecnie scrum jest wykorzystywany w około 56% zespołów pracujących w sektorze IT. Ponad połowa zespołów prędzej czy później zmierzy się z wyzwaniem zaadoptowania procesów UX do frameworku scrum. Dlaczego uważam to za wyzwanie? Pracując w branży ponad 10 lat, rozmawiając z innymi specjalistami z branży UX można jednoznacznie stwierdzić, że obecnie standardem jest funkcjonowanie osobnych procesów dla faz discovery i delivery. I jest w tym siła, ale jedynie w przypadku projektów powstających zupełnie od czystej karty, gdzie budujemy produkt od zera i to jedynie w jego w początkowej fazie.
W każdym innym przypadku podejście to generuje problemy. Makiety powstają w oderwaniu od technologii. Projektanci mogą nie być świadomi ograniczeń technologicznych lub czasu potrzebnego na development zaprojektowanych funkcjonalności, a deweloperzy są sfrustrowani. Często brakuje im w zespole osoby, która wytłumaczyłaby idee przyświecającą autorowi kiedy to projektował daną funkcjonalność. Nie mogą poprosić o wprowadzenie na makiety zmian wynikających z analizy technicznej, przez co finalnie makiety są bardziej inspiracją niż finalną wersją produktu.
Fazy tworzenia produktu w zgodzie z UX
Skąd wynika twarde i naturalne dzielenie procesu tworzenia produktu cyfrowego na fazy discovery i delivery? Nie mam na to badań, ale mogę posłużyć się moją refleksją. To pokłosie początków branży, gdzie IT mocno wspomagało się współpracą z agencjami digitalowymi w zakresie makiet. Agencja wykonywała fazę discovery - persony, user journey, badania i wreszcie makiety. Następnie cały ten zestaw przekazywany był do firmy obsługującej IT… w ten sposób naturalnie powstał powyższy podział. Model ten jest niestety kontynuowany również w organizacjach, które tworzą działy UX u siebie lub outsourcują usługi IT. Często Business Analyst pracuje z UX podczas fazy discovery, następnie po wykonaniu makiet, UX wyłączany jest z procesu delivery i scrum. Nie uczestniczy w ceremoniach, traci kontakt z produktem, którego jest autorem. To odwrotność tego co charakteryzuje liderów produktów cyfrowych.
Projektując topowy produkt dla marki będącej w top 3 firm farmaceutycznych na świecie mogłem doświadczyć potęgi adaptacji UX do procesu scrum. Po 2 latach od tego projektu nadal uważam, że takie podejście pozwala zmaksymalizować potencjał budżetu poświęcanego zarówno na UX jak i development. Idea ta przyświeca nam teraz wszystkim w Monogo podczas planowania projektów dla naszych klientów.
Jak włączyć UX do procesu scrum w efektywny sposób?
Pierwszym sposobem jest stworzenie dwóch naprzemiennych sprintów - UX oraz Delivery. Prace UX poprzedzają prace developerskie o jeden sprint. Sprinty trwają dwa tygodnie, w połowie sprintu UX następuje weryfikacja makiet. Nanoszone są uwagi zespołu technicznego, product ownera lub dowolnego członka zespołu scrum, ważnego dla danego kontekstu tworzenia produktu. Na końcu sprintu powstaje makieta gotowej funkcjonalności, przekazywana jest ona do implementacji. Można pomyśleć, że przecież w podejściu tym niewiele się zmienia. Również mamy osobny zespół UX oraz dev. To fakt, lecz jest to zalążek podejścia, w którym istnieje część przecięcia się tych dwóch światów. Spotkania Dev + BA + Product Owner + dowolny członek zespołu, w połowie sprintu UX pozwala na zlikwidowanie wielu czynników, które destabilizują proces delivery. Mamy przestrzeń do wyrównania wiedzy o produkcie, poznania genezy oraz propozycji zmian wynikających z natury technicznej lub długiego czasu potrzebnego na implementacje.
Najlepszą jednak formą pokazującą najwyższą dojrzałość organizacji jest dodanie specjalisty UX jako członka zespołu scrum. W tym podejściu zadania UXowe, researchowe oraz developerskie trafiają do jednego backlogu. UX z BA pracują nad backlogiem nieustannie i w zasadzie są głównymi aktorami ceremonii Backlog Refinement. To oni dostarczają uzupełnione user stories zarówno jeśli chodzi o AC oraz makiety gotowych rozwiązań. Jeśli na backlog refinement pojawiają się zmiany/niejasności, to BA oraz UX są odpowiedzialni za dostarczenie tasków w takiej formie, aby mogły być one estymowane oraz następnie ‘brane’ na sprint. Wymiana wiedzy o produkcie oraz wszelka potrzeba zmiany koncepcji jest komunikowana na bieżąco.
Specjalista UX jest dostępny w każdym momencie i dba o zgodność makiety z finalną wersją produktu. W nomenklaturze scrum jest deweloperem, dbającym o increment. Zdecydowanie łatwiej w takim podejściu zagospodarować czas na badania i developować jedynie potwierdzone hipotezy.
Co zyskasz dodając specjalistę UX jako członka zespołu scrum?
Przede wszystkim kluczowa jest możliwość testowania rozwiązania z użytkownikami na różnych etapach projektu. Jednakowo od makiety przez klikalny prototyp po produkt na środowisku testowym. Wszelka potrzeba zmian wynikająca z wywiadów z użytkownikami czy change request przechodzą przez autora rozwiązania. W zasadzie UX jako jedyna osoba w całym zespole jest w stanie przewidzieć konsekwencje wprowadzanych zmian. A wszystko to w szerokim kontekście user journey produktu. Bez takiej osoby produkt weryfikowany jest dopiero w wersji go-live na podstawie badań ilościowych. To duże ryzyko biznesowe.
Budżet przepalony, użytkownicy nie konwertują tak jak powinni. Zdecydowanie tańsze jest dodanie specjalisty UX jako członka zespołu scrum. Specjalista UX w tym modelu może rysować i weryfikować każdą hipotezę, jaką zespół uzna za wartą zweryfikowania. Przeprowadzi wywiady pogłębione, przeanalizuje dane, przygotuje testy A/B i narysuje tyle wersji rozwiązania ile potrzeba. A ostatecznie wybierze tą najlepszą, czy to z perspektywy technologii, czasu developmentu i wreszcie użytkownika.
Będzie prowadził spotkania dotykające tworzenia makiet funkcjonalności. Wyjaśni, dlaczego akurat tak zaprojektował daną funkcjonalność i czy zmiany proponowane przez zespół nie zaburzają procesu w jakimś innym miejscu, o którym zespół może jeszcze nie wiedzieć. Wszystko dlatego, że UX projektuje rozwiązanie do przodu. Może wiedzieć, że ta konkretna funkcja będzie rozwijana w jakimś kierunku, dlatego świadomość wszystkich zaangażowanych w projekt, co do koncepcji autora rozwiązania, jest w tym wypadku niezwykle ważna.
I wreszcie - UX może skupić się na jakości dostarczania coraz lepszej jakości makiet z perspektywy zespołu. Co więcej, określić jakość dostarczanego tzw. incrementu.
Podsumowanie roli UX w procesie Scrum
Dobrze zaprojektowana strona to strona stworzona z myślą o kliencie. Znasz powiedzenie: „Raz, a dobrze"? Bez specjalisty UX i regularnych badań nie jesteś w stanie określić zasadności kierunku, w jakim zmierza projekt. Dodając UX na stałe do procesu scrum oszczędzasz czas zespołu i pieniądze, mając pewność, że realizujesz założone cele. Nie bez powodu liderzy produktów cyfrowych realizują filozofię design thinking it w swoich projektach.
Chcesz zaimplementować UX do swojego procesu scrum w organizacji?
Umów się na niezobowiązującą rozmowę. Zachęcam do kontaktu.