Bedąc na Wroc# (o którym pisałam tutaj) brałam udział w rewelacyjnej prezentacji Roy’a Osherove „Growing great teams and adopting new processes through Elastic Leadership”. Bardzo mnie ona zainspirowała, więc pokrótce przedstawię jej temat.
Bus factor
Tłumacząc na język polski jest to „czynnik autobusowy”. O co w nim chodzi? Jest to liczba osób, które muszą zostać przejechane przez autobus (lub po prostu ulec jakiemuś losowemu przypadkowi, który wykluczy je z prac w projekcie), żeby nie można było ukończyć projektu. Załóżmy, że w zespole tylko jedna osoba umie robić builda. Jeśli jej zabraknie, może się okazać, że nikt inny nie umie poradzić sobie z tym zadaniem i projekt nie może być kontynuowany. W tym przypadku wartość Bus factor wynosi 1.
Ok, a jak to się ma do tematu?
Zaraz będę rozwijać. Na podstawie powyższego akapitu chyba wszyscy się zgodzimy, że warto maksymalizować wartość Bus factor. Dzięki temu nieobecność jednej osoby nie powinna znacząco wpływać na projekt.
Dobry zespół – co to znaczy?
Można zapewne napisać wiele zdań określając dobry zespół. Ale tak naprawdę można go opisać w jednym zdaniu. Dobry zespół to taki, który umie sam rozwiązywać swoje problemy. Jeśli zabraknie jakiejś osoby w zespole – nie szkodzi, reszta powinna sobie poradzić. Jak to mówią:
„Show must go on”
Jak sprawdzić czy leader robi dobrą robotę?
Według Roy’a jest na to tylko jeden sposób – sprawić, żeby stał się niepotrzebny. Jego najważniejszym zadaniem jest uczenie innych tego, co sam już umie. Dzieki temu:
- firma się rozwija (pracownicy ciągle poszerzają wiedzę),
- efektywność teamu wzrasta,
- efektywność projektu wzrasta,
- leader ciągle ma pracę (uczy innych),
- leader ma więcej czasu, żeby samemu się rozwijać.
Oczywiście nie trzeba umieć wszystkiego perfekcyjnie. Załóżmy, że mamy w zespole osobę, która utrzymuje całą infrastrukturę serwerową. Jest w tym biegła. Nie chodzi o to, żeby wszyscy członkowie zespołu również perfekcyjnie umieli zarządzać tą infrastrukturą. Chodzi o to, że jeśli ta osoba pójdzie na urlop, trafi do szpitala czy po prostu odejdzie z pracy, to reszta teamu sobie poradzi. Może zajmie im to więcej czasu, może nie będzie to najbardziej optymalne rozwiązanie, ale będzie – i będzie działało.
Cel
Celem powinien być zespół złożony z liderów. Chodzi tu przede wszystkim o globalną wiedzę dotyczącą projektu, która często bywa porozdzielana między członkami zespołu lub umiejscowiona w jednej osobie team lidera. Jeszcze jedną ważną sprawą jest to, że takiego teamu się trzeba tworzyć z najlepszych zatrudnionych osób. Taki team się buduje przez jakiś czas – nawet z kiepskiego zespołu. Jest to praca ciężka – ale kto mówił, że leadership to łatwa praca?
Podoba Ci się to, co tworzę? Chcesz dostawać informacje o:
– wydarzeniach, które organizuję lub wspieram (np. konferencje, meetupy, webinary)
– inicjatywach, które organizuję lub wspieram (np. GeekWeekWro, DevAdventCalendar)
– moich prelekcjach, kursach i szkoleniach
– wyróżnionych artykułach z mojego bloga
0% SPAMu, 100% informacji! Krótko i na temat.
Programmer-girl Weronika Mularczyk 
Z drugiej strony z perspektywy pracownika bardzo korzystnie jest być niezastąpionym. To bardzo opłacalne finansowo oraz czyni pracę niezwykle „lajtową”, polecam! O kimś takim mówi się wtedy „szaman wiedzy”, bo tylko Ty wiesz co robisz, a reszta patrzy na to jak na magię i jedyne co może zrobić to kiwać potakująco głową gdy coś mówisz.
PolubieniePolubienie
Z perspektywy pracownika to oczywiście może być fajne w pewnym sensie. Ale czy zawsze? Nawet wtedy gdy coś się sypnie w weekend i tylko Ty to umiesz naprawić (a zależy na czasie)? I czy zawsze wiesz, jak naprawić problem?
A z perspektywy firmy i innych pracowników jest to trochę mniej fajnie – bo jak zabraknie tej jednej osoby (obojętnie czy z powodu choroby, urlopu czy nawet zmiany pracy), to niestety straty mogą być spore.
PolubieniePolubione przez 1 osoba
Heh to prawda : ).
Ja, jeszcze na poprzednich studiach, załapałem się do pracy kompletnie nie związany z moim wykształceniem, czyli zarządzaniem właśnie, zamiast tego za całkiem niezłą kasę zostałem hardware’owcem. Firma była naprawdę malutka więc byłem jedynym pracownikiem zajmującym się tą dziedziną.
Rzeczywiście to było trochę stresujące, kiedy pojawiały się problemy, ale jednocześnie dawało boosta do samorozwoju i motywację do nauki. Bo mogłem liczyć tylko i wyłącznie na siebie, jako że reszta pracowników panikowała przy konieczności samodzielnej instalacji oprogramowania do drukarki ; p. Praca przy rozwiązywaniu problemów jest super! : D
PS: To mnie właśnie przekonało, że IT może być fajne, że może warto spróbować informatyki inżynierskiej i zostać programista.
PolubieniePolubienie
Pingback: Skąd brać pomysły na posty? – programmer-girl