Jako product manager na pewno nie raz spotkałeś się z sytuacją, w której nie było do końca jasne, kto za co odpowiada w produkcie: Kto powinien podjąć decyzję o wysokopoziomowych priorytetach? Kogo zaangażować w proces discovery? Kto tak naprawdę jest odpowiedzialny za rollout nowej funkcji?

Brak przejrzystości prowadzi do niekończących się spotkań, konfliktów między zespołami, przeciążenia product managera oraz - co najgorsze 0 opóźnień w dostarczaniu wartości dla użytkowników.

Jednym z frameworków pozwalających zaatakować ten problem jest macierz RACI - jedno z najprostszych narzędzi do definiowania ról i odpowiedzialności w projektach.

Macierz RACI – na czym polega?

Macierz RACI to po prostu tabela, w której dla każdego zadania przypisuje się odpowiednie role według konkretnych 4 kategorii. Te kategorie składają się na akronim RACI:

• R (Responsible, Odpowiedzialny) – osoba (lub osoby), które bezpośrednio wykonują pracę i realizują zadanie. Może to być np. UX Designer odpowiedzialny za przygotowanie prototypów lub developer implementujący nową funkcję.

• A (Accountable, Rozliczany) – osoba, która ponosi ostateczną odpowiedzialność za zadanie i upewnia się, że zostanie ono ukończone. W idealnym scenariuszu dla każdego zadania powinna być tylko jedna taka osoba. Przykład? PM odpowiedzialny za dostarczenie roadmapy produktu.

• C (Consulted, Konsultowany) – osoby, które powinny zostać skonsultowane przed podjęciem decyzji lub wykonaniem zadania. To np. customer support dzielący się insightami o problemach użytkowników lub zespół prawny weryfikujący zgodność rozwiązania z przepisami.

• I (Informed, Informowany) – osoby, które powinny być poinformowane o postępach lub wyniku pracy, ale nie mają wpływu na jej wykonanie. Przykładem może być zespół sprzedaży, który powinien wiedzieć o zmianach w produkcie, ale nie bierze udziału w ich tworzeniu.

Jak wygląda macierz RACI w praktyce?

Macierz RACI to po prostu tabela, w której dla każdego zadania przypisuje się odpowiednie role według powyższych kategorii. Wygląda to mniej więcej tak:

Dzięki takiemu podejściu każdy w zespole dokładnie wie, jaka jest jego rola w danym zadaniu, a unikanie dublowania odpowiedzialności i konfliktów staje się o wiele prostsze. Kluczowe korzyści które ma dać macierzy RACI to:

• ✅ Klarowność ról – każdy wie, co ma robić i kto podejmuje decyzje.

• ✅ Szybsze podejmowanie decyzji – mniej zbędnych spotkań, mniej niepewności.

• ✅ Lepsza współpraca między działami – precyzyjne określenie, kto powinien być konsultowany i informowany.

• ✅ Mniej konfliktów – brak przeciągania liny między zespołami.

Tu przykład jeszcze jednej macierzy:

Moje praktyczne doświadczenia z macierzą RACI ⚔️

Niepopularna opinia: nigdy nie widziałem, aby długoterminowo jakaś rozbudowana macierz RACI rzeczywiście działała i była konsekwentnie utrzymywana.

Owszem, RACI dobrze działała jako narzędzia do jednorazowego przegadania realnej odpowiedzialności, zwłaszcza gdy pojawiały się wątpliwości, lub na początku współpracy (na przykład między Product Ownerem / Product Managerem a zespołem developerskim).

W takich sytuacjach lepiej sprawdzały mi się jednak narzędzia takie jak:

• Delegation Poker i Delegation Board,

• bezpośrednie ustalenie, kto jest DRI (Directly Responsible Individual) za dany element.

• model DACI, stosowanego w Atlassianie

Widziałem kilka firm, które próbowały na stałe wdrożyć macierz RACI, zwykle jako odpowiedź na problemy z komunikacją i realnym poczuciem odpowiedzialności w zespołach. Efekt był zawsze podobny:

• zespoły/indywidualni kontrybutorzy tracili mnóstwo czasu na tworzenie szczegółowej macierzy, prowadząc niekończące się dyskusje o niezliczonych przypadkach brzegowych,

• tabele rozrastały się do gigantycznych rozmiarów, co sprawiało, że nikt ich nie aktualizował, a z czasem wszyscy o nich zapominali,

• dodatkowo, ludzie zamykali się w swoich obszarach i niechętnie współpracowali nad wspólnymi zadaniami.

Osobiście preferuję podejście oparte na DRI (Directly Responsible Individuals), gdzie konkretna osoba określa, co, z kim i jak deleguje, aby osiągnąć cel.

Ale to oczywiście tylko moje doświadczenia 🙂 

Doświadczenia produktowej społeczności

W naszej społeczności kampusu Product Academy kilka osób podzieliło się swoimi doświadczeniami z macierzą RACI i podobnymi technikami do ustalenia odpowiedzialności: