Управление пересекающимися ролями в командах

Введение

Чаще всего обязанности пересекаются там, где размыты границы ролей. Особенно в межфункциональных проектах — когда маркетолог работает с разработчиками, а дизайнер с аналитиками. Так сами собой возникают «серые зоны»: участки, где и правда непонятно, за кем решающее слово.

Роли со временем меняются, и картина от этого только запутывается. То, что год назад целиком лежало на одном специалисте, сегодня может требовать участия нескольких. Технологии не стоят на месте, процессы обрастают деталями, и вчера ещё чёткие границы начинают расплываться.

Стремление к самостоятельности — третий фактор. Опытный сотрудник скорее возьмёт ответственность на себя, чем будет ждать, пока кто-то другой подведёт и завалит проект. Для одного человека это понятно, но в масштабе команды выходит дублирование усилий — и координация начинает шататься. Подробнее: Управление инженерными проектами.

Цена неопределенности

• Дальше — поиск болевых точек. Попросите команду вспомнить случаи за последний месяц, когда было непонятно, кто за что отвечает. Таких эпизодов почти всегда набирается больше, чем кажется на старте.

Матрица RACI

RACI — таблица, которая закрепляет за каждым участником конкретную роль в каждом процессе. Работает она ровно настолько, насколько последовательно и дисциплинированно ею пользуются.

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

• Responsible (Исполнитель) — тот, кто непосредственно делает работу. Исполнителей у одной задачи может быть несколько.
• Accountable (Ответственный) — тот, кто отвечает за результат и принимает ключевые решения. Здесь принципиально: ответственный у задачи только один.
• Consulted (Консультируемый) — те, чьё мнение надо учесть, как правило, эксперты в смежных областях.
• Informed (Информируемый) — те, кого держат в курсе, но чьё мнение для решения не требуется.

Как подступиться: возьмите для начала один процесс — например, найм сотрудника или запуск новой функции продукта — и составьте RACI-матрицу для него. Когда команда поймёт принцип на живом примере, распространить его на остальное будет несложно.

Пример из практики: при запуске новой функции продукта Responsible — разработчик, Accountable — продакт-менеджер, Consulted — дизайнер и аналитик, Informed — руководство и служба поддержки.

Главное ограничение: у каждой задачи ровно один Accountable. Назначьте двоих — и по факту не отвечает никто.

Еженедельные синхронизации

Регулярные встречи команды — инструмент координации. Вся его польза держится на формате. Обычные летучки то и дело расползаются в разбор деталей. Время уходит, а согласованности, ради которой всё затевалось, так и нет.

Рабочий формат еженедельной синхронизации:

• Что планирую (3 минуты на человека): коротко о ключевых задачах на неделю.
• Где нужна помощь (2 минуты на человека): конкретные запросы на поддержку или консультацию.
• Потенциальные пересечения (5 минут на всю группу): обсуждаем задачи, которые могут зацепить работу коллег.

На всё уходит 15–20 минут. Сберегаются часы дублированной работы — выгодный обмен при любом размере команды.

Матрица компетенций

В любой команде есть неформальные эксперты — те, к кому идут за советом по конкретным темам. Сделайте эту экспертизу явной и закрепите её. Тогда станет понятнее, к кому идти за консультацией и за кем последнее слово в спорной ситуации.

Матрица компетенций задаёт три уровня:

• Эксперт — принимает окончательные решения в своей области, консультирует коллег, отвечает за то, чтобы команда росла в этом направлении.
• Практик — сам справляется со стандартными задачами и при необходимости подстрахует эксперта.
• Новичок — осваивает область, работает под присмотром эксперта или практика.

Один и тот же человек вполне может быть экспертом в одной области и новичком в другой. Это нормально — а на практике даже удобно. Больше об этом: Управление компанией.

Прозрачность процесса

Грамотно настроенный инструмент управления проектами снимает вопрос «кто чем занят» и показывает пересечения раньше, чем те выльются в конфликт или лишнюю работу. Что здесь важно:

• Единое информационное пространство: все задачи, их статусы и исполнители видны в одном месте, доступном всей команде.
• Прозрачность загрузки: каждый видит, чем заняты коллеги и насколько они загружены.
• Автоматические уведомления: система сама сообщает заинтересованным об изменениях в задачах, без ручной переписки.
• Простота инструмента: простая система, за которой следят, обходит навороченную, которую половина команды так и не освоила. Толк от инструмента ровно такой, насколько им реально пользуются.

Но даже отлаженные процессы дают немного, если в команде не принято открыто говорить о проблемах. Людям должно быть спокойно признаться: «Я не понимаю, где кончается моя зона ответственности». Иначе никакие структурные инструменты до корня путаницы не доберутся.

Читайте также:

О гибких методах управления проектами читайте в материале Agile-подход к управлению проектами.

О том, как выстроенные процессы повышают эффективность, читайте в статье Рабочий процесс управления проектами: шаги по оптимизации успеха проекта.

Как организовать распределённые команды, разбираем в материале Организация команды для удаленной работы.

Заключение

Команды растут, проекты усложняются — и границы ответственности приходится регулярно пересматривать, а координацию постоянно донастраивать. Нуля пересечений добиваться незачем. Важно, чтобы каждое из них было осознанным, управляемым и работало на общий результат — а не рождалось из нечёткой структуры и решений, принятых в одиночку, без согласования.