RACI матриця як інструмент управління відповідальністю. RACI: розшифровка

Одна з найбільш частих причин невдалих проектів — неправильний розподіл функцій між членами команди. Напевно ви вже стикалися з цим: при найменших труднощах учасники починають шукати винуватих і перекидати відповідальність один на одного замість того, щоб вирішити проблему. І як раз щоб таких ситуацій не виникало, була придумана матриця RACI — простий і ефективний інструмент планування людських ресурсів.

"Під мікроскопом": 4 ключових ролі у кожному проекті

Розподіл завдань — одна з основних обов'язків менеджера. Але на практиці все зазвичай виглядає інакше: керівник просто призначає членів команди з розрахунком на те, що фахівці самі вирішать, хто і що повинен робити. Але що відбувається, якщо були зірвані терміни або випущений неякісний продукт? "Я цим не займаюся", "мені цього не говорили" І ніяких корисних дій.


Грамотно побудована матриця відповідальності RACI дозволяє вирішити багато проблем. Згідно з цією методикою, незалежно від складності та обсягу робіт, член команди проекту виконує одну з чотирьох ролей.

R — Responsible

У перекладі Responsible означає "виконавець". Це співробітник, на якому безпосередньо лежить відповідальність за виконання певного учасника роботи. При цьому в більшості випадків він не вибирає способи рішення і підкоряється керівнику проекту. На цю роль призначають компетентних працівників і фахівців — людей, які вміють робити . У RACI виконавці виконують такі функції:

визначають, що конкретно потрібно зробити для реалізації проекту і скільки часу це займе (в межах умов, поставлених "зверху");

складають список необхідних ресурсів;

беруть участь у погодженні та затвердженні технічної документації;

аналізують хід виконання проекту і проміжні результати ;

надають керівнику звіти про виконану роботу.

Таких людей в команді може бути кілька. Крім того, ця роль може комбінуватися з іншими. Найчастіше зустрічається поєднання Accountable + Resbonsible (у перекладі — "відповідальний + виконавець").

A — Accountable

"Підзвітний", або "відповідальний" — це головний керівник проекту. Саме він відповідає за те, щоб поставлені завдання були виконані в строк, з необхідним рівнем якості і в межах виділеного бюджету. Крім того, A:

вибирає виконавців та команди управління проектом;

призначає завдання всім учасникам;

контролює хід роботи;

розподіляє ресурси між виконавцями;

веде облік використання ресурсів, а також обґрунтує куратору необхідність виділення додаткових коштів;

розглядає ідеї і пропозиції інших членів команди, може стверджувати або заперечувати їх.

Зазвичай керівник проекту виступає в якості "сполучної ланки" між замовником або вищим начальством і командою.

C — Consulted

Третя роль в матриці RACI — "консультант" (його іноді також називають "куратором"). Поряд з керівником, він приймає участь в управлінні проектом, але займається в першу чергу вирішенням стратегічних питань:

затверджує будь-які зміни у обсязі і терміни робіт;

виділяє ресурси, необхідні для реалізації проекту;

при необхідності узгоджує з замовником необхідність збільшити бюджет;

отримує від керівника звіти про виконану роботу;

приймає рішення у будь-яких непередбачених ситуаціях, при виникненні критичних змін, які можуть вплинути на строки та вартість проекту.

На роль консультантів зазвичай призначають менеджерів вищої ланки. Саме вони визначають глобальні цілі, а потім призначають керівника проекту, який вже розподіляє завдання між членами команди.

I — Informed

Крім перерахованих ролей, в матриці RACI вказують "информируемого" ("спостерігача"). Він виконує функції адміністратора і в основному займається організацією документообігу. Спостерігач підпорядковується керівнику проекту, проте, на відміну від інших учасників, що не несе відповідальності за його результати. Замість цього він:

збирає та систематизує всю інформацію по проекту, ресурсів та планам;

веде протоколи нарад;

приймає документацію від учасників проекту, щоб потім передати їх у відповідні структури;

стежить за строками подання та правильністю заповнення звітів.

Зверніть увагу, що зв'язок з спостерігачем є переважно однобічної. Його основна функція — звільнити менеджера від необхідності витрачати час на бюрократичні процедури і "розвантажити" його.

Вчимося будувати RACI-матрицю на прикладі

Поговоримо про практичну сторону питання. Як правильно скласти діаграму розподілу повноважень та відповідальності? 1. Складаємо to do-list Насамперед необхідно розписати все, що потрібно зробити. Ступінь деталізації залежить від конкретного проекту. Іноді для простоти контролю та управління розробляють кілька матриць. Спочатку перерахуйте основні блоки роботи, а потім розбийте кожний на окремі функції і завдання. Список робіт зазначається в таблиці по вертикалі.

Етапи































Технічне завдання































Прототип































Дизайн































Програмний код































Звіт про тестування































Презентація сайту





























2. Вибираємо учасників команди Тут потрібно відповісти на питання: "Хто буде займатися цим проектом?". По горизонталі необхідно виписати всіх співробітників і/або відділів, які беруть участь у реалізації на всіх етапах — від планування до презентації результатів і складання звіту.


Етапи



Аналітик



Дизайнер



Сіс. архітектор



Розробник



Тестувальник



Сіс. адмін.



Project manager



Технічне завдання































Прототип































Дизайн































Програмний код































Звіт про тестування































Презентація сайту





























3. Заповнюємо таблицю Після цього можна приступати до розподілу функцій. Для цього потрібно мати чітке уявлення про кожному етапі роботи і про те, як відбувається робота в командах. Візьмемо за основу наш приклад і зупинимося на етапі "Дизайн". В даному випадку R — виконавець — тільки один. У процесі роботи він орієнтується на попередньо підготовлений прототип сайту. Тому системний архітектор, який займався його розробкою, на цьому етапі виконує функцію консультанта C. Також можуть висловлювати свої побажання аналітик і розробник. Готовий дизайн затверджується з менеджером проекту (A). А ось тестувальники і системний адміністратор на цьому етапі не приймають ніяких рішень, а лише отримують інформацію про те, як йде робота, а тому їм присвоюють роль информируемих — I.

Етапи



Аналітик



Дизайнер



Сіс. архітектор



Розробник



Тестувальник



Сіс. адмін.



Project manager



Технічне завдання



R



I



C



C



I



C



A



Прототип



C



I



R



C



I



I



A



Дизайн



C



R



C



C



I



I



A



Програмний код



C



I



C



AR



I



I



I



Звіт про тестування



C



C



C



C



AR



I



I



Презентація сайту



C



I



C



C



I



AR



I

Різновиди моделі

У більшості випадків можна обійтися стандартною матрицею. Однак при роботі над більш складними проектами іноді виникає необхідність у додаткових ролях. Тому в останні роки з'явилося 2 розширених варіанти діаграми відповідальності. RACI-VS Тут до стандартних ролей додаються ще дві:

Verifies (V) — співробітник або спеціальна команда, які перевіряють, наскільки результат реалізації тієї чи іншої задачі відповідає затвердженим критеріям.

Signs off (S) погоджує здачу проекту з замовником, проводить презентацію та надає звіти. Зазвичай цю функцію виконує відповідальний за виконання роботи (Accountable), але RACI-VS для цього залучають окремого спеціаліста.

Завдяки посиленому контролю і більш тісного контакту з клієнтом, дана модель оптимально підходить для технічно складних чи масштабних проектів, над якими працюють десятки або навіть сотні) людей. RASCI У цьому варіанті В матриці з'являється одна нова роль — Supportive (S). Її ключові функції полягають у забезпеченні проекту додатковими ресурсами, тобто підтримки керівника і виконавців.

Ідеальне співвідношення ролей

Матриця RACI складається не тільки щоб знати, кого "репресувати" у разі якихось проблем. Ще на етапі планування з допомогою цієї таблиці ви можете побачити слабкі місця в організації робочого процесу. Вертикальний аналіз дозволяє побачити обов'язки та повноваження кожного з учасників проекту, об'єктивно оцінити рівень навантаження:

багато R — швидше за все, людині доведеться розриватися між декількома завданнями, що негативно позначиться на швидкості і результати роботи;

багато A — співробітник "отримує по шиї" за всіх; рекомендується розподілити відповідальність більш рівномірно;

немає осередків R і A — привід задуматися про доцільність цієї посади як такої (по суті, ви платите фахівцеві, який не робить нічого);

немає порожніх клітинок — знову ж таки проблема перенавантаження, не кожен здатний одночасно виконувати стільки завдань.

Горизонтальний аналіз у свою чергу, демонструє якість організації роботи на кожному етапі. Тут теж часто виникають проблеми:

багато R — можливо, має місце дублювання функцій, і хтось із членів команди виконує непотрібну роботу;

багато A — відбувається "розмивання" відповідальності і плутанина при здачі проектів;

багато C — обговорення значно гальмують робочий процес (потрібно чекати, поки всі внесуть свої правки та зауваження, знаходити компроміси і т. д.);

немає I — може бути сигналом до того, що одним завданням займається дуже багато виконавців, що також уповільнює виконання проекту.

З допомогою RACI менеджер може швидко виявити перевантажених або недостатньо зайнятих працівників, непотрібні посади і ділянки роботи, за які ніхто не відповідає. Грамотно складена матриця дозволяє істотно підвищити якість організації та контролю за виконанням проектів, а також зменшити кількість конфліктів між виконавцями ("Я цим не займаюся", "Це він повинен був зробити" і т. д.).

Корисні поради

Щоб матриця RACI виконувала свої функції і забезпечувала ефективну безперебійну роботу в компанії, потрібно пам'ятати про кількох важливих моментах.

При заповненні таблиці враховуйте кваліфікацію працівників. Так, бухгалтера не варто призначати консультантом (C) на етапі верстки сайту як мінімум тому, що він не розбирається в цій області.

На кожній дільниці має бути тільки один Accountable (A). Якщо їх кілька, вказуйте умови. Наприклад, A1 — відповідальний за тестування десктопної версії сайту, а A2 — мобільного.

У будь-якої задачі обов'язково повинні бути Accountable і Responsible (у перекладі — "Відповідальний" і "Виконавець").

Намагайтеся сформулювати кожну задачу максимально конкретно. Використовуйте дієслова — "опублікувати", "підготувати", "написати", "перевірити", "оновити" і т. д. Бажано відразу вказувати необхідні результати — не просто "Перевірити швидкість завантаження сайту", а "Переконатися, що швидкість завантаження сайту не більше 08 сек".

Дії повинні бути застосовні не до конкретного працівника, а до посади в цілому.

Складати матрицю RACI краще в команді, на основі розбору реальних робочих ситуацій. Важливо, щоб кожен учасник усвідомлював свою роль і задачі, які перед ним стоять.