Zarządzaj karierą, zespołem i projektami
4 godz. 9 min · Biznes i Automatyzacje
Cezary ŁysiakDevZaczynamy 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.
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.
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.
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.
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.
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.
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).
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ść.
Przyszła pora na komunikację z innymi działami.
Czyli taka komunikacja można nazwać pozioma.
Ta komunikacja może być bardzo regularna albo wręcz przeciwnie.
Tutaj to wszystko zależy i najczęściej będzie w kontekście jakichś
projektów, które robicie.
Bo czasami dostaniesz jakiś projekt, który jest między dziełowy, czyli jedni robią
to, drudzy robią to, potem jakoś to integrujemy, a może robimy coś razem, a
może nawet mieszamy zespoły do tego projektu?
Trudno powiedzieć, ale czasami będzie tak, że ktoś po prostu ma Ci dostarczyć jakieś
API albo jakąś część rozwiązania, albo na odwrót Ty musisz komuś to dostarczyć.
Najczęściej jednak to jest chyba taka część projektowa, gdzie będziemy tutaj
najwięcej mieli do czynienia z innymi dziełami.
No, może być też oczywiście tak, że to nie musi być taki konkretny, techniczny
projekt, tylko być może na przykład dział marketingu ma coś dla ciebie do zrobienia,
to wtedy się z nimi komunikujesz.
No i tutaj oczywiście zależy, czy się będziemy komunikować z działem bardziej
technicznym, czy bardziej takim mniej technicznym, jak na
przykład marketing czy jakiś inny.
I tutaj dostosowujemy oczywiście komunikację do tego, z kim się
komunikujemy, ale w tym konkretnym przypadku Wypadku możemy sobie pozwolić
już na takie inne rodzaje komunikacji.
Tak samo jak w zespole, troszeczkę bardziej możemy technicznie
podejść do tematu.
Chyba, że właśnie jest to marketing, no to może trochę mniej.
Więc zamiast takich spotkań typowych, projektowych, które oczywiście możemy
robić i czasami wiadomo, lepiej jest pogadać niż zostawiać jakieś dziwne
rzeczy, możemy spróbować jakichś innych rzeczy.
I takimi innymi rzeczami, które mogą tutaj pomóc, może być na przykład dokumentacja.
Czyli wspólnie się umawiamy, że jeżeli tamte prace jakoś trwają, to tworzymy
jakiś dokument, w którym cały czas jak powstają nowe
rzeczy, to my go uzupełniamy.
Jeżeli właśnie ktoś nam tworzy API, my komuś tworzymy API, to od
razu jest udokumentowane.
Być może używamy jakiegoś swaggera i tam się staramy zrobić tak, żeby było od razu
widać, jak się tam wchodzi, czy to jest zrobione, w jakim to jest
miejscu, z czego możemy korzystać, z czego nie możemy korzystać.
Tak się też można komunikować.
Wtedy nie są potrzebne te spotkania, tylko możemy sobie po prostu działać.
Ale jeżeli często jest tak, że czasami jedno dwa zdania więcej znaczą niż 74
dokumentacje, więc wiadomo nie stronimy, ale możemy spróbować inaczej.
Jeżeli to jest jakiś taki projekt, w którym pracujemy wspólnie, być
może nawet nad tym samym kodem.
To kod też może być takim rodzajem komunikacji,
który też warto wziąć pod uwagę.
Wtedy po prostu staramy się tak pisać i tak komunikować, być może jakimiś parami.
Nie wiadomo, może to jest dobry pomysł, żeby ludzie widzieli, że coś idzie do
przodu, bo na przykład dobrze opisany commit już pokazuje, że
już to jest zrobione.
Więc być może to jest coś, na co czekałem.
Być może to jest jakaś część, którą potrzebowałem, żeby pójść
dalej ze swoimi pracami. Nie wiadomo.
Ale taki rodzaj komunikacji też może być
całkiem fajny i parę razy to próbowałem i naprawdę to fajnie działa.
Nigdy nie było tak, że się odbyło bez żadnego spotkania, no bo to
jest praktycznie niemożliwe.
Ale duża, duża część projektu.
Komunikowaliśmy się po prostu na przykład w tym Swaggerem czy nawet tymi PR ami.
To jest naprawdę do zrobienia i warte rozważenia, bo czemu by nie?
A tak poza tym, to ta komunikacja nie za bardzo się różni od takiej
zwykłej komunikacji innej.
Więc tak samo trzeba być transparentnym, trzeba mówić jak jest, trzeba pokazywać,
trzeba negocjować normalne rzeczy, o których już mówiliśmy, więc
nie będę się powtarzał.
A my widzimy się w kolejnej lekcji. Hej!