Ох уж эти зоны ответственности! Мой опыт показывает, что в неумелых руках это инструмент поиска виноватых и их наказания. Менеджмент так неумело им пользуется, что со временем уже никто не хочет лишний раз ничего делать: может оказаться, что твоё действие вошло в зону, где включается система демотивации, и за инициативу, попытку что-то исправить тебя будут не хвалить, а ругать и лишать премии.
Знаю я одну компанию, где за исправление инцидента можно было лишиться премии или части зарплаты, ведь при исправлении и релизе на прод находили твои логи и назначали тебя виновником ошибки. Пару таких косяков в квартал — и прощай, премия! В итоге люди боялись как огня что-то исправлять, и продукт становился хуже и хуже с каждым днём. Порочная система.
На самом же деле понятные и прозрачные зоны ответственности в компании — это отличный инструмент для поиска точек роста и подсвечивания недоработок в ваших процессах.
Давайте попробуем вместе разобраться, где чья зона ответственности и что делать, если вы не знаете, как найти свою.
Что такое зона ответственности и почему её полезно знать
Зона ответственности в работе — это функции, находящиеся под контролем сотрудника: то, что он должен делать или не должен, за что отвечает и за что нет.
Например, в зоне ответственности сотрудника службы поддержки могут находиться реагирование и диагностика инцидентов, которые поступают из систем мониторинга продакшн контура, в виде SD от первой линии или обратной связи от клиентов через чат-бота, но исправление инцидентов — это уже зона ответственности команд разработки.
Тут я, конечно, привёл очень простой пример, но обычно дальше начинается жесть. Одна команда говорит: «За этот функционал отвечает другая команда. Пускай она фиксит свои баги». Дальше команда поддержки приходит ко второй системе, а та говорит, что и они тут ни при чём: «Мы уже давно не поддерживаем этот сервис. Это не к нам».
И вот бедный сотрудник поддержки в тупике, так как вроде у всех в зоне ответственности есть тема с bug fixing, но что-то никто не спешит их делать, а по итогу страдают клиенты и компания. Такая динамо-машина может продолжаться неделями, а то и месяцами, пока информация не дойдёт до руководителей высшего звена. Они раздадут пиздюлей заставят команды фиксить баги, чего бы это ни стоило сотрудникам.
В такой маленькой истории сокрыто много проблем, которые потом могут стать ПРОБЛЕМИЩАМИ!
- Сотрудник поддержки не видит ценность своей работы. Он проводит глубокий анализ инцидента, чтобы командам разработки было проще понять причины проблемы, а по итогу они его динамят и нос воротят.
- Поддержка начинает ругаться с командами, которые не берут в работу баги. При этом на поддержку давят другие руководители + ещё SLA и KPI всякие.
- Все всех начинают потихоньку ненавидеть, обсуждать друг друга за спиной, а потом и не за спиной.
- Уровень токсичности продолжает нарастать и люди начинают увольняться, забирая с собой экспертизу, уникальные знания и опыт.
- Клиент, а может и клиенты, страдают днями, неделями, месяцами из-за того, что сотрудники не могут договориться, кто будет фиксить баги.
Всё это из-за непонятной и непрозрачной для сотрудников зоны ответственности. Сказать: «Все команды разработки должны в первую очередь уделять время багам», — не работает. Начинается делёжка своих и чужих, и колесо сансары делает ещё один оборот.
Как можно разрулить описанную выше ситуацию с сотрудником поддержки
Давайте сначала закроем предыдущую тему и потом пойдём дальше. Не буду перебирать все варианты, которые крутятся в голове, а выскажу самый, на мой взгляд, лаконичный выход из ситуации: сделать ответственным за приоритизацию и распределение багов владельца продукта. Если баг технический, то архитектора и в крайнем случае CTO (технического директора).
Чтобы сотрудник поддержки не ходил по всем командам и их тимлидам, не упрашивал взять баг на исправление, в зоне ответственности продакта должно быть явно прописано — он отвечает за стабильность функциональности продукта и клиентский опыт.
Почему продакт? Если пользователь не может воспользоваться какой-то функцией продукта или она работает не так, как задумано/ожидается, — это головная боль продакта, чтобы в его продукте всё было хорошо. К тому же обычно именно владельцы продукта управляют бэклогами команд разработки и могут самостоятельно продвинуть свои фичи и повысить приоритет инцидентов, ну или в крайнем случае передоговориться с другими продактами.
Бинго! Не благодарите. На самом деле было бы неплохо поблагодарить)
Зачем устанавливать зоны ответственности, если это такая жесть
Чётко определённая зона ответственности помогает регламентировать отношения между сотрудниками и повысить эффективность работы.
- Точка опоры в сложных ситуациях. Когда вы не понимаете, к кому идти или кто должен подключиться к решению вопроса, можно посмотреть, в чьей зоне ответственности решение такого типа задач. Вам не придётся тратить часы и дни в поисках помощи и идти всё выше и выше, пока не доберётесь до какого-нибудь генерального директора, если зоны будут хорошо описаны и лежать в доступном и очевидном месте.
- Увеличение свободы в принятии решений и снижение микроменеджмента. Например, мы говорим о зоне ответственности для менеджера проектов. Описав его зоны ответственности, мы даём ему много свободы в том, как решать задачи, общаться с клиентами и обеспечивать высокое качество в своей зоне. Конечно, повышается уровень абстракции, но и места для творчества и идей становится больше.
- Повышение инициативности сотрудников. Не всё учтено в должностных инструкциях, ведь описание каждого шага займёт 100500+ листов, и всё равно невозможно предусмотреть все сценарии. Через зоны ответственности можно прививать чувство единства с продуктом и компанией: теперь человек отвечает за свои действия, результат или его отсутствие.
- Выдача полномочий в принятии решений. Если мы понимаем зоны ответственности сотрудников, то можем дать им права, доступы, протекцию делать всё необходимое для выполнения их задач в оговорённых рамках.
- Быстрые и формализованные ответы на вопросы «Кто виноват?» и «Что делать?». Мы понимаем зоны ответственности, поэтому можем восстановить хронологию событий: кто какие решения принимал и как происходило развитие проблемы. Понять, на каком этапе было принято неверное решение, становится проще. Конечно, виноватых искать — гиблое дело. Лучше подумать о том, как пересобрать процесс, чтобы такие ошибки больше не повторялись.
Что делаеть, если вы не понимаете свою зону ответственности или зону ответственности вашей команды
Часто бывает непонятно, с чего начать. Это нормально. Главное, не переживать и сделать первый шаг в общении вокруг этой темы. К сожалению, без коммуникаций с этой задачей разобраться не получится. Так что бонусом подкачаете soft skills.
Если вы руководитель:
- Поговорить с руководителем выше, если он у вас есть, и обсудить, какие у него зоны ответственности и какие должны быть у вас.
- Узнать у коллег, которые находятся на схожих должностях, что входит в их зоны ответственности, и составить из их ответов свою версию.
- Обсудить со своими подчинёнными, какая у вас зона ответственности и что вы ожидаете от них. Попросить сказать, что команда ожидает от вас. В таком обсуждении вы сможете найти границы, откуда можно будет думать дальше.
- Попросить помощи у ментора или коуча, чтобы он с вами проработал эту тему.
- Найти на рынке (неважно какой страны) человека с похожей на вашу ролью или должностью, договориться с ним о встрече или созвоне. Как вариант — купить его время и попросить рассказать про его зоны ответственности и чем он ежедневно занят.
- Можно ещё опубликовать пост в соцсетях — возможно, кто-то увидит и в комментах напишет свои мысли. Также можно зайти в профильное сообщество и попросить там помощи.
Если вы функциональный сотрудник:
- Проговорить свои зоны ответственности на собеседовании с HR и потом с командой или руководителем на фит-интервью.
- Обсудить с руководителем перед выходом на работу или до начала работы в команде.
- Поговорить с командой в первые дни работы, чтобы ребята понимали, какие, вам кажется, у вас зоны ответственности, какие у них и где возможны конфликты интересов.
- Посмотреть регламенты на порталах и базах знаний компании, там тоже может быть описано, какая команда или роль за что отвечает.
А если всё совсем плохо и я не знаю, с чего начать?
- Опять же посмотреть регламенты на порталах и базах знаний компании.
- Поискать в интернете, что ожидают от вашей должности или роли: изучить статьи, YouTube, LinkedIn, сообщества в telegram.
- Узнать у друзей или попросить друзей спросить у их коллег.
- Спросить у себя: «Что от меня могут ожидать? Какая у меня зона ответственности?»
Как фиксировать зоны ответственности
Фиксация — задача не из лёгких. Мой опыт говорит, что это лишь вопрос времени, когда зоны ответственности снова начнут расплываться. Но мы можем оттянуть этот момент рядом мер.
Вот мои мысли по поводу закрепления:
- Просто устно договориться и пожать руки. Этого бывает достаточно на первых порах. Если люди начнут забывать, что вы о чём-то договорились, то переходим к следующему пункту.
- Написать в рабочем мессенджере или в почте. Уже более официальный вариант. Если начнутся проблемы, можно поднять переписку и напомнить о договорённостях.
- Оформить как регламент или устав и запросить согласование. Тяжелая бюрократическая артиллерия. Высечь договорённости на бумаге, но будет ли её кто-то читать и опираться в работе… Это большой вопрос.
- Автоматизировать принятия решений: уведомления, программное обеспечение, алгоритмы принятия решений. Пускай «скользкие» моменты решает робот, а не люди.
- Визуализировать работу. Сделать её максимально прозрачной и понятной для людей, а «скользкие» моменты автоматизировать. Здесь вам могут помочь онлайн-доски, CRM-системы и прочие инструменты.
Что хочется, чтобы вы сделали после прочтения этой статьи
Как минимум задумались, а не требуют ли ваши зоны ответственности checkup (а) — какие они сейчас, где заканчиваются ваши и начинаются других коллег, не устарели и не потеряли ли они актуальности.
🎃 Не всё чем я занимаюсь попадает на сайт. В моём telegram-канале «Доставка ценности» ты сможешь следить за публикацией новых статей, кейсов, видео, анонсов вебинаров, мастер-классов и мыслями на разные темы. Так же в комментариях можно поделиться своим опытом, спросить совета у коллег.