To jest 289. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT SolidJobs, który mam przyjemność współtworzyć, dyskutujemy o tematach związanych z byciem liderem i zarządzaniem zespołem IT.

Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania.

Odpalamy!

 

Cześć, Łukasz.

 

Cześć, Krzysztofie.

 

Nasze kolejne spotkanie w ramach serii podcastów dla lidera i managera IT. Dzisiaj będziemy mówić o temacie, który oczywiście jest złożony, skomplikowany, wpływa na niego wiele różnych rzeczy, ale rolę, jaką odgrywa lider i manager jest też nie do przecenienia, mianowicie efektywność zespołu IT. 

Bo to nie tylko szybkie dostarczanie wartości, ale również mądre dostarczanie wartości, na co dzisiaj będziemy zwracać uwagę. Właśnie, Łukasz, co według Ciebie jest takimi cechami, które definiują efektywny zespół? 

 

Dla mnie efektywny zespół to po prostu taki zespół, który dowozi. Dowozi wartość, dowozi rzeczy na czas i dowozi je też w jakiejś rozsądnej jakości. Tak, że po prostu końcowy klient, użytkownik jest zadowolony z tych efektów pracy. 

I tak bym też w ogóle patrzył na tę efektywność zespołu przez pryzmat właśnie tego produktu końcowego. Oczywiście to nie musi być oprogramowanie. Też np. jeśli mamy zespół wsparcia użytkownika, to będzie to jakieś tam zadowolenie na przykład z tego, że nasze problemy są rozwiązywane na czas i sprawnie te rozwiązania też są znajdowane. 

 

Tak, ja bym też postawił na tę skuteczność, czyli jednak efekt do dowożenia. To jest coś, co jest najistotniejsze. Na koniec dnia to jednak biznes właśnie w tym upatruje wartość, czy też sens istnienia działu IT, żeby było dostarczane to, co powinno być dostarczane. 

Ale widzę też tutaj taki istotny aspekt trwałości w czasie, bo pewnie łatwo jest stworzyć taki zespół, jak to ma miejsce na przykład w game development, gdzie wypalamy się niejako, tworzymy co prawda szybko, ale jednak ten zespół później musi te rany swoje lizać. Chodzi mi o to, aby w czasie ten zespół był w stanie dowozić podobną wartość i działać ponownie też podobnie sprawnie, i to jest, myślę, tutaj też istotny element efektywności zespołu. 

To nie musi być zawsze dostarczanie najszybciej, to nie musi być zawsze dostarczanie czegoś z najwyższą jakością, ale taka przewidywalna jakość w czasie. 

 

Ten nacisk na jakość jest ważny, bo co z tego, że dostarczymy bardzo szybko, bardzo dużo, jeśli potem w kolejnych przyrostach, w kolejnych sprintach, w kolejnych jakichś okresach czasu będziemy zmuszeni zredukować znacznie po prostu tę taką pozorną efektywność na rzecz tego, że będziemy musieli poprawiać jakieś bugi, błędy, a nie będziemy już dostarczać właśnie tych nowych wartości. 

Ważne jest właśnie to, żeby to, co dostarczamy, żebyśmy dostarczali też mądrze. Też tutaj cechą pewnie efektywnego zespołu jest to, że właśnie zanim coś zacznie robić, to przemyśli, czy w ogóle warto robić to, co tutaj jest do zrobienia, bo może to jest bez sensu, żeby robić jakąś rzecz, bo możemy to rozwiązać jakoś poza systemem. Często tak bywa, albo może coś już jest gdzieś i można to wykonać inaczej, tylko na przykład ktoś, kto tutaj te wymagania nam dostarczył, nie wiedział, że np. nie wiem, można coś zrobić, może najpierw porozmawiajmy, że nie wiem, da się tutaj zrobić coś jakimiś mniej uczęszczanymi ścieżkami po prostu w programie, czy właśnie jakąś, rozwiązać jakąś procedurą po prostu, a nie konkretnym featurem. 

 

Dokładnie. Wtedy może się okazać, że dowozimy szybko, bo na przykład skorzystamy z gotowych komponentów, albo w ogóle nie stworzymy jakiegoś rozwiązania, bo w drodze rozmowy z klientem okaże się, że jednak nie jest to potrzebne, albo da się zrealizować właśnie inaczej. Wtedy połączymy tę szybkość dostarczania z efektywnością. 

 

Tak, tu też poruszyłeś taką ciekawą kwestię korzystania z czegoś, co już jest, z jakichś gotowych komponentów, z jakichś gotowych bibliotek, czy też po prostu z innych narzędzi, bo czasami to też może być tak właśnie, że skorzystamy z dwóch różnych narzędzi i to nie jest problem, że to był taki jakiś fikcyjny problem, że ktoś sobie wyobraził, że wszystko musi być w ramach tego jednego systemu.

Co mi przychodzi do głowy na przykład, to czat w systemie. Też wielokrotnie w różnych sytuacjach słyszałem, że jest potrzebny czat. A są dedykowane narzędzia takie jak na przykład właśnie Microsoft Teams czy Slack, które pewnie robią to lepiej, efektywniej i niekoniecznie to musi być coś, co będzie wbudowane w nasz system. 

 

Dokładnie, czyli takie mądre tworzenie rozwiązań to też tutaj wpływa bezpośrednio na efektywność widzianą z zewnątrz, tak jak efektywność zespołu IT. Więc wydaje się, że dla managera IT jest tutaj oczywisty przepis. Weźmy pięciu, sześciu super efektywnych programistów, stworzymy z tego zespół, który jest ekstra, hiper efektywny, ale czy aby na pewno?

 

Tutaj jest właśnie ta kwestia efektywności indywidualnej a zespołowej i pytanie, czy efektywność zespołu to jest po prostu suma tych efektywności jednostek, czy jednak nie. Bo z moich doświadczeń to bywa tak, że ogólnie w zespole mamy różnych ludzi, raczej to jest rzadko spotykane, że mamy samych tam hiper super graczy A, jak to mówią, tylko jest rozkład normalny. 

I teraz z moich doświadczeń zawsze było tak, że ogólnie dobry zespół i jedna trochę gorsza osoba, to ten zespół tą osobę potrafił ładnie podciągnąć i po jakimś czasie po prostu ta osoba stawała się takim pełnoprawnym, nazwijmy to, członkiem zespołu i dawała tutaj rzeczywiście taką średnią wartość jak inni. 

Też spotykałem się z takimi sytuacjami, gdzie przeciętny zespół i jedna wybitna jednostka, też ta wybitna jednostka potrafiła tutaj podciągnąć cały zespół do góry i sprawić, że cały zespół stawał się, no może niewybitny, ale bardzo dobry. 

Tutaj też chyba kiedyś rozmawialiśmy o tym serialu Chicago Bulls, gdzie był przykład Michaela Jordana, który przyszedł do zespołu i z zespołu, powiedzmy, przeciętniaków zrobił, jedna jednostka wybitna zrobiła z nich mistrzów. 

 

Tak, zgadza się. No myślę, że tutaj jednak takie działanie czysto ludzkie, czyli dążenie do tego jak działa grupa, ma swoje bezpośrednie przełożenie, tak. Jeśli obracamy się wśród efektywnych osób, to mamy jakąś tam chęć, żeby przynajmniej dorównać temu poziomowi. 

Ale tutaj według mnie stoi za tym jeszcze jedna rzecz, za tym, że nie możemy stawiać znaku równości pomiędzy taką sumą efektywności indywidualnych i efektywnością zespołu. Mianowicie to, że na efektywność zespołu ma wpływ coś, co nazwałbym kulturą organizacyjną, sposób zarządzania, całe otoczenie, na które być może ta grupa osób po prostu nie ma wpływu, ale jest pod wpływem właśnie tych czynników. Więc chociażby to, jakie są relacje w zespole, w jaki sposób tutaj jest ten zespół zarządzany, ma bezpośrednie przełożenie na efektywność i na dowożenie realizowane przez ten zespół. 

 

Tak, i tutaj właśnie wchodzi rola tego lidera zespołu, kierownika, czy jak zwał, Scrum Mastera może, który po prostu spaja ten zespół i tutaj pomaga budować relacje, pomaga też w tym, żeby nie było jakichś przeszkód w tym, jak pracujemy. 

 

Tak. Wpływ organizacji jest też według mnie mega istotny, bo jeśli działamy w jakimś dużym zespole, gdzie nasza sprawczość, decyzyjność jest praktycznie zerowa, to automatycznie będzie nam się chciało mniej. Nawet jeśli będziemy mieli jakieś ciekawe pomysły, fajne usprawnienia itd., to i tak będzie mała szansa, że będą one w stanie być zrealizowane i wcielone w życie, więc musimy mieć takie umocowanie w organizacji, jak to się pięknie nazywa, żeby też mieć tę sprawczość, która później będzie widoczna właśnie w efektywności. 

 

Tak, zdecydowanie. Zespół musi być taką samodzielną jednostką, która ma tę decyzyjność, ma tę sprawczość i ma kontrolę nad tym produktem, który tworzy. Oczywiście, wiadomo, że jest jakiś z zewnątrz klient, który mówi, co chce, ale jeśli chodzi o to, jak to zrealizować, to w moim mniemaniu zespół musi mieć tę sprawczość. 

Tak, zdecydowanie. Zespół musi być taką samodzielną jednostką, która ma tę decyzyjność, ma tę sprawczość i ma kontrolę nad tym produktem, który tworzy. Oczywiście, wiadomo, że jest jakiś z zewnątrz klient, który mówi, co chce, ale jeśli chodzi o to, jak to zrealizować, to w moim mniemaniu zespół musi mieć tę sprawczość.

 

Oczywiście tutaj zależy też od tego, w jaki sposób zarządzamy produktem czy projektem, ale nie możemy zapominać o tym, że ten zespół ludzi, których zatrudniamy, to są często naprawdę łebscy ludzie, którzy mają dobre pomysły. 

Szkoda byłoby tego nie wykorzystać, więc myślę, że efektywność tutaj jak gdyby zyska na tym, jeśli pozwolimy tym osobom się wypowiadać, pozwolimy im zgłaszać jakieś pomysły, usprawnienia, zgłaszać uwagi, to tylko będzie z korzyścią, ponieważ takie raz prowadzone procesy, które zostały ukształtowane, ale się nie zmieniają, pomimo tego, że całe środowisko się zmienia, z czasem po prostu nam tą efektywność umniejszają. Musimy pozwolić tym osobom, które na co dzień te procesy są gdzieś tam uwikłane, które się nimi zajmują, aby miały możliwość te procesy usprawniać. 

 

Tak, czyli podsumowując ten punkt, zespół efektywny to zespół zmotywowany i zespół posiadający decyzyjność. 

 

Dokładnie i wsparcie ze strony bezpośrednich przełożonych, jak również całej organizacji. Ale nawet jeśli mamy taką korzystną kulturę, takie korzystne środowisko do pracy, ale nie mamy odpowiednich narzędzi, to wiadomo, że ta praca nam nie będzie szła i nie będzie to się przejawiało w postaci szybkości i jakości. Więc te narzędzia pracy, którymi powinniśmy operować, które mamy do dyspozycji, też wpływają bezpośrednio na naszą efektywność. 

 

Tak, i to mogą być naprawdę takie pierdoły, jak brak dodatkowych monitorów albo np. mamy tylko jeden monitor w biurze, a do pracy zdalnej już nam nie przysługuje. To może być brak jakiejś licencji, gdzie byliśmy np. przyzwyczajeni do ReSharpera, a w nowej firmie w ramach oszczędności nie otrzymujemy tego typu narzędzi. Teraz w dobie AI brak np. jakiejś licencji na Chata GTP czy inny tutaj odpowiednik. 

Co to jeszcze może być? No sam sprzęt, może dostaliśmy po prostu jakąś maszynę po kimś i zamiast po prostu iść do przodu, to często czekamy, walczymy ze sprzętem. Za mały dysk to może być. Też jakby tutaj spotkałem się z problemem, że cały czas na czerwono i żeby przejść między jednym projektem a drugim, to trzeba wykonać ileś czynności dodatkowych. To są naprawdę takie rzeczy, które nie powinny mieć miejsca w normalnym funkcjonowaniu. 

 

Oczywiście, chociażby to, że nie wykorzystujemy pipeline’ów CI/CD, to, że nie wykorzystujemy chmury, to, że no nie wiem, nie ma środowisk testowych itd., wszystko to zwyczajnie będzie wydłużało niepotrzebnie czas na wytwarzanie kodu na jego testowanie, wdrażanie itd. Dałoby się temu łatwo zapobiec, po prostu korzystając z narzędzi. A jak sobie spojrzymy gdzieś tam od strony później tzw. biznesu, zarządu czy jakkolwiek, to okaże się, że ten zespół będzie postrzegany jako mniej efektywny. Nikt nie będzie tutaj patrzył, że nie ma odpowiednich narzędzi. Po prostu będzie ten zespół widziany jako taki, który powinien może dowozić szybciej. 

 

Tak, albo tu jeszcze nawet pójdę jeszcze głębiej, bo mówiłeś brak pipeline’ów. Brak na przykład testów jednostkowych albo też brak wsparcia od organizacji, brak w ogóle tego, że jest przewidziany czas w ramach projektu na pisanie testów automatycznych i tylko testowanie manualne, to wcześniej czy później się zemści na tej efektywności zespołu. 

Jak projekt jest jeszcze mały, nie jest w fazie produkcyjnej, tylko po prostu zaczęliśmy, to może to nie jest większym problemem, a potem każda kolejna zmiana i psujemy to, co zrobiliśmy wcześniej. 

 

Czyli oprócz pewnego wsparcia ze strony organizacji, oprócz jakiegoś takiego zgrania wewnętrznego i odpowiednich narzędzi do pracy, trzeba z pewnością wymienić metodologię, według której zespół działa. I myślę tutaj głównie o zwinności, czy według Ciebie ma to bezpośrednio przełożenie efektywności? 

 

Tak, ale jeszcze chciałbym wrócić do narzędzi, bo jeszcze wydaje mi się, że o jednej ważnej rzeczy zapomnieliśmy, mianowicie o szkoleniu naszych członków zespołu. I to też jest taki brak narzędzia, czyli brak na przykład takiego, jak to się mówi, funduszu szkoleniowego, który po prostu by pozwolił na to, że te kompetencje zespołu będą up to date, nie wiem, jakieś wysłanie ludzi na konferencje. 

Ja wiem, że dla tych konferencjach to jest tak, że tak naprawdę to się niczego nie dowiesz, ale z drugiej strony to jest tak, że liźniesz jakby różnych trendów i możesz potem…

 

Poszerzyć tę wiedzę.

 

Tak, poszerzyć już na własnych warunkach. Wiesz po prostu, czego szukać potem i jakie są właśnie trendy, jakie są teraz nowe narzędzia. Więc pod takim względem to mi się wydaje, że tak raz w roku chociaż pół zespołu powinno pojechać na taką konferencję. Jeśli firma nie ma budżetu tak na to, żeby wszyscy co roku jechali, to chociaż, żeby ich jakoś rotować. 

 

I zaczęliśmy temat sposobu pracy, metodologii pracy. Czy zwinność, czy to w jaki sposób, no nie wiem, są realizowane w sposób iteracyjny? Przyrosty, czy to ma wpływ na efektywność, czy gdyby podejść do tego w sposób chociażby waterfallowy, to de facto ta efektywność mierzona różnymi metodykami byłaby taka sama? 

 

Nie mam niestety przygotowanych żadnych statystyk ani badań, natomiast z moich doświadczeń wynika, że tak. Właśnie to, że możemy szybko dostać feedback na temat efektu naszej pracy, no to jest to kluczowe właśnie, żebyśmy efektywnie dostarczali produkt. To, że np. możemy zrobić jakiś prosty prototyp, jakiś mock w ogóle funkcji, który jeszcze nie działa, ale tylko wygląda i mamy zaufanie, że też ta osoba po drugiej stronie rozumie, że to jest tylko mock, to są to ważne rzeczy, które po prostu sprawiają, że ta efektywność końcowa jest wysoka. 

Właśnie to, że możemy szybko dostać feedback na temat efektu naszej pracy, no to jest to kluczowe właśnie, żebyśmy efektywnie dostarczali produkt. To, że np. możemy zrobić jakiś prosty prototyp, jakiś mock w ogóle funkcji, który jeszcze nie działa, ale tylko wygląda i mamy zaufanie, że też ta osoba po drugiej stronie rozumie, że to jest tylko mock, to są to ważne rzeczy, które po prostu sprawiają, że ta efektywność końcowa jest wysoka.

 

Tak, ten feedback, który szybko zyskujemy wpływa na to, że usprawniamy procesy, usprawniamy to, w którym kierunku idziemy, więc tego zmarnowanego czasu na koniec dnia nie ma, albo jest przynajmniej jakoś tam minimalizowany, a to ma bezpośrednie przełożenie na to, że nasza efektywność rozumiana jako szybkie, skuteczne dostarczanie rozwiązań jest po prostu wyższa. 

 

A to jeszcze tutaj poruszyłeś jeszcze jedną ważną rzecz, właśnie to, że ten proces naszego zespołu ciągle poprawiamy, ulepszamy. I tak dla mnie właśnie zawsze ważnym takim spotkaniem w sprincie był retrospective, czyli nie review, nie to, że patrzymy na produkt, tylko to, że patrzymy, jak nam poszło i dlaczego nam coś nie poszło, albo też, co często jest pomijane, dlaczego coś nam dobrze poszło i wyciąganie z tego wniosków. 

Wydaje mi się, że to nie jest spotkanie, które musi być bardzo długie, a może procentować w tych przyszłych sprintach, nazwijmy to. 

 

Oczywiście. I możemy bazować na takim naszym odczuciu, czy przeczuciu, czy jakiejś takiej ogólnej historycznej obserwacji, czy nasza efektywność się zwiększa, czy nie, ale chyba zgodzimy się tutaj, że lepiej jest bazować jednak na danych, na liczbach, które w jakiś sposób powiedzą nam, czy ta efektywność się poprawia, pogarsza, czy idziemy w dobrym kierunku, czy nie. Czy możemy coś powiedzieć na temat wskaźników, które pomogłyby nam zidentyfikować, jaka ta efektywność zespołu obecnie jest? 

 

Ogólnie ja nie jestem jakimś wielkim fanem wskaźników, bo wydaje mi się, że to jest często tak, że zespół nie jest głupi i po prostu się adaptuje pod to, żeby jakby grać pod wskaźniki. Czyli często się spotykałem z tym, że właśnie jeśli mierzymy jedną rzecz, to druga rzecz, która jest naczyniem powiązanym, gdzieś tam jest odpuszczana, więc to trzeba bardzo dobrze przemyśleć, to co mierzymy. 

I oczywiście takie wskaźniki możemy podzielić na wskaźniki ilościowe, czyli suche liczby możemy porównać między sobą, i wskaźniki jakościowe, czyli bardziej takie wskaźniki opisowe, nasze odczucia, tego typu rzeczy. 

To może kilka przykładów tutaj podajmy, żeby nasi czytelnicy, czy też słuchacze mieli jakby pojęcie, o czym mówimy. 

Takimi wskaźnikami ilościowymi, czyli tymi, które możemy zmierzyć, to najprostsze to jest po prostu liczba zrealizowanych zadań, np. w sprincie. Możemy też, jeśli jesteśmy Agile, liczyć velocity, czyli jakby prędkość tych zadań, czyli czas, liczba zadań w czasie. Możemy też mieć takie wskaźniki jakości, jak np. liczba błędów, czy też defektów. 

Ja też lubię w tym przypadku zrobić rozróżnienie między liczbą błędów, które zostały wykryte na etapie jeszcze przed puszczeniem czegoś do klienta, przed jakimiś user acceptance testami, a liczba błędów, które do nas przychodzą już od klienta, lub też wręcz z produkcji. I to są wskaźniki ilościowe, mimo że tutaj słowo jakość się pojawiło. Nie mylmy. 

I oczywiście to, co zarząd lubi najbardziej, czyli wskaźniki finansowe, czyli ile nam tutaj przychodu np. wygenerował dany zespół, ile te feature’y, które zespół zrobił, wygenerowały przychód lub straty. W przypadku, nie wiem, zespołów wsparcia, to myślę, że tutaj możemy mówić bardziej, ile po prostu kosztów zostało wygenerowanych. 

Jakieś takie wskaźniki też wewnętrzne w zespole, to po czym poznać, że ten zespół się dogaduje. Możemy np. mierzyć rotację pracowników, ilu tam tych członków zespołu rocznie nam się wymienia. Im mniej, tym lepiej oczywiście. 

Jest na pewno dużo innych czynników, już nie będę ich tutaj wszystkich wymieniał. Znaczy wszystkich to w ogóle pewnie trudno byłoby wymienić. Może jeszcze tak ostatnie, czyli ocena satysfakcji klienta, jakaś liczbowa, np. Net Promoter Score. Czy coś tutaj do tych ilościowych byś chciał dodać, Krzysztofie?

 

Tak, tak. Myślę, że w ramach żartu oczywiście, ale ilość linii kodu też może być mierzona metryką i trochę śmieję, a trochę nie, bo nieraz faktycznie jest to taka metryka, która ma badać efektywność zespołu, bo wydaje się, że im więcej albo im szybciej tego kodu nastukamy, tym lepiej. 

 

To ja tu przewrotnie powiem, że taka metryka też jakości, to ile tych linii kodu zostało usuniętych w ramach sprintu. 

 

To już miałby większy sens, pewnie, tak, tak. To jest najłatwiejszy kod do utrzymania, taki, który nie powstał albo został usunięty. Taki lubimy najbardziej. Ale śmieję się, bo faktycznie to, co powiedziałeś, myślę, że jest istotne i faktycznie występuje. Jeśli się skupimy tylko na jednej czy dwóch metrykach, no to może się okazać, że to nam idzie do góry, ale wszystko inne spada. 

Więc może dla takiej wiedzy, dla może takiego ogólnego wglądu, na przykład dla kierownika, dla managera, dla zespołu podczas retrospektywy, żeby sobie na początku zobaczyć, jak to nam się tam zmienia, ale traktować to mimo wszystko jako taką naszą wewnętrzną informację, to może mieć jakiś tam sens, ponieważ daje namacalną informację, jak ta efektywność wygląda.

 Ale jeśli będziemy chcieli uzależniać na przykład awans, podwyżkę, czy cokolwiek takiego od tych liczb, no tutaj już trzeba naprawdę na to uważać, bo możemy sobie niestety strzelić w stopę. 

 

To wskoczmy jeszcze szybko na te wskaźniki jakościowe. Może opowiedzmy też kilka przykładów, żebyście mieli po prostu świadomość, o co tutaj chodzi. 

Na przykład byłby to poziom zaangażowania, albo też satysfakcji pracowników. Możemy to jakimiś okresowymi ankietami mierzyć, jakimiś wywiadami, i z tego trzeba wnioski po prostu wyciągnąć. C

o tu możemy jeszcze? Jakiś poziom właśnie komunikacji i współpracy w zespole. Jak ktoś ma problem, to czy inni członkowie zespołu tutaj, jak chętnie i czy pomogą rozwiązać coś. Opinie oczywiście klientów, satysfakcja klienta, czy też innych dotycząca właśnie jakości usług, czy produktów, no to np. ma, znowu się posłużę tutaj tym przykładem wsparcia klienta, czy udaje nam się rozwiązać zadania, problemy klientów, czy klienci są usatysfakcjonowani z tego, jak rozwiązaliśmy produkt, czy po prostu zostali gdzieś wysłani na drzewo i tak muszą sobie radzić sami, a stracili tylko czas na to, żeby się kontaktować gdzieś z tym wsparciem. Czy na przykład też to wsparcie odbijało piłeczkę przez tutaj dłuższy czas i odsyłało tego klienta między jedną a drugą osobą. 

To też jest ważne, żeby na przykład była taka osoba, która jest takim frontmanem w przypadku wsparcia, jeśli jedna osoba się zajmuje danym problemem, żeby w miarę możliwości, oczywiście są różne urlopy itd., ale żeby mimo wszystko, nawet jeśli inne osoby rozwiązują problem, to żeby ta komunikacja szła przez tą osobę, która ma tą relację z tym klientem, tak mi się wydaje. 

I to też buduje właśnie zaufanie i też relacje po prostu. Jeśli jesteśmy w dobrych relacjach z tym klientem, to też mi się wydaje, że klient będzie bardziej zadowolony. 

Co tutaj dalej możemy powiedzieć? Jakaś kreatywność, zdolność właśnie rozwiązywania problemów w taki nieszablonowy sposób, czyli też to, co powiedziałem, też na samym początku, czy nie tylko, że dostajemy zadanie i próbujemy je rozwiązać, ale też, czy najpierw do tego problemu podchodzimy, czy się zastanawiamy nad sensownością tego, co robimy. Albo post factum też, wiadomo, że lepiej przed, ale post factum też warto sobie zadać pytanie, czy to, co zrobiliśmy, było okej. 

Też ostatnio o tym mówiliśmy, jak rozmawialiśmy o rekrutacji, i że warto też tą rekrutację potem po jakimś czasie zweryfikować, na przykład po roku, czy to był dobry strzał, czy nasz proces był okej, czy nie był okej. Czyli efektywność tych podejmowanych decyzji. I wszelkiego typu oceny po prostu, czy to w ramach jakichś ankiet, czy też opinie przełożonych, które gdzieś tam wyciągamy z nich wnioski. 

 

Tak, właśnie warto sobie okresowo ten tak zwany puls zespołu badać, widziany nie tylko oczami członków tego zespołu, ale również osób z zewnątrz albo klientów, ludzi, którzy z tym zespołem współpracują, żeby mieć taki ogląd, jak ten zespół funkcjonuje, widziany z zewnątrz, ale też, jakie ma poczucie funkcjonowania. 

 

Tak, natomiast my jako ten lider, jako kierownik powinniśmy też zawsze sobie zadać pytanie, jaki mamy cel w tym, że mierzymy te wskaźniki. Czyli nasze słynne to zależy. I nie należy na pewno mierzyć zawsze wszystkiego, bo to jest bez sensu. Zawsze zadajmy sobie pytanie, dlaczego to robimy, i wybierzmy po prostu pod daną sytuację, pod dany zespół, pod dany projekt te wskaźniki, które nam w danym momencie pomogą. Też może być tak, że na różnych etapach projektu różne wskaźniki mają większy lub mniejszy sens. 

Na przykład jeśli zespół jest jeszcze młody, niezgrany, to może warto inne rzeczy tutaj mierzyć, na przykład ten poziom zaufania w zespole, a jeśli wiemy, że to już są starzy wyjadacze, którzy ze sobą już pracowali przy niejednym projekcie, to pewnie szkoda czasu, żeby tego typu wskaźniki mierzyć. Chyba że np. gdzieś zauważymy problem i wtedy n wprowadzamy jakieś wskaźniki, które mierzymy. Z drugiej strony to może być za późno, bo na przykład nie będziemy mieli porównania. 

Tak, natomiast my jako ten lider, jako kierownik powinniśmy też zawsze sobie zadać pytanie, jaki mamy cel w tym, że mierzymy te wskaźniki. Czyli nasze słynne to zależy. I nie należy na pewno mierzyć zawsze wszystkiego, bo to jest bez sensu. Zawsze zadajmy sobie pytanie, dlaczego to robimy, i wybierzmy po prostu pod daną sytuację, pod dany zespół, pod dany projekt te wskaźniki, które nam w danym momencie pomogą. Też może być tak, że na różnych etapach projektu różne wskaźniki mają większy lub mniejszy sens.

Tutaj, co prawda, już to powiedziałem, ale jeszcze może przywołam jeszcze raz, że możemy sobie pewne rzeczy mierzyć tak zupełnie wewnętrznie. I to też jest pewnie rola lidera, żeby właśnie tutaj wskazać, że nie mierzymy tych rzeczy, żeby pokazać zarządowi, później wskazać palcem, że ty tam działasz mało efektywnie, a ty bardziej, tylko dla własnego oglądu, dla własnego spojrzenia, ewentualnie ulepszania procesów. Ale chciałbym właśnie podwójną linią, miszlaczkiem jeszcze podkreślić tą rolę lidera. 

A mogę się jeszcze tylko odnieść? 

 

Jasne. 

 

Ja jeszcze tak przewrotnie bym chciał powiedzieć, bo ja z kolei jako lider zespołu albo kierownik zawsze miałem inną filozofię i u mnie wszelkie wskaźniki, które były mierzone, były mierzone na tablicy tam, gdzie zespół pracował. Znaczy, mówimy o tych ilościowych, bo wiadomo, że nie było tam rozprawek na tablicy, ale jakieś takie różne wykresy, to jest też taka zasada wizualizacji, właśnie i tego, że zespół wie, na czym stoi, i właśnie raczej nie starałem się, żeby zespół też odpowiadał za to, żeby mierzyć te rzeczy i żeby czuli też wtedy odpowiedzialność za to, co mierzymy dzięki temu. 

 

Wiesz, wydaje mi się, że zespół, który jest kompetentny technicznie, będzie w stanie wiele rzeczy sobie mierzyć, ile tam powiedzmy średnio trwa deploy, jak długo coś się kompiluje itd. Więc tutaj myślę, że największe kompetencje ten zespół właśnie posiada w sobie, żeby takie rzeczy mierzyć i fajnie by było, żeby to było transparentne. 

 

Ja nigdy nie mierzyłem czasu kompilacji, ale rozumiem, że może to być problem czasami. 

 

Tak, wtedy, wiesz, idziemy sobie pograć w piłkarzyki czy tam na PlayStation, a tak, kod się kompiluje, prawda? Znany mem. 

No właśnie, mówiłem o roli lidera, który według mnie tutaj grywa dużą rolę. Tak jak powiedziałeś, zespół może być na różnym etapie rozwoju. Mamy te fazy storming, norming i performing, i zależy, czy dopiero gdzieś tam kształtujemy ten zespół, czy to jest pierwszy projekt tego zespołu, czy też któryś tam, wtedy różnie może ta efektywność wyglądać i różnego nadzoru, dozoru albo pomocy ze strony lidera z tego tytułu może zespół wymagać. Ale chyba zgodzimy się obaj, że mimo wszystko taka zbyt duża interwencja lidera, który no może czasem i chce dobrze, ale przedobrze z tą chęcią nie jest korzystna, prawda? 

 

To jest właśnie ten ciężki problem lidera, żeby let them go i żeby pozwolić im działać samemu i się nie wtrącać i po prostu dawać tylko feedback konstruktywny, a nie dawać tutaj micro managementu, czy właśnie też nie wkładać tutaj swoich rąk do pracy. No to jest zawsze ciężkie. Zawsze dla mnie było ciężkie, żeby po prostu odciąć się, tak? Troszkę od tego, co robi zespół. I tutaj pewnie leży też klucz do tej efektywności zespołu, żeby potrafić to zrobić i znaleźć ten złoty środek, to miejsce odcięcia. 

 

Tak, czyli jako lider pracować nie w zespole, ale nad zespołem. No to jest trudne zadanie. Tym niemniej możemy oczywiście wspomagać ten zespół, chociażby rozwijając kompetencje, pracując też jako swego rodzaju coach czy mentor, wówczas takie zwiększanie kompetencji zdecydowanie przełoży się na zwiększoną efektywność zespołu. 

Ale musimy pamiętać, że jesteśmy też wówczas takim trochę psychologiem w tym zespole. Jeśli ten zespół realizuje ciągle powtarzalne, nudne zadania, to może się szybko wypalić i też w związku z tym ta efektywność poleci na łeb na szyję. I taką trochę rolą wówczas tego lidera jest, żeby próbować jakoś temu przeciwdziałać, przenosząc między zespołami, dając różne zadania, w jaki sposób tę pracę urozmaicając. 

 

Tak, tutaj lider czy też ten kierownik ma dużo różnych narzędzi, o których też mówiliśmy w poprzednich odcinkach. Jest np. ten pair programming, ale też można po prostu, jeśli ma się więcej zespołów, też odpowiednio dobrać tych ludzi, czy też wymienić się osobami między zespołami, żeby ta wiedza po prostu krążyła. Dbanie o to, żeby jedna osoba nie była całym silosem, np. SQL-owym, albo żeby jedna osoba tylko nie zajmowała się, nie wiem, dbaniem o jakość, tylko żeby cały zespół tutaj był zaangażowany w tę jakość. 

To są takie rzeczy, których gdzieś tam może też nie widać, ale to są takie narzędzia, które po prostu ten lider ma i o które powinien zadbać. 

 

Tak, to oraz trafiona albo nietrafiona rekrutacja potrafi bardzo mocno wpłynąć na efektywność zespołu. Tutaj może odeślę do naszych wcześniejszych odcinków właśnie w tej serii, bo tam to rozłożyliśmy na czynniki pierwsze. 

 

I oczywiście w tym momencie powinniśmy zareklamować najlepszy portal na świecie, jeśli chodzi o rekrutację specjalistów, czyli SolidJobs, zapraszamy wszystkich. Jeśli szukacie najlepszych specjalistów, to tam ich znajdziecie. 

 

Tak, to jest z pewnością pierwszy i bardzo dobry krok w kierunku budowania efektywnego zespołu. 

 

I najskromniejszy to jest też portal, tak? 

 

Tak jest. Dobrze, Łukasz, to na końcu zerknijmy może na to, co może nam przeszkadzać, jakieś problemy, przeciwności, które obniżają efektywność zespołu IT. 

 

To są przede wszystkim różnego typu czynniki zewnętrzne, czyli np. spotkania, które tak wszyscy lubimy. Są to też niejasne wymagania oraz częste zmiany w wymaganiach. Tutaj, co z tego, że zrobiliśmy najlepszą funkcję na świecie, jeśli zaraz się okaże, że musimy robić to od nowa, bo te wymagania się fundamentalnie gdzieś zmieniły. Ale też to może być nadmiar na przykład pracy albo właśnie to, że jest dużo zadań i nie jesteśmy w stanie po prostu się skupić na jednym zadaniu, tylko skaczemy między jednym a drugim. 

Natomiast w drugą stronę, moim zdaniem to też jest złe, jeśli jest za mało zadań, bo wtedy tam zgodnie bodajże z prawem czas po prostu się… 

 

Parkinsona. 

 

A, Parkinsona. Okej, tak. Co może nam przeszkodzić? Oczywiście dług technologiczny. Musimy cały czas dbać o to, żeby to, co robimy, było w jakiejś rozsądnej jakości. Co może od siebie dodasz, Krzysztofie? 

 

Ja bym jeszcze raz wrócił do spotkań, które zaznaczyłeś, bo według mnie zbyt duża ich liczba umiejscowionych w dziwnych porach dnia, które nas rozpraszają, wybijają z tego rytmu, doskonale zmniejsza efektywność, więc to też jest pewna rola oczywiście ze strony kierownika, managera, lidera, żeby tę liczbę spotkań minimalizować, albo przynajmniej spróbować w jakiś sposób układać dzień pracowników, tak żeby pewne pory były przeznaczone na spotkania, a większe bloki czasu przeznaczone na tę pracę kreatywną, na tą związaną z myśleniem, programowaniem, bo takie dłuższe bloki czasu są nam zwyczajnie potrzebne.

 

Tak, natomiast jeśli jeszcze mówimy o spotkaniach, to zawsze spotkanie to jest taki chłopiec do bicia, ale ja zawsze dzielę spotkania na spotkania takie projektowe i pozostałe, bym powiedział. I projektowe to są takie, gdzie mamy jakiś efekt po tym spotkaniu, jakiś artefakt. To niekoniecznie musi być kawałek oprogramowania, ale może być jakaś check lista, jakieś coś, co dalej nam pomoże, jakiś mock up, jakieś rysunki na tablicy, czy też jakieś diagramy. 

Tego typu spotkania są ważne i posuwają też do przodu. Natomiast to, co powinniśmy minimalizować, to pewnie takie spotkania właśnie zarządcze i takie spotkania, które niekoniecznie jakby wnoszą coś do naszej pracy codziennej. 

No właśnie, sporo tych rzeczy dzisiaj było. Długa lista tego, co wpływa na efektywność, jak można ją mierzyć, jak można ją podnosić, co na to wpływa, więc myślę, że nie możemy pozostawić naszych słuchaczy bez jakiegoś dobrego podsumowania. 

Okej, czyli tradycyjnie. Pamiętajcie, że kluczowe osoby w zespole są kluczowe. Czyli warto tutaj jest dbać o to, żeby te osoby, które gdzieś ciągną ten zespół do przodu, żeby miały też motywację do tego, żeby je ciągnęły. Warto jest też zadbać o to, żeby jeśli są jakieś osoby, które gdzieś tam odstają, to żeby też je dociągać po prostu do tej średniej zespołu. Czyli dbajmy o siebie nawzajem, tak bym może to podsumował. 

Dalej, kluczowa moim zdaniem jest zwinność, czyli szybkość adaptacji do zmian. Czyli to, że możemy dostać szybki feedback i szybko wprowadzać zmiany powoduje po prostu to, że efektywnie wytwarzamy oprogramowanie. 

Kolejne może takie równanie moje, to morale plus kompetencje równa się efektywność, czyli dbajmy zarówno o to, żeby zespół był dobrze zmotywowany, jak i o to, żeby miał kompetencje do wykonywania swoich obowiązków. Na przykład tutaj mówiliśmy o tym, żeby nie tworzyć takich silosów, tylko żeby właśnie też wymieniać się wiedzą. Ale też dbajmy o te szkolenia, o różnego rodzaju po prostu wymianę wiedzy. 

I ostatni punkt, myślę, naszego podsumowania, czyli dystraktory (ale mądre, fajne słowo), czyli takie czynniki zewnętrzne, które gdzieś nam przeszkadzają. Czyli te spotkania, niejasne wymagania, zmiany, złe zarządzanie, czy też przeciążenie pracą, dbajmy o to, żeby tego było jak najmniej. 

 

Tak, zatem teraz już wiecie, co robić, idźcie i bądźcie efektywni. Możecie też oczywiście przesłuchać nasze wcześniejsze odcinki z tej serii, ale również z wcześniejszych serii.

A jeśli szukacie swojej nowej przygody w IT, albo szukacie kogoś, kto do waszego zespołu miałby dołączyć, to zapraszamy na SolidJobs, gdzie znajdziecie mnóstwo ofert pracy, zawsze z widełkami wynagrodzeń, więc to jest pewnie to miejsce, które powinniście odwiedzić po przesłuchaniu tego odcinka.

 

Jeszcze ode mnie na koniec prośba, żebyście lajkowali, polecali, a przede wszystkim polecali u Was w zespole. Jeśli uważacie, że warto było odsłuchać ten odcinek, to polećcie go dalej, po prostu to jest sposób na to, żebyśmy rośli tutaj w siłę i żebyśmy docierali do coraz szerszego grona odbiorców. Tak że dziękujemy i do zobaczenia.

 

Dzięki wielkie, cześć!