O odwadze, kiedy trzeba powiedzieć "nie"

Najważniejszą rzeczą w wyprawie jest doprowadzenie jej do końca.

Chingis Chan

Czy przytoczony powyżej cytat jest prawdziwy? Spróbujmy przenieść go na grunt projektów IT. W tej sytuacji naszą wyprawą będzie najbliższe wydanie nowej wersji dla klientów, tak zwane wyjście na produkcję. Z pewnością każdy z nas miał okazję brać udział w niejednym takim wydaniu. Najlepsze są te wydania wykonane w piątek, no koniec tygodnia pracy, nieprawdaż ;)?

Niemniej jednak, każdy projekt w trakcie swojego trwania ma zaplanowane wydania. W zależności od tego co wykonujemy może to być nowa wersja już istniejącego systemu, aktualizacja z powodu znalezionych błędów lub po prostu pierwsze wydanie naszej aplikacji, produktu. Tak czy inaczej musi zostać to zaplanowane z dużym wyprzedzeniem tak, abyśmy mogli się do tego odpowiednio przygotować. W takim razie co należy zrobić?

 Ważne jest nie samo osiągnięcie wierzchołka, lecz droga do niego. - Joe Tasker

W pierwszej kolejności musimy ustalić zakres funkcjonalności, jakie będziemy chcieli wydać dla użytkowników końcowych. Jedną z metod do ustalenia tego zakresu jest zbudowanie tzw. MVP. Czym jest MVP i jak je zrealizować dla najbliższego wydania zostało opisane na firmowym blogu The Software House i można przeczytać tutaj. No dobrze mamy już zbudowane MVP oraz oczywiście wyznaczony termin jego dostarczenia dla użytkowników końcowych. Wszyscy, Product Owner oraz zespół deweloperski, zgodzili się na zakres, więc teraz jest czas, aby przejść do jego realizacji. Pracując w Scrumie dzielimy sobie ustalony zakres prac na poszczególne Sprinty i krok po krok realizujemy kolejne klocki z tej układanki. Prace trwają, pięknie dowozimy kolejne Sprinty, idzie nam jak po maśle, gładko i bez przeszkód….STOP! Tak może jest w idealnym świecie, ale idealnym świecie niestety nie żyjemy. Nie wiem jak wy, ale w moim dotychczasowym zawodowym życiu nie zdarzyło się, aby udało się dowieźć wszystko bez przeszkód. Zawsze coś nagle wpadnie do zakresu prac lub w trakcie trwania prac odkryjemy, że jednak tak jak myśleliśmy na początku to tego nie da się w ten sposób zrealizować. Oczywiście zdarzają się też skrajne sytuacje, gdy nagle nasza koleżanka lub kolega z zespołu chorują i ich zakres prac nie postępuje tak, jak sobie to zakładaliśmy. I co wtedy zrobić? Dostarczyć za wszelką cenę wszystko to na co się umówiliśmy? Czy może jednak powinniśmy coś zmodyfikować? 

Zatrzymajmy się na chwilę. Zastanówmy się w pierwszej kolejności nad celem projektu. W każdym przypadku mamy do realizacji jakąś potrzebę. Jest to bardzo istotne w trakcie budowania zakresu prac oraz jego realizacji. W trakcie procesu budowania MVP pytanie odnośnie w jaki najprostszy sposób możemy zaspokoić potrzebę naszych użytkowników końcowych powinno paść wielokrotnie. To w pewien sposób pozwala nam zastanowienie się, które funkcjonalności są tzw. must have. Niemniej jednak równie istotne jest dostarczenie odpowiedniej jakości produktu. I tutaj bardzo istotną rolę odgrywa Business Analyst jak i również Quality Assurance. Pracując ramię w ramię są oni odpowiedzialni za dostarczenie zadowalającej jakości produktu do klienta. Głównym zadaniem jest:

• Ensures business needs are met and any solutions satisfy those needs

• Ensures the end product or service meets the stakeholders' needs

Zadanie te mają swój początek już od początku trwania projektu, a w szczególności od powstawania pierwszych wymagań. QA i BA powinni zadbać aby każde realizowane zadanie odpowiadało na potrzeby użytkownika, co jest zgodne z nowymi wytycznymi w Scrum Guide. Jeżeli nie miałeś okazji zapoznać się z nową wersją to polecam zajrzeć tutaj -> Scrum Guide 2020. Następnie już w trakcie trwania prac deweloperskich oboje powinni brać czynny udział w kontrolowaniu, czy zadania są realizowane z wytycznymi zawartymi między innymi w Acceptance Criteria danego zadania. Oprócz sprawdzenia poprawności zrealizowania zadania należy sprawdzić czy to zadanie działa w szerszym kontekście i wpisuje się w całościową wizję realizację projektu. Jest to bardzo odpowiedzialne zadanie i niejednokrotnie będziemy się mierzyć z presją, nie tylko zespołu ale również przedstawicieli klienta, aby pozytywnie zakończyć naszą pracę. Jednak warto pamiętać o słowach Winstona Churchilla:

Masz wrogów? To dobrze. To znaczy, że broniłeś czegoś w ciągu swojego życia. 

Należy pamiętać jaka jest nasza najważniejsza rola w danym projekcie - mamy dostarczyć wysokiej jakości produkt oraz taki, który będzie odpowiadał na potrzeby naszych użytkowników. Czemu jest to tak istotne? W dzisiejszym świecie istnieje ostra konkurencja i nie możemy sobie pozwolić na wpadki wizerunkowe. Użytkownicy końcowi jak i my sami ulegamy tzw. pierwszemu wrażeniu podczas kontaktu z nową aplikacją, system czy produktem. Jest to bardzo wrażliwy moment styku na linii użytkownik - nasz produkt. Jeżeli odzew nie będzie pozytywny to niestety możemy stracić naszych odbiorców na zawsze. Oczywiście inaczej jest, gdy nasz użytkownik końcowy nie ma wyboru i pracuje korzystając z naszej aplikacji, lekko zmuszony do tego. Taki użytkownik z pewnością będzie bardziej podatny na sugestie naszej konkurencji aby wybrać ich rozwiązanie. Jeżeli jesteśmy już znanym graczem na rynku z wypracowaną reputacją, to nawet pojawiające się wpadki udaje się obronić na naszą korzyść. Ostatni świeży przykład z pewną grą ;) pokazuje, że pomimo wielu negatywnych reakcji naszych użytkowników można generować rekordowe przychody ze sprzedaży. Podobnym przykładem jest również samolot Dreamliner, który po swojej premierze musiał zostać uziemiony, bo nie wszystko działało jak powinno. Innym przykładem może być również jeden z modeli telefonu Nokii, w którym nie wszystkie przyciski były obsługiwane przez zainstalowane oprogramowanie. Z pewnością każdy z nas może przytoczyć wiele innych podobnych historii. Niemniej jednak nie każdy może sobie pozwolić na takie wpadki i dlatego tak ważne jest wsłuchiwanie się w głos płynący od QA i BA. Dlatego Drogie Koleżanki i Koledzy miejcie odwagę zablokować wydanie, gdy widzicie, że coś nie funkcjonuje tak jak powinno! Z drugiej strony Drodzy Klienci, Product Ownerzy i Project Manager nie denerwujcie się, gdy nie dajemy zielonego światła na wydanie. Robimy to tylko w trosce o Wasze interesy i zadowolenie Waszych użytkowników, aby nasz wspólny cel został zrealizowany. Pamiętajcie również o tym, że:

Charakter człowieka wyraża się nie tylko w odważnym decydowaniu na atak, ale także w umiejętności rezygnowania - Ludwig Purtscheller