Jak zostać liderem w IT: Balans między długiem, a nowym featurem
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ść.
Ktoś kiedyś mądry powiedział, ale nie pamiętam kto, że w momencie kiedy
odchodzisz od klawiatury powstaje dług techniczny.
No i ten ktoś według mnie miał sporo racji.
No bo dług jest z nami, był i będzie.
Jeżeli ktoś twierdzi, że jest inaczej, no to Cię okłamuje.
Bo dług niestety jest czymś, czym zazwyczaj musimy żyć.
Przynajmniej przez jakiś czas, a zazwyczaj cały czas.
Ale czasami w tym długu naprawdę nie ma nic złego.
No bo być może jest to jakieś takie miejsce w aplikacji,
które zostało zrobione dla jednego klienta i wiesz, że tam dużego ruchu nie ma, a
może nawet dla wielu klientów, ale wiesz, że tam tego dużego ruchu nie masz, bo
nawet monitorujesz i widzisz, że rzadko z tego ktoś korzysta.
Więc być może takie miejsce jest po prostu no nie za ładne, ale wystarczająco dobre.
Przynajmniej na ten moment.
Nie zapominamy o nim, ale na razie sobie może być.
No bo pamiętaj, że Ty już jako ten lider nie możesz sobie pozwolić na to, żeby
powiedzieć, że o tylko kod musi być dobry i koniec.
I w ogóle nic mnie nie obchodzi.
Ty jesteś tym pomostem między biznesem a działem IT technicznym.
Jak zwał tak zwał i musisz jednak pokazywać cały czas swoim
ludziom, że no słuchajcie, ja was rozumiem, ok, wszystko jest jasne, no ale
użytkownik potrzebuje tego i tego, my wtedy zarobimy więcej, więc
robimy feature tym razem, A po drugiej stronie, po stronie biznesowej też czasami
musisz pójść i powiedzieć no słuchajcie, no już przez długi czas tutaj to
zostawiliśmy, może nawet troszeczkę zbyt długi, ale jeżeli jeszcze chwilkę, to tak
zostanie, no to będziemy mieli spory problem, no bo
tutaj będziemy mogli przyjąć mniej użytkowników, bo to już nie jest wydajne,
bo zresztą ty lepiej wiesz ode mnie, ile tutaj może być różnego rodzaju problemów.
Tak czy owak, tym długiem będzie trzeba się jakoś zająć, bo za duży dług na pewno
się na nas zemści, ale tylko na pewno, Bo zawsze jest tak, że
jak za długo poczekamy, no to się okazuje, że musimy na serwerze podkręcać RAM czy
tam procesor, No bo to już przestaje wszystko wydalać, bo mamy coraz więcej
tych klientów i tak dalej i wiemy, że tam się kryje jakiś nie za dobry kod,
który można by było poprawić.
Już nie wspominając o tym, że te nowe ficzery, na którym zależy biznesowi,
ale w sumie nam też powinno zależeć.
No bo czym lepszy projekt, tym fajniejszy.
Więcej klientów jakby same plusy wiadomo, Ale te nowe ficzery nawet już jest
ciężko tutaj jakoś dostarczyć.
No bo w takim kodzie, który już jest tym sporym długiem obciążony, no to po prostu
w nim się źle pracuje i naprawdę trudno jest tam wprowadzić coś nowego.
Już nie mówiąc o tym, że dużo łatwiej jest tam wprowadzić jakieś błędy albo po prostu
całkiem wziąć to zepsuć w miejscu, w którym nawet się nie spodziewamy,
że coś mogłoby takiego być.
No więc tym długiem jakoś tam musimy spróbować przynajmniej zarządzać, jakoś
balansować tutaj między tym, ile tego długu może zostać, a tym
nowym ficzerem, który chcemy wprowadzić.
No i jak to można robić?
No na pewno słyszałeś o czymś takim jak sprinty techniczne.
To jest jeden ze sposobów, moim zdaniem nawet całkiem spoko.
Wtedy po prostu jeden sprint raz na jakiś czas poświęcacie na to, żeby zająć się
tym, co zespół uważa, że w danym momencie by było najlepiej usprawnić.
No bo zespół najlepiej wie, gdzie się tego długu najwięcej kryje, który najbardziej
przeszkadza i tak dalej, i tak dalej.
Ale ja osobiście tutaj znowu wracam do metody Skauta czy tam reguły skauta.
Czyli jestem zdania, że za każdym razem, kiedy coś widzimy i za każdym
razem, kiedy wchodzimy w jakiś kod.
No i oczywiście nie mówię tutaj o sytuacjach, że jakieś
tutaj wielkie przeróbki trzeba robić, ale jeżeli możemy coś trochę poprawić,
no to za każdym razem poprawiamy.
Ale nawet jeżeli to jest jakaś większa zmiana, być może, no to ja w każdym jednym
projekcie staram się znaleźć czas, znaleźć jakieś powiązanie.
Czy ten projekt przez przypadek nie wiąże się z jakąś częścią kodu, którą uważamy,
że już takim długiem trochę obrosła?
No i jeżeli mamy na to czas, a zazwyczaj jest trochę na to czasu,
no bo czemu by nie?
To się staram wprowadzić do tego projektu zadanie, które przy okazji niejako
troszeczkę wyczyścić tego długu.
I może Ci się wydawać, że to wolno działa i być może nawet to wolno działa, ale z
drugiej strony, jeżeli robisz to sukcesywnie, za każdym razem, za każdym
razem szukasz tego miejsca, gdzie można by było trochę usprawnić coś, no to nagle się
budzisz I to nie jest może po tygodniu, ale budzisz się po pół roku i okazuje się,
że ten już to miejsce w waszym systemie, to miejsce w kodzie
już jest piękne i się chce z nim pracować i się dobrze z nim pracuje.
I tak dalej, i tak dalej.
Więc ja Ci polecam taką metodę, ale sprinty techniczne
oczywiście również są spoko.
I to już by było chyba na tyle w tej lekcji.
Dziękuję Ci za uwagę i lecimy dalej.