Jak utworzyć macierz RACI w Jira: jasno określ odpowiedzialność
Na przykładzie niewielkiej zmiany w portalu klienta ustal, kto wykonuje pracę, kto odpowiada za wynik i kogo należy zaangażować.
Zgłoszenie Jira może mieć przypisaną osobę, a mimo to pozostawiać ważne obowiązki nieustalone. Kto odpowiada za końcowy wynik? Kto powinien sprawdzić pracę przed jej zakończeniem? Kto potrzebuje informacji bez udziału w każdej dyskusji?
Te pytania stają się trudniejsze, gdy jedna praca obejmuje produkt, programowanie, testy i obsługę klienta. Przypisana osoba może wdrożyć zmianę, ale nie staje się przez to odpowiedzialna za wszystkie związane z nią rozmowy.
Macierz RACI uwidacznia te oczekiwania. Łączy niewielki zestaw rezultatów z zaangażowanymi osobami i zapisuje sposób udziału każdej z nich.
W tym poradniku stworzymy praktyczny przykład fikcyjnego wydania portalu klienta, a następnie uporządkujemy macierz w Power Pack dla Jira. Celem jest krótkie, użyteczne porozumienie, które pozwala działać z pewnością.
Co oznacza RACI?
RACI opisuje cztery sposoby udziału w pracy:
| Responsible — wykonuje pracę | Wykonuje pracę niezbędną do uzyskania rezultatu. | Kto faktycznie to zrobi? |
| Accountable — odpowiada za wynik | Ponosi odpowiedzialność za wynik i jego ukończenie. | Kto dopilnuje uzyskania akceptowalnego rezultatu? |
| Consulted — konsultowany | Przekazuje informacje i wiedzę, które powinny wpłynąć na pracę. | Czyjej wiedzy potrzebujemy przed zakończeniem? |
| Informed — informowany | Otrzymuje istotne aktualizacje lub wynik. | Kto musi wiedzieć, co się wydarzyło? |
W każdym wierszu wyznacz jedną osobę odpowiedzialną za wynik. Przypisz co najmniej jednego wykonawcę i jasno opisz współdzielone obowiązki wykonawcze. Konsultacja oznacza rozmowę; poinformowanie może wymagać tylko krótkiej wiadomości.
Definicje te odpowiadają opisowi macierzy RACI firmy Atlassian. Dalsza część poradnika stosuje je w przykładowym procesie Jira.
Rozróżnienie wykonania i odpowiedzialności za wynik jest szczególnie przydatne. Programista może wdrożyć preferencję powiadomień, podczas gdy właściciel produktu odpowiada za uzyskanie uzgodnionego rezultatu dla klienta. Żadna rola nie zastępuje oceny technicznej ani współpracy.
Zacznij od rzeczywistego problemu koordynacji
Nasz fikcyjny zespół przygotowuje aktualizację portalu klienta. Klienci będą wybierać otrzymywane wiadomości dotyczące konta. Zmiana wymaga także testów i krótkiej instrukcji dla pomocy technicznej.
W zespole są Maya, właścicielka produktu; Leo, programista; Priya, testerka; oraz Sam, lider obsługi klienta. Imiona i przydziały są przykładami, a nie wymaganym modelem zatrudnienia.
Przed utworzeniem macierzy zespół wskazuje niejasność: wszyscy zgadzają się, że trzeba zbudować ekran preferencji, lecz nikt nie przejął wyraźnie odpowiedzialności za instrukcję wsparcia. Testy zależą też od decyzji produktowej określającej, które wiadomości klienci muszą nadal otrzymywać.
To dobry powód do utworzenia RACI. Zespół z jednym prostym zadaniem i oczywistą odpowiedzialnością może jej nie potrzebować. Stosuj model tam, gdzie rozmowa o obowiązkach zmieni sposób pracy.
Wybierz zgłoszenie Jira stanowiące sensowne miejsce dyskusji. Powinno opisywać wspólny rezultat i odsyłać do odpowiednich prac wykonawczych. Powiedz zespołowi, gdzie jest macierz, aby weszła do rutyny planowania.
Opisuj rozpoznawalne rezultaty
Zacznij od wyników, nie od szerokich działów czy niejednoznacznych etapów. „Programowanie” oznacza grupę osób. „Wdrożyć kontrolki preferencji e-mail” opisuje pracę, którą można ukończyć.
W naszym przykładzie zespół wybiera cztery wiersze:
- Uzgodnić, które preferencje powiadomień klienci mogą zmieniać.
- Wdrożyć kontrolki preferencji e-mail.
- Sprawdzić wpływ zmian preferencji na wysyłkę wiadomości.
- Opublikować instrukcję wsparcia dotyczącą nowych kontrolek.
Każdy wiersz powinien być dość mały, by miał jasną odpowiedzialność, ale na tyle ważny, by uzasadniał rozmowę. Wypisywanie każdego drobnego kroku może ukryć problem koordynacji pod administracją.
Jeżeli wiersz ciągle potrzebuje dwóch osób odpowiedzialnych za wynik, sprawdź zakres. „Zbudować i uruchomić całe rozwiązanie” może obejmować kilka wyników z różnymi właścicielami. Podziel go tam, gdzie odpowiedzialność naprawdę się zmienia, i sprawdź, czy części nadal opisują całość.
Przygotuj pierwszą wersję macierzy
Oto początkowe ustalenie zespołu. Myślnik oznacza brak przypisanej roli dla danego rezultatu.
| Uzgodnić zachowanie preferencji | A | R | C | C |
| Wdrożyć kontrolki preferencji | A | R | C | I |
| Sprawdzić preferencje i zachowanie wiadomości | A | C | R | I |
| Opublikować instrukcję wsparcia | C | R | I | A |
Ostatni wiersz wymaga wyjaśnienia. Sam odpowiada za poprawność i przydatność instrukcji, a Leo opisuje techniczne kroki. Tak uzgodnił ten konkretny zespół. Inny mógłby powierzyć przygotowanie tekstu specjaliście wsparcia.
Macierz powinna przedstawiać rzeczywiste ustalenia. Nie wypełniaj jej wyłącznie na podstawie stanowisk. Ktoś może mieć odpowiednią wiedzę, ale nie mieć czasu na wykonanie pracy, a wysoki tytuł nie czyni go automatycznie właściwą osobą odpowiedzialną za wynik.
Przeczytaj każdy wiersz na głos. Dla testów ustalenie brzmi: Priya sprawdza, Leo wnosi wiedzę techniczną, Maya odpowiada za wynik, a Sam go otrzymuje. Jeśli kogokolwiek to zaskakuje, wyjaśnij rozbieżność przed uznaniem macierzy za uzgodnioną.
Zapisz ustalenia w Power Pack
Otwórz Power Pack w zgłoszeniu Jira i użyj RACI / DACI Matrix. Model odpowiedzialności jest oznaczony RA(S)CI: zawiera cztery role RACI i opcjonalne wsparcie Support. Możesz zbudować przykład przy użyciu R, A, C i I bez przypisywania S.
Przejdź przez widoki uczestników, rezultatów i macierzy. Najpierw dodaj osoby. Lista obsługuje wyszukiwanie użytkowników Jira oraz wpisy uczestników zewnętrznych i bez konta Jira. Wpis zewnętrzny zapisuje osobę na liście; nie tworzy konta i nie daje dostępu do zgłoszenia.
Następnie dodaj uzgodnione rezultaty. Power Pack ma też akcję Import Subtasks, która pobiera istniejące podzadania do puli dostępnych rezultatów. Przed przejściem do macierzy sprawdź wybrane elementy, aby wiersze odpowiadały planowanej rozmowie.
W macierzy przypisz rolę na każdym istotnym przecięciu. Klikanie komórki przełącza dostępne role; aktywne komórki obsługują również skróty z literami ról. Pozostaw komórkę pustą, jeżeli dana osoba nie ma sensownej odpowiedzialności w tym wierszu.
Narzędzie wskazuje brak właściciela, wielu właścicieli oraz wiersze bez wykonawcy. Traktuj te sygnały jako zachętę do sprawdzenia przydziałów. Poprawny wiersz potwierdza podstawowy układ ról, nie zgodę osób, ich dostępność ani ukończenie pracy.
Zmiany są zapisywane przy zgłoszeniu Jira. Sprawdź wskaźnik zapisu przed wyjściem lub poproszeniem o przegląd. Stan lokalny albo offline nie potwierdza, że inny członek zespołu widzi już najnowszą wersję.
Sprawdzaj osoby, nie tylko wiersze
Macierz może wyglądać rozsądnie w każdym wierszu, a zarazem skupiać zbyt dużo pracy na jednej osobie. Po przejrzeniu rezultatów przeczytaj każdą kolumnę osoby.
W naszym przykładzie Leo uzgadnia zachowanie, wdraża kontrolki i przygotowuje instrukcję. Dla małej zmiany może to pasować. Przy większym wydaniu może ujawnić wąskie gardło, którym należy się zająć przed obietnicą terminu.
Zapytaj każdą osobę, czy rozumie rolę i może ją wypełnić. Ustal, kiedy potrzebna jest konsultacja, jak szybko oczekuje się informacji zwrotnej i co otrzymają osoby informowane. Szczegóły terminów i komunikacji zapisuj w zwykłym procesie Jira przy pracy.
C w komórce nie planuje przeglądu. I nie wysyła aktualizacji. Macierz nazywa oczekiwanie; zespół musi je wykonać.
Oddziel odpowiedzialność od przepływu Jira
Przypisania RACI opisują udział w uzyskaniu rezultatu. Nie są tożsame z osobą przypisaną w Jira, uprawnieniami ani statusem przepływu pracy.
Zmiana komórki nie zastępuje przypisania zadania wykonawczego, udzielenia dostępu czy przejścia zgłoszenia do innego statusu. Uzgadniaj te działania z porozumieniem w normalnym procesie.
Power Pack eksportuje macierz jako tabelę Markdown lub CSV do dyskusji poza narzędziem. Udostępniając kopię, wskaż zgłoszenie Jira jako miejsce sprawdzania aktualnych przydziałów. W przeciwnym razie stara tabela może krążyć po zmianie planu.
Wróć do macierzy przy zmianie zakresu, niedostępności uczestnika lub nowym wymaganiu przeglądu. Krótkie sprawdzenie przy istotnej zmianie jest przydatniejsze niż traktowanie pierwszej wersji jako stałej.
Unikaj trzech częstych błędów RACI
Konsultowanie wszystkiego ze wszystkimi
Konsultacja powinna odpowiadać na konkretne pytanie. Angażowanie wszystkich w każdy wiersz może odtworzyć obciążenie spotkaniami, które macierz miała zmniejszyć. Nazwij potrzebną wiedzę, a osoby potrzebujące wyłącznie wyniku oznacz jako informowane.
Domyślne przydzielanie odpowiedzialności za wynik jako dodatkowej pracy
Osoba odpowiedzialna za wynik potrzebuje kontekstu i uprawnień pozwalających rozwiązywać problemy. Nie wybieraj jej tylko dlatego, że zajmuje najwyższe stanowisko lub uczestniczy w największej liczbie spotkań.
Rozwiązywanie problemu decyzji za pomocą RACI
Czasami niejasne jest nie to, kto wykona pracę, ale kto wybierze spośród opcji. Wtedy DACI może lepiej uporządkować rozmowę: określ prowadzącego, jednego decydenta, współtwórców i osoby do poinformowania. Podejmij decyzję, a potem w razie potrzeby ustal realizację przez RACI.
Wypróbuj niewielką macierz z zespołem
Wybierz zgłoszenie, w którym odpowiedzialność przekracza granice zespołów. Określ trzy do pięciu sensownych rezultatów, dodaj uczestników i wspólnie uzgodnij role.
Zachowaj porozumienie przy zgłoszeniu dzięki RACI / DACI Matrix w Power Pack. Sprawdź wskaźniki odpowiedzialności, potwierdź zapis i omów wynik z wymienionymi osobami.
Zacznij od macierzy usuwającej prawdziwą niejasność. Dla zespołu portalu korzyść jest prosta: wszyscy wiedzą, kto buduje kontrolki, kto je sprawdza, kto odpowiada za wynik i kto przygotowuje wsparcie.
Powiązane artykuły
DACI w Jira: jasna odpowiedzialność za każdą decyzję
Wykorzystaj DACI w Jira do wyznaczenia prowadzącego, jednego decydenta i zebrania przydatnych opinii. Praktyczna decyzja o powiadomieniach z Power Pack.
Zarządzaj akceptacjami interesariuszy w Jira: pokaż jasny status zgody
Nadaj każdemu przeglądowi zakres, wskazanego zatwierdzającego i widoczny status. Zachowaj zrozumiałość akceptacji przy zmianach wydania.
Porozmawiajmy
Masz pytania dotyczące tego artykułu? Porozmawiajmy o Twoich celach technicznych.