„Nie uwierzę, dopóki nie zobaczę” powinno być najczęściej wypowiadanym zdaniem – klamrą spinającą każde nowe wymaganie interesariusza. Projekt nie jest bowiem objawioną opowieścią o dogmatach, których treści nie powinno się kwestionować lub przekształcać. Z kolei interesariusz powołujący projekt do życia nie jest nieomylny, a wena twórcy potrafi być kapryśna.
Ograniczone zaufanie do pewników i ciągła zmiana kierunku rozwoju nie tylko stanowią fundament każdego projektu, ale również definiują genezę Agile – perspektywę metodyk zwinnych. Najtrudniejsze jednak pierwsze zdanie we wstępie… Kto, dlaczego i jak powinien rozpocząć opowieść w karcie projektu?
Agile na marginesie
Zwinne zarządzanie projektami często uwzględnia zwinność na marginesie, ograniczając normę Agile jedynie do pracy zespołu, czyli sprintów. Jednym z powodów jest stygmatyzowanie podejścia Agile’owego jako mody w IT, z kolei innym źródłem nieporozumienia jest brak refleksji o genezie podejścia. Metodyki zwinne nie są pochodną trendów w zarządzaniu, ale służą za lustro, w którym odbija się kondycja środowiska IT na przestrzeni ostatnich dwudziestu lat. Skonkludowano to w 2001 roku w ramach Agile Manifesto.
Agile jest bowiem zbiorem wartości i reguł odnoszących się do kultury pracy całej organizacji, nie tylko zaś do pojedynczego zespołu deweloperskiego. Zdarza się, że zlekceważenie powyższego faktu skutkuje tym, że zarówno zbieranie wymagań dla produktu, jak i budowanie Product Backlogu mają miejsce za zamkniętymi drzwiami, bez zaangażowania zespołu. Jakie są dalsze konsekwencje? Zapośredniczanie oczekiwań i potrzeb klienta oraz oddelegowywanie „specjalistów” do wymienionych zadań nie sprzyjają rozumieniu ani konstruktywnej adopcji metodyk zwinnych.
Na czym polega praktyka zarządzania wymaganiami w projekcie, w którym zespół deweloperski pracuje w Scrumie? Najczęściej realizowana jest poprzez znaczone karty tradycyjnie rozdawane w organizacji. W myśl tego założenia osoby na stanowiskach analityków biznesowych wypełniają zadanie zebrania oraz interpretacji i odpowiedniego sformułowania wymagań biznesowych. Proces potrafi trwać tygodniami lub miesiącami dopóki lista nie będzie składać się z odpowiedniej liczby zadań. Ilość dystansuje jednak jakość, ponieważ kompetencje analizy biznesowej są niewystarczające, żeby uwzględnić całe spektrum wymagań projektowych. Projekt w końcu czas zacząć, zadania zostają przekazane zespołowi a następnie… czas na Scrum? Podejście zwinne nie jest jednak ani osobnym etapem, ani dopiskiem w planie wykonania projektu. Puls zwinności weryfikuje się bowiem uwzględniając przekrój wszystkich aktywności w projekcie.
Ghostwriter* nie tworzy karty projektu
Przekonanie o wartości osobnych ról w organizacji mających wyłączną odpowiedzialność za kontakt z biznesem jest pochodną tayloryzmu. Idea wyspecjalizowanej grupy osób do kierowania i organizacji pracy innych ludzi cały czas odbija się echem, powracając w dwóch słowach: analizy biznesowej.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) przestrzega zarówno przed monopolem ról, jak i przekonaniem o jedynym i niezmiennym zakresie projektu. Tworzenie karty projektu oraz definiowanie zakresu projektu nie są czynnościami skończonymi ani tym bardziej jednorazowymi. Powrót do przyszłości, czyli proaktywna weryfikacja założeń oraz wymagań jest konieczna dla dostarczenia wartości w projekcie.
Jak zadbać o dostarczanie wartości w projekcie? PMBOK przekonuje do konkretnych narzędzi oraz technik, czyli artefaktów uwzględnianych również w Scrumie. PMBOK zwraca także uwagę na to, iż każda technika opiera się na modelu grupowym oraz odpowiednim sposobie prowadzenia spotkań jako bardziej efektywnych i miarodajnych w porównaniu do pojedynczych, wyizolowanych interakcji. Dzięki realizacji poniżej wymienionych wskazówek oraz poprzez dbanie o ciągłe aktualizowanie informacji (inspect and adapt) – wymagania w projekcie tworzą się oraz anulują się regularnie jako wynik proaktywnego feedbacku. Głównym celem podejmowanych kroków jest weryfikacja oczekiwań (interesariusze) oraz gotowość do ich realizacji (zespół deweloperski), który według PMBOK-a może manifestować się poprzez: warsztaty JAD (Joint Application Development), ankiety, wywiady oraz grupy badawcze, burzę mózgów, mapy myśli, obserwacje użytkowników produktu czy kartę projektu.
Co Product Owner miał na myśli?
Język determinuje kulturę – jeden z tropów antropologii kulturowej odnosi się również do środowiska zawodowego. Język komunikacji wpływa na kulturę pracy, co odzwierciedla sposób, w jaki na przykład zespoły deweloperskie porozumiewają się ze stroną biznesową. Najczęściej występuje brak komunikacji poprzedzony nieudanymi próbami wypracowania wspólnego języka: biznes nie rozumie technicznej ekspertyzy oraz nie dzieli się informacjami o wizji produktu, zespół deweloperów zaś nie akceptuje potrzeby przystępnego wytłumaczenia logiki swojej pracy oraz odrzuca kontekst biznesowy. Brak wypracowanego wspólnego języka sprawia, że tracą na tym produkt oraz zespół. Wyznacznikiem udanej komunikacji dwóch stron powinien być bowiem język trzeciej strony – użytkownika danego produktu, czyli user story.
Jaka powinna być komunikacja, żeby realizowała strategiczne założenie projektu o dostarczaniu wartości dla klienta? Scrum wypisuje na to receptę – nawyk codziennego feedbacku oraz regularny dialog z interesariuszami i użytkownikami produktu. Wszystkie artefakty Scruma korespondują ściśle z kryterium powodzenia projektu wyznaczonego przez PMBOK-a.
Poetycki wydźwięk pytania o interpretację Product Backlogu uwzględniający klucz w postaci Product Ownera posiada w swoim zestawie również wytrych – zespół scrumowy. To właśnie zespół podejmuje się interpretacji tego, co Product Owner miał na myśli poprzez realizację spriorytetyzowanych wymagań w Product Backlogu. Bez zaangażowania oraz konstruktywnej współpracy biznesu z R&D projekt grzęźnie na mieliźnie i żadna siła metodologii wodospadu nie jest w stanie zmienić jego położenia.
Fot. Sony PicturesBądź zmianą, którą chcesz widzieć w projekcie
W filmie Arrival sposób wypracowania wspólnej komunikacji polegał na nauce nowego języka, której podjęła się specjalistka lingwistyki w kontakcie z Heptatodami, czyli istotami pozaziemskimi. Poznanie rzeczywistości językowej użytkowników wymagało czasu oraz eksperymentów. Celem była interpretacja intencji przybyszów oraz dowiedzenie się większej ilości szczegółów odnośnie ich przyszłych planów. Proces nauki nowego języka przebiegał jednak w atmosferze strachu oraz ogólnej podejrzliwości odnośnie powodzenia eksperymentu komunikacyjnego. Brak akceptacji dla poświęconego na naukę czasu oraz brak przekonania do wartości wspólnego języka okazał się poważnym zagrożeniem dla wszystkich zaangażowanych stron.
Jak często podobne okoliczności towarzyszą zbieraniu oraz realizacji wymagań w projekcie? Warto przywołać model kooperacji pomiędzy biznesem a developmentem, który wyjątkowo rzadko ewoluuje w model konstruktywnej współpracy. Project Manager, który ma na względzie powodzenie projektu oraz rozumie sposoby realizacji tego celu – będzie wspierał i umożliwiał współpracę zespołu deweloperskiego ze stroną biznesową.
Myślenie życzeniowe podpowiada wszelką pomyślność oraz spełnienie treści karty projektu. Każdy nowy początek projektu będzie jednak zarazem każdym nowym końcem. Powrót do przyszłości oznacza bowiem konieczność nieustannej weryfikacji oraz dostosowywania wstępnych założeń do rzeczywistości.
* Ghostwriter (pisarz-widmo) – osoba, która za wynagrodzeniem pisze, koryguje lub redaguje: opowiadania, artykuły, sprawozdania, teksty piosenek, prace naukowe, książki, które następnie zostają opublikowane pod nazwiskiem zleceniodawcy.
Zdjęcia przedstawiają kadry z filmu Arrival, reż. Denis Villeneuve
Antropolożka korporacji oraz praktyk metodyk Scrum i Large-Scale Scrum (LeSS). Specjalizuje się w tworzeniu i praktykowaniu najlepszych metod współpracy biznesowej oraz w kształtowaniu kultury organizacyjnej ze szczególnym uwzględnieniem budowania, wzmacniania i odkrywania potencjału antropologii kulturowej. Obserwacje i komentarze publikuje na blogu: www.itisnotrocketscience.me