Как я понял, чего хочу от работы

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

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

Как я пришёл к карте ответственности

В конце июня я приобрёл первую версию курса Стать Тимлидом от Школы сильных программистов. В первом уроке рассматривалась роль тимлида, а как раз с ней я и хотел определиться.

Авторы курса вводят три роли тимлида:

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

В зависимости от компании, твоего положения и желания можно распределять ответственность между этими тремя ролями. Например, быть техлидом и отдавать роли инженера 80% своего времени и ответственности.

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

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

Моя карта ответственности за 2 квартал 2024

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

На конец июня 2024 года я уже 3 месяца официально был руководителем, а на деле и того больше, потому что заниматься обязанностями тимлида я начал задолго до официального вступления в должность. Я решил начать с карты as-is, т.е. фактического состояния на момент составления этой карты.

Я точно так же выделил 3 роли, но немного изменил их. Теперь это Технический лидер, Управление людьми и Процессы команды.

Далее я решил отразить на этой карте то, чем я уже занимаюсь на своей должности.

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

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

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

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

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

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

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

С развитием тоже интересно. Как я уже писал в предыдущих публикациях, мне важно наличие регулярных one to one между сотрудником и руководителем. Было бы странно, если бы я не хотел это внедрить в своей команде. Также мне была интересна тема проведения performance review и составления индивидуальных планов развития. На тот момент я уже организовал первый прогон по придуманному процессу, но пометил зелёным, так как он был довольно сырой.

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

В процессы команды я решил добавить System Design - это то самое проектирование задачи. В тот момент процесс у нас был, прямо скажем, ужасный и неудобный. Нужно было что-то с этим делать.

Вот с таким планом я ушёл в следующий квартал. По правде говоря, поначалу я составил план аж на полгода, но спустя квартал понял, что это слишком огромный промежуток и приоритеты могут 100 раз поменяться.

Моя карта ответственности за 3 квартал 2024

Недавно я составлял свежую карту ответственности по итогу третьего квартала. И вот что там получилось.

Практически все пункты, которые я хотел добавить, были добавлены! Не получилось только с составлением профиля кандидата (т.к. сейчас у нас нет потребности в найме) и развитием отношений между отделами. Честно сказать, я не успел уделить этому достаточно времени.

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

Что делать дальше? То же самое, что мы делали ранее - добавлять и перекрашивать стикеры!

В Управлении людьми я хочу уделить время управлению конфликтами и продвижению корпоративной культуры. В развитии мне интересно внедрить квартальные ревью с каждым участником команды. Такое небольшое ретро с обсуждением и предварительным заполнением небольшой анкеты по самооценке.

Также хотелось бы найти время на составление карты компетенций - предыдущая показала себя нежизнеспособной. А в счастье и вовлечённости мне хотелось бы заняться материальными и нематериальными компенсациями.

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

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

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

Посмотрим, что из этого выйдет при подведении итогов в 4 квартале. Но когда я составил карту за 3 квартал, я увидел свой прогресс, что добавило мне мотивации продолжать. Я не сидел без дела весь квартал, я действительно работал.

Итоги

На мой взгляд, карта ответственности - очень универсальная вещь. Её можно составлять даже не ограничиваясь IT направлениями. Она здорово помогает понять, насколько много (или мало) работы вы на самом деле выполняете. С помощью неё можно спланировать план развития и согласовать его с руководством.

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

Подписывайтесь на мой Telegram и оставляйте комментарии к публикации с этой статьёй - я буду рад услышать ваше мнение.