#1 Faza Designu – Design w Scrumie: 7 grzechów głównych i jak ich unikać

Design w Scrumie

1.  Wstęp
2. Grzech #1: Faza designu – czy to na pewno Agile?
3. Faza Designu – Problemy
4. Co zrobić, jeśli te problemy istnieją w Twoim zespole?

1.Wstęp

Na temat miejsca designu w świecie Agile od jakiegoś czasu toczy się wiele zaciętych dyskusji. Mimo, że Manifest Agile obchodzi w tym roku 20. urodziny nadal zastanawiamy się m.in.:

  • jaka jest rola projektantów w zwinnym tworzeniu oprogramowania,
  • gdzie przeplata się ona z pracą programistów,
  • a gdzie przenika z rolą Product Ownerów.

Przewodnik po Scrumie nie podaje jak na tacy rozwiązań, w postaci gotowych wzorców i procesów, zachęca raczej do dostosowywania ram działania do kontekstu, w którym obecnie tworzymy. Nieuniknione jest więc działanie metodą prób i błędów, której ryzykiem jest opieranie działań zespołów scrumowych o, tylko pozornie ułatwiające pracę, nieprawidłowe założenia.

Nieuniknione jest działanie metodą prób i błędów, której ryzykiem jest opieranie działań zespołów Scrumowych o nieprawidłowe założenia.

Ten artykuł jest pierwszym z serii, w której postaram się przybliżyć podstawowe błędy jakie popełniamy próbując włączyć Design w Scruma.  Jakie jest więc nasze 7 grzechów głównych?

Zacznijmy od podstaw…

2. Grzech #1: Faza designu – w czym leży problem?

Korzenie myślenia o Designie jako osobnej fazie projektu sięgają podejścia kaskadowego, kiedy to zespół, złożony głównie z projektantów, przez kilka, a nawet kilkanaście tygodni skupiał się na określaniu architektury informacji i ścieżek użytkowników, tworzeniu prototypów low i hi-fidelity, swoją pracę wieńcząc soczystą dokumentacją, potem przekazywaną do implementacji przez zespół developerski.

Mimo, że tak bardzo chcemy być Agile to nadal trudno nam wyjść z kaskadowych ram myślenia o tworzeniu rozwiązań.

Wiele zespołów wpada w pułapkę fazy designu, bardzo zbliżonej do tej, którą opisałam powyżej. Po jej zakończeniu następuję hand-off gotowych do implementacji ekranów do zespołu developerskiego i dopiero tutaj zaczyna się praca w oparciu o Scruma. Water(scrum)fall w czystej postaci.

Pozornie zwinny proces, gdzie praca w Scrumie zaczyna się dopiero po przekazaniu zespołowi developerskiemu gotowych do implementacji ekranów. Water-scrum-fall w czystej postaci.

W innym, już nieco bardziej zwinnym duchu, projektanci pracują w osobnych sprintach projektowych, które toczą się 2-3 tygodnie przed właściwym, wdrożeniowym sprintem scrumowym. Sprint projektowy, koronowany jest akceptacją ze strony klienta. Dopiero po niej następuje przekazanie prototypów i szczegółowej dokumentacji do zespołu developerów, omówienie zaprojektowanych rozwiązań i praca nad ich implementacją w ramach sprintu właściwego.

Projektanci pracują w osobnych sprintach designerskich, które toczą się 2-3 tygodnie przed właściwym sprintem scrumowym.

Tylko, czy to nie brzmi jak mini-kaskada?

3. Jakie problemy niesie ze sobą kurczowe trzymanie się fazy designu?

Nadal działamy w oparciu o silosy kompetencyjne.

Inni specjaliści zbierają wymagania i tworzą rozwiązania, a inni je później wdrażają.

  • Developerzy nie mają więc możliwości na wniesienie swojej perspektywy w rozwiązania problemów projektowych, które będą później implementować. Stają się, mówiąc brzydko, biernymi klepaczami kodu.
  • Designerzy natomiast tworzą bardzo szczegółowe makiety, pławiąc się w sosie „perspektywy użytkownika”, nie biorąc pod uwagę ani tego, jak czasochłonna i skomplikowana może być implementacja proponowanych przez nich rozwiązań, ani czy proponowane rozwiązania są spójne z celami biznesowymi klienta.
  • Ostatecznie, jako efekt braku komunikacji powstają często produkty-wydmuszki, którym brakuje tak perspektywy biznesowej i technologicznej

Inni specjaliści zbierają wymagania i tworzą rozwiązania, a inni je później wdrażają.

Wprowadzanie zmian jest czasochłonne i kosztowne.

Praca w oparciu o fazę designu, nawet jeśli jest to jej wariacja w formie Sprinu Designerskiego nie pozwala pozbyć się całkowicie głównego problemu, który spędzał nam sen z powiek w podejściu kaskadowym, czyli kosztownych poprawek.

  • Często zdarza się, szczególnie jeśli projekty powstają bez udziału specjalistów technicznych, że podczas implementacji rozwiązań wymagane jest wprowadzenie zmian, a czasem nawet całkowite porzucenie początkowo obranego podejścia.
  • Wymagana jest wtedy iteracja projektów ekranów, ponowne uzyskanie na ich podstawie akceptacji ze strony klienta, zaktualizowanie dokumentacji, a potem hand-off gotowych ekranów do dev teamu.
  • To wszystko kosztuje nasz zespół stracony czas i opóźnienia, które ostatecznie mogą wpływać na roadmapę pracy na produktem.

Projekt jest jedynym źródłem prawdy

Problem designu jako source of truth zasługuje na osobny artykuł, który na pewno powstanie w ramach tej grzesznej serii.

  • Faza designu poprzedzająca implementację często wiąże się, tak jak wspominałam wcześniej, z koniecznością uzyskania akceptacji rozwiązań ze strony klienta przed rozpoczęciem pracy nad ich wdrażaniem. Akceptacja wydawana jest na podstawie prototypów, które ilustrują proponowane rozwiązania. Od tego momentu to właśnie projekt staje się Świętą Księgą, o którą opiera się praca zespołu developerskiego.
  • Zespół, nawet jeśli ma lepszy pomysł na funkcjonalność, którą ma zaraz wdrażać nie próbuje nawet sugerować zmian, bo jest już na nie zwyczajnie za późno – w końcu jesteśmy w fazie implementacji rozwiązań, a nie ich generowania.
  • To z kolei zawęża możliwości rozwoju produktu, a rolę developera ogranicza do wspomnianego już wcześniej klepacza kodu.

4. Co zrobić, jeśli wspomniane wcześniej problemy zauważasz w swoim zespole?

Oczywista odpowiedź, która nasuwa się na to pytanie brzmi: zrezygnuj z odrębnej fazy designu i zadbaj o to, aby praca designerów była realną częścią sprintu scrumowego. To jasne, ważniejsze pytanie brzmi – jak to zrobić?

Nie zawsze nagła zmiana podejścia, o które nasz zespół opiera swoje działanie będzie możliwa. Odejście od myślenia o designie jako fazie, to proces, który wymaga czasu, otwartości ze strony specjalistów oraz osób zarządzających organizacją. Dodatkowo musimy być gotowi na całe morze wzlotów i upadków.

Warto jednak zacząć od podstawowego, małego kroku: Włączaj developerów w dyskusje na temat planowanych rozwiązań.

Odejście od myślenia o designie jako fazie, to proces, który wymaga czasu i zaangażowania ze osób zarządzających organizacją. Dodatkowo musimy być gotowi na całe morze wzlotów i upadków.

Jak włączyć programistów w proces tworzenia rozwiązań?

 

  • Jeśli jesteś projektantem_ką nie ograniczaj tych rozmów tylko do zaprezentowania już narysowanych ekranów i zebrania feedbacku na ich temat.
  • Spotkajcie się i porozmawiajcie ZANIM zaczniesz ubierać wymagania w formę wizualną. Może Cię zdziwić jak wiele świetnych, ux-owych pomysłów mają programiści
  • W takich dyskusjach przyda Wam się whiteboard (lub jego wersja online np. Miro, FigJam, Mural) lub po prostu kartka papieru. Wspólnie rysujcie flowcharty, wireframy, notujcie najważniejsze spostrzeżenia. To będzie Twoja baza do stworzenia bardziej zaawansowanych mockup’ów.
  • Dzięki takim spotkaniom będziecie mogli wcześniej określić potencjalne ryzyka i zapobiec za wczasu czasochłonnym i frustrującym zmianom w fazie implementacji.
  • Dodatkowo zaangażowanie całego zespołu w budowani produktu na pewno wzrośnie, a oparta o nie atmosfera będzie sprzyjać bardziej kreatywnej pracy.

Więcej na temat kooperacyjnej współpracy podczas wczesnych faz pracy nad produktami możesz przeczytać w publikacji o Lean UX autorstwa Jeffa Gothelfa i Josha Seidena

Zainteresował Cię ten artykuł i chcesz otrzymywać więcej materiałów na temat zwinnego projektowania? Zapisz się na mój Newsletter!

Czekają na Ciebie:
? Dawka opiniotwórczych artykułów
? Porcja materiałów edukacyjnych
? Dyskusja dotycząca roli Product Designu w świecie Agile.

Dołączając do odbiorców Newslettera otrzymasz dodatkowo mini poradnik “6 podstawowych zasad pracy Designera w Scrumie.”