Porozmawiajmy o IT

Efektywność zespołu IT. Gość: Łukasz Drynkowski - POIT 289

• Krzysztof Kempiński • Season 1 • Episode 289

Share episode

Witam w dwieście osiemdziesiątym dziewiątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy w serii podcastów dla lidera i menedżera IT jest efektywność zespołu IT.

Dziś moim gościem jest Łukasz Drynkowski, z którym mam przyjemność współtworzyć portal z ofertami pracy dla branży IT o nazwie SOLID.Jobs.


Główne myśli o efektywności zespołu z tego odcinka to:

  • efektywność zespołu to nie tylko szybkość
  • motywacja i relacje mają kluczowe znaczenie
  • sprawczość i autonomia zwiększają efektywność
  • odpowiednie narzędzia i kompetencje są niezbędne
  • zwinność to klucz do adaptacji i efektywności
  • mierzenie efektywności można oprzeć o wskaźniki jakościowe i/lub ilościowe
  • rola lidera to wspieranie, nie przeszkadzanie
  • najczęstsze przeszkody to przeciążenie i chaos

Subskrypcja podcastu:


Linki:


Wsparcie:


Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl

https://porozmawiajmyoit.pl/289

Krzysztof Kempiński:

To jest 289. Odcinek podcastu Porozmawiajmy IT, w którym, w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT Solid. Jobs, który mam przyjemność współtworzyć, dyskutujemy o tematach związanych z byciem liderem i zarządzania zespołem IT. Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania. Odpalamy, cześć Łukasz. Dzień dobry, mianowicie efektywność zespołu IT? No, bo to nie tylko szybkie dostarczanie wartości, ale również mądre dostarczanie wartości, na co dzisiaj będziemy zwracać uwagę. No, i właśnie, Łukasz, co według Ciebie jest takimi cechami, które definiują efektywny zespół?

Łukasz Drynkowski:

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ż. na przykład, jeśli mamy zespół na przykład wsparcia użytkownika, to będzie to jakieś tam zadowolenie, na przykład z tego, że nasze problemy są rozwiązywane na czas i jakby sprawnie i te rozwiązania też są znajdowane.

Krzysztof Kempiński:

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 dewelopmencie, 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 czy 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, tak no, myślę że ten nacisk na jakość jest ważny.

Łukasz Drynkowski:

No, 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ą efektywność, tą taką pozorną efektywność, na rzecz tego, że będziemy musieli poprawiać jakieś bugi, błędy. A 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 na przykład można coś zrobić może najpierw porozmawiajmy, że da się tutaj zrobić coś jakimiś mniej uczęszczanymi ścieżkami w programie czy rozwiązać jakąś procedurą, po prostu, a nie konkretnym featurem.

Krzysztof Kempiński:

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 i wtedy połączymy tą szybkość dostarczania z efektywnością.

Łukasz Drynkowski:

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, na przykład taki co mi przychodzi do głowy. Na przykład przykład sorry za tutaj masło maślane to czat w systemie. To też wielokrotnie słyszałem, w różnych sytuacjach słyszałem, że jest potrzebny czat. No, a są dedykowane narzędzia, takie jak na przykład właśnie Microsoft Teams czy Slack, które pewnie robią to lepiej, efektywniej, niekoniecznie. To musi być coś, co będzie wbudowane w nasz system.

Krzysztof Kempiński:

Takie mądre tworzenie rozwiązań. to też tutaj wpływa bezpośrednio na efektywność widzianą z zewnątrz, efektywność zespołu IT. Wydaje się, że dla menedżera 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.

Łukasz Drynkowski:

Ale trzeba by na pewno. No, 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 na przykład mamy ogólnie w zespole, mamy różnych ludzi, raczej to taką średnią wartość jak inni. Spotykałem się z takimi sytuacjami, gdzie powiedzmy, 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, tak, ale bardzo dobry. Tutaj też chyba kiedyś rozmawialiśmy o tym serialu Chicago Bulls, gdzie był, 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.

Krzysztof Kempiński:

Tak zgadza się. 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. 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ół.

Łukasz Drynkowski:

Tak, no, 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ż. Pomaga w tym, żeby nie było jakichś przeszkód w tym, jak pracujemy.

Krzysztof Kempiński:

Tak plus wpływ organizacji, według mnie mega istotny. No, bo jeśli działamy w jakimś dużym zespole, gdzie nasza sprawczość, decyzyjność jest praktycznie zerowa, no, to automatycznie będzie nam się chciało mniej. Nawet jeśli będziemy mieli jakieś ciekawe pomysły, fajne usprawnienia i tak dalej, to i tak będzie mała szansa, że będą one w stanie być zrealizowane i wcielone w życie. Więc 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.

Łukasz Drynkowski:

Tak, zdecydowanie też 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 gdzieś tam 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ą znowu użyję słowa sprawczość.

Krzysztof Kempiński:

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ć.

Łukasz Drynkowski:

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

Krzysztof Kempiński:

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, no 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.

Łukasz Drynkowski:

Więc te narzędzi Teraz w dobie AI, to brak na przykład jakiejś licencji na czata, gtp czy inny tutaj odpowiednik. Co to jeszcze może być. Sam sprzęt? tak 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 wykonać 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.

Krzysztof Kempiński:

Oczywiście chociażby to że nie wykorzystujemy pipeline'ów, cicd, to że nie wykorzystujemy chmury, to że nie ma środowisk testowych i tak dalej, wszystko to zwyczajnie będzie wydłużało niepotrzebnie zbędnie 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, natomiast po prostu będzie ten zespół widziany jako taki, który powinien, może dowozić szybciej.

Łukasz Drynkowski:

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 tutaj od organizacji, brak w ogóle tego, że jest przewidziany czas w ramach projektu na pisanie testów automatycznych i tylko testowanie manualne. No, to jakby 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 nie jest większym problemem. A potem każda kolejna zmiana, do zmiany, do zmiany, i psujemy to, co zrobiliśmy wcześniej.

Krzysztof Kempiński:

Dokładnie, 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?

Łukasz Drynkowski:

ma to bezpośrednie przełożenie efektywności 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ę ty się niczego nie dowiesz, ale z drugiej strony to jest tak że liźniesz jakby różnych trendów i możesz potem Poszerzyć tam piecany.

Łukasz Drynkowski:

Tak poszerzyć, poszerzyć już we własnym, jakby na własnych warunkach, tak 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 na to żeby wszyscy co roku jechali, no, to chociaż żeby ich jakoś rotować. No, i zaczęliśmy temat sposobu pracy, metodologii pracy, czy zwinność, czy to, w jaki sposób są realizowane w sposób iteracyjny przyrosty, czy to ma, że możemy szybko dostać feedback na temat efektu naszej pracy. No, to to jest kluczowe, właśnie żebyśmy efektywnie dostarczali produkt, to że na przykład 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ą ważne rzeczy, które po prostu sprawiają, że ta efektywność końcowa jest wysoka.

Krzysztof Kempiński:

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 niemal, bo jest przynajmniej jakoś tam minimalizowany. No, 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.

Łukasz Drynkowski:

A to jeszcze tutaj proszę jeszcze jedną ważną rzecz właśnie to, że ten proces naszego zespołu ciągle poprawiamy, ulepszamy. 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. Myślę, że to nie jest spotkanie które musi być bardzo długie, a może jakby procentować w tych przyszłych sprintach.

Krzysztof Kempiński:

Nazwijmy to Oczywiście, 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 grać pod wskaźniki.

Łukasz Drynkowski:

I 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. No, i oczywiście takie wskaźniki możemy podzielić na wskaźniki ilościowe, czyli coś co po prostu możemy no liczby, suche liczby możemy porównać między sobą. 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.

Łukasz Drynkowski:

Pewnie ilościowymi, czyli tymi, które możemy zmierzyć. No to najprostszy, to jest po prostu liczba zrealizowanych zadań, na przykład w sprincie. Możemy też, jeśli jesteśmy agile, no to velocity liczyć, czyli jakby prędkość tych zadań, czyli liczba zadań w czasie. Tak tak.

Łukasz Drynkowski:

Możemy też mieć takie wskaźniki jakości, jak na przykład 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. No, i, to są wskaźniki ilościowe. Mimo że tutaj słowo jakość się pojawiła, nie mylmy nam tutaj przychodu na przykład wygenerował dany zespół, ile te feature, które zespół zrobił, wygenerowały przychody lub straty. W przypadku 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 na przykład mierzyć rotację pracowników, ilu tam tych członków zespołu rocznie nam się wymienia, im mniej, tym lepiej. Oczywiście 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 na przykład ocena satysfakcji klienta, jakaś liczbowa, na przykład Net Promoter Score.

Krzysztof Kempiński:

Czy coś tutaj do tych ilościowych byś chciał, krzysztofie? Tak myślę że w ramach żartu, oczywiście, ale ilość linii kodu też może być mierzoną metryką, i trochę się śmienia, 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.

Łukasz Drynkowski:

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

Krzysztof Kempiński:

To już miałby większy sens, pewnie. Tak. Tak, to jest najłatwiejszy kod do utrzymania, taki, który nie powstał, bo 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 menedżera, dla zespołu, podczas na przykład 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ę.

Łukasz Drynkowski:

Tutaj już trzeba naprawdę na to uważać, bo możemy sobie niestety strzelić w stopę.

Łukasz Drynkowski:

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. To tak, to na przykład byłby to poziom zaangażowania albo też satysfakcji pracowników. Możemy to jakimiś na przykład okresowymi ankietami mierzyć, jakimiś wywiadami? no, i z tego trzeba wnioski po prostu wyciągnąć, co tu możemy. jeszcze Jakiś poziom właśnie komunikacji i współpracy w zespole, to też, czy 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 na przykład. 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 i tak dalej, ale żeby mimo wszystko, nawet jeśli inne osoby tutaj 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 Relacje. Jeśli jesteśmy w dobrych relacjach z tym klientem, to też mi się wydaje, że klient będzie bardziej zadowolony.

Łukasz Drynkowski:

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 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. wiadomo że lepiej przed, ale post factum też warto sobie zadać pytanie czy to co zrobiliśmy było okej. Toteż ostatnio mówiliśmy, jak rozmawialiśmy o rekrutacji, że warto też tą rekrutację potem po jakimś czasie zweryfikować, na przykład po pół roku, czy to był dobry strzał, czy jakby nasz proces był okej czy nie był okej, czyli efektywność tych podejmowanych decyzji, No, 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.

Krzysztof Kempiński:

Warto sobie okresowo ten tzw 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ół cel. w tym, że mierzymy te wskaźniki, czyli nasze słynne, to zależy.

Łukasz Drynkowski:

Nie należy na pewno mierzyć zawsze wszystkiego, bo to jest bez sensu. Zawsze zadajmy sobie pytanie, dlaczego to robimy, i wybierzmy po prostu poddaną sytuację, poddany zespół, poddany 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, nie do, jak to się mówi nie do tarty tak niezgrany?

Łukasz Drynkowski:

no, 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, no to jakby pewnie szkoda czasu, żeby tego typu wskaźniki mierzyć, chyba że gdzieś zauważymy problem i wtedy na przykład wprowadzamy jakiś wskaźnik, który mierzymy. Z drugiej strony to może być za późno, bo na przykład nie będziemy mieli porównania.

Krzysztof Kempiński:

No, tak, tak 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 i ewentualnie ulepszania procesów. Ale chciałbym właśnie podwójną linią i szlaczkiem jeszcze podkreślić tą rolę lidera.

Łukasz Drynkowski:

Mogę się jeszcze tylko odnieść. 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, to były mierzone 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.

Krzysztof Kempiński:

Wiesz, wydaje mi się, że zespół, który jest kompetentny technicznie, będzie w stanie wiele rzeczy sobie mierzyć, tak ile tam powiedzmy średnio trwa deploy, jak długo coś się kompiluje, jak często musimy wycofywać listy, i tak dalej, i tak dalej. 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.

Łukasz Drynkowski:

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

Krzysztof Kempiński:

Tak, 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 odgrywa dużą rolę. Tak, jak powiedziałeś, zespół może być na różnym etapie rozwoju. Tak, mamy te fazy storming, norming i performing, i zależy od tego, czy dopiero gdzieś tam kształtujemy ten zespół, czy to jest pierwszy projekt tego zespołu czy też któryś tam. No, to 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ę obydwoje, że mimo wszystko taka zbyt duża interwencja lidera, który no może czasem i chce dobrze, ale przedobrza z tą chęcią, nie jest korzystna, prawda.

Łukasz Drynkowski:

No, to jest właśnie ten ciężki problem lidera, żeby let them go, żeby pozwolić im działać samemu i się nie wtrącać i po prostu dawać tylko feedback i konstruktywny, a nie dawać tutaj mikromanagementu 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ół. No, 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.

Krzysztof Kempiński:

Czyli jako lider pracować nie w zespole, ale nad zespołem. 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. to takie zwiększanie kompetencji zdecydowanie przełoży się na zwiększoną efektywność zespołu zespole. Jeśli ten zespół realizuje ciągle powtarzalne, nudne zadania, no, 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.

Łukasz Drynkowski:

w jaki sposób tą pracę, rozmaicając zadania w jaki sposób tą pracę rozmaicając, tak tutaj lider ma, lider czy też ten kierownik ma dużo różnych narzędzi, o których też mówiliśmy w poprzednich odcinkach. Jest na przykład ten per-programming, ale też jest 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 nie wiem na przykład SQL-owym, albo żeby jedna osoba tylko nie zajmowała się dbaniem o jakość, tylko żeby cały zespół tutaj był zaangażowany w tą jakość. To są takie rzeczy, które gdzieś tam ich może też nie widać, ale to są takie narzędzia, które po prostu ten lider ma i o które powinien zadbać.

Krzysztof Kempiński:

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.

Łukasz Drynkowski:

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

Krzysztof Kempiński:

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

Łukasz Drynkowski:

I najskromniejszy. To jest też portal.

Krzysztof Kempiński:

Tak, Tak jest, 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, które obniżają efektywność zespołu IT.

Łukasz Drynkowski:

No, to są przede wszystkim różnego typu czynniki zewnętrzne, czyli na przykład 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 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 ten czas po prostu się.

Krzysztof Kempiński:

Parkinsona, a Parkinsona, tak tak dobrze dzwoniło.

Łukasz Drynkowski:

Okej, tak, co może nam przeszkodzić? No, oczywiście dług technologiczny.

Krzysztof Kempiński:

Musimy cały czas dbać o to, żeby to, co robimy było w jakiejś rozsądnej jakościych porach dnia, które nas rozpraszają, na przykład wybijają z tego rytmu. To doskonale zmniejsza efektywność. Więc to też jest pewna rola oczywiście ze strony kierownika, menadżera, 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 no, bo taki czas dłuższy, takie dłuższe bloki czasu są nam zwyczajnie potrzebne.

Łukasz Drynkowski:

Tak natomiast, jeśli jeszcze mówimy o spotkaniach, to ja, bo zawsze spotkanie to jest takie chłopiec do bicia, ale ja bym te spotkania, ja zawsze dzielę spotkania na spotkania takie projektowe, i pozostałe bym powiedział Projektowe, to są takie, gdzie no, mamy jakiś efekt po tym spotkaniu. Jakiś artefakt, tak, to niekoniecznie musi być kawałek oprogramowania, ale może być jakaś checklista, coś co dalej nam pomoże, jakiś mock-up, jakieś rysunki na tablicy czy też jakieś diagramy. Tego typu spotkania one są, myślę, ważne i jakby posuwają też do przodu. Tak 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, jakby do naszej pracy codziennej.

Krzysztof Kempiński:

Tak Dokładnie dokładnie. 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.

Łukasz Drynkowski:

Okej, czyli tradycyjnie to tak. 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, zarówno o to, żeby zespół był dobrze zmotywowany, ale też dbajmy 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 wymiany wiedzy. No 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ą. No, to dbajmy o to, żeby tego było jak najmniej.

Krzysztof Kempiński:

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 Solid Jobs, 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.

Łukasz Drynkowski:

I 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, no, to polećcie go dalej, i 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.

Krzysztof Kempiński:

Dzięki, wielkie cześć.

People on this episode

Head Shot

Krzysztof Kempiński

Host