Jak zostać liderem w IT: Make it work - make it right - make it fast
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 tej lekcji porozmawiamy o takim zdaniu, bardzo chyba znanym w IT.
Make it work. Make it right.
Make it fast od Kenta Becka.
I to też zdanie posłuży nam, żeby tak sobie szerzej trochę porozmawiać
o różnego tego typu zasadach w IT.
No i pewnie znasz to zdanie, ale tak sobie krótko jeszcze.
Może nie zdanie, może jakieś takie zasadę.
I na pewno ją znasz, ale sobie trochę może o niej porozmawiajmy.
O co w tym chodzi?
No chodzi o to, że jeżeli tworzymy oprogramowanie, no to ogólnie to jest taka
dobra zasada, bo w sumie są rzeczywiście trzy etapy.
Na początku robimy, żeby to działało, potem robimy, żeby było elegancko, a potem
robimy, żeby było szybko, optymalnie.
Jak zwał, tak zwał.
Najogólniej rzecz biorąc.
Do czego tutaj się przyczepić?
No tak, na pierwszy rzut oka to nie ma do niczego tutaj się przyczepić, ale
zazwyczaj w takich miejscach jakieś tam niebezpieczeństwo jest.
No i o nim też tutaj sobie porozmawiamy.
No bo na początku robimy, żeby po prostu to zadziałało.
No i w szczególności w takich przypadkach, kiedy coś nowego Próbujemy zrobić albo
coś, w czym jeszcze nie pracowaliśmy.
Być może jakaś nowa technologia, a być może mamy jakiś szalony
pomysł, który chcemy sprawdzić.
No i wtedy oczywiście wchodzi coś takiego jak proof of concept.
No i tam rzeczywiście nie ma co kombinować, nie ma co szukać jakichś
wspaniałych zasad, czystych kodów, nie wiadomo czego.
No bo jest spora szansa, że to po prostu nie zadziała.
No i szkoda jest czasu, energii, pieniędzy i wszystkiego, żeby tutaj
jakiś nie wiadomo co budować.
No i to jest jakby oczywiste.
A potem jak przyjdzie czas, no to wtedy sobie to poprawimy, jeżeli się okaże,
że to rzeczywiście da się zrobić.
No i tutaj już się pojawia pierwsze niebezpieczeństwo.
No bo jeżeli coś zrobisz i to już jakoś tam zadziałało, no to istnieje taka
chętka mała, może nawet nie u ciebie, ale u innych decydentów może pojawić się taka
chętka, że jak już to działa, to może po co to ruszać?
Może tutaj już nie ma co?
W sumie to działa, a są jeszcze inne rzeczy do zrobienia.
Może. Może szkoda czasu.
Więc tutaj trzeba uważać na takie rzeczy, Bo moim zdaniem to make it right.
To musimy zrobić za każdym razem, bo to jest po prostu budowanie takiego ultra
długu technicznego i po co to komu?
To i tak się na nas odbije wcześniej czy później.
Więc tutaj trzeba uważać, bo to rajd musi być.
No i tutaj jeszcze nie jest takie bardzo kontrowersyjne.
No ale potem mamy make it fast.
No i tutaj według mnie tu już taka spore niebezpieczeństwo jest, no bo z punktu
widzenia technicznego, no to dlaczego mielibyśmy tego nie zrobić, co nie?
No bo po co marnować takty procesora, jak to może być szybko?
No i poza tym dobry kod na dobry kod to również taki, który szybko działa.
No i dobre rozwiązanie to jest też takie, które działa szybko, więc dlaczego
w sumie mielibyśmy tego nie robić?
No i ogólnie to zależy.
No bo jeżeli mówimy tutaj o jakimś rozwiązaniu, który dajmy na to
działa sobie raz na 24 godziny, przetwarza jakieś tam dane, może buduje jakieś
raporty i to w nocy sobie leci i działa 10 minut, no to czy rzeczywiście tutaj jest
jakaś potrzeba, żeby to działało szybciej.
Ja nie wiem, może jest, a może nie ma.
Trudno powiedzieć, ale to wszystko zależy od sytuacji.
Nie zawsze potrzebujemy rakiety.
Czasami naprawdę wystarczy nam jakaś dorożka albo rower.
Naprawdę?
I tutaj trzeba się pochylić nad ludźmi ze strony biznesu.
Albo pochylić się nie nad nimi, a nad ich potrzebami.
I rzeczywiście czasami tego nie potrzebujemy.
A nawet jeżeli się okaże po pewnym czasie, że ta funkcjonalność zaczyna się
rozrastać, że tam jest coraz więcej danych, że jak to trwało 10 minut, to
teraz już zaczyna trwać dwie godziny i obciąża nam bazę itp itede i tak dalej.
No to nic nie stoi na przeszkodzie, żeby tam wrócić i zrobić to fast.
I tutaj ta zasada tylko służy mi do tego.
Ja w ogóle kocham tą zasadę, ona jest wspaniała.
W ogóle jej twórca też jest wspaniały.
Jak macie sobie chwilę to poczytajcie o nim, bo naprawdę to
jest niezły kozak w IT.
Ale tak jest ze wszystkimi zasadami, bo one wszystkie brzmią ładnie i pięknie i
jest taka chęć, a w szczególności w naszych technicznych sercach, żeby
na nie spojrzeć tak zerojedynkowo.
A świat nie jest zerojedynkowy.
Co już chyba udało nam się tutaj kilka razy udowodnić i ma jakieś odcienie
szarości, więc za każdym razem przepuść sobie te swoje wszystkie
mądre zasady, które istnieją w IT.
Ja tutaj sobie nie kpię.
One naprawdę są spoko, bo mądre zasady są mądre i są zasadami i naprawdę warto je
znać i z nich korzystać, ale korzystać przepuszczając, przepuszczając przez swój
filtr jakiś taki leaderski filtr balansu między tym, co techniczne, a tym, co
biznesowe, między tym, co potrzebne a w danym momencie niepotrzebne.
I to nie chodzi tylko o techniczno biznesowe.
Może chodzić o sprawy techniczno techniczne albo biznesowo biznesowe.
To, co chcę Ci powiedzieć, to naprawdę przepuszczaj to wszystko przez Twój mózg,
bo to zazwyczaj nie jest takie jednoznaczne.
Są różne sytuacje, są różne projekty, są różne sytuacje, a Ty jako lider
musisz to rozumieć jak nikt inny.
Widzimy się w następnej lekcji.