Что такое зона ответственности
Прежде всего важно различать понятия ролей и зон ответственности каждого из партнеров. Роль — функция партнера в компании. Существует три уровня ролей:
- Владелец. Решает вопросы, связанные со стратегическим развитием компании: анализ рынка, создание новых продуктов, привлечение инвестиций.
- Руководитель (менеджер, управленец). Ставит задачи, контролирует их выполнение, нанимает и увольняет сотрудников, работает с командой. Владелец «добывает» деньги, а управленец должен грамотно их потратить — реализовать бюджет.
- Эксперт (исполнитель). Отвечает за непосредственное выполнение задач, участвует в переговорах.
Об этой градации стоит помнить, так как, когда партнеры высказывают друг другу претензии, скажем, о недостаточной включенности одного в работу, то важно определить, в какой роли, на каком уровне каждый из них находится.
Например, в начинающей дизайн-студии один партнер отвечает за выпуск рекламы, а второй — за дизайн. Тот, кто выпускает рекламу, говорит дизайнеру: «Мы до сих пор не сдали макеты, ты нарушил срок сдачи на месяц. Я жду их от тебя». В этом случае партнер в роли эксперта предъявляет претензию партнеру с такой же ролью, на том же уровне.
Единственное решение такого конфликта — переговоры о смене роли. Если же один партнер (эксперт) подчиняется другому (управленцу), то второй вправе уволить партнера с исполнительской роли.
Зоны ответственности — более широкое понятие, которое обозначает все те области, за результаты которых отвечает один из партнеров. Например, привлекает инвестиции, руководит отделом маркетинга и участвует в ключевых продажах. Зоны ответственности меняются редко, а вот роли — довольно часто. А еще есть зоны внимания: они предполагают участие в решении задач, но исключают ответственность за результат.
Когда нужно определить зоны ответственности и как это сделать
Если у партнеров нет совместного опыта работы, необходимо дать друг другу тестовый период, — несколько месяцев, например, — чтобы понять, комфортно ли работать в тандеме. Важно договориться, что каждый может в любой момент выйти из этого союза. Необязательно сразу планировать что-то крупное, достаточно создать модель проекта, организовать что-то совместно или же поработать над одной конкретной задачей.
Если все довольны работой и хотят продолжать, то нужно перейти к переговорам о зонах ответственности. Их нужно обговаривать и прописывать в начале бизнес-партнерства, а потом регулярно актуализировать список.
Многие это делают интуитивно, например, решают, что один отвечает за продажи, другой — за продукт, и начинают работать. Однако это не совсем точное распределение, так как есть пересекающиеся области, которые выходят за рамки «продаж» и «продукта». И на этих пограничных зонах будут возникать конфликты из-за путаницы зон ответственности и зон внимания.
Читайте по теме:
Есть хорошее упражнение, чтобы определить зоны ответственности и убрать расхождения в их понимании: партнеры засекают одну минуту, за это время один из них пишет свои зоны ответственности в проекте. Остальные тоже пишут зоны ответственности первого, а затем результаты сравниваются. И это нужно проделать с каждым партнером.
Таким образом вырисовывается общая картина понимания зон ответственности в партнерстве. На ее основе необходимо скорректировать или актуализировать перечень.
При этом важно начинать формулировку с глагола или отглагольного существительного. Неверно: «бюджет расходов и доходов». Верно: «утверждение/контроль/подготовка отчета бюджета расходов и доходов». Как только в списке появляется глагол, сразу понятен желаемый результат работы каждого.
Соответственно, партнеры лучше понимают распределение обязанностей между друг другом. В процессе сотрудничества будет возникать гораздо меньше недопониманий и конфликтов.
Сколько должно быть партнеров
Есть мнение, что три партнера лучше, чем два — при решении спорного вопроса третий поможет рассудить. На самом деле, добавление каждого нового человека увеличивает хаос и затрудняет принятие решений. Если действует правило, что «решает большинство» (оно губительное, на мой взгляд), то рано или поздно партнерство из трех человек может превратиться в политические игры по переманиванию третьего на свою сторону.
Как тогда действовать? Например, финальное решение будет принимать человек, в чьей зоне ответственности лежит проблема. Если зоны компетенций пересекаются, то последнее слово за генеральным директором — тем, кто отвечает за финансовый результат. Очень небольшое число вопросов (продажа доли, привлечение нового партнера) должно решаться партнерами вместе, при этом 100% голосов должно быть на одной стороне.
Пример неудачного расширения команды: есть два партнера, которые часто не могут договориться. Они решают подключить к бизнес-процессам третьего, но в итоге начинают проецировать свои недопонимания на новенького, пытаясь решить проблемы через посредника.
Это явление в психологической терминологии называется триангуляция — когда двое не решают проблему друг друга, а пытаются найти третьего, на которого начинают опираться. В случаях, когда два совладельца понимают, что их компетенций не хватает для развития компании, добавление третьего действительно может пойти на пользу. Но чаще всего третьему необязательно становится партнером, а можно быть наемным сотрудником.
Фиксируем зоны ответственности
Договоренности на словах — это отсутствие договоренностей. Любое незаписанное соглашение имеет две особенности: оно со временем забывается и интерпретируется по-другому. Для того чтобы зоны ответственности соблюдались, а роли выполнялись, необходимо письменно отражать их в документе.
Название не так важно, это может быть «партнерское соглашение», «партнерский кодекс». Главное, чтобы все зоны ответственности были описаны конкретно и поставлены подписи каждого партнера. Подписывая документ, человек чувствует ответственность за свою часть работы. К нему следует возвращаться в случае разногласия.
Как только зоны ответственности или роли в союзе поменялись, не забудьте обновить документ и подписать еще раз.
Чек-лист идеального бизнес-партнерства
1. Все зоны ответственности распределены между партнерами
Не должно оставаться «серой», никем не занятой зоны. При расширении деятельности компании необходимо распределить новые зоны между собой и записать их в документ.
2. Все пункты из партнерского соглашения выполняются
Если хотя бы один пункт не соблюдается, то создается ощущение их необязательности. Какие-то задачи стали не актуальны? Вычеркните их из соглашения и добавьте другие.
3. Прописаны ценности работы компании
Один результат можно получить разными методами. Для каждого партнера этические границы сильно разнятся. Важно заранее обговорить основные ценности компании.
4. Одно явление означает одно и то же для всех партнеров
Часто конфликт происходит тогда, когда люди называют одно явление разными словами. Или наоборот, одним словом называют разные явления.
Например, один под «коммуникацией» может иметь в виду развитие социальных сетей, другой — работу над корпоративным стилем компании, брендбуком, айдентикой, третий — контроль за общением в коллективе, поддержанием команды. Такие недопонимания могут возникать даже у опытных партнеров, поэтому в процессе работы важно всегда переспрашивать и убеждаться, что понятийный аппарат у всех один.
5. Прозрачная мотивация
Никакие штрафы, санкции не работают. Партнеры должны договориться, что конкретно будет их мотивировать, какая у бизнеса цель.
6. Обратная связь
Иногда партнеры договариваются о том, что они не дают друг другу обратную связь, и им это подходит. Однако в большинстве случаев без конструктивной критики крайне тяжело развиваться. Главное — давать обратную связь в процессе работы, а не после результата.
Чтобы эффект от бизнес-партнерства был положительным и приносил финансовый успех, важно выделять время на разговоры о текущих зонах ответственности и ролях, так как они могут меняться. Такие переговоры можно проводить самостоятельно или с помощью посредника, который не занимает ничью сторону.
Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!
Разграничение зон ответственности сотрудника
Менеджер или руководитель отдела должен уметь правильно ставить задачи участникам проекта. Распределение ролей между членами команды позволяет быстро получать результаты и избежать конфликтов. Прочитав статью, вы узнаете, что такое зона ответственности сотрудника и как можно распределить роли при работе над проектом.
Что такое зона ответственности
Зона ответственности в менеджменте — обособленный процесс, за исполнение которого отвечает конкретный сотрудник компании. У специалиста есть необходимые инструменты для выполнения работы. Компетенция работника позволяет выполнять поставленные цели, контролировать сроки сдачи отчетности и самостоятельно решать возникающие проблемы. За распределение функций в коллективе отвечают менеджер проекта и руководитель отдела.
Типы ответственности
Есть несколько классификаций зон ответственности. По первой классификации ответственность бывает личной и групповой. В одном случае за выполнение работы отвечает сотрудник, во втором случае достижение цели зависит от действий нескольких участников команды.
Вторая классификация показывает степень влияния:
- зона ответственности;
- зона влияния;
- зона смирения.
Зона ответственности — это функции, находящиеся под контролем. Специалист выполняет работу и отвечает за результат.
Зона влияния — область, где сотрудник является консультантом, проверяет сделанную работу или участвует в голосовании при принятии решений. Работник влияет на реализацию процесса, но не является ответственным за выполнение задания.
Зона смирения — область, где у исполнителя нет рычагов влияния на принятие решений. Часто это направления, которыми занимается другой отдел компании.
Преимущества установки границ
Правильная организация деятельности позволяет руководству эффективно управлять командой, а сотрудникам быстрее выполнять работу:
- Упрощается реализация проектов, потому что команда работает по шаблону.
- Возможна ротация исполнителей в коллективах, занимающихся разными проектами.
- Новые исполнители сразу понимают правила работы и роли участников группы.
- Вероятность возникновения конфликтов в коллективе становится минимальной.
- Увеличивается скорость принятия решений при разработке проектов.
- Руководство видит, чем заняты работники, и получает прозрачную отчетность.
- Становится легко установить ответственных в провале задания или проекта.
- Менеджер может разработать эффективную систему мотивации персонала.
При отсутствии четких границ появляются проблемы: от конфликта внутри команды до увольнения ценных кадров. Поэтому разграничить функции исполнителей рекомендуется до начала работы.
Матрица ответственности сотрудников
Эффективным инструментом для организации деятельности команды является матрица RACI. В ней показаны возможности участников команды. Матрица RACI подходит для любого направления бизнеса. Она наглядно демонстрирует, какими функциями занимается работник, и за что отвечает.
Роли участников команды в матрице RACI:
- Исполнитель (Responsible). Отвечает за выполнение отдельной задачи. У каждой функции, необходимой для реализации проекта, должен быть исполнитель. У масштабной функции может быть несколько исполнителей. Но лучше выделить подзадачи и распределить между работниками.
- Ответственный (Accountable). Управляет проектом или является его владельцем. Получает отчеты исполнителей, принимает работу или просит внести правки. Может утверждать или отклонять предложения по улучшению проекта. Роли ответственного и исполнителя может выполнять один работник.
- Эксперт (Consulted). Проводит консультации по конкретным вопросам. Помогает наладить взаимодействие подразделений внутри компании, согласовывать выполненную работу. Не занимается реализацией функции, а обеспечивает поддержку исполнителей.
- Информируемый (Informed). Получает информацию о результатах работы команды. Часто в матрице информируемый является исполнителем следующего этапа реализации проекта.
Матрица RACI отображает связи участников команды. В схему можно добавлять дополнительные роли. Делать это рекомендуется при необходимости и не усложнять управленческую структуру.
VS: подтверждающий (Verifier) и подписывающий (Signatory). Первый проверяет, соответствует ли работа установленному стандарту, второй согласовывает отчет. Обе роли может выполнять один человек.
Q: контроллер качества (Quality). Проверят качество готового продукта не только по техническим стандартам, но и по удобству для пользователей или другим критериям.
S: поддержка (Support). Помогает базовому исполнителю выполнить задание. Например, обучает стажера или подменяет работника при болезни.
Как распределить ответственность
Построить матрицу RACI необходимо до начала работы над проектом. Визуализировать матрицу можно таблицей, где горизонтальные строки — задачи проекта, а вертикальные столбцы — имена участников команды. Буква в ячейке на пересечении столбца и строки показывает роль участника команды при разработке.
Этапы установки границ по стандарту RACI:
- Определение целей проекта и требований к качеству работы.
- Составление списка функций, необходимых для запуска продукта.
- Распределение ролей среди участников команды.
- Обсуждение и утверждение составленной матрицы.
- Проведение инструктажа участников коллектива.
- Периодический контроль установленных границ.
Создание матрицы начинается с составления списка заданий. Итоговая таблица не должна быть перегруженной. Не стоит указывать очевидные цели, например, «присутствовать на совещаниях».
Цели прописываются в первом столбце. Шапка таблицы отводится под перечисление должностей и имен работников компании. При обсуждении проекта таблица заполняется: на пересечении строчек и столбцов появляются буквы, показывающие степень ответственности.
Ошибки менеджеров и руководителей
Структура матрицы RACI помогает проверить, правильно ли разделены сферы влияния. Следует посмотреть на заполнение таблицы, чтобы увидеть, были ли допущены ошибки при планировании работы.
Если участник команды становится исполнителем ® нескольких задач, необходимо проверить, насколько они масштабны, и не будет ли работник перегружен. Желательно снять часть ролей с исполнителя и передать коллегам.
Если на одно задание назначено много ответственных (А), при проверке работы часто возникают сложности. Мнения проверяющих могут не совпадать, что приводит к возникновению конфликтов и затягиванию сроков. Желательно сделать так, чтобы у процесса был один ответственный.
Участник команды может совмещать R и A функцию при выполнении работы. Но рекомендуется сделать так, чтобы эти буквы попадали в одну ячейку не часто. Иначе участники коллектива будут перегружены и не смогут оперативно реагировать на нестандартные ситуации.
Когда у работника нет ни одной R или A функции, следует подумать, нужен ли человек в команде, и можно ли оптимизировать штат.
Не следует назначать много консультантов © и информируемых (I) на задание. Коммуникации по заданиям не должны отвлекать работников от базовых функций. Избыточное число согласований затягивает сроки сдачи проекта.
Оформление документов
Разграничение ответственности сотрудников компании можно закрепить на бумаге. Руководитель вправе издать Приказ о распределении обязанности, где перечислены ФИО работников и указаны задания, которые они выполняют.
Если функция работника остается прежней, и Приказ только уточняет его полномочия, то согласия не требуется. Когда после издания Приказа должностные полномочия меняются, следует получить письменное согласие работника и заключить дополнительное соглашение.
Разделения зон ответственности помогает сотрудникам четко осознать границы своего влияния на реализацию проекта и сосредоточиться на главных задачах. Руководитель понимает, как работает система и кто отвечает за каждый процесс. Разделение обязанностей помогает команде быстро и эффективно выполнять работу, что позволяет вывести бизнес на новый уровень.
Зоны ответственности в проекте
Вопрос границ и зон ответственности сам по себе глобальный. Для человека, например, формирование личных границ является этапом взросления и становления личности.
Но если посмотреть на границы в контексте IT-проектов, то окажется, что из-за не самых качественных границ регулярно возникают проблемы. Они приводят к чему угодно: от потери ценных кадров с негативным фидбеком о работе в компании до провала проектов.
Ниже попробую порассуждать, когда с этими проблемами сталкиваются, предложу пример из опыта и вариант фиксации границ зон ответственности.
Когда начинаются проблемы границ
В проектах автоматизации присутствует примерно одинаковый набор функциональных задач. На начальных этапах проекта или в маленьких компаниях и командах есть один-два-три человека, которые делают работу, начиная управлением продукта и маркетингом, заканчивая full stack разработкой. И работают без жалоб, при этом решая вопросы общением.
Со временем наступает ситуация, когда приходится заняться расширением команды, например:
Уровень зрелости решения достигает необходимости повышения качества отдельных функций
Людей перестаёт хватать, чтобы делать функции самостоятельно
Возникает потребность в полноценном выполнении некоторых функций, которые делались по совместительству
И тогда команда сталкивается с проблемами роста:
Слишком много времени начинает уходить на взаимодействие, встречи забивают календарь, а работать некогда
Возникают конфликты и жаркие споры при решении тех или иных вопросов
Одну и ту же работу делают разные люди
Давайте на примере
Достану из чертогов памяти один пример автоматизации, на котором было не всё гладко. Начинался он как любой другой проект. Со стартом проекта выделялась небольшая команда, решение начинало потихоньку развиваться, и дела как-то делались.
С ростом проекта задач становилось больше, что привело и к увеличению команды. И начались общие претензии по качеству работы, а также конкретные жалобы на:
Менеджеров — не делали работу хорошо
Заказчиков — бесконечно меняли требования
Аналитиков — не успевали в срок
Итого напряжение в команде росло, в проекте менялись менеджеры, а сроки соблюдались с большим трудом. А я, как тимлид аналитики, получал негативную обратную связь от падаванов, которые жаловались на процессы и говорили, что «так работать нельзя».
При погружении в проект обнаружилась проблема — слишком много времени уходило на коммуникацию, и при этом регулярно возникали вопросы типа «а кто решил, что делаем именно так?». Эту ситуацию и попробовали решить, зафиксировав границы ролей.
Как можно распределять ответственность
Задача разделения ответственности раскладывается на следующий список подзадач:
Зафиксировать список ролей
Для каждой роли зафиксировать набор функций, за которые она отвечает
Базовым подходом для решения такой задачи можно считать RACI-матрицу. Концептуально список ролей не зафиксирован жестко и может быть различным, но базовыми считаются:
Responsible — Исполнитель, ответственен за некоторый участок работы, который доверен только ему
Accountable — Ответственный, управляет процессом или является его владельцем
Consulted — Эксперт, обладает экспертизой в том или ином вопросе
Informed — Информирующий, обладает информацией по процессу, может косвенно влиять на результат
Но если попытаться применить эту модель, то у неё всплывают свои минусы: с одной стороны, слегка избыточна и сложна для построения, с другой — недостаточно атомарна, чтобы явно обозначить набор функций, которыми занимается, например, та же аналитика:
Аналитик работает как “Исполнитель” по своим задачам
Та же аналитика, особенно лид аналитики, “Ответственна” за свои процессы
Аналитик часто “Эксперт” в тех или иных вопросах
Аналитик также “Информирующий” по вопросам взаимодействия внутри команды
Альтернатива
Если всё-таки отталкиваться от функций, то у них есть:
Ответственный — один конкретный специалист или некоторая роль, которая отвечает за финальный результат
Все остальные — в силу своей заинтересованности могут так или иначе влиять на результат
Получается следующее представление границ каждой функции:
Зона ответственности — та часть деятельности, за которую ответственен именно специалист. Чтобы реально что-то менять и чем-то управлять, та или иная функция должна быть именно в этой зоне
Зона влияния — область, которая находится рядом с зоной ответственности специалиста. Здесь специалист может советовать как эксперт или просто о чём-то информировать, задать любой вопрос и предложить любой новый подход, не неся при этом финальной ответственности
Зона смирения — область, в которой нет рычагов влияния. Сюда попадают, если все попытки повлиять на что-то исчерпаны, и больше вариантов нет. Здесь есть две опции — «понять, принять и смириться» или «уйти» из проекта или из компании.
Подход кажется удобным, если список функций и ролей известен. Например, в компаниях, где есть более-менее устоявшиеся процессы. Для каждой функции определяется ответственный, а все остальные роли при наличии желания могут пытаться влиять на выполнение функции и на процессы.
И получается вполне прозрачный механизм. Если хочется что-то изменить, то вариант один — сделать это своей зоной ответственности.
Так что с примером?
Если вернуться к примеру с этими зонами, то:
Проверили, что участники команды понимают существующие роли в проекте
Для каждой роли зафиксировали список функций, за которые эта роль ответственна
Договорились, что остальное — зона влияния, где каждый может что-то пытаться делать, но финальное решение не принимает и ответственность не несёт
Имели три конфликтующие проектные роли — аналитика, проектный менеджмент и заказчик.
Сначала поговорили с аналитиками. Они, согласно предыдущей статье «Аналитик в автоматизации — кто он и чем занимается», специалисты широкого спектра. Поэтому, если упростить, зафиксировали, что аналитика занимается:
Фиксацией разных требований и ограничений
Формализацией, проектированием и оптимизацией бизнес-процессов
Разработкой моделей данных (ER-диаграмм)
Разработкой различных постановки задач или спецификаций
Дальше менеджеры. Мы жёстко разделили роли аналитики и менеджера. И поэтому в зоне ответственности менеджера остались вполне себе стандартные менеджерские вопросы, на которые заказчик и аналитика могли влиять:
Формирование проектной команды
Организация процессов взаимодействия
Фиксация скоупа проекта и приоритетов задач
Фиксация и отслеживание сроков
Организация работы людей в проекте
Ну а заказчик был определён и зафиксирован как участник, который несёт ответственность за продукт. За ним финальное решение о том, куда пойдёт продукт. Аналитик, как эксперт, влияет на продукт — предлагает новые фичи, рекомендует различные подходы и тенденции.
Что получилось?
Нормально расставленные и зафиксированные границы — штука хорошая. Даже если кто-то один так себе границы соблюдает, остальные участники команды помогают процессу работать верно.
В итоге, пообщавшись и договорившись по задачам, удалось перевести работу в нужное и продуктивное русло:
Прекратилась передача задач и приоритетов напрямую заказчиком в аналитику
Менеджер смог делать свою работу и управлять заказчиком, его бэклогом, сроками и ожиданием
Заказчик получил свои (корректные) рычаги влияния на задачи
Аналитики знают, что должны сделать, если видят проблему и хотят что-то изменить в решении или в процессах
Так же сделали и с другими ролями в проекте, например, с дизайнерами, разработчиками, тестированием. И главное, чтобы границы не ломались, договорились до следующего:
Новеньких сразу обучаем принятым границам между ролями
Поощряем работу в зоне влияния, поощряем эскалацию
На периодических со специалистами встречах собираем обратную связь и, при необходимости, вносим точечные правки
И общий профит
На уровне выше конкретного проекта также есть профит соблюдения общих границ. Например, для нас, как для компании-интегратора:
Упрощается запуск проектов, так как проекты работают по одному шаблону
Проектную команду расширять легче, так как исключается длительное погружение в процессы конкретного проекта
Ротация сотрудников между проектами возможна и работает
Новому человеку проще разобраться, как работает компания
Ясны границы, в которых можно влиять на процессы
Ценность сотрудника для компании не зависит от конкретного проекта
А можно без этого обойтись?
Да, можно и без таких формальных заморочек. Например, в in house, где каждый проект часто уникальная снежинка, или в небольшой команде. Как замечено в одном из комментариев к прошлой статье, в маленьких компаниях часто обходятся без аналитиков. Да и без узких специалистов вообще.
При этом важно понимать, что функции есть всегда. Просто один человек может выполнять функции нескольких ролей. И когда в команду приходит новый человек, особенно если это новая выделенная роль в команде, важно зафиксировать, чем этот человек будет заниматься и какие полномочия ему передаются.
И стоит ещё сказать, что описанный подход к разделению ответственности, наверняка не единственно верный. Сейчас пришли к этому. Может быть, через какое-то время поймём, что здесь тоже всё не так гладко. Но это не значит, что мы откажемся от фиксации функций и от того, чтобы ответственность за них делить между ролями. Просто может быть, что попилим как-то иначе.