W ostatnim artykule (jesteś product ownerem – zaangażuj swój zespół) obiecałem wam, że poruszę kwestię bycia liderem. Jednak się rozmyśliłem. Myślę, że napisane przez psychologów artykuły i posty pozwolą ciekawym tematu łatwo go zgłębić. Ale mam za to coś innego. Spojrzenie na rolę Product Ownera (PO) z punktu widzenia agile’a, nie psychologii.
W poprzednim artykule starałem się Wam pokazać aspekt motywowania zespołu. Ale co to w ogóle oznacza, że jesteś dobrym Product Ownerem? W cyklu artykułów postaram się Wam przytoczyć najważniejsze moim zdaniem cechy i umiejętności PO. Dzisiejsza część będzie traktować o interesariuszach i klientach, a w kolejnych opowiem Wam o produkcie, product backlogu oraz zespole.
Wyjdźmy od agile’a. Co to oznacza, że jesteś/cie zwinni? Zgodnie z definicją Słownika Języka Polskiego zwinny to “wykonujący szybkie, zręczne ruchy”. Wg twórców Agile Manifesto zwinny (ang. agile) oznacza, że jest empiryczny (doświadczamy czegoś, aby to poznać) oraz transparentny (przejrzysty). Dlaczego piszę o zwinności? Ponieważ jedną z cech dobrego PO jest umiejętność zwinnego zarządzania produktem. Tę umiejętność z kolei możemy rozbić na takie elementy jak:
- częsta zmiana produktu – to jest o tyle ciekawy punkt, że gdy popatrzymy na rynek np. smartphonów coraz częściej mamy do czynienia z nowymi wersjami, a nierzadko się zdarza, że mamy również do czynienia z kolejnymi wersjami oprogramowania niezależnymi od samego urządzenia. Innymi słowy cykl życia produktu ulega skróceniu,
- szybka informacja zwrotna – całe podejście iteracyjne bazuje na podstawowym założeniu, że nie będzie zwinności, agile’a, Scruma, jeżeli nie będziemy skracać pętli informacji zwrotnej (feedback loop). Zaproszenie interesariuszy na Sprint Review jest skracaniem pętli feedbacku. I może to doprowadzić do zmian nie tylko w naszym sposobie pracy i całej organizacji, ale również u naszych klientów,
- identyfikacja mocnych i słabych stron produktu, ale również szans i zagrożeń. Oczywiście mowa tutaj o analizie SWOT, ale też o kolejnej cesze dobrego PO – wiedzy domenowej, czyli doskonałej znajomości produktu,
- bazowanie na danych empirycznych – robimy mały kawałek, sprawdzajmy go jak najczęściej i dostosowujemy do otoczenia i oczekiwań interesariuszy czy klientów. Jak mówi mój syn “banał”, ale ilu z nas tak robi?
Steve Blank mówi, że trudno budować relacje, zbierać wymagania od interesariuszy czy klientów (będę w tej części stosował oba pojęcia wymiennie), kiedy nas z nimi nie ma. Innymi słowy “fakty można znaleźć jedynie tam, gdzie można znaleźć Twoich klientów”. A rozwijając tę myśl daje nam więcej wskazówek:
- nawiąż z nimi bezpośredni kontakt,
- nie chodzi o to, aby porozmawiać z nimi raz – proces ten musi trwać ciągle,
- tylko w ten sposób możesz potwierdzić, czy stworzyłeś realną wizję przyszłości, czy jest ona raczej efektem halucynacji.
Zwłaszcza ten ostatni punkt jest dość dosłowny i trafny. Trudno sobie wyobrazić, że zbudujesz dobry produkt, nie weryfikując hipotez z rynkiem i Twoim klientami.
Ale jak ich znaleźć? Jako doświadczony PO pracujący od dłuższego czasu z jednym produktem nie będziesz miał problemu z odpowiedzeniem sobie na to pytanie. Ale jeżeli Twoja droga Ownerska dopiero się rozpoczęła lub dostałeś właśnie do zrealizowania nowy projekt w dziedzinie, której do tej pory razem z zespołem nie dotykaliście? Poszukaj ich! Odpowiedź jest dość oczywista. Możecie do tego użyć np. techniki Stakeholder Map. Pomoże wam ona w identyfikacji interesariuszy produktu czy też projektu. Kluczowe jest tutaj, aby zaangażować w tę technikę cały zespół. Tylko wtedy naprawdę możecie zidentyfikować wszystkich zainteresowanych, a niejako przy okazji, zaangażować zespół.
Dobry PO jest asertywny. W kontaktach z klientami, czy też bardziej interesariuszami, warto być asertywnym, ponieważ jak życie pokazuje, bardzo często macie do czynienia z sytuacjami, kiedy ktoś próbuje wam narzucić konkretną datę wykonania, lub kiedy wiele wymagań z różnych obszarów ma być zrobionych w tym samym czasie. Do narzuconej daty jeszcze wrócę. Skupmy się na razie na wielu interesariuszach i ich oczekiwaniach, że wymagania zostaną zrealizowane w tym samym czasie. Najlepiej, aby wszystko było dostarczone na wczoraj. Spotkaliście się już z takim podejściem? A jak sobie z tym poradzić? Najprostszym sposobem pogodzenia, albo przynajmniej próby pogodzenia wielu interesariuszy jest użycie jakiejś techniki. Przykładem może być tutaj Difficulty Matrix (inaczej zwanym Big Wall). Jeżeli wyobrazicie sobie, że wydrukowane inicjatywy zostaną rozłożone na dwuwymiarowej matrycy, gdzie z jednej strony będzie złożoność techniczna (zaangażujcie w to developerów), a z drugiej strony interesariusze rozłożą swoje inicjatywy w kontekście dostarczanej wartości biznesowej, to może uda się ich pogodzić. W rezultacie dostaniecie spiorytetyzowany backlog, który będziecie realizować po kolei, a nie wszystko na raz.
Interesariusze, przekazując swoje potrzeby i wymagania zadają najczęściej pytanie – kiedy mi to zrobicie? Co odpowiadacie? Pewnie zależy od sytuacji. Pamiętajcie jednak, że mamy pracować w środowisku zwinnym. A to oznacza, że samoorganizacja zespołów jest jedną z najważniejszych cech. Idąc dalej, odpowiedź na tak zadanie pytanie wymaga konsultacji z zespołem. Bo to zespół jest odpowiedzialny za dostarczenie konkretnych funkcjonalności. I analizując jego prędkość, można oszacować na kiedy jakieś duże wymaganie czy projekt zostanie dostarczony. W innym przypadku możecie naciskać na zespół, aby jednak dostarczył wymagania w określonej, narzuconej dacie. To z kolei może prowadzić do tworzenia długu technicznego. A gdzie w tym wszystkim dobry PO? Dobry Product Owner jest świadomy tej sytuacji i może tak poprowadzić rozmowę z interesariuszem, aby mu to wyjaśnić i wrócić z konkretną propozycją daty, zamiast dać sobie ją narzucić.
Na zakończenie pierwszej części cyklu “Jak być dobrym Product Ownerem”, chciałem się z Wami podzielić dobrymi praktykami we współpracy z interesariuszami. Zidentyfikowałem takie jak:
- badajcie ich satysfakcję, to znaczy rozmawiajcie z nimi o ich potrzebach, przekazujcie informację zwrotną jak i kiedy zlecone wymagania powstaną. Możecie również cyklicznie zaplanować badanie satysfakcji interesariuszy na przykład poprzez ankietę,
- nie pozostawajcie bierni na otrzymywaną informacją zwrotną; pokażcie, co się z nią dzieje, jak zmieniacie produkt czy proces w kontekście oczekiwań,
- nie pozostawajcie również bierni na „wrzucanie” wymagań. Jeżeli klienci i interesariusze oczekują zrealizowania pewnych wymagań, nie zawsze należy je zrealizować. Jeżeli kłócą się one z wizją produktu, tworzą dług techniczny lub po prostu są to wymagania, z których nikt nie będzie korzystał, nie róbcie ich. Ale uargumentujcie swoją odmowę!