Jestem sponsorem. Kiedyś sam rozwijałem produkty, teraz zatrudniam osoby, które to robią. Przejście od jednej roli do drugiej, zrozumienie różnic i zmiana nawyków sporo mi zajęły. Co teraz ode mnie zależy, co muszę teraz robić? Czego nie powinienem? O tym nie przeczytacie na innych blogach…
Niewiele jest artykułów o roli sponsora, czy też pisanych z perspektywy sponsora w projektach dotyczących budowania produktów cyfrowych. Zwłaszcza takich, które wykorzystują scrum czy inne podejścia zwinne. Najłatwiej dowiedzieć się o tym co robi sponsor w waterfallu, komitetach sterujących i tym podobnych. Dostępna „literatura” o agile wydaje się udawać, że ktoś taki nie istnieje.
Twórcy scrum i jego wyznawcy idealizują świat wokół skupiając się na tym, co się dzieje w procesie pisania samego kodu. Sponsora wrzucają do worka „Management+interesariusze” => nie nasz problem. Może dlatego, że już w zespole jest wystarczająco dużo wyzwań, z którymi rzadko kto sobie radzi. Może dlatego, że nie ma zbyt wielu ludzi, którzy byli z obu stron… i uczestniczą w tej dyskusji.
Sponsor ma wpływ i znaczenie. Choćby dlatego, że zwykle jest szefem osób odpowiadających za rozwój produktów lub za biznes za nimi stojący. Trudno uniknąć jego obecności zwłaszcza w okresie transformacji – zmiany podejścia z tradycyjnego na zwinne. Stara rola nie da o sobie zapomnieć. Ludzie nie dadzą.
Najczęściej jest to osoba dużo bardziej doświadczona niż podwładni. Tak być powinno, w innym wypadku, od kogo mieliby się uczyć. Z tym doświadczeniem wiąże się najwięcej wyzwań. W pewnym zakresie wręcz wykorzystanie go jest jedną z rzeczy, których sponsor nie powinien robić.
Najważniejsza to unikać mikrozarządzania. Nie rozwijamy naszych ludzi mówiąc im co i jak mają robić. Przy rozwoju produktów jest to szczególnie trudne, bo oznacza powstrzymanie się od sugerowania rozwiązań i uwag na poziomie pikseli oraz szczegółów. Jest to również trudne, ponieważ często praca „seniora” jest pracą mentora, który uczy określonych kompetencji.
Z zasad scrum wynika, że sponsorowi nie wolno wręcz komunikować się z zespołem. Chodzi o to, żeby unikać merytorycznego wpływu na to, co robi zespół w czasie, gdy coś tworzy / buduje. Z jednej strony jest to życzeniowe, z drugiej zrozumiałe. Jakakolwiek furtka w tym zakresie łatwo rozmywa odpowiedzialność i tworzy pole do wymówek dla uczestników projektu.
Ostatni „zakaz” jest szczególnie ważny. Sponsor jest kluczowym uczestnikiem tego, co się dzieje wokół projektu. Tu ma jedno ważne „Nie” do zrobienia. Nie powinien spowalniać, w szczególności w jakimkolwiek stopniu opóźniać decyzji mogących mieć wpływ na projekt. Zespoły najlepiej działają, gdy są całkowicie autonomiczne – nie muszą czekać na wyniki działań, które są prowadzone poza nimi. To prosty przepis na porażkę, gdy muszą. W praktyce bardzo trudno całkowicie uniknąć jakiś zatwierdzeń czy rozstrzygnięć. I ich wpływ trzeba minimalizować niczego nie opóźniając.
Te „zakazy” są dość trudne w praktyce. Trudno się powstrzymać od podpowiadanie zwłaszcza, gdy świetnie się wie „jak” (a przynajmniej jest się przekonanym, że się wie). Na szczęście jest cała masa rzeczy, które sponsor robić powinien..
O tym jednak wkrótce.