Mentalność Gholuma. Wskaźnik Bus Factor – #1.

M

Mentalność Gholuma

Pracując w branży IT, na pewno spotkaliście się z terminem Bus Factor. Jeśli nie, to pokrótce, jest to termin określający wartość ryzyka utraty kluczowych informacji w zespole, w zależności od tego ilu członków zespołu musi zabraknąć, żeby te informacje utracić.

Wedle wikipedi wzkaźnik ten może przyjmować różne nazwy…

Bus Factor – Wikipedia

bread truck scenariolottery factortruck factor, bus/truck number, or lorry factor

Przykładowo, jeśli w Twoim 10-cio osobowym zespole, 2 osoby znają się na infrastrukturze sieci to wskaźnik bus factor dla tego rodzaju umiejętności/wiedzy wynosi 2. Im niższy wskaźnik tym gorzej.

Inny przykład. Jeśli masz w zespole 4 osoby zajmujące się frontendem w tym samym projekcie, to wskaźnik bus factor wynosi 4. Dlatego jeśli stracisz jedną z tych osób, np. nagle ucieknie z kochanką/kochankiem za granicę (nie pytajcie), nic takiego strasznego się nie stanie, bo zostają jeszcze 3 osoby.

Natomiast jeśli masz w tym samym projekcie jedną osobę zajmującą się bazami danych i tylko ten człowiek posiada wiedzę nt. tych rozwiązań dla tego projektu, wskaźnik bus factor wynosi 1.

To jest sytuacja potencjalnie groźna. Co jeśli ten człowiek ucieknie z w/w parą?

Chodzi o wyznaczenie najmniejszej możliwej liczby osób które, jeśli „znikną” z projektu, spowodują jego zatrzymanie.

Temat ten był omawiany nie raz i nie dwa.

Przy czym, chcę go poruszyć trochę z innej strony, niż zwykle się to robi. Można powiedzieć, że zaglądam pod kamień.

…a tam robaki?

W tym poście skupię się na, jak to sobie określam, mentalności tytułowego Gholuma, który zagarnia powykręcanymi pazurami każdy skarb (kodzik), każdą błyskotkę (serwisik), wszystko co godne uwagi całej drużyny pierścienia (dev-teamu).

Nie dość, że zagarnia to wszystko dla siebie, to jeszcze nie chce się tym dzielić.

Owszem, wrzuca kodzik do repo. Pracuje szybko i wytrwale, pracuje mądrze i dobrze. Problem jednak jest taki, że to Gholum samolub.

Żartów dość

Temat jest poważny, zwłaszcza u nas, w kraju gdzie branża IT jeszcze dojrzewa, jeszcze się klaruje, w związku z czym pewne zachowania i pewne standardy dopiero się kształtują.

Niektórzy z Was na pewno znają/widzieli sytuację, jak któryś ze współpracowników…nie wiem jak to nazwać…”ukrywa kod” do ostatniego momentu przed wbitką do repo. Wrzuca kod i usilnie stara się nie dzielić wiedzą nt. rozwiązania które właśnie dodaje do „wspólnej puli”.

To niekoniecznie wynika z charakteru danej osoby. Taki współpracownik niekoniecznie musi być, wcześniej wspomnianym, Gholumem.

Ten człowiekiem może po prostu robi swoje, ale pracujecie w miejscu gdzie nie ma określonych standardów dotyczących dzielenia się wiedzą, dokumentowania wiedzy i „myśli”.

Każda sytuacja, gdzie jakiś członek zespołu nie dzieli się swoją wiedzą z resztą zespołu, z takich czy innych przyczyn, jest potencjalnie groźna.

Każdy przypadek gdzie zespół nie ma wypracowanych technik ograniczających wskaźnik bus factor, jest potencjalnie groźny.

…legendy i plemienne przekazy.

Abstrahuję już od przypadków kiedy pracownik znika z powierzchni Ziemii nagle, ale jeśli zmieni pracę? Ile tej wiedzy będzie mógł przekazać podczas okresu wypowiedzenia?

Przykładowo, ile Ty programisto nauczysz się nt. środowisk i konfiguracji na firmowym Azure, jesli za miesiąc odchodzi Wasz DevOps? Ile z tego nauczy się nowy DevOps, jeśli wiedza będzie przekazana w formie plemiennego przekazu ustnego?

Dobrze, że możemy się częściowo wzorować na zachodzie, gdzie branża IT, będąc bardziej dojrzałą, ma już wypracowane techniki i zachowania.

STOP – Chwila na refleksję

Drogi czytelniku. Dzisiaj daję Ci tylko do myślenia. Tym samym rozpoczynam krótki cykl nt. technik zmniejszania ryzyka (zwiększania wartości wskaźnika buz factor) utraty wiedzy czy umiejętności w projekcie, w wyniku nieprzewidzianych roszad w zespole.

Jak to wygląda u Ciebie? Jak w organizacji dla której pracujesz? Jakieś niestandardowe techniki? Napisz w komentarzach.

Ponadto, jeśli interesuj cie tzw. „tematy miekkie”, mam do zaoferowania kilka:



Photo by Dylan Collette on Unsplash

About the author

Add comment

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi