Давайте вернемся на два года назад, когда я был разработчиком.
О чем я только думал? «Я хочу стать лидером команды.
Это круто, он решает все вопросы, получает больше денег, им становятся после старшего».
.
Тогда не было никого, кто бы мне сказал: речь вообще о другом.
Мне пришлось учиться на своих ошибках.
Я дважды становился руководителем команды
У меня есть такая черта: я стараюсь наводить порядок, систематизировать и выстраивать процессы.Поэтому меня всегда тянуло к чему-то большему, чем просто написанию кода.
В моем первом стартапе, назовем его «Т», в процессах разработки царил полный хаос.
Сейчас я бы вряд ли там работал, но тогда там было очень атмосферно.
Представь.
Много параллельных клиентов.
Менеджер пошел напрямую (и конкретно) к разработчикам.
Мы часто не укладывались в заявленные сроки и сидели допоздна.
Помню, как однажды в 20 часов позвонил начальник и попросил прийти на работу, чтобы закончить фичу для заказчика, потому что «он объявил срок на завтрашнее утро».
Но в T мы были «семьей».
И делали все сами – как могли.
Я помню, как устанавливал Ubuntu на стоечный сервер, который нам дал один из инвесторов.
Когда я включил его, раздался звук взлетающего вертолета! Там я дослужился до статуса технического директора и работал с командой из 10 человек.
По сути, там случился первый, по прихоти, опыт руководства командой.
В D, куда я пришел разработчиком, все было по-другому, особенно когда дело касалось процессов.
Компания внедрила классический Scrum: четкие спринты, диаграммы сгорания, демонстрации, планирование, Story Points, подготовка к будущему спринту.
Я был поражен качеством процесса, спокойно писал код и смотрел, как все работает. Потом я подружился со Скрам-мастером и начал задавать ему вопросы.
Он охотно отвечал и делился классными книгами.
Особенно запомнилась книга Хенрика Книберга «Scrum и XP: заметки с передовой».
Процесс в «Д» был построен близко к этой методологии: в результате все руководство и продавцы прекрасно понимали, когда будет результат. Я также присоединился к Skyeng в качестве разработчика.
В отличие от других моих компаний, здесь прекрасно реализована непрерывная интеграция: каждый день фичи попадают в продакшн.
В моей команде этот процесс больше всего напоминал Канбан.
У нас был отличный тимлид Петя.
На разговорах один на один мы могли обсудить все: от проблем со срывом сроков до настроек таск-трекера.
Иногда я просто давал отзывы, иногда что-то советовал.
Так Петя разобрался во мне и узнал об опыте руководства командой на «Т» и дистанционного обучения в Scrum на «Д».
В какой-то момент он предложил мне выступить в стендапе.
Операция «преемник» в моем случае выглядела так и заняла 6 минут)
А через неделю выяснилось, что в компании открывается новое направление, и в этот проект отправили Петю и часть команды.
Оставшимся ребятам нужен новый лидер.
Все происходит само собой, как будто невидимый Закон Притяжения подталкивает вас к лидерству в команде.
Когда компании нужен тимлид и все думают: «Где его взятьЭ», они часто нанимают ребят, которые:
- лучше организован
- быстро втягиваться в процессы и идеи команды,
- мотивированы и завоевывают авторитет в глазах коллег-разработчиков.
Так это сработало у меня и как минимум у нескольких коллег из других компаний, с которыми я разговаривал на эту тему.
И забавно, что все отметили: для совершения перехода не пришлось прилагать почти никаких усилий.
Здесь нужно объяснить, кто в нашем случае тимлид. Это определенно отличный программист, который хорошо разбирается в коде проекта и может при необходимости написать код самостоятельно (например, если кто-то из ребят заболел или в отпуске, а это срочно необходимо).
Но по функционалу вы скорее менеджер: общаетесь с бизнесом и другими командами, выстраиваете процессы внутри своих и почти не пишете код. У нас также есть должности технического руководителя, но только на крупных проектах.
Вот как выглядели примерные обязанности тимлида в Skyeng в начале истории: 
Но одно дело брать на себя задачи тимлида, а совсем другое – справляться с ними.
Что изменилось и как я с этим справился
Первые несколько дней живешь с ощущением эйфории, триумфа и восторга.Конечно: ты стоишь у руля целой команды, на тебя рассчитывают, у тебя больше возможностей и ответственности! Прошло несколько лет с момента ухода из «Т», я набирался опыта, анализировал свои ошибки, видел передовые процессы и методологии и работал над ними.
Все это придало мне сил и уверенности для моей второй попытки возглавить команду.
Однако со временем чувство эйфории прошло, и началась повседневная жизнь.
Это то, что я заметил про себя.
Нужно быть морально готовым расстаться со своим «вечерним дзеном»… и подружиться с «ежеквартальными».
Результат работы тимлида обычно невозможно увидеть за один день или даже неделю.
Это и плюс, и минус.
В своем докладе «Отходы и неудачи при переходе от инженера к тимлиду» Артем Каличкин попадает в самую точку, говоря, что «программисты — одни из самых счастливых людей на свете».
Когда ты разработчик, каждый день у тебя есть откомпилированная сборка, выполненная задача, новая фича в продакшене — и в этом есть определенное удовольствие.
Некий дзен: дело сделал, можно со спокойной душой идти вечером отдыхать.
Тимлиду редко есть чем поделиться на стендапе: ведь вчера вы «планировали, звонили, читали почту и добавляли задачи в бэклог».
Такие результаты, как новый раздел на веб-сайте или крупная функция в приложении, состоят из небольших шагов, которые вы и ваша команда предпринимаете каждый день.
За это время вы можете не написать ни строчки кода, но в целом у вас получится такой объем работы, который вы бы никогда не выполнили за это время.
Например, моя команда создала раздел «Темы обучения» для приложения Skyeng на iOS и Android: реализовала карту уровней упражнений, шкалу энергии для разных категорий учеников, ежедневные цели, трекеры прогресса в задачах, разные механики выполнения заданий.
открытки, озвучка и многое другое.
Тот же раздел в приложении.
Оценить количество экранов и механику одного урока можно в гифке: прогресс ускоряется
Во многом это история о делегировании.
Нужно бороться с привычкой все делать самому.
Фактически, чтобы стать настоящим тимлидом, вам необходимо научиться программировать руками разработчиков вашей команды.
Неопытный тимлид может легко стать узким местом для команды.
.
Чем меньше разработчик отвлекается от работы, тем идеальнее результат и команда.
Поэтому у него есть портфель задач с приоритетами, стендап и еще пару встреч в неделю.
А если нужно спланировать новую фичу для работы, обнаружен критический баг, продукт не работает или у команды есть вопрос, тянут тимлида.
Чтобы всё и все работали, приходится много общаться.
Вы рискуете превратиться в «оператора колл-центра» — и если не прекратить это, выгорание гарантировано в течение одного-двух месяцев.
Здесь я хочу поздороваться и сказать искреннее спасибо моему продукту.
Увидев эту проблему, он отправил меня читать «Джедайские техники» Дорофеева, «Тайм-менеджмент» Архангельского, а также изучать каналы и чаты для тимлидов, записи с конференций и так далее.
Практики, которые я изучил, помогли устранить недостаток внимания.
Я всех предупредил, что буду проверять почту 1-2 раза в день, стал устраивать дни без встреч и звонков, письменно планировал свой рабочий день (даже пытался внедрить такую практику в команде, но разработчики этого не любят) .
Я менял приоритеты только в том случае, если происходило что-то действительно критическое.
В результате запланированные дела больше не откладывались.
В общем, мне пришлось ломать свои привычки и срочно осваивать кучу полезных приемов.
Навыки, необходимые руководителю, не развиваются в ходе разработки.
Как руководитель группы вы становитесь активным участником торговых отношений между бизнесом и развитием.
Цель любой компании — прибыль, поэтому заказчик хочет получить от разработки множество качественных функций в короткие сроки.
Разработчики стремятся делать работу качественно, но не торопясь.
В этой картине тимлид должен сохранять необходимый баланс между качеством, скоростью и объемом решаемых задач.
Для этого необходимо построить доверительные отношения с заказчиком, чтобы он понимал, чем занимается команда, сколько времени займет вырезание той или иной фичи, успеем мы или нет, что сделать, чтобы мы успели.
.
Вам необходимо развивать эти «мягкие навыки» и в то же время твердо отстаивать позицию и принципы команды.
А еще подумайте о процессах, форматах, архитектуре пайплайна: как к вам приходят задачи, как они выполняются, как фиксируются, как идут в производство.
Конечно, сами навыки можно развивать.
Но нужно быть готовым, что это приведет к определенной трансформации личности.
Больше не лидер команды: как не потерять себя и снова найти себя
Два года назад я считал, что тимлид — это следующий шаг в эволюции программиста.Сейчас я думаю, что это другая, параллельная ветка развития.
Исход перехода во многом зависит от каждого человека – и вы не узнаете, пока не попробуете.
Эту роль необходимо опробовать.
И не месяц, не два.
Я думаю, минимум шесть.
Еще лучше – год или два.
Высока вероятность, что будет сложно, вам захочется вернуться назад, не добившись результата.
Я бы посоветовал вам поставить себе срок и сказать: «Я не делаю промежуточных выводов до конца этого периода.
Я протестирую это и в конце приму решение, подходит оно мне или нет».
Лично я так и сделал.
Проработав лидом полтора года (с сентября 2018 по февраль 2020), я осознанно решил уйти с этой должности и вернулся к разработке.
В то же время руководитель группы канал которого я читал, вырос и стал техническим директором в моей компании.
Мы всегда удаленно, основное общение в Slack: поэтому «все перемещения записываются».
Все получилось как на картинке: коллега, которого я предложил, пробует себя в роли тимлида, а я наслаждаюсь «вечерним дзеном» в рамках другой команды.
А этим летом я и еще пара ребят, прошедших аналогичный путь, провели внутреннюю встречу по поводу нашего опыта.
И самый главный вопрос, который возник у слушателей: ок, а как ты понимаешь, когда думаешь, куда развиваться дальше, подходит тебе роль тимлида или нет? И пришла идея обсудить это в публичном формате с:
- Егор Толстой (подкаст и курсы «Подлодка») — он сделал выбор в пользу продакт-менеджмента и расскажет о моменте, когда понял, что устал вести разработку,
- Вадим Мартынов (сообщество Контур и RndTech) — он вернулся к разработчикам и расскажет, как переучивался писать код и как все это сказалось на финансах,
- И Евгений Кот (Wrike и тот же репортаж о боли тимлида) - в качестве ведущего.
А если у вас еще есть силы, давайте пообщаемся в Zoom. Здесь вы можете положить напоминание календаря .
Присоединяйтесь к обсуждению «MoreNotTeamLead» или смотрите его в записи.
Надеюсь, наш опыт будет вам полезен, ведь два года назад я тоже так думал.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Ваше отношение к вопросу 36,39% Я разработчик, не хочу быть лидом 135 20,49% Я разработчик, хочу быть лидом 76 19,41% Я тимлид, я хорошо 72 9.97% Я руководитель команды, я плохо себя чувствую 37 13.75% Я больше не руководитель команды Проголосовал 51 371 пользователь.
65 пользователей воздержались.
Тэги: #Карьера в IT-индустрии #программирование #Управление разработкой #Управление проектами #тимлиды и разработчики #грабли везде #уроки ошибок #я тимлид почему меня это ранит
-
Выпущен Ext Js 4
19 Oct, 24 -
Wpa Теперь Можно Взломать За 1 Минуту
19 Oct, 24
