Nie każda grupa ludzi to zespół. To niby oczywiste stwierdzenie, a jednak większość firm nazywa „zespołem” wszystko co może. Mają więc „zespoły” sprzedaży, wsparcia, architektów, czy analityków. To nadużywanie zespołowości w organizacjach powoduje, że często widzę brak zrozumienia w oczach liderów, gdy mówię im, że powinni zacząć pracować zespołowo. Dlatego ostatnio zaczynam rozmowy od zdefiniowania, czym zespołowość jest i czym nie jest. W ten sposób doszedłem do trzech najważniejszych cech zespołów.
1. Zespół posiada jeden, wspólny cel
Po pierwsze, członkowie zespołu muszą mieć wspólny cel. Znowu brzmi jak banał, a jednak gdy zapytasz poszczególnych członków za co im firma płaci, możesz się zdziwić, jak rozbieżne te cele będą. Najczęściej okaże się, że celem analityka jest zrobienie analizy, celem developera jest napisanie kodu, a celem testera przetestowanie. Teoretycznie są spójne, ale w praktyce każda osoba będzie optymalizowała swoją pracę, czyli starała się wykonać jak najwięcej tego co potrafi. I dzięki temu uzyskacie dużą ilość analizy, kodu, czy testów, a niekoniecznie tego, co ma wartość biznesową. Dlatego powinniście zacząć od ustalenia, co jest produktem pracy zespołu i to najlepiej z perspektywy końcowego użytkownika. A następnie potwierdzić z zespołem, że jest to ich wspólny cel.
Bez formalnych ról
W Scrumie idea wspólnego celu jest wykorzystana do maksimum, poprzez nazwanie osób pracujących nad produktem „developerami”. To trochę niefortunna nazwa, bo sugeruje programistów, natomiast chodzi o „product developers”, czyli wszystkich, którzy są niezbędni do dostarczenia kolejnej wersji produktu. Nie ma więc formalnych ról, chociaż oczywiście są specjalizacje, bo każdy ma swoje kompetencje. Jednak członkowie takiego zespołu zamiast zastanawiać się „jakie są moje zadania?” powinni skupić się na odpowiedzeniu na pytanie „co muszę zrobić, żeby osiągnąć nasz wspólny cel”. Pozwoli to na uniknięcie sytuacji, gdy ktoś przyjdzie na Przegląd Sprintu i stwierdzi „ja swoją robotę wykonałem, to tester nie skończył”. Tym samym praca zespołowa najczęściej wymusza wyjście poza swoje specjalizacje i sprawdzanie (najlepiej codziennie) „jak mogę pomóc reszcie mojego zespołu?”. Jeżeli chcesz zobaczyć przykład, jak członkowie zespołu mogą się wspierać nawzajem, to przeczytaj Case Study Siemensa.
Dedykowany
Jeżeli członek zespołu ma mieć jeden cel, to musi należeć do jednego zespołu. A nie do kilku, czy kilkunastu, jak to się dzieje w wielu firmach. Przypisanie pracownika do dwóch zespołów powoduje, że w momencie, gdy oba go potrzebują, ten musi zdecydować, któremu pomóc, a który zignorować. To raczej nie pomoże w osiągnięciu obu celów. Co oznacza, że nasz pracownik ustala, który z nich jest ważniejszy. O kosztach przełączania kontekstu między tymi zespołami już nawet nie wspomnę.
Dlaczego więc przypisanie ludzi do wielu zespołów jest tak popularne? Najczęściej z uwagi na wąskie specjalizacje, które pozwalają na szybkie wykonanie „moich zadań”. To co na pierwszy rzut oka wygląda na sensowne rozwiązanie szybko prowadzi do sytuacji, gdzie tematem X w całej firmie może się zająć tylko jeden człowiek – specjalista od X. A to jest już receptą na posiadanie wąskich gardeł i kolejek zdań czekających na specjalistów. W takiej sytuacji ciężko jest zbudować więcej niż jeden zespół mogący rozwiązywać problemy X. Dlatego w zespołach chcemy, żeby ludzie wychodzili poza swoje specjalizacje i uczyli się nowych kompetencji. Ponieważ wymaga to czasu, wsparcie ze strony firmy jest krytyczne.
2. Zespół jest niezależny na zewnątrz
Drugą cechą pozwalającą zespołowi na efektywne wykonywanie pracy jest brak zależności na zewnątrz. Oznacza to, że zespół powinien sam móc dostarczyć wartość bez proszenia innych o pomoc lub pozwolenie.
Interdyscyplinarny
Jeżeli zespół ma dostarczyć wartość dla użytkownika, to potrzebuje wszystkie kompetencje i wiedzę niezbędne do stworzenia kolejnej wersji produktu. Jeżeli jakiejś kompetencji mu brakuje, to pracując w Scrumie szybko się o tym dowie, gdy na koniec Sprintu niczego nie dostarczy. W takiej sytuacji musicie albo zbudować nowe kompetencje u członków zespołu, albo go poszerzyć o osobę, która ma odpowiednie kwalifikacje. W zależności od produktu potrzebne umiejętności mogą obejmować szeroki zakres – od zrozumienia potrzeb użytkownika, poprzez zaprojektowanie rozwiązania, znajomość różnych technologii i komponentów Waszego systemu, aż do przetestowania, udokumentowania, wdrożenia czy nawet promocji kolejnych wersji produktu.
Umocowany
Drugą konsekwencją oczekiwania od zespołu, że sam osiągnie cel jest danie mu odpowiedniej władzy. Najczęściej oznacza to możliwość podejmowania ważnych decyzji przez jego członków, ale również prawo do przeprowadzenia potrzebnych prac przez zespół. W przypadku tworzenia oprogramowania oznacza to zgodę na dokonywanie zmian w całym kodzie, czyli ograniczenie monopolu różnych grup na modyfikowanie ich komponentów. W przeciwnym przypadku potrzebne decyzje i zmiany będą lądowały w kolejce innych osób lub zespołów w firmie i tam czekały, aż ktoś się nimi zajmie.
Odpowiedzialny za osiągnięcie celu
Umocowanie zespołu oznacza również oddanie odpowiedzialności za stworzenie planu i śledzenie postępów pracy członkom zespołu. Zamiast więc kontrolować każdego członka zespołu z osobna lepiej jest popatrzyć na wspólny wynik całego zespołu na przykład na Review.
3. Zespół jest współzależny do wewnątrz
Trzecią, najmniej oczywistą cechą pracy zespołowej jest współzależność członków zespołu. Tłumacząc na przykładzie – czy grupa sprzedawców będzie „zespołem”? To zależy, czy jej członkowie potrzebują wsparcia pozostałych osób. Mogą mieć wspólny cel (np. sprzedaż na poziomie 1 mln zł), ale jeżeli każdy sprzedawca jest w stanie pracować niezależnie, to wszystkie „prace zespołowe” będzie traktować jako niepotrzebny narzut. Tak samo w dowolnej innej grupie, jej członkowie będą współpracowali jedynie z ludźmi, którzy są potrzebni do osiągnięcia celu. Można to łatwo zaobserwować na Daily, kiedy członkowie zespołu, zamiast ustalać co potrzebują od siebie nawzajem, zdają krótki raport, żeby jak najszybciej wrócić do swojej pracy.
Bez formalnych liderów
Formalni managerowie i koordynatorzy najczęściej spowalniają przepływ informacji – programista zamiast porozmawiać bezpośrednio z testerem poinformuje swojego szefa, którzy porozmawia z kierownikiem testerów, który wreszcie przekaże informacje swojemu podwładnemu. Wydawałoby się, że wolniej się nie da, ale jak dorzucimy do tego elektroniczne narzędzie do zarządzania zadaniami takie jak Jira, to coś co w normalnych warunkach zajęłoby pięć minut nagle trwa cały tydzień. Dlatego staraj się unikać formalnych kierowników wewnątrz zespołów (a tym bardziej na zewnątrz) i postaraj się, żeby każdy mógł porozmawiać z każdym. Oczywiście nie oznacza to, że wszyscy będą mieli to samo doświadczenie i ten sam wpływ na decyzje. Nie oznacza to również, że musisz kompletnie zrezygnować z managerów w firmie i mieć zupełnie płaską strukturę. Ważne jest jednak, aby dołączając do zespołu ludzie zostawiali „wizytówki” za drzwiami.
Samozarządzający
Jego w zespole nie ma formalnych managerów, to członkowie sami powinni ustalać zasady współpracy i w jaki sposób chcą pracować, aby osiągnąć wspólny cel. Te reguły będą zależeć zarówno od samego zespołu, organizacji, jak i tworzonego produktu czy realizowanego celu. Dlatego każdy zespół powinien poświęcić trochę czasu na ustalenie tych zasad i dobranie odpowiednich narzędzi, które pomogą im efektywnie osiągać ten cel. Oczywiście świetnie nadaje się do tego Retrospektywa, ale to nie jest jedyny sposób na ustalenie wspólnego procesu i wybór technik i narzędzi.
Nieduży
Jeżeli w zespole każdy ma pracować i rozmawiać z każdym, to ilość kanałów komunikacyjnych będzie rosła wykładniczo wraz z ilością osób w zespole. Inaczej mówiąc – trzyosobowy zespół ma tylko trzy kanały komunikacyjne, siedmioosobowy już dwadzieścia jeden, a jedenastoosobowy aż pięćdziesiąt pięć! Szansa, że ten ostatni będzie pracował jako jeden zespół jest niewielka. Raczej nastąpi naturalny rozpad na dwa pod-zespoły. Ustalenie wspólnych zasad współpracy przy tak dużej grupie ludzi też jest dużo trudniejsze. Dlatego staraj się budować małe zespoły. Oczywiście Waszym ograniczeniem będzie ilość potrzebnych kompetencji, dlatego tak ważne jest posiadanie ludzi potrafiących zrobić więcej niż jedną rzecz. W sytuacji, gdy duża grupa ma pracować nad jednym produktem dobrym pomysłem jest stworzenie kilku interdyscyplinarnych zespołów potrafiących niezależnie dostarczyć wartość dla klienta.
Zbudowanie zespołu zajmuje czas
Jak widzisz, wrzucenie grupy ludzi do pokoju i nazwanie ich zespołem nie zagwarantuje sukcesu. Musicie poświęcić czas, żeby zrozumieć nowe odpowiedzialności, zwłaszcza że ludzie nierzadko przychodzą ze środowisk, gdzie byli odpowiedzialni jedynie za swoje zadania. Również wypracowanie efektywnych zasad współpracy oraz poszerzenie kompetencji zajmuje czas. Dlatego staraj się utrzymywać stabilne zespoły, a nie zmieniać ich skład co miesiąc. W przeciwnym przypadku cały wysiłek, który poświęciliście na stworzenie zespołu pójdzie na marne. Często łatwiej jest nauczyć się nowych umiejętności w zespole, niż zbudować efektywny zespół od zera.
