SPOC to jeden z wielu sposobów na adresowanie problemów komunikacyjnych. Czy Single Point of Contact to dobre rozwiązanie? Czym dokładnie jest SPOC, jakie ma zalety i wady, oraz w jaki sposób jest używany w ramach zwinnych frameworków?
SPOC
SPOC to skrót, który rozwijamy jako Single Point of Contact. Przetłumaczyć to możemy na Jeden (Jedyny) Punkt Kontaktu. Jest to rola lub pozycja, która pełni kluczową funkcję w zarządzaniu komunikacją i koordynacją. Mając w jakimś temacie SPOC-a, nie zastanawiamy się „do kogo pójść” albo „z kim się skontaktować”. Jak w dym uderzamy do Single Point of Contact.
Osoba pełniąca rolę SPOC jest odpowiedzialna za zapewnienie jednolitego źródła informacji i koordynacji działań w ramach jakiegoś tematu. Może to być SPOC w temacie wymagań albo who is who. Bardzo często mamy do czynienia ze SPOC-ami jeżeli chodzi o zgłaszanie wymagań i błędów. Taka osoba jest centralnym punktem w procesie komunikacji zarówno wewnątrz zespołu, jak i na zewnątrz, z klientem lub innymi zespołami.
Jest to przykład zarówno centralizacji, jak i upraszczania – nie musimy się zastanawiać kto, gdzie, kiedy. Mamy jasno wskazane „kto” i wiemy, że „zawsze”. To trochę tak jak taki key account manager.
Product Owner jako SPOC
W Scrumie, to Product Owner często pełni rolę SPOC, reprezentując interesy klienta i definiując priorytety. Jest to naturalny kandydat/naturalna kandydatka na Single Point of Contact. PO jest odpowiedzialny za tworzenie i zarządzanie Product Backlogiem. Dzięki temu ma pełne zrozumienie potrzeb klienta i może przekazywać je zespołowi w sposób klarowny. A skoro jest punktem centralnym w komunikacji między zespołem a klientem, to pozwala uniknąć konfuzji i sprzyja efektywnej wymianie informacji. Z kolei klient nie boryka się z wieloma reprezentantami tylko zawsze rozmawia z jedną osobą.
PO określa priorytety zadań w backlogu i jest dostępny dla zespołu przez cały czas, gotowy do udzielenia odpowiedzi na pytania czy dokonania kluczowych decyzji, co eliminuje opóźnienia wynikające z oczekiwania na zatwierdzenia czy konsultacje.
Choć rola Product Ownera jako SPOC ma wiele zalet, to istnieją również pewne ryzyka i potencjalne problemy, z którymi można się spotkać. Przede wszystkim PO może być nadmiernie obciążony pracą, szczególnie w projektach o dużym zakresie lub wielu zespołach. Znamy to z życia – Zarządzanie Backlogiem Produktu, komunikacja z klientem, priorytetyzacja zadań jednocześnie mogą stanowić ogromne wyzwanie.
Kiedy Product Owner jest jedynym źródłem wymagań i wytycznych, istnieje ryzyko, że różnorodność perspektyw i pomysłów zostanie ograniczona. W końcu nie mamy etapu diverge, nie generujemy pomysłów tylko załatwiamy je jednoosobowo. To może prowadzić do utraty innowacyjności i pomijania cennych punktów widzenia innych członków zespołu.
W przypadku bardziej skomplikowanych produktów, Product Owner może nie być w stanie samodzielnie rozwiązać wszystkich problemów i podejmować wszystkie decyzje… Brzmi strasznie?
Scrum Master jako SPOC
Zacznijmy od tego, że Scrum Master jest SPOC-em dla zespołu, w temacie wszystkich rzeczy scrumowych, procesu, impedimentów i blokerów. Zespół nie zastanawia się, do kogo uderzyć, tylko idzie do Scrum Mastera. Inni, chcąc dowiedzieć się czegoś o naszym zespole działają w podobny sposób. To SM wie najwięcej i jest najbardziej dostępny.
Zresztą, w Scrum Guide mamy jawnie wpisane, że to Scrum Master jest odpowiedzialny za usuwanie przeszkód, które mogą utrudniać pracę zespołu. Działa jako most między zespołem a interesariuszami. SM chroni też zespół przed nadmiernymi zakłóceniami i wpływami zewnętrznymi, umożliwiając mu skoncentrowanie się na dostarczaniu wartości klientowi. Jest swego rodzaju buforem dla innych – a my już wiemy, że ten bufor możemy nazwać SPOC-em.
Tutaj również istnieją ryzyka. Przede wszystkim możemy nauczyć zespół bierności i niemocy, bo wszystko załatwia za nich Scrum Master. Wtedy mówimy o problemie pod tytułem Scrum Mom. Istnieje też ryzyko, że Scrum Master może nie odnaleźć się w konflikcie interesów między poszczególnymi osobami. Ryzyka są tu jednak mniejsze niż w przypadku traktowania PO jako SPOC-a.
SPOC Bus Factor
Największym ryzykiem posiadania SPOC-a w jakimkolwiek temacie jest ryzyko jednego punktu awarii. To ten słynny Bus Factor. Jeśli nasz „rodzynek” stanie się niedostępny z jakiegokolwiek powodu, może to spowolnić lub zakłócić wszystkie nasze procesy. W przypadku choroby, urlopu lub innego rodzaju nieobecności, brak alternatywnego źródła wymagań i decyzji może prowadzić do opóźnień.
W przypadku Product Ownera przesłaniającego zespół (dla interesariuszy) i interesariuszy (dla zespołu) mamy jeszcze ryzyko braku bezpośredniego kontaktu z klientem. Deweloperzy mogą w ogóle nie mieć bezpośredniego dostęp do źródła informacji i wrażeń klienta poza Sprint Review. To może prowadzić do nieporozumień i błędów w interpretacji potrzeb. Kiedy zespół jest oddzielony od biznesu przez SPOC, może to ograniczyć zdolność zespołu do zgłaszania własnych pomysłów, innowacji i sugestii. To może prowadzić do przegapienia cennych okazji lub pomysłów na ulepszenia.
Tak więc nawet w sytuacji, w której mamy sprawnie działającego SPOC-a, nie powinniśy utrudniać czy zabraniać bezpośredniego kontakt z klientem. Traktujmy SPOC jako domyślny sposób działania, ale nie jedyny. Lub utrzymujmy SPOC-a na poziomie decyzyjnym, a w ramach pracy nad wymaganiami – promujmy kontakty bezpośrednie.
Oddzielenie „jednej strony” od „drugiej” przez SPOC-a zawsze wiąże się z ryzykami. Można je jednak zminimalizować poprzez zachowanie otwartej komunikacji, współpracę w zespole oraz umożliwienie bezpośredniego kontaktu w odpowiednich momentach. To pozwoli na osiągnięcie równowagi między efektywnością, a zachowaniem bezpośredniego zaangażowania zespołu w proces dostarczania produktu.
Single Point of Contact
Są sytuacje, w których Single Point of Contact może przynieść prawdziwy oddech dla „chronionych”, usprawni komunikację i pomoże walczyć z bałaganem i wieloma rodzajami prawdy. O ile zadbamy o transparentność, dostępność i jasne zasadydziałania, to nie powinniśmy mieć problemów.
Jak to już zresztą zostało napisane – Product Owner jest SPOC-em w temacie wymagań, a Scrum Master – w tematach scrumowych. Nie zmienimy tego, za to możemy to wykorzystać. I to zarówno w działaniu na co dzień, jak i jako przykład, jak SPOC może wyglądać.
