Тимлид, или Туда и обратно

от автора

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



Алексей Кудрявцев: Всем привет. Сергей, расскажи пару слов о себе?

Сергей Боиштян: На данный момент, я старший разработчик, был лидом, техлидом и просто разработчиком. Работаю в Авито, до этого в Тинькофф.

Даниил Попов: Давай сначала проясним, кто такой разработчик, какая у него ответственность и чем он занимается на работе.

О роли разработчика

Сергей Боиштян: Разработчик — это в первую очередь роль, а не конкретная позиция. В IT сейчас много людей, которые одновременно могут и разрабатывать, и выполнять иные функции.

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

Разработчик — роль, в которой инженер помогает реализовывать фичи продукта.

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

Даниил Попов: За что отвечает разработчик?

Сергей Боиштян: Сейчас набирают популярность практики CI/CD и на разработчика ложится ответственность взять фичу, самостоятельно ее реализовать, с помощью средств автоматизации протестировать, либо быть на связи с тем, кто ее тестирует, и проконтролировать ее выпуск в релиз.

Даниил Попов: Если коротко: довести задачу в Jira от ToDo до Closed через все 500 статусов.

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

О важности команды

Даниил Попов: Задача разработчика — чтобы пользователи наслаждались качеством, оперативностью работы кода. Тогда что такое команда, какие задачи она решает? Различаешь ли ты виды команд?

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

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

Есть команды, где у каждого свой блок ответственности. В них разработчик в первую очередь пишет код, а во вторую — при необходимости саппортит тестировщика, отвечающего за качество продукта.

Алексей Кудрявцев: Слышал, что это не по Agile.

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

Даниил Попов: Лично мне не нравится понятие «общий код — общая ответственность». Кажется, что эта практика приводит к тому, что никто не несет ответственность. Как ты считаешь?

Сергей Боиштян: Недавно наткнулся в книге на фразу: «Если в команде ответственных больше чем один, либо их нет вовсе, то ничего не будет происходить, так как никто не захочет брать ответственность».

Мне нравится подход, когда все общее, но у тебя есть четкий фокус на неделю или на месяц.

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

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

Сергей Боиштян: Чтобы окончательно закопать общую ответственность, приведу пример из жизни. Обычно есть pull request, который «трогает» какой-то модуль. Если у этого модуля нет ответственного, то все ревьюеры, подумав, что другой оставит более полезный комментарий, посмотрят внутрь мельком. В итоге код превращается в мешанину. А на вопросы «почему тут так» появляются ответы «я сделал, мне никто ничего не ответил, я решил, что это эффективно», а дальше это эволюционирует в фразу «так исторически сложилось, не трогай».

Про базовые обязанности тимлида

Даниил Попов: Мы постепенно подходим к понятию «лида» как человека, который в себе эту ответственность сосредотачивает. Какие обязанности у такого человека?

Сергей Боиштян: Лид — это тоже роль. Его обязанности разнятся в зависимости от того, в какой команде он находится. Если мы говорим про команду, где все равны, то лид направляет членов команды, так как им часто сложно прийти к консенсусу. Тогда главная задача лида — привести любой спор к продуктивному окончанию, при появлении какого-либо вопроса, как можно быстрее и эффективнее его закрыть. Лид помогает остальным высказать свое мнение и остается беспристрастным с учетом, что также владеет экспертизой. Со стороны может показаться, что эту роль могут исполнять scrum-мастера. В моем понимании, scrum-мастер находится вообще сбоку и может фасилитировать встречи, но я за то, чтобы эта роль оставалась за тимлидом.

Если же в команде функции четко разделены, то тимлид становится еще и человеком, владеющим процессом. Он понимает на каждом этапе, кто что делает и за что отвечает.

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

Алексей Кудрявцев: У меня создается впечатление, что лид делает все. Ты и архитектор, и scrum-мастер, и людей должен находить, и уметь их фасилитировать. Это огромный набор. Это не одна роль, а несколько. Где здесь правда?

Даниил Попов: Самое главное, что при этом ты не программируешь.

Алексей Кудрявцев: Ну, ты же пытаешься.

Даниил Попов: Ключевое слово — «пытаешься». Написал три строчки, тебя отвлекли и все.

Сергей Боиштян: Лид — это человек, которым затыкают дыры в команде. В каждой команде вне зависимости от формата есть проблемы, и ответственность за них необходимо на кого-то переложить.

Алексей Кудрявцев: Мне кажется, что лид работает с людьми и их мотивацией, а есть отдельно архитектор, который отвечает за код.

Даниил Попов: Я различаю понятия «тимлид» и «техлид». Техлид — это человек, который отвечает за техническую сторону продукта: какие библиотеки, паттерны использовать, какую инфраструктуру применить. Тимлид — это про people management. Эти роли не пересекаются. Можно попробовать эти роли объединить, но очень сложно следить параллельно за архитектурой и 1:1.

Тимлид — это лидер команды, который ведет команду к светлому юзерскому будущему.

Сергей Боиштян: Вернемся к определению «команды», где куча людей делают что-то одно. Для того, чтобы делать что-то эффективно и оставаться командой, нужен тимлид, который лепит из разрозненных инженеров единое целое, дает реализовать потенциал каждого, сделать продукт лучше.

Даниил Попов: Если бы в басне про лебедя, рака и щуку был тимлид, они бы затащили куда надо.

Откуда берутся тимлиды

Даниил Попов: Интересно понять, как тимлидами становятся. Я накидал четыре способа. Первый: тимлидом назначают лучшего разработчика. Второй: назначают самого опытного. Третий: назначают за другие заслуги, только не придумал за какие. Ну и четвертый вариант, когда разработчик сам идет в лиды. Как считаешь, какие из этих вариантов жизнеспособны?

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

Из твоих вариантов можно оставить два: когда инициатива идет от тебя и когда она идет извне. В моем случае она шла от меня, но я видел в соседних командах обратную ситуацию. Брали опытного разработчика из команды, аргументируя, что он уже знает культуру, умеет общаться. Никто не отказывался, так как предлагали тем, кто понимал, что если не он, то больше никто.

Даниил Попов: У меня обратный опыт. Мой тимлид ушел и меня сделали тимлидом. Бытует мнение, что опытный разработчик станет хорошим тимлидом, но это в корне неправильно предположение. Недавно прочитал мысль, что, делая лучшего разработчика тимлидом, вы теряете лучшего разработчика и получаете плохого менеджера. Согласен?

Сергей Боиштян: Звучит как правда. Я встречал не так много хороших тимлидов. Как люди они мне все нравились, но часто меня не устраивало, как они исполняли свою роль. Мне казалось, что я могу лучше. Теперь, когда знаю, что не могу, я сформировал четкие критерии хорошего лида.

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

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

Вопросы роста

Даниил Попов: А куда двигаться дальше тимлиду? Head of mobile, CEO, CTO?

Сергей Боиштян: А зачем куда-то двигаться?

Даниил Попов: На нашем постсоветском пространстве бытует мнение, что нужно всегда куда-то расти. Если не растешь, значит жизнь прожил зря. И расти можно только с повышением позиции, с получением новой лычки. Я тоже раньше так думал, а потом понял, что это необязательный путь. Что для тебя значит рост?

Сергей Боиштян: Когда-то я прочитал о классификации сфер влияния человека, где рост означал увеличение одной из сфер влияния — профессиональной, финансовой, социальной, семьи и здоровья. Полгода назад я узнал про Ценностный опросник Шварца. Тогда я не мог понять, хочу быть лидом или нет. Я искал опросники и тесты, пытаясь осознать, какая из сфер для меня важна. Хочу ли я быть известным разработчиком или большую зарплату, либо хочу work-life balance и мне без разницы, на каком я уровне я нахожусь.

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

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

Расти и развиваться нужно, чтобы быть счастливым.

Просто люди часто растут и развиваются не туда, так как не осознают, что на самом деле для них важно.

Алексей Кудрявцев: Получается, что самое важное — понимать, куда ты растешь.

О плюсах и минусах тимлидства

Даниил Попов: Давай разберемся, что тебе нравилось в твоей роли, а что нет.

Сергей Боиштян: Сначала еще чуть поясню, почему я захотел стать лидом. Когда я пришел в разработку, я кайфовал от того, что у меня получается. Затем я попал в команду и начались проблемы на pull request’ах из-за недопониманий и дискоммуникации. Рационального разговора не получалось, а внутри накапливалось желание делать все эффективно. В таких ситуациях я призывал лида на помощь, но его на всех не хватало.

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

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

Алексей Кудрявцев: Я так понял, что ты хотел писать код, но так как ты хочешь.

Сергей Боиштян: Я хотел писать код быстро.

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

Сергей Боиштян: С какими проблемами я столкнулся? Мне повезло, что не пришлось никого смещать или бороться. Я просто пришел лидом в новый проект, набрал себе людей в команду, они принимали мои принципы, но в какой-то момент в команде появились не совсем согласные со мной люди.

Даниил Попов: Ты их нанял?

Сергей Боиштян: Да, так получилось. Я научился говорить и общаться, но не развил в себе самокритику и объективность к собственным идеям. Я пришел к выводу, что надо не продвигать свои мысли, а понять, какая мысль правильная и продвигать ее. Это было непросто. У нас постоянно были споры. В команде был человек с правильными мыслями, которые он не мог донести, и моя задача была в том, чтобы донести ее за него, а у меня, конечно, было собственное эго и точка зрения.

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

Я беру рациональные мысли людей, помогаю их донести, а сам ничего не делаю — насколько это полезно? Может полезнее мне реализовывать эти мысли как разработчику?

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

Обратно в разработчики

Алексей Кудрявцев: Тебе не пугало, что, уходя из лидов в разработчики, ты терял перспективу роста, что будешь senior-разработчиком до конца своих дней?

Сергей Боиштян: У меня не было сомнений и долгих размышлений. Это накапливалось, и в какой-то момент я почувствовал, что тимлидерство не приносит удовольствие. Я подумал, какие у меня есть пути, кем я могу быть, осознал, что могу быть только разработчиком, и согласился с этой мыслью.

Я не пытался решить все сразу, а пытался вернуться в то состояние, когда я был счастлив.

Даниил Попов: Ты сказал, что стал тимлидом, потому что хотел быть властелином решений. Когда ты снова стал разработчиком, снова стал исполнителем. Тебя по прежнему это беспокоит?

Сергей Боиштян: Это был сильный дискомфорт. Вариантов было два: либо смириться с тем, что тебе говорят, либо научиться говорить другим так, чтобы тебя слышали и меняли мнение. Я снова начал развивать в себе качества, которые прокачивал в роли тимлида, но теперь не с целью достижения консенсуса, а с целью доносить мнение так, чтобы его слышали, и понимать мотивацию человека.

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

Алексей Кудрявцев: Каким образом ты развивал в себе эти умения слушать, понимать себя?

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

А как же зарплата?

Алексей Кудрявцев: Лидство — это еще и более высокая зарплата. Как стать снова разработчиком, не потеряв в деньгах?

Сергей Боиштян: Я понимаю, что в этом мире всегда будут люди, зарабатывающие больше меня.

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

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

Даниил Попов: Денежная мотивация работает от трех до шести месяцев, а потом перестает.

Сергей Боиштян: Я такого факта не слышал, но соглашусь.

Алексей Кудрявцев: Когда денежные потребности будут закрыты, вылезут более важные потребности, которым он будет уделять внимание. Например, более крутые проекты.

Сергей Боиштян: Я смотрел видео на TED, где спикер приводил примеры экспериментов, подтверждающих разные виды мотивации. Одним людям обещали деньги за выполнение какой-то задачи, другим ставили условие придумать уникальное решение для этой задачи. Выяснилось, что первые делали задачу медленнее, чем те, у кого стоял челлендж придумать новый способ. Спикер, автор книг по мотивации, объяснял, что современных людей мотивирует ответственность и свобода. У меня не стояло мысли о деньгах при переходе в разработку. Оплата на уровне рынка — это подтверждение того, что ты хороший программист и тебя ценят. Сравнивать с лидом — это не для меня.

Алексей Кудрявцев: Многим некомфортно даунгрейдится при переходе с высокооплачиваемой должности лида. Как жить с мыслью, что потеряешь в деньгах?

Сергей Боиштян: Вариантов два: найди место, где должность разработчика оплачивается выше или найди еще один способ заработка.

Про планы

Алексей Кудрявцев: Теперь, когда ты снова разработчик, как видишь развитие в этой роли?

Сергей Боиштян: Не знаю, какие ценности у меня будут на первом месте через пять лет, но до этого срока мне будет комфортно в своей роли, хотя через год я, конечно, могу сказать совершенно другое. У меня есть долгосрочный стратегический план, и через десяток лет, если я буду продолжать быть хорошим инженером, смогу стать хорошим представителем верхушки IT.

Алексей Кудрявцев: Но технологии же устаревают!

Сергей Боиштян: Скажи это своему CTO.

Алексей Кудрявцев: CTO — это же не инженер, а лидовское направление.

Сергей Боиштян: Я нырнул в лидство и понимаю, какие навыки нужны, что быть руководителем. У меня всегда есть возможность вернуться в лиды и продолжать развиваться как инженер.

Еще одна альтернатива появляется, когда ты начинаешь выступать на конференциях — это возможность стать developer advocate.

У инженера много путей развития, даже вот писать подкасты и статьи.

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

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

Даниил Попов: Я не согласен, что CTO обязан быть отставшим от технологий, он же может саморазвиваться.

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

Даниил Попов — Зависит от человека: все и по чуть-чуть или в глубину.

Сергей Боиштян: Мне нравится развиваться в ширину.

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

Понятно, что это занимает у него больше времени, чем у того, кто копает вглубь.

Алексей Кудрявцев: Не было мысли, что лидство не соответствовало ожиданиям именно в конкретном месте и проекте, а в другом бы случае все получилось?

Сергей Боиштян: Доля правды тут есть. Я человек систематизированный и за четкие процессы. Возможно, я мог бы выполнять роль человека, который все организовывает и помогает двигаться. Теперь я понимаю, что много топлива в таком случае уходит на общение с людьми. Если я фоново это разовью и мне попадутся правильные люди, буду рад попробовать. Но это утопичная ситуация.

Советы

Даниил Попов: Дай два совета. Первый людям, которые хотят стать тимлидами, а второй — тем, которые понимают, что лидерство — это не для них.

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

Мой совет — поймите себя: пройдите тесты, порефлексируйте, поведите дневник, сходите к психологу.

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

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

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

Даниил Попов: Вывод: нет ничего стыдного, чтобы задауншифтиться.

В октябре на Saint AppsConf Сергей Боиштян будет рассказывать о своем виденье CI/CD. Про процессы, soft skills и все такое доклады тоже будут, мы же обещали. Например, Владимир Иванов планирует обсудить проблемы индустрии и рассказать, чем каждый из нас может помочь.


ссылка на оригинал статьи https://habr.com/ru/company/oleg-bunin/blog/461349/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *