Dziś tekst, który będzie użyteczny dla wszystkich Product Ownerów i Scrum Masterów. Panuje przekonanie, że jeśli Właściciel Produktu zarządza swoim Backlogiem Produktu, jest też jego jedynym twórcą. Nic bardziej mylnego! Wszystkim powinno zależeć, aby doprowadzić do sytuacji, w której Klient też pracuje nad listą wymagań.
Coś dla Klienta
Generalnie świat nie jest czarno-biały, tak samo jest z Klientami. Jedni chcą i będą się angażować w prace nad Backlogiem Produktu, inni wręcz przeciwnie. Nie ma jednego najlepszego modelu współpracy w tym zakresie, bo wszystko często zależy od wzajemnych relacji i uwarunkowań umownych.
Są Klienci, którzy są partnerami dla Product Ownera i budowanego Produktu. Ta sytuacja jest najlepsza! Wzajemne zrozumienie Product Ownera i Klienta budowane wokół Produktu jest pierwszym krokiem w kierunku powodzenia budowanego Produktu.
Jak wszyscy (chyba) wiemy budowanie Produktu to proces wielopoziomowy. Jestem sobie w stanie wyobrazić i widziałem takich Klientów, którzy przychodzili do Zespołu z listą zawierającą (według nich) komplet specyfikacji budowlanego rozwiązania. Widziałem też takich Klientów, którzy budując rozwiązanie od zera kooperowali z zespołem celem uzyskania najlepszego efektu końcowego. Nie można powiedzieć, że jedna albo druga sytuacja jest zła. Można za to przewidzieć, że pewne sytuacje skutecznie uniemożliwią efektywne budowanie produktu.
Kiedy Klient wie lepiej
Generalnie zakłada się, że osoby tworzące rozwiązanie są ekspertami w dziedzinie przygotowywanej funkcjonalności. Nie mówię tutaj o merytoryce, a raczej o jej przełożeniu na technologię, UX/UI, aspekty systemowe etc. Merytorykę pozostawiłbym (i pozostawiam) tam, gdzie ma ona swoje źródło, a więc w rękach Klienta.
Tutaj pojawić się może problem. Niektórzy Klienci nie akceptują powyższego rozdziału merytoryki od eksperckości, co prowadzi do konfliktów. Sytuacja, w której Klient przychodzi ze „swoim” backlogiem i żąda jego realizacji jest nie do zaakceptowania dla większości zespołów realizacyjnych. Wcale się temu nie dziwię, choć istnieje pokusa, aby zdjąć z siebie odpowiedzialność i wziąć od Klienta „gotową” listę wymagań z pełnym dobrodziejstwem inwentarza.
Można i powinno się działać inaczej. Jak pokazuje doświadczenie, zaangażowanie Klienta w pracę nad Backlogiem jest kluczem do osiągnięcia celów budowanego Produktu. Zaangażowanie to osiągniemy niezależnie od tego, czy Klient przyszedł ze „swoim” Backlogiem, czy przyszedł z „niczym” i pracuje z nami od zera nad rozwojem swojego rozwiązania.
Korzyści z kooperacji
Jakich korzyści z kooperacji z możemy doświadczyć? Jest ich na tyle dużo, że pokuszę się na wymienienie tylko czterech podstawowych. Po pierwsze dzięki udziałowi Klienta w procesie tworzenia Backlogu uzyskujemy lepsze rozumienie potrzeb. Mówiąc o powyższym mam na myśli zarówno stronę „kliencką” jak również stronę „technologiczną”. O tej technologicznej myślę, że nie ma się co rozwodzić. Stosują takie podejście Klient ma jednak większą wiedzę w zakresie kierunku rozwoju produktu, również pod względem systemowym. Parafrazując – bardzo szybko dowiaduje się on, co jest możliwe a co nie oraz gdzie warto poświęcić środki i czas, aby osiągnąć lepsze rezultaty.
Kolejną korzyścią z kooperacji będzie budowanie wzajemnych relacji pomiędzy Klientem, a szeroko rozumianym Scrum Teamem. Nic nie zrobi lepiej naszej pracy nad Produktem niż wspólne godziny spędzone nad przygotowaniem rozwiązania, dogadywanie szczegółów i określanie wymagań. W długiej perspektywie pozwoli nam to również zaoszczędzić (prawdopodobnie) wielu nieporozumień, które pojawić się mogą w toku naszej codziennej pracy. Można powiedzieć, że wspólna, ciężka praca nad wymaganiami będzie spoiwem mocniejszym niż beton.
Trzecią z korzyści, na którą na pewno warto zwrócić uwagę jest możliwość nieomal online’owej zmiany zakresu. Oczywiście, nie ma znów wielu „szaleńców”, którzy będą decydowali się na to bez żadnych warunków. W tym miejscu zwrócę uwagę na wynik dobrej kooperacji i wspólne rozumienie celu, który przed nami stoi. Jeśli wszyscy gramy do tej samej bramki, jeśli stoi przed nami realizacja tego samego produktu, to dlaczego mamy nie zrobić sobie czasami wzajemnie przysługi? Oczywiście z korzyścią dla obu stron.
W końcu ostatnia, choć nie najmniej ważna rzecz! Dzięki bliskiej współpracy Klienta i Product Ownera, dobrej ich relacji, wzajemnym rozumieniu potrzeb istnieje duże większe prawdopodobieństwo, że będziemy robić właściwe rzeczy we właściwym czasie. Nie będzie to konsekwencją jedynie dobrych relacji, a raczej dobrej znajomości Backlogu, rozumienia aspektów na przestrzeni biznesowo-systemowej a gdzieś na końcu również wszystkich wyżej opisanych elementów.
Czy warto wciągnąć Kilenta do pracy nad backlogiem?
Na pewno! Jestem przekonany, że korzyści, które wskazałem powyżej przekonają nieprzekonanych. Warto pracować z Klientem na Backlogiem Produktu. Jednak tak jak z innymi rzeczami, tak i ze wspólną pracą nad listą wymagań naszego Produktu warto uważać.
Są Klienci, którzy takie podejście będą potrafili wykorzystać, szczególnie jeśli Product Owner nie do końca pewnie czuje się po stronie zespołu wytwórczego. Zamiast realizować wymagania najważniejsze, najbardziej opłacalne, najbardziej realne do wykonania technologicznie, realizujemy wtedy stanowisko Klienta, który nie liczy się z niczym. Czemu ma to służyć? Na pewno nie Produktowi ani Scrum Teamowi. A w długiej perspektywie na pewno nie zwróci się to również samemu Klientowi!
