Тимлид Очевидность

Я принес. Пучок подкастов Я в шутку называю себя подкастологом, потому что слушаю и смотрю несколько десятков разных ИТ-подкастов. А еще и два подкаста веду в компании своих товарищей. Я начал увлекаться подкастами году в 2013-м. Капец, больше десяти лет прошло. Для меня это было окно в разные увлекательные и полезные идеи и новости из индустрии. Пожалуй, для меня подкасты даже интереснее, чем доклады на конференциях (хотя я не умаляю их важность). Так что у меня есть чем с вами поделиться сегодня. Олдовое Еще в 2020-м году я писал пост/тред про подкасты. Аудио подкасты К посту я прикреплю два скрина (в один не влезает) из Pocket Casts со списком аудио подкастов, которые я слушаю. Пока скринил, проверил подкасты на активность и с сожалением обнаружил, что многие клевые подкасты перестали быть активны во второй половине прошлого года. Папка с миксом Папка в телеграме с миксом активных аудио и видео подкастов https://t.me/addlist/PCvdlc8oAE80NmEy

Приглашаем опытных ИТ-специалистов на One Day Offer в ГК «Иннотех»! ⚡️ Если ты искал работу в финтехе, присоединяйся к команде разработки революционной core banking платформы ⚡️ В команду нужны: 🔵BE-разработчики, 🔵системные аналитики, 🔵тимлиды, 🔵архитекторы Важен опыт работы от 2 лет. Что предлагаем: 🔵высоконагруженные системы, передовой технологический стек (Spring Boot, Quarkus, Kotlin) и микросервисную архитектуру, 🔵удалёнку, ДМС и множество бонусов, 🔵развитую культуру и команду профессионалов. Подробнее о вакансиях на сайте. 🗳 Успей подать заявку Реклама. Информация о рекламодателе. erid: 2SDnjdmn2MF

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

Перформанс ревью. Плюсы, минусы, подводные камни В этом выпуске мы поговорили на животрепещущую для бигтехов тему – перформанс ревью. Вокруг этого процесса куча споров. Много и сторонников, и противников. Тем не менее, это практически стандартная процедура для многих крупных компаний, так что разбираться точно надо. Я специально постарался поднакинуть для драматизма, но мои товарищи неплохо это всё отбили :) Описание выпуска, список поднятых вопросов, ссылка на прослушивание тут. Приятного прослушивания! Приносите в комментарии свою трактовку плюсов и минусов ревью. Всегда интересно узнавать чужой опыт и мысли.

Я принес. Что такое жизнь без работы и что такое работа после саббатикала? Пару месяцев назад мы с коллегами делали митап в Питере на тему «Как быть счастливым на работе?». Сегодня хочу поделиться с вами одним из докладов митапа на очень интересную тему https://www.youtube.com/watch?v=vURgYlDurxk У многих моих знакомых идея того, чтобы долго (год и дольше) не работать, вызывает совершенно разные мнения: ⁃ Ну и правильно, от работы кони дохнут! ⁃ Я совершенно точно не могу не работать, вы чего? ⁃ Наконец-то доиграю, дочитаю, досмотрю всё накопленное. ⁃ Займусь чем-то общественно полезным. ⁃ Бизнесок свой, давно задуманный, замучу. Мнения представлять можно разные, но мало кто реально в такой долгосрочный саббатикал ходил. А тут вот можно послушать реальную историю. Лично для меня в этой истории почему-то очень ярко отложилось то, как у докладчика изменился уровень потребления. Когда перерабатывал, то потреблял больше и дороже, как бы награждая себя за это своё старание и страдание. А когда перестал в этой суете крутиться, успокоился, то отказалось этого всего и не надо уже. А был ли у вас опыт, когда вы полгода-год не работали? Что делали? Как впечатления? А если бы сейчас так можно было, чем бы занялись?

⛱ Как сложно порой сходить в отпуск. Да ладно в отпуск, даже просто поболеть денек! А если ты Delivery Manager и управляешь парой команд и парой проектов, то даже на обед не каждый день получается отбежать. Такова жизнь руководителя. А вот был бы кадровый резерв – все было бы проще… Был бы готовый зам на все случаи жизни… ⚡️15 мая в 20.00 мск. приглашаем на открытый урок "Зам замыч – поговорим про кадровый резерв". На занятии обсудим: - что такое кадровый резерв; - как запустить кадровый резерв; - дополнительные бонусы кадрового резерва; - роль Delivery Manager. 👉Регистрация Вебинар приурочен к старту курса "Delivery Manager" в OTUS, на котором обучают управлять большими командами и портфелем проектов, выстраивать эффективные процессы и руководить тимлидами. При поступлении в группу курса возможны разные способы оплаты и рассрочка платежа. Реклама. ООО «Отус онлайн-образование», ИНН 9705100963

CAP-теорема тимлидов Недавно мы с Серафимой Чекулаевой готовили контент для совместного вебинара в KOTELOV подкасте на тему взаимодействия тимлидов и продактов. В ходе разговора Серафима сказала, что она будучи продактом, ценила в тимлидах три вещи: пипл-менеджмент, техническую компетентность и процессно-проектную деятельность. Но при этом она больше двух вещей не ожидала никогда. Я подумал: «Черт возьми, это же CAP-теорема, но про тимлидов» 🙂 Ты чего, дед, какая теорема? Есть такая идея, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: согласованность данных, доступность, устойчивость к фрагментации. Ну то есть имеются три стула, на все три не сядешь, на два можно. А какие два нужны именно вам, следует подбирать по вашей ситуации. Тимлиды То же самое и с тимлидами. Хочется, чтобы они всё сразу умели, хотели и делали. Но в реальности полный набор навыков еще поди найди у человека, а даже если и нашел, то появляется классическая ситуация, когда 80% времени надо код писать и 80% времени заниматься менеджментом. Так что можно проектировать нанимаемого тимлида (или себя самого, если угодно) согласно CAP-теореме для тимлидов. Понимаем, что за команда, чего не хватает, какие уже есть люди и компетенции в команде, и недостающие вещи дотягиваем тимлидом. Эта методика хорошо разрешает вопросы типа «А вот бывает техлид и тимлид. Кто из них что делает?». Техлид будет за технику и архитектуру, а тимлид – за внутренние и внешние коммуникации, ведения проектов, организацию рабочих процессов. Если в команде нет сильных технарей, тимлид будет покрывать техническую составляющую и на сдачу как-то поддерживать либо внутренние коммуникации между людьми, либо организацию и контроль комплексного ведения проектов, чтобы четенько, в срок, прозрачно, понятно для внешнего наблюдателя. В общем, смысл вы, надеюсь, поняли. А ты кто? Я бывал в разных комбинациях. В данный момент я про людей и процессы/проекты, работаю с очень сильными технарями. На прошлой работе был больше про разработку, а баланс между людьми и процессами варьировал в зависимости от того, что сильнее болит. Сначала болели (можно сказать, отсутствовали) процессы и занимался ими. Потом перестали болеть и я больше уделял внимание пипл-менеджменту. Потом стало казаться, что пипл-менеджмент и процессы/проекты приносят больше глобального профита, поэтому от техники стал отходить постепенно. Все три стула сразу На мой взгляд, такое возможно исключительно в том случае, когда они маленькие. То есть маленькая команда (2-3 человека) и небольшой набор проектов (чтобы не рваться по разным сторонам). Ну либо когда человек работает по 10-12 часов в день. Но тут у меня есть опасения по поводу долгосрочной перспективы, а также его мотивации и здоровья. Да и качество с такими регулярными овертаймами обычно хромает. Итог Забавная отсылка к оригинальной CAP-теореме заставляет задуматься: «Сам я на каких стульях сижу? А хочу на каких сидеть?». Пишите в комментариях, на каких стульях сидите вы. А если на всех трех сразу, и у вас это замечательно получается, то делитесь секретами успеха и продуктивности!

Нужны ли джуны в крупных IT-компаниях? На ютубе «‎Технологий в Контуре» вышел новый выпуск «Согласен / Не согласен». В шоу сталкиваются контуровцы разных ролей и обсуждают чувствительные тезисы, которые связаны с их профессиями. В этом выпуске столкнулись два разработчика: джун и сеньор. Ребята обсудили вечные темы: нужны ли джуны в крупных IT-компаниях, зачем в них вкладываться и каким компаниям это выгодно. Ну и почему джуны переоценивают свой уровень, приходя на крупный проект (а переоценивают ли?) Подписывайтесь на канал – шоу выходит раз в две недели, а еще там публикуют полезные доклады, выступления и трансляции митапов Контура для айтишников всех уровней

Я принес. Иногда лучше делать, а не планировать Сегодня на повестке дня довольно спорная, на мой взгляд, статья https://habr.com/ru/companies/ruvds/articles/788920/ Статья, кстати, бешено заплюсована на хабре. Моё личное мнение такое: в статье есть довольно инфантильно-популистская часть про то, что, грубо говоря, менеджеры не нужны, они паразиты и вообще только усложняют работу, гады такие. Я работал и работником руками (сисадмином, разработчиком), и менеджером (тимлидом, техническим менеджером проектов), и я своими глазами видел, как без разумного менеджмента происходящего всё может пойти сильно не так, а проекты развалиться, не дожив до релиза. Так что в этом пункте я не соглашусь. Однако соглашусь в том, что бюрократизация может выходить из разумных пределов, и люди тратят больше времени и денег на согласования формулировки одного названия или предложения, чем уже сели бы да сделали на уровне «достаточно хорошо» или даже «удовлетворительно». Про «политику» в офисно-корпоративных историях тоже скорее соглашусь. Нередко на позициях тимлида и выше уже приходится в этом как-то хотя бы минимально участвовать, либо утыкаться в стеклянный карьерный потолок, либо и вовсе прослыть нелояльным и отправиться на мороз. Интересно будет в комментариях прочитать ваше мнение о данной статье.

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