Jak zostać liderem w IT: Kultura zespołowa
Zarządzaj karierą, zespołem i projektami
4 godz. 9 min · Biznes i Automatyzacje
Cezary ŁysiakDevCzego się nauczysz
- Dogłębne zrozumienie roli lidera w IT i jego kluczowych kompetencji
- Praktyczne wskazówki, jak budować autorytet i zaufanie w zespole
- Nauka zarządzania projektami IT z naciskiem na efektywność i wyniki
- Rozpoznawanie i radzenie sobie z czerwonymi flagami w zespole i projektach
- Zrozumienie miejsca zespołu IT w strukturze firmy i jego wpływu na cele biznesowe
- Strategie oparte na rzeczywistych wyzwaniach i doświadczeniach liderów w IT
Rola lidera w IT
Zaczynamy od podstaw. Zastanowimy się kim tak właściwie jest (czy powinien być) lider. Wydaje mi się, że panuje spore niezrozumienie czy może sporo niedopowiedzeń na temat faktycznych zadań i umiejętności na tym stanowisku. Od razu też spróbujemy się zastanowić czy to dla Ciebie. Wiele osób zrobiło sobie krzywdę wchodząc w tę rolę bez zrozumienia specyfiki wymagań i zakresu obowiązków.
Miejsce lidera i zespołu IT w firmie
Następnie spróbujemy umiejscowić lidera i jego techniczny zespół w strukturze firmy. Skupimy się w dużej mierze nad dynamiką pomiędzy potrzebami biznesu a dostarczaniem technicznych rozwiązań. Wspólnie spróbujemy zrozumieć czego oczekuje od nas biznes i jak widzi naszą rolę w całej firmie. Zastanowimy się też nad różnicami pomiędzy rodzajami firm i jak to wpływa na pracę lidera.
Komunikacja
Nie sposób docenić wystarczająco jak ważna jest to umiejętność w pasie z narzędziami lidera. Komunikacja z zespołem będzie się różnić od tej z przełożonymi czy z innymi działami. Porozmawiamy też o rodzajach komunikacji, które nie koniecznie bezpośrednio się kojarzą z tym słowem, a mogą odgrywać sporą rolę w codziennej pracy.
Efektywne zarządzenie zespołem
W tej części zastanowimy się nad codzienną pracą w zespole technicznym. Budowanie oprogramowania (czy rozwiązań) to przede wszystkim ludzie. Twoim zadaniem jest zbudować dobrze funkcjonującą maszynę, gdzie zakresy odpowiedzialności są jasne, relacje p[rzynajmniej poprawne, a autorytet i decyzyjność niezachwiana.
Realizacja projektów IT
Zazwyczaj w takim kontekście (projektowym) będą upływały Twoje dni. Jako członek zespołu (zazwyczaj) otrzymujesz zadania i je realizujesz. Jako lider możesz pracować nad zadaniami, ale częściej zarządzasz pracą tak, aby innym pracowało się dobrze. Usuwasz problemy. Zgłębiasz technologiczne czy biznesowe wyzwania. Sprawdzasz czy trzymacie się ustalonych ram. W tej części skupimy się na tym, jak to robić tak, aby zorganizować to w sposób tak optymalny, jak to jest możliwe.
Czerwone flagi
Ta część to zbiór sytuacji, na które trzeba uważać. Pokażę Ci na co zwracać uwagę i jakie sytuacje rozwiązywać od razu, gdy pojawią się ich pierwsze symptomy. Za późne zwrócenie na nie uwagi może prowadzić do poważnych problemów.
Rozwój lidera i zespołu
W tej części pokażę Ci jak ważne jest myślenie długofalowe. Zarówno w kontekście rozwoju projektu, ale również zespołu, pojedynczych jego członków, ale również Ciebie jako lidera. Zastanowimy się również ponownie czy to rzeczywiście jest droga dla Ciebie (bo nie jest to stanowisko dla każdego - i... nie ma w tym nic złego).
Dla kogo jest ten kurs?
Ten kurs jest przeznaczony dla osób, które chcą rozwijać się jako liderzy w IT, szczególnie w kontekście zarządzania zespołami technicznymi i realizacji projektów. Zakłada on podstawową znajomość pracy zespołowej oraz doświadczenie w projektach technicznych, ale nie wymaga wcześniejszego doświadczenia w roli lidera. Kurs został stworzony z myślą o programistach, testerach i innych specjalistach technicznych, którzy chcą wyjść poza swoją dotychczasową rolę i nauczyć się skutecznie prowadzić ludzi i projekty.
Cześć.
W swoim zespole nie chcesz na pewno mieć monarchii, ale też nie
chcesz mieć demokracji.
Tak naprawdę to co chcesz mieć i to jest coś, co sobie zapożyczyłem
z książki Reicha del Rio. Zasady.
Chcesz mieć merytokrację pomysłów?
No i o co w tym chodzi?
Chodzi o to, że w takim sposobie zarządzania czy w takim sposobie pracy
rządzą wyłącznie najlepsze pomysły.
Nie ludzie, nie jakieś dziwne rzeczy, tylko właśnie te najlepsze pomysły.
I to nie chodzi o to, że te pomysły muszą być najlepsze pod kątem technicznym, Więc
tylko patrzymy na guru internetowych, którzy mówią, jak coś powinno być zrobione
i to znaczy, że to jest dobry pomysł.
Nie na te decyzje.
Czy te pomysły uwzględniają parę rzeczy, na przykład jakie mamy w danym momencie
możliwości, zasoby, jaki mamy posiadany czas, jaka jest wymagana jakość i
jaki jest czas życia tego rozwiązania.
No bo jeżeli na przykład to rozwiązanie ma żyć niezbyt długo, to być może
możemy odpuścić trochę z jakości.
Czemu by nie?
Przecież to w tym naprawdę nie będzie nic złego.
No takie rzeczy czasami, które miały żyć krótko, mają tendencję do życia długo.
Wszystkiego nie przewidzimy, ale mam nadzieję, że mniej więcej
czujesz o co mi chodzi.
Więc o te pomysły Chodzi nie zawsze o te najlepsze technicznie, ale te, które
najlepiej zrealizują w danym momencie.
To, co mamy do zrobienia przy zasobach, czasie i tak dalej, takich jakich mamy.
I tutaj znowu wraca trójkącik, który warto znać.
Warto go mieć przed oczami, w szczególności jak jesteś liderem.
Musisz brać pod uwagę takie rzeczy.
Bo jeżeli jesteś być może tylko programistą i nie chcesz o tym myśleć w
danym momencie, bo programiści bardziej patrzą na tą część, przynajmniej mam
nadzieję na zakres i na jakość, a już na czas i na koszty trochę mniej.
Ty już nie masz czegoś takiego.
Już nie masz takiej możliwości, żeby spojrzeć na to w ten dosyć wąski sposób.
Musisz patrzeć na to całościowo, bo jesteś tym pomostem między biznesem
a technicznymi rzeczami.
Przynajmniej powinieneś być i mam nadzieję, że jesteś częścią
kultury Twojego zespołu.
Na pewno są jakieś wartości, które razem, wspólnie powinniście wyznawać.
Już o tym trochę mówiliśmy tutaj, więc nie będę się powtarzał, ale może dam jakiś
przykład, może pokażę, jak to u mnie często działa.
Na przykład u mnie jest często taka zasada, że nie robimy rzeczy głupich
tylko dlatego, że ktoś tak powiedział.
Ale to też nie znaczy, że je odrzucamy.
Zawsze dajemy jakieś alternatywy, pokazujemy, jak to można by było zrobić
lepiej, sprawniej, wydajniej, mniej głupio.
Czasami i tak, żeby uwzględnić to, żeby dla kogoś to było,
być może dla biznesu tańsze, a być może dla użytkowników bardziej
użyteczne bardziej łatwe w użytkowaniu?
Trudno powiedzieć.
Ale my mamy taką zasadę.
Ty możesz sobie ją zapożyczyć ode mnie.
Możesz wytworzyć jakąś własną zasadę.
Ważne jest to, żebyście w tym swoim zespole jednak wyznawali jakieś wartości
i po prostu ich nie odpuszczali.
Oczywiście czasami zostaniecie przegłosowani, cały czas istnieje jakaś
góra, która może Was przegłosować.
Tak się zdarza, ale wy w zespole raczej się trzymacie właśnie
dokładnie tych wartości.
Wtedy będzie wam się dobrze współpracować i będziecie pchać te projekty do przodu na
własnych zasadach, na tyle, na ile się da.
Uważam, że bardzo ważne jest też to, żeby w Twoim zespole była
kultura ciągłego wzrostu.
Mam na myśli to, że za każdym razem każdy członek zespołu
jeden do drugiego, łącznie z tobą.
Oczywiście, że łącznie z Tobą może przyjść i powiedzieć, co mu się podoba w
jego rozwiązaniu lub nie podoba.
Nie żeby kogoś zgnoić, Nie żeby kogoś upokorzyć, nie żeby pokazać,
że się jest mądrzejszym. To w ogóle nie o to chodzi.
Wszyscy muszą tak samo.
Ten, który daje krytykę, musi dać ją konstruktywną.
Tak samo jak ta osoba, która przyjmuje krytykę.
Musi zrozumieć, że to jest tylko po to, żeby następnym razem
spróbować zrobić coś lepiej.
I oczywiście tutaj mogą powstać jakieś zgrzyty i takie inne
rzeczy, mimo że nie powinny.
Jeżeli właśnie tak to potraktujemy jako lekcję, którą być może warto, być może
nie, być może jesteśmy w stanie pokazać tej osobie, że jednak nasze
rozwiązanie jest lepsze.
Jak będzie, tak będzie.
Ważne jest tylko to, żeby ta kultura ciągłego wzrostu u was była i
żeby wszyscy z niej starali się skorzystać.
Bo wtedy każdego dnia stajemy się coraz lepsi i coraz lepsi.
Chcesz, żeby Twoi pracownicy byli z dnia na dzień coraz lepsi, bo będziecie mogli
wtedy robić większe, potężniejsze, dużo fajniejsze rzeczy i będziecie
dostawać dużo fajniejsze projekty.
Jeżeli w firmie akurat rozdzielają projekty między działami, to zobaczysz,
że będziecie dostawać dużo ciekawsze.
Nie wiem, czy to jest do końca takie konieczne, ale ja uważam, że w tych
zespołach, którym ja pomagam się rozwijać i w którym pomagam
prowadzić te projekty i nimi jakoś tam zarządzać, ważna jest reguła skauta.
Nie wiem, czy słyszałeś kiedyś o czymś takim.
W regule skauta chodzi o to, że zostawiamy po sobie zawsze te rzeczy, którymi się
zajmujemy lepiej, niż je zastaliśmy wcześniej.
I to się nazywa reguła skauta, bo to jest jedna z reguł skautów w Stanach
Zjednoczonych, czyli takich naszych harcerzy.
I o co w tym chodzi?
No, najprościej pewnie to pokazać na kodzie.
Czyli jest sobie jakiś kod, czasami legacy.
No niektórzy mówią, że jak się odejdzie od komputera, to już jest legacy.
Ja się trochę z tym zgadzam, ale to jest na inną rozmowę.
Tak czy owak wchodzimy w ten kod i być może tam nie jest wszystko zrobione tak,
jak te standardy nasze zespołowe by to widziały.
Być może ten kot już jest stary.
Być może ktoś miał gorszy dzień.
Nie ma to żadnego znaczenia.
Wchodzę i zostawiam po sobie.
To chociaż trochę lepsze, niż było, zanim tutaj przyszedłem.
Jeżeli nawet, to nie do końca dotyczy tego, co ja mam w tym momencie zrobić, Ale
znajduję się w okolicy, najlepiej bliskiej okolicy, bo wiadomo, za każdym razem
przebudowywać wszystko to też nie jest najlepsza droga, ale właśnie trochę lepiej
trochę może nawet sformatować ten kod, może czasami nawet dodać gdzieś komentarz,
który Ci się wydaje jakiś ważny.
A może po prostu przerobić gdzieś jakiś, wyciągnąć jakąś klasę, coś tutaj,
jakimś modułem się zabawić?
Możliwości jest różnych sporo i to nie dotyczy tylko kodu.
To może dotyczyć także dokumentacji.
To może dotyczyć jakichś procedur, które być może można jakoś usprawnić.
Możliwości jest sporo.
Reguła skauta jest zawsze spoko, bo to są te malutkie kroczki, które za każdym razem
doprowadzają nas do coraz to, coraz to coraz lepszych rozwiązań, procedur.
You name it.
No jak już rozmawiamy o kulturze zespołowej, no to na pewno nie możemy
zapomnieć o tym, co już chyba było mówione, ale
tutaj akurat warto to powtórzyć.
Ludzie nie muszą się lubić, ale nie możesz pozwolić na jakikolwiek wrogość w zespole.
Tego nie może być.
Nic tak bardzo nie destabilizuje wszystkiego, co tylko jest, więc wasza
kultura musi opierać się na tym, że się wzajemnie szanujemy, że
doceniamy się jako specjalistów w tym, co w tym momencie robimy, że rozmawiamy
konstruktywnie, rozmawiamy i w ten sposób załatwiamy wszelkie problemy.
Inne są niedopuszczalne.
I na takie rzeczy musisz bardzo szybko reagować i szybko je
w samym zarodku niszczyć.
Tak, niszczyć.
I na tę lekcję chyba wystarczy. Na razie.
Hej.