Что такое Accountable?

Accountable в матрице RACI

"Accountable" — это одна из четырёх ролей в матрице RACI. Это один из важнейших инструментов BA для управления ответственностью и коммуникацией в проекте.

Что такое RACI матрица

RACI расшифровывается как:

• R — Responsible (Ответственный) — тот, кто делает работу
• A — Accountable (Подотчётный/Утверждающий) — тот, кто несёт полную ответственность
• C — Consulted (Консультант) — того спрашивают мнение
• I — Informed (Информируемый) — того уведомляют о результатах

Что такое Accountable

Accountable — это лицо, которое несёт конечную ответственность за результат. Это не обязательно тот, кто выполняет работу (может быть только один Accountable на задачу).

Ключевые характеристики:

1. Ответственность перед руководством — именно Accountable ответит руководству, если что-то пошло не так
2. Принимает решения — Accountable принимает финальное решение, может переиграть рекомендации других
3. Утверждает результаты — результат работы передается на утверждение Accountable
4. Всегда один — на каждую задачу должен быть ровно один Accountable (иначе никто не отвечает)
5. Может не выполнять саму работу — Accountable может полностью делегировать выполнение, но остаётся ответственным

Примеры из практики

Проект: Внедрение платёжной системы

Задача: "Интеграция с Payment Gateway Stripe"

R (Responsible):  Backend разработчик Иван
                  - Пишет код интеграции
                  - Тестирует API Stripe
                  - Делает review других кодов

A (Accountable):  Техлид/CTO Петр
                  - Отвечает перед клиентом если интеграция неправильная
                  - Принимает final решение по архитектуре
                  - Утверждает результат разработки

C (Consulted):    Security специалист
                  - Проверяет, что ключи Stripe безопасно хранятся
                  - Рецензирует код на уязвимости

I (Informed):     DevOps инженер
                  - Уведомляется когда интеграция готова
                  - Настраивает переменные окружения

Другой пример: Утверждение требований

Задача: "Согласовать и утвердить требования к новой CRM"

R (Responsible):  BA (я)
                  - Собираю требования
                  - Создаю документ с требованиями
                  - Организую встречи

A (Accountable):  Product Manager
                  - Несёт ответственность перед бизнесом что требования верные
                  - Принимает финальное решение какие требования в MVP
                  - Утверждает документ требований

C (Consulted):    Финансовый директор
                  - Проверяет что требования не превышают бюджет
                  - Дает feedback на экономические аспекты

I (Informed):     Разработчики
                  - Уведомляются когда требования утверждены
                  - Могут планировать спринты

Различие между Responsible и Accountable

Это очень важно понимать:

Моя практика применения RACI

Я использую RACI матрицу в каждом проекте:

Шаг 1: Определение участников

Создаю список всех ролей в проекте:

• Sponsor (заказчик)
• Product Owner
• Project Manager
• BA
• Архитектор
• Tech Lead
• Разработчики
• QA
• DevOps
• Дизайнер

Шаг 2: Определение основных задач

Для каждой ключевой задачи создаю строку в таблице:

• Сбор требований
• Проектирование архитектуры
• Разработка feature X
• Тестирование
• Развёртывание в prod
• Поддержка после внедрения

Шаг 3: Заполнение матрицы

Задача: Разработка API для мобильного приложения

Спонсор (заказчик):      I (информируем о завершении)
PO:                       A (утверждает требования к API)
BA:                       R (собирает требования, описывает endpoints)
Архитектор:              C (консультирует по структуре данных)
Tech Lead:               A (отвечает за качество кода)
В разработчики:          R (разрабатывают API)
QA:                      R (тестируют API)
DevOps:                  R + C (развёртывают, консультируют по secrets)
Dизайнер:                I (информируют что API готов)

Шаг 4: Валидация

Проверяю:

• На каждый столбец (задачу) есть ровно один Accountable?
• На каждую строку (роль) есть задачи где она R или A?
• Нет ли слишком много C (это означает плохую коммуникацию)?

Типичные ошибки

Ошибка 1: Несколько Accountable на одну задачу

Задача: "Утвердить бюджет"
A: Финдиректор И руководитель проекта И спонсор
           ↓
Никто не отвечает, все ждут друг друга

Решение: Выбрать ЕДИНственного Accountable (обычно тот, кто подписывает бюджет).

Ошибка 2: Accountable = Responsible

Задача: "Написать 1000 строк кода"
R + A: Один разработчик
           ↓
Если он болел, всё падает. Нет резервного плана.

Решение: Accountable — tech lead, Responsible — разработчик + backup.

Ошибка 3: Слишком много Consulted

Задача: "Выбрать БД для проекта"
C: Архитектор, tech lead, DevOps, DBA, Senior разработчик
           ↓
Процесс согласования месяц, никто не может решить

Решение: Ограничить C до максимум 2-3 человек, остальные I.

Как я применяю RACI в общении

1. На встречах: "Давайте уточним, кто Accountable за этот баг? Рома, это ты?"

2. В письмах: "Важно! Accountable за это требование — Product Manager. Если что изменится, согласуем с ним."

3. При распределении работы: "Иван, ты Responsible за реализацию. Но Петр (tech lead) — Accountable и должен утвердить твой код."

4. В документации: Публикую RACI матрицу в вики проекта, чтобы все понимали кто за что отвечает

5. При эскалации: "У нас проблема с требованиями. Accountable — PM, поэтому его звоним."

Преимущества использования RACI

✓ Ясность — каждый знает свою роль ✓ Избежание конфликтов — понятно кто принимает решение ✓ Эффективность — не тратим время на согласование ✓ Ответственность — есть человек отвечающий перед боссом ✓ Масштабируемость — матрица работает для проектов любого размера

RACI матрица — это не просто инструмент, это способ организовать коммуникацию и избежать хаоса в проекте.