Zależności i potrzeba koordynacji spowalniają realizację zmniejszając skuteczność działań. W rozwoju produktów cyfrowych odpowiedzią na ten problem są autonomiczne, multidyscyplinarne zespoły. Dlaczego to ważne i od czego zacząć?

Im więcej działań i ludzi trzeba zgrać, tym gorsze są wyniki. Realizacja najlepiej idzie tam, gdzie niewielkie zespoły są w stanie coś zmienić bez czekania na innych. Typowe struktury organizacji to utrudniają.

Stare struktury i nowe modele

Struktury te ciągle podobne są do ustalonej ponad 100 lat temu dla Tabulating Machines (dziś IBM). Pionowo, według funkcji, organizują się nawet świeżo zakładane startupy. Wynika to z zależności merytorycznej – sprzedawcy są zatrudniani przez szefów sprzedaży i tak dalej. Większość menedżerów jest przekonana, że tak powinno być. Jednak praca najczęściej odbywa się w poprzek struktur.

W 2012 roku opisany został tzw. “model Spotify”. Firma postawiła w nim na niezależne zespoły złożone z ludzi o różnych specjalizacjach. Skład każdego miał wystarczyć by opracować i wdrożyć zmianę w produkcie. Zainspirowało to do reorganizacji między innymi holenderski bank ING.

Amazon przeszedł długą drogę, by postawić na zespoły “jednowątkowe” – samodzielne i zajmujące się jednym obszarem. Można o tym przeczytać w książce “Working backwards”. Zarządzający doszli do wniosku, że żaden temat nie pójdzie do przodu, jeśli nie będzie miał dedykowanego zespołu, który może się na nim skupić. Lepiej wybrać przedsięwzięcia, dla których warto powołać zespoły i zrezygnować z pozostałych, niż pozwolić, by część sama się wyeliminowała z “braku zasobów”.

Najczęściej wszystko rozbija się o “zasoby IT”. Od technologii wszyscy czegoś chcą a znacznie więcej czasu zajmuje tu wprowadzanie zmian niż ich wymyślanie. By to uporządkować tworzy się procesy zapewniające priorytetyzację i koordynację realizacji. Szybko okazuje się, że trudno uzyskać tempo działania potrzebne do rozwoju produktu.

Nigdzie stare metody organizacji pracy tak nie obnażyły swoich wad jak przy rozwoju produktów wykorzystujących oprogramowanie. Zajmuje się nim coraz więcej firm. Czytam właśnie o odwołaniu prezesa Volkswagena, który nie był stanie zapewnić terminowego rozwoju systemu operacyjnego samochodów. Takie problemy wymuszają zmiany, które Steve Deming nazwał “kopernikańskim przewrotem w zarządzaniu”.

Zespoły produktowe czy projektowe?

Temat nie jest nowy, w 2016 roku na swoim blogu pisałem: “fundament w rozwoju produktów to autonomiczne zespoły dobrych ludzi, których łączy wspólny cel. To jest tak ważne, że nie wiem jakim cudem jeszcze o tym nie napisałem”.

Jednak w zarządzaniu rzeczy zmieniają się wolno. Prowadząc w latach 2018-2020 zajęcia programu Management ICAN pracowałem z dziesiątkami menedżerów z całej Polski. Temat zespołów produktowych i “model Spotify” znali nieliczni. Najczęstsze skojarzenie jakie się pojawiało to “zespoły projektowe”. To jednak pozorne podobieństwo.

Zespoły projektowe powołuje się tylko na jakiś czas. Dobiera się ludzi, określa cel, zakres i budżet zmiany po czym planuje jej realizację w określonym terminie. Zwykle projekty nie osiągają założonych korzyści przy zaplanowanych kosztach i w założonym czasie. Dzieje się tak zwłaszcza, gdy dotyczą stworzenia czegoś, co organizacja robi po raz pierwszy. W największym stopniu dotyczyły to budowy produktów cyfrowych.

Zakres, czas i budżet – nie ma pewnych metod panowania nad nim w rozwoju produktów. Zbyt wielu rzeczy nie da się przewidzieć. Gdy produkt zostaje wprowadzony na rynek, nie można przestać się nim zajmować. W przypadku sukcesu, trzeba wprowadzać zmiany by spełniać oczekiwania klientów. Gdy produkt nie jest trafiony – przez jakiś czas zwykle próbuje się go modyfikować, by to zmienić.

Trudno założyć, kiedy “zwolnią się zasoby”, co w projektach się planuje. Poziom współpracy niezbędnej do rozwoju produktów rzadko występuje w zespołach projektowych, których członkowie często mają jeszcze “inne obowiązki”. Z tych powodów na początku trzeba zadać pytanie, czy wartość związana z produktem ma na tyle duże znaczenie dla organizacji, by zapewnić mu zespół na nieokreślony czas. W nielicznych wypadkach odpowiadać na nie twierdząco, a potem wypracować skuteczny model pracy zespołów. Proste, prawda?

W stronę zespołów

Zarządzającym Amazon dojście do jednowątkowych zespołów zajęło lata. W Spotify mówią, że szukanie modelu pracy takiej organizacji nigdy się nie kończy. Nie trzeba jednak czekać na finał tego procesu przed wprowadzaniem OKR.

Metoda wymusza wyjaśnienie strategii i określenie priorytetów. Powinno z tego wynikać, gdzie trzeba przyłożyć siłę. Z tą wiedzą można rozpocząć przebudowę organizacji. Trzeba przy tym wpłynąć na trzy rzeczy.

Rola menedżerów. W tradycyjnym podejściu menedżer działu ma sprawiać, że rzeczy “się dzieją”. W nowym zależności pionowe związane z zatrudnianiem specjalistów pozostają bez zmian. Nie mogą jednak “nadpisywać” decyzji podejmowanych w ramach zespołów. Sukces menedżera, to sukces zespołów, w których pracują jego ludzie.

Odpowiedzialność. Wyjaśnienie co to słowo oznacza, tam gdzie to zespoły “robią rzeczy”. Definiowanie odpowiedzialności to także podział terytorium czyli określenie kto odpowiada za poszczególne procesy / produkty.

Definicja zespołu. Na skuteczność zespołu wpływa dobór ludzi, ich liczba, określenie celu i sensu istnienia, sposób pomiaru wyników i wiele wiele więcej. Fundamentalna jest rola lidera.