Вопрос границ и зон ответственности сам по себе глобальный. Для человека, например, формирование личных границ является этапом взросления и становления личности.
Но если посмотреть на границы в контексте IT-проектов, то окажется, что из-за не самых качественных границ регулярно возникают проблемы. Они приводят к чему угодно: от потери ценных кадров с негативным фидбеком о работе в компании до провала проектов.
Ниже попробую порассуждать, когда с этими проблемами сталкиваются, предложу пример из опыта и вариант фиксации границ зон ответственности.
Когда начинаются проблемы границ
В проектах автоматизации присутствует примерно одинаковый набор функциональных задач. На начальных этапах проекта или в маленьких компаниях и командах есть один-два-три человека, которые делают работу, начиная управлением продукта и маркетингом, заканчивая full stack разработкой. И работают без жалоб, при этом решая вопросы общением.
Со временем наступает ситуация, когда приходится заняться расширением команды, например:
Уровень зрелости решения достигает необходимости повышения качества отдельных функций
Людей перестаёт хватать, чтобы делать функции самостоятельно
Возникает потребность в полноценном выполнении некоторых функций, которые делались по совместительству
И тогда команда сталкивается с проблемами роста:
Слишком много времени начинает уходить на взаимодействие, встречи забивают календарь, а работать некогда
Возникают конфликты и жаркие споры при решении тех или иных вопросов
Одну и ту же работу делают разные люди
Давайте на примере
Достану из чертогов памяти один пример автоматизации, на котором было не всё гладко. Начинался он как любой другой проект. Со стартом проекта выделялась небольшая команда, решение начинало потихоньку развиваться, и дела как-то делались.
С ростом проекта задач становилось больше, что привело и к увеличению команды. И начались общие претензии по качеству работы, а также конкретные жалобы на:
Менеджеров — не делали работу хорошо
Заказчиков — бесконечно меняли требования
Аналитиков — не успевали в срок
Итого напряжение в команде росло, в проекте менялись менеджеры, а сроки соблюдались с большим трудом. А я, как тимлид аналитики, получал негативную обратную связь от падаванов, которые жаловались на процессы и говорили, что «так работать нельзя».
При погружении в проект обнаружилась проблема — слишком много времени уходило на коммуникацию, и при этом регулярно возникали вопросы типа «а кто решил, что делаем именно так?». Эту ситуацию и попробовали решить, зафиксировав границы ролей.
Как можно распределять ответственность
Задача разделения ответственности раскладывается на следующий список подзадач:
Зафиксировать список ролей
Для каждой роли зафиксировать набор функций, за которые она отвечает
Базовым подходом для решения такой задачи можно считать RACI-матрицу. Концептуально список ролей не зафиксирован жестко и может быть различным, но базовыми считаются:
Responsible — Исполнитель, ответственен за некоторый участок работы, который доверен только ему
Accountable — Ответственный, управляет процессом или является его владельцем
Consulted — Эксперт, обладает экспертизой в том или ином вопросе
Informed — Информирующий, обладает информацией по процессу, может косвенно влиять на результат
Кстати, на хабре есть статья «Эффективное распределение ролей посредством RACI матрицы», в которой есть в том числе и пример её использования.
Но если попытаться применить эту модель, то у неё всплывают свои минусы: с одной стороны, слегка избыточна и сложна для построения, с другой — недостаточно атомарна, чтобы явно обозначить набор функций, которыми занимается, например, та же аналитика:
Аналитик работает как “Исполнитель” по своим задачам
Та же аналитика, особенно лид аналитики, “Ответственна” за свои процессы
Аналитик часто “Эксперт” в тех или иных вопросах
Аналитик также “Информирующий” по вопросам взаимодействия внутри команды
Альтернатива
Если всё-таки отталкиваться от функций, то у них есть:
Ответственный — один конкретный специалист или некоторая роль, которая отвечает за финальный результат
Все остальные — в силу своей заинтересованности могут так или иначе влиять на результат
Получается следующее представление границ каждой функции:
Зона ответственности — та часть деятельности, за которую ответственен именно специалист. Чтобы реально что-то менять и чем-то управлять, та или иная функция должна быть именно в этой зоне
Зона влияния — область, которая находится рядом с зоной ответственности специалиста. Здесь специалист может советовать как эксперт или просто о чём-то информировать, задать любой вопрос и предложить любой новый подход, не неся при этом финальной ответственности
Зона смирения — область, в которой нет рычагов влияния. Сюда попадают, если все попытки повлиять на что-то исчерпаны, и больше вариантов нет. Здесь есть две опции — «понять, принять и смириться» или «уйти» из проекта или из компании.
Подход кажется удобным, если список функций и ролей известен. Например, в компаниях, где есть более-менее устоявшиеся процессы. Для каждой функции определяется ответственный, а все остальные роли при наличии желания могут пытаться влиять на выполнение функции и на процессы.
И получается вполне прозрачный механизм. Если хочется что-то изменить, то вариант один — сделать это своей зоной ответственности.
Так что с примером?
Если вернуться к примеру с этими зонами, то:
Проверили, что участники команды понимают существующие роли в проекте
Для каждой роли зафиксировали список функций, за которые эта роль ответственна
Договорились, что остальное — зона влияния, где каждый может что-то пытаться делать, но финальное решение не принимает и ответственность не несёт
Имели три конфликтующие проектные роли — аналитика, проектный менеджмент и заказчик.
Сначала поговорили с аналитиками. Они, согласно предыдущей статье «Аналитик в автоматизации — кто он и чем занимается», специалисты широкого спектра. Поэтому, если упростить, зафиксировали, что аналитика занимается:
Продуктовым анализом
Фиксацией разных требований и ограничений
Формализацией, проектированием и оптимизацией бизнес-процессов
Разработкой моделей данных (ER-диаграмм)
Разработкой различных постановки задач или спецификаций
Дальше менеджеры. Мы жёстко разделили роли аналитики и менеджера. И поэтому в зоне ответственности менеджера остались вполне себе стандартные менеджерские вопросы, на которые заказчик и аналитика могли влиять:
Формирование проектной команды
Организация процессов взаимодействия
Фиксация скоупа проекта и приоритетов задач
Фиксация и отслеживание сроков
Организация работы людей в проекте
Ну а заказчик был определён и зафиксирован как участник, который несёт ответственность за продукт. За ним финальное решение о том, куда пойдёт продукт. Аналитик, как эксперт, влияет на продукт — предлагает новые фичи, рекомендует различные подходы и тенденции.
Что получилось?
Нормально расставленные и зафиксированные границы — штука хорошая. Даже если кто-то один так себе границы соблюдает, остальные участники команды помогают процессу работать верно.
В итоге, пообщавшись и договорившись по задачам, удалось перевести работу в нужное и продуктивное русло:
Прекратилась передача задач и приоритетов напрямую заказчиком в аналитику
Менеджер смог делать свою работу и управлять заказчиком, его бэклогом, сроками и ожиданием
Заказчик получил свои (корректные) рычаги влияния на задачи
Аналитики знают, что должны сделать, если видят проблему и хотят что-то изменить в решении или в процессах
Так же сделали и с другими ролями в проекте, например, с дизайнерами, разработчиками, тестированием. И главное, чтобы границы не ломались, договорились до следующего:
Новеньких сразу обучаем принятым границам между ролями
Поощряем работу в зоне влияния, поощряем эскалацию
На периодических со специалистами встречах собираем обратную связь и, при необходимости, вносим точечные правки
И общий профит
На уровне выше конкретного проекта также есть профит соблюдения общих границ. Например, для нас, как для компании-интегратора:
Упрощается запуск проектов, так как проекты работают по одному шаблону
Проектную команду расширять легче, так как исключается длительное погружение в процессы конкретного проекта
Ротация сотрудников между проектами возможна и работает
Новому человеку проще разобраться, как работает компания
Ясны границы, в которых можно влиять на процессы
Ценность сотрудника для компании не зависит от конкретного проекта
А можно без этого обойтись?
Да, можно и без таких формальных заморочек. Например, в in house, где каждый проект часто уникальная снежинка, или в небольшой команде. Как замечено в одном из комментариев к прошлой статье, в маленьких компаниях часто обходятся без аналитиков. Да и без узких специалистов вообще.
При этом важно понимать, что функции есть всегда. Просто один человек может выполнять функции нескольких ролей. И когда в команду приходит новый человек, особенно если это новая выделенная роль в команде, важно зафиксировать, чем этот человек будет заниматься и какие полномочия ему передаются.
И стоит ещё сказать, что описанный подход к разделению ответственности, наверняка не единственно верный. Сейчас пришли к этому. Может быть, через какое-то время поймём, что здесь тоже всё не так гладко. Но это не значит, что мы откажемся от фиксации функций и от того, чтобы ответственность за них делить между ролями. Просто может быть, что попилим как-то иначе.