Bus factor, czyli co wspólnego ma przechodzenie przez ulicę z płynnością projektu IT?

Cześć, dzień dobry. Witam was w podcascie IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce. Podcast IT i Biznes kieruję do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek piąty Bas Faktor. Jak zadbać o ciągłość realizacji projektu IT? Z tego odcinka dowiesz się, czym jest pojęcie Bas Faktor, jakie ryzyka za sobą niesie i przede wszystkim, jak owe ryzyka zminimalizować lub nawet wyeliminować.

Jeśli realizujesz lub planujesz zrealizować ważny dla twojej firmy projekt IT, z pewnością powinieneś lub powinnaś posłuchać dzisiejszego odcinka. Także serdecznie zapraszam. Cześć, dzień dobry.

Witam serdecznie raz jeszcze w odcinku numer pięć. Na wstępie chciałbym podziękować wszystkim słuchaczom za dotychczas przekazane uwagi. Działam nad tym, aby każdy kolejny odcinek był lepszy od poprzednich, zarówno pod względem merytorycznym, jak i technicznym.

Także wszelka informacja zwrotna mile widziana i raz jeszcze bardzo za nią dziękuję. Dzisiaj opowiem o pojęciu Bas Faktor, czyli tak zwanym przypadku autobusowym, które jest popularne w projektach IT, ale według mnie jest to zjawisko, które często pojawia się także w innych sferach biznesu, czy to w marketingu, czy w sprzedaży, czy w rekrutacji. Także trafiamy tutaj na taki wyjątkowy obszar, który szczególnie łączy IT i biznes.

Zacznijmy od krótkiej historii, która wprowadzi nas w temat dzisiejszego odcinka. Wyobraźmy sobie Asię. Asia prowadzi duży e-commerce i współpracuje z programistami, ale także administratorem serwerów, co ważne jednym administratorem serwerów, który nazywa się Janek.

Janek odpowiada za wszelkie kwestie związane z serwerami i jest jedyną osobą, która nimi zarządza i ma do nich pełny dostęp. Pewnego słonecznego dnia Janek idzie sobie spokojnie chodnikiem, słucha ulubionej muzyki na słuchawkach i postanawia przejść na drugą stronę jezdni, tak dość nieoczekiwanie. Pech sprawia, że wchodzi na tę jezdnię nie oglądając się wcześniej za siebie i jak być może już się domyślasz, zostaje potrącony przez jadący autobus.

Stąd właśnie nazwa przypadku autobusowego. Idąc dalej, przyjmijmy na potrzeby tej historii, że Janek trafia do szpitala i staje się tymczasowo w 100% niedostępny. Czyli nie ma komputera, nie ma dostępu do internetu.

Powiedzmy, że nic się super dużego nie stało przez to, że ten autobus się pojawił, natomiast nadal Janek jest po prostu niedostępny. Kilka godzin po wypadku serwer odnotowuje duże obciążenie i nagle system przestaje działać. Pojawia się jakaś biała strona, jakieś piętsetki, jakieś inne takie błędy, które dla użytkownika nic nie mówią, a programiści w kilka sekund znajdują przyczynę.

Natomiast z reguły w tego typu sytuacji wystarczyło krótkie zgłoszenie do Janka typu, cześć Janek, znowu nasz e-commerce nie działa. No i on realizował jakąś magię na serwerze, coś tam restartował, coś tam zmieniał i to powodowało, że ten e-commerce wracał szybko do życia, tak tymczasowo. Ale tym razem Janek jest niedostępny.

No i nasza bohaterka Asia zostaje w tym momencie z telefonami od klientów, którzy informują o awarii, którzy chcieli dokonywać zakupów przez to, że ich nie dokonują, to sklep zaczyna generować straty. No i Asia zostaje z myślą, co tu teraz zrobić. I teraz, co można byłoby zrobić, aby takiej sytuacji zapobiec? Oczywiście, Janek mógł dać te dostępy do serwera komuś innemu, no ale pracował, była rutyna i on po prostu zawsze był dostępny, więc do tej pory nie było tego typu sytuacji i takiej potrzeby.

Po drugie, ta osoba, której przekazałby te dostępy, to niekoniecznie musiała mieć też umiejętności związane z obsługą serwerów, no bo tutaj też wspomnieliśmy na początku historii, że Janek był jedyną osobą, która rzeczywiście dostęp i wiedzę na temat zarządzania serwerami miała. I teraz z tej konkretnej sytuacji, ja bym się skupił na początek na tych dostępach do serwerów, tak, żeby one były przekazywane minimum dwóm osobom. I wiem, że dla niektórych z Was może to się wydawać oczywiste, ale naprawdę widziałem już sytuację i to niestety niejednokrotnie, kiedy pojawiali się u nas nowi potencjalni klienci już z jakąś awarią i nie mający dostępów do serwera, no bo właśnie było to dla nich tak oczywiste i tak bezobsługowe do tej pory, bezobsługowe w tym znaczeniu, że była po prostu osoba, która się tym zajmowała, no że po prostu o tym kompletnie nie myśleli.

I teraz w tej konkretnej historii można by przyjąć, że ten współczynnik ryzyka Bas Factor wynosił 1, ponieważ od jednej konkretnej osoby był zależny ten dany obszar, w tym wypadku zarządzania serwerami. Czasem zdarza się też, że taki konkretny obszar jako całość jest trudny do przekazania, no bo ktoś niekoniecznie musi się znać na tym, żeby obsługiwać na przykład właśnie serwery, ktoś inny w zespole. Natomiast jest taka możliwość, że jeżeli pojawiała się awaria, która co jakiś czas występowała i mieliśmy jakieś tymczasowe rozwiązanie na to, żeby tą awarię wyeliminować, to chociaż tym tymczasowym rozwiązaniem warto byłoby się w zespole podzielić i myślę, że to jest taki drugi przypadek, taka druga część, którą można by z tej historii wyciągnąć, aby no właśnie takimi nawet jednostkowymi mikro procesami typu pojawia się awaria, że nagle coś przestaje działać i administrator serwerów coś restartuje, coś robi na serwerze, to chociaż tą konkretną informację pokazać czy przekazać zespołowi, tak aby chociaż ten jeden konkretny obszar, wiedząc, że te awarie co jakiś czas występują, był zaopiekowany również przez kogoś innego.

Czyli opowiedzieliśmy sobie o tym, że bus factor był tutaj na poziomie 1, no bo od jednej osoby był zależny ten dany proces i że ryzyko było z jednej strony w miejscu uprawnień do serwera, a z drugiej strony w kwestii umiejętności administrowania serwerami. Natomiast oczywiście buzz factor to nie jest tylko kwestia przekazywania dostępów czy tylko kwestia związana z serwerami, tylko jest to ocena ryzyka danego procesu w skali od 1 do ilości osób jaka jest w zespole, czyli na zasadzie co się stanie, jeśli ta dana osoba lub te dane osoby nie będą dłużej dostępne. I przez to właśnie ja na buzz factor patrzę nie tylko przez pryzmat tych ryzyk takich, nie wiem, ludzkich, przypadków losowych dotyczących ludzi, ale także przez pryzmat rzeczy, które ci ludzie realizują, czyli tych konkretnych procesów, obszarów, którymi się zajmują i o takich właśnie zjawiskach, tak bym chyba to nazwał, czy takich właśnie obszarach, gdzie ci ludzie coś realizują i gdzie coś może pójść nie tak, i gdzie ten buzz factor też de facto występuje, choć nie dotyczy bezpośrednio człowieka, opowiem za chwilkę, bo myślę, że też warto na takie aspekty przy okazji tego pojęcia zwrócić uwagę.

Weźmy tutaj na tapet najpierw obszar IT i najczęściej spotykane miejsca, gdzie występuje bus factor. Pierwszym takim miejscem jest pisanie kodu przez programistów i pisanie go na jednej maszynie bez kopii tego kodu wrzucanej na zewnątrz. Czyli teraz standardowo programista, który pisze swój kod, powinien go na bieżąco wrzucać na tak zwane repozytorium, czyli na zewnętrzne źródło, gdzie ten kod powinien się znajdować i być właśnie uruchamiany przez wszystkich, czy wrzucany przez wszystkich programistów.

Teraz to repozytorium oczywiście też powinno mieć kopie zapasowe, natomiast kluczowy jest ten aspekt, że jeżeli programista produkuje czy pisze swój kod na swoim sprzęcie, to mamy tutaj buzz factor związany właśnie z tym sprzętem, że w momencie, kiedy ten sprzęt ulegnie awarii, no to mimo, że programista jest dostępny, kodu nie mamy i jakiejś ważnej funkcjonalności wypuścić nie możemy. Czyli w tym wypadku właśnie ten bus factor moim zdaniem występuje w kontekście sprzętu i tego, że jeżeli w jednym konkretnym miejscu trzymamy kod, a nie w dwóch, no to to jest właśnie ryzyko, z którym musimy sobie poradzić i z którego zdawać sprawę sobie powinniśmy. Warto taki proces wdrożyć, że programista na bieżąco, jak zapisuje zmiany związane z kodem, to po prostu wypycha je, w cudzysłowie, od angielskiego push na repozytorium i na bieżąco ten kod tam się backupuje.

Możemy też spojrzeć na to przez pryzmat grupy testerów. To znaczy często jest w projektach tak, że jak już jest w zespole tester, to ten tester wykonuje swoje właśnie różne testy, weryfikacje różnych funkcjonalności w taki sposób, w jaki jakiś sobie wypracował, ale niekoniecznie ma te swoje właśnie metody, sposoby gdzieś zapisane, czy jakieś checklisty opracowane, tylko sprawdza według swojego po prostu podejścia. Teraz warto ustalić i zapisać zasady przeprowadzania testów, aby w razie nieobecności tego głównego testera móc łatwo wdrożyć nową osobę właśnie w ten obszar testów.

W idealnym świecie dowolną osobę, która wejdzie i na podstawie gotowej instrukcji zacznie te testy przeprowadzać, ale w takim racjonalnym świecie po prostu osobę, która faktycznie na testach się zna, ale która też będzie wiedziała, co dokładnie w danym systemie należałoby sprawdzić. Jeszcze jednym miejscem, gdzie ten Bus Factor moim zdaniem bardzo często występuje w projektach, to jest proces uruchamiania zmian na głównych tak zwanych produkcyjnych serwerach, gdzie ten proces powinien być wykonywany standardowo przez kilka osób, to znaczy wykonywany przez jedną, ale czy to dowolną osobę z zespołu czy po prostu jedną z kilku osób, które mają uprawnienia do tego, żeby takie uruchomienie zmian na tej tak zwanej produkcji wykonać. Teraz tutaj też jest często tak, że jakaś jedna konkretna osoba takim procesem uruchomienia zmian się zajmuje.

W momencie, kiedy tej osoby nie ma, nagle zmian nie da się uruchomić albo ludzie nie do końca wiedzą jak można byłoby to zrobić. No i dlatego bardzo ważne jest, żeby ten proces też sobie krótko spisać i sprawdzić czy inne osoby też oprócz tej głównej osoby realizującej ten proces uruchomienia zmian faktycznie są w stanie go zrealizować. Możemy także przejść do sfery bezpośrednio biznesowej i tych obszarów poza IT, w których też dostrzegam Bus Factor.

Jednym z takich obszarów jest np. proces sprzedaży, gdzie zdarza się, że np. w firmie tylko jedna osoba zaangażowana jest w proces odbioru i akceptacji oferty zanim wyjdzie ona do klienta.

No i to jest taki myślę klasyczny Bus Factor, no bo w przypadku kiedy tej osoby zabraknie oferty przestają wychodzić. Drugi taki proces to realizacja procesów HR-owych przez jedną osobę w firmie czy samej rekrutacji czy po prostu procesów HR-owych. No i tutaj myślę, że warto z perspektywy rozwiązań technologicznych pomyśleć nad rozwiązaniem typu ATS, które może pomóc w przejęciu obowiązków takiej osoby, jeżeli pojawią się one nagle do przejęcia.

No i trzeci taki obszar, który wybrałem to jest realizowanie księgowości firmy tylko przez jednego stałego księgowego i wymiana informacji tylko z nim. No i oczywiście ktoś nowy wchodząc w obszar księgowości może sobie przejrzeć wszystkie wcześniejsze zapisy, natomiast jest to z reguły też czasochłonne i czasem są też jakieś ustalenia, których się nie zapisało czy o coś się dopytało księgowego no i warto to po prostu też zapisać. Należy pamiętać o tym, że na pewnych etapach rozwoju firmy, szczególnie kiedy jakiś proces dopiero się klaruje, to ryzyko Bus Factora jest niestety nieuniknione i jest też w 100% normalne.

Także ja bym też nie panikował, że ojejku ile teraz widzimy Bus Factorów po tym jak przesłuchaliśmy ten odcinek, tylko bardziej skupił się na tym jak można do tego podejść, żeby to ryzyko po prostu czy to wyeliminować czy po prostu postarać się zmniejszyć. Przejdźmy zatem do możliwych rozwiązań. Na początek jak łatwo sprawdzić kto z Twojego zespołu jest podatny na przypadek autobusowy, czy może bardziej jakie procesy są podatne na ten przypadek autobusowy.

No i to co ja bym zrobił to przygotował listę osób z Twojego zespołu wraz z listą głównych zadań każdej z tych osób. Następnie te główne zadania spisałbym na drugiej liście nie dublując ich, czyli jeżeli kilka osób ma to samo zadanie zapisujemy sobie je jako jedno, ale obok tego zadania wpisujemy właśnie tą ilość osób, która dane zadanie może realizować. Czyli na przykład jeżeli ktoś programuje jakiś określony obszar i w tym obszarze wiemy, że działały trzy osoby no to przy tym programowaniu tego konkretnego obszaru wpisujemy na przykład trójeczkę.

Jeżeli wiemy, że administracją serwerami zajmują się u nas dwie osoby to piszemy obok procesu administracji serwerami dwójeczkę, a jeżeli są procesy, które są wykonywane tylko przez jedną osobę to piszemy sobie jedynkę. I teraz tam gdzie mamy jedynki to od tych zadań bym zaczął. I teraz jak już mamy te zadania wypisane to zastanówmy się czy do tych zadań jest przygotowana jakaś instrukcja, czy jakaś checklista do wykonania tego zadania.

Jeżeli nie no to to jest pierwsza rzecz, którą trzeba będzie nadrobić z tą osobą, która obecnie to zadanie realizuje. Drugi obszar to czy do wykonania tego zadania potrzebne są właśnie jakieś uprawnienia, jakieś dostępy, jakieś wejście gdzieś. Jeżeli tak to to też należałoby gdzieś zapisać tak, żeby był do tego po prostu dostęp.

I tak naprawdę największy problem to będzie teraz z tym, żeby ta osoba, która ten konkretny obszar zajmuje to spisała, no bo trzeba do tego usiąść, trzeba to jakoś spisać. Jeżeli to jest jakieś zadanie, które wymaga pracy przy komputerze i można by na przykład nagrać ekran to myślę, że taką instrukcją ad hoc którą można zrobić to jest właśnie przekazanie tej konkretnej rzeczy w formie wideo, czyli nagranie po prostu ekranu. Natomiast jeżeli to jest też coś, co się wykonuje poza komputerem albo trudno to pokazać na nagraniu ekranu to można też po prostu włączyć dyktafon i ktoś kto wykonuje ten dany proces to po prostu o nim opowiada co robi i to też jest jakaś forma tego aby w razie w komuś przekazać po prostu ten dany obszar czy to dane zadanie.

Myślę, że Asia z opowieści na początku tego odcinka z pewnością po przesłuchaniu tej części pomyślałaby czy ktoś jeszcze ma dostęp do serwera z jej głównym projektem i czy ktoś jeszcze jest w stanie reagować na ewentualne awarie, które się pojawiają. Z uwagi na to, że zbliżamy się do końca dzisiejszego odcinka czas na krótkie podsumowanie. Po pierwsze bus factor to ryzyko związane z tym, że kogoś lub czegoś nagle zabraknie.

Po drugie mierzymy to ryzyko w formie ilości osób jakie mogą wykonać daną rzecz. Im większa ta ilość będzie przy danej rzeczy tym ryzyko jest mniejsze. Warto zapisywać nawet krótkie instrukcje jak sobie poradzić w danej sytuacji aby mogła reagować na nie więcej niż jedna osoba.

Pół żartem, pół serio sprawdźcie czy macie dostęp do swoich serwerów bezpiecznie zapisane. Na koniec pamiętaj o najważniejszym pytaniu. Co się stanie jeśli Janek bądź inna ważna osoba w twoim zespole nie będzie dostępny przez 3 tygodnie? Lepiej zadać to pytanie w warunkach kontrolowanych kiedy owy Janek jest dostępny.

I to już koniec dzisiejszego odcinka. Bardzo dziękuję za jego wysłuchanie. Jako, że dotarłeś lub dotarłaś aż do końca zdradzę, że następny odcinek będzie mówił o tym co w IT zdarza się niestety bardzo często.

To znaczy co zrobić z projektem IT, który wiecznie się opóźnia. Także w kolejnym odcinku porozmawiamy o tym skąd te opóźnienia wynikają i przede wszystkim jak sobie z nimi radzić. Raz jeszcze dziękuję serdecznie za wysłuchanie dzisiejszego odcinka.

Do usłyszenia w następny wtorek. Cześć.