Przewodnik po Agile Scrum dla Właścicieli Produktów. Część 2 – Pojedynczy Punkt Kontaktowy

Za każdym razem, gdy właściciel produktu dołącza do zespołu Scrumowego, zasadniczo staje się niepasującym elementem. Developerzy i Scrum Master pochodzą z jednej firmy i dobrze się znają – mają doświadczenie i przywykli do pracy ze sobą. Zaakceptowanie nowego członka zespołu może być wyzwaniem, gdyż trzeba się zmierzyć z nieznanym, a często również nieprzewidywalnym.

Spis treści

1. Definicja Pojedynczego Punktu Kontaktowego
2. Zarządzaj
3. Właściciel produktu nie jest interesariuszem
4. Twój produkt na zawsze

Przyjacielskie zapoznawanie się nie jest konieczne w zespole Scrumowym – ważniejsze jest jasne określenie odpowiedzialności konkretnych członków. To kluczowe dla sukcesu projektu.

Definicja Pojedynczego Punktu Kontaktowego

W odniesieniu do zasad Scruma oznacza to, że właściciel produktu (czyli Pojedynczy Punkt Kontaktowy) powinien być jedynym kanałem komunikacji pomiędzy zespołem a zewnętrznymi źródłami informacji od strony klienta.

Aby utrzymać odpowiednie środowisko sprzyjające pracy w Agile Scrum, zespół powinien pozostać hermetyczny. Oznacza to, że zewnętrzne podmioty takie jak udziałowcy, kadra zarządzająca software housem czy konsultanci powinni kontaktować się z odpowiednim członkiem zespołu, zamiast bezpośrednio ingerować w pracę całego teamu. Tutaj właśnie pojawia się kwestia Pojedynczego Punktu Kontaktowego (Single Point of Contact, SPoC).

Zarządzaj

Praca właściciela produktu sprowadza się właściwie do jednego kluczowego zadania – zarządzania backlogiem. Musisz go wypełnić oraz dodawać, redukować, akceptować i odrzucać zadania w nim zawarte. Backlog to punkt centralny dla całego zespołu. Ścieżki i tempo pracy oraz efektywność developmentu w głównej mierze zależy od sposobu zarządzania nim. To nie tylko “biblia” produktowa dla programistów aplikacji mobilnej. Dla Ciebie to kanał komunikacji, przez który przechodzą wszystkie decyzje odnośnie produkcji.

Siła backlogu

Nie ignoruj siły backlogu. Nie jest to tylko narzędzie, ale także ochrona przed działaniami z zewnątrz. W jaki sposób? Przypuśćmy, że jako właściciel produktu musisz odpowiadać przed grupą udziałowców, prezesem i innymi osobami inwestującymi w projekt. Będą oni oczywiście przedstawiać swoje propozycje zmian i poprawek oraz dzielić się feedbackiem. W takiej sytuacji bycie Pojedynczym Punktem Kontaktowym może stać się trudne. Będziesz czuć pokusę, aby poinformować zespół Scrum o wątpliwościach kontraktorów. Nie rób tego. Te problemy powinny być w całości rozwiązane przez Ciebie. Wszystkie rzeczy zawarte w backlogu są sposobem na przekazanie zewnętrznych informacji zespołowi. Musisz je wcześniej przełożyć na język dopasowany do komunikacji w stylu Scrum.

Tylko istotne informacje

Dzielenie się informacjami typu: “Prezes najpierw musi to zatwierdzić” albo “Wciąż czekamy na decyzję zarządu w tej sprawie” są, szczerze mówiąc, całkowicie bezużyteczne – nie wnoszą nic, a tylko utrudniają pracę. W zespole Scrumowym to Ty podejmujesz decyzje, a jeżeli są one zależne od zewnętrznego źródła, miej pewność, że wszystkie odpowiedzi uda Ci się zdobyć na czas, aby przekazać je zespołowi i umożliwić mu pracę. Planując nowy sprint wszystkie te decyzje zasilą kolejny backlog.

Jeśli nie uda Ci się tego zrobić, alternatywą jest opóźnienie rozpoczęcia sprintu lub pominięcie pozycji, wobec których nie ma jeszcze informacji zwrotnej. To drugie podejście pozwoli kontynuować pracę bez opóźnień, a gdy odgórne decyzje zostaną podjęte – można je uwzględnić w sesji planowania pracy na kolejny sprint.

Pojedynczy Punkt Kontaktowy – Komunikacja, nie transmisja

Komunikacja powinna przebiegać w dwie strony. Podejmowanie decyzji i akceptowanie rezultatów pracy jest częścią Twojej pracy. Bez słuchania innych członków zespołu projekt nie będzie przebiegał tak gładko, jakbyśmy chcieli. Pamiętaj, że jako Pojedynczy Punkt Kontaktowy jesteś tutaj po to, aby powiedzieć, jakie są wymagania. Zadaniem developerów jest poinformować Cię, ile potrwa ich realizacja.

Oni też czasami będą musieli stawić czoła wyzwaniom. Skup się na wysłuchaniu wszystkiego, co mają do powiedzenia na spotkaniach Scrumowych i zaoferuj wsparcie w obszarach, w których możesz to zrobić. Siedzenie i czekanie, aż sami dojdą do czegoś, na co masz rozwiązanie, nie jest zbyt pomocne. Nie zachęca to też zespołu do okazania zrozumienia i otwartości wobec Ciebie.

Upewnij się jednak, że komunikacja naprawdę leży po Twojej stronie. Wymaga tego bycie Pojedynczym Punktem Kontaktowym. Skup się na produkcie i na zespole. Polegaj na zewnętrznych sugestiach, wymaganiach i informacjach zwrotnych, ale także na swoich własnych spostrzeżeniach odnośnie developmentu. Krótko mówiąc – odpowiednio zarządzaj procesem.

Nasi specjaliści wiedzą najlepiej

Prawdopodobnie Twoja firma też zatrudnia specjalistów IT. Na pewno znają się na rzeczy i świetnie zarządzają wewnętrznym systemem oraz rozwiązują codzienne problemy. Nie są oni jednak odpowiedzialni za budowę Twojej aplikacji mobilnej. Twój zespół IT zazwyczaj musi dostarczyć pewne elementy profesjonalnym developerom aplikacji – tego wymaga projekt. Niektóre z nich będą poza twoim obszarem specjalizacji i możesz ulec pokusie skontaktowania członka zespołu Scrum bezpośrednio ze swoim specjalistą.

Może się to wydawać świetną drogą na skróty i sposobem na odkorkowanie Twojego napiętego grafiku, ale niestety zazwyczaj kończy się źle. Jeśli taki rodzaj komunikacji jest konieczny, i tak wszystko powinno się odbywać za pomocą Pojedynczego Punktu Kontaktowego. Jeśli znajdziesz się w takiej sytuacji, najpierw zbierz wszystkie wymagania zespołu Scrumowego w jednym dokumencie i udostępnij go swojemu specjaliście. Poproś go, aby odpowiedział i przedstawił adekwatne rozwiązania w tym samym miejscu. W ten sposób zachowasz pozycję Pojedynczego Punktu Kontaktowego oraz stworzysz świetną dokumentację dla danego zagadnienia – co może się przydać, gdy coś będzie szło nie tak.

Oczywiście delikatne naginanie zasad nie zniszczy struktury Scrumowego uniwersum. Jeżeli problem jest udokumentowany, a Ty oraz zespół wiecie dokładnie co i jak, dopuszczenie kontaktu pomiędzy dwoma specjalistami może być pomocne w omawianiu szczegółów.

Musisz świadomie dokumentować całą komunikację – wtedy bez problemu zachowasz swój status Pojedynczego Punktu Kontaktowego. Najbardziej istotne jest to, aby nie przekazywać nikomu Twojej możliwości podejmowania decyzji.

Właściciel produktu nie jest interesariuszem

Może się to wydawać nieco niejasne. Co, jeśli jesteś i tym i tym? W większości startupów osoba z pomysłem i pieniędzmi, aby go zrealizować, jest też właścicielem produktu. Jednak rozdzielenie tych dwóch ról jest niezwykle istotne i bardzo pomocne w zespole Scrumowym.

Po pierwsze, łatwiej jest podejmować decyzje (również te trudne) na czas, gdy nie musisz każdej z nich przedstawiać swoim przełożonym. Kolejną zaletą jest dostęp do informacji na temat postępów w projekcie, co pozwala sprawdzić, czy wszystko idzie zgodnie z Twoją własną wizją i oczekiwaniami.

Jeśli chodzi o komunikację wewnątrz zespołu, rozdzielenie ról jest konieczne. Pracując z zespołem Scrumowym musisz pozostać właścicielem produktu. Zajmuj się rzeczami, które są najważniejsze dla rozwoju Twojego produktu. Sprawy z tym niezwiązane – jak negocjacje kontraktu czy kwestie rozliczeniowe – omawiaj z managementem firmy IT.

Wracając do pracy w Scrumie – to, czego nie ma w backlogu nie zostanie stworzone przez zespół. Jeśli uda Ci się pogodzić te dwie role, które czasami przypominają rozdwojenie jaźni – będzie dobrze!

Twój produkt na zawsze

Zmiany, ciągłe poprawki i nieprzerwana współpraca są naturalne dla zwinnego wytwarzania oprogramowania. Struktura i zasady metodologii Scrum pozwalają trzymać tę różnorodność w ryzach. Określenie Pojedynczego Punktu Kontaktu dla komunikacji zewnętrznej to jedna z podstawowych reguł pozwalająca w odpowiedni sposób prowadzić zwinny projekt.

Pojedynczy Punkt Kontaktowy – Wiele sygnałów z zewnątrz = mniej kontroli nad projektem

Aby pracować efektywnie, zespół Scrum musi mieć całkowitą jasność odnośnie łańcucha odpowiedzialności. Zakłócanie integralności teamu poprzez zewnętrzne wpływy zazwyczaj powoduje więcej problemów niż ich rozwiązuje – zwłaszcza, jeżeli zakłócenia te pochodzą z kilku źródeł i nikt ich nie kontroluje ani nie dokumentuje. Gdzie kucharek sześć, tam projekt Agile cierpi.

Z perspektywy właściciela produktu, im więcej osób postronnych dopuścisz do projektu, tym mniej kontroli nad procesem developmentu będziesz mieć. W efekcie może się okazać, że produkt nie jest spójny z Twoją wielką wizją.

To może zabrzmieć jak oczywistość, ale musisz wejść w posiadanie swojego produktu. Poznanie go wzdłuż i wszerz to Twoje główne zadanie. Podczas jego tworzenia będziesz mieć okazję, aby poznać go w każdym najmniejszym szczególe. Twoja rola właściciela produktu nie skończy się wraz z wdrożeniem aplikacji. Musisz się nią zajmować przez cały cykl jej życia. Wiedza, którą posiądziesz podczas developmentu będzie nieoceniona w trakcie jej dalszego rozwoju. Pozostanie Pojedynczym Punktem Kontaktowym pozwoli Ci zachować świadomość odnośnie wszystkich aspektów produktu oraz jego problemów i możliwości. Dobrze udokumentowany proces tworzenia aplikacji sprawi, że będziesz jedyną osobą specjalizującą się w zarządzaniu aplikacją, która zajmie się nią we wszystkich sprawach z nią związanych.