Розбір кейса і класна матриця RACI

Розбір кейса і класна матриця RACI

Звісно, писати про концепції – це класно, але ще крутіше – показувати на прикладах як вони працюють. Сьогодні обговоримо матрицю RACI. Це модель, яка допомагає розподіляти зони відповідальності та повноваження між співробітниками в бізнес-процесах.

Розповім спочатку про кейс.

Ми в компанії проводили тести, суть яких полягала у виході на нові сегменти аудиторії. Продакт-маркетинг менеджер описував сегмент, за яким можливий PMF (ґрунтуючись на даних із продажів), описував, за якими результатами ми зрозуміємо, що PMF є, команда просування працювала над ключовими словами, майданчиками для запуску, а ми з моєю командою робили візуали для цих кампаній-тестів.

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

Уся проєктна команда була великою, близько 15 осіб. І ми з моєю креативною командою отримували коментарі майже від кожного.

Звичайно, запуски гальмувалися, доводилося пояснювати, чому таке рішення, нескінченно збирати ці коментарі, загалом, зрозуміло, що було :))

Підпишіться на наш Телеграм. Там ви знайдете анонси нових матеріалів та приємні бонуси

Після першого раунду ми зрозуміли, що це не працює, коли мета – швидкий запуск, і ось тут якраз прийшла на допомогу матриця RACI.

Що це таке?

RACI розшифровується як:

  • Responsible (хто робить роботу, наприклад, у цьому випадку дизайнер)
  • Accoubtable (хто приймає результат, хто за нього відповідає глобально, у цьому випадку це була я з погляду бренду і комунікації та Product marketing manager з погляду глибокого розуміння аудиторії)
  • Consultant (хтось, хто може принести valuable insights у роботу, у нашому випадку це був CPO і CMO)
  • Informed (хтось, хто повинен бути проінформований про рух роботи і готовність результату, наприклад, у цьому випадку це була команда просування, яка планувала свій запуск, ґрунтуючись на нашому дедлайні).

Ми створили сторінку в Confluence під кожен запуск із таким розподілом ролей.

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

Під кожен запуск у нас була окрема сторінка з Responsible, Accountable, Consultants, Informed, які отримували сповіщення про зміни на цій сторінці (наприклад, про апдейти статусів), а ще ті, від кого ми чекали на коментарі, могли залишати їх на тій самій сторінці в окремому блоці (=> ми не губили їх у безкінечних чатах слека, могли відповідати на них там самими, могли збирати якісь insights&findings в одне місце й навчатися завдяки ним).

Класна техніка, яка допомагає окреслити коло контриб’юторів і не перетворювати процес на тортури.

Рейтинг
( Поки що оцінок немає )
Сподобалася стаття? Поділитися з друзями:
Роби Бізнес, Укр
Додати коментар

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: