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?
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 :)
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ą.
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.
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.
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 się z tym po prostu zgadzam.
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 jeszcze odrobinkę, ale minęło 40% trzeba się zająć resztą.
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.
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 :)
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":).
MA:"w tym konkretnie momencie swego żywota (je ZUS)," <- trochę spaliłeś tekst "Owoc żywota twojego je ZUS"
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.
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 różnych tygodniach.
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".
No to jakbyś ośmielił się _to_ nazwać? ;)
PaSkol,
Chyba "getting things done, with unit tests" :)
Czyli "Almost TDD" ;)
możesz śmiało pisać na ten temat, jak widać po komentarzach jest zapotrzebowanie ;) i ja chętnie poczytam :)
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 :-) ?
lila,
Wychodzę też wcześniej:). Zwykle o 15.
Ł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ć:).
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 od czasu w automatyczne testowanie systemowe, próbujemy metodologii kanban itp. itd. W swoich postach może akurat poruszysz też tematykę wprowadzania nowych nawyków, pewnych nowych zasad w pracy zespołu, byłoby miło:)!
Osobiście myślałem, że moja praca niewiele się zmieni od momentu przejście na leadowanie i tak trochę do tego podchodziłem na początku, próbowałem nawet kodować przez 95% czasu, ale jest tak jak piszesz… to raczej nie ma sensu i trzeba wyznaczyć sobie jakieś priorytety i zredukować kodowanie, cóż, trochę tego szkoda, ale może też zacznę korzystać z evernote-a, skoro tak polecasz:)
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 wszystkiego. Równolegle używam OneNote’a, ale jednak EN jest dla mnie wygodniejszy (i ma podobno lepszego klienta na androida – nie widziałem tego onenote’a więc się nie wypowiadam).
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 ?
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.
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.
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.
Karol,
Wola ludu zatem ciałem stać się winna:). Liczę na dzielenie się własnymi doświadczeniami, timliderska grupa wsparcia.
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.
Ź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?
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 spotkań, kontrola pracy, tworzenie planów itp.
3. Efekty pracy team leadera są inne niż programisty. To jest właśnie główny powód dla którego programiści nie potrafią odnaleźć się w roli TLa. Efekt pracy programisty jest namacalny, programista tworzy kod. TL dba o programistów, likwiduje przeszkody, upewnia się, że zespół wie co ma robić i robi robotę, którą faktycznie ma się zajmować :) Brak POZORNIE niezauważalnych efektów może być frustrujący.
4. TL nie musi być najlepszym koderem. Ważne aby nauczył się pracować z ludźmi, którzy są lepsi od niego. Jeżeli przełkniesz to, to jest ok. Oni ufają Ci, że dbasz o ich prace, Ty ufasz im i pytasz ich o propozycje rozwiązania problemów.
5. Czy jest miejsce na kodowanie? To zależy od organizacji i osoby TL. Fatalne jest patrzenie na tworzone rozwiązanie jedynie z poziomu kodera. Powinieneś patrzeć nieco szerzej.
Tak jak pisałem, bycie Team Leaderem nie powinno być nagrodą dla programisty. Chcesz awansować ale być bliżej spraw technicznych? Zostań projektantem lub architektem.
Czy bycie TLem może sprawiać frajdę? Z pewnością nie taką jak programowanie :) Ale tutaj też możesz znaleźć dużo obszarów do rozwoju.
Pozdrawiam
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.
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 – to już zależy od oczekiwań firmy i od definicji stanowiska w danej sytuacji.
A, no i w sumie nie napisałem tego chyba wprost – to nie był dla mnie "awans". Po prostu przyszedłem do firmy na to stanowisko. Nie pracowałem tam wcześniej jako programista.
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.
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 tych zadań
* issues
** przegląd nowych/zaktualizowanych tj.:
*** problemy z założeniami/wymaganiami,
*** do rozwiązania przez:
**** klienta,
**** PMa,
**** członków zespołu
* pielęgnacja repozytorium
* kodowanie
Mam nadzieję, że zweryfikujesz to co mi się wymyśliło, a może jeszcze coś dorzucisz ;).
Ciekawi mnie też, czy (skoro "prowadzisz zespół" ;) ) masz wpływ na finalną postać kodu, czyli podejmujesz decyzję, że tutaj jednak inny wzorzec, a tutaj należy skorzystać z już istniejących klas i dokonać jedynie ich rozbudowy poprzez kolejną klasę potomną, zaś ta klasa powinna być rozbita na dwie, bo kłóci się z zasadą pojedynczej odpowiedzialności. Czyli czy jesteś odpowiedzialny za utrzymanie spójności kodu, aby nie "poszedł sobie w maliny".
Przy okazji, w jednym z komentarzy pisałeś, że nie macie opowieści użytkownika, a mimo to używasz tego pojęcia w harmonogramie (i ja je ująłem w powyższej liście zadań).
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 działa, bo od tego jest programista (powinien uruchomić system przed oznaczeniem zadania jako skończone) oraz testerzy. Dla mnie liczy się głównie jakość kodu i to właśnie do mnie należy podjęcie decyzji gdzie można pójść na kompromis, a gdzie jednak trzeba docisnąć i coś zrobić inaczej/lepiej, co zasługuje na refactoring a co nie, gdzie jaki wzorzec, gdzie jakie narzędzie itd.
Co do User Stories to mamy je czysto "organizacyjnie" dla samych siebie – pod nie podpięte są poszczególne taski programistyczne. W tym akurat projekcie czasami 1 US = 1 task.
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?
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 ;)
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ć nie tylko ja) i tłumaczę na technologię. Tak to widzę.
PaSkol,
Tak, wydaje mi się że zebrałeś wszystko co trzeba. Wracajmy zatem:).
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ł.
Dobry artykuł… Pomaga zorganizować sobie pracę i zaplanować wszystko niedoświadczonym liderom (mnie) :)