Зоны ответственности в проекте

[Kate]

Вопрос границ и зон ответственности сам по себе глобальный. Для человека, например, формирование личных границ является этапом взросления и становления личности.

Но если посмотреть на границы в контексте IT-проектов, то окажется, что из-за не самых качественных границ регулярно возникают проблемы. Они приводят к чему угодно: от потери ценных кадров с негативным фидбеком о работе в компании до провала проектов.

Ниже попробую порассуждать, когда с этими проблемами сталкиваются, предложу пример из опыта и вариант фиксации границ зон ответственности.

Когда начинаются проблемы границ​

В проектах автоматизации присутствует примерно одинаковый набор функциональных задач. На начальных этапах проекта или в маленьких компаниях и командах есть один-два-три человека, которые делают работу, начиная управлением продукта и маркетингом, заканчивая full stack разработкой. И работают без жалоб, при этом решая вопросы общением.

Со временем наступает ситуация, когда приходится заняться расширением команды, например:

• Уровень зрелости решения достигает необходимости повышения качества отдельных функций
• Людей перестаёт хватать, чтобы делать функции самостоятельно
• Возникает потребность в полноценном выполнении некоторых функций, которые делались по совместительству

И тогда команда сталкивается с проблемами роста:

• Слишком много времени начинает уходить на взаимодействие, встречи забивают календарь, а работать некогда
• Возникают конфликты и жаркие споры при решении тех или иных вопросов
• Одну и ту же работу делают разные люди

Давайте на примере​

Достану из чертогов памяти один пример автоматизации, на котором было не всё гладко. Начинался он как любой другой проект. Со стартом проекта выделялась небольшая команда, решение начинало потихоньку развиваться, и дела как-то делались.

С ростом проекта задач становилось больше, что привело и к увеличению команды. И начались общие претензии по качеству работы, а также конкретные жалобы на:

• Менеджеров — не делали работу хорошо
• Заказчиков — бесконечно меняли требования
• Аналитиков — не успевали в срок

Круговорот недовольства в проекте
Итого напряжение в команде росло, в проекте менялись менеджеры, а сроки соблюдались с большим трудом. А я, как тимлид аналитики, получал негативную обратную связь от падаванов, которые жаловались на процессы и говорили, что «так работать нельзя».

При погружении в проект обнаружилась проблема — слишком много времени уходило на коммуникацию, и при этом регулярно возникали вопросы типа «а кто решил, что делаем именно так?». Эту ситуацию и попробовали решить, зафиксировав границы ролей.

Как можно распределять ответственность​

Задача разделения ответственности раскладывается на следующий список подзадач:

• Зафиксировать список ролей
• Для каждой роли зафиксировать набор функций, за которые она отвечает

Базовым подходом для решения такой задачи можно считать RACI-матрицу. Концептуально список ролей не зафиксирован жестко и может быть различным, но базовыми считаются:

• Responsible — Исполнитель, ответственен за некоторый участок работы, который доверен только ему
• Accountable — Ответственный, управляет процессом или является его владельцем
• Consulted — Эксперт, обладает экспертизой в том или ином вопросе
• Informed — Информирующий, обладает информацией по процессу, может косвенно влиять на результат

Кстати, на хабре есть статья «Эффективное распределение ролей посредством RACI матрицы», в которой есть в том числе и пример её использования.

Но если попытаться применить эту модель, то у неё всплывают свои минусы: с одной стороны, слегка избыточна и сложна для построения, с другой — недостаточно атомарна, чтобы явно обозначить набор функций, которыми занимается, например, та же аналитика:

• Аналитик работает как “Исполнитель” по своим задачам
• Та же аналитика, особенно лид аналитики, “Ответственна” за свои процессы
• Аналитик часто “Эксперт” в тех или иных вопросах
• Аналитик также “Информирующий” по вопросам взаимодействия внутри команды

Альтернатива​

Если всё-таки отталкиваться от функций, то у них есть:

• Ответственный — один конкретный специалист или некоторая роль, которая отвечает за финальный результат
• Все остальные — в силу своей заинтересованности могут так или иначе влиять на результат

Получается следующее представление границ каждой функции:

Круги ответственности

• Зона ответственности — та часть деятельности, за которую ответственен именно специалист. Чтобы реально что-то менять и чем-то управлять, та или иная функция должна быть именно в этой зоне
• Зона влияния — область, которая находится рядом с зоной ответственности специалиста. Здесь специалист может советовать как эксперт или просто о чём-то информировать, задать любой вопрос и предложить любой новый подход, не неся при этом финальной ответственности
• Зона смирения — область, в которой нет рычагов влияния. Сюда попадают, если все попытки повлиять на что-то исчерпаны, и больше вариантов нет. Здесь есть две опции — «понять, принять и смириться» или «уйти» из проекта или из компании.

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

И получается вполне прозрачный механизм. Если хочется что-то изменить, то вариант один — сделать это своей зоной ответственности.

Так что с примером?​

Если вернуться к примеру с этими зонами, то:

1. Проверили, что участники команды понимают существующие роли в проекте
2. Для каждой роли зафиксировали список функций, за которые эта роль ответственна
3. Договорились, что остальное — зона влияния, где каждый может что-то пытаться делать, но финальное решение не принимает и ответственность не несёт

Имели три конфликтующие проектные роли — аналитика, проектный менеджмент и заказчик.

Сначала поговорили с аналитиками. Они, согласно предыдущей статье «Аналитик в автоматизации — кто он и чем занимается», специалисты широкого спектра. Поэтому, если упростить, зафиксировали, что аналитика занимается:

• Продуктовым анализом
• Фиксацией разных требований и ограничений
• Формализацией, проектированием и оптимизацией бизнес-процессов
• Разработкой моделей данных (ER-диаграмм)
• Разработкой различных постановки задач или спецификаций

Дальше менеджеры. Мы жёстко разделили роли аналитики и менеджера. И поэтому в зоне ответственности менеджера остались вполне себе стандартные менеджерские вопросы, на которые заказчик и аналитика могли влиять:

• Формирование проектной команды
• Организация процессов взаимодействия
• Фиксация скоупа проекта и приоритетов задач
• Фиксация и отслеживание сроков
• Организация работы людей в проекте

Ну а заказчик был определён и зафиксирован как участник, который несёт ответственность за продукт. За ним финальное решение о том, куда пойдёт продукт. Аналитик, как эксперт, влияет на продукт — предлагает новые фичи, рекомендует различные подходы и тенденции.

Что получилось?​

Нормально расставленные и зафиксированные границы — штука хорошая. Даже если кто-то один так себе границы соблюдает, остальные участники команды помогают процессу работать верно.

В итоге, пообщавшись и договорившись по задачам, удалось перевести работу в нужное и продуктивное русло:

• Прекратилась передача задач и приоритетов напрямую заказчиком в аналитику
• Менеджер смог делать свою работу и управлять заказчиком, его бэклогом, сроками и ожиданием
• Заказчик получил свои (корректные) рычаги влияния на задачи
• Аналитики знают, что должны сделать, если видят проблему и хотят что-то изменить в решении или в процессах

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

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

И общий профит​

На уровне выше конкретного проекта также есть профит соблюдения общих границ. Например, для нас, как для компании-интегратора:

• Упрощается запуск проектов, так как проекты работают по одному шаблону
• Проектную команду расширять легче, так как исключается длительное погружение в процессы конкретного проекта
• Ротация сотрудников между проектами возможна и работает
• Новому человеку проще разобраться, как работает компания
• Ясны границы, в которых можно влиять на процессы
• Ценность сотрудника для компании не зависит от конкретного проекта

А можно без этого обойтись?​

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

При этом важно понимать, что функции есть всегда. Просто один человек может выполнять функции нескольких ролей. И когда в команду приходит новый человек, особенно если это новая выделенная роль в команде, важно зафиксировать, чем этот человек будет заниматься и какие полномочия ему передаются.

И стоит ещё сказать, что описанный подход к разделению ответственности, наверняка не единственно верный. Сейчас пришли к этому. Может быть, через какое-то время поймём, что здесь тоже всё не так гладко. Но это не значит, что мы откажемся от фиксации функций и от того, чтобы ответственность за них делить между ролями. Просто может быть, что попилим как-то иначе.


Источник статьи: https://habr.com/ru/post/560260/