26.05.2021 12:00
e-antonov 14 18300 Источник

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

Всё это я проговаривал на вебинаре в Хекслете тут.

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

Общий стаж моей работы в ИТ - около 14 лет. Я начинал с системного администрирования, потом перешел в разработку, поработав как в аутсорсе, так и в продукте. Несколько раз проходил путь от стажера/джуниора до тимлида.

Шаг номер 0. Зачем?

Итак, вам предложили стать тимлидом или вы сами захотели им стать. Что надо сделать в первую очередь? Хорошенько подумать, а надо ли оно вам.

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

Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же: 

  • Кто-то туда идет, потому что ему нравится работать с людьми, помогать им, развивать их. Тут безусловно найдется поле для деятельности. Море работы с людьми, развитие команды, помощь соседним отделам и т.д.

  • Кто-то - потому что хочет больше влиять на процессы и результат. Лично я отношу себя к данному лагерю. В этом плане тоже всегда есть чем заняться. Хромающие процессы по всем фронтам. От начала формирования бизнес задач и требований, до уже конечных результатов разработки.

Ложные цели, на которые не надо вестись:

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

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

  • Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.

Второе, на что надо обратить внимание при рассмотрении данной должности: тимлиды бывают разные.

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

Советую заранее узнать, что же именно от вас требуется. 

Спойлер: 80-90% вакансий на российском рынке - полуменеджер-полуразработчик. Формально говорится, что 60-70% времени надо писать код, а 30-40% менеджерить. При небольших размерах команды и порядочном работодателе это может неплохо работать. Лично у меня где-то сейчас 40 на 60 получается делить код с менеджементом. Хотя я чувствую, как при разрастании команды код отодвигается от меня всё дальше и дальше. 

Однако при недобросовестном или просто непонимающем работодателе, от вас будут ожидать примерно 100% менеджмента и 100% написания кода. Постарайтесь узнать об этом как можно раньше, чтобы СБЕЖАТЬ.

Шаг номер 1. Знание - сила!

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

Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.

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

  • М. Уоткинс "Первые 90 дней". Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность. Чем заняться в первые 90 дней. И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.

  • Дж. Ханк Рейнвотер "Как пасти котов". Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.

  • Ф. Брукс "Мифический человеко-месяц". Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.

  • Э. Голдратт. "Цель. Процесс непрерывного совершенствования". Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное. 

  • Д. Ким, К. Бер, Д. Спаффорд. "Проект "Феникс". Роман о том, как DevOps меняет бизнес к лучшему". Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.

  • Т. ДеМарко "Deadline. Роман об управлении проектами". Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.

  • Т. ДеМарко, Т. Листер "Вальсируя с Медведями". Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.

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

  • М. Ильяхов, Л. Сарычева "Новые правила деловой переписки". Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем. О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.

  • А. Орлов "Джедайские техники конструктивного общения". Коротко, по делу, с примерами. Однозначно рекомендую. И в работе пригодится, и в быту.

  • М. Гоулстон "Как разговаривать с мудаками". Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)

  • Роадмап тимлида https://tlroadmap.io/ Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.

  • Курсерный курс https://www.coursera.org/specializations/product-management Долгий и основательный курс, который покрывает всё про управление проектами. Выявление требований, план рисков, декомпозиция и распределение задач, аджайл техники и прочее. Вы справедливо можете заметить, что этот курс нужен менеджерам проектов, а не тимлидам. Теоритечески - да, а на практике возможно, что если у вас менеджер проекта и есть, то в каких-то деталях он может не очень разбираться. Тогда понадобится ваше участие.

  • Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodka https://podlodka.io/tlcrew Там много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.

Шаг номер 2. Общий план первоначальных действий

От теории переносимся к практике.

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

Далее, когда вы поняли официальную часть, надо погрузиться в неофициальную.

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

Какие назначить первые встречи, чтобы во всё это погрузиться?

Первым делом встретьтесь 1 на 1 с руководителем и, используя роадмап тимлида https://tlroadmap.io/, обговорите конкретные ожидания от вашей позиции. Главное помнить, что в роадмапе указано не "всё, что должен знать и делать тимлид", а "всё, что могут требовать от тимлида в разных компаниях", т.е. это объединение подмножеств хотелок из разных компаний. Так что, когда вам начальник скажет: "Ну, вроде выглядит норм, давай-ка всем занимайся," - вашей задачей будет ему объяснить, что всем заниматься невозможно физически и нужно проанализировать конкретную ситуацию, проект, команду, выделить наиболее важные области, которые вы и возьмете на себя.

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

  • взглянуть на текущую ситуацию с разных сторон;

  • узнать какую-то историю, которая творилась еще до вас;

  • проанализировать самих людей;

  • понять ожидания этих людей от вас.

Шаг номер 3. Распространенные проблемы. Предупрежден - значит вооружен

Здесь я коротко рассмотрю типичные проблемы и как с ними бороться.

Проблема с внешними коммуникациями

  • Авторитет и субординация в команде.

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

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

  • Отношения с руководством.

    Есть такая штука, как матрица доверие-прозрачность.

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

  • Общение с заказчиками.

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

Проблема с самим собой

  • Синдром самозванца. 

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

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

    Даже если вдруг окажется, что у вас не получается быть тимлидом, вы всегда можете (обговорите этот момент с руководством заранее) откатиться обратно, и в этом нет ничего плохого или стыдного. Хуже - совсем не попробовать, боясь неудачи, чем попробовать и зафейлиться. Даже негативный опыт будет очень ценным для вас, ведь только так вы сможете понять, точно ли вам надо работать на этой позиции. Сейчас мне сложно вспомнить, где именно и кем проводился опрос, но вроде статистика была такова, что около 30% тимлидов откатывается обратно в разработку. Так что искать себя, пробовать, заниматься тем, к чему душа лежит - это нормально.

  • Меньше пишешь код, теряешь позиции на рынке среди технарей.

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

    Тут надо понять, что ценность этой позиции не в том, чтобы быть самым крутым технарем (хотя хороший технический бэкграунд, безусловно, важен). Ценность в том, чтобы быть на стыке разработки и бизнеса, людей и процессов, хард и софт скиллов. Хороших разработчиков, на мой субъективный взгляд, больше, чем хороших тимлидов. Поэтому, теряя позиции на рынке труда разработчиков, вы можете открыть для себя новый, менее насыщенный кандидатами, рынок тимлидов.

Проблема с объемом работы

  • Неумение и страх делегировать.

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

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

  • Микроменеджмент и чайка менеджмент.

    Тоже большие проблемы не только начинающих, но и продолжающих. Если микроменеджмент растет из страха делегирования, то чайка менеджмент растет скорее из лени и безалаберности. Бороться нужно усердной работой над собой и самоанализом на тему "а не фигню ли я делаю, как менеджер?".

  • Остается мало времени на повышение квалификации.

    Действительно, у тимлидов в среднем остается меньше времени, чем у рядовых разработчиков, чтобы что-то изучить, завести пет проект и т.д. Какой-то серебряной пули тут нет. Кто-то выделяет себе немного времени на работе, кто-то в дороге до/с работы, кто-то по вечерам. Главное, что я могу тут посоветовать - внимательно выбирать то, чему вы планируете учиться, и учиться правильно, без сумбура и иллюзий компетентности.

  • А чему учиться-то, хардам, или софтам?

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

    Стоит ли совсем бросать хард скиллы? В кругах тимлидов ходит много споров об этом. Лично я не бросаю. Качаю и харды, но времени на это у меня остается довольно мало. Раньше меня это расстраивало, а сейчас нет, потому что я понял и прочувствовал, что как менеджер я могу принести проекту и команде больше пользы, чем как разработчик.

Проблемы со здоровьем ментальным и физическим

  • Гигиена труда и образ жизни.

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

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

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

    - Помните, что за пределами монитора и работы тоже существует жизнь. Иначе можно в какой-то момент понять, что в последние N лет кроме дедлайнов, тасок в жире, проектов и заказчиков вы ничего и не видели, хотя мечтали (возможно) о чем-то другом.

  • Важность рефлексии, что в работе, что в быту.

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

Шаг номер 4. Полезные качества для тимлида

Полезные качества, которые надо в себе взращивать:

  • Умение не сойти с ума при многозадачности.

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

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

    Умение разговаривать на языке собеседника.

    Важнейшая суперсила. Программист говорит одно, инфраструктурщик - другое, заказчик/менеджер - третье, и никто не может разобраться, что делать. А тимлид приходит и понимает, что они говорят об одном и том же, объясняет это такими словами, что все и поймут о чем речь, и разберутся, что делать, чтобы достичь необходимый результат.

    Умение говорить "нет".

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

    Дисциплина.

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

  • Эмпатия.

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

Шаг номер 5. Что делать дальше?

  • Продолжайте учиться.

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

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

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

  • Продолжайте (или начинайте) общаться с разными людьми в индустрии.

    Я поработал и пообщался с довольно большим количеством программистов и тимлидов из разных (десятки) компаний, и оказалось, что многие из них не высовывают нос за пределы своей работы, своего отдела. Люди не знают, как обстоит с технологиями, процессами, общением, условиями труда в других компаниях. Это незнание толкает их на переизобретение одних и тех же велосипедов, а также не позволяет хоть сколь объективно оценить положение дел в своей компании.

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

  • Всегда критически мыслите.

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

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

Дополнительные материалы

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

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

Успехов!

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