5 Whys: Nájdi skutočnú príčinu
Keď sa niečo pokazí, je ľahké vyriešiť symptóm a ísť ďalej. Ale ak neriešiš skutočnú príčinu, problém sa vráti. 5 Whys je jednoduchá, ale mocná technika na nájdenie root cause.
Pôvod: Toyota Production System
Sakichi Toyoda, zakladateľ Toyota, vyvinul metódu 5 Whys ako súčasť Toyota Production System. Taiichi Ohno, architekt TPS, ju opísal:
"Opakovaným kladením otázky 'prečo?' päťkrát sa povaha problému a jeho riešenie stanú jasnými."
Dnes ju používajú nielen výrobné firmy, ale aj Lean Startup metodológia (Eric Ries) a tech firmy ako Amazon a Buffer.
Ako funguje 5 Whys
Základný princíp
- Definuj problém
- Opýtaj sa "Prečo?"
- Na odpoveď sa opýtaj znova "Prečo?"
- Opakuj 5× (alebo kým sa nedostaneš k root cause)
- Identifikuj a implementuj riešenie
Príklad: Toyota
Problém: Stroj sa zastavil.
| # | Prečo? | Odpoveď |
|---|---|---|
| 1 | Prečo sa stroj zastavil? | Poistka vyhorela kvôli preťaženiu |
| 2 | Prečo bolo preťaženie? | Ložisko nebolo dostatočne premazané |
| 3 | Prečo nebolo premazané? | Pumpa nečerpala dosť oleja |
| 4 | Prečo pumpa nečerpala? | Bola upchatá kovovými pilinami |
| 5 | Prečo bola upchatá? | Na pumpe nebol filter |
Root cause: Chýbajúci filter. Riešenie: Pridať filter na pumpu.
Keby sme len vymenili poistku (symptóm), problém by sa vrátil.
5 Whys pre startupy
Príklad: Startup - Nízka konverzia
Problém: Len 2% návštevníkov sa zaregistruje.
| # | Prečo? | Odpoveď |
|---|---|---|
| 1 | Prečo sa nezaregistrujú? | Opúšťajú stránku pred formulárom |
| 2 | Prečo opúšťajú? | Trvá im príliš dlho nájsť hodnotu |
| 3 | Prečo trvá dlho? | Landing page vysvetľuje funkcie, nie problém |
| 4 | Prečo vysvetľuje funkcie? | Kopírovali sme konkurenciu |
| 5 | Prečo kopírovali? | Nemáme jasný positioning |
Root cause: Nejasný positioning. Riešenie: Prepísať positioning a landing page na problém, nie funkcie.
Príklad: Customer Support
Problém: Veľa support ticketov o rovnakom probléme.
| # | Prečo? | Odpoveď |
|---|---|---|
| 1 | Prečo píšu o tom istom? | Nevedia nájsť export funkciu |
| 2 | Prečo nenájdu? | Je skrytá v nastaveniach |
| 3 | Prečo je skrytá? | Pridali sme ju na poslednú chvíľu |
| 4 | Prečo na poslednú chvíľu? | Nebola v pôvodnom scope |
| 5 | Prečo nebola v scope? | Nerobili sme user research pred vývojom |
Root cause: Chýbajúci user research. Riešenie: Zaviesť user research pred každým feature.
Pravidlá 5 Whys
1. Nikdy nehľadaj vinníka
❌ Zle: "Prečo? Pretože Jano urobil chybu."
✅ Dobre: "Prečo bola chyba možná? Čo v systéme ju umožnilo?"
Human error nie je root cause
Ak tvoja 5 Whys analýza končí pri "ľudskej chybe", nepôjdeš dosť hlboko. Ľudia robia chyby - otázka je, prečo systém umožnil, že chyba mala následky.
2. Opýtaj sa "skutočne prečo?"
Každá odpoveď musí byť overiteľná. Ak je príliš vágna, pokračuj v pýtaní.
❌ Vágne: "Pretože sme neboli dosť opatrní." ✅ Konkrétne: "Pretože nemáme checklist pred deployom."
3. Počet 5 je orientačný
Niekedy stačia 3 "prečo", niekedy potrebuješ 7. Cieľom je actionable root cause - niečo, čo môžeš reálne zmeniť.
4. Zaznamenaj a zdieľaj
5 Whys nie je len mentálne cvičenie. Zaznamenaj analýzu a zdieľaj ju s tímom. To isté platí pre riešenie.
Lean Startup Postmortem
Eric Ries adaptoval 5 Whys pre startupy ako súčasť postmortem procesu po incidentoch:
Kedy robiť postmortem?
- Po výpadku systému
- Po zlyhání feature launchu
- Po strate významného zákazníka
- Po internom konflikte
- Po neúspešnom experimente
Postmortem štruktúra
┌─────────────────────────────────┐
│ POSTMORTEM TEMPLATE │
├─────────────────────────────────┤
│ Incident: [Popis čo sa stalo] │
│ Dátum: [Kedy] │
│ Dopad: [Na koho a ako] │
├─────────────────────────────────┤
│ 5 WHYS ANALÝZA │
│ 1. Prečo? → [odpoveď] │
│ 2. Prečo? → [odpoveď] │
│ 3. Prečo? → [odpoveď] │
│ 4. Prečo? → [odpoveď] │
│ 5. Prečo? → [odpoveď] │
├─────────────────────────────────┤
│ ROOT CAUSE: [Hlavná príčina] │
│ ACTION ITEMS: │
│ □ [Akcia 1] - Zodpovedný: [Kto] │
│ □ [Akcia 2] - Zodpovedný: [Kto] │
└─────────────────────────────────┘
Proportional investment
Eric Ries odporúča: Investuj do riešenia proporcionálne k závažnosti problému. Malý bug = malé riešenie. Výpadok produkcie = systémová zmena.
5 Whys v customer discovery
5 Whys nie je len pre debugging. Je mocný nástroj aj pri customer interviews:
Príklad: Customer Interview
Problém zákazníka: "Potrebujem lepší CRM."
| # | Prečo? | Odpoveď |
|---|---|---|
| 1 | Prečo potrebuješ lepší CRM? | Súčasný je pomalý |
| 2 | Prečo je pomalý problém? | Trvá mi dlho nájsť info o zákazníkovi |
| 3 | Prečo to potrebuješ rýchlo? | Zákazníci volajú a čakajú |
| 4 | Prečo čakajú? | Nemáme rýchle vyhľadávanie |
| 5 | Prečo? | Info je roztrúsené vo viacerých systémoch |
Skutočná potreba: Nie "lepší CRM", ale jednotný pohľad na zákazníka.
Po launchi novej funkcie máte 50 support ticketov denne o rovnakom probléme. Tvoj kolega hovorí: 'Proste napíšeme FAQ article a bude pokoj.' Čo urobíš?
Kedy 5 Whys nestačí
Komplexné problémy
5 Whys predpokladá lineárnu kauzalitu (A→B→C). Pri komplexných systémoch môže byť viac príčin:
┌─────────┐
│Problem A│──┐
└─────────┘ ▼
┌─────────┐ ┌─────────┐
│Problem B│─┤ SYMPTÓM │
└─────────┘ └─────────┘
┌─────────┐ ▲
│Problem C│──┘
└─────────┘
V takých prípadoch použi Fishbone diagram (Ishikawa) alebo Systems thinking.
Keď nemáš dáta
5 Whys potrebuje fakty, nie domnienky. Ak nevieš, prečo niečo nastalo, najprv zozbieraj dáta.
Čo sa môže pokaziť
"Prečo?" → "Pretože sme to zle naprogramovali." STOP.
Toto nie je root cause. Pýtaj sa ďalej: Prečo bolo možné naprogramovať zle? Prečo prešlo cez review? Prečo nemáme testy?
Poučenie: Ak odpoveď je "niekto urobil chybu", pokračuj v pýtaní. Hľadaj systém.
5 Whys stretnutie sa môže zmeniť na obviňovanie. "Prečo? Pretože Jano to pokazil." Toto je toxické a neproduktívne.
Poučenie: Pravidlo #1: Nikdy nehľadáme vinníka. Hľadáme systém, ktorý umožnil problém.
Praktické cvičenie
Vyber problém vo svojom startupe a aplikuj 5 Whys:
Problém:
5 Whys analýza:
| # | Prečo? | Odpoveď |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 |
Root cause:
Akčné kroky:
Kľúčové poznatky
- 5 Whys = opakovaným pýtaním sa "prečo?" nájdeš skutočnú príčinu
- Pôvod v Toyota Production System, dnes súčasť Lean Startup
- Pravidlo #1: Nikdy nehľadaj vinníka - hľadaj systém
- Human error nie je root cause - pýtaj sa, čo v systéme chybu umožnilo
- Používaj pri postmortems, customer interviews, aj product debugging
- Pri komplexných problémoch kombinuj s inými metódami (Fishbone, systems thinking)
Dodatočné materiály
Základné čítanie
- Eric Ries: The Lean Startup - Kapitola o 5 Whys
- Taiichi Ohno: Toyota Production System
Články
- Buffer: The 5 Whys Process We Use
- Atlassian: 5 Whys Analysis
Nástroje
- Miro/Mural - Pre team 5 Whys sessions
- Notion/Confluence - Pre dokumentáciu postmortems
Skopiruj prompt a vloz do obľúbenej AI pre personalizovane učenie.
Odpovedz na 3 otázky