AMA z Bartkiem Gatz

Za nami czwarte spotkanie w formule Ask-Me-Anything. Tym razem gościem był Bartek Gatz, a tematem przewodnim „Zarządzanie dużymi backlogami”.

Bartek Gatz to Dyrektor Product Managementu w Dynatrace. Rocznik ’76, absolwent Politechnik Gdańskiej. Od 20 lat pracuje nad produktami APM i ALM w tym od kilkunastu jak product manager. Miał okazję widzieć transformacje firm, narodziny i schyłek dużych i małych produktów, sukcesy, porażki, triumfy i błędy. Praktyk i entuzjasta robienia rzeczy po swojemu, ale z jasno określonym celem. Obecnie szef zespołu product managerów pracujących w Gdańskiej filii Dynatrace. Wcześniej pracował m.in. w Amazon, Spartez i Atlassian. Poza pracą: fotograf amator, podróżnik amator i stolarz amator. Entuzjasta komputerów i konsol z lat 70, 80 i 90, prezes i współzałożyciel Stowarzyszenia RetroKomp. Dumny ojciec trzech córek, z których żadna nie interesuje się stolarstwem.

W ramach dyskusji Bartek wyszedł z inicjatywą przeprowadzenia warsztatu on-line, który pogłębiłby temat rozmowy. Jesteś zainteresowany? Wypełnij formularz – Klik.

Dodatkowo, poniżej znajdziecie 18 odpowiedzi, na pytania, które nie zdążyły bądź zdążyły zostać zadanie w trakcie transmisji. Przeczytaj koniecznie – odpowiedzi zawierają mnóstwo praktycznych rad i wskazówek dla produktowców.

1. Jak zsynchronizować pracę miedzy zespołami deweloperskimi w przypadku występowania zależności między nimi?

Do dyspozycji jest kilka dobrych praktyk, o których można sobie poczytać w internetach, więc nie będę tutaj specjalnie rozwijał tematu. Natomiast trzeba sobie zadać dwa pytania:

Jeżeli takich zależności jest dużo, to czy nasze zespoły są na pewno zdolne do dowiezienia wartości klientowi end-to-end? Mówię tutaj o definicji zespołu w rozumieniu Scrum Guide’a.

Jeżeli nie, to może warto przekonfigurować zespoły. Każda zależność pomiędzy zespołami to konieczność synchronizacji, a zatem strata czasu i niekontrolowany czas dowiezienia funkcjonalności do klienta. Może można tego uniknąć.

Czy synchronizacja prac zespołów to na pewno zadanie dla product managera? Moim zdaniem to pole do popisu dla project / program managerów. Ale też dla scrum masterów, który w rozumieniu Scruma powinno to podnieść jako impediment → patrz a).

2. Jakie podejście stosujesz do efektywnej synchronizacji wysiłków nad wieloma backlogami, które mogą być od siebie zależne?

To podobne pytanie jak to numer 1. Ale tutaj chciałem dodać jedną ważną rzecz – w przypadku wielu PMów może się pojawić konflikt priorytetów, bez względu na to czy mamy do czynienia z jednym czy z wieloma backlogami. Pomocą tutaj będzie transparentna priorytetyzacja i WSPÓLNE ustalenie priorytetów w oparciu o fakty. O technice transparentnego priorytetyzowania możemy pomówić na naszym warsztacie, o którym wspomniałem kilkukrotnie podczas AMA

3. Czy dobrze sprawdza się to, że UX i Produkt to oddzielne zespoły w przypadku większej firmy? Jakie to ma zalety i jakie wady?

Definicja “oddzielnych zespołów” może być różna w zależności od firmy. Moim zdaniem pomiędzy PM, UX ale też Dev Managerem / Architektem nie powinno być zależności hierarchicznej. To powinny być osoby i funkcje pracujące razem, ale też kreatywnie podważające swoje wzajemnie status quo. PM będzie przychodzić z problemami i okazjami biznesowymi. UX będzie kwestionować i poprawiać ich użyteczność, a DM/Arch będzie trzymać pozostałą dwójkę w ryzach technicznych możliwości. Taki triumwirat pracujący pod hasłem “róbmy rzeczy ważne, dobrze i w oparciu o solidne techniczne podwaliny” daje szansę na udane inkrementy. Jakikolwiek konflikt pomiędzy tymi osobami osłabia tę konstrukcję i grozi robieniem rzeczy bez sensu, nieużywalnych lub niedziałających.

4. Kiedy zaczynasz dostrzegać i jak do tego podchodzisz gdy w jednym backlogu zaczynamy pracować nad zbyt wieloma aspektami produktu i/lub są to inicjatywy/hipotezy dążące do różnych, czasem rozbieżnych kierunków rozwoju produktu/firmy?

Staram się oceniać wszystkie inicjatywy pod kątem ich impaktu, pilności, kosztu oraz ryzka i w ten sposób je porównywać. Do tego dochodzą oczywiście cele strategiczne firmy. Po spriorytetyzowaniu backlogu staram się potem robić jak najmniej rzeczy na raz i tym samym skracać czas trwania inkrementów i oszczędzać czas zespołu na przełączaniu kontekstu. Rzeczy z dna backlogu albo takie, które za długo w nim leżą staram się wyrzucać. O reszcie opowiem chętnie na warsztacie.

5. Czy, a jeśli tak, to gdzie/jak, składujesz hipotezy na pomysły, nie chcąc zaśmiecać nimi backlogu i tym samym niwelować transparentności produktu?

Pracuję z zespołem w oparciu o dwa backlogi – backlog hipotez i backlog wykonawczy. Szczegóły na warsztacie.

6. Jak pracować nad refinementem wokół elementów backlogu? Jak szczegółowo PBIs określać?

Są trzy istotne elementy składowe każdego dobrego wpisu do backlogu:

• informacja po co to robimy, dla kogo i na kiedy oraz dowód że to prawda
• zarys rozwiązania, służący do nawiązania dyskusji
• mierzalne i określone z góry kryteria sukcesu

Reszta to kwestia rozmów i sparingu z UX, Architektami pozostałymi architektami, poprawek, a dopiero na końcu rozbicie na zadania.

7. W jaki sposób oceniacie potencjalny impact funkcjonalności?

W mojej praktyce oceniałem to po ilości i jakości klientów, których dana funkcjonalność zadowoli. Ale ten model może być zupełnie inny w przypadku produktów robionych na zamówienie albo mocno customizowanych.

8. W jaki sposób można skorzystać z Waszego (firmy) doświadczenia w zakresie wdrożenia i stosowania tego modelu? Czy wyobrażasz sobie, że taki model/bardzo zbliżony jest implementowany w innej firmie z Waszym mentoringiem w procesie wdrożenia?

Nasza firma (Dynatrace) nie prowadzi aktywnego mentoringu z zarządzania i wdrażania procesu. Uczymy się na własnym materiale i własnych błędach, korzystając oczywiście z doświadczenia wnoszonego przez pracowników. Ale nie mamy też sekretnego procesu. Chętnie opowiem jak wygląda nasz proces, ale najlepiej poćwiczyć go na warsztacie na który zapraszam.

9. W jaki sposób badacie zależności między produktami w modelu? W jak sposób dokonujecie ewaluacji ich wzajemnego wpływu na siebie?

Nie rozumiem do końca pytania. Jak definiujemy tu “produkt”? Jeżeli mówimy o produktach w portfolio jednej firmy, to bardzo BARDZO trudne zadanie. Na tyle trudne, że niektóre firmy (np. Dynatrace właśnie) postanowiły połączyć produkty ze swojego portfolio w jeden produkt, a to czego nie udało się połączyć – po prostu wygasić. Focus zapewnia szybkość pracy, ale oczywiście idzie z nim też ryzyko. Brak dywersyfikacji i postawienie wszystkiego na jedną kartę równie często źle się kończy. Obawiam się jednak, że moje dotychczasowe doświadczenie nie pozwala na pełną odpowiedź na to pytanie.

10. W jak wygląda u Was proces celebracji?

Mamy ogólnofirmowe spotkania celebracyjne, na których opowiadamy sobie sukcesy i lekcje z produktu. Te odbywają się cyklicznie. Dodatkowo każdy zespół ma swój budżet na celebrację i wykorzystuje ten budżet wedle swojego uznania. Zdarza się też że PM postawi kolegom z zespołu piwo, ale złośliwi twierdzą, że robi to tylko wtedy kiedy coś wcześniej nabroił.

11. Co ile robicie update wybranych i roadmap dla produktów?

Idelanie by było gdyby rodmapa(y) była zawsze aktualna. W praktyce duże updejty robię co dwa, trzy miesiące.

12. Jakie narzędzia wykorzystujecie do tego modelu i co musieliście dorobić we własnym zakresie, by dopasować narzędzia?

Domyślam się, że chodzi o model dyskutowany na spotkaniu. Korzystamy głównie z JIRY, a dodatkową dokumentację trzymamy w Confluence i Sharepoint.

13. Ile osób jest aktualnie zaangażowanych u Was w proces po lewej stronie, a ile po stronie prawej? Kto zarządza i spaja obie części modelu?

Nie wolno mi podać dokładnych liczb. Ale w proces budowania backlogu value incrementów (hiopotez) zaangażowanych jest kilkadziesiąt osób w całej firmie, natomiast w realizację kilkaset. Na styku pracują głównie osoby z funkcjami PM, UX, Architekt, Lead Product Engineer.

14. Jakie są role w poszczególnych procesach – ideation, shaping, validation, sparing, prioritization – i czy to CPO podejmuje decyzje? 

CPO nie dałby rady się tak wyskalować. Szczegóły chętnie omówię na warsztacie, a tutaj na szybko tylko napiszę, że praktycznie każdy stakeholder ma wpływ na cykl życia pomysłu. Ostateczna decyzja należy do PMa zarządzającego danym fragmentem produktu, ale jest to decyzja oświecona sparringiem z pozostałymi.

15. Jak metodycznie robicie proces ideation?

Piękno tego procesu polega na tym, że do procesu ideacji nie wymagamy metodyki. Masz problem? Zapisz go na kartce i przynieś. Masz pomysł? To samo. Ale pamiętaj, że zaraz padną pytania “po co” i bądź gotowy na dyskusję.

16. Jakiego rodzaju mierniki obieracie dla technicznych inicjatyw/tasków?

Kilka przykładów: zmniejszenie liczby bugów, zmniejszenie liczby ticketów na supporcie, czas budowania produktu, czas przepuszczania produktu przez pipeline, czas potrzebny na tworzenie dokumentacji, itp.

17. Praca z backlogami z zespołami rozproszonymi i międzynarodowymi vs kolektywami – jakie są różnice? Jakie praktyki „ratują życie”? 🙂

Zachęcam do przejrzenia slajdów z jednego z moich historycznych wystąpień: https://www.slideshare.net/xmgatz/how-to-be-a-good-it-product-manager-part-3-remote-collaboration-87204445

18. Gdzie się zaczyna, a gdzie kończy historia życia wymagania.

Zaczyna się w momencje incepcji pomysłu lub identyfikkacji problemu. Kończy w momencie kiedy wiemy czy rezultat prac się przyjął (sukces) lub nie (rollback lub kolejny inkrement).

19. Handover czyli przejmowanie produktu po kimś lub wdrożenie w nowy produkt. Jak do tego podejść?

Zapraszam na warsztat.

20. Jakie są dobre praktyki w pracy ze zdalnym zespołem?

Zachęcam do przejrzenia slajdów z jednego z moich historycznych wystąpień: https://www.slideshare.net/xmgatz/how-to-be-a-good-it-product-manager-part-3-remote-collaboration-87204445

21. Dlaczego nie warto się bać ryzykować?

Tutaj znowu temat jest znacznie ciekawszy niż pozwala na to format. Zachęcam do przejrzenia moich slajdów z niedawnego wystąpienia w Krakowie, ale szczerze mówiąc bez komentarza będą pewnie mało czytelne. Może warto urządzić dodatkową sesję? https://www.slideshare.net/xmgatz/product-management-pitfalls-of-data-driven-development