Zależności, konieczność komunikacji i koordynacji spowalniają realizację i zmniejszają skuteczność. Szczególnie dotyka to rozwoju produktów cyfrowych. By to zmienić trzeba zmienić sposób działania firmy. Dlaczego to ważne i od czego zacząć?
W artykule “Kto odpowiada za realizację OKR” piszę, że współpraca między zespołami powoduje straty wynikające z dodatkowych spotkań i ustaleń. Im więcej działań i ludzi trzeba zgrać, tym gorzej. Realizacja najlepiej idzie tam, gdzie zespoły są w stanie coś zmienić bez współpracy z innymi. Typowe struktury organizacji to utrudniają.
Stare struktury i nowe modele
Struktury firm 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, zwykle kilka poziomów od “góry”.
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 powołuje się zespoły i zrezygnować z pozostałych, niż pozwolić, by część sama się wyeliminowała z “braku zasobów”. Niestety często tak to w praktyce się odbywa.
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 mniejszym stopniu dotyczyły budowania kolejnego mostu, w większym – tworzenia kolejnego produktu cyfrowego. Mosty są do siebie podobne, każdy nowy produkt jest inny.
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 czekać na finał przed wprowadzaniem OKR. Metoda wymusza określenie priorytetów firmy. Powinny być odzwierciedleniem strategii, a sama organizacja dostosowana do jej realizacji. Analizując gdzie trzeba przyłożyć siłę i gdzie potrzebna jest współpraca można rozpocząć przebudowę organizacji. Trzeba jeszcze wyjaśnić 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”. Także podział terytorium czyli określenie kto odpowiada za poszczególne procesy / produkty (również te mające wewnętrznych odbiorców).
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.
To już jednak tematy na kolejne wpisy.