Это статья не сеньора, очередной раз пишущего про управление персоналом. Я - Junior Golang-разработчик! У меня нет ответов на все вопросы, но есть путь. Вот что работает, когда ты ещё сам учишься писать код, а уже отвечаешь за команду.
1. Как так вышло?
Еще в начале обучения в Яндекс.Практикуме я слышал о возможности поработать над реальным проектом, поэтому моя вовлеченность в обучение была максимальной, особенно во время дипломного проекта. Как итог, спустя 2 месяца, я попал в Мастерскую Яндекс Практикума — программу, где студенты и выпускники работают над реальными проектами для бизнеса и НКО под руководством экспертов из крупных компаний. Мой первый проект — разработка для Яндекс.Развитие.
Позиция тимлида не была назначаемой, но меня эта идея привлекала еще с самого начала учебы!
Первым важным этапом было знакомство с брифом от заказчика. Не так представлял себе работу старших коллег. Но если задуматься, кто со слов клиента в свободной форме должен сформировать образ рабочего проекта? У нас для этого есть руководитель по технической части, который провел декомпозицию и "нарезал" задачи. Но мы успели написать своё видение отдельных частей ТЗ и мне это понравилось. Благо, перед попаданием в Мастерскую, имел дело с небольшими ТЗ. Оно и дало понимание того, что я хочу видеть и что мне нужно для написания работающего кода. Но Мастерская – это другой уровень: бриф от заказчика, живые сроки и команда, за которую ты отвечаешь. У коллег были свои представления, по которым тоже были сформированы потенциальные задачи. Ждать никто не хотел.
"Я думал моя задача писать код, а оказалось - задавать вопросы."
2. Тимлидерство - это не повышение, это смена профессии
До начала понимания кто такой "тимлид" прошло 2 недели написания кода. Начали всплывать технические вопросы, вопросы касаемо отдельных членов команды, настала пора вникать в процесс коммуникации. Без потерь не обошлось. К счастью, речь сейчас о времени. Потерять члена команды из-за коммуникации было бы серьезной неудачей для меня!
Но что со временем? Начиная узнавать текущее положение дел у команды, причины замедления разработки, обсуждение вариантов реализации, участие в ревью... все это не прошло без следа.
Цифры оказались интересными. При возникновении спорных ситуаций или вопросов касаемо реализации задачи, до половины времени уходило на обсуждения. Знаю, что даже на уровне сеньоров и тимлидов такие дискуссии происходят, как и между тимлидами и техлидами. Что уже говорить о джунах! Но я не ожидал, на код останется только утро и вечер! И если сам вступаю в обсуждения, а у нас хватает и более опытных коллег, основный вопрос: "чем одно решение лучше другого?". Не по мнению, а языком фактов.
Основной вывод: не "я теперь главный", а "мне теперь сложнее развивать хардскилы"
3. Код-ревью, которого не было в pet-проектах
Пришла очередь и код ревью. Чтобы ускорить разработку приняли решение сначала проводить ревью самостоятельно и при отсутствии замечаний отправлять на ревью руководителю. Хорошо, что мы дошли до этого благодаря своему желанию учиться. В первом проекте, хотелось бы видеть четкие рамки и обязанности.
Что такое ревью со стороны опытного разработчика? - Поиск ошибок и оптимизация. Что такое со стороны набирающегося опыта? - Ответственность за чужой код. Новый навык, который кажется чем-то новым и непонятным.
В нашей команде есть Ольга Музыченко. Основной ревьюер, на чьем примере в ревью стал участвовать и я. Именно тогда времени для разработки кода стало еще меньше.
В жизни есть 1 важное правило: если тебя что-то пугает, это нужно сделать! Особенно что касается обучения. Начав делать ревью всё оказалось проще.
"Просто начать, даже если страшно"
4. 10 человек в команде - как не стать чужим
Когда все джуны, но ты тимлид — возникает странная ситуация. Формально мы на равных. По факту у меня есть обязанности, которые иногда требуют отстаивать позицию. И это некомфортно.
В команде есть Александр Фокин — опытный разработчик, изучающий Go вторым языком. Активный участник технических обсуждений, и его замечания всегда по делу. Как и Ольга, Саша — из тех, кто двигает команду вперёд своим опытом. В одной из задач он предложил использовать именованные параметры вместо позиционных в простой транзакции. Я не был уверен, что это даст преимущество, но сказал, что изучу вопрос. Посмотрел практики, примеры — в нашем конкретном случае выгоды не увидел, оставил позиционные. Но сам факт обсуждения был полезен: я запомнил этот паттерн и понял, что, если не могу сразу аргументированно объяснить "почему именно так" — нужно разобраться глубже.
Саша отнёсся к решению спокойно. Это и есть конструктивное обсуждение: кто-то предложил улучшение → изучили → приняли осознанное решение → оба согласны с итогом, даже если он не совпал с первоначальным предложением.
Но бывают ситуации, где приходится настаивать на своём, даже если это вызывает сопротивление. Здесь помогает понимание: моя задача не в том, чтобы всем нравиться. Моя задача — чтобы команда двигалась синхронно.
Как это делать, оставаясь "своим"?
Объяснять решения фактами, а не статусом. "Потому что я тимлид" не работает, когда ты джун.
Напоминать про общие цели до конфликта, а не после. Когда люди помнят, к чему мы идём, спорные решения принимаются проще.
Признавать, когда не знаешь. Лучше сказать "изучу вопрос", чем давить непроверенным мнением.
"Важно принимать решения лучшие для команды, а не для кого-то одного!"
Для управления всем процессом у нас есть проджект-менеджер Валерия Овчинник��ва. Очень помогает решать вопросы: общение с командой, контроль сроков, контакт с фронтом и куратором. Я работаю с сырой информацией о процессе, она выстраивает из неё полную картину.
5. Что я понял за это время
Первые несколько недель практически всё время тратилось на код, но дальше на код стало уходить максимум половина времени. Сейчас часто обсуждения решений, ревью или коммуникация с командой. Бывают дни практически без кодинга совсем. Сначала была просто усталость, но потом я понял если уделять время только коду – команда будет работать вразнобой. Иногда приходится выбрать вариант решения чужой задачи на текущем этапе, даже понимая, что есть вероятность его изменения в будущем. Если я напишу поменьше кода, но синхронизирую всех – мы делаем задуманное.
Главные выводы:
Тимлид-джун – это просто другая профессия с момента, как ты начал.
Моя задача не быть умнее всех, а обеспечить, чтобы команда приняла лучшее решение. Даже если оно не мое.
Временами пишу код в конце дня, когда уже устал и сложно сделать даже анализ своего кода. Это не оптимально, но необходимо: я джун, мне нужно не отставать технически и закрывать свои задачи в проекте. Тем более понимаю — без сильных хардскиллов не стать хорошим тимлидом в будущем.
Стоило ли? Да. Я научился принимать решения, за которые страшно. Научился говорить 'нет' более опытным коллегам. Научился синхронизировать людей, а не только код. Это сложнее, чем любая задача на LeetCode. И именно поэтому — ценнее.
