W plemionach drzemie potencjał. Dlaczego w Divante nie ma tradycyjnych zespołów?

Gdy Divante rozrosło się do 150 osób, założyciele postanowili usprawnić komunikację i współpracę pomiędzy pracownikami. Szukali inspiracji, którą znaleźli w strukturach Spotify. Zespół Divante przyjrzał się bliżej koncepcji plemion, skonsultował swój pomysł z innymi wrocławskimi firmami i przeprowadził transformację.

Grzegorz Bandurowski opowiedział nam o tym, dlaczego w Divante działają plemiona, kto jest wodzem plemienia oraz jak krok po kroku przeprowadzić taką transformację. Dla zrozumienia na czym polega ta zmiana, opracowaliśmy z Grzegorzem słownik pojęć:

• plemię – grupa specjalistów współpracująca ze sobą stale. W jej skład wchodzą osoby z wielu dziedzin: programiści, testerzy, analitycy i Project Managerowie. Ta grupa nie zostaje rozwiązana po zakończeniu projektu, tylko przechodzi do realizacji kolejnego.
• wódz plemienia – osoba prowadząca plemię od strony organizacyjnej, jak i operacyjnej, zajmuje się tym, by zespół pracował w sposób efektywny i przewidziany. Jest odpowiedzialna za motywowanie, feedbacki, a także sprawy “bardziej przyziemne”, takie jak urlopy czy zasady współpracy (podwyżki, zlecanie umów).

Divante wcześniej pracowało w tradycyjnej strukturze zespołów projektowych i działów specjalistycznych. Zespoły projektowe były zwykle rozwiązywane po zakończeniu projektów (specjaliści przechodzili wtedy do kolejnych projektów), a gdy dział programistów liczył blisko 100 osób, trudno było nim zarządzać i otoczyć specjalistów należytą opieką. Rozwiązaniem okazało się podzielenie firmy na mniejsze jednostki, tj. plemiona, które są bardziej samodzielnie, mają stały skład członków zespołu, sprzyjają budowaniu relacji, efektywności i jak najlepszych praktyk realizowania projektów.

Jak transformacja wyglądała od środka? Tego dowiecie się z poniższej rozmowy z Grzegorzem Bandurowskim.

Jak przed “transformacją” realizowały zadania zespoły w Divante?

Członków dobierano z dostępnych, bądź “uwalniających się” specjalistów przechodzących z kończących się projektów. Po jego zakończeniu, osoby wchodzące w jego skład otrzymywały nowe przydziały i migrowały do nowego zespołu.

Jaką rolę pełnił lider?

Lider był osobą techniczną, która prowadziła zespół projektowo, kontrolowała jego postępy i w razie potrzeby również angażowała się w ustalenia z osobami technicznymi po stronie Klienta. Zadania były przydzielane na spotkaniach planistycznych na podstawie dostępności oraz kompetencji poszczególnych członków zespołu projektowego. Kontrola odbywała się najczęściej w modelu AGILE za pomocą iteracyjnego podziału zakresu prac oraz spotkań statusowych / planistycznych.

Kto w starym modelu ponosił odpowiedzialność za błędy, niedociągnięcia, a jak to wygląda w plemionach?

Z reguły osobą, do której kierowane były jakiekolwiek zastrzeżenia do pracy zespołu był PM bądź Lider Technologiczny projektu. Obecnie jest podobnie, bo te role zostały utrzymane w ramach projektów. Jednak osobą, która globalnie odpowiada za wydajność oraz efekty pracy plemienia – jest Wódz i to on na końcu musi podjąć konkretne działania czy wziąć odpowiedzialność za pracę swoich specjalistów.

Dlaczego przeszliście na model znany m.in. ze Spotify i działacie na zasadach plemion? I dlaczego transformacji dokonaliście dopiero przy 150 osobach w firmie?

Przy 150 osobach w firmie i przy ilości zleceń, którą realizujemy – rotacja pomiędzy projektami / Klientami jest olbrzymia. Również działy (np. IT) zaczęły rozrastać się do takich rozmiarów, że codzienny kontakt przełożonych z ludźmi był bardzo ograniczony a co za tym idzie – szansa na wartościowy feedback, bardzo znikoma. Również budowanie kompetencji oraz utrzymywanie dobrych standardów wypracowanych w projektach było trudne, ponieważ zespoły, którym udało się wypracować efektywne środowisko pracy i komunikacji – były rozwiązywane na rzecz nowych zleceń.

Mieliśmy w historii firmy parę zespołów, które pracowały dla jednego Klienta, w stałym składzie przez dłuższy okres czasu – ich efektywność i zaangażowanie za każdym razem utwierdzały nas w przekonaniu, że właśnie w takich silnie zintegrowanych i doświadczonych zespołach specjalistów drzemie ogromny potencjał.

Oferty pracy z

Jak taka transformacja wyglądała krok po kroku?

Pojawiła się idea by skorzystać z modelu sprawdzonego przez Spotify, pojawiły się też pierwsze pomysły wokół jakiego “klucza” zawiązać pierwszy taki zespół oraz kto powinien go poprowadzić jako “wódz”. Zawiązaliśmy pierwszy zespół, który miał budować kompetencje w obrębie jednej z technologii wykorzystywanych przez nas w projektach, które już realizowaliśmy.

Był więc problem z utrzymywaniem stałych relacji pomiędzy członkami zespołów i feedbackiem. W jaki sposób szukaliście rozwiązania tego problemu?

Podjęliśmy się wymiany wiedzy z innymi firmami IT, które na wrocławskim podwórku porwały się na taki model i miały już jakieś doświadczenia z tym związane. Oprócz tego mocno przestudiowaliśmy sposób w jaki powstał pierwowzór (Spotify) i odnieśliśmy go do naszych firmowych realiów. Wytworzenie odpowiednich narzędzi czy mierników efektywności takiej nowoutworzonej grupy było jednym z najważniejszych zadań pierwszego wodza. To, co przez kwartał miała wypracować “Drużyna A” (nazwa pierwszego plemienia Divante) – miało dać początek i wzór odpowiednich praktyk dla kolejnych plemion w przypadku pomyślnej weryfikacji koncepcji.

Różnica między Divante a Spotify polega na tym, że Wy pracujecie dla klientów, a Spotify rozwija własny produkt. Zmieniło to coś w przygotowaniach do nowej organizacji pracy? Czy dało się przenieść format Spotify 1:1 do Divante?

Nie i nawet nie próbowaliśmy na siłę powielać 1:1 rozwiązań Spotify. Zainspirowaliśmy się ich podejściem do tematu i przełożyliśmy to na grunt naszej organizacji. Istnienie Klientów i tej części “usługowej” wymagało od nas wydzielenia trochę innego zakresu odpowiedzialności i ról wewnątrz zespołów, tak by wydzielić świadomie osoby odpowiedzialne za komunikację, choćby z Klientami. Jest również trochę inne podejście w kwestii planowania prac oraz ich rozliczania, które również rządzi się innymi prawami, a co za tym idzie – innymi sposobami kontroli oraz raportowania tych obszarów.

Czym taka praca w plemionach różni się od pracy w zespołach?

Przede wszystkim plemię jest stałe i nie rozpada się po ukończeniu wdrożenia / projektu. Wszyscy siedzą w jednym pokoju i komunikują się ze sobą bezpośrednio w razie pytań czy wątpliwości. Fakt, że współpracują ze sobą od dłuższego czasu – odbiera im cały ten narzut anonimowości, niepewności czy małego chaosu związanego z wymianą osób w zespole czy współpracą w zmieniającym się składzie osobowym.

Zaaranżowane spotkania i wymiana wiedzy wewnątrz plemienia sprzyja również wytwarzaniu procedur mających na celu zwiększenie efektywności oraz rozwiązań reużywalnych, które w obrębie danej technologii mogą zostać stworzone w sposób uniwersalny. Dzięki takiemu podejściu, każde kolejne wdrożenie czy realizacja jest bardziej optymalna, wolna od błędów i bogata w ciekawe rozwiązania, które pomagają nam w pracy. To pozwala nam z kolei skupić się na rozwoju oraz zorganizować sobie czas na kolejne wyzwania i zadania, które pchają nas do przodu (automatyzacja, skalowalność itd.).

Jak dużą swobodę mają plemiona?

Powiedziałbym, że dosyć sporą. Firma udostępnia narzędzia i pewne ramy, w których się poruszamy, ale ostateczna decyzja bądź moc sprawcza do podjęcia jakiegoś działania – jest już w gestii Wodzów. Co więcej, adaptacja jest wciąż w trakcie, w związku z czym to jakie wnioski oraz potrzeby płyną od samych plemion – jest bardzo szybko implementowane w kontekście całej firmy za sprawą Wodzów, którzy z kolei zbierają feedback i wymieniają opinie wewnątrz swoich zespołów.

Czy przejście na model pracy w plemionach zmienił proces rekrutacji?

Z punktu widzenia Działu HR w zasadzie nie. Z punktu widzenia dobierania osób do zespołu i bardziej świadomego podejmowaniu decyzji o pierwszych projektach danego specjalisty – myślę, że tak. Osoby są dobierane do plemienia, w którym lepiej mogą użyć swoich kompetencji. Wodzowie często też zgłaszają zapotrzebowanie na konkretnych specjalistów.

Z potencjalnymi kandydatami zdarza się też przeprowadzić dodatkową rozmowę o przydziale do konkretnej grupy specjalistów czy technologii w obrębie firmy i ma on możliwość porozmawiać ze swoim docelowym Wodzem. To daje obu stronom możliwość “dotarcia się” czy wybadania wzajemnych oczekiwań jeszcze przed oficjalnym rozpoczęciem współpracy. Oszczędza to rozczarowań.

Plemiona wymagają większych umiejętności miękkich od członków całego zespołu?

Zdecydowanie. Zespół jest stały, a wiadomo że im dłużej spędza się czas w danym gronie – tym łatwiej o pewien rodzaj frustracji czy irytacji. Dlatego bardzo istotne jest to jak takie osoby radzą sobie z relacjami między sobą, czy potrafią o tym rozmawiać i się dogadać. Relacja plemienna wymaga odpowiedzialności za słowa, empatii i bardziej rozwiniętych umiejętności komunikowania problemów oraz ich rozwiązywania. To nie zespół projektowy złożony z przypadkowych osób na pewien, ograniczony okres czasu. To bardziej forma relacji na zasadzie przywiązania i wzajemności.

Gdzie trafia nowy programista w zespole? Od czego zależy jego przydział?

Plemię posiada konkretny zasób projektów i odpowiedzialności. O przydziale programisty decyduje Wódz Plemienia w porozumieniu z Liderem Technologicznym. W oparciu o wywiad i konkretne kompetencje danego specjalisty, jest on przydzielany tak by: A. Wnieść jak największą wartość dla projektu / zespołu. B. Spełniać własne cele i ambicje w pracy. Oczywiście nie zawsze wszystko wygląda tak różowo, jednak to zawsze dla nas klucz. Specjalista musi się dobrze czuć w projekcie, a projekt musi odpowiednio korzystać na jego kompetencjach i zaangażowaniu.

Każdy pracownik może należeć do dowolnej drużyny, plemienia?

Nowi pracownicy są przydzielani na podstawie zapotrzebowań oraz kompetencji, jednak ich dołączenie musi zaakceptować Wódz. Specjaliści już “ulokowani” w konkretnych plemionach są z nimi raczej na stałe i nie zmieniają przydziałów.

Nie jest to jednak wykluczone i jeśli z jakiegoś powodu Wódz bądź konkretny programista uznałby, że będzie mu lepiej bądź bardziej przyda się w innym zespole – dokonujemy takich zmian. Często to odbywa się też pod kątem zmiany technologii. Ktoś chce programować w innym frameworku – zostaje przeniesiony do plemienia, w którym może się szybko nauczyć danej technologii i rozwinąć w jej obszarze.

Czy podział na plemiona widać na co dzień w biurze firmy? Każde plemię ma osobne miejsce w siedzibie?

Każde plemie ma swoje “skrzydło” w siedzibie głównej firmy. Przydział do plemion oraz podział ich ze względu na technologię czy Klientów jest jawny. Tak czy inaczej, jako wodzowie – staramy się dzielić wiedzę między swoimi zespołami i tworzyć im miejsce do kooperacji. Nie chodzi też o to by teraz wszystko realizować w zamkniętych zespołach i nie oglądać się na resztę firmy – bardzo staramy się do tego nie dopuścić.

A jak wygląda współpraca pomiędzy drużynami, plemionami?

Każde plemię ma Wodza, a Wodzowie spotkania operacyjne do podejmowania kluczowych decyzji w obrębie ich funkcjonowania. Na nich planujemy wspólne spotkania edukacyjne, warsztaty na podstawie jakiegoś rozwiązania / wiedzy wypracowanej w danym plemieniu. Tworzymy zespołom również przestrzeń do kooperacji w ramach swoich projektów, gdy widzimy taką okazję.

Jeśli ktoś ma ciekawy projekt, w którym dany specjalista może pomóc, a ja wiem że ma “wolny etat” i zawsze chciał mieć możliwość pracy w danym temacie – uzgadniamy zakres takiej kooperacji i umożliwiamy pracę na zasadzie “wypożyczenia”. Często również dobieramy konkretne, wiodące osoby w jakimś obszarze i spotykamy się, by wypracować wspólne rozwiązanie oparte o nasze doświadczenia i staramy się je równolegle sprawdzać czy wdrażać w pracy dla naszych Klientów.

Jak wymieniacie się wiedzą? W Spotify, od którego czerpaliście inspirację do utworzenia Waszych plemion, developerzy Java czy C++ tworzą bractwa, żeby rozmawiać o frameworku, w którym pracują. W Divante też jest na to miejsce?

Spotykamy się w gronie Wodzów oraz Tribe Leadów i dyskutujemy o tym, co będzie najlepsze dla danych osób / zespołów. Organizujemy spotkania EDU, które są prowadzone przez członków, ale są otwarte dla wszystkich osób w firmie. Staramy się również angażować wymiennie pewne osoby pomiędzy plemionami, tak by miały również przestrzeń do współpracy przy jakimś temacie i wymiany doświadczeń. Istnieje również plan utworzenia tzw. Gildii, które będą ponad plemionami zrzeszać programistów czy specjalistów z danego obszaru – tak by umożliwiać im edukację i wymianę wiedzy pomiędzy plemionami.

Co się dzieje, gdy jeden z członków plemienia odstaje od reszty? Gdy dłużej wykonuje zadania niż inni?

Otrzymuje wsparcie bądź (zależnie od braków) jest dołączany do projektu / grupy osób, która będzie w stanie poprowadzić czy rozwinąć go w danym obszarze. Juniorzy bądź słabsi technicznie członkowie nie są spychani do słabszych projektów – raczej staramy się dać im możliwości do podciągnięcia i rozwinięcia umiejętności na tyle by mogli być samodzielni.

Co zostało ze starego modelu? Co się nie zmieniło?

Duch firmy i atmosfera panująca w biurze. Organizacyjnie i operacyjnie, globalne wprowadzenie plemion i powołanie Wodzów w miejsce Dyrektorów działów bardzo mocno zmieniło to, jak działa firma. Nie zmieniła się za to generalna metodyka pracy, skład kompetencyjny zespołów, podejście do Klientów oraz model w jakim staramy się wdrażać projekty. Nadal mamy PMów, nadal mamy planning / daily, nadal wyceniamy zadania – po prostu organizacja pracy i komfort podejmowania decyzji czy współpracy w stałym środowisku osobowym mocno poprawił warunki pracy generalnie.

Z czym dzisiaj macie problem jeśli chodzi o plemiona? Jest zbyt duża migracja członków?

Nie mamy problemu z migracjami. Wciąż pracujemy nad wymianą doświadczeń i wiedzy pomiędzy plemionami – to jest coś na czym nam najbardziej zależy. Wciąż udoskonalamy integrację oraz możliwości współpracy pomiędzy plemionami. Na poziomie organizacyjnym, wciąż wypracowujemy też zakres decyzji, które mogą być podejmowane niezależnie na poziomie plemion, a które powinny być podejmowane wspólnie przez wszystkich Wodzów i przy konsultacji Zarządu firmy.

Model plemion zabija wyścig szczurów? W Divante nie ma jednostek tylko zespoły, które albo ponoszą porażkę, albo odnoszą sukces?

Myślenie, że jakakolwiek idea wyklucza zupełnie ten problem jest złudne. Zawsze ktoś będzie potrzebował czuć się bardziej wyróżniony czy dostać lepszy projekt. Uważam jednak, że w modelu plemion ludziom łatwiej jest sobie z tym radzić, łatwiej akceptować pewne sytuacje, które mogą taki wyścig wywołać. Dodatkowo wódz oraz członkowie plemienia mają więcej możliwości do wyłapywania i przeciwdziałania takim zachowaniom (retro, feedbacki, dobra znajomość siebie nawzajem).

Grzegorz Bandurowski. Senior Project Manager i Tribe Master w Divante. Od 6 lat pasjonat Project Managmentu oraz praktyk stosowanych przy zarządzaniu projektami IT. W swojej karierze prowadził wdrożenia zarówno startupowych aplikacji Web / Mobile, jak i ogromnych serwisów e-commerce dla liderów rynku. W Divante odpowiedzialny za największych Klientów z polskiego rynku, jak również liderów na rynkach zagranicznych. Ostatnio „wódz plemienia” i opiekun pierwszej organizacji na zasadzie TRIBE, która ma za sobą już dwa duże wdrożenia w nowej technologii oraz szereg wypracowanych procedur zwiększających efektywność wdrożeń IT. Prywatnie muzyk (gitarzysta) i pasjonat amerykańskiej ligi NBA.