Czym jest bus factor?

Bus factor to jedno z najważniejszych pojęć związanych z długiem technicznym, systemami legacy i ogólną kondycją projektu. Im jest niższy, tym gorzej. Dlatego w tym artykule wyjaśniamy, czym jest, dlaczego spada i jak go podnieść.

Dowiedz się więcej, jak zdiagnozować swój projekt. Koniecznie pobierz nasz e-book „Czy Twój projekt płonie? Autodiagnoza”:

Czym jest bus factor?

Bus factor (znany też jako truck factor) to wskaźnik ryzyka dla zespołu/projektu: oznacza minimalną liczbę osób, które musiałyby nagle stać się niedostępne (np. odejść z pracy, zachorować, zostać przeniesione do innego projektu — obrazowo: „wpaść pod autobus”), żeby projektu nie dało się dalej utrzymywać albo dowieźć.

Bus factor = 1 → bardzo duże ryzyko: jedna kluczowa osoba trzyma krytyczną wiedzę i/lub dostępy.
Im wyższy bus factor → tym większa odporność: wiedza, odpowiedzialność i dostępy są rozłożone na kilka osób.

Skąd się bierze bus factor?

Bus factor bierze się stąd, że w projektach wiedza, dostępy i odpowiedzialność „same z siebie” lubią zbijać się w jedno miejsce — chyba że świadomie temu przeciwdziałasz. Gdy pojawia się presja czasu, najłatwiejsza droga to ta na skróty: „niech zrobi to osoba, która już to zna”. To działa szybko tu i teraz, ale utrwala specjalizację i sprawia, że jedna osoba staje się domyślnym wyborem do coraz większej liczby tematów.

Do tego dochodzi efekt pierwszego autora: ktoś, kto postawił dany system albo moduł, zna historię decyzji, kontekst i wszystkie obejścia, więc naturalnie przejmuje rolę opiekuna. Z czasem w jego głowie gromadzi się wiedza, której nie widać w kodzie ani w dokumentacji — mentalne mapy, „haczyki”, powody, dla których coś jest zrobione akurat tak, oraz intuicja w diagnozowaniu problemów. To jest wiedza ukryta, której nie da się łatwo przekazać w biegu.

Równolegle często powstają wąskie gardła w dostępie: klucze do produkcji, uprawnienia administracyjne, kontakty do vendorów czy prawa do wdrożeń zostają u jednej osoby „dla bezpieczeństwa” albo po prostu z rozpędu. Dokumentacja zwykle nie nadąża za tempem zmian, więc dług dokumentacyjny rośnie, a wejście w temat wymaga coraz większego kontekstu. Jeśli organizacja dodatkowo wzmacnia to strukturą ról — pojedynczym „ownerem”, silosami albo samotnym specjalistą od DevOps, danych czy CRM — ryzyko robi się systemowe.

Na koniec wchodzi czynnik ludzki: wiele firm nagradza „bohaterów”, którzy zawsze ratują sytuację, co niechcący zniechęca do dzielenia się wiedzą i delegowania. A gdy dochodzi rotacja ludzi między projektami, osoba, która zostaje najdłużej, staje się kotwicą wiedzy — i w praktyce jedynym punktem awarii. W efekcie bus factor nie jest wyjątkiem, tylko naturalnym skutkiem ubocznym optymalizacji na szybkość, jeśli nie budujesz redundancji celowo.

Jak sprawdzić czy bus factor w twoim produkcie jest niski?

Nie jest tak, że „masz albo nie masz” bus factor — on zawsze istnieje. Pytanie brzmi tylko: czy jest niebezpiecznie niski. I da się to sprawdzić całkiem praktycznie.

Zacznij od prostego pytania: „Jeśli X wypada na 2 tygodnie, co staje?” Jeśli potrafisz od razu wskazać konkretną osobę i rozpisać łańcuch zależności („bo tylko ona ma dostęp”, „bo tylko ona zna integrację”, „bo tylko ona robi release’y”), to ten obszar ma bus factor w okolicach 1.

Potem zrób test dostępu: kto może wdrożyć, zatwierdzić, wejść na produkcję, zarządzać CRM/reklamami, odnowić umowy z vendorami? Jeżeli odpowiedź brzmi „jedna osoba”, to dla tej zdolności bus factor też wynosi około 1 — niezależnie od tego, ile osób „teoretycznie” jest w zespole.

Kolejny krok to test zmiany: kto potrafi bezpiecznie modyfikować ten system bez pytania kogokolwiek o zgodę, kontekst albo „jak to działa”? Jeśli tylko jedna osoba czuje się na tyle pewnie, żeby zrobić zmianę end-to-end, to bus factor jest niski, bo reszta jest w praktyce zablokowana.

Bardzo trzeźwiący bywa test incydentu: spójrz na ostatnie 3 awarie albo eskalacje i sprawdź, kto je finalnie dowiózł. Jeśli to ta sama osoba, masz koncentrację wiedzy i odpowiedzialności — i ryzyko, które rośnie z każdym kolejnym „ratowaniem sytuacji”.

Na koniec test urlopu: czy tempo realnie spada, gdy konkretne osoby są na wakacjach? Jeśli tak, to masz single point of failure — miejsca, gdzie bus factor jest za niski, żeby projekt był odporny.

Jak obliczyć bus factor?

Bus factor „liczysz”, tłumacząc definicję na coś, co da się policzyć:

Bus factor = minimalna liczba osób, które muszą wypaść, żeby projekt stanął.

W praktyce najczyściej działa podejście operacyjne: potraktuj projekt jako zestaw kluczowych obszarów kompetencji/zdolności i policz, ile osób potrafi każdy z nich ogarnąć end-to-end.

Najpierw wypisz krytyczne obszary techniczne i biznesowe (np. wdrożenia/release, reakcja na incydenty, billing i rozliczenia, kluczowe integracje, raportowanie, wiedza o krytycznym kliencie, itp.). Potem zrób macierz kompetencji ze skalą 1–4 (1 = nie zna, 4 = ekspert).

Dla każdego obszaru policz coverage = liczba osób z oceną 3–4, czyli takich, które są w stanie dowieźć temat samodzielnie, bez prowadzenia za rękę. To dokładnie odpowiada testowi „red zone” z e-booka: red zone to sytuacja, w której w danym obszarze tylko jedna osoba ma poziom 3–4.

Operacyjnie bus factor projektu to po prostu najmniejsze pokrycie wśród obszarów krytycznych:

bus_factor ≈ min_area( liczba osób z poziomem 3–4 w obszarze )

Czyli jeśli wdrożenia mają 2 osoby „samodzielne”, raportowanie 3, ale kluczowa integracja tylko 1, to cały projekt ma bus factor w okolicach 1 — bo nadal istnieje pojedynczy punkt, który potrafi unieruchomić dowożenie.

Jak policzyć bus factor – przykład

Zespół (przykład) i skala ocen

Zespół:

• Ania (backend)
• Bartek (DevOps)
• Kasia (data)
• Tomek (frontend)
• Ewa (PM / ops)

Skala 1–4:

• 1 = brak praktycznej wiedzy
• 2 = pomoże z prowadzeniem / instrukcją
• 3 = zrobi samodzielnie
• 4 = ekspert / potrafi uczyć

Krok 1: Zdefiniuj „obszary” (capabilities)

Wybierz rzeczy, które jeśli nikt nie umie ich zrobić, projekt realnie staje.

Przykładowe obszary:

1. Wdrożenie na produkcję i rollback
2. Płatności i billing (Stripe)
3. Kluczowe API (order service)
4. Pipeline danych i raportowanie
5. Release frontendu i feature flags
6. Reakcja na incydenty / runbooki on-call
7. Onboarding kluczowych klientów

Krok 2: Macierz umiejętności (skala 1–4)

(3–4 = „zrobi samodzielnie”)

Krok 3: Policz „coverage” na obszar (≥3)

Definicja: coverage(obszar) = liczba osób z oceną ≥ 3 (czyli dowiozą samodzielnie).

• Deploy → Bartek = 1
• Payments → Ania = 1
• Core API → Ania = 1
• Data pipeline → Kasia = 1
• Frontend release → Tomek = 1
• Incident response → Bartek = 1
• Onboarding → Ewa = 1

Krok 4: Wylicz bus factor

Bus factor projektu ≈ minimum coverage spośród obszarów krytycznych.

Tutaj najniższe coverage = 1, więc:

✅ Bus factor = 1
Czyli projekt ma dużo single pointów of failure — w każdym krytycznym obszarze jest tylko jedna osoba, która „dowiezie bez prowadzenia za rękę”.

Co zrobić z bus factorem?

Proponujemy konkretny, powtarzalny proces:

Najpierw policz bus factor tak, jak wyżej.

Potem:

1. Przypisz 1–2 osoby „backup” do każdej czerwonej strefy (red zone)

„Czerwona strefa” to każdy ważny obszar, w którym tylko jedna osoba potrafi ogarnąć temat dobrze (poziom 3–4 w macierzy).

Prosty przykład:
„Miesięczny raport dla klienta” → tylko Kasia wie, jak to zrobić → red zone.
Wybierz backupy: Ewa (Backup A) + Ania (Backup B).

Jak to zrobić w 20 minut:

• Zrób listę kluczowych obszarów (10–20).
• Przy każdym dopisz:
  • Owner (rockstar) = osoba, która teraz zawsze to robi
  • Backup A + Backup B = osoby, które nauczą się tego jako następne
• I tyle. Właśnie zamieniasz „wiedzę plemienną” w konkretny plan.

2. Mini playbooki (krótkie notatki „jak to działa”)

Następnie „rockstar” spisuje najważniejsze „jak to działa” w krótkim, praktycznym formacie.

Powinna to być maksymalnie jedna strona. Dobry mini playbook odpowiada na:

• Po co to jest?
• Gdzie wchodzę / co otwieram?
• Checklistę krok po kroku
• Typowe błędy + jak je naprawić
• Gdzie są hasła/dostępy (albo kto je nadaje)

Przykład: Kasia pisze „Miesięczny raport dla klienta – mini playbook”:

• link do arkusza / dashboardu
• „kliknij tu, wyeksportuj to, wklej tutaj”
• „przed wysyłką sprawdź 3 liczby”
• „jeśli liczby wyglądają źle: zrób 2 szybkie kontrole”

3. Rotuj odpowiedzialność

Chodzi o to, żeby zadanie wykonała osoba inna niż „rockstar” — w realnych warunkach, na prawdziwym przykładzie.

Jak zrobić rotację bez chaosu:

• Wybierz jedno nadchodzące, prawdziwe zadanie z czerwonej strefy.
• Przypisz je Backup A jako osobie, która ma je dowieźć („doer”).
• Rola rockstara jest tylko taka, żeby:
  • być dostępny/a,
  • zrobić szybki review wyniku,
  • odpowiadać na pytania.

Przykład:
Następny miesięczny raport:

• Ewa przygotowuje i wysyła raport.
• Kasia patrzy i robi review, ale nie przejmuje zadania.

4. Sprawdzaj co 4–6 tygodni (czy jesteśmy mniej zależni?)

Regularnie aktualizuj obraz sytuacji: co 4–6 tygodni sprawdź, czy bus factor rośnie, czy dalej stoi na 1.

Jak to zrobić w ok. 30 minut:

• Wróć do listy czerwonych stref.
• Dla każdego obszaru zapytaj: „Czy jest już przynajmniej jeden backup, który umie dowieźć to end-to-end?”
  • Jeśli tak → czerwona strefa jest „zamknięta” (albo przynajmniej wyraźnie poprawiona).
  • Jeśli nie → zaplanuj kolejną rotację i zaktualizuj mini playbook.

Prosty wynik:

• Czerwone strefy łącznie: 8
• Czerwone strefy z backupem, który umie to zrobić: 3
• Cel na przyszły miesiąc: 5

Podsumowanie

Im wyższy bus factor, tym lepiej dla Twojego projektu. Mamy nadzieję, że ten artykuł pomoże Ci go rozpoznać i utrzymywać na bezpiecznym, wysokim poziomie.

Co dalej?

Jeśli chcesz jeszcze dokładniej zdiagnozować kondycję projektu, zajrzyj do e-booka o autodiagnozie projektu.

A jeśli nadal potrzebujesz wsparcia, odezwij się do nas i poproś o audyt projektu — chętnie pomożemy.

FAQ Bus factor