“Jak będziesz miał chwilę…” – jedno z największych niedopowiedzeń branży IT.
W dzisiejszym artykule chciałbym podzielić się z Tobą niedawną refleksją „z przymrużeniem oka” na temat zjawiska językowego, które miałem okazję dosyć często obserwować w swojej dotychczasowej pracy. Jak zapewne już się domyślasz po przeczytaniu tytułu chodzi mi dodatki do listy zadań do zrobienie w trybie „Nic pilnego, jak będziecie mieli wolną chwilę”.
Na wstępie chciałbym od razu zaznaczyć że sam fakt przekazywania rzeczy “niepilnych” nie jest absolutnie czymś złym. Wręcz bardzo dobrze, że nie wszystko co wpada do nas musi być odrazu najwyższym priorytetem. Gdyby tak było to mielibyśmy do czynienia z nieustanną dyskusją na temat tego czy kolejna “nowość” na pewno zasługuje na to żeby zrzucić z góry listy inne wcześniej zaplanowane prace. Jestem przekonany że w dłuższej perspektywie taki dialog nie posłużył by dobrze budowaniu pozytywnych relacji z interesariuszami ani samemu postępowi produktu. Alternatywą dla postawy obronnej byłoby po prostu przyjmowanie kolejnych „pierwszych” priorytetów do realizacji i w efekcie wejście w tryb „kołowrotka dla chomika” gdzie co chwilę porzucamy aktualny temat, zaczynamy nową rzecz, doprowadzamy do niekoniecznie zadowalającego stanu i znów zmiana kierunku. Wniosek jest prosty – system budowania produktu przez ciągłe „dorzucanie czegoś na górę” nikomu nie służy.
Jaki więc dostrzegam problem z robieniem czegoś „jak będzie chwila”? Tradycyjnie już chyba najbardziej doskwierają mi niedopowiedzenia i pułapki zawarte w tym określeniu. Przeanalizujmy więc sprawę od początku.
Pierwszy element układanki w moim odczuciu jest taki, że najkrótsza chyba definicja roli product ownera mówi o tym, że jego podstawowym zadaniem maksymalizacji efektu pracy wykonywanej przez zespół deweloperski. Co za tym idzie – podstawowym zadaniem produktowca jest zapewnić to, żeby zespół miał co robić, a co więcej żeby realizowane zadania miały możliwie jak największą wartość dla produktu i organizacji. Naturalnym staje się wniosek, że podstawową powinnością produktowca jest dbać o to, aby tych mitycznych „wolnych chwil” po prostu nie było. Dla pewności powtórzę jeszcze raz – produktowcy dostają wypłaty w dużej mierze za to żeby zapewnić ciągły dopływ wartościowych rzeczy do zrobienia. Tak więc jeśli coś trafia do wykonania, to powinno to być dlatego że jest ważne i niesie ze sobą dużą wartość dla produktu czy organizacji, a nie dlatego że „nie ma co robić”.
Drugi kawałek stanowi wartość zadania. Jeżeli z jakiegoś powodu dociera do nas już dany temat, to musi on być na tyle istotny, że ktoś uznał że jednak powinien zostać zrealizowany. Dlatego pomocne w znalezieniu mocy przerobowych na dane zagadnienie będzie ustalenie dlaczego to zadanie posiada „niezerową” ważność? Co zyskamy realizując to zadanie? Warto mieć w pamięci, że niektóre sprawy mogą nie wyglądać z pozoru na bardzo wartościowe, ale jednak kryją jakąś perełkę. Ostatecznie nawet najlepszy produktowiec nie wie wszystkiego i zgłaszając się z taką prośbą można wspomóc swój „request” takim uzasadnieniem.
Ostatnim elementem wartym wspomnienia w moim odczuciu jest to, jak bardzo można odłożyć w czasie realizację danego zadania oraz jakie inne zadania będą musiały zostać opóźnione. W ten sposób (w idealnym świecie oczywiście) zacznie pojawiać się obustronne zrozumienie – z jednej strony produktowiec zrozumie jaka jest relatywna ważność zadania, a z drugiej interesariusz dowie się jakie inne zadania zostaną opóźnione w realizacji aby zabezpieczyć czas na spełnienie zgłaszanej przez niego potrzeby. Innymi słowy poza zrozumieniem co i dlaczego jest do zrobienia, ustalamy też kolejność realizacji – czyli priorytet.
Podsumowując więc moje rozumienie „idealnego” zgłoszenia tematu do backloga, powinniśmy sobie zawsze odpowiedzieć na 3 pytania przy redagowaniu zadania:
Co? Dlaczego? Kiedy?
Zanim przejdę do zakończenia, chciałbym wyartykułować jeszcze jedną myśl. Nie zawsze wszystkie requesty jakie do nas trafiają muszą zawierać odpowiedzi na wszystkie z tych trzech pytań. Jest moim zdaniem jak najbardziej w porządku aby gromadzić takie skrawki wiedzy na przyszłość, aby mieć po prostu bazę pomysłów w momencie kiedy zaczniemy się zastanawiać jaki następny krok wykonać w produkcie. Z pełną odpowiedzialnością mogę przyznać że conajmniej kilkukrotnie w historii bardzo przydała mi się taka lista i bez wątpienia jest to ułatwienie w pracy produktowca. Jedyne zastrzeżenie jakie tutaj mam to konieczność obustronnego zrozumienia, że jeśli coś jest „pomysłem” to nie koniecznie kiedykolwiek trafi do realizacji. Tak długo jak istnieje ta świadomość, nie widzę problemu z odkładaniem rzeczy na bardzo odległą przyszłość.
Mam nadzieję, moje powyższe przemyślenia pozwoliły Tobie zrozumieć już moją awersję do tak luźno sformułowanych zgłoszeń. A może należałoby powiedzieć zgłoszeń tak bardzo niedopowiedzianych? Tak czy siak, mam nadzieję że to przemyślenie okaże się dla Ciebie użyteczne i pomoże skuteczniej pozyskiwać potrzebne informacje od interesariuszy ilekroć znów dostaniesz prośbę o „dorzucenie czegoś na listę”. Oczywiście zachęcam też do komentowania – co Ciebie najbardziej boli w komunikacji produktowej na codzień albo w jakie pułapki najczęściej mamy okazję wpadać?
Piona!
