У нас в компании мы очень внимательно подходим к ответственности. Фактически рост сотрудника напрямую связан с объемом ответственности, которую тот может «прожевать». Так младший берёт ответственность за задачи; мидл — берёт ответственность за проект; старший — за портфель проектов; ведущий — за команду и производственный процесс.

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

Допустим, у нас есть джун, которому поставили задачу подобрать семантическое ядро по процедуре УЗИ. Ставить такую задачу будет либо старший, либо мидл. В момент постановки задачи, они опишут понимание (для джуна понимание сформировать сложно, не хватает насмотренности), и отдают его на джуна. Если джун говорит: «Я всё понял, пошёл делать», значит ответственность за задачу делегирована, теперь это ответственность на джуне.

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

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

Пока я вижу только такой путь как избежать этой ситуации:

— Явно указывать, что ответственность на джуне и за ним никто не будет проверять его работу.
— Напомнить, что он всегда может прийти к мидлу и старшему и проконсультироваться по сложным вопросам.
— Напомнить, что в агентстве есть принцип работы в «четыре руки», для задач, которые сложно выполнять.
— Разбирать ошибки, и слушать что думал джун, когда отдавал задачу с ошибкой.
— Дать право на ошибку (обсуждать это явно), но если ошибки будут повторяются, явно сказать, что мы с ним прекратим работать.

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

В прошлом году мы наняли около 8 человек как перформанс-маркетологов. Искали в основном мидлов и старших специалистов.

Основная проблема в найме — это кучу времени уходит на собеседования. Раньше собеседования шли в районе 3 часов. Обычно на вакансию за месяц откликаются от 600-900 кандидатов. Если отсеивать только по вакансии, то мы оставим где-то 150-200 человек. То есть в один рабочий день нужно будет провести до 9 интервью.

Поэтому нужно было придумать дополнительный фильтр кандидатов. Раньше все наймы шли через сайт, где нужно было заполнить опросник. Если отвечать полно и подробно, то на него уходит от 3 до 9 часов. Это сразу же отсеивало людей, которые не могли поделиться своим опытом или которые не готовы были выделить хотя бы 3 часа на ответы на вопросы.

Но подобный опросник работал очень плохо с внешними площадками. А нам нужно было в первую очередь увеличить количество откликов, потому что только собственными ресурсами мы можем в лучшем случае нанять 3-4 человека за год.

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

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

Но в 97-98% случаев кандидаты выполняли тестовое задание. И как показала практика, сильные специалисты делают интересные тестовые, которые практически гарантируют им оплачиваемую стажировку, если они не провалятся на интервью.

Как проверяли тестовое
Если вы думаете, что над тестовым сидят по 20-30 минут и проверяют каждую цифру, то сильно ошибаетесь. На проверку тестового в день отводится 20 минут времени ведущего специалиста. В месяц это для компании обходится примерно в 40 000 ₽. И это только за проверку тестовых, без интервью, стажировок и т. д.!

Поэтому по проверки тестовых мы выработали определенный процесс, нужно было ответить положительно на эти вопросы:
— тестовое было сделано (все пункты, которые требовались в ТЗ реализованы)?
— была описана логика решения?
— была посчитана эффективность (и она адекватная, без сильных ошибок)?

Если были какие-то сомнения по тестовому (это сложно объяснить, интуиция, когда ты видишь что сделано некачественно, но не можешь описать словами что не так) → не бери этого человека. Я проводил над собой эксперимент, и брал на интервью ребят, по которым были сомнения. К сожалению, эти люди проваливали свои собеседования. Один раз мне даже давили на совесть («Я мать одиночка, у меня двое детей»). В общем, верим своему опыту и интуиции.

На проверку одного тестового не должно уходить больше 3 минут. Если занимает больше времени → обычно что-то не так с тестовым, или тестовое очень сильно понравилось. Интересные механики, или расчёт.

Я обычно еще проверяю стандартные ошибки (берут среднее от среднего, неправильно считают формулы, логические ошибки). Если ошибки явные → человека не беру.

Ежедневно я веду заметки по каждому дню. Раньше это делал на бумаге в блокноте, а сейчас в дневных заметках Obsidian. Хочу сегодня рассказать для чего и как это помогает.

Не забыть
В течении дня проходит множество встреч и событий. Во время этих встреч в голову приходят интересные мысли → я их записываю. Договорились о чём-то → я это записываю. Прозвучал важный факт → я это записываю. Кто-то взял на себя ответственность за какую-то задачу → я это записываю. 30 минут обсуждали что-то и пришли к какому-то выводу → записываю, чтоб потом спросить про эту гипотезу или теорию (что случилось дальше).

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

Поэтому я вначале сбрасываю куда-то весь мусор из мыслей и идей. А в конце дня разбираю и уже формирую задачи/напоминания в Singularity.

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

Прогресс 1-to-1 планёрок
На личных планёрках о чём-то договариваюсь с подопечными. Обо всём этом, мы с подопечным обсудим на следующей планёрке. Это очень сильно помогает экономить силы на подготовку к следующей личной планёрке.

Что дальше
Формат такого ежедневника постоянно меняю, что-то добавляю, что-то убираю. К примеру, изучение иностранного языка для меня не эффективен по такой методике. Старые добрые заметки в блокнот — намного эффективней (лучше запоминается).

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