В течение восьми лет, проведенных на должности директора по разработке, я старался постоянно отслеживать на что тратится мое время. Тогда я занимался техническим управлением стартапа, так что круг моих обязанностей был очень широк. С помощью тайм-менеджмента я тщательно отслеживал на что трачу время, и это позволяло мне правильно составить расписание и грамотно спланировать работу. К примеру, я знаю, что около трети времени трачу на совместную работу и помощь команде, так что знаю, сколько на это выделить часов. Если бы я посвящал совещаниям и планированию всю рабочую неделю, то на собственные технические задачи времени уже не хватало бы. А это повредило бы и групповой работе.
Будущие коллеги часто расспрашивают меня о работе, поэтому я решил сделать подробный обзор своей деятельности на должности директора по разработке. Разумеется, у каждой компании, и у каждой отдельной роли внутри неё, есть своя специфика. Но, надеюсь, этот обзор даст некоторое общее представление о том, как проходит день из жизни технического руководителя.
Чем занимается директор по разработке?
Для начала скажу пару слов о своем профессиональном пути. Впервые я вступил в должность директора по разработке в компании Packback, веб-сервисе вопросов и ответов для профессоров колледжей. Я присоединился к команде, когда в компании было всего четыре человека; по сути, это были её основатели и я. За три года нашей работы компания заработала около 5 миллионов долларов и расширила штат почти до 30 человек. Моя команда разработчиков была довольно скудной (к моменту моего ухода в 2016 году их было пятеро), однако за 3 года работы круг моих функций расширился существенно.
Я покинул Packback и присоединился к Graide Network в том же качестве. Сначала под моим началом работал только подрядчик. Но за четыре года работы я нанял еще трёх разработчиков и взял на себя ряд обязанностей по управлению продуктом.
За эти годы формат моей работы претерпел большие изменения. Основной моей задачей было помочь команде создавать такое ПО, которое отвечало бы запросам заказчика, контролируя сроки и бюджет.
Ключевое слово – «помочь». Что это значит? Что директор по разработке пишет код? Или только следит за тем, чтобы все участники команды его писали? Отвечая вкратце: смотря по обстоятельствам.
Директор по разработке должен обладать техническими навыками
Как правило, директор меньше занимается разработкой, чем, скажем, тимлиды, но он все равно должен регулярно работать с кодом, чтобы не терять навык. Также очень важно помогать членам своей команды выходить из тупиков, а, значит, давать ответы на технические вопросы и разрешать конфликты между коллегами. Иногда директор по разработке участвует в обучении новых разработчиков и дает свою оценку технических навыков и личностных качеств кандидатов на эту должность.
Директор по разработке должен быть коммуникабельным
«Коммуникабельность» — сложное понятие. Многие считают, что хороший менеджер должен непременно быть экстравертом, но это совсем не обязательно. Куда важнее обладать эмпатией и готовностью помогать своей команде преодолевать сложности — как технические, так и личные.
Нельзя забывать и о «руководящем» аспекте должности. Когда начальник просит дать обратную связь, в приоритете всегда должны быть интересы команды в целом. Иной раз это означает, что если кто-то из её участников не справляется со своей работой, с ним придётся попрощаться.
О самом сложном
Сложнее всего в новой управленческой должности мне было оценивать свою работу. Николас Минс хорошо сказал об этом в великолепной статье о метапродуктивности для менеджеров:
«Бывает, что когда в конце последней рабочей встречи я оглядываюсь на то, как прошёл мой день, то чувствую, что не сделал абсолютно ничего. Я весь день был чем-то занят: общался с коллегами, читал документы, проверял статус работы, ужасно устал, но совершенно ничего не добился».
Николас Минс
Мне было относительно просто определить свой уровень продуктивности, когда я был разработчиком ПО. Например, если я доделал фичу или принял pull request, то за день есть некоторый прогресс. А вот понять, насколько продуктивным был мой день в качестве директора, было задачей посложнее.
Так что я начал контролировать рабочее время. Потраченные на задачу часы — не идеальное мерило производительности, но так я по крайней мере мог убедиться, что уделяю достаточно времени каждому рабочему направлению.
Как проходит мой день?
Обязанности директоров по разработке различаются в зависимости от масштабов компании-работодателя и её организационной структуры. Я разделил свои задачи на четыре категории, чтобы составить общее впечатление о том, чем заполнен мой рабочий день. Получилось примерно следующее:
- Технические задачи 35%
- Управленческие задачи 35%
- Рекрутинг 15%
- Административные задачи 15%
Я жёстко контролировал на что трачу время своей восьмилетней управленческой карьеры. Но для простоты восприятия в этой статье я буду использовать округлённые значения. Точное количество часов не столь важно, полезнее отслеживать рост или сокращение затрат времени на те или иначе задачи в течение недели.
Технические задачи: 35% моего времени
В эту категорию входит:
- написание и обзор кода,
- поиск багов,
- решение коллективных задач,
- исследование обновлений ПО и новых методик по работе с ним.
По мере увеличения штата разработчиков, сокращалось и время, которое я тратил на написание и анализ кода. Но я считаю, что директору по разработке все равно необходимо хотя бы часть времени посвящать кодингу.
Управленческие задачи: 35% моего времени
Этот сегмент состоит непосредственно из управления персоналом, установления временных рамок, стратегического планирования и встреч с членами команды разного функционала.
Забота о команде, защита их интересов на деловых встречах и помощь разработчикам в создании технических спецификаций — всё это было частью моих обязанностей в Packback.
В Graide Network я взял на себя более стратегическую роль, консультируясь с основателями по выбору ПО и участвуя в важных звонках по продажам. Любопытно: задачи, которые я брал на себя в разных компаниях, отличались, а распределение времени было почти нет.
Рекрутинг: 15% моего времени
Рекрутинг включал в себя:
- посещение конференций, митапов и буткемпов по программированию,
- написание постов в блоге,
- встречи с кандидатами на работу,
- оценку технического тестирования.
Иногда я тратил прорву времени на поиск кандидатов-разработчиков. С опытом я осознал, что искать их стоит всегда. Лучшие кандидаты, как правило, довольно пассивны в плане поиска работы. Поэтому я стал выделять время на встречи с ними стабильно каждую неделю.
Административные задачи: 15% моего времени
Ну и наконец несколько часов в неделю я тратил на чтение и написание электронных писем, ответы на вопросы в Slack, случайные разговоры и другие повседневные дела для поддержки команды. Я старался не допускать того чтобы подобные отвлекающие факторы влияли на работу разработчиков, но при необходимости согласовывал с ними эти моменты. Поскольку основная задача директора по разработке — максимальная продуктивность команды, само собой разумеется, что на него ложится большая часть административной работы.
Как стать хорошим директором по разработке?
Нельзя исчерпывающе ответить на этот вопрос в одной небольшой статье. Но можно выделить основные задачи, на которых, на мой взгляд, стоит сосредоточиться.
1. Расширяйте возможности своей команды
Быть хорошим управленцем — значит помогать другим достигать больших целей. То есть ваше влияние должно стать менее выраженным, чем в бытность тимлидом или разработчиком, вы больше не сможете тратить всё своё время только на работу с кодом. Поначалу я фрустрировал от того, как сильно сократился список моих еженедельных достижений. Но потом осознал, что благодаря хорошему менеджменту моя команда добивается куда большего, пусть и не за счёт моего индивидуального вклада в техническую составляющую. Это позволило мне по-настоящему оценить роль своей работы.
2. Общайтесь как можно больше
Независимо от того, работает ли ваша команда в одном кабинете или удалённо по всему миру, коммуникация — одна из ваших самых важных задач как менеджера. В маркетинге существует такое правило: люди должны услышать ваше сообщение семь раз, и только потом они усвоят его. Думаю, что это равно относится и к командному общению. Конечно, я не имею ввиду, что нужно в буквальном смысле повторять одно и то же по семь раз за летучку. Но попробуйте, когда вносите корректировки в работу, проговаривать их потом при личном общении, на групповых встречах, по почте и просто мимоходом. Перемены часто пугают, но чем чаще люди о чем-то слышат, тем быстрее к ним привыкают.
3. Будьте источником спокойствия
И финальный пункт: вы как директор по разработке должны привносить порядок в хаос.
«Ваше присутствие должно вносить больше четкости и структуры в любой процесс, которого вы касаетесь. По-настоящему хороший руководитель может попасть в ситуацию, в которой его сотрудники потеряли представление о своих целях, и вернуть им ясность, указав верное направление».
Не драматизируйте, не изолируйте свою команду от остальной компании, не настраивайте сотрудников друг против друга. Вместо этого вносите ясность, развеивайте стресс, помогая своей команде решать поставленные задачи чётко и без лишней суеты.
Автор — Карл Фьюз, основатель draft.dev. Источник.