#3 Design jako jedyne źródło prawdy – Design w Scrumie: 7 grzechów głównych

1. Wstęp
2. Co daje tworzenie szczegółowych makiet hi-fidelity?
3. Makieta jako jedyne źródło prawdy: minusy
4. Kiedy warto stosować makiety hi-fidelity?
5. W jaki sposób zastąpić tworzenie makiet hi-fidelity?
6. Takeaways

1. Wstęp

W wielu Zespołach zwinnych nadal obowiązuje model pracy, gdzie stworzenie makiet hi-fidelity jest koniecznym krokiem przed rozpoczęciem implementacji nowych rozwiązań.

Czy jest to model zgodny z duchem Agile? Czy makieta musi powstać, aby programiści mogli rozpocząć swoją pracę? Tradycyjna odpowiedź brzmi: to zależy! Od czego? Odpowiedź na te pytanie znajdziesz poniżej.

2. Co daje tworzenie szczegółowych makiet hi-fidelity?

Korzenie myślenia o makiecie, jako podstawie do prac programistycznych sięgają podejścia kaskadowego. Ukoronowaniem fazy designu jest w nim zaakceptowany przez przedstawicieli biznesu, szczegółowy projekt interfejsu obrazujący ostateczne UI produktu.

Tworzenie szczegółowych makiet może mieć duży sens, także w pracy zespołów zwinnych. Dzięki projektom hi-fidelity:

• mamy pewność, że zarówno zespół jak i interesariusze rozumieją planowane rozwiązania dokładnie w ten sam sposób
• możemy bardziej precyzyjnie wyestymować czasochłonności prac programistycznych
• makiety możemy poddać weryfikacji ze strony zewnętrznych zespołów (np. prawników)
• a także wykorzystać je, aby przetestować słuszność rozwiązań jeszcze przed ich implementacją

Problem polega na tym, że pracując w z wykorzystaniem frameworków zwinnych zbyt często powielamy znany z kaskady schemat wymagania – design – akceptacja – implementacja, gdzie nadal projekt UI traktowany jest jako etap obowiązkowy, źródło prawdy, bez którego niemożliwe jest rozpoczęcie prac nad kodem. 

3. Makieta jako jedyne źródło prawdy: minusy

Traktowanie makiety jako jedynego źródła prawdy, bez którego nie jest możliwa implementacja rozwiązań ogranicza elastyczność zespołów deweloperskich. Może też prowadzić do niepożądanych, z perspektywy zwinnej, sytuacji.  

Wprowadzanie zmian, będące podstawą podejścia zwinnego, jest trudniejsze i czasochłonne. 

Jeśli makiety traktujemy jak Świętą Księgę, a każda najmniejsza zmiana koncepcji musi być wprowadzona w projekty (a często też zaakceptowana przez przedstawicieli biznesu), to możemy być pewni, że start implementacji zostanie opóźniony.

Stres związany z niedomykaniem zadań na czas może pociągnąć za sobą niechęć Zespołu do sugerowania nowych, lepszych rozwiązań. W efekcie jedna z głównych wartości, którą znamy z Manifestu Agile, czyli reagowanie na zmiany ponad realizację założonego planu zostaje zachwiana.

Pomysły na rozwiązania generowane są jedynie przez Designerów, bez cennej perspektywy technicznej

Korzystanie z makiet i prototypów jako głównego fundamentu dla pracy deweloperów może wpłynąć na „rozleniwienie” Zespołu. Skoro i tak jako deweloperzy nie możemy zrobić nic bez przypieczętowania pomysłów makietą to może niech każdy zajmie się tym co potrafi najlepiej: designerzy generowaniem pomysłów i projektowaniem interfejsów, a programiści kodowaniem.

Z takiego podziału krótka już droga do znanej z kaskady pracy w silosach i tworzenia rozwiązań jedynie przez projektantów. Takie podejście zawęża w znaczący sposób możliwości rozwoju produktu, a rolę dewelopera sprowadza do „klepacza kodu”.

Istnieje ryzyko, że pracując w oparciu o Scruma tak naprawdę nadal uprawiamy nieefektywną kaskadę

Jeśli pracujemy w Zespole gdzie implementację rozwiązań zawsze musi poprzedzić stworzenie projektu hi-fidelity, po którym następuje oficjalny hand-off gotowych rozwiązań do programistów, to możliwe, że wcale nie pracujemy w zwinnym Scrumie, a wpadliśmy pułapkę fazy designu i tzw. Water-Scrum-Falla.

Wariacji na temat takiego modelu jest kilka:

• zakłada znaną z kaskady kilkutygodniową (lub nawet kilkumiesięczną!) pracę zespołu designerów nad UX i UI produktu. Makiety i prototypy są iterowane, a  po uzyskaniu akceptu ze strony biznesu trafiają do zespołu deweloperów gdzie zaczyna się praca w Scrumie

• w innym, pozornie zwinnym modelu 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.

Modeli jest więcej, ale wszystkie brzmią jak kaskada i prowadzą do znanych z kaskady problemów takich jak wolniejsze tempo prac czy wspomniana już mniejsza elastyczność Zespołu i utrudnione wprowadzanie zmian w trakcie implementacji.

4.Kiedy warto stosować makiety hi-fidelity?

Jak mam nadzieję zauważyliście, nie chcę demonizować tworzenia szczegółowych projektów UI w podejściu zwinnym. Makiety hi-fidelity są tu nadal bardzo przydatnym narzędziem, ale powinniśmy korzystać z nich w umiejętny sposób.

W jakich sytuacjach stosować makiety hi-fidelity?

1. Korzystaj z makiet hi-fi dla potwierdzenia, że cały zespół rozumie planowane rozwiązania w ten sam sposób. W tym przypadku pracę nad makietami powinna poprzedzać dyskusja, w której będzie uczestniczył cały Zespół. Dzięki temu finalne rozwiązania będą czerpać z doświadczenia i wiedzy wszystkich jego członków.
2. Makiety hi-fidelity wykorzystuj jako punkt wyjścia do dyskusji. Bywają sytuacje, w których rozwiązania nad którymi pracujemy są zupełnie nowe, albo są tak skomplikowane i dotykają tak abstrakcyjnych problemów, że bez graficznego projektu interfejsu trudno jest w ogóle rozpocząć dyskusję z Zespołem czy biznesem. Wystarczającym punktem startowym mogą być szkicowe wireframy, ale czasem potrzebujemy czegoś bardziej namacalnego – wtedy makieta hi-fi (którą poddamy później iteracjom) jest dobrym rozwiązaniem.
3. Makiety hi-fi są świetne w testowaniu założeń. Mogą być wykorzystane w testach użyteczności, a także w eksperymentach na etapie Product Discovery. Wykorzystanie makiet hi-fi będzie tańsze niż zaimplementowanie modułu i poddanie go testom, ale ze względu na ograniczoną interaktywność może też dać mniej wiarygodne rezultaty.
4. Korzystaj z makiet hi-fi jeśli potrzebujesz weryfikacji rozwiązań od strony prawnej. W niektórych branżach na ostateczny kształt produktu duży wpływ mają przepisy prawne. W takim wypadku wykorzystanie makiet, które zweryfikuje np. zespół prawników będzie bezpieczniejsze niż sprawdzanie czy rozwiązania są zgodne z przepisami już „na produkcji”.

5.W jaki sposób zastąpić tworzenie makiet hi-fidelity?

Pamiętajmy o tym, że powyższe przypadki zwykle nie obejmują pracy nad wszystkimi modułami naszego produktu. Nie zawsze więc projekt hi-fi musi powstać. Jak możemy go zastąpić?

1. Zaaranżujmy dyskusję na temat rozwiązań, w której weźmie udział cały Zespół (np. w ramach refinementu). Spróbujmy opisać planowane wdrożenia czy zmiany słowami, skorzystajmy ze szkiców lo-fi, które będą rysować nie tylko designerzy, ale też inni członkowie Zespołu. Ten sposób sprawdza się szczególnie przy produktach, które mają za sobą już kilka pierwszych sprintów i już wiemy „czym to się to je”.
2. Skorzystajmy z makiet lo-fidelity. Czasem mogą być one bardzo schematycznym szkicem powstałym np. podczas wspomnianego wyżej spotkania, czasem są owocem pracy projektanta. W obu przypadkach stworzenie projektu lo-fi jest zdecydowanie szybsze niż praca nad makietą hi-fi. Jednocześnie wireframy pozwalają w większym niż dyskusja stopniu zweryfikować czy cały zespół oraz ewentualni interesariusze dobrze się rozumieją.
3. Przeprowadźmy UX Review zaimplementowanych rozwiązań. Jeśli po wspomnianej w pierwszym punkcie dyskusji od razu następuje implementacja, warto, aby po wdrożeniu rozwiązań Designer sprawdził czy odzwierciedlają one założenia z dyskusji i są spójne z obowiązującym UX produktu. Wynikiem UX Review mogą być sugestie ewentualnych ulepszeń.

6.Takeaways

Co warto zapamiętać?

• Projekt hi-fidelity nie jest konieczny do rozpoczęcia pracy nad implementacją planowanych rozwiązań
• Istnieją sytuacje, kiedy makieta hi-fi jest przydatnym narzędziem, jednak zwykle nie obejmują one całego zakresu prac nad produktem
• Wykorzystywanie makiet hi-fi jako jedynego źródła prawdy może wpędzić nasz Zespół w modele pracy niebezpiecznie zbliżone do podejścia kaskadowego
• Wykorzystywanie makiet hi-fi jako jedynego źródła prawdy może ograniczyć wpływ programistów na kształt produktu i w znaczący sposób zawęzić możliwości jego rozwoju
• Makietę hi-fi często może zastąpić dyskusja, naszkicowanie rozwiązań w postaci makiet lo-fi, a także UX Review