Roy Osherove, podczas swojej prezentacji na WROC#, mówił, że genialny zespół rozwija się – nie da się go od zera stworzyć. Trzeba wykonać ciężką pracę, by zespół się ze sobą zgrał, poznał swoje słabe i mocne strony oraz sprawdził się w boju.
Mając za sobą praktykę Team Leadera, chciałbym opisać kilka kwestii na jakie warto zwrócić uwagę podczas prowadzenia zespołu programistycznego. Pewnie część będzie wam znana, ale przynajmniej część powinna być dla was interesująca i wartościowa.
Zebrało się ich aż 10 😀. Żeby nie zanudzać was ścianą tekstu w jednym artykule rozbiłem ten temat na mniejsze posty - po 2 porady w każdym.
// wszystkie porady zostały zebrane w podsumowaniu cyklu.
Poznaj mocne i słabe strony zespołu
Pamiętaj, że zespół to zbiór indywidualnych cech każdej z osób. Aby osiągnąć maksymalną wydajność zespołu trzeba poznać drzemiące w każdym możliwości i wykorzystać je w takiej formie, aby najlepiej się zgrywały i pokrywały. Inaczej współpracownicy nie będą się znać nawzajem i będą niepotrzebnie tracili czas na nieporozumienia.
Weźmy za przykład osobę, która często nie kończy powierzonych jej zadań i później ktoś musi to robić za nią. Może się okazać, że nie robi tego celowo – może to być jej naturalna cecha charakteru. Taka osoba będzie bardzo szybko poznawała domenę biznesową i rozpoczynała zadania. Natychmiastowo rozpracuje dany temat i pchnie go do przodu, ale pogubi się na końcowych detalach problemu. W takiej sytuacji warto znaleźć kogoś o przeciwnych cechach, kogoś kto uzupełni się ze wspomnianym kolegą i pomoże mu w sytuacjach, w których on sobie nie radzi.
Pomocne okażą się tutaj narzędzia typu Strength Finder, które rozpoznają mocne strony zespołu (i twoje również). Przegadując wspólnie te cechy dostrzeżecie, w jaki sposób rzutują one na wasze zachowania i podejmowane decyzje. Uświadomicie sobie, dlaczego w niektórych momentach ktoś reaguje w taki, a nie inny sposób. Taka analiza pozwoli lepiej zrozumieć swoje wady i zalety, co przyczyni się do zwiększenia zaufania i zbudowania głębszej więzi w zespole.
Pozwól ludziom popełniać błędy
Jest takie powiedzenie, że aby nie popełniać błędów trzeba mieć doświadczenie. Z drugiej strony, żeby mieć doświadczenie trzeba popełniać błędy. I tego nie przeskoczymy.
Trzeba dać ludziom przestrzeń, by w kontrolowanym otoczeniu mogli się sprawdzić i przetestować swoje umiejętności. Tylko w ten sposób będą mogli osiągnąć wyższy poziom swoich kompetencji. Sprawdzanie się w nowych sytuacjach rozwija nieznane wcześniej umiejętności i zachęca do dalszych prób, a co za tym idzie otwiera kompletnie nowy świat możliwości. My, jako team leaderzy, zyskujemy kolegę o szerszych horyzontach i lepszych umiejętnościach, kogoś, na kim można polegać w sytuacjach, w których jeszcze kilka miesięcy temu by sobie nie radził.
Świetnie pasuje tutaj cytat Alberto Brandoliniego “Development is a learning process, working code is a side effect” – im łatwiej twoim kolegom będzie się uczyć nowych technologii / praktyk / umiejętności, tym lepszy produkt będą oni tworzyć.
Oczywiście, nie zawsze dana próba się powiedzie. Niektóre mogą zakończyć się niepowodzeniem, które może rodzić demotywację. Naszą rolą jest wytłumaczyć, dlaczego coś się nie udało i dać feedback co następnym razem można zrobić lepiej. Pamiętajmy jednak, by nie rzucać pracowników od razu na zbyt głęboką wodę, ponieważ zniechęci ich do prób i zamknie ich w swoim własnym świecie.
Trzeba też pamiętać, że ktoś za błędy naszych współpracowników będzie musiał zapłacić. Może to być ten, kto popełnił błąd, inni członkowie zespołu siedząc po godzinach i naprawiając błędy, firma która decyduje się świadczyć usługę za darmo i naprawić błąd lub klient, który dostrzega potrzebę rozwoju i bierze koszt na siebie. Pomoże tutaj zasada „Fail fast and hard. Don’t fail silently.” – trzeba jasno dać do zrozumienia, że popełnienie błędu nie jest czymś złym, ale brak informacji o problemie będzie tylko potęgować nieprzyjemne konsekwencje dla samego zespołu.
