Dwie osoby w zespole poprawiają tę samą treść na stronie, każda w innym miejscu, żadna nie wie o pracy drugiej. Klient dostaje sprzeczne odpowiedzi od dwóch różnych osób w tej samej sprawie. To nie problem z komunikacją - to problem z organizacją pracy zespołu, a dokładniej z brakiem jasnego podziału ról i obowiązków.
Im więcej osób w zespole, tym łatwiej o sytuację, w której nikt nie wie, kto za co odpowiada. Zespół działa wtedy chaotycznie nie dlatego, że ludzie są niekompetentni, tylko dlatego, że nikt nigdy nie usiadł i nie ustalił, kto podejmuje jakie decyzje.
W tym artykule pokażę, jak podzielić role i obowiązki w zespole, żeby praca się nie dublowała, jak reagować, gdy zakresy odpowiedzialności zaczynają się nakładać, i jak komunikować ten podział nowym osobom dołączającym do zespołu.
Dlaczego niejasny podział ról spowalnia zespół
Gdy nikt nie wie, kto decyduje o danej sprawie, decyzje albo nie zapadają wcale, albo zapadają kilka razy przez różne osoby - z różnym skutkiem. Zespół traci czas nie na samą pracę, tylko na ustalanie, kto w ogóle powinien tę pracę wykonać.
Drugi efekt niejasnego podziału ról to podwójna praca. Dwie osoby, każda przekonana, że to ich zadanie, wykonują tę samą rzecz niezależnie od siebie - co jest stratą czasu równie kosztowną jak sytuacja, w której nikt nie robi nic, bo każdy zakłada, że zajmie się tym ktoś inny.
Jak zacząć - mapowanie odpowiedzialności
Zanim zespół zacznie dzielić zadania, warto spisać, jakie obszary decyzji i pracy w ogóle istnieją w projekcie - na przykład kontakt z klientem, decyzje o zakresie prac, code review, testowanie, publikacja treści. Dla każdego obszaru trzeba ustalić, kto go realizuje, a kto podejmuje ostateczną decyzję, gdy pojawia się spór.
Pomocne bywa proste rozróżnienie: kto wykonuje pracę, kto ją zatwierdza, kogo trzeba poinformować o wyniku, a kogo warto skonsultować przed rozpoczęciem. Nie trzeba tworzyć rozbudowanej macierzy dla każdego drobnego zadania - wystarczy zastosować to rozróżnienie do kilku największych obszarów odpowiedzialności w projekcie.
Przykład: agencja digital marketingu mapuje odpowiedzialności dla obszaru "publikacja treści na blogu klienta". Okazuje się, że treść pisze copywriter, zatwierdza ją strateg konta, publikuje specjalista SEO, a klienta trzeba tylko poinformować o publikacji, bez konieczności jego akceptacji na każdym etapie. Wcześniej wszystkie cztery osoby czuły się odpowiedzialne za każdy z tych kroków, co prowadziło do opóźnień.
Role w zespole projektowym i ich zakres
Właściciel produktu
Odpowiada za priorytety i decyzje o tym, co zespół robi w pierwszej kolejności. To ostateczny głos w sprawach zakresu pracy, nawet jeśli decyzje konsultuje z resztą zespołu.
Osoba realizująca zadanie
Odpowiada za wykonanie konkretnej pracy zgodnie z ustaleniami. Ma prawo zgłaszać wątpliwości co do wykonalności zadania, ale nie podejmuje decyzji o priorytetach całego projektu.
Osoba koordynująca
Pilnuje, żeby praca płynęła bez przeszkód - usuwa blokady, dba o komunikację między osobami realizującymi zadania a właścicielem produktu. Nie wykonuje zadań merytorycznych, tylko dba o sam proces pracy zespołu. W zespołach pracujących w Scrumie tę rolę pełni zwykle Scrum Master - więcej o samej metodyce w artykule Scrum - kompletny przewodnik dla początkujących.
W małych zespołach jedna osoba często łączy dwie z tych ról naraz, na przykład właściciela produktu i koordynatora. To normalne, o ile obie funkcje są świadomie przypisane, a nie po prostu domyślnie przejmowane przez najbardziej zaangażowaną osobę w zespole.
Jak unikać dublowania pracy
Najprostszym sposobem na uniknięcie dublowania pracy jest zasada jednego właściciela zadania - każde zadanie ma przypisaną dokładnie jedną osobę odpowiedzialną za jego wykonanie, nawet jeśli w pracę zaangażowanych jest więcej osób. Dzięki temu w razie wątpliwości wiadomo, do kogo się zwrócić.
Przykład: w zespole marketingowym dwie osoby przygotowują ten sam post na social media, bo obie widziały to zadanie na wspólnej liście i żadna nie sprawdziła, czy ktoś już nie zaczął pracy. Rozwiązaniem jest prosta zasada - zanim ktoś zacznie zadanie, oznacza je jako swoje, widoczne dla całego zespołu, a nie tylko w prywatnej notatce.
Co zrobić, gdy zakresy ról się nakładają
Nakładanie się ról to nie zawsze błąd - czasem wynika z naturalnej bliskości dwóch obszarów pracy, na przykład testowania i code review. Problemem staje się dopiero, gdy nikt nie ustalił, jak te dwie role mają ze sobą współpracować.
W takich sytuacjach pomaga krótka rozmowa między osobami, których role się przecinają, zakończona prostą zasadą - na przykład, że code review zawsze poprzedza testy manualne, a nie odwrotnie. Ważne, żeby taka zasada została zapisana i dostępna dla całego zespołu, a nie tylko zapamiętana przez dwie osoby, które ją ustaliły.
Jeśli konflikt ról powtarza się regularnie, dobrym momentem na jego rozwiązanie jest regularne spotkanie zespołu, a nie kolejna doraźna rozmowa na czacie, która i tak zostanie zapomniana za tydzień.
Warto też odróżnić nakładanie się ról od zwykłego braku zaufania. Czasem dwie osoby wchodzą sobie w kompetencje nie dlatego, że podział jest niejasny, tylko dlatego, że jedna z nich nie ufa, że druga wykona zadanie poprawnie, i sama sprawdza albo poprawia jego pracę. To już nie problem organizacyjny, tylko sygnał, że w zespole trzeba wprost porozmawiać o zaufaniu i kompetencjach, zanim dalsze ustalanie zasad przyniesie efekt.
Jak komunikować podział ról nowym osobom w zespole
Nowa osoba w zespole nie zna niepisanych zasad, które reszta zespołu wypracowała miesiącami. Bez jasnego wytłumaczenia, kto za co odpowiada, nowy członek zespołu albo nie podejmuje żadnych decyzji z obawy przed przekroczeniem kompetencji, albo przypadkiem wchodzi w zakres cudzej odpowiedzialności.
Podział ról i obowiązków powinien być jednym z pierwszych tematów podczas wdrażania nowego członka zespołu - najlepiej w formie krótkiego, spisanego dokumentu, a nie ustnego wyjaśnienia, które łatwo zapomnieć w pierwszym tygodniu pełnym nowych informacji.
Warto też jasno wskazać nowej osobie, do kogo konkretnie zwrócić się z pytaniem w danym obszarze - zamiast zostawiać ją z ogólnym "pytaj, jeśli czegoś nie wiesz", co w praktyce oznacza brak jakiegokolwiek punktu kontaktu.
W małych zespołach, gdzie jedna osoba pełni kilka ról naraz, ten krok bywa pomijany, bo wydaje się oczywisty dla obecnych członków zespołu. Nowa osoba jednak nie ma tej wiedzy - dlatego nawet w zespole liczącym cztery czy pięć osób warto spisać podział ról tak samo dokładnie, jak w większej organizacji. Więcej o samej organizacji pracy w takich warunkach przeczytasz w artykule jak efektywnie zarządzać projektami w małym zespole.
Organizacja ról w Taskello
W Taskello każde zadanie ma przypisaną konkretną osobę odpowiedzialną, dzięki czemu unika się sytuacji, w której dwie osoby niezależnie zaczynają tę samą pracę. Osoba przypisana do zadania jest widoczna dla całego zespołu, więc nikt nie musi pytać, kto się czymś zajmuje.
Role w projekcie - na przykład kto zarządza obszarem roboczym, a kto tylko realizuje przypisane zadania - można ustawić na poziomie uprawnień, zamiast polegać wyłącznie na ustnych ustaleniach. Dzięki temu podział odpowiedzialności jest widoczny w samym narzędziu, a nie tylko w pamięci osób, które go ustaliły, podobnie jak przy delegowaniu zadań w zespole.
Jasny podział ról nie sprawia, że zespół pracuje sztywniej - przeciwnie, daje każdej osobie pewność, w jakim obszarze może podejmować decyzje samodzielnie, a kiedy skonsultować się z kimś innym. To ta pewność, a nie dodatkowa biurokracja, sprawia, że praca zespołu przestaje się dublować.
Warto raz na jakiś czas wrócić do spisanego podziału ról i sprawdzić, czy nadal odzwierciedla rzeczywistość. Zespoły rosną, projekty się zmieniają, a role ustalone pół roku temu mogą już nie pasować do obecnego składu i zakresu prac - lepiej zauważyć to samodzielnie, niż dowiedzieć się o tym dopiero z kolejnej sytuacji zdublowanej pracy.