Знакомо ли тебе слово "делегирование"?

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

Или нет? Иногда вместо бесценного опыта сотрудник остаётся без свободного времени и премий; ты – без повышения, перформанса и доверия к команде. К сожалению, мало у кого делегирование с первого раза работает как надо. Это – отдельный и сложный менеджерский скилл.

Как, делегируя, приносить команде и себе пользу, а не вред?

Под катом разберём важные составляющие успеха.

---

Адекватные ожидания

Допустим, у тебя есть "задача". Вообще любая: запилить микросервис; подготовить презентацию к совету директоров; провести миграцию данных в новую базу; переверстать страничку в приложении.

И ты подумываешь её делегировать.

Насколько качественно и быстро, по твоему мнению, должна быть выполнена работа, чтобы принять её и сказать человеку, что он справился?

Если твой ответ:

Результат должен быть таким, будто я делал сам

У меня для тебя плохие новости: делегирование почти наверняка не удастся.

Единственный способ получить результат с таким же качеством и скоростью, как делаешь ты сам – выполнить работу самостоятельно. Сотрудники отличаются от тебя навыками и способом мышления. И это нормально.

Хорошая новость состоит в том, что у большинства задач, помимо "эталонного" решения (если такое вообще найдётся), бывает ещё "достаточно хорошее".

"Достаточно хороший" результат – именно то, что нужно стремиться получить в результате делегирования.

– Есть у меня идея, как попотеть и реализовать http-хэндлер с ответом за 50 мс. А насколько это критично? Ну..подойдет и 500 (страница грузится примерно за 600). Вот 700 – уже плохо, а 500 – достаточно хорошо.

– Нужно подготовить демо + презентацию проекта. В идеале бы, конечно, шрифты и заголовки вычитать + схемы красивые нарисовать. Но достаточно для понимания – внятные заголовки + схема ключевого компонента. Остальное – nice to have

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

---

Выбор исполнителя

Окей, мы договорились с собой о том, какой результат считать достаточно хорошим. И за какое время мы сможем его получить. Как выбрать исполнителя?

Рассмотрим возможные отношения "человек - делегируемая задача", которые часто встречаются на практике. Во всех случаях будем предполагать, что человек, как минимум, не оказывает активного сопротивления полученным задачам и базово мотивирован работать.

Мотивация – отдельная большая тема, про неё выйдет другая статья.

a. Человек выполнит задачу легко и абсолютно без рисков. Он такое много раз делал.

Тактически безопасно: если сотрудника не собьёт автобус, он и правда справится. Скорее всего, даже не придётся переделывать.

Дефолтный вариант в одном из трех случаев:

1. Планка "достаточно хорошего" результата находится близко к уровню "безупречно". Например: ты реализуешь критичную логику в биллинге своего сервиса, ошибка приведёт к многомиллионным потерям в секунду

2. Времени на задачу мало. Например, релизить нужно "завтра" (или даже "вчера")

3. Человек подустал и хочет спокойной и размеренной работы, без челленджей и напряжения

Почему этот вариант – не дефолтный на все случаи жизни?

У него есть стратегическая проблема:

Если человек является абсолютно безопасным и надёжным исполнителем для задачи, скорее всего, сам он воспримет задачу как рутину. Она не будет вызовом, не поможет ему выйти на новый уровень и так далее. Если делегировать только таким способом, сотрудники начнут протухать и перестанут развиваться. Самые проактивные – начнут менять работу.

Так что используй эту схему делегирования с умом.

––

b. Человек "наверное" справится. Задача чуть сложнее, чем те, что он часто решает. Или в целом является для него новой, но ты веришь, что он разберётся.

Стратегически – лучший вид задач для развития сотрудников и команды. Ровно такое делегирование позволяет прокачивать людей и поддерживать нематериальную мотивацию в работе. Эту схему делегирования обязательно нужно использовать, если хочешь развивать команду.

Но у неё, конечно, есть тактические риски. Наше "наверное" будет реализовываться: человек споткнется, поймет что-то неправильно, придётся переделывать и тд.

Поэтому:

1. Не используй эту схему, если сделано должно быть "завтра" или "идеально".

2. Как можно конкретнее и детальнее сформулируй "образ результата". О нём – в параграфе ниже

3. Убедись, что человек мотивирован более, чем на уровне "ну, ладно, так уж и быть". Без этого трудности и ошибки могут его серьёзно подкосить

––

c. Человек почти гарантированно не справится. Его уровень значительно ниже, чем необходимый для выполнения задачи

– Зачем мы вообще обсуждаем этот кейс? Вроде всё очевидно – делегировать задачи по такой схеме не стоит, так ведь?

Да. Ну..почти.

Есть интересный корнер-кейс: человек ну очень хочет научиться решать такие задачи и вырасти. Глаза горят, в бой рвётся, но задача превышает его скилл даже не в 2, а, скажем, в 10 раз. Например, инженер недавно научился в существующие микросервисы правки вносить, а у тебя на носу – большой новый проект, где нужно по сервису в неделю клепать.

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

1. Выбрать компетентного ответственного за проект (иногда – это ты. Иногда – другой инженер из команды)

2. Рвущегося в бой новичка поставить ответственным за часть задачи + понаблюдать за ходом проекта в целом. Ответственного за проект – попросить его поменторить

Проект сойдётся позже, чем при полном выполнении компетентным сотрудником, но даст стратегические преимущества:

– Более прокачанный по хардам и, что важно, мотивированный новичок
– Более прокачанный по софтам (да – эти навыки тоже нужно развивать) инженер высокого уровня
– Усиленные горизонтальные связи в команде

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

---

Образ результата для исполнителя

– Окей, у нас есть понимание, что такое "достаточно хорошо". Попрошу сотрудника сделать и приму задачу, когда станет "достаточно хорошо", верно?

Ну..Почти.

Перед тем, как человек возьмётся за дело, нужно явно и как можно детальнее записать, что буквально ожидается на выходе. Если за подобную задачу он берётся в первый раз, объяснение просто по определению не может быть слишком подробным.

Несколько критериев, которые помогут тебе понять, что результат описан прозрачно и хорошо:

1. Должен быть указан четкий срок окончания работы.

2. Результат должен быть осязаемым и измеримым. С минимумом пространства для интерпретаций.

"Сделать, чтоб было зашибись" (вы смеётесь, а я однажды получил код сервиса вот с таким комментарием) – абсолютно неизмеримый результат, плохо.

Разработать сервис для работы с товарами в магазине"

– чуть получше, но всё ещё плохо.

Разработать сервис с тремя http-хэндлерами: создание товара, редактирование товара, удаление товара, и получение товара

– лучше.

Разработать сервис с тремя http-хэндлерами: создание товара, редактирование товара, удаление товара, и получение товара. Создание и редактирование должны срабатывать за 100 мс, чтение – за 50 мс. Код должен быть покрыт юнит-тестами. Его должны окнуть на ревью в команде Y

– ещё лучше.

––

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

Да чёрт его знает, какие хэндлеры нам понадобятся. Надо с продактом поговорить + поресёрчить – тогда видно будет.

И это нормально. Значит, так и записываем:

a. Сформулировать, что должен делать сервис. Для этого: поговорить с продактом, собрать требования здесь и здесь, и слепить дизайн-док
b. Окнуть дизайн-док об меня, после чего мы сформулируем требования и дедлайны следующего этапа и обновим задачу

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

– А разве мы не убиваем пространство для творчества, подробно описывая результат?

Это – тонкая грань, которую важно не перешагнуть. До тех пор, пока ты вводишь ограничения, снижающие вероятность, что человек пойдет "не туда" или сделает "не то", всё окей. Хорошее решение ведь тоже нужно придумать. Отправлять людей перебирать все "плохие" – долго и дорого.

Но буквально описывать, какой код в каком файле нужно написать – это слишком.

Как можно точнее скажи, "что" должно быть сделано. Без необходимости – не говори "как". Уточняй до тех пор, пока и тебе, и исполнителю не станет абсолютно понятно, куда идти.

---

Промежуточный контроль и обратная связь

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

А бывают – протяжённые во времени.
На них тактика "выдать задачу" + "проверить результат" не работает.

По крайней мере, если ты – не садист и не хочешь, чтобы человек несколько раз полностью переделывал работу.

Если сотрудник взялся за проект длиной в несколько недель или месяцев – проверить, как идут дела, нужно не через несколько недель, а через несколько дней.

Договоритесь на самом старте о регулярных чекапах: стендапы; отдельные встречи-статусы по проекту; письма – лишь бы вам обоим было удобно.

Руководителю на таких чекапах важно быть вовлечённым и по-честному обдумывать прогресс и действия человека, а не просто ждать, пока прозвучат слова "у меня проблема" / "кажется, я делаю что-то не так и т.д.". Если исполнитель не очень опытен в выполнении задач или не делал таких вообще – он ведь может самостоятельно и не понять, что у него проблема. Для этого нужен детальный взгляд того, кто такие задачи уже выполнял.

8 из 10 проектов могли бы быть сделаны быстрее и лучше, если бы исполнители раньше получили обратную связь о проблемах :)

---

Виды делегируемых задач

Задачи на работу "руками" (написать код / сверстать страничку / etc) – очевидные кандидаты на делегирование. Для них нетрудно сформировать образ желаемого результата, договориться с сотрудником, проконтролировать и т.д.

Но у тебя, как у руководителя, есть ещё и другая ценная для команды работа, правда?

– Проведение стендапов
– Управление проектами команды
– Менторство и развитие сотрудников
– Переговоры со смежниками
– ...

Так вот, процессы и коммуникации тоже можно делегировать.
Провести встречу / договориться / собрать статус по проекту – это тоже работа, которую нужно уметь выполнять.

Во-первых, она занимает твоё время и интеллектуальный ресурс (даже если кажется, что ты делаешь это на автомате и легко);

Во-вторых, в коммуникациях и процессах тоже есть бас-фактор. Если с твоим уходом в отпуск перформанс команды / дожимание сложных проектов и переговоров / обратная связь для сотрудников проседают или пропадают совсем – это верный знак того, что ты стал боттл-неком в процессах и коммуникациях;

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

Как делегировать процессы и коммуникации?
Точно так же, как задачи.

1. Сформулировать образ "достаточно хорошего" желаемого результата.

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

Результат встречи со смежниками по проекту – набор достигнутых договоренностей: кто, как и когда реализует логику для таких-то фичей, когда команда А вытащит свой костыль из..бэка команды B и так далее

Если встреча (или серия встреч) правда полезная – ты сможешь сформулировать и записать, какой результат ожидаешь

2. Выбрать подходящего сотрудника

Помимо хард-скиллов (они никуда не пропадают! Тебе ведь важно, чтобы человек понимал всех говорящих?) добавляются ещё и софты.

– Как понять, что человек софтовый?

Например, по личному впечатлению от разговоров с ним + по фидбекам от коллег.

– Вроде софтовый, но все равно боюсь делегировать. Он же раньше не делал такое – вдруг не справится?

Ошибки подчиненных – это нормально, за этим ты и здесь. Всё как с первыми попытками человека писать код: садишься рядом и смотришь, как он это делает. Если получается плохо – подхватываешь встречу в моменте, а с ним, впоследствие, разбираешь ошибки и способы сделать лучше.

Внезапно, переговоры, как и задачи на написание кода, позволяют делать несколько попыток. Не смогли договориться с первого раза? Ну ничего, встретитесь еще раз на следующий день.

3. И далее по списку – сформулировать образ результата для сотрудника, дать фидбек и прочее.

---

Ответственность

Последнее, но не по важности: ответственность за результат.

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

Если ты выбрал человека неправильно, не посаппортил по дороге, не дал комментариев в нужное время и задача профачена – у тебя нет возможности сказать: "ну, это Вася задачу слил, я просто рядом стоял". За этим, отчасти, и нужен руководитель: ты можешь делегировать свои задачи, выбирать исполнителей, давать им ошибаться и развивать, но для крупных стейкхолдеров и руководителей более высокого уровня ты всё ещё ответственен за результат. Делегирование – это твоя деталь реализации.

Держи это в голове, выполняя остальные пункты :)

---

Подведём итоги

Если хочешь делегировать задачу:

1. Договорись с собой про достаточно хороший, реалистичный результат.

2. Выбери исполнителя. Если есть возможность – так, чтобы задача была для него развитием. Но не забывай о жестких дедлайнах и стоимости ошибок.

3. Прозрачно донеси до человека (лучше письменно), что конкретно и когда он должен сделать.

4. Отслеживай прогресс, присоединяйся к поиску проблем, регулярно делись обратной связью по выполнению задачи.

5. Не забывай, что перед внешними людьми ты должен быть готов ответить за результат.

Ну вот и всё! Легко сказать и сложно сделать :)

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

Много другого контента про жизнь и работу руководителей, обсуждений, вопросов и консультаций можно найти в моём канале. Буду рад всем заглянувшим на огонёк.

До новых встреч!