Nasza praktyka pokazuje, że SPOC to jeden z ulubionych sposób na adresowanie problemów w wielu organizacjach. Czy Single Point of Contact to rozwiązanie, które faktycznie daje nam aż tyle wartości dodanej, czy też może jest ono po prostu najprostsze?
SPOC
Single Point of Contact to w wolnym tłumaczeniu jeden (jedyny) punkt kontaktu. W niektórych przypadkach jest to faktycznie wygodne. Dla niezadowolonego klienta banku, tym Single Point of Contact jest pracownik obsługi na sali sprzedażowej. Tym samym osoby faktycznie odpowiedzialne za niezadowolenie klienta są za niewidzialnym parawanem SPOC-a. Prawdopodobnie narzekania i komentarze w końcu do nich trafią, ale nie odczują tego na własnej skórze. O tym zjawisku mówiliśmy jakiś czas temu. Nazywa się skin-in-the-game. Pracownik sprzedaży jest w tym przypadku twarzą produktu, ale miał bardzo mały (jeśli jakiś) wpływ na jego rozwój.
Nie patrzmy na rozwój produktu, a na jego finalny odbiór przez klienta. Zastanówmy się czy konstrukcja, w której pracownik obsługi jest SPOC jest dobra?
A żeby nie dywagować na abstrakcyjnych przykładach, przenieśmy się z powrotem na grunt Deweloperów i dewelopmentu.
Zespół
Tym samym lądujemy w Zespole. Wiele organizacji, z różnych względów oczywiście, załatwia sobie SPOC-a do najróżniejszych spraw. Jeden będzie zajmował się obsługą błędów, inny będzie przyjmował na siebie wszystkie zadania związane z konkretnym elementem produktu. Z punktu widzenia organizacji załatwiamy sobie spokój. Jest ktoś, kto się zajmie daną sprawą zawsze wtedy, kiedy będzie trzeba. Problem z głowy?
Podobna rzecz ma miejsce w Zespole Scrumowym. Nie patrząc na poszczególne kompetencje kapitału ludzkiego Deweloperów, w naszym Scrum Teamie mamy co najmniej dwie odpowiedzialności, które za Single Point of Contact mogą spokojnie „robić”. Jedną z nich jest Product Owner, drugą natomiast Scrum Master.
W tym miejscu, jeszcze bez wchodzenia w szczegóły powiem, że sprawa nie jest taka jednoznaczna. Z jednej strony posiadanie SPOC-a pomoże w niektórych sytuacjach, z drugiej zaś spowoduje, że zbytnio się usztywnimy i nasz Zespół nie będzie w stanie normalnie funkcjonować (patrz: Bus Factor). Gdzie znaleźć rozwiązanie?
SM jako SPOC
Sprawdźmy jak SPOC może to wyglądać i do czego może to doprowadzić. Rozpocznijmy od Scrum Mastera.
SM wydaje się być naturalnym SPOC-em dla wszystkich przeszkód, jakie się pojawią w Zespole. Część zależności międzyzespołowych czy najpilniejszych błędów również mogą trafiać do Scrum Mastera. SM może też być jedynym organizatorem i osobą przeprowadzającą wydarzenia Scrum. Pytanie brzmi: po co?
Z jednej strony, posiadanie osoby, która to wszystko ogarnie i zdejmie odpowiedzialność z Zespołu jest naprawdę cenna. Możemy sobie pozwolić wówczas na skupienie się na najważniejszym zadaniu, jakie zostało nam powierzone, a więc na wytwarzaniu produktu. Z drugiej strony, widząc takie rzeczy możemy być pewnie co najmniej dwóch rzeczy: Scrum Master będzie Scrum Mom, a na jego barkach leżeć będą wszystkie problemy Zespołu.
O negatywnych konsekwencjach „matkowania” zespołowi nawet nie piszę. Możecie przeczytać o skutkach tej postawy w podlinkowanym tekście. Z kolei zrzucenie wszystkich problemów zespołu na SM jest o tyle niebezpieczne, że wszyscy szybko poczują, że ma lokaja, a sam Scrum Master z Sevant Leadera stanie się „wynieś, przynieś, pozamiataj”.
To może PO jako SPOC?
Odpowiedzialność za wymagania w Backlogu to duża sprawa. Patrząc z punktu widzenia SPOC możemy doprowadzić do sytuacji, w której PO będzie barierą pomiędzy Zespołem, a Interesariuszami naszego Produktu. Nie będzie to problemem, gdy mierzymy się z tzw. „aktywnym biznesem”. Zadba on o swoje interesy i poprzez aktywną pracę z Backlogiem, Product Ownerem i Deweloperami osiągnie swoje cele. Idealnie do tego nadającym się wydarzeniem będzie Sprint Review.
Co jednak w przypadku, gdy PO postawi komunikacyjną tamę i nie pozwoli na swobodną wymianę informacji? Brak możliwość potwierdzenia lub przedyskutowania wymagań z biznesem spowoduje, że zamiast bezpośrednio pytać u źródła, musimy skorzystać z usług Single Point of Contact w postaci Product Ownera. Zakładając, że mamy tych wymagań więcej niż jedno, PO ze SPOC-a staje się wąskim gardłem procesu. Pamiętacie zabawę w głuchy telefon? Robimy dokładnie to samo, jesteśmy tylko jakieś ćwierć wieku starsi!
Innym problemem, z którym na pewno będziemy musieli się zmierzyć jest brak wiedzy Deweloperów co do sposobu myślenia czy długoterminowych planów naszego Klienta. Uczestnictwo Deweloperów w Sprint Review daje im możliwość przekonania się „czego oni faktycznie chcą”. Będzie jak znalazł, kiedy przyjdzie zmierzyć się z nie do końca jasnym wymaganiem.
Wnioski
Single Point of Contact nie zawsze musi przeszkadzać. Są sytuacje w których taka rola może przynieść prawdziwy oddech dla „chronionych”. Płynie z tego prosty wniosek, SPOC-a można mieć, ale tam, gdzie faktycznie się przyda i nie spowoduje negatywnych konsekwencji.
Gdyby ktoś zapytał się mnie o podstawowy problem z jednym punktem kontaktu, na pewno wskazałbym ograniczoną komunikację. A czasem nawet brak transparentności. W zwinnym procesie są one podstawą. Ich brak, chociażby w przykładach opisanych powyżej, może mieć poważne konsekwencje. Im więcej osób będzie miało wiedzę o wizji i celu tym lepiej dla całego Produktu. Pamiętajmy też o Bus Factor.
Szukając odpowiedzi na pytanie, czy potrzebujemy takiej roli warto wrócić pamięcią do przeszłości i zastanowić się, dlaczego SPOC powstał i jakie problemy pomógł nam rozwiązać? Czemu chcemy mieć „jedną osobę od…”? Czy chodziło wygodę Deweloperów? A może jest to odpowiedź na brak wystarczającej ilości pracy dla PO czy SM? Nigdy nie oceniajmy, dopóki nie dokonamy analizy przyczyn, jak i potencjalnych skutków.
