16 августа 2024
Личный опыт: что поможет начинающему тимлиду команды разработчиков лучше справляться с новыми задачами
Тимлидами в команде разработки, как правило, становятся опытные разработчики. И часто они не готовы к новым задачам в качестве менеджера, который отвечает за выстраивание внутренних процессов и слаженную работу команды.
Разработчик Борис Гордеев больше года занимал позицию тимлида и рассказывает, какие навыки необходимы начинающим руководителям в IT-сфере для комфортной работы с коллегами и топ-менеджментом.
Разработчик Борис Гордеев больше года занимал позицию тимлида и рассказывает, какие навыки необходимы начинающим руководителям в IT-сфере для комфортной работы с коллегами и топ-менеджментом.
Борис Гордеев
Инженер-разработчик в финтехе. Больше года был тимлидом в команде разработчиков в стартапе
Тимлидами в команде разработки, как правило, становятся опытные разработчики. И часто они не готовы к новым задачам в качестве менеджера, который отвечает за выстраивание внутренних процессов и слаженную работу команды.
Разработчик Борис Гордеев больше года занимал позицию тимлида и рассказывает, какие навыки необходимы начинающим руководителям в IT-сфере для комфортной работы с коллегами и топ-менеджментом.
Разработчик Борис Гордеев больше года занимал позицию тимлида и рассказывает, какие навыки необходимы начинающим руководителям в IT-сфере для комфортной работы с коллегами и топ-менеджментом.
Я начал свою карьеру в разработке десять лет назад, когда заканчивал магистратуру в Университете ИТМО и параллельно работал. Три года назад я попробовал себя в управлении небольшой командой. Нам хотелось выстроить взаимодействие между сотрудниками и с заказчиками, наладить внутреннюю работу, и я вызвался помочь. К тому моменту я видел достаточно примеров разных стилей и подходов, что работает и что нет, и мне было интересно самому поэкспериментировать с управлением.
По моему мнению, единственно верного подхода к управлению IT-командой нет. Что, пожалуй, роднит эту область с разработкой. Именно поэтому в этой статье я не хотел бы сводить всё к простым правилам и советам, которым нужно следовать для неминуемого успеха. Вместо этого я расскажу про то, чему стоит научиться тимлидам, чтобы с ними было приятно и полезно работать.
По моему мнению, единственно верного подхода к управлению IT-командой нет. Что, пожалуй, роднит эту область с разработкой. Именно поэтому в этой статье я не хотел бы сводить всё к простым правилам и советам, которым нужно следовать для неминуемого успеха. Вместо этого я расскажу про то, чему стоит научиться тимлидам, чтобы с ними было приятно и полезно работать.
Учитесь слушать
Как только тимлид получает хотя бы минимальную зону ответственности, он быстро обнаруживает, что от него многие чего-то хотят. Менеджмент будет приходить с грандиозными идеями новых фичей, а коллеги и подчинённые ― с вопросами и жалобами.
Общение с коллегами часто сводится к рутине: например, нужно поставить команде задачи или подготовить информацию в ответ на вопрос менеджера. Но бывает и так, что людей нужно просто выслушать. Коллеги могут устать от непростых взаимоотношений в команде, сжатых сроков или каких-то рабочих моментов.
Необязательно сразу начинать решать такие вопросы. Иногда сотрудники хотят высказаться, узнать что-то новое или пожаловаться. Важно правильно определять такие моменты, чтобы сохранять эмоциональное здоровье в команде.
Общение с коллегами часто сводится к рутине: например, нужно поставить команде задачи или подготовить информацию в ответ на вопрос менеджера. Но бывает и так, что людей нужно просто выслушать. Коллеги могут устать от непростых взаимоотношений в команде, сжатых сроков или каких-то рабочих моментов.
Необязательно сразу начинать решать такие вопросы. Иногда сотрудники хотят высказаться, узнать что-то новое или пожаловаться. Важно правильно определять такие моменты, чтобы сохранять эмоциональное здоровье в команде.
Однажды подчинённый обратился ко мне с простыми вопросами из серии «правильно ли я тут делаю? нравится ли тебе мой код?». Мне показалось странным слышать от него такие вопросы, я стал выяснять, что да как, и сотрудник признался, что во время код-ревью ему нагрубил коллега. Сразу сказать о конфликте человек не решился, но после небольшого разговора по душам эмоции всё же взяли верх. Оказалось, что за тем самым коллегой и раньше замечали такое поведение при схожих обстоятельствах. Возможно, я никогда бы и не узнал о том, как эту ситуацию видят другие, и не поговорил бы со всеми. Так почти на пустом месте вскрылся групповой конфликт. Конец у этой истории хороший: мы все собрались, коллеги проговорили некомфортные моменты грубияну, тот принял информацию к сведению ― работа наладилась.
Похожие ситуации случались и с более прикладными задачами. Так, комментируя мой технический документ, новый в команде, но опытный старший разработчик начал поднимать фундаментальные вопросы о моём решении вроде «а зачем так вообще делать?». Я мог ему ответить, что решение выверенное и в доработках не нуждается. Но я предпочёл ещё раз аргументировать свою позицию, проговорить мотивацию и предметную область. В итоге у нас получилось глубокое и полезное обсуждение вопроса ― задачу мы решили куда эффективнее и грациознее.
Похожие ситуации случались и с более прикладными задачами. Так, комментируя мой технический документ, новый в команде, но опытный старший разработчик начал поднимать фундаментальные вопросы о моём решении вроде «а зачем так вообще делать?». Я мог ему ответить, что решение выверенное и в доработках не нуждается. Но я предпочёл ещё раз аргументировать свою позицию, проговорить мотивацию и предметную область. В итоге у нас получилось глубокое и полезное обсуждение вопроса ― задачу мы решили куда эффективнее и грациознее.
Учитесь общаться с менеджментом
Обычная ситуация ― к тимлиду зашёл начальник поинтересоваться, когда будет готова новая функция продукта. Из раза в раз я наблюдаю одну и ту же ошибку в такой ситуации со стороны новичков, которые пускаются в пространное описание технических подробностей реализуемых задач.
Менеджмент в любой компании ― будь то IT-гигант или стартап ― зачастую интересует только, когда всё будет готово и можно ли текущие разработки показывать вышестоящему руководству или заказчику. Вряд ли ему будут интересны детали о коде или проблемах с данными, с которыми столкнулась команда.
Менеджмент в любой компании ― будь то IT-гигант или стартап ― зачастую интересует только, когда всё будет готово и можно ли текущие разработки показывать вышестоящему руководству или заказчику. Вряд ли ему будут интересны детали о коде или проблемах с данными, с которыми столкнулась команда.
- Когда менеджер спрашивает у тимлида, когда будет готова задача, стоит придерживаться прикладной коммуникации. Например: «Столкнулись в одном месте с техническими сложностями, но параллельно решили вот такие задачи ― получится даже лучше. Посмотреть на промежуточный результат можно будет тогда-то».
Временную неудачу или задержку можно представить руководству так, что оно уйдёт как минимум не разочарованным. Все должны понимать, что происходит в команде, и иметь реалистичные ожидания по отношению к ней. Отсутствие претензий позволит команде работать свободнее.
Научитесь выстраивать комфортную работу команды на бесплатных занятиях
Узнаете, как управлять конфликтом и как вести себя в разных конфликтных ситуациях
Научитесь выстраивать рабочие отношения в малых командах. Поймёте, как формировать доверительные отношения
Узнаете, как избавиться от страха некомпетентности, научиться присваивать свои достижения и стать увереннее
Учитесь анализировать задачи и грамотно передавать их команде ― или не передавать
Тимлиду следует корректно с технической точки зрения подготовить задачи, с которыми предстоит работать команде.
Обычно задания приходят не от инженеров или разработчиков, а от владельцев продукта или продакт-менеджеров. А в небольших организациях ставить задачи могут непосредственные начальники или высшее руководство. То есть это не всегда те, кто понимает состояние продукта и инженерные решения, поэтому их требования могут быть высокоуровневыми. А тимлидам нужно преобразовать эти требования в тикеты в системе управления проектами. Или же и вовсе не брать их в обработку, а отправить обратно или перенаправить по правильному адресу.
Обычно задания приходят не от инженеров или разработчиков, а от владельцев продукта или продакт-менеджеров. А в небольших организациях ставить задачи могут непосредственные начальники или высшее руководство. То есть это не всегда те, кто понимает состояние продукта и инженерные решения, поэтому их требования могут быть высокоуровневыми. А тимлидам нужно преобразовать эти требования в тикеты в системе управления проектами. Или же и вовсе не брать их в обработку, а отправить обратно или перенаправить по правильному адресу.
В своё время у нашего продукта был специальный интерфейс, через который администраторы вносили объявления в систему. Что-то вроде блога. И вот однажды мы решили, что некоторые наши клиенты могут делать так же.
Мы попросили клиентский отдел рассказать о желаниях подходящих заказчиков и получили от них что-то вроде ТЗ. Важный нюанс заключался в специфической терминологии, которую использовали коллеги в описании: «у нас есть такие-то виды клиентов, которые хотят создавать такие-то сущности, иметь такие-то права».
Моя команда уже собиралась приступить к созданию отдельного продукта только лишь по этому описанию, но я вовремя вмешался. Детально обговорив требования, мы поняли, что всё это у нас уже есть, просто называется по-другому. В итоге мы сэкономили много времени и усилий, так как нужно было лишь расширить существующую систему.
Мы попросили клиентский отдел рассказать о желаниях подходящих заказчиков и получили от них что-то вроде ТЗ. Важный нюанс заключался в специфической терминологии, которую использовали коллеги в описании: «у нас есть такие-то виды клиентов, которые хотят создавать такие-то сущности, иметь такие-то права».
Моя команда уже собиралась приступить к созданию отдельного продукта только лишь по этому описанию, но я вовремя вмешался. Детально обговорив требования, мы поняли, что всё это у нас уже есть, просто называется по-другому. В итоге мы сэкономили много времени и усилий, так как нужно было лишь расширить существующую систему.
А когда брать в работу что-то не стоит? Для многих инженеров такое развитие событий ― наиболее благоприятный вариант, ведь всё уже работает хорошо и ничего делать не нужно.
Частый случай ― когда к тимлиду приходят жаловаться на какую-то проблему, но её решение зависит не от него. Допустим, ваша команда рисует для заказчика графики. И вот к вам приходит не знающий внутреннего устройства системы человек и говорит, что графики работают неправильно из-за некорректных входных данных. Эту проблему можно решить на стороне графика, но ведь нужно разобраться, почему входные данные оказались неправильные. Поэтому лучше отправить эту задачу команде, которая работает со входными данными.
Конечный результат в виде продукта, а также командный путь к нему будут сильно зависеть от того, как хорошо тимлид соотнесёт желания владельца продукта или начальника с реальностью. Как это сделать, зависит только от опыта тимлида. От себя скажу, что я за то, чтобы проговаривать всё с командой и совместно находить лучшие решения.
Частый случай ― когда к тимлиду приходят жаловаться на какую-то проблему, но её решение зависит не от него. Допустим, ваша команда рисует для заказчика графики. И вот к вам приходит не знающий внутреннего устройства системы человек и говорит, что графики работают неправильно из-за некорректных входных данных. Эту проблему можно решить на стороне графика, но ведь нужно разобраться, почему входные данные оказались неправильные. Поэтому лучше отправить эту задачу команде, которая работает со входными данными.
Конечный результат в виде продукта, а также командный путь к нему будут сильно зависеть от того, как хорошо тимлид соотнесёт желания владельца продукта или начальника с реальностью. Как это сделать, зависит только от опыта тимлида. От себя скажу, что я за то, чтобы проговаривать всё с командой и совместно находить лучшие решения.
Учитесь быть гибкими с командой
Вопреки тому, что нам рассказывали в вузе или в интернете, идеального универсального понимания рабочего процесса до сих пор нет. Я вот, например, пока не увидел правильного рабочего scrum-процесса, несмотря на то что пытаются почти все. Поэтому не советую брать какой-то манифест и бежать проповедовать его в команде.
- Главное ― рабочие процессы должны быть удобны всем.
Коллегам хочется проговаривать задачи детальнее? → Подрегулируйте процесс, чтобы проводить встречи для обсуждения задач.
Если сотрудники предпочитают сидеть и работать → раскидайте задачи между ними и уменьшите количество процессуальной нагрузки.
Одна из важных задач тимлида ― организовать ритм, в котором людям будет удобно работать изо дня в день.
Если сотрудники предпочитают сидеть и работать → раскидайте задачи между ними и уменьшите количество процессуальной нагрузки.
Одна из важных задач тимлида ― организовать ритм, в котором людям будет удобно работать изо дня в день.
Учитесь ценить время
Часто повышение по службе предполагает новые обязательства в довесок к уже имеющимся. Тимлиду команды разработчиков нужно не только кодить, но ещё и планировать наперёд и за всех ― времени будет меньше.
- Время нужно научиться ценить и мудро им управлять. Балансировать между должным вниманием к команде и решением задач тимлида.
Так, может уже больше не получаться подробно обсуждать каждый вопрос. Научитесь лаконично и вежливо превращать такие встречи в электронные письма или сообщения в мессенджере.
Находите время помогать тем, кому ваша помощь действительно нужна, но и на свои задачи тимлида оставляйте время. Нужно научиться фокусироваться на них: в календаре ставить окошко, в которое вас нельзя будет позвать на встречу, а в корпоративном мессенджере ставить статус «Не беспокоить». Помогать сотрудникам важно, но не нужно забывать и про свои личные KPI.
Научитесь делегировать задачи. Наверняка в команде есть сотрудник, кому вы можете передать важную работу. Умейте доверять вашим сотрудникам ― они это ценят.
Научитесь ценить время вашего руководства. Цены вам в их глазах не будет в таком случае. Если вы можете превратить встречу в сообщение ― так и поступите. Если вы собираетесь представить начальству решение или документ ― сделайте так, чтобы к нему не нужно было возвращаться.
В идеальном сценарии, если ни у кого никогда не возникает желания прийти к вам и поуправлять вашей работой, считайте, что вы справились безупречно 🙂
Находите время помогать тем, кому ваша помощь действительно нужна, но и на свои задачи тимлида оставляйте время. Нужно научиться фокусироваться на них: в календаре ставить окошко, в которое вас нельзя будет позвать на встречу, а в корпоративном мессенджере ставить статус «Не беспокоить». Помогать сотрудникам важно, но не нужно забывать и про свои личные KPI.
Научитесь делегировать задачи. Наверняка в команде есть сотрудник, кому вы можете передать важную работу. Умейте доверять вашим сотрудникам ― они это ценят.
Научитесь ценить время вашего руководства. Цены вам в их глазах не будет в таком случае. Если вы можете превратить встречу в сообщение ― так и поступите. Если вы собираетесь представить начальству решение или документ ― сделайте так, чтобы к нему не нужно было возвращаться.
В идеальном сценарии, если ни у кого никогда не возникает желания прийти к вам и поуправлять вашей работой, считайте, что вы справились безупречно 🙂
Читать также
Мнение автора и редакции может не совпадать. Хотите написать колонку для Медиа Нетологии? Читайте наши условия публикации.
Чтобы быть в курсе всех новостей и не пропускать новые статьи, присоединяйтесь к Telegram-каналу Нетологии.
Чтобы быть в курсе всех новостей и не пропускать новые статьи, присоединяйтесь к Telegram-каналу Нетологии.
Борис Гордеев
Инженер-разработчик в финтехе. Больше года был тимлидом в команде разработчиков в стартапе
Оцените статью