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…
…bread truck scenario, lottery factor, truck 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:
- Boiling Frogs. Wrazenia.
- Recesja a Twoj stolek
- Oderwanie od rzeczywistości, romantyczny kod i dramat programisty.
Photo by Dylan Collette on Unsplash
