Design w duchu Agile – 4 zasady ułatwiające wdrożenie Zwinnego Projektowania

Design w Scrumie

Zwinnego projektowania nie da się wdrożyć w pojedynkę. Nie wystarczy oświadczyć: „Od dzisiaj Design będzie integralną częścią budowania rozwiązań” – bo, po pierwsze, nie istnieje jeden uniwersalny sposób na wdrożenie praktyk zwinnych, a po drugie – aby procesy projektowe działały sprawnie, do nowego podejścia , oprócz projektantów, musi być przekonany cały Zespół Developerski.

Aby procesy projektowe działały sprawnie, do nowego podejścia , oprócz projektantów, musi być przekonany cały Zespół Developerski.

Zaangażowanie całego Zespołu jest ważne ze względu na to, że wspomniane „nowe podejście” to nie tylko sposób w jaki będziemy zarządzać pracą designerów. Konieczne zmiany obejmują również obszary związane z kulturą i organizacją pracy pozostałych specjalistów.

Jeśli chcecie przygotować żyzny grunt pod włączenie Designu w pracę Zespołów zwinnych w Waszych procesach (i głowach!) musi dokonać się kilka podstawowych zmian. Zasady, które znajdziecie poniżej czerpią garściami z podejścia leanowego, są jego syntezą i moim subiektywnym must have w tym temacie.

Inwestujcie czas w lepszą komunikację, a nie dokumentację

Oczywiście, dobre udokumentowanie rezultatów naszej pracy (niezależnie od specjalizacji) jest ważne, ale nawet najlepsza dokumentacja nie zastąpi bezpośredniej komunikacji między członkami Zespołu.

Podejście zwinne zakłada rozbicie silosów i pracę w zespołach cross-kompetencyjnych. User Experience czy wizualne rozwiąznia UI nie są już domeną tylko i wyłącznie UX/UI czy Product Designerów. Oczywiście projektanci pozostają do pewnego stopnia odpowiedzialni za efekty pracy, ale podejmując ostateczne decyzje projektowe powinni czerpać z wiedzy i umiejętności innych specjalistów.

Dodatkowo, jak już wspominałam w jednym ze wcześniejszych artykułów, rola designera w Zespole Zwinnym nie ogranicza się do tworzenia makiet i przekazywania ich do implementacji. Zadania mogą dodatkowo obejmować analizę danych, przeprowadzanie badań, facylitację warsztatów projektowych, a także inicjowanie i moderowanie dyskusji na temat potencjalnych rozwiązań.

Wszystkie te działania wymagają dobrej komunikacji, która nie może być jednostronna. Do współpracy konieczny jest dialog. Co możecie zrobić, aby przygotować się na wdrożenie prac projektowych we flow pracy Zespołu?

Ćwiczcie dawanie i odbieranie feedbacku.

Feedback stał się w ostatnich latach modnym buzzwordem co, w pewnym stopniu sprawiło, że zaczęliśmy go bagatelizować. Tymczasem nadal, mimo, że wszyscy o nim mówią, niewiele zespołów posługuje się informacją zwrotną w dojrzały sposób.

Feedback stał się w ostatnich latach modnym buzzwordem - mimo, że wszyscy o nim mówią, to nadal niewiele zespołów posługuje się informacją zwrotną w dojrzały sposób.

Dzięki konstruktywnym, prawidłowo zbudowanym komunikatom na temat zachowania, działania czy postępowania innych członków Zespołu możemy szybko eliminować błędy, motywować się wzajemnie do działania, budować zaufanie, a przez to pracować efektywniej.

Warto więc odkurzyć wiedzę na temat przekazywania feedbacku – z pomocą mogą przyjść materiały od Management 3.0, które w bardzo przystępny sposób przytaczają podstawowe zasady dawania i odbierania informacji zwrotnej.

 

Zapoznajcie się z NVC (ang. Non Violent Comunication).

Porozumienie Bez Przemocy to sposób komunikacji opracowany przez Marshalla Rosenberga, który pozwala na ograniczenie możliwości wystąpienia przemocy w dialogu w jakiejkolwiek formie, psychicznej lub fizycznej. NVC skupia się na formułowaniu komunikatów pozbawionych etykietowania siebie i innych, oceniania tego, co zostało powiedziane czy zrobione, a wagę przenosi na uczucia i potrzeby obu stron.

Dzięki temu podejściu jesteśmy w stanie wspólnie wypracować rozwiązania uwzględniające perspektywę obu stron, z zachowaniem dobrej atmosfery w Zespole. Więcej o Porozumieniu Bez Przemocy znajdziecie w publikacji Rosenberga o tym samym tytule. Przydatne nie tylko w życiu zawodowym!

Doskonalcie aktywne słuchanie.

Aktywne słuchanie oznacza to nie tylko całkowite zaangażowanie i skupienie na rozmowie, ale także zadawanie pytań i uważne słuchanie odpowiedzi.  Dodatkowo ważna jest obserwacja mowy ciała rozmówcy, parafrazowanie jego wypowiedzi oraz dawanie przestrzeni do wyrażenia opinii (czasem po prostu milknąc na chwilę). Aktywne słuchanie to umiejętność niezastąpiona podczas zespołowych refinementów i retrospektyw, która pozwala na poszerzenie naszych horyzontów i otwarcie się na pomysły innych członków Zespołu.

Każdy ma prawo głosu – współprojektowanie to podstawa

Podejście Lean UX zakłada, że zespół developerski zorientowany jest problemowo.

Jak w swojej publikacji na temat Lean UX pisze J.Gothelf: Zespół zorientowany problemowo to taki, któremu dano do rozwiązania problem biznesowy, a nie zestaw funkcji do implementacji. Inaczej mówiąc, jest to zespół skoncentrowany na wyniku.

Trudno o tego typu zorientowanie, jeśli do tworzenia rozwiązań dopuszczani są tylko niektórzy z członków zespołu. Monopol na opracowywanie UX i UI produktu w podejściu zwinnym nie należy już tylko do projektantów czy współpracujących z nimi Product Ownerów / Managerów.

Jeśli więc do tej pory jako projekant_ka pracowałeś_łaś w pojedynkę, dostarczając programistom gotowych do implementacji  rozwiązań – czas na zmianę! W jaki sposób?

  • Otwórz się  na ścisłą współpracę z programistami zanim usiądziesz do tworzenia szczegółowych makiet.
  • Włączaj ich w dyskusje na temat planowanych rozwiązań, w tym tworzenie flow użytkowników, czy szkicowanie ekranów.
  • Zachęcaj do dzielenia się pomysłami na rozwiązania problemów biznesowych, z którymi się mierzycie.
  • Zadbaj o to, aby decyzje podejmować demokratycznie opierając się o perspektywę nie tylko Zespołu Developerskiego, ale także interesariuszy takich jak biznes czy użytkownicy końcowi.

Z pomocą w aktywizacji pozostałych specjalistów może przyjść przeprowadzenie warsztatów projektowych, ale czasem wystarczy po prostu stworzyć przestrzeń do dyskusji np. podczas spotkań typu refinement.

Otwórzcie się na zmiany, adaptacje i… błędy

Pomimo, że adaptacja i iteratywność są przez Scrum Guide wymieniane jako jedne z podstawowych składowych teorii Scruma, Zespoły nadal żywią dużą niechęć do wprowadzania zmian w raz wytworzone rozwiązania.

Pomimo, że adaptacja i iteratywność sto jedne z podstawowych składowych teorii Scruma, Zespoły nadal żywią dużą niechęć do wprowadzania zmian w raz wytworzone rozwiązania.

Jest to w dużej mierze pokłosie nastawienia, które obowiązywało jeszcze podejściu kaskadowym. Odgórne projektowanie interfejsów, miało za zadanie przygotowanie najlepszych możliwych rozwiązań i zniwelowanie do minimum kosztownych zmian na etapie ich implementacji. Czas pokazał jednak, że w rzeczywistości tworzyliśmy produkty, które po zetknięciu z realnym użytkownikiem okazywały się być nietrafione. Zmiany były więc ostatecznie i tak nieuniknione.

O ile w kaskadzie problemy odkrywaliśmy po kosztownej, wielomiesięcznej pracy dziesiątek specjalistów, o tyle frameworki zwinne dają nam możliwość określenia potencjalnych problemów o wiele szybciej. Dodatkowo agile pozwala na tworzenie rozwiązań MVP pozwalających przetestować rentowność danego przedsięwzięcia zanim zainwestujemy w nie kolejne godziny pracy.

Aby więc być gotowymi na wdrażanie Designu w procesy zwinne Zespoły muszą zaakceptować fakt, że zmiana jest wpisana w Agile.

Projekt UI nie musi być dopieszczony do granic możliwości, aby programiści zaczęli go implementować. Ba, może w ogóle nie istnieć! Raz zaimplementowana funkcjonalność nie jest nietykalnym artefaktem, możemy ją ulepszać, dopracowywać, a czasem… podjąć decyzję o jej usunięciu. Tak, błędne decyzje zdarzają się najlepszym ale, o ile wyciągamy z nich wnioski, pomogą nam unikać podobnych pułapek w przyszłości.

Weryfikacja i mierzalność to podstawy tworzenia produktów

Decyzje projektowe, które będziemy podejmować pracując w Zespołach Zwinnych nie mogą być oparte jedynie o intuicję projektantów, czy innych członków Zespołu.  Pomimo, że często doświadczenie specjalistów opiera się o wiele owocnych realizacji  to… musimy pamiętać, że nie istnieje jeden, uniwersalny przepis na sukces. Decyzje o ostatecznym kształcie implementowanych rozwiązań muszą opierać się o fakty, a nie tylko domysły.

Decyzje o ostatecznym kształcie implementowanych rozwiązań muszą opierać się o fakty, a nie tylko domysły.

Jak upewnić się, że działacie w racjonalny sposób?

Podejmujcie decyzje na podstawie danych. Wdrożenie analityki produktowej jest możliwe na każdym etapie rozwoju produktu. Jeśli działacie na żywym orgazmie, który ma już grono odbiorców, możecie opierać się o analizę ruchu na stronie, czy w aplikacji i związane z nią dane ilościowe. Jeśli produkt, który tworzycie dopiero raczkuje warto poświęcić wiecej czasu na analizę danych jakościowych, które możecie uzyskać np. poprzez Badania UX.

Badanie i odkrywanie powinno być procesem ciągłym. Product Discovery i podejmowanie na jego podstawie decyzji o rozwoju produktu powinno być działaniem stale wpisanym w pracę Zespołu. Nie może ograniczać się do badań potrzeb użytkowników czy eksperymentów jedynie przed rozpoczęciem fazy implementacji. Dzięki ciągłości w prowadzeniu Discovery będziecie na bieżąco w kontakcie z użytkownikami końcowymi i ich środowiskiem, co ułatwi reagowanie na zmieniające się potrzeby grupy docelowej czy szanse, które daje rynek.

Podsumowanie

Włączenie Designu w praktyki zwinne wymaga zmiany nastawienia nie tylko projektantów, ale całych Zespołów Developerskich. Wdrażając zwinne projektowanie warto oprzeć się o zasady czerpiące z metody Lean UX.

  • Komunikacja ponad domumentację
  • Współprojektowanie i demokratyczne podejmowanie decyzji
  • Otwarcie się na zmiany, adaptacje i… błędy
  • Weryfikacja i mierzalność jako podstawa tworzenia produktów

Więcej na temat Lean UX możecie znaleźć we wspomnianej już publikacji J.Gothelfa i J. Seidena Lean UX dla zespołów Agile, a także na blogu Project: People .