Pivot-pivot-pivot! Zarządzanie często zmieniającymi się wymaganiami

27 października
Anna Dombrovskaya
Pivot-pivot-pivot! Zarządzanie często zmieniającymi się wymaganiami
Nikt z nas nie lubi zmian. Ale to zespół programistów lubi je najmniej, zwłaszcza jeśli chodzi o nowe wymagania dla zadań już podjętych w sprincie, a tym bardziej - wykonane. W moim ostatnim projekcie była ich wystarczająca ilość, napisałam ten artykuł na podstawie wyników jego retrospektywy. Dlatego w pewnym stopniu można to nazwać korektą błędów, a nawet podręcznikiem dla tych, którzy będą zarządzać wymaganiami w „szybko zmieniającym się środowisku”.

Kiedy dostałam się do projektu, byłam zachwycona: czysty Agile, kontrakt T&M, ustalone są tylko warunki i skład zespołu i można bawić się zakresami projektu. Nie było zakresu jako takiego: był pomysł, makiety, przybliżona wizja i termin. Tutaj ukryty był haczyk: MVP (w naszym przypadku MLP - Minimal Lovable Product) musiał zostać wykonany w ciągu trzech miesięcy, zaczynając od dziś. Brak pomysłu na to, co dokładnie oferujemy użytkownikowi jako MLP, od razu poddał w wątpliwość termin dla całego zespołu.

Tak więc projekt ruszył 1 czerwca: ścieżka UX i ścieżka programistyczna ruszyły w tym samym czasie. Na etapie renderowania User Flow okazało się, że jeden z głównych przepływów nie ma żadnej wartości dla użytkownika, dlatego wykonaliśmy pierwszy pivot. Wymyślone przez nas procesy rejestracji i logowania nie były obsługiwane przez gotowe rozwiązanie, więc dokonaliśmy drugiego przeglądu. Rozpoczęliśmy prace od makiet, ponieważ project kit został nakreślony przez zewnętrzną agencję zajmującą się rozwojem marki produktu, a nie chcieliśmy na nich polegać.

Zespół zaczął mieć wątpliwości. To był koniec pierwszego miesiąca z trzech, ale nie ustaliliśmy jeszcze celów sprintów - nie było nawet przybliżonego podziału zakresu projektu na sprinty przed pierwszym wydaniem. Udało się zdefiniować zakres, ale słowo „pivot” rozbrzmiewało w naszym projekcie częściej niż w odcinku „Friends”, w którym Ross Geller ciągnął kanapę po schodach.

gif pivot

Następnie klient podesłał nam konsultanta UX, który zdecydował się wprowadzić zmiany w prawie każdym ekranie. Lockdown dopadł ich gdzieś w Azji, a zespół klienta był rozproszony we wszystkich strefach czasowych Stanów Zjednoczonych - od oceanu po ocean - jako część naszego zespołu ds. Produktu. Dlatego pod koniec drugiego miesiąca mieliśmy dwie wersje makiet w Invision do dyskusji z klientem na temat UX (była też trzecia z projektami), wireframe'y w Zeplinie dla każdego sprintu dla programistów oraz makiety wstawione do specyfikacje w Confluence. Cały ten obraz był losowo aktualizowany z różnych stref czasowych, dlatego po zamknięciu historii wieczorem, rano można było znaleźć jeszcze kilka nowych zmian w wymaganiach i projektach.

Było wiele innych niuansów: zespół operacyjny ciągle wprowadzał poprawki i sugestie (szczególnie dotyczące tekstów), integracja z Salesforce w ogóle się nie rozpoczęła ze względu na wybraną architekturę synchronizacji kont, a zarząd postanowił ponownie przejrzeć koncepcję migracji istniejących treści SEO do nową witrynę i zmienił architekturę w ostatniej chwili. W pewnym momencie stało się jasne, że zakres projektu musi zostać bezlitośnie przycięty, w przeciwnym razie nie bylibyśmy w stanie nic zrobić. Już napisane i zatwierdzone wymagania musiały zostać podzielone.

Pivot-pivot-pivot!

Ostatecznie termin został przesunięty z 1 września na 21 sierpnia, ale udało się. Jednak tylko dzięki zaangażowanej pracy zespołu i chęci klienta do poszerzenia zakresu projektu.

Krótko mówiąc, wyciągnęłam wnioski z całej tej historii. Sformułowałam więc punkty, które następnym razem będą mogły nieco ułatwić życie zespołowi programistów i testerów.

1. Jak najwcześniej zapisz zakres i cele każdego sprintu wydania

Nawet działasz w czystym Agile, nawet jeśli nic nie rozumiesz, nadal zapisuj cele każdego sprintu dla całej skali wydania. Spisany zakres pozwala zrozumieć, na ile jest ambitny. Pomaga zespołowi i klientowi (a co najważniejsze - najwyższemu kierownictwu klienta) w równym stopniu ocenić, jak daleko zaszliśmy, a analitykowi biznesowemu, project managerowi i product ownerowi wyskalować, upewnić się, że wszystko jest objęte wymaganiami, śledzić etapy wdrażania funkcji i wcześniej dać sobie sprawę, że niektóre z nich powinny być usunięte. Im szybciej zaczniesz koordynować tę decyzję z kierownictwem, tym lepiej, a spójny tekst będzie łatwiejszy do zrozumienia niż niejasne obawy wyrażone słowami. To, że zakres się zmieni jest normalne. Najważniejsze: nie zapomnij zaktualizować odpowiedniego dokumentu.

2. Bądź zawsze w kontakcie

Idź na wszystkie spotkania UX z klientem i bez niego. Poproś o włączenie cię do wszystkich dyskusji na temat wymagań, treści, strategii, a nawet szczegółów architektonicznych. Jeśli roszczenia są zbierane przez zespół pracujący on-site, na przykład w USA, rozpocznij regularne spotkania telefoniczne stałej porze i proś o aktualizacje. Śledź wszystkie komentarze w Invision i dodaj swój komentarz, gdy zauważysz, że zmiany nie pasują do wizji twojej, programistów lub są sprzeczne z zadaniami wykonanymi wcześniej. Gdy tylko tracisz kontekst, przestajesz być pomocny dla zespołu - w takim razie kogo powinni zapytać, jak powinno być? Dodatkowo można przegapić ważną zmianę w wymaganiach (mój telefon zadzwonił podczas późnego spotkania, więc musiałem pominąć pięć minut dyskusji - w efekcie błędne wymagania zostały prawie dołączone do sprintu) lub nie ostrzec klienta i zespołu UX, jeśli nie możemy spełnić ich życzeń z powodu ograniczeń w rozwoju.

3. Utwórz listę poprawek i edycji

Utwórz listę kontrolną i zapisz każdy nowy projekt i zmianę wymagań, które usłyszysz od klienta i zespołu lub pomyśl o sobie. Listę tę mam zawsze pod ręką w zeszycie, bo lubię ręcznie wykreślać wykonane zadania. Mówią, że powoduje to tak samo szybkie uwalnianie endorfin jak spożycie alkoholu (ale to efektywna i produktywna praca przyczynia się do zdrowego stylu życia). Kiedy pojechałam na wakacje, zespół trochę się sfrustrował i stworzył podobną listę w Confluence. Bardzo pomogło mi to później odnaleźć się w procesie.

4. Użyj matrycy Eisenhowera, jeśli jest zbyt wiele edycji

Pamiętasz podstawy zarządzania czasem , mówię o ważnych i pilnych sprawach? Dla siebie trochę przeformatowałam nazewnictwo: zmiany dzielą się na „drobne” i „ważne/pilne”. Jeśli jest ich dużo, zawsze możesz o czymś zapomnieć lub nie mieć czasu na wyjaśnienia.

Najpierw należy zatem wykonać drobne i pilne edycje (zadanie jest już w sprincie), a dopiero potem duże i pilne. Możesz omówić je z zespołami programistów i QA: być może niektóre pozostaną ważne, ale nie będą tak pilne. Przed upływem terminu nie sugerowałam developerowi, że zadanie, nad którym pracuje, może zostać wyrzucone z zakresu projektu. A potem zarzucałam sobie, że tracili cenny czas przed wydaniem na funkcjonalności, których nikt nie potrzebował.

Z drobnymi zmianami, które nie są pilne można sobie poradzić przy okazji, ale możesz zapomnieć o dużych, nieistotnych zmianach - zanim do nich dojdziesz, będą one już wyrzucone z zakresu obecnego wydania.

5. Podziel historie użytkowników tak bardzo, jak to możliwe

To był mój błąd. User stories przeciągały się ze sprintu do sprintu, wymagania były na bieżąco korygowane, a potem część z nich trzeba było podzielić, decydując się na rezygnację z jakiejś funkcjonalności. Drobne user stories (w stylu „Chcę mieć na pulpicie ikonę do aktywacji użytkownika jednym kliknięciem i aby użytkownik otrzymał wiadomość e-mail po aktywacji”) zapewniają klientowi większą przejrzystość postępów i ułatwiają wyrzucanie tego typu wymagań z zakresu, by przetestować funkcjonalność bez niego.

6. Stwórz jedno źródło prawdy

Napisałem już, ile wersji wireframe'ów i designów było w naszym projekcie, w Invision nie mieliśmy North Star Vision 1.0. Był stale aktualizowany, gdy zdecydowali się wyrzucić coś poza zakres projektu lub wręcz przeciwnie, dodać tam nowe funkcje. Nawiasem mówiąc, jeśli chcesz coś dodać do zakresu, MUSISZ najpierw omówić to z zespołem. Czasami może się okazać, że krytyczne funkcje nie są takie trudne do wdrożenia. I lepiej zapytać/przeczytać z wyprzedzeniem o możliwościach użycia jakichkolwiek komponentów out-of-the-box. Następnie wszelkie próby przedyskutowania przez klienta opcji dostosowania mogą zostać zastopowane od razu.

7. Nie przechowuj wymagań zadań z Jiry w Confluence. Niestety, to nie działa!

Z natury jestem leniwa, więc nie lubię edytować wymagań w kilku miejscach jednocześnie. Uwielbiam opisywać historię w Confluence, ale w Jira wystarczy dodać link do wybranej strony. Ale jeśli wymagania często się zmieniają, to podejście jest skazane na porażkę. Wyobraź sobie, że przygotowałeś historię opisującą rozwój funkcji dla wireframe'ów, programiści zapisali je i logikę, ale potem pojawiły się designy. Co zrobić? Nie możesz aktualizować stron w Confluence, są one symulowane i oczekują na testy. Może stworzyć nową wersję wymagań? Ale wtedy Confluence będzie zaśmiecone nieistotnymi wymaganiami.

Ostatecznie zespół zdecydował, że nadal będziemy aktualizować wymagania w Confluence, ale w Jira zaczniemy tworzyć konkretne małe historie (pamiętaj, że trzeba je jak najbardziej rozdzielić) z osobnym opisem, naprawionym linkiem do ekranu w Zeplinie (a nie w Invision, który jest na bieżąco aktualizowany) i link „Jeśli chcesz poznać kontekst zadania - przejdź do Confluence”. Musisz dołączyć zadania funkcjonalne do podzadań konkretnych historii. Ułatwiło nam to uporządkowanie zakresu: jeśli historia została wykluczona z wydania, wszystkie podzadania również i nie zaśmiecały listy zaległości.

8. Używaj Kanban lub najkrótszych możliwych sprintów Scruma

To rada bardziej dla project managerów, ale chcę ją dodać do listy, ponieważ uważam, że analityk biznesowy może i powinien mieć na to wpływ! Załóżmy, że początkowo wybrałeś dwutygodniowe sprinty. Ale za dwa tygodnie wiele może się zmienić w zadaniach, na które zespół nie będzie miał już czasu zareagować. Dla nas cotygodniowe sprinty były zbyt długie, mimo że cotygodniowe przygotowania do sprintu zajmowały dużo czasu.

Kiedyś, gdy termin realizacji projektu został przesunięty z 1 września na 21 sierpnia, po prostu dodaliśmy wszystkie pozostałe zadania do sprintu bez szacunków, aby nie tracić czasu programistów na przygotowania. Wyczyściliśmy tablicę w trakcie i wcale nie wyszło to na dobre ani zespołowi ani klientowi, ponieważ team miał mnóstwo zadań w statusie "to-do" i trudno było zrozumieć, na co mamy czas, a na co nie. W rzeczywistości tablica Scruma zmieniła się w Kanban, dopóki jej nie uporządkowaliśmy.

9. Raz w tygodniu omawiaj zakres z zespołem

Może się to wydawać oczywiste, ale pamiętaj, aby omówić z zespołem zakres na następny tydzień, a także zmiany w North Star Vision. Zadzwoń do PMa, ścieżki UX, wszystkich programistów i QA (tylko nie zapomnij dać wszystkim oprócz leadów wyboru: poświęć czas na rozwój lub weź udział w kolejnym spotkaniu). Możesz więc zidentyfikować wąskie gardła, określić, co zostało wyrzucone poza zakres projektu (programiści na spotkaniach są zanurzeni w kodzie, mogą po prostu pominąć takie informacje). Nawiasem mówiąc, otwórz wszystkie strony z wymaganiami i designami z wyprzedzeniem, aby zapobiec zmianom kontekstu podczas ładowania strony.

10. Ustanów przejrzysty proces zatwierdzania designów i wymagań

Zarządzaj klientem, nie bój się śledzić jego reakcji i poproś o jak najszybsze obejrzenie projektów. Sprawdź dokładnie swoje zmiany i pamiętaj, że klient też może się mylić. Osoby po stronie klienta mogą mieć zadania o wyższym priorytecie, więc nie tylko proponuj opcje, ale także podziel się swoją wizją, na temat tego, który z nich powinien zostać opracowany. Naucz się odmawiać klientowi: jeśli zadanie zostało już zakończone, przedyskutuj z klientem, jak wysoki jest priorytet zmian i czy mogą zaczekać do następnej wersji. Ponadto należy doradzić klientowi, aby jak najszybciej wysłał North Star Vision do swojego najwyższego kierownictwa, a na pewno nie w przeddzień wewnętrznego wydania produktu. W przeciwnym razie poszczególne edycje będą musiały być koordynowane na najwyższym poziomie firmy klienta.

11. Poświęć trochę czasu na edycję tekstu w zakresie sprintu przez interesariuszy

Mówiłam już o ważnych i pilnych zmianach, ale chcę osobno podkreślić zmiany tekstowe. W naszym projekcie klient stawiał ogromny nacisk na prawidłowe pozycjonowanie produktu, dlatego KAŻDE słowo i każdy tekst był dla niego bardzo ważny i mógł zmieniać się wielokrotnie w trakcie sprintu. Na początku zebrałam wszystkie komentarze tekstowe w jednym zadaniu i prosiłam o edytowanie czegoś w każdym sprincie, aż zdałem sobie sprawę, że jest to bez znaczenia. Treść na tych samych stronach zmieniała się z prędkością, jeśli nie światła, to zdecydowanie dźwięku. Wtedy wyjaśniliśmy klientowi, że wszystkie teksty powinny być przeglądane w North Star Prototype i tam również edytowane. Tuż przed wydaniem poprosiliśmy zespół front-endowy o przejrzenie wszystkich ekranów naraz i zaktualizowanie tekstów.

Buddyzm naucza, że jednym z trzech największych cierpień ludzi jest zmiana. Dlatego bądź przygotowany na to, że w projektach takich jak nasz zespół czasami będzie sfrustrowany (nie spodobałoby mi się też, gdyby moja trzydniowa praca nie była nikomu potrzebna). Dlatego pozostań ostoją zespołu! Ze zmianami nie da się walczyć (bo nie da się walczyć z tym, czego nie można zmienić - paradoks, ale w twoim przypadku będą to zmiany). Pozostaje tylko zaakceptować fakt, że rzeczy są nietrwałe. A BA może tylko próbować złagodzić ból związany z tymi zmianami dla zespołu. I po prostu płyń!

one more gif img