fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
9 minut

Zawód-team leader. Plan tygodnia.


26.03.2012

Jak kilkukrotnie pisałem – od prawie kwartału nie jestem już samotnym homo-jeźdźcem na zerojedynkowej dev-pustyni. Teraz oprócz kodowania mam sporo innych “zawodowych” spraw na głowie… i o tym sprawach będę czasem refleksje puszczał. Wcześniejszy cykl Zawód-programista wyewoluował sobie w Zawód-team leader. Życie.

Oficjalnie moje stanowisko to “dev lead”, ale “team leader” jest moim zdaniem bardziej pasujące do nowych obowiązków.

Zacznę od rzeczy absolutnie podstawowej, czyli jak zorganizowałem swoją pracę w skali tygodnia. Tak aby wypracować powtarzalny schemat sprawdzający się w różnych scenariuszach, pozwalający na powtarzanie pewnej rutyny.

Początki

Jak chyba ogromna większość osób w mojej sytuacji, zostałem rzucony przez los w całkowicie nowy świat. Oto miałem przestać robić coś, na czym się znam, do czego byłem szkolony, w czym jestem dobry i na którym to gruncie przez lata zdobywałem doświadczenie, i zacząć praktycznie od zera w nowej dziedzinie.

Raczej nie spodziewałem się takiego obrotu spraw w tym konkretnie momencie swego żywota (je ZUS), więc i żadnej teorii na ten temat nie poznawałem.

Zgodziłem się, bo doszedłem do wniosku, że faktycznie – jeśli teraz nie jestem na to jeszcze gotowy (“duchowo”), to już nigdy nie będę. Co by mnie poniekąd zasmuciło.

Efekt był dość porażający – przez pierwsze dwa tygodnie nie udało mi się zrobić prawie nic. Nie do końca wiedziałem czym mam się zająć, kiedy się tym zająć, jak ogarnąć nowe sprawy, i do tego jeszcze generować w projekcie ruch w kierunku jego szczęśliwego zakończenia…

Okazało się, że “na czuja” to za daleko nie pojadę. Musiałem sobie, jak zwykle, wszystko spisać, uporządkować i usystematyzować.

Poniżej efekty.

Założenia

Słyszałem wielokrotnie, od masy osób, że w momencie zmiany stanu z “developera” na “X leadera” mogę zapomnieć o kodowaniu. No może czasem jakiś kawałek architektury, albo code review, ale normalne programowanie? Podobno “się nie da”.

Taki scenariusz był dla mnie najzwyczajniej w świecie nie do przyjęcia z wielu powodów.

Po pierwsze: kodowanie to coś więcej niż moja praca od wielu lat. To moje hobby. To coś, co sprawia mi długofalowo najwięcej przyjemności i satysfakcji. To Moja ulubiona czynność. I nie wyobrażam sobie zamiany tego na ałtlooki, eksele, telefony, skajpy itd. No fuckin way. Między innymi z tego powodu nawet nie starałem się przez ponad dwa lata zmienić własnej jednoosobowej działalności gospodarczej w coś “większego”.

Po drugie: nie rozumiem, nie rozumiem, nie rozumiem jak mogę być jakimkolwiek “leadem” jeśli nie robię tego co zespół – czyli nie tworzę kodu? Serio, jest to dla mnie niepojęte. Tylko i wyłącznie przez implementację takich samych jak wszyscy zadań jestem w stanie zweryfikować czy architektura jest dobra, czy kod się wygodnie pisze, czy nie ma przeszkadzajek dających się łatwo usunąć, czy każdy scenariusz jest odpowiednio przemyślany, czy struktura testów jest odpowiednia i zachęca do ich poprawnego tworzenia, czy narzędzia/biblioteki nie wchodzą w drogę zamiast pomagać… Jasne, zespół może podobne problemy zgłosić albo samodzielnie naprawić, ale jako osoba bezpośrednio odpowiedzialna za projekt i kod powinienem być w stanie znać z autopsji te sprawy. Oczywiście inne obowiązki nie pozwolą mi kodować tyle co zespołowi programiści, ale poziom “zero” jest nieakceptowalny.

Te dwa powody nie są jedyne, ale wystarczające.

Dlatego pierwsze i najważniejsze założenie: muszę programować (kodowanie przez ~40% swojego czasu uważam za cel godny dążenia).

Założenie drugie: muszę wiedzieć co i kiedy robić oraz co i kiedy mogę sobie darować, bo wszystkiego naraz, jak już wiem, nie dam rady pociągnąć.

Założenie trzecie: osoby zainteresowane muszą wiedzieć co i kiedy robię, i muszą móc na tym polegać. Więc mój plan nie może być na tyle trudny do wykonania, żebym w jakiejkolwiek sytuacji nie dał rady się z czymś wyrobić. Ba, w scenariuszu idealnym – tzn gdy nic nie wali się na głowę z priorytetem CRITICAL!!! WORLD IS GOING TO END – wykonanie mojego planu powinno zostawić sporo czasu na bonusowe rzeczy pracowe, na które aktualnie mam ochotę.

Organizacja

Skończyło się na prostym planie tygodnia. Najpierw wypisałem sobie zadania, które muszę wykonywać. A potem porozrzucałem je między dniami w najsensowniejszy na chwilę obecną sposób.

Wiadomo, że praca “w biurze” generuje sporo nieplanowanych przerwań. Myślę też, że nie da się być dobrym “leadem” w modelu zdalnym, jeśli cały zespół pracuje razem w jednym pomieszczeniu. Dlatego postarałem się pogodzić jedno z drugim i zagwarantowałem sobie dwa dni tygodniowo pracy w domu. Te dni najczęściej faktycznie przynoszą o wiele mniej rozproszenia niż dni pozostałe, pozwalając tym samym skupić się na tych zadaniach, które skupienia najbardziej wymagają. Czyli pracach czysto programistycznych.

Oto moja tygodniowa check-lista. Codziennie muszę odhaczyć wszystkie pozycje na niej zawarte. Jak nie, to sam sobie mam prawo wymierzyć siarczystego liścia, bo znaczy że zawaliłem, i to bardzo.

Oprócz tej listy mam też zwykłą listę TODO, gdzie trzymam rzeczy wymagające mojej uwagi: listę bugów do poprawy, kawałki kodu do refaktoringu, maile do napisania, rozmowy do przeprowadzenia itd… Wszystko siedzi sobie w Evernote, którego trzymam się jak bobas cyca od czasu romansu z GTD.

Poniedziałek

* weryfikacja zadań z piątku i weekendu (gdyby ktoś nadgorliwie postanowił coś w domu ponadrabiać)

* kodowanie

* przegląd nowych/zaktualizowanych issues (problemy z założeniami/wymaganiami, do rozwiązania przez klienta, PMa, bądź innych członków zespołu)

* przegląd i ew. rozdzielenie w zespole nowych/zaktualizowanych bugów (błędy znalezione przez test team lub klienta)

Wtorek – praca w domu

* weryfikacja zadań

* kodowanie (większość dnia)

* przegląd issues

Środa

* przygotowanie do spotkania – podsumowanie postępów zrobionych przez zespół w ciągu ostatniego tygodnia

* weryfikacja zadań

* cotygodniowe spotkanie z zespołem

* kodowanie

* przegląd issues

* przegląd bugów

Czwartek – praca w domu

* weryfikacja zadań

* kodowanie (większość dnia)

* przegląd issues

Piątek

* TFS-day, bez kodowania

* oznaczenie zakończonych user stories (potrzebne dla test team do planowania testów na kolejny tydzień)

* user stories z nieskończonymi zadaniami – ustawić planowany tydzień zakończenia

* plany na kolejny tydzień – podział tasków między członków zespołu

* przegląd issues

* przegląd bugów

 

W ten oto sposób koło się zamyka. Taki rozkład jazdy gwarantuje, że:

* zwykle nikt nie czeka na mój udział w rozwiązywaniu issues (sam czekać nienawidzę)

* zwykle weryfikuję zadania na bieżąco, albo je akceptując albo zwracając z feedbackiem; raczej nie wiszą w kolejce dłużej niż jeden dzień (sam czekać nienawidzę, po raz 2)

* zwykle każdy z członków zespołu wie co ma robić na przynajmniej tydzień do przodu

* testerzy mają dane do planowania testów na kolejny tydzień wtedy kiedy im są potrzebne (sam czekać nienawidzę, po raz 3), a ja nie muszę codziennie aktualizować stanu projektu tylko agreguję sobie większość nierównej walki z TFSem na wesoły przedweekendowy piątek

* mi jest dobrze bo mogę póki co powiedzieć: DA SIĘ “leadować” i programować, trzeba tylko znaleźć odpowiednią granicę żeby niczego nie zaniedbać; mam nadzieję, że sprawdzi się to także w perspektywie dalszej niż kwartał

Aha, warty uwagi jest fakt, że do pracy przychodzę przed programistami – staram się być w biurze o 7 rano, czyli przynajmniej godzinę przed pozostałymi członkami zespołu – więc od samego początku jestem już rozchodzony, gotowy do ewentualnego wspólnego rozwiązywania problemów.


Co o tym sądzicie? Pracuję tak na razie dość krótko, nie przetrwało to jeszcze całego cyklu życia projektu i prawdopodobnie będzie modyfikowane, ale… póki co jestem zadowolony. Najważniejsza korzyść: nie kręcę się teraz na krześle jak dziecko w przerębli próbując zająć się wszystkim naraz, a jednocześnie starcza mi czasu na wszystko.

I pytanie jeszcze jedno – czy posty na podobne tematy znajdą w ogóle czytelników? Za/przeciw/kontra? Ciekawe/nudne/pomocne/zbędne?

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Zapisując się na newsletter zgadzasz się na przetwarzanie Twoich danych osobowych w celu wysyłania na wskazany przez Ciebie adres e-mail informacji handlowych o nowościach, promocjach, produktach i usługach związanych z serwisem devstyle.pl. Będzie to marketing bezpośredni, do realizacji którego wykorzystam Twoje telekomunikacyjne urządzenia końcowe. Administratorem Twoich danych osobowych będzie Maciej Aniserowicz prowadzący działalność gospodarczą w Białymstoku (15-215) przy ul. Konopnickiej 14/8, NIP 5422824401. Przysługuje Tobie prawo do cofnięcia zgody, żądania wglądu do Twoich danych, wniesienia sprzeciwu co do ich przetwarzania, sprostowania, usunięcia i ograniczenia przetwarzania. Więcej informacji o tym jak przetwarzam Twoje dane znajdziesz na devstyle.pl/RODO. Powered by ConvertKit
Notify of
Jacek S

Hej Macku, ciekawe uwagi :) Mam kilka pytan, o rzeczy ktorych mi brakuje:

celowo pominales spotkania typu daily meetings? czy robicie retrospekcje? Jak zbieracie feedback odnosnie pracy Twojej, zespolu i konkretnych czlonkow zespolu?

czy jestes odpowiedzialny tez za career development czlonkow zespolu? Jesli tak, jak czesto robicie 1-on-1 i czy robicie :>

Ile osob jest w zespole? pozwala to pokazac, przy jakim zespole nadal jestes w stanie sobie pozwolic na 40% kodowania :)

Marcin Goł
Marcin Goł

tak wyglądają początki. Napisz coś więcej – jak duży zespół, ile projektów równolegle itd A i co do sformułowania że każdy wie co ma robic (lub .każdy wie jakie sa twoje priorytety) to jeszcze zmienisz zdanie:) A i pamiętaj że warto słuchać tego co ludzie mówią.

procent

Faktycznie za mało danych:).
Więc doszczegółowienie:
* zespół: ja + 1-4 osoby, różnie bywa
* 1 projekt

Tak jak napisałem – mam nadzieję że na kodowanie zawsze będzie czas – to jest moja nejlepsza umiejętność i średnio rozsądne byłoby całkowite z niego rezygnowanie.

procent

Jacek S,
Jedyne "formalne" spotkanie to zaznaczone w środę "zebranie". Nie zbieramy się codziennie, ewentualne problemy rozwiązujemy na bieżąco w ciągu dnia.
Feedback – nie bardzo rozumiem. Dużo bugów = średnia praca, mało zamykanych tasków = średnia praca. Z kolei dobry postęp + mało "zwrotów" z feedbackiem ode mnie + mało bugów od testerów = dobra praca.
Career development – to nie zostało sprecyzowane, ale raczej nie do końca. Powinienem "motywować do pracy", co też staram się robić (o tym niedługo), ale to chyba by było na tyle. 1-on-1 nie ma, nie do mnie to należy.

procent

Marcin Goł, Ano początki… ale nigdzie nie jest powiedziane, że to się musi tak strasznie zmienić. Nikt przecież nie będzie wbrew mojej woli wpychał mnie do 5 projektów naraz i dawał mi 10 programistów do prowadzenia, jeśli nie będę sobie z tym radził lub jeśli po prostu nie będę chciał. Co do tego że "każdy wie…" – to wszystko jest "do dotarcia". Jeśli ktoś pracuje inaczej niż bym oczekiwał, lub ja pracuję inaczej niż ktoś inny oczekuje – od tego jest komunikacja. Tak żeby nikt niczego w sobie nie dusił. A co ludzie mówią – słucham bardzo uważnie:). Nie zawsze… Read more »

PaSkol
PaSkol

Na jednego czytelnika czyli mnie możesz w ciemno liczyć. Temat mnie bardzo interesuje, przyznam, że ten wpis pozostawił we mnie dużo niedosytu. Marzy mi się morze szczegółów z całego tygodnia, czyli skoro już plan ustalono, to jak wyglądał taki tydzień wg planu. Ale naprawdę w szczegółach, tj.: * poniedziałek: zweryfikowałem następujące zadania, przeszły te, odpadły te, programowałem to i to, przydzieliłem nowe, * wtorek: (j.w), * itd. To będzie 100 razy lepsze niż książki, bo z życia wzięte i dotyczące żyjącego, niewyimaginowanego projektu. Bezcenna konfrontacja teorii z praktyką. P.S. Ciężko się trzymać w karbach? Tj. fajnie się programuje, można by… Read more »

procent

PaSkol,
No to się cieszę:).
W takie szczegóły wdawać się prawdopodobnie nie będę, tym bardziej że projekt nie jest "publiczny". Nie wiem czy będę mógł o nim pisać mniej ogólnikowo.

A czy ciężko się trzymać w karbach… Nie. Programuję dopiero wtedy gdy mam już wszystko inne zrobione – to ma najniższy priorytet. Nie ma z tym problemu, bo staram się nie brać na siebie kluczowych elementów (o tym też kiedy indziej). Nawet jak jakiś ficzer zajmuje mi 3 tygodnie, a programista zrobiłby to w 3 dni, to nie ma biedy.

barozi
barozi

Witaj, Ja również poproszę o więcej tego typu wpisów. Sam zawsze myślałem, że nie jestem stworzony do takiej pracy, ale widze, że jest to nieunikniony etap w karierze IT.

Pytanko a propos zarządzania zadaniami dla programistów. Czy stosujesz jakieś metody zarządzania np. Visual Management z tablicą zadań i karteczkami, czy zadowalasz się tylko raportami z TFS’a . Z doświadczenia wiem, że zadania na ekranie nie wpływają na zaangażowanie pracownika tak bardzo jak np. kolumna z jego zadaniami na ścianie pokoju :)

procent

barozi,
Nie nazwałbym tego "nieuniknionym etapem w karierze", ale… w pewnym momencie jedna osoba przestaje się skalować:). Poza tym u mnie akurat okazało się że po długim czasie samodzielnej pracy bardzo chętnie spróbuję czegoś nowego.

Co do zarządzania zadaniami to tylko TFS – każdy ma swoje, posortowane stackrankiem, i jazda. Plus co tydzień przechodzimy przez to co kto zrobił i co kto będzie robił teraz.
Ale na szczęście jest tak, że mam właściwie wolną rekę jeśli chodzi o różne praktyki – byle by projekt szedł do przodu – więc pewnie będę wypróbowywał różne pomysły w różnych aspektach "leadowania":).

Hm
Hm

MA:"w tym konkretnie momencie swego żywota (je ZUS)," <- trochę spaliłeś tekst "Owoc żywota twojego je ZUS"

procent

Hm,
Nie spaliłem, po prostu świadomie napisałem kilka słów które nie maja sensu. Co dość regularnie ma miejsce na tym blogu.

PaSkol
PaSkol

Przypuszczałem, że na drodze do szczegółowości staną kwestie tajemnicy biznesowej. Ale może uda się chociaż tak, że podasz iż do zrealizowania były trzy opowieści użytkownika (1 kartka A4, 2 kartki A4, 1.5 kartki A4), które przekładały się na klasę, kolekcję klas, itd. Z tego przestrzelono się w przypadku jednej, druga została zrealizowana przed terminem, a trzecia w terminie. Napotkano takie problemy, ktoś poszedł w maliny, ale udało się to szybko wyłapać. Generalnie chodzi o doniesienie z poligonu, że metodyka Agile rzeczywiście się sprawdza. No i ile rzeczywiście na każde z planowanych czynności zostaje poświęcone czasu. Jak tenże czas oscyluje w… Read more »

procent

PaSkol,
W tym projekcie nie da się odpowiedzieć na zadane przez Ciebie pytania bez wchodzenia w szczegóły, bo nie mamy czegoś takiego jak "user story" jeśli chodzi o wymagania/specyfikację. Nie da się tego zmierzyć "kartkami".

Aha, i nie ośmieliłbym się nazwać tego co robimy "metodyką agile".

PaSkol
PaSkol

No to jakbyś ośmielił się _to_ nazwać? ;)

procent

PaSkol,
Chyba "getting things done, with unit tests" :)

PaSkol
PaSkol

Czyli "Almost TDD" ;)

Łukasz
Łukasz

możesz śmiało pisać na ten temat, jak widać po komentarzach jest zapotrzebowanie ;) i ja chętnie poczytam :)

lila

Genialnie, że już na początku ustawiasz sobie takie reguły pracy – trzymam kciuki za powodzenie.
Mam tylko pytanie: przychodzisz godzinę wcześniej, a o której wychodzisz :-) ?

procent

lila,
Wychodzę też wcześniej:). Zwykle o 15.

procent

Łukasz,
Ano na to wygląda. I spoko bo mam kolejne szkice… które, nie ma co się oszukiwać, pewnie tak czy siak bym w końcu puścił, nawet gdyby miał ich nikt nie przeczytać:).

neino
neino

Też zostałem ostatnio liderem zespołu programistów i tym bardziej będę śledził Twoje posty procent;) W naszej pracy również rozwijamy pewnego rodzaju własną metodologię, do którym można m.in. zaliczyć: – cotygodniowe krótkie zebrania w poniedziałki, – wspólne oszacowywanie i rozdzielanie zadań i bugów w momencie zabrania się za kolejną wersję programu, i w sumie wielu innych rzeczy. Nie wiem jak Ty, ale ja czuję ogromną potrzebę ciągłego usprawnienia całego procesu już od początku, mam parę pomysłów, ale czasami nie jestem przekonany czy one akurat tutaj wypalą, a są w sumie kluczowe. Na szczęście wolna ręka w tej kwestii pomaga. Wkraczamy więc… Read more »

procent

neino, Metodyka != metodologia:), w tym kontekście mówimy o metodyce. Nie wymyślam bynajmniej własnej – po prostu realizujemy projekt z najmniejszym możliwym narzutem procedur. Aktualnie robię to trochę na czuja, ale nadejdzie czas na bardziej świadomie działania w tym zakresie. Co do usprawniania procesu, to zawsze czuję potrzebę usprawniania wszystkiego:). Więc tak, tutaj się zgadzamy. O nowych nawykach/zasadach pisałem w kontekście Gita, nie było tu zbytniej filozofii – najpierw kilka godzin wspólnego szkolenia a potem po prostu wykorzystanie w praktyce. Jeżeli z kolei coś wymaga ujednolicenia/usprawnienia, to zbiorczy mail lub poruszenie czegoś na spotkaniu załatwia sprawę. A evernote’a polecam do… Read more »

Bozar
Bozar

Moj kolega z zespolu zostal jakis czas temu naszym "team leaderem" i powiem szczerze, ze przykro mi na niego patrzyc. Prawdopodobnie zarabia duzo i dlatego jeszcze z nami pracuje. Generalnie dla kierownika zespolu i dyrektora departamenu jest nikim. Panuje zasada: biznes mowi – my robimy. Biznes chce tak – robimy tak, biznes chce inaczej – robimy inaczej…

Jak wyglada twoja wspolpraca z PM oraz z zespolem biznesowym ? Na ile twoje decyzje i sugestie sa uznawane przez pracownikow wyzszego szczebla ?

procent

Bozar,
Nie ma takiej możliwości żebym w firmie, w której spędzam min. 1/3 życia, był "nikim". Niedługo po studiach byłem w jednej firmie "nikim" jako programista, długo tak nie wytrzymałem.
Jeżeli chodzi o styl pracy, wykorzystywane narzędzia, określenie "biurokracji" czy "formalizmów" to mam wolną rękę. A co do wymagań stawianych przed produktami to oczywiście musi być tak jak chce klient:). Mogę coś zasugerować i nikt w firmie mnie nie dusi żebym zamknął ryja, ale jak klient uwagi odrzuci to naturalnie musi być tak jak on chce.

Karol
Karol

Bardzo ciekawy i wartościowy wpis. Ostatnio też sprawuję pieczę nad projektem, mimo tego że również programuję. Pytałeś się, czy podobne posty znajdą czytelników – moim zdaniem na pewno. Blogów o programowaniu w .NET jest bardzo dużo. Blogów, które poruszają takie tematy – o wiele mniej.

PaSkol
PaSkol

Tak sobie jeszcze pomyślałem (skoro już wspomniałeś o Evernote i Getting Things Done), że warto byłoby pokazać, jak zaprzągłeś Evernote do pracy i to w kontekście GTD. Jak przekłada się praca zespołu na strukturę w Evernote, itd.

procent

Karol,
Wola ludu zatem ciałem stać się winna:). Liczę na dzielenie się własnymi doświadczeniami, timliderska grupa wsparcia.

procent

PaSkol,
O GTD i EN w tym kontekście pisałem w zeszłe wakacje ( http://www.maciejaniserowicz.com/?tag=/gtd ). Jeśli chodzi o zespół to nie używamy EN "zespołowo". W firmie korzystamy z onenote budując wspólną bazę wiedzy o realizowanych projektach i wykorzystywanych technologiach. Ja mam oprócz tego evernote’a obok.

PaSkol
PaSkol

Źle się wyraziłem, czytałem ten cykl, do którego link podałeś. Chodziło mi właśnie o GTD jako sposób na pracę zespołu i jego realizację (tej pracy zespołu) w Evernote. No ale skoro OneNote, to w tym kontekście zaintrygowało mnie "budowanie bazy wiedzy" w tymże narzędziu. Nie znam go zbyt dobrze, używałem kiedyś raz, bo była w nim jakaś specyfikacja. Do budowania bazy wiedzy bardziej pasuje mi system wiki, ale być może OneNote to też takie wiki?

Dawid Pytel

Witam Ja jestem team leaderem już kilka lat więc także podzielę się swoimi obserwacjami i doświadczeniem. Według mnie: 1. Team Leader musi posiadać predyspozycje do wykonywania tej pracy. To nie jest tak, że TLem powinna zostać osoba najlepiej znającą się na programowaniu. Zrobimy jej tym krzywdę i po jakimś czasie osoba ta może odejść bo bardziej odpowiada jej po prostu kodowanie. 2. Predyspozycje to przede wszystkim komunikacja z innymi osobami. Ogromna ilość moich obowiązków to analiza przychodzących zadań i błędów, komunikacja z biznesem w celu ich omówienia i doprecyzowania. Oczywiście wszystko zależy od organizacji ale w moim wypadku dochodzi organizacja… Read more »

procent

PaSkol,
OneNote to program do notowania. Do notowania czegokolwiek. Notatniki można synchronizować pomiędzy maszynami i wspóldzielić między osobami. Jest to bardzo fajne narzędzie, tyle że ja osobiście preferuję EN.

procent

Dawid Pytel, Dzięki za uwagi. Z większością się zgadzam, ale z "predyspozycjami" bym nie przesadzał. Wszystko jest kwestią doświadczenia i bardzo wiele zależy od zaangażowania. Wypychanie na siłę najlepszych programistów do roli leaderów jest nagminne, ale faktycznie błędne. Taki programista musi sam chcieć się "zeskalować" – ja chciałem. A czy team leader musi być najlepszym koderem? To zależy. TL to pojęcie tak szerokie, że można tam wrzucić wszystko zahaczające o programistę, PMa, architekta… W moim przypadku moją zaletą jest największe doświadczenie programistyczne i chęć przekazania go zespołowi. PM nie musi być "techniczną wyrocznią", ale ja – tak. Ale znowu –… Read more »

barozi
barozi

Dawid Pytel,
Zgadzam się w 100%. TL to ktoś z pogranicza managera i programisty. Tak jak napisał Maciej: PM nie musi być guru dla programistów, ale TL juz tak. Ja w rozwoju swojej kariery raczej celuję w Architekta. Jakoś bardziej mi pasuje praca bliżej technologii, niż MS Projecta lub temu podobnych.

PaSkol
PaSkol

W celu lepszego zrozumienia, co należy do Twoich obowiązków, pozwoliłem sobie poniżej dokonać ich syntezy na podstawie Twojego harmonogramu. Niestety nie wiem, co dokładnie rozumiesz pod issues (problem? zagadnienie? czy zatem zgłoszony błąd jest problemem?), więc jest on oddzielnie ujęty. Mam nadzieję, że użyty system gwiazdek (notacja zapożyczona z Wikipedii) jest zrozumiały (pokazuje hierarchię). * cotygodniowe spotkanie z zespołem (podsumowanie zeszłotygodniowych postępów) * zadania (w tym zgłoszone błędy) ** przeglądanie oczekujących ** weryfikacja ** podział pomiędzy członków zespołu ** przydział do członków zespołu * user stories ** oznaczenie zakończonych ** ustalenie, które mają niezakończone zadania *** ustawienie planowanego tygodnia zakończenia… Read more »

procent

PaSkol, Niezłe podsumowanie, można wpisywać w umowę na stanowisko TL:). Issues zdefiniowałem przy pierwszym dniu jako "problemy z założeniami/wymaganiami, do rozwiązania przez klienta, PMa, bądź innych członków zespołu". Do obowiązków dorzuciłbym ogólnie bycie "proxy" między zespołem a resztą świata. Jak ktoś ma problem to uderza do mnie – ja go rozwiązuję, zajmuję się jego eskalacją "wyżej" bądź wskazuję osobę która może pomóc. Wpływ na finalną postać kodu mam, można powiedzieć, absolutny. Weryfikuję zadania, więc decyduję o tym czy dany sposób implementacji jest OK czy nie. Działanie funkcjonalności nie jest głównym kryterium akceptacji zadania – czasami nawet nie sprawdzam czy rozwiązanie… Read more »

Artur
Artur

Nigdy nie pracowałem w korpo i pewnie dlatego w mojej świadomości nie istnieje TL. W mojej świadomości, oprócz dev (których można dzielić na junior/senior lub na sto stopni gradacji) istnieją takie role: PM, architekt, analityk. Specjalnie napisałem role, bo jedna osoba może pełnić kilka ról.
O PM wspominasz lakonicznie, architektem jesteś Ty (jak rozumiem, cedując czasami część projektu na dev), a analityka nie widzę. No i mam pytania:
1) A co robi u Was PM?
2) jest gdzieś w tym wszystkim analityk?

PaSkol
PaSkol

Czyli po Twoich wyjaśnieniach wychodziłoby coś takiego:

* cotygodniowe spotkanie z zespołem (podsumowanie zeszłotygodniowych postępów)
* bycie łącznikiem pomiędzy zespołem, a resztą świata
* organizacja pracy zespołu
*** wstępny podział zagadnień na:
**** zgodne z kompetencjami zespołu
**** niezgodne z kompetencjami zespołu (do przekazania komuś innemu)
* zarządzanie zagadnieniami (zadania, błędy)
** przegląd:
** weryfikacja
** podział pomiędzy członków zespołu
** przydział do członków zespołu
** zatwierdzanie i oznaczenie zakończonych
** ustawienie planowanego tygodnia zakończenia pozostałych
* pielęgnacja repozytorium
* kodowanie
* troska o spójność i jakość wytwarzanego kodu, decydujące zdanie co do jego kształtu

I teraz możemy wracać do dyskusji o tym co jest w tej funkcji najważniejsze ;)

procent

Artur, Pracowałem w "korpo", ale teraz nie pracuję. W sumie – na szczęście:). U mnie TL to połączenie ról wymienionych przez Ciebie: senior dev, architekt i częściowo analityk. Plus… kierowanie małym zespołem:). PM zajmuje się monitorowaniem projektu na wyższym poziomie niż ja. Ja mam "pod sobą" jeden projekt, PM może mieć ich 5 czy 8. Siłą rzeczy więc część niskopoziomowych zadan związanych z "zarządzaniem" spada na mnie. Co do "analityka": w tej firmie nie przechodziłem jeszcze przez tą fazę. Ale jest osoba pracująca bezpośrednio z klientem w celu zebrania wymagań czysto biznesowych, a potem m.in. ja na to siadam (choć… Read more »

procent

PaSkol,
Tak, wydaje mi się że zebrałeś wszystko co trzeba. Wracajmy zatem:).

Piotr

Hm w zasadzie opisany przez Ciebie rozkład pracy team leadera pokrywa się się z moim wyobrażeniem, chociaż zaciekawił mnie opis organizacji. Ważne jest to, że występuje różnorodność i naprzemienność zadań, która sprawia, że zawód team leadera wygląda całkiem interesująco. Kto wie, może kiedyś uda mi się zająć takie stanowisko :) Na pewno bym chciał.

Folia

Dobry artykuł… Pomaga zorganizować sobie pracę i zaplanować wszystko niedoświadczonym liderom (mnie) :)

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Facebook

Książka

Zobacz również