После периода стажировки и работы разработчиком начался следующий важный этап.
У меня появилась первая команда в том формате, где я уже стал тимлидом. Не просто разработчиком, который иногда помогает другим. Не просто человеком, к которому можно подойти с вопросом.
А именно тимлидом — с ответственностью за команду, задачи, сроки, качество и результат.
Для меня это был серьёзный переход.
Тимлид — не самый главный программист
Потому что тимлид — это не «самый главный программист». И не человек, который просто пишет больше всех кода.
На практике это роль, где ты продолжаешь быть техническим специалистом, но при этом у тебя появляется новый уровень ответственности.
Ты отвечаешь уже не только за свою задачу.
Ты смотришь, как движется весь проект. Понимаешь, кто чем занят. Помогаешь разработчикам, если они застряли. Распределяешь задачи. Участвуешь в оценках. Следишь за качеством. Проводишь код-ревью.
Общаешься с менеджерами, иногда с заказчиком. Объясняешь технические ограничения простым языком. Принимаешь решения, которые потом могут повлиять на весь проект.
И при этом код всё ещё никуда не исчезает.
Первый проект в новой роли
Первый проект, который я вёл сам в этой роли, был сложной площадкой. О ней я, наверное, расскажу отдельно, потому что там была своя большая история.
Но если коротко, это был проект, где хватало всего: сложная логика, наследие предыдущей команды, неоднозначные технические решения и задачи, которые нельзя было просто взять и быстро закрыть.
Именно там я по-настоящему почувствовал, что такое роль тимлида.
У тебя есть обычные обязанности: организовать работу, помочь команде двигаться вперёд, контролировать качество, не потерять сроки, держать в голове общую картину проекта.
Но просто раздать задачи и уйти в сторону не получится.
Потому что самые сложные места всё равно часто приходят к тебе.
Сложные места приходят к тебе
Сложные задачи. Непонятные участки кода. Архитектурные вопросы. Баги, которые никто не может быстро найти. Ошибки, которые проявляются только при определённых условиях.
И, конечно, особая категория — баги, оставшиеся после предыдущей команды.
Это вообще отдельный жанр.
Открываешь задачу. Читаешь описание. Кажется, что нужно поправить что-то небольшое. Потом открываешь код. Потом ещё один файл. Потом компонент. Потом шаблон. Потом какую-то старую логику, которая внезапно влияет на текущую задачу.
И через некоторое время понимаешь: это не баг, это археологическая экспедиция.
Такие задачи редко бывают красивыми.
Чужой код и ответственность
Там не всегда можно сразу написать новое элегантное решение. Часто сначала нужно понять, почему всё вообще работает именно так. Кто и зачем это сделал. Какие зависимости есть внутри.
Что сломается, если исправить проблему напрямую. Где можно аккуратно поправить, а где нужно остановиться и не трогать лишнего.
Сложные баги очень хорошо учат ответственности.
Потому что разработчик иногда думает: «Сейчас быстро поправлю». А тимлид должен думать шире: «Что будет после этой правки? Кого она затронет? Как это проверить? Не создадим ли мы новую проблему вместо старой?»
В этой роли я часто брал на себя самые сложные задачи. Не потому, что хотелось геройствовать. А потому, что понимал: если команда застряла, кто-то должен зайти в самую неприятную часть проекта и разобраться.
Иногда это означало несколько часов чтения чужого кода. Иногда — разговоры с менеджером, чтобы уточнить реальное поведение системы. Иногда — поиск причины бага, который на первый взгляд вообще не был связан с тем местом, где проявлялся.
Иногда — принятие решения, что быстрое исправление сейчас опаснее, чем более долгий, но правильный путь.
Тимлидство — не про власть
Постепенно я начал понимать, что тимлидство — это не про власть.
Это про ответственность.
Ты не просто говоришь людям, что делать. Ты создаёшь условия, чтобы команда могла делать работу нормально. Ты помогаешь не утонуть в хаосе. Ты берёшь на себя неопределённость. Ты закрываешь сложные вопросы.
Ты отвечаешь за результат даже тогда, когда сам написал не весь код.
И это очень сильно меняет мышление.
Когда ты разработчик, ты часто смотришь на задачу через призму своего участка работы. Когда ты тимлид, ты начинаешь видеть систему целиком: людей, сроки, риски, качество, технический долг, ожидания заказчика, возможности команды.
Когда опыт собирается в одну картину
Именно на этом этапе мой предыдущий опыт неожиданно собрался в одну картину.
Опыт руководителя студии помогал понимать процессы и коммуникацию. Период стажировки помогал помнить, каково это — начинать с нуля и не понимать половину происходящего.
Работа разработчиком на реальных проектах дала техническую базу и уважение к деталям. А роль тимлида заставила соединить всё это вместе.
Если оглядываться назад, путь получился не самый прямой.
Сначала руководитель студии. Потом стажёр PHP-разработчика. Потом разработчик на проектах. Потом первый опыт тимлида. Со стороны это могло выглядеть странно, но внутри всё было логично: я хотел расти по реальным навыкам, а не по названию должности.
И в итоге этот путь сработал.
Как из стажёра вырастает тимлид
Если много работать, не бояться начинать с нуля и держать в голове цель, можно пройти большой путь.
Даже если в какой-то момент приходится сделать шаг назад.
Даже если вчера ты был руководителем, а сегодня снова учишься как стажёр.
Даже если первые серьёзные задачи выглядят слишком сложными.
Путь строится не из красивых должностей. Он строится из решений, которые ты принимаешь каждый день: разобраться, доделать, не сдаться, взять ответственность, помочь команде, закрыть сложный баг, стать лучше, чем был вчера.
И иногда именно так из стажёра постепенно вырастает тимлид.
