Когда-то Юрий Орлов решил перейти из врачей в программисты. В 2018 году он устроился в Genix джуном, а сейчас он — тимлид VK Group. Начало истории вы можете послушать здесь, а в статье мы обсудим перипетии тимлидства — как опыт работы врачом помогает находить общий язык с людьми, должен ли тимлид писать код лучше членов команды, как работает Planning poker и что самое сложное в задачах тимлида.
Cтатья подготовлена по мотивам подкаста Moscow Python Podcast при поддержке курсов Learn Python.
Есть ли жизнь после первой работы
Если обрисовать прошлое крупными мазками, когда я ушел из Genix, я устроился на маленький стартап с зарубежным участием. Наш контракт действовал полгода. За это время компания переместилась из Европы в США, особой необходимости в моих услугах они не испытывали, и мы решили расстаться. Тогда я понял, что на тот момент я не был готов полностью себя мотивировать и ставить себе задачи — это было тяжело.
Я нашел отличную компанию, в которой проработал год и три месяца. Это была стандартная компания по разработке, скажем так, множества разных проектов. Меня брали под конкретный проект, где на тот момент только планировался пилот, чтобы участвовать в тендере для некой крупной компании. Поначалу задач было немного. А потом моя компания выиграла тендер, и выяснилось, что проект предназначался для Сбера. Моя команда из двух человек расширилась, и мы попали в Сбер.
Ещё врачом я заинтересовался Python, потому что он очень хорошо развивался в рамках Machine Learning. Я думал, что это будет интересно, но всегда получалось так, что на всех работах я приближался к ML, но никогда с ним не работал. Оказалось, что этот проект тоже был связан с ML. Мы делали систему, которая позволяла бы получать разные данные из огромного количества баз данных на всех территориях, где присутствует Сбер.
Мы автоматизировали всю эту работу. Это был огромный опыт — опыт работы в крупной компании и понимание того, через какие стадии проходит большой проект в одной из крупнейших компаний России. Мы прочувствовали на себе все меры безопасности, увидели, как проводится тестирование, прошли через несколько стадий вывода в стейдж, несколько стадий вывода в прод и, конечно, участвовали в общем празднике, когда все дошло до прода.
Когды мы запустили проект, стало немного скучно. Мы его ваяли с нуля, поэтому я в принципе все знал. Конечно, можно развиваться по накатанной, но мне хотелось попробовать что-то еще. Поэтому я устроился в компанию, занятую в индустрии ставок на спорт. Там познакомился с получением большого количества данных и столкнулся с высоконагруженными системами. Они были не лучшим образом собраны, и тем не менее как-то функционировали.
Компания планировала создать систему для обучения людей, которые следят за спортивными матчами и помогают ребятам вычислять разные проценты для назначения ставок. Такие люди нужны на сотни соревнований, которые происходят по всему миру. Им нужно отправлять данные в реальном времени, а ты должен эти данные в реальном времени собирать, сохранять и отправить им. Мы запланировали такую систему и начали её создавать, а параллельно выпустили обучающую систему.
В процессе мы столкнулись с очень нестандартной проблемой: появлялись люди, которые хотели обучаться по этой системе из других точек мира. Например из Вьетнама, Аргентины, Чили. Google может себе позволить иметь сервера в разных частях света, мы же до таких масштабов не доросли. Были проблемы со связью.
Там я впервые подошел к планированию не только для себя, но и для команды. Изначально в моей команде было два человека — я и тестировщик. Но мы разрастались, появилось несколько бэкендеров, фронтендеров. А потом появился полноценный тимлид. До каких-то вещей я дошёл сам, но он отшлифовал их и я увидел, как это должно работать правильно.
Когда VK стали искать тимлида на проект, я уже знал, что делать, и сам строил сложную систему, поэтому решил попытать счастья. В итоге устроился. Я старался добраться до самых разных областей, дотянуться до максимума сложных вещей в пределах досягаемости. Решая сложные задачи и находя решения проблем, я повысил свою квалификацию.
Что касается тимлидства как управления людьми, я обратился к своему прошлому опыту. Полтора года я руководил отделением УЗИ в 18 человек. Там я усвоил, как разговаривать с людьми, как их мотивировать, как ставить задачи. Потом айтишная специфика наложилась на полученный опыт, и я быстро это усвоил.
Что лучше: хороший разработчик или плохой тимлид?
Есть в среде разработчиков недобрая шутка: повышая разраба до тимлида или менеджера, мы теряем хорошего разраба и получаем непонятно какого тимлида или менеджера. В твоей работе роль тимлида на чём основывается больше: организовать людей, чтобы они всё правильно делали, или самому писать код правильно и этим подавать пример?
В первую очередь моя задача — это организация. Есть огромное количество деталей, которые разрабы избегают и не хотят ими заниматься. Я их прекрасно понимаю, сам таким был. Эти детали берет на себя тимлид.
Особенно это заметно в большой компании, где не одна твоя команда занимается продуктом и все вы движетесь в одном направлении, а есть соседние команды со своими продуктами, которыми можно и нужно пользоваться, чтобы не пилить свой велосипед. Когда ты обращаешься к другой команде, ты сталкиваешься с тем, что у них есть свои приоритеты. Если ты попытаешься и в это влезть, и параллельно код писать, у тебя что-то сломается — либо код, либо взаимодействие с другими командами. Поэтому организация подобных вещей это первостепенная задача. Какие-то встречи с разными командами, встречи планирования с продактами. В каких-то командах продакты есть, в каких то командах они приходящие, и порой ты можешь знать о происходящем в команде больше, чем их продакт, просто потому что ты с ними взаимодействуешь.
Что касается того, должен тимлид писать код или нет — я пишу код и не хочу от этого отказываться. Сомневаюсь что пишу отличный код, да и не знаю, есть ли люди, которые его пишут на отлично и не хотят что-то изменить. У меня в команде есть люди, которые пишут код лучше меня. Я знаю, почему: они постоянно на него смотрят и с ним работают. Я же прихожу и решаю определенные задачи, поэтому не всегда могу видеть весь проект постоянно. Одна из основных задач тимлида — это научиться делегировать и доверять своим сотрудникам. Когда ты можешь на них положиться, понимаешь, что они напишут рабочее решение, ты поднимаешься на одну ступень как тимлид.
Получается, в команде есть люди, пишущие код лучше, чем ты. Как ты оцениваешь, что они пишут код лучше? На что ты смотришь, как ты сравниваешь? У каждого разраба свои шкала и способ оценки.
Когда команда была небольшой, большую часть проекта я писал самостоятельно. Людей не было, на мне лежало меньше организационных задач, и я просто писал код. Пришли люди, посмотрели на код, изменили. И я смотрел на этот код и понимаю, что они классно переделали. Я, наверное, сделал бы тоже самое, если бы вернулся к тем задачам спустя время.
Так и запишем: «субъективно-эмоциональная оценка».
Тимлидские будни. Как отвоёвывать приоритет своих задач в других командах, что общего между управлением отделом УЗИ и управлением разработчиками, и какая из всего спектра задач самая сложная
Ещё ты упомянул, что помогаешь командам договариваться друг с другом. Это еще один интересный для разрабов вопрос: как командам синхронизироваться? У каждой команды есть свой продакт, свои бэклог, есть задачи, которая она не успевает сделать. И тут приходит тимлид соседней команды и говорит: «Мы тут пользуемся вашей API и поняли, что нужно внести несколько изменений, а то у нас не получается ей пользоваться». Естественная реакция продакта — не сорвать сроки, поэтому он встает на твоем пути и говорит: «Не пущу, у нас полный бэклог. Если возьмем твои задачи, то не успеем сделать свои и будет беда». Компания — большая структура, она понимает, что такое возможно, и поэтому разные компании у себя внутри обеспечивают разные механизмы сотрудничества отделов. Как у вас устроены эти механизмы и как ты ими пользуешься?
Люди применяют разные подходы. Я никогда не стараюсь забегать и говорить, мол, нам больше всех горит. Что такое организация планирования: когда видишь, что в будущем понадобится определенный функционал, выясняешь что у вас есть продукты и есть команды, которые делают похожее, ты, как тимлид, в голове должен держать, чем примерно занимаются соседние команды. Если ты понимаешь, что через месяц-два вам понадобится функционал, стоит заранее побеседовать с тимлидом, продактом. Сказать, мол, у вас все супер, классно, но спустя пару месяцев нам придется воспользоваться вашим продуктом.
Часто они сами заинтересованы тебе помочь, ведь ты хочешь использовать и развивать их продукт. Есть, конечно, запланированные дела, но часто бывает, что твой взгляд со стороны помогает им поставить задачи, о которых они даже не задумывались. Если ты это делаешь плавно, планируя заранее, тогда получается все очень неплохо. Сначала приходишь на планинги, запихиваешь задачу в бэклог. Через некоторое время снова приходишь на планнинг и говоришь: «Вот такая задача есть, давайте ей поднимем приоритет». Сама команда к тому моменту уже познакомилась с задачей и с тобой, и перестаёт воспринимать её как что-то чужое и навязанное. Скорее всего, всё уже будет готово к нужному моменту.
То есть, используете подход совместного долгосрочного бюджетирования. Хороший поход. Ты также упомянул, что в работе тимлида тебе помогает опыт руководства отделением УЗИ. Скажи, если проводить параллели, что общего между организацией работы технических и медицинских специалистов отделения УЗИ и организацией работы команды разработки — программистов, тестировщиков, девопсов и прочих — что общего и в чем разница?
Общее в первую очередь то, что это люди, а не машины. У всех могут возникать свои проблемы, болезни и так далее. Ты должен держать в уме, что что-то подобное может случиться — то есть всегда должен быть план Б на случай, если этот человек по какой-то причине не сможет продолжать работу. Задачи для руководителя медицинского и IT подразделения очень схожи. Человек может заболеть, уволиться, выгореть, это тоже встречается в медицине — не реже, чем у айтишников, если не чаще.
Когда ты организуешь работу большого числа людей, ты понимаешь, что все люди работают по разному. Какой-то человек мотивирован и будет выдавать больше и быстрее, но с подобными людьми главное не закидывать их большим кол-вом задач. Иначе ты собьешь его мотивацию и он быстро выгорит. В лучшем случае он станет гораздо хуже работать, в худшем — просто помашет тебе рукой. Тоже самое и с УЗИстами, которым ты закидываешь слишком много пациентов. Если я вижу, что какие-то задачи срочные и я не могу их кому-то впихнуть, я беру их на себя. Это будет не идеальным решением, но я обеспечу базис, который будет работать и который можно использовать, и в будущем мы, может, к этому вернемся. Оценки возможности людей очень схожи и в IT и в медицине. Решения тоже примерно одинаковы, просто ты используешь разную терминологию когда об этом рассказываешь.
Вы пользуетесь Planning Poker. Давай о нем поговорим. Есть мнение, что технология пришла к нам из глубокой старины. Для чего это было сделано: инженерные команды делали бизнес автоматизацию. Эта бизнес-автоматизация, как правило, была довольно типовая. Берем сап — натягиваем. Берем следующий глобус — натягиваем. Поэтому условно десять человек, которые занимались натягиванием сапа для какой-то компании, были более-менее взаимозаменяемые. Они могли одинаково оценить, сколько времени займет та или иная кнопочка, та или иная бизнес-логика, тот или иной запрос в бэкенд, и Planning poker хорошо работал. Сейчас же у нас программисты в команде вообще не взаимозаменяемые. Кто то хорошо знает JSON:API, кто-то GraphQL, кто-то Java и т.д..
Как по твоему опыту люди оценивают, насколько хорошо они могут оценить работу другого? У тебя нет такого, что в команде только один человек, который эту задачу и делает и оценивает, а остальные в лучшем случае могут мяукнуть?
Есть люди, работавшие с технологиями, а есть те, кто о них слышал в лучшем случае. Естественно, при оценке подобных задач я буду склоняться к опыту того человека, кто с этим работал. Я не могу сказать, оценивает он хорошо или плохо, если я сам с подобными вещами незнаком. Тут недостаток в том, что ты рискуешь не получить задачу за указанный тобой срок — 10 помидоров, например.
Если есть 5 человек, и 2 из них работали с технологией недавно, а трое — три года назад, то ты, конечно, будешь учитывать мнение всех, но склоняться к мнению тех, кто работали в менее далеком прошлом.
Еще очень важная деталь: я стараюсь, чтобы с используемыми технологиями знакомился каждый сотрудник в команде. В спринтах может будет очень мелкая задачка, на один сторипоинт к примеру, но эта задачка позволит человеку залезть в этот код или сервис и посмотреть, как это работает.
Разработчики — народ активный, смышленый и старается что-то почитать, если что-то не знает. Соответственно, сделав простую задачку, он про эту технологию почитает, и в следующий раз, когда будет оценка задач из этой технологии, он сам будет понимать лучше весь этот процесс. Ваш технологический стек нужно распределять по всей команде. Пусть даже кто-то будет делать больше, а кто-то меньше, но все по чуть-чуть должны этим пользоваться. Тогда и оценки станут ближе к реальности со временем, и люди будут развиваться.
По сравнению со временем, когда ты руководил УЗИ, что для тебя самое сложное из всех твоих активностей?
Учеба. В процессе всего моего развития в IT я стараюсь учиться. До момента, когда я стал тимлидом, это получалось гораздо лучше, потому что оставалось больше времени, больше психоэмоциональной энергии. Ты не пропускаешь через себя проблемы и задачи всей команды, и мотивации и желания куда-то расти остается больше. Сейчас с этим сложнее. Подозреваю, что это самая сложная задача для меня — помимо организации, планирования и написания кода, заставлять себя почитать о чем то новом или записаться на курсы для IT.
Cтатья подготовлена по мотивам подкаста Moscow Python Podcast при поддержке курсов Learn Python.
