Už víme, že projektový tým se ve skutečnosti může skládat z mnoha týmů, jak na straně zákazníka, tak na straně dodavatele. To je sice skvělé, ale samotná existence role neříká nic o tom, co se stane, když se projekt dostane do krize, nebo kdo má poslední slovo při nasazení do produkce.
Zde přichází na řadu RACI matice. Je to nástroj, který mapuje vztah konkrétních rolí ke konkrétním úkolům či rozhodnutím. Zabraňuje tomu, aby se dva lidé hádali o volant, nebo naopak, aby volant nikdo nedržel.
Co znamenají písmena RACI?
RACI je akronym, který definuje čtyři úrovně zapojení do úkolu. V češtině je klíčové pochopit rozdíl mezi R a A, což bývá nejčastější kámen úrazu.
R – Responsible (Ten, kdo to dělá)
- „Dělník“ úkolu. Ten, kdo reálně píše kód, tvoří dokumentaci nebo konfiguruje server.
- Může jich být více (např. celý tým vývojářů pracuje na jedné funkci).
A – Accountable (Ten, kdo za to ručí)
- „Vlastník“ úkolu. Ten, kdo má právo veta a nese finální odpovědnost, pokud se to nepovede.
- Zlaté pravidlo: U každého úkolu musí být vždy jen jedno A. Pokud je jich více, vzniká chaos. Pokud žádné, úkol se neudělá.
C – Consulted (Ten, s kým se to konzultuje)
- Expert, jehož názor je potřeba před dokončením úkolu (např. Security expert, Architekt).
- Probíhá zde obousměrná komunikace.
I – Informed (Ten, kdo je informován)
- Člověk, který potřebuje vědět o výsledku, ale nezasahuje do procesu (např. zákaznická podpora, která musí vědět, že nová verze je venku).
- Probíhá zde jednosměrná komunikace.
Jak vypadá RACI matice v praxi?
Vizuálně jde o jednoduchou tabulku.
- Řádky: Jednotlivé úkoly, milníky nebo rozhodnutí (např. „Design databáze“, „Schválení UX návrhu“).
- Sloupce: Role nebo konkrétní lidé (Dev, PO, Architect, Stakeholder).
Příklad:
| Aktivita | Accountable | Responsible | Consulted | Informed |
| Definice funkčních požadavků a obchodních potřeb pro systém | Business Analysis Team | Business Analysis Team | Key Users, Project Management, External Vendor | Development Team, QA Team |
| Analýza potřeb uživatelů a sestavení specifikací | Business Analysis Team | Business Analysis Team | Key Users, Project Management | Development Team |
| Zajištění potřebné IT infrastruktury pro nový systém | IT Infrastructure Team | IT Infrastructure Team | Security Team, External Vendor | Project Management, QA Team |
| Implementace serverů, sítě a zabezpečení | IT Infrastructure Team | IT Infrastructure Team | Security Team | Development Team |
Základní pravidlo zní, že Accountable (A) může být pouze jeden tým / jedna osoba. V ostatních políčkách může být klidně více týmů, u políčka „C“ ve výjimečných případech nemusí být nikdo.
Kde se RACI vyplatí
Použití RACI není nutné u každé maličkosti, ale například v těchto situacích zachránilo projekty:
- nasazení nové bankovní aplikace u velkého klienta
- projekt s velkým počtem změn během jednotlivých projektových fází
- onboarding nováčků do týmu
V prvním projektu díky RACI každý věděl co má dělat – například DevOps (R) provádí skript, Release Manager (A) dává finální „GO“, QA Lead (C) potvrzuje, že testy prošly a Helpdesk (I) dostává info, že může očekávat telefonáty o změnách. Nikdo se neptá „Už to tam je?“, „Můžu to pustit?“, „Kdo to schvaluje?“.
Ve druhém případě RACI jednoznačně definuje, že Vývojář (C) se k proveditelnosti vyjadřuje, ale pouze Project Manager (A) má právo změnu schválit a upravit backlog.
Ve třetím případě má nováček k dispozici tabulku, kde je jasně uvedeno, kdo co dělá a kdo je za co zodpovědný. Jakmile se stane součástí jednoho týmu, najde si příslušné řádky v RACI a ví, co všechno dělá, kdo je za jeho práci zodpovědný, s kým je potřeba konzultovat a koho informovat o výsledku.
Kde se nepoužití RACI nevyplácí
Jestliže projekt běží bez komplikací a v dobré náladě, zpravidla poběží velmi podobně s RACI i bez RACI. Potřeba jasně definovaných kompetencí nastává až v době, kdy jde do tuhého a nikdo na sobě nechce nechat ležet břímě viny.
Typické scénáře, kdy litujeme, že jsme RACI neudělali hned na začátku:
- syndrom „to měl udělat on“
- rozhodovací paralýza
- e-mailová bouře
První případ je klasická situace, kdy není definováno, kdo je zodpovědný (A), resp. kdo danou věc realizuje (R). Byl nahlášen kritický bug v zabezpečení. Security tým si myslel, že bugy opravuje vývoj. Vývoj si myslel, že když se jedná o security bug, opraví to Security. Infrastruktura nevěděla, kdo to má udělat, ale věděla, že oni ne.
Druhý případ je situace, kdy vícero týmů si myslí, že jsou zodpovědní (A). Vybírá se například cloudová platforma. Rozhodnout chce CTO, Lead Architect i Project Manager. Všichni se totiž cítí jako A. Jaký to má výsledek? Nekonečné schůzky, hádky a projekt stojí.
Třetí případ je situace, kdy je příliš mnoho lidí v políčkách C a I. Projektový manager se asi trochu bál, aby někoho neurazil, a tak ke každému designu tlačítka se vyjadřuje 30 lidí z oddělení marketingu, prodeje, personalistiky, financí a právních záležitostí. Vývoj stojí, protože každé oddělení má protichůdné připomínky a je potřeba je všechny zpracovat.