Jak być (nie)dobrym tech-leadem.

Przy okazji nowego roku, pojawiły się roszady w pracy pojawi się nowy zespól i mam być tech leadem. Macie jakieś porady, antyporady, co robić, czego nie robić, przydatne porady lub materiały do polecenia żeby się do kształcić?

Jakie dokształcić? Team lead to ten gość co lata na milion spotkań, zbiera wymagania, dogaduje je i przekazuje zespołowi. Możesz ćwiczyć cierpliwość conajwyżej. Od Ciebie też zależy decyzja w razie sporów implementacyjnych.

Takie były obowiązki team leaderów których spotkałem.

Nie przypisuj zadań do ludzi w zespole, tylko dbaj o dobrą jakość backlogu i planowanie sprintu, twórz kulturę w której każdy może pokazać swoje najlepsze oblicze, otwartą na feedback i możliwości usprawnień w retrospekcjach ;)

Nie szalej z tempem, bo to naturalnie powinno wychodzić od zespołu, inaczej zajedziesz team szybko. Staraj się, żeby te interakcje w zespole nie były tylko i wyłącznie skupione wokół tego co trzeba dowieźć, bo mały small talk buduje zespół. Jak masz kogoś, kto trochę odstaje to nie olewaj tylko adresuj.

A tak to życzę cierpliwości i pokory - napisz po pół roku tutaj jak się żyje jako tech lead.

Bądź takim TL jakiego sam byś chciał mieć :)

Naucz się rozwiązywać konflikty i sztuki negocjacji/perswazji. Często będziesz w sytuacjach gdzie to od ciebie będzie coś zależeć i to ty będziesz musiał podjąć ostateczną decyzję, często wbrew innym. Nie zliczę ile razy musiałem podjąć "niepopularne" decyzje. Jako tech lead będziesz też reprezentował zespół/projekt od strony technicznej przed biznesem i często będą na ciebie wywierać presję typu czemu tak długo, czemu tak drogo, a czy nie moglibyśmy dać pani Anetce "na boku" wjazdu do bazy, żeby sobie ręcznie dane poprawiała jak się coś popsuje, itp. Tu właśnie przydaje się umiejętność negocjacji, przekonywania i obrony swojego zdania.

Do tego naucz się delegować zadania. Jako lead będziesz dostawał masę rzeczy do wykonania. Możesz próbować się wykazać i brać wszystko na klatę jak leci żeby się pokazać jaki z ciebie kozak, ale lepiej będzie jak część zadań będziesz delegował do kolegów z zespołu. Np zrobienie POC nowej biblioteki do generowania PDF, rozkminienie integracji z jakimś legacy API które jest w firmie od 20 lat i tylko 2 osoby wiedzą jak ono działa, itp.

No i nie staraj się być najmądrzejszy, pozwól też mówić innym oraz popełniać błędy bo inaczej się nie nauczą.

_flamingAccount napisał(a):

Przy okazji nowego roku, pojawiły się roszady w pracy pojawi się nowy zespól i mam być tech leadem. Macie jakieś porady, antyporady, co robić, czego nie robić, przydatne porady lub materiały do polecenia żeby się do kształcić?

Odśwież sieć kontaktów, CV i co tam jeszcze masz. A poza tym jak robisz zdalnie to masz więcej czasu na siłownie, góry czy bieganie. Zadbaj o fitness bo to pomaga na samopoczucie. Możesz też spróbować work&travel.

Parę kwartałów uciągniesz, a powyższe ciężko będzie ci zreprodukować w nowej robocie.

Zawróć póki możesz. Tech Lead to 2-3x więcej pracy za może 1.3x więcej kasy (liczby wzięte z kosmosu - co nie znaczy że nieprawdziwe).

kelog napisał(a):

Zawróć póki możesz. Tech Lead to 2-3x więcej pracy za może 1.3x więcej kasy (liczby wzięte z kosmosu - co nie znaczy że nieprawdziwe).

Zależy od firmy i ogarnięcia OPa. Jak da sobie wchodzić na głowę z obowiązkami to juz jego problem. Podstawową umiejętnością każdego leada to umiejętność delegowania "mniej waznych" zadań do zespołu by móc się skupić na tym co naprawdę ważne.

Posiadanie lead czy architekt w nazwie stanowiska nie oznacza automatycznie że musimy być najmądrzejsi i gwiazdorzyc przed biznesem żeby się pokazać jacy to super nie jesteśmy i wszystko robimy sami.

Nie szalej z tempem w Scrumie, nie zbijaj estymat. Dbaj o to by pracownicy nie rotowali, zbuduj fajny zespół, a nie zbieraninę ludzi jak to często bywa po korpach.

Pierwsza rzecz z doświadczenia - nie można kogoś "wybrać" tech leadem. Taka pozycja jak tech-lead bierze się (moim zdaniem) stąd, że bierzesz sobie zespół trzech programistów, wrzucasz ich do projektu, i po pewnym czasie widać że jedna z tych osób "kieruje" innych w dobrą stronę, i ona dostaje wtedy etykietkę "lead".

Nałożenie na kogoś z góry takiej etykietki raczej się mija z celem - co niby ktoś chciałby tym zyskać? Że nie można kwestionować takiej osoby? Dla mnie 2/10.

Ale co do rady jak być dobrym tech leadem:

• nie rób micromanagement/development by remote control
• pozwól członkom zespołów wybrać swoje narzędzia, język programowania, toole, sposoby, niech wypracują swój styl pracy
• nie bądź decyzyjny (chyba że team nie jest w stanie podjąć decyzji)
• jeśli jest konflikt w zespole, to Ty rozwiąż remis (ale jeśli w zespole jest konsensus inny niż Twój, to nie ingeruj)
• dbaj o to żeby nie było blockerów i problemów, ale nie narzucaj swojej wizji (chyba że team sam nie może jej wybrać)
• służ radą i pomocą, ale nie narzucaj innym swoich pomysłów

Pierwsza rzecz z doświadczenia - nie można kogoś "wybrać" tech leadem. Taka pozycja jak tech-lead bierze się (moim zdaniem) stąd, że bierzesz sobie zespół trzech programistów, wrzucasz ich do projektu, i po pewnym czasie widać że jedna z tych osób "kieruje" innych w dobrą stronę, i ona dostaje wtedy etykietkę "lead".

Nałożenie na kogoś z góry takiej etykietki raczej się mija z celem - co niby ktoś chciałby tym zyskać? Że nie można kwestionować takiej osoby? Dla mnie 2/10.

Uważam ze tak jak piszesz to najnaturalniejsza ścieżka. Czy inny model ma sens? W obecnym składzie będziemy mieć mid'a/juniora deva, mid'a testera, plus bedziemy szukać seniora, z przyczyn oczywistych gościa z rokiem doświadczenia nie można wybrać lead'em. Ktoś już musi zacząć chodzić na meetingi i próbować ogarniać jak wszystko działa, potem w drożyć juniorów itd.
Ich nia struktura również nie przewiduje, nie technicznych menagerów, wiec jest PO i TechLead jako pierwsze punkty kontaktu.
Tarcia mogą być gdy pojawi się drugi senior, ale plan na seniora jest taki ze w razie co ma mnie zastępować i ogarniać zespól, wiec jakieś specjalnej odgórnej różnicy w szarży nie ma. A doklejenie go zespołu który ma juz 3 osoby psychologicznie, nie powinno doprowadzić do "wyścigu szczurów".
Wiec w obecnej konfiguracji gwiazd, ma to jakiś sens, choć nie uważam ze jest idealne.

Szukając argumentów na tak troche na siłę:
W kulturach innych niż polska, wyraźny podział na role jest koniecznością. Spontanicznie wybicie sie nie jest możliwe, bo pycha i ego lokalnemu menagerowi, oddelegowanie jakiejkolwiek władzy do devów. Albo inni devi będą patrzeć na to i inaczej reagować w zależności od oficjalnego stopnia, wliczając to aktywny sabotaż..

Riddle napisał(a):

Pierwsza rzecz z doświadczenia - nie można kogoś "wybrać" tech leadem. Taka pozycja jak tech-lead bierze się (moim zdaniem) stąd, że bierzesz sobie zespół trzech programistów, wrzucasz ich do projektu, i po pewnym czasie widać że jedna z tych osób "kieruje" innych w dobrą stronę, i ona dostaje wtedy etykietkę "lead".

Nałożenie na kogoś z góry takiej etykietki raczej się mija z celem - co niby ktoś chciałby tym zyskać? Że nie można kwestionować takiej osoby? Dla mnie 2/10.

tu sie cholernie zgadzam, i autorzy ksiązek o zarządzaniu które kiedyś czytałam też takie zdanie mają

Ale co do rady jak być dobrym tech leadem:

• Nie rób micromanagement/development by remote control
• pozwól członkom zespołów wybrać swoje narzędzia, język programowania, toole, sposoby, niech wypracują swój styl pracy
• Nie bądź decyzyjny (chyba że team nie w stanie podjąć decyzji)
• jeśli jest konflikt w zespole, to Ty rozwiąż remis (ale jeśli w zespole jest konsensus inny niż Twój, to nie ingeruj)
• dbaj o to żeby nie było blockerów i problemów, ale nie narzucaj swojej wizji (chyba że team sam nie może jej wybrać)
• służ radą i pomocą, ale nie narzucaj innym swoich pomysłów

ale to trochę przeczy powyższemu, naturalny lider by przedstawiał swoje pomysły tak ze zespół by sie z nimi spontanicznie zgadzał ;)

Miang napisał(a):

Ale co do rady jak być dobrym tech leadem:

• Nie rób micromanagement/development by remote control
• pozwól członkom zespołów wybrać swoje narzędzia, język programowania, toole, sposoby, niech wypracują swój styl pracy
• Nie bądź decyzyjny (chyba że team nie w stanie podjąć decyzji)
• jeśli jest konflikt w zespole, to Ty rozwiąż remis (ale jeśli w zespole jest konsensus inny niż Twój, to nie ingeruj)
• dbaj o to żeby nie było blockerów i problemów, ale nie narzucaj swojej wizji (chyba że team sam nie może jej wybrać)
• służ radą i pomocą, ale nie narzucaj innym swoich pomysłów

ale to trochę przeczy powyższemu, naturalny lider by przedstawiał swoje pomysły tak ze zespół by sie z nimi spontanicznie zgadzał ;)

Noo, nie zgadzam sie. Team lead nie jest od tego żeby narzucać decyzje i pomysły (Albo przedstawiać swoje pomysły tak żeby zespół się zgadzał). Nie chcesz mieć jednynego "prawego" a zespół to jest grupa NPC'ów którzy tylko przepakowują pomysły leada.

Dobry zespół to taki w którym każdy kontrybuuje do projektu, każdy podejmuje decyzje, każdy jest kompetentny, każdy może prowadzić development jak pozostali i lead jest na urlopie.

Miang napisał(a):

nawet junior?

Skomplikowana odpowiedź. Zależy od tego co chcesz. Powiem tak:

• Jeśli chcesz mieć kompetentny zespół, który dostarcza jakościowe produkty, któremu można ufać, jest rzetelny:

  • ...to każda osoba w zespole powinna: umieć dostarczać całościowe oprogramowanie, nie powinno być silosów, powinna podejmować decyzje techniczne o całym produkcie (update'ach, deployach, commitach, rozwiązaniach, testach), etc.

• Natomiast jeśli chcesz mieć grupę nieogarów których trzeba pilnować, i jeden gostek ma ich ogarniać i odpowiadać za nich, bo pozostali robią fuszerę

  • no to wtedy to nie jest team lead i zespół. Wtedy to jest banda amatorów jeden sensowny programista. I wtedy faktycznie możesz mieć osobą która robi micromanagement nad tymi juniorami, i może nadpisać każdą ich decyzję. Tylko że tak się nie da dostarczać wartościowego oprogramowania, nie da się jechać szybko i tanio - wtedy powstaje shitcode i shitprodukt.

Riddle napisał(a):

Miang napisał(a):

nawet junior?

Skomplikowana odpowiedź. Zależy od tego co chcesz. Powiem tak:

• Jeśli chcesz mieć kompetentny zespół, który dostarcza jakościowe produkty, któremu można ufać, jest rzetelny:
  • ...to każda osoba w zespole powinna: umieć dostarczać całościowe oprogramowanie, nie powinno być silosów, powinna podejmować decyzje techniczne o całym produkcie (update'ach, deployach, commitach, rozwiązaniach, testach), etc.

tylko ze wtedy jakość zespołu jest jakością najsłabszego jego członka

• Natomiast jeśli chcesz mieć grupę nieogarów których trzeba pilnować, i jeden gostek ma ich ogarniać i odpowiadać za nich, bo pozostali robią fuszerę
  • no to wtedy to nie jest team lead i zespół. Wtedy to jest banda amatorów jeden sensowny programista.

kilku takich co się do wszystkiego nadają i jeden lub dówch na przyuczeniu

Miang napisał(a):

Skomplikowana odpowiedź. Zależy od tego co chcesz. Powiem tak:

• Jeśli chcesz mieć kompetentny zespół, który dostarcza jakościowe produkty, któremu można ufać, jest rzetelny:
  • ...to każda osoba w zespole powinna: umieć dostarczać całościowe oprogramowanie, nie powinno być silosów, powinna podejmować decyzje techniczne o całym produkcie (update'ach, deployach, commitach, rozwiązaniach, testach), etc.

tylko ze wtedy jakość zespołu jest jakością najsłabszego jego członka

To jest oczywiście prawda, ale nie ma to specjalnego znaczenia, skoro najsłabszy członek jest tak samo kompetentny jak najmocniejszy członek (albo prawie tak samo).

Miang napisał(a):

kilku takich co się do wszystkiego nadają i jeden lub dówch na przyuczeniu

Po co Ci tych dwóch na przyuczeniu?

Jeśli ja miałbym teraz postawić projekt, i miałbym wybrać 3ech kompetetnych pracowników, albo 3ech kompetetnych + 2óch juniorów, to bez wahania wybrałbym to pierwsze. Ci goście na przyuczeniu przez większość czasu tylko by spowalniali tych trzech kompetentnych (dopóki sami się nie staną kompetentni). Ale jeśli chciałoby się to osiągnąć, to lepiej tych "na przyuczeniu" szkolić na side jakichś side, throw-away projektach.

_flamingAccount napisał(a):

mam być tech leadem. Macie jakieś porady

Tak. Zrezygnuj jeśli możesz.

Tak czytam te posty i zastanawiam się, ile z nich to faktyczna analiza tematu, a ile marzenia. Większość z rad być może sprawdziłoby się jedynie w bardzo dojrzałym zespole, gdzie nikt nigdy się nie kłóci, a pozycja osoby jest rośnie jedynie z wiedzą.

1. Jasne, że im mniej trzeba kontrolować ludzi tym lepiej, a micromanagement to taka najwyższa forma kontroli w IT. Czasem jednak trzeba to robić, zwłaszcza gdy się ma nowe osoby w zespole - tj. „zrób X, a następnie pogadaj z Y, potem napisz do Z”. Oczywiście docelowy stan powinien być taki, że ty sobie brylujesz przy piłkarzykach i czytasz o hiperfajnych technologiach, ale dojście do tego stanu zajmuje czas. Czasem nigdy się dojść do niego nie da nawet bo ludzie przychodzą i odchodzą.
2. Tak samo jest z podejmowaniem decyzji - czasami trzeba wymusić decyzję. Super, fajnie, żeby zespół sam je podejmował, ale zawsze znajdzie się sytuacja patowa - np. jedna osoba będzie chciała Lomboka, druga nie, reszcie to obojętne. I co wtedy? Tech lead decyduje, będzie ktoś niezadowolony z decyzji - ale takową musi być podjęta.

Z takich porad porad - pamiętaj, że nie wszystko musi być 100% dobrane pod zespół. Takim sztandarowym przykładem jest statyczna analiza kodu - w 90% lepiej skorzystać z gotowego zestawu reguł, niż tworzyć własny. A już o niebo lepiej niż tworzyć własne reguły.
Druga porada - staraj się monitorować, gdzie i kto tworzy błędy. Niekoniecznie wysoka liczba błędów będzie winą osoby, która je robi, ale jednak warto się temu przyglądać.
Trzecia - staraj się, żeby w backlogu były taski techniczne czyli dokumentacja, praca nad CI/CD, dopisywanie testów, narzędzi typu mocki (jeśli trzeba). Czasem trzeba wyszarpać ten czas, ale się opłaca.
Czwarta - naucz się chwalić. Jak zespół zmniejszy liczbę generowanych błędów o np. 30% przy zachowaniu tego samego tempa - powiedz to tak, żeby chociaż menedżer usłyszał. I zespół.

Tak. Zrezygnuj jeśli możesz.

@onomatobeka why?

Synchronizacja działań między różnymi ludźmi i ułatwianie komunikacji. To zwykle szwankuje.

Albo ludzie się nie dogadują ideologicznie (i wygrywa osoba z największą siłą przekonania albo władzą w zespole, ew. większość, czyli idiokracja)

Albo nie dogadują się pod kątem działań (np. dwie osoby robią ten sam task albo robią coś osobno, bez jakiejkolwiek koordynacji działań, ew. w inny sposób sobie nawzajem przeszkadzają).

Albo nie dogadują się pod kątem oczekiwań (np. biznes nieklarownie dał znać programistom, czego oczekuje, albo jeden programista powiedział coś do drugiego, a on inaczej zrozumiał).

Albo nawala workflow (np. przeciąganie integracji tak długo, że aż występują konflikty w Git, brak automatyzacji itp.)

Ludzie ogólnie mają skłonność do:

• zakładania, że druga osoba obdarzona jest telepatią
• zakładaniu a priori, że to oni mają rację, a inna osoba nie ma racji
• działaniu fragmentarycznie i oczekiwaniu, że w magiczny sposób fragmentaryczne działania się zintegrują w jedną całość bez wysiłku włożonego w komunikację, integrację, standaryzację, automatyzację procesów itp.)

Czyli ideałem byłaby nad-komunikacja, budowanie faktycznego porozumienia i synchronizacja działań.

Ja, niestety częściowo na podstawie swoich błędów mogę dać takie rady:

• Być częścią zespołu, a nie poganiaczem.
• Izolować zespół od jak największej ilości g...a, które krąży w przestrzeni. Serio, nikogo nie powinno obchodzić, że ktoś gdzieś, coś dziwnego powiedział. Nie chodzi o kręcenie za plecami kolegów, tylko moment refleksji, czy faktycznie jakiś piard pani Halinki z księgowości jest informacją, którą należy nakręcać.
• Nabrać pokory. Wspierać i oczekiwać krytyki własnych pomysłów. Szukać najlepszych rozwiązań problemów, a nie forsować własne.
• Brać na siebie odpowiedzialność za efekty działania zespołu. Wewnątrz otwarcie komunikować problemy wewnątrz zespołu, na zewnątrz zero tekstów "no nie dowieźliśmy, bo Kowalski nie dał rady zrobić swojego zadania".
• Dawać jak najwięcej swobody w wyborze narzędzi, bibliotek, podziału zadań, sposobu pracy.
• Pisząc na wysokim poziomie, to "zespół odnosi sukces i zespół odpowiada za swoje porażki".
• Dziękować, chwalić, doceniać. Oficjalnie wszyscy grają cyników, co to "są tu tylko dla kasy", ale szczere i wyłącznie szczere pochwały są zawsze mile widziane.

wartek01 napisał(a):

Tak czytam te posty i zastanawiam się, ile z nich to faktyczna analiza tematu, a ile marzenia. Większość z rad być może sprawdziłoby się jedynie w bardzo dojrzałym zespole, gdzie nikt nigdy się nie kłóci, a pozycja osoby jest rośnie jedynie z wiedzą.

1. Jasne, że im mniej trzeba kontrolować ludzi tym lepiej, a micromanagement to taka najwyższa forma kontroli w IT. Czasem jednak trzeba to robić, zwłaszcza gdy się ma nowe osoby w zespole - tj. „zrób X, a następnie pogadaj z Y, potem napisz do Z”. Oczywiście docelowy stan powinien być taki, że ty sobie brylujesz przy piłkarzykach i czytasz o hiperfajnych technologiach, ale dojście do tego stanu zajmuje czas. Czasem nigdy się dojść do niego nie da nawet bo ludzie przychodzą i odchodzą.
2. Tak samo jest z podejmowaniem decyzji - czasami trzeba wymusić decyzję. Super, fajnie, żeby zespół sam je podejmował, ale zawsze znajdzie się sytuacja patowa - np. jedna osoba będzie chciała Lomboka, druga nie, reszcie to obojętne. I co wtedy? Tech lead decyduje, będzie ktoś niezadowolony z decyzji - ale takową musi być podjęta.

Z takich porad porad - pamiętaj, że nie wszystko musi być 100% dobrane pod zespół. Takim sztandarowym przykładem jest statyczna analiza kodu - w 90% lepiej skorzystać z gotowego zestawu reguł, niż tworzyć własny. A już o niebo lepiej niż tworzyć własne reguły.
Druga porada - staraj się monitorować, gdzie i kto tworzy błędy. Niekoniecznie wysoka liczba błędów będzie winą osoby, która je robi, ale jednak warto się temu przyglądać.
Trzecia - staraj się, żeby w backlogu były taski techniczne czyli dokumentacja, praca nad CI/CD, dopisywanie testów, narzędzi typu mocki (jeśli trzeba). Czasem trzeba wyszarpać ten czas, ale się opłaca.
Czwarta - naucz się chwalić. Jak zespół zmniejszy liczbę generowanych błędów o np. 30% przy zachowaniu tego samego tempa - powiedz to tak, żeby chociaż menedżer usłyszał. I zespół.

Dodatkowo wszyscy zakładają że będziesz mieć ogarniaczy a tu góra Ci powie, że może zapłacić z 15k brutto max z jednego programistę, albo niedajboze od razu dostaniesz hindusów do zespołu to się męcz.

Akurat miałam założyć dosłownie taki sam temat na forum
Obecnie mam 4 punkty, które są moim planem postępowania:

• Spisywanie listy TODO (na podstawie maili i wiadomości z komunikatora - do kogo w jakiej sprawie się odezwać, kto czeka na pomoc, jaki request utknął i trzeba eskalować itp) i obsługiwanie zgodnie priorytetem wynikającym ze zdrowego rozsądku - bo nie da się wszystko na raz i odkąd zaczęłam po prostu odpisywać nie mam czasu, odezwę się później/jutro w tej sprawie, zaczęło mi się lepiej żyć, a potem patrzę na listę TODO i odhaczam w swoim tempie.
• Delegowanie zadań
• Rozwiązywanie/adresowanie problemów blokujących innych devów
• Stworzenie przestrzeni, gdzie inne osoby mogą się wykazać, mogą mieć inicjatywę (a nie tylko zrobić taska)

Osobiście mam problem z natłokiem rzeczy, które do mnie spływają, ale pomału znajduję balans. Czuję też, że przez to, że mamy akurat przeciągnięty termin dowiezienia nowego bardzo istotnego feature'a, planuję strategicznie rozlokowanie sił pod kątem sensownego dostarczenia i cierpią moje ideały (żeby nie było silosów wiedzy i jeden dev pracujący nad tematem, żeby było miejsce na kreatywność i techniczny rozwój a nie tylko robienie tasków itp).

Podbijam temat, chętnie poczytam więcej opinii i doświadczeń.

szarotka napisał(a):

Akurat miałam założyć dosłownie taki sam temat na forum
Obecnie mam 4 punkty, które są moim planem postępowania:

• Spisywanie listy TODO (na podstawie maili i wiadomości z komunikatora - do kogo w jakiej sprawie się odezwać, kto czeka na pomoc, jaki request utknął i trzeba eskalować itp) i obsługiwanie zgodnie priorytetem wynikającym ze zdrowego rozsądku - bo nie da się wszystko na raz i odkąd zaczęłam po prostu odpisywać nie mam czasu, odezwę się później/jutro w tej sprawie, zaczęło mi się lepiej żyć, a potem patrzę na listę TODO i odhaczam w swoim tempie.
• Delegowanie zadań
• Rozwiązywanie/adresowanie problemów blokujących innych devów
• Stworzenie przestrzeni, gdzie inne osoby mogą się wykazać, mogą mieć inicjatywę (a nie tylko zrobić taska)

Powiedziałbym, że tylko dwa ostatnie mają sens, a dwa pierwsze są słabe.

Dobry teamlead powinien pozwolić zespołowi na samoorganizację.

@Riddle Jest mnóstwo badań na ten temat i wskazywanie konkretnej osoby ma większy sens niż powiedzenie "niech ktoś się tym zajmie"

Tutaj bardziej chodzi o ludzką naturę. We większości przypadków nikt nie będzie kwapił się do dodatkowej roboty jeśli nie ma takiego obowiązku (tzn jak ludzie mają wybór czy chcą miec więcej pracy to z reguły podejmą decyzje, żeby jej nie mieć). Założenie, że wszyscy w zespole czują odpowiedzialność projektową jest z goła trochę naiwne. Idea oczywiście bardzo prawa, ale no wszyscy wiemy jak jest ;-) Pomijam już fakt priorytetów. Ludzie mają swoje tematy ongoing i raczej mało kto rzuci to na zasadzie "bo inny temat trzeba zrobić, niech ktoś go zrobi". Dlatego oddelegowanie konkretnej osoby jest tutaj imo jedynym sensownym wyjściem - Określa się priorytet i na tej podstawie konkretna osoba bierze na klatę ten konkretny temat.

Zawczasu odpowiem na argument odnośnie samoorganizujących się zespołów w agile. Ile faktycznie takich zespołów na 10 się znajdzie? 1-3? Definicja to jedno a realia to drugie.

Jak będziesz bucem, to nikt do Ciebie po pomoc nie przyjdzie. Natomiast jeśli znajdziesz czas, by porozmawiać z ludźmi i im pomóc, czy podzielić się wiedzą, to będą to dobre podstawy. Docenią, że ktoś im pomógł, nierzadko podziękują i przyjdą ponownie (bo będą wiedzieli, że jesteś rozsądnym gościem, a nie jakimś buco-kaznodzieją).

Kolejna sprawa, jeśli się jeszcze nie pogodziłeś z tym, że "nikt tego nie zrobi lepiej od Ciebie", to powinieneś ;-) Ułatwi to liderowanie Tobie i innym. Do tego powinieneś być na bieżąco z technologią (może nie znać jej dogłębnie, ale szeroko). Dzięki temu, będziesz w stanie zapewniać rozwój innym ("czy możesz rozpracować temat XYZ, może będzie pasował do naszego case'a. Interesują mnie szczegóły A/B/C").

Powyższe dla tech leada. W przypadku team leada sprawa się komplikuje, bo każdy człowiek jest inny i leadership buduje na innych fundamentach (są profile psychologiczne leaderów, np. buduje autorytet na bazie empatii, wiedzy eksperckiej czy komunikacji itp.) oraz dostosowuje komunikację do innych profili psychologicznych. Tu albo natural-born leader, albo trzeba się dokształcić z liderowania.

@Riddle: w dobrym zespole nie powinno być silosów, i właśnie każdy powinien zajmować się każdym tematem.

prędzej zbudujesz dobry zespół silosując lub mikrosilosująć ludzi. Utrzymując niski busfactor robisz dobrze na oliwioną maszynę z wymiennymi cześciami. Moim zdaniem optymalna sytuacja jest taka ze każdy potrafi wykonać zadania w waszym stacku, ale wiekszości przypadków są one przypisane do osoby która robi je najsprawniej, bo np. ma wprawe lub je lubi.

@_flamingAccount: Masz jakieś dane na poparcie tej tezy, czy "tak mi się wydaje"?

Której tezy?

niski busfactor robisz dobrze na oliwioną maszynę z wymiennymi cześciami
Jest taka filozofia ze jeśli chociaż jedna osoba dojdzie lub odejdzie ze zespołu to jest to juz nowy zespół z inna dynamika miedzy ludzmi i nowymi przejściowymi tarciami. Jest w tym jakiś sens i z tego punktu widzenia, optymalizacja bus-factora, czyli tego co sie stanie gdy team sie rozleci nie słuzy budowaniu zespołu, prawie z definicji. Może być to dobre dla projektu ale nie buduje to sprawnej grupy ludzi prawie ze z definicji.

Moim zdaniem optymalna sytuacja(...) każdy potrafi wykonać zadania(...), ale(...) przypisane do osoby która robi je najsprawniej

To jest tautologia, bus factor jest rozmiaru całego zespołu, wiec jest optymalny a równocześnie odnosisz korzyści z mikrooptymalizacji.

prędzej zbudujesz dobry zespół silosując lub mikrosilosująć ludzi

Dobry zespół musi sie czymś wyróżniać, innaczej to tylko zespół. Korzystając ze specjalizacji ludzi i ich talentów, możesz trafniej estymować, redukować liczbę bugów lub szybciej dostarczać kod niz normalnie. W sytuacjach skrajnych możesz oddelegować ludzi dobrych w danej kwestii do gaszenia pożarów.
Przychodzi mi jeszcze jedna zaleta do głowy, zdobywanie wiedzy samodzielnie jest trudniejsze niż zgapienie od kolegi, wiec jak ktoś postawiony przed tym samym zadaniem piąty raz znajdzie szybsze rozwiązanie problemu, reszta zespołu moze je od niego zgapić.

Odpowiadając ostatnie to moja teza bez, danych nie ma ale to bezpieczna teza. Redukcja bus-fatoru to kurs na jako-tako ale bez turbulecji, umiarkowane specjalizacja daje lepszy potencjał ale zwiększa ryzyko.

Tutaj bardziej chodzi o ludzką naturę. We większości przypadków nikt nie będzie kwapił się do dodatkowej roboty jeśli nie ma takiego obowiązku (tzn jak ludzie mają wybór czy chcą miec więcej pracy to z reguły podejmą decyzje, żeby jej nie mieć). Założenie, że wszyscy w zespole czują odpowiedzialność projektową jest z goła trochę naiwne. Idea oczywiście bardzo prawa, ale no wszyscy wiemy jak jest ;-) Pomijam już fakt priorytetów. Ludzie mają swoje tematy ongoing i raczej mało kto rzuci to na zasadzie "bo inny temat trzeba zrobić, niech ktoś go zrobi". Dlatego oddelegowanie konkretnej osoby jest tutaj imo jedynym sensownym wyjściem - Określa się priorytet i na tej podstawie konkretna osoba bierze na klatę ten konkretny temat.

Zawczasu odpowiem na argument odnośnie samoorganizujących się zespołów w agile. Ile faktycznie takich zespołów na 10 się znajdzie? 1-3? Definicja to jedno a realia to drugie.

W zespołach w których byłem(i one działały) problem samoorganizacji i przydzielania tasków był rozwiązywany był rozwiązywany mniej więcej tak:
-Błędy dzieliły się na dwa rodzaje, "każdy się czasem myli i to normalne" oraz drugie "OPR dla czego to popsułeś, nie można takich rzeczy robić". Różnica miedzy 1 a drugimi była taka że 1 to niewinne bugi, drugie to sytuacje marnujące czas innym członkom zespołu, innym zespołów, nie budujący się projekt itp. Im więcej wiecej strat dla środowiska na około tym ważniejsze jest żeby posprzątać swoje jak najszybciej, najlepiej zanim inni się skapną i zaczną narzekać.
-Jeśli każdy developer ma taka wewnętrza skale to większości przypadków, nie ma problemów ze ktoś się nie kwapi, ważnej rzeczy zrobić bo są ważne.
-Inną zasadą było ze kto popsuł ten sprząta. Popsułeś testy napraw testy, w prowadziłeś buga, spoko każdemu się zdarza, ale weź to popraw na spokojnie. Po pierwsze kara robienie po łepkach, ale powoduje też jakiś rodzaj odpowiedzialnosci za sekcje w kodzie i ludzie są zmotywowani żeby znaleźć co się popsuło.
-Każdy wie są taski fajnie i nie fajne a planowania są nudne. Jeśli uważasz i udzielasz się na planowaniu to prawdopobieństwo że sam wybierzesz zadania dla siebie rośnie(bo po prostu wiesz jak je zrobic), jeśli sie nie udzielasz, wybierasz z tego co zostało lub dosjesz przydział. Proste i sprawiedliwe, samolubny interes pokrywa sie z interesem grupy.
-jak samo organizacja przestawała działać, to miały miejsce soft-delegacje, sugestie, szukanie chętnego itp.
-jeśli chętnego dalej nie było a coś musiało być zrobione i było ważne, to padało "masz wolne capacity, przypisze do Ciebie"
-jeśli coś musiało być zrobione i nie było ważne, np. prezentacja to chętnego się losowało lub rozdzielało się nieszczęścia "żeby było po równo".
-osoby wykonujące wyjątkowo trudne lub parszywe zadania oraz takie biorące dodatkową odpowiedzialność dostawały nie pisane punkty szacunku, wymienialne na święty spokój.

-dodatkowo nie zależnie od tego wszystkiego był jakiś PO i management określający zakres zadań lub piorytety.

W zespole dysfunkcyjnym w którym byłem nikt nie brał za nic odpowiedzialność... i nic nie działało...