Product Developer

Онбординг тимлида (и других менеджеров) шаблон чеклиста «Вот команда. тимлидь» — говорят тимлиду и возвращаются только через 3 месяца, чтобы сказать, что он молодец (или не очень). Правильно, ведь тимлид — это менеджер. Сам разберется, чего от него ожидают. Сам план онбординга себе составит. И цели на испытательный срок тоже — сам. ^^ Вы могли подумать, что это сарказм, и это правда, но на половину. Если цели и план онбординга есть от руководителя — хорошо. Но если нет, — важно, чтобы тимлид составил их сам и выровнялся по ожиданиям. В серии постов поговорим про план онбординга и цели. Это саммари выступления Толи Панова на Podlodka TL Crew, улучшенное и дополненное моими мыслями и материалами. Первый месяц онбординга — 1-я неделя: знакомство с командой На общих встречах и индивидуально обменяться с ребятами ожиданиями, спросить о проблемах, где нужна помощь. Можно использовать чеклист вопросов для первых 1-1 с инженерами, который составил мой тимлид. Мой любимый вопрос — «Зачем тебе тимлид?». Если у инженера есть содержательный ответ — это бесценный источник информации для онбординга. Еще один ценный вопрос — «что работает хорошо и нужно не сломать». Поможет понять, что ценят в текущих процессах — это не стоит поначалу менять. — 2-я неделя: изучение целей команды Сначала цели стоит разделить на командные и личные. Командные — проекты, которые бизнес или заказчики ждут от вашей команды. Личные — задачи, для выполнения которых обязательно ваше участие. Например, команда пятый спринт подряд факапит цели и продакт просит вас с этим разобраться. Руководитель расскажет, какие проекты команды считает важными и на какие личные цели стоит обратить внимание. На время онбординга стоит созваниваться с ним не реже раза в неделю и отслеживать прогресс. Продакт погрузит в цели и проекты команды. Стоит попросить его рассказать не только о том, чем команда занята сейчас, но и о планах на 3-6 месяцев. А еще в команде обычно есть неформальный лидер. Скорее всего, он ревьювит весь код и пишет архитектурную доку. Он поделится важными для команды техническими целями, про которые могут не знать PO и руководитель. Он же поможет, если нет продакта. — 3-я неделя: формирование целей, определение приоритетов Здесь всё зависит от предыдущего пункта. Совет — фокусироваться на том, что не решится без вашего участия. Личные цели — за вас никто не сделает. Наём команды — самому все проекты не затащить. В разговорах с ребятами из пункта 1 может помочь вопрос: «Если бы ты был мной — на чем сфокусировался бы?» В итоге стоит эти приоритеты зафиксировать и выровняться с руководителем. — 3-я неделя: изучение команды Когда вы знаете цели, какие проекты горят и какие есть проблемы, — пора предметно посмотреть на команду. Есть ли все нужные компетенции? Здесь может помочь StarMap команды. Это таблица, где в строках навыки, которые нужны команде для работы: языки, фреймворки, модули, компоненты, сервисы и тд. Каждый столбец — это член команды, который обладает навыком, готов учиться, или готов учить других. — 4-я неделя: погружение в проекты Рекомендую погружаться в проекты только после изучения команды, целей и задач — так вы сможете понять, куда именно стоит углубиться. Важная ремарка: если руководитель сразу говорит, что проект Х — суперважный, то не стоит откладывать на 4ю неделю. Для погружения в проекты попросите заонбордить вас как разработчика. Доставьте простенькую задачу до прода, соберите все шишки и боли. Так поймете, что стоит улучшить, чтобы нанятые ребята быстрее онбордились. Погрузитесь в высокоуровневую архитектуру. Узнаете, какие есть модули, как взаимодействуют, какие узкие места, какую нагрузку она выдержит, и тд. Это поможет увидеть риски в проекте и заранее их отработать. ——— Итогом первого месяца должно стать понимание вводных, постановка реалистичных целей, и начало движения по этим целям. В следующем посте поговорим о том, каких результатов ждут от тимлида на испытательном сроке и когда. И о чем еще нужно не забыть во время онбординга.

Сколько зарабатывают бэкендеры? А продакты? А тимлиды? Есть сервисы, где анонимно публикуют зарплату и отзывы о работодателях. Из зарубежных известных — Glassdoor и levels.fуi А вот у нас такого нет. Вернее, не было до недавнего времени. Знакомые ребята запустили в телеге Glassdoor на минималках — Getmatch. Инсайдеры из российских IT-компаний анонимно расказывают о процессе собеседования в бигтехи, сколько на самом деле платят, приходится ли перерабатывать, есть ли токсики в команде, какие шансы вырасти по зарплате в компании и что для этого делать. Там же ребята делятся опытом прохождения собесов, рассказывают, что спрашивают на секциях, какие этапы и какие офферы. Мой любимый пост — про бэкендера с зп 950к. А еще публикуют исследования, например «Как выросла зарплата продактов за 3 месяца?» или «Кто зарабатывает больше продакты или проджекты?». Канал хорош, а комменты под постами — прямо огонь 😄 Видно, что тема цепляет. Чуваки набрали 15к подписчиков за 2 месяца. Я подписался. @g_jobchannel

Инцидент-менеджмент «Инцидент» — что для вас в этом слове? Для меня — адреналин, желание спасти мир, возможность проявить технические компетенции и быстрое принятие решений. А потом кайф, когда получилось поднять. Вы когда-нибудь задумывались, что 99.99% доступность — это не больше 4 минут даунтайма в месяц? Успеть отреагировать и починить инцидент за короткое время — целая отдельная область знаний со специальными профессиями: Дежурные мониторинга, SRE, Инцидент-менеджеры. Но и без разработчиков сервиса не обойтись. Из каждого инцидента должны быть выводы, а система должна становиться чуточку надежнее. Если интересно заглянуть внутрь, что там у бигтехов с тушением пожаров — от души рекомендую новый эпизод подкаста «Кода Кода». Ведущие — Виктор Корейша, руководитель направления Managed Services в Ozon, и Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure и автор канала «Тимлид Очевидность». Гости подскаста — Андрей Борзов, заместитель технического директора по эксплуатации в Туту и Андрей Чупейкин, CTO блока платформы в Ozon. Слушайте на удобной платформе

Рост инженера в тимлида 1 октября один из наших инженеров стал менеджером. Поздравим Никиту! 🚀 И немного посочувствуем ему 😅 Часто тимлидом становится самый сильный инженер после ухода или повышения руководителя. Обычно это выглядит так: «Вася уходит, теперь ты тимлид. Поздравляем, готовься страдать» Так компания может потерять хорошего инженера, а взамен получить плохого менеджера. Вы поймите правильно, я никого не хочу обидеть. У многих ребят есть задатки, многие «на харизме» становятся лидерами, многие «интуитивно» успешно справляются. Но харизма и интуиция не делают автоматически хорошим менеджером. Нельзя просто так резко проснуться хорошим тимлидом, если ты никогда им не был. Есть системный подход, который повышает шансы на успех мероприятия. На примере Никиты, который за 1.5 года после трудоустройства вырос до тимлида, посмотрим, как в Авито устроен процесс. 1️⃣ — Сначала стать отличным инженером Из плохого инженера хороший менеджер не получится. Поэтому Никиту ждал онбординг и закрепление как инженера. Нужно было понять доменную область, особенности работы в кроссфункциональной команде, осознать её потребности и заслужить доверие коллег. На это ушло примерно полгода. 2️⃣ — Проявлять задатки менеджера … а не быть самым технически прокачанным и авторитетным Переход инженера в менеджера возможен начиная с грейда Е5. Для понимания, есть еще Е6-7-8. Никита пришел как раз на Е5, и у него уже был опыт тимлидства на прошлом месте. Мы охотно принимаем на инженерные позиции ребят с опытом лидерства. С такими зрелыми инженерами приятно работать: их не нужно сильно менеджить, они снимают нагрузку с тимлидов и создают внутренний кадровый резерв. Так получилось, что среди разработчиков в моем юните — аж шестеро бывших тимлидов. 3️⃣ — Определить точку А какие компетенции менеджера уже есть, а каким нужно учиться. Для этого в Авито есть секция «Оценка менеджерского опыта», если кандидат был тимлидом в прошлом. Либо «Кейс», если опыта заведомо нет. На этапе «оценки опыта» мы определили, какие компетенции у Никиты не было возможности прокачать на прошлом месте, но Авито ожидает их от готовых тимлидов. Эти компетенции позже мы будем осознанно прокачивать. 4️⃣ — Должно быть обоюдное желание Спустя полгода Никита сказал, что посмотрел на работу тимлида в Авито и передумал 😂. Поэтому мне пришлось открывать вакансию тимлида, когда тимлид Авторизации ушел в саббатикал. Спустя еще 3 месяца, Никита решился, но тимлида я уже нанял. На первый взгляд это проблема, но на самом деле — совсем нет. В Авито есть TechLead Hub — это пул обученных кандидатов в техлиды, которые прошли интервью и готовы стать техлидами в других командах. Мы знали, что в течение года наша команда вырастет и разделится. Так что Никита остался, чтобы помочь с разделением и стать техлидом отделившейся половинки. 5️⃣ — Получить теоретическую базу Мы предложили Никите пройти внутренний курс Engineering TeamLead School. На курсе он узнал что-то новое и систематизировал то, что уже знал: про управление людьми, командами, процессами, целеполагание и бизнес. 6️⃣ — Попрактиковаться будучи инженером Чтобы выполнять задачи тимлида, не обязательно официально им быть. Никита начал применять знания на практике: процессы потюнил, квартальный роадмап построил, в найме поучаствовал, в онбординге помог. 7️⃣ — Пройти интервью Это обязательный этап. Его проводит независимый руководитель из другого кластера, чтобы оценить готовность кандидата. Не все проходят это интервью с первого раза. Например, я прошел на TUL только со второго раза, прокачав западающие навыки после первого интервью. 8️⃣ — Поздравляю, у вас тимлид. Дальше — долгий путь перехода, «онбординг» и цели на «испытательный срок». Бросать на этом этапе свежеиспеченного тимлида — очень рискованно. Но об этом будет следующий пост. ——— А вы видели воочию, как инженер становился тимлидом? Поделитесь! Особенно интересно, как это ощущается среди разработчиков, когда твой вчерашний братишка — теперь твой руководитель.

Матемаркетинг — конфа про цифры в продукте и маркетинге. Для меня важно, чтобы была проверенная ценность, когда рекомендую конференцию. В этот раз я спросил у товарища, который из разработчика стал продактом. — Женя сказал, что был на Матемаркетинге 2 года назад и тогда ему очень зашло, и с радостью пойдет еще раз. Поэтому вы читаете этот пост, а Женя пойдет на конфу 🙂 Я сам заглянул в программу конференции и понял, что будет интересно и продактам, и аналитикам, и дата инженерам, и продуктовым разработчикам. Примеры докладов: 1. Новая North Star метрика Авито — Максим Новиков, руководитель Аналитики кластера Communications. 2. Прогнозирование выручки — Алексей Веретенников, аналитик данных, Яндекс. 3. Как оценить GMV рынка на неполных и смещенных данных — Михаил Виданов, руководитель группы аналитики рынка, Яндекс. 4. Как понять, какая организация хранилища подходит вам? — Максим Стаценко, руководитель службы подготовки и анализа больших данных, Яндекс И еще несколько десятков крутых тем от крутых спикеров из именитых компаний! Треки: — DWH и Data-платформы — A/B-Тестирование — Устойчивость — Дашбординг и визуализация данных — Прогнозирование и оценка рынка — Аналитика реального финансового эффекта — Карьера аналитика и коммуникация с командой — Управление и аудит платных рекламных каналов — Аналитическая инфраструктура в условиях импортозамещения — Практический ML Для подписчиков — промокод на скидку 15% на все типы билетов — PRODUCTDEV15 Бонус при покупке — доступ к записям всех докладов прошлых лет, которые аккуратно разложены по категориям. 7-8 ноября. МГУ, кластер «Ломоносов». Билеты на сайте.

Предположения и жопа When you assume, you make an ass of you and me. Недавно наткнулся на эту фразу, решил поделиться 😅 Мой вольный перевод: «Когда ты предполагаешь, ты выставляешь дураком и себя и меня». Смысл в том, что предположения могут приводить к ошибкам, из-за которых в итоге пострадают обе стороны. Представим ситуацию: 1. Петя ждёт задачу Васи, чтобы приступить к своей. От этого зависит цель спринта. 2. Петя уходит на полспринта в отпуск, рассчитывая, что задача Васи будет готова к середине спринта. 3. Вася, между тем, решает начать с более интересных для себя задач. Ведь никто не уточнял приоритеты. 4. Петя выходит из отпуска и видит, что задача только взята в работу. 5. В итоге Вася успел все свои задачи, Петя не успел ничего, а цель спринта — провалена. Что происходит дальше? Петя злится на Васю, обвиняя его в непрофессионализме. Вася чувствует себя несправедливо обвинённым, ведь он сделал все свои задачи. Но при этом цель спринта провалена и Вася чувствует свою ответственность за это. Оба оказывается в жопе неудобной ситуации. Почему? Из-за того, что оба сделали предположения, но не потрудились обсудить реальные ожидания. Когда вы сомневаетесь или зависите от действий других, используйте секретную технику — задайте вопрос. Общайтесь словами через рот. Это создаёт ясность и снимает ненужное напряжение.

Podlodka Techlead Crew с 14 по 18 октября До Авито у меня не было опыта работы с канареечными релизами и graceful degradation, про circuit breaker я только слышал, а feature-toggles готовил неправильно. Мне бы помог следующий сезон Techlead Crew — «Проектируем надёжность»! Смотрите, какие крутые сессии и спикеры: 1️⃣ — Архитектурная ката «Проектируем надежность» Будем в командах решать реальные архитектурные задачи, изучать новые методы и подходы. Проведут: — Павел Лакосников, руководитель Arch Governance в Авито; — Игорь Антонов, Тимлид в Т-Банке; — Григорий Скобелев, Techlead в Plata и директор ПК Techlead Crew; 2️⃣ — Доклад «Канареечный деплой: от стратегии к надежности» — Илья Садыков, Senior Backend Engineer в Авито, поделится опытом развития канареек в Авито. Считаю, тут это очень круто сделано, и доклад будет полезен мне самому, чтобы понять особенности механизма. 3️⃣ — Круглый стол «Архитектура на старте: подготовка к успеху» — Александр Поломодов (Т-Банк) и Олег Бондарь (Яндекс) обсудят ключевые принципы надежной архитектуры и механизмы самоисцеления и повторных попыток. 4️⃣ — Публичное собеседование Техлида Проведет Григорий Кошелев. В ходе интервью проверим, насколько техлиды понимают важность надёжности систем. И еще 6 крутых сессий! Я делал HR Crew и Teamlead Crew в составе программного комитета и могу сказать, что ПК подлодки старается сделать каждый сезон лучше предыдущего. От всей души рекомендую https://podlodka.io/techcrew Для моих подписчиков — промокод techlead_crew_7_2HRicB

OAuth 2.0 в картинках Иногда бывает сложно объяснить, как работает OAuth. Инфы в интернете много, но она вся мудрёная и порой противоречивая. Кажется, что некоторые авторы специально усложняют тему, чтобы выглядеть умнее. А тема-то не такая сложная — успешный сценарий можно объяснить за один пост в телеге с одной sequence-диаграммой. Участники: 👤 Пользователь — владеет ресурсами и авторизует ваше приложение на доступ к ним. Например, ему нужно разместить объявление, но вместо регистрации с логином и паролем он хочет «войти через Google». 💻 Ваше клиент-серверное приложение — например, доска объявлений, где вы хотите разрешить вход через Google. 🔐 OAuth провайдер — предоставляет сервер для авторизации и сервер для доступа к ресурсу. Например, Google предоставляет доступ к имени, email и ID пользователя. 🛠️ 5 шагов, чтобы реализовать «вход через Google»: 1️⃣ — Получить конфигурацию OAuth Провайдеры предоставляют discovery-endpoint, который вернет актуальные url для OAuth протокола. Рекомендуется запрашивать конфигурацию вместо хардкода или сохранения в конфиге. Проверьте сами: https://accounts.google.com/.well-known/openid-configuration 2️⃣ — Отправить запрос на авторизацию После нажатия на кнопку «Войти через Google» ваше клиентское приложение выполняет запрос в ваш бэкенд. Ваш бэкенд перенаправляет клиента на URL, составленный с помощью authorization_endpoint из 1️⃣ и стандартных oauth-параметров: 1. response_type=(code|token) — Определяет flow: Auth Code или Implicit. Используйте code, т.к. иначе токен передается на клиент в query string, оставаясь в логах веб-серверов, и может быть украден с клиента 2. client_id — Публичный идентификатор вашего приложения, который вы получили через веб-интерфейс OAuth провайдера для разработчиков. 3. state Уникальный случайный код, который генерирует ваш бэкенд. Нужен, чтобы предотвратить CSRF атаки. В конце флоу помогает убедиться, что изначальный запрос был инициирован вашим приложением. 4. scope — Список типов ресурсов, к которым приложение запрашивает доступ. openid — для доступа к userinfo_endpoint из 1️⃣. calendar_read — чтение календаря. 3️⃣ — Пользователь взаимодействует с OAuth провайдером. Обычно здесь пользователь вводит логин-пароль, проходит 2fa через sms, и т.д. Если пользователь уже залогинен на этом устройстве, то увидит просто кнопку "Предоставить доступ YourApp к информации о вас". Этот процесс непрозрачен для вашего приложения, т.к. пользователь взаимодействует с OAuth провайдером через браузер без вашего участия. 4️⃣ — Получение токена OAuth провайдер перенаправляет браузер обратно к вашему сервису, используя redirect_uri, который передал ваш бэкенд на шаге 2️⃣. Параметры redirect_uri: 1. state — Должен соответствовать тому, который передал ваш бэкенд на шаге 2️⃣. Если не совпадает, — значит пользователь подвергся CSRF атаке. 2. code — Одноразовый код, сгенерированный oauth провайдером. Ваш бэкенд делает запрос в OAuth Auth server для получения access_token и других. После получения access_token ваш бэкенд использует его для запросов к ресурсам. Auth Code flow безопаснее, чем implicit flow, потому что добавляется шаг взаимодействия вашего сервиса и OAuth провайдера для получения токена. Таким образом на клиенте не светятся никакие секреты, и вероятность их компрометации снижается. 5️⃣ — Получение ресурсов Когда ваш сервис получает access_token, он может быть использован для вызова API сервера ресурсов сразу или в будущем. access_token имеет ограниченный срок действия и его нужно регулярно обновлять с помощью refresh_token. Доказательством аутентификации служит id_token. ID пользователя можно достать из поля sub (subject), раскодировав base64 JWT id_token. Или обратиться к userinfo_uri, используя access_token. Вот собственно и всё. OAuth — это просто. Распространите. —— Специально для поста я перевел инфографику из статьи ув. тов. Phil Boutros. На картинке к посту — превью. Сам pdf файл — чуть ниже. Для закрепления материала можно поиграться в официальной OAuth 2.0 Playground

Servant leadership vs Управляемость команды Disclaimer: это реклама бесплатного вебинара от Soft Skills Lab. Ребят уважаю, тема откликается, сам пойду. Концепция «Лидер-слуга» — стиль управления через предоставление свободы сотрудникам и помощь в устранении препятствий. Команда вовлечена в принятие всех решений, с их мнением считаются, и они вольны делать что захотят и как захотят. Google был одной из первых компаний, кто популяризировал эту концепцию. В книге Work Rules автор утверждает, что свобода сотрудников — ключ к продуктивности. И что единственный способ обеспечить свободу — это отнять власть у менеджеров. Например, менеджер не может самостоятельно решить вопрос о найме, увольнении или оценке на перформанс ревью. Даже без таких радикальных мер я знаю много тимлидов, которые стараются работать в стиле servant leadership. И я сам поддерживаю вовлечение инженеров и чувствую, что ребята тоже проявляют инициативу. Этот подход может сплотить команду, поднять мотивацию и привести к росту перформанса и скорости достижения результатов. Но… Есть некая грань, после которой команда садится на шею и становится неуправляемой: ▫️ исключения из правил становятся нормой — опоздать, забыть, не прийти ▫️ требования к тимлиду/продакту/… растут, а эффективность команды падает ▫️ отговорок больше, чем сделанных задач Если узнали свою команду хотя бы в одном пункте, это опасный звоночек. Потеря управляемости — процесс постепенный и незаметный, поэтому важно вовремя его отловить и остановить. 3 октября в 20:00 по мск Саша Клименко, основательница Soft Skills Lab, проведет открытый воркшоп «Как не потерять управляемость команды? 5 ошибок в коммуникации и как их исправлять». Это будет бесплатное занятие в Zoom с практикой на реальных кейсах и общением голосом (приносите свои ситуации и вопросы!) За 1,5 часа вы узнаете: ▫️ Какие ошибки в коммуникации не дают наладить контакт с командой? ▫️ Как отследить потерю управляемости и не допустить ее? ▫️ Что делать, если вы уже чувствуете, что сотрудники сели на шею? Ссылку на встречу отправят в бота. Зарегистрироваться. Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqx6CbxM

SMART для ИПР и не только — фреймворк для постановки целей Это пост-дополнение к посту с шаблоном ИПР. По нему возникли вопросы — «что за заголовки Конкретные, Измеримые,… Что туда писать»? В мире красивых аббревиатур много булшита, но эти 5 букв считаю достаточно ценными, чтобы о них рассказать. Если просто записать в ИПР «Прокачаться в базах данных» — это будет достаточно абстрактно и породит кучу вопросов: — Зачем? — Как поймешь, что прокачался? — А когда? Вот SMART — как раз чтобы ответить на эти вопросы при постановке цели. 1️⃣ Specific (конкретная) — Цель должна быть понятной и чёткой Пример, вместо «Прокачаться в базах данных» — «Научиться оптимизировать SQL запросы». Чем более детализирована цель, тем легче к ней идти. 2️⃣ Measurable (измеримая) — Цель должна иметь чёткие показатели успеха. Пример: «Уменьшить время выполнения SQL-запросов в синхронных пользовательских сценариях до 500 миллисекунд максимум при нагрузке в 1М пользователей». Чем больше конкретных цифр получится дать — тем лучше. Если получится выполнить цель в изначальной постановке — круто! Но это редкость. Не беда, если в процессе придет понимание, что в текущем виде цель не получается выполнить. Расценивайте это как вектор. Направление, куда двигаться. И да, с появлением новых вводных вектор может меняться. Лучше двигаться с вектором, чем по кругу или по траектории как на картинке к посту. 3️⃣ Achievable (достижимая) — Реалистична ли цель в текущих условиях? Есть ли обучающие материалы, эксперты за которыми можно наблюдать, и задачи, на которых применить новые знания? Пример: «Пройти курс по оптимизации SQL-запросов и внедрить улучшения в течение двух спринтов, привлекать эксперта Васю для ревью» Важно не перегружать себя и оценивать реальные возможности. 4️⃣ Relevant (релевантная/согласованная) — Цель должна быть важной для ваших текущих задач и карьеры. Пример: «Запросы нужно оптимизировать для того, чтобы сервис держал нагрузку на 1 миллионе пользователей — с текущим ростом это будет через полгода» Важно, чтобы цель приносила пользу лично вам и вашей команде. 5️⃣ Time-bound (ограниченная по времени) — Определите дедлайн. Пример: "Закончить курс по SQL за 2 недели и оптимизировать запросы до конца месяца". Причем план может быть отложенным — здесь не сказано, что это должно происходить в следующие два спринта. Это может быть план развития на полугодие, где конкретно эта цель стартует в следующем квартале. Сроки мотивируют и помогают не откладывать выполнение задач. ——— SMART пригождается не только в ИПР, но и в постановке целей на квартал для команды или личных целей. Важная ремарка: бывают цели, к которым очень сложно приложить линеечку. У нас был рефакторинг, эффект от которого мы не смогли оцифровать. Но! сама попытка дала важные мысли о том, как скорректировать план рефакторинга. Когда будете ставить цели в следующий раз — попробуйте описать их по этим 5 буквам. Даже если финальая формулировка не будет описана по SMART, это упражнение будет полезным и поможет доуточнить цель и путь достижения.

Avito Product Bootcamp Найти работу начинающему продакту — это адский ад, даже наверное сложнее, чем разработчику. У меня в команде есть продакт Серега, который попал в Авито через буткемп. Он очень хорошо влился, полноценно участвует в работе, а на последней статсессии подкидывал годные идеи. Я рад, что благодаря буткемпу Серега с нами. Этой осенью стартует очередной поток буткемпа, и я пишу этот пост чтобы зазвать туда вас 🙂 Не обещаю, что будет просто, но это реально, и открытых позиций довольно много. Нужно будет решить кейс и пройти интервью с HR и юнит-лидом. Подробнее о мероприятии и условиях участия: https://start.avito.ru/product-bootcamp Регистрация проходит до 22 сентября. Расписание — Регистрация — до 22.09 — Решение кейса — до 29.09 — Оценка работ — до 06.10 — Итоговый рейтинг — до 11.10 — Интервью в Авито — 14.10 - 29.11 Если заинтересовало, не бойтесь, попробуйте свои силы. Даже если у вас нет опыта или он небольшой. В худшем случае — потренируетесь на реальном кейсе, а это уже польза для прокачки. Буду рад новым коллегам! ❤️ P.S. В Авито у каждого нанятого буткемпера будет ИПР 🙂 Зарегистрироваться

Как составить индивидуальный план развития Один товарищ спросил, как самому составить себе ИПР. Я пытался найти и скинуть ему какую-нибудь годную статью, но не смог. Поэтому пишу пост и выкладываю шаблон ИПР, который мне дали в QIWI 4 года назад — он всё еще лучший ♥️ Вот простой фреймворк из 3 шагов: 1️⃣ — Точка А — Где мы сейчас Самодиагностика, собес или сессия с ментором помогут определить текущий уровень. Для самодиагностики можно примерить на себя матрицы компетенций из Avito Playbook: — Разработчики (Там есть даже шаблон Windrose, добавленный мною) — Аналитики данных — Продакты — Дизайнеры — Тимлиды и инжиниринг менеджеры — Data-Science инженеры 2️⃣ — Точка Б — Куда хотим попасть — Если хотите помочь команде — можно составить StarMap, чтобы найти недостающие в команде компетенции и качать именно их. Более простой вариант — спросить у продакта или тимлида, каких компетенций им хотелось бы добавить команде. — Если хотите пользу для себя — можно попросить подробный фидбек на собеседовании, либо пройти сессию с ментором. Можно сходить на конференцию, посмотреть что сейчас в тренде. Можно подумать, каких навыков не хватало на прошлых задачах. Важно понимать цель, сроки и ожидаемый результат: 1. Какой эффект даст прокачка навыка? 2. Когда хотите увидеть результат? 3. В чем польза? Например, Вася хочет: — качать алгосы, чтобы лучше проходить собесы — качать базы данных, чтобы оптимизировать медленные запросы и улучшить продукт. Эффектом может быть либо прокачка в решении интересной рабочей задачи, либо смена работы. Выбор за Васей. 3️⃣ — Строим маршрут А -> Б Если хотите прокачаться именно в рабочих задачах, то можно пойти по модели Дженнингса: — 10% теория. Это могут быть статьи, поход на конференцию, просмотр записей докладов, ну или курс. — 20% наблюдение за другими. Найдите коллегу, который хорошо делает то, чему хотите научиться. — 70% практика с обратной связью от ментора. Ну тут всё просто. Берешь и делаешь 🙂. Потом собираешь обратную связь и переделываешь. Пропишите конкретные шаги, установите дедлайны и оцените риски. Если нужна помощь — договоритесь с людьми заранее. Главное — критерии успеха: как вы поймёте, что навык прокачан? Возможно, это будет успешное завершение рабочей задачи. ——— Если вы всё хотели составить себе ИПР, но никак не добирались до этого и ждали знака — вот он. Составьте себе ИПР 🙃 Шаблон ИПР поможет побороть проблему белого листа.

E-CODE by Ozon Tech | 28 и 29 сентября Больше бесплатных оффлайн конференций от бигтехов! 2 дня, 4 параллельных трека, 50 выступлений. Москва, 28-29 сентября. Онлайн трансляция, конечно же, будет. 28 сентября — Менеджмент, Бэкенд, Инфра, Наука и жизнь. Точно буду смотреть: 1️⃣ — Алексей Пименов / Neogenda —Трехуровневая система управления Алексея всегда интересно послушать, хожу на его доклады на всех конференциях 🙂 2️⃣ — Александр Бирюков / Т-Банк — SageDB: зачем мы пишем свою базу данных Меня привлекает тема баз данных, а когда кто-то из игроков рынка пишет свою — это значит, что по каким-то причинам не подошли существующие, и это вдвойне интересно. 3️⃣ — ClickHouse как пример DBaaS во внутреннем облаке / Евгений Сударчиков / Ozon В Авито у нас есть ClickHouse в DBaaS, хочу сравнить реализацию и возможности для разработчиков. 4️⃣ — Квантовые вычисления: основные идеи и современное состояние технологии / Станислав Страупе / Сбер/МГУ/РКЦ На доклад про квантовый компьютер я ходил на HighLoad++ в 2020 году. Было очень познавательно, и сейчас для меня это шанс быстро освежить тему и узнать прогресс за прошедшее время. 29 сентября — QA, Mobile, ML&DS, Наука и жизнь. Меня заинтересовали: 1️⃣ — Нагрузочное тестирование в Ozon: прошлое, настоящее и будущее / Иван Приходько / Ozon Все готовят нагрузочное тестирование по-разному. Буду набираться насмотренности. 2️⃣ — Figma Mockup to Server-Driven UI / Владислав Чешенко / Альфа-Банк. Знаю, что в Альфе Server-Driven UI начали делать еще до санкций, и очень интересно посмотреть на их опыт. 3️⃣ — История развития архитектуры системы рекомендаций Ozon / Алексей Гурьянов / Ozon В Авито рекомендации — очень интересная и сложная область разработки. Хочу посмотреть, как её готовят в других компаниях. Москва. 28 и 29 сентября. Оффлайн и онлайн. Зарегистрироваться

Как лечить пять дисфункций команды: практические шаги В прошлом посте я описал пять дисфункций команды по Патрику Ленсиони, а теперь поговорим о том, как их "лечить". Часть идей из книги, часть из личного опыта, часть — из ваших комментариев. Список не полный, так что делитесь своими мыслями, буду рад обсудить. 1️⃣ Отсутствие доверия Лечение: — Поощряйте открытое признание ошибок. Начните с себя, покажите свою ошибку. Призывайте ошибаться и учиться на ошибках. А в следующий раз, когда разработчик заранее скажет о проблеме по цели спринта, — поблагодарите и объясните, как это помогло команде достичь цели — Тимбилдинги, как бы банально ни звучало. Нужно дать возможность команде узнать друг друга вне рабочего контекста. Можно провести даже онлайн. Мы делали встречу под названием «барушник» в пятницу вечером — созванивались по зуму, чтобы поиграть в клавогонки или просто поболтать на разные темы — Командные тренинги. Есть разные упражнения, но по сути важно просто собрать всех вместе и дать пространство рассказать друг другу о взаимных ожиданиях. Есть тренинг «пять пороков команды», я его проходил лет пять назад. Он тогда стал хорошей стартовой точкой для налаживания отношений в команде Признаки улучшения: ребята чаще обращаются за помощью к команде, открыто обсуждают свои трудности и ошибки, воспринимая их как возможность для роста. 2️⃣ Боязнь конфликтов Лечение: — Попробуйте практику «адвокат дьявола». Один из участников обсуждения намеренно надевает шляпу адвоката дьявола и оспаривает предложенные идеи. Важно заранее проговорить это и оспаривать именно идею, а не накидывать на её автора. Нужен модератор — Перед важными решениями можно проводить анонимные опросы, чтобы выявить сомнения — Обучайте команду конструктивной обратной связи. Тут советую всем Методичку по ненасильственному общению и Фреймворки обратной связи Признаки улучшения: Обсуждения становятся более оживленными, решения принимаются после рассмотрения альтернатив, с учетом плюсов, минусов и рисков. 3️⃣ Отсутствие обязательств Лечение: — Попробуйте технику «молчаливого голосования», где каждый анонимно оценивает свою поддержку решения. Если команда не поддержит решение — то не будет и обязательств по его соблюдению — Записывайте все договоренности в конце обсуждений и назначайте ответственного, который будет при случае возвращать команду к принятым решениям и договоренностям — Для экшн-айтемов четко прописывайте: кто, что и до какого момента должен сделать Признаки улучшения: Решения принимаются быстрее, команда более последовательна в их выполнении. Экшн-айтемы с ретроспектив не накапливаются, а своевременно выполняются. 4️⃣ Уклонение от ответственности Лечение: — Проводите регулярные сессии обратной связи в формате 360 — Поощряйте культуру "вызова", где каждый член команды может задать вопрос о действиях коллеги. Тут важно не переборщить 🙂 — При возникновении ситуаций как в прошлом посте, например один разработчик слишком часто берет дейоффы, спрашивайте у ребят на 1-1 — что мешает им высказаться Признаки улучшения: Члены команды регулярно обмениваются конструктивной обратной связью, что приводит к повышению общего качества работы и укреплению командного духа 5️⃣ Невнимание к результатам Лечение: — Визуализируйте общие цели команды и регулярно обсуждайте прогресс — Обсудите с командой, как личные цели каждого участника могут способствовать достижению общих целей проекта — Празднуйте общие успехи команды, а не только индивидуальные достижения Признаки улучшения: Сотрудники чаще обсуждают общие цели, готовы жертвовать личными интересами ради общего результата. ——— Важно помнить, что "лечение" этих дисфункций — это непрерывный процесс. При чем во многом это процесс перевоспитания взрослых людей, а это на грани возможного. Начните с построения доверия и постепенно двигайтесь вверх по пирамиде. Возможно, в процессе прочтения, у вас где-то бомбануло, или вы вспомнили свой способ «лечения». Как сказал в начале, список не полный, поэтому буду рад обсудить в комментариях.

Yet Another Level — плейлист! В июле я зазывал вас на митап от Яндекса, а сейчас приношу плейлист видосов оттуда. При чем там есть сокровища с предыдущих митапов, не только для тимлидов, но и для разработчиков. Всего 14 выступлений. Прям советую посмотреть: 📌 Георгий Могелашвили, Lead Developer / ex Engineering Manager @ Booking.com — «Как расти, когда не растят». Сильный доклад о самостоятельном составлении плана развития. 📌 Александр Афенов, мой коллега, Technical Cluster Lead в Авито Доставке. «Жока и Бока: две очень разные судьбы тимлидов». Сравнение двух подходов к роли тимлида: — с естественной склонностью, но без плана, — без склонности, но с чётким планом. Спойлер: есть подводные камни в обоих вариантах. 📌 Евгений Антонов, мой товарищ, технический менеджер в Yandex Infrastructure. «Играющий тренер: выиграет или проиграет?» — Личная история о том, как быть тимлидом, который пишет код, и в какой момент это перестаёт работать. 📌 Анастасия Абрашитова, руководитель отдела DevTools, Яндекс — «Без ботвы: растим тимлидов правильно» — как повышать разработчиков до тимлидов, чтобы это не превратилось в лотерею. Ссылки на плейлист: 📺 — YouTube 📺 — VK Видео

Пять пороков команды — это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция». Пост получился объёмным, поэтому я его разделил на две части: здесь обзор и примеры, а в следующем — о методах «лечения». Дисфункции идут по пирамиде — одна вытекает из другой, создавая систему взаимозависимых проблем. Я сталкивался с ними в больших командах, когда личный вклад размывается, и можно «затеряться». Итак, вот они, слева-направо, люблю их снизу-вверх: 1️⃣ Отсутствие доверия — члены команды боятся ошибиться, т.к. предполагают, что за ошибку их сначала публично отчитают, а потом и вовсе уволят (и из-за этого они умрут от голода). Например, разработчик неделю не признается в проблемах по задаче, боясь показаться некомпетентным. В результате цель спринта провалена, а осознание этого приходит в последний день, когда уже ничего нельзя сделать. Это базовая дисфункция, лежащая в корне всех остальных проблем. Поэтому «лечение» команды нужно начинать именно с неё. 2️⃣ Боязнь конфликтов — команда избегает конструктивных споров: либо поверхностно соглашается с решением, либо быстро идет на компромисс, который в итоге никому не выгоден. Лишь бы не вступать в конфликт Правильно — незачем раскачивать лодку. Сиди тихо и не высовывайся, всем лучше будет. Например, при проработке нового сервиса разработчик предлагает новую технологию и никто не высказывает альтернативное мнение, хотя у многих есть сомнения. Потом приходится переделывать большие куски кода. 3️⃣ Отсутствие обязательств — команда не берет на себя ответственность за решения и договоренности. Кто не принимает решений, тот не ошибается — Удобно. Например, когда на ретроспективе возникает экшен-айтем, никто не вызывается взять его на себя. А командные соглашения забываются сразу после выходных. Или другой пример — при выборе архитектуры разработчики не могут принять ответственность за решение и всегда привлекают тимлида. 4️⃣ Уклонение от ответственности — члены команды не призывают друг друга к ответу за действия и результаты. Пока сидишь тихо и не привлекаешь внимание — всё хорошо. А если начнешь от кого-то чего-то требовать, то и от тебя начнут требовать. А оно тебе надо? Например, никто не обращает внимания на то, что коллега постоянно нарушает код-стайл, аргументируя это спешкой. Техдолг растет, но все молчат. Другой пример — один из разработчиков слишком часто берет дейоффы и «болеет». При этом никто из команды этого не замечает. 5️⃣ Невнимание к результатам — личные цели ставятся выше командных. Какая нафиг цель спринта? Какие такие продуктовые метрики? Вот если я в резюме напишу, что работал с CockroachDB — вот это да, это понятно зачем нужно. … В итоге, это всё про страх потерять работу. Сиди на попе ровно, получай зарплату, не делай много / не высовывайся, не требуй много с других / не докапывайся. И всё будет хорошо. Нет, не будет. В такой атмосфере нет ни удовольствия от работы, ни роста и развития. Люди увольняются, а проект загнивает. Поэтому с дисфункциями нужно бороться. Ключевое отличие команды от рабочей группы — наличие общей цели и взаимной поддержки. Но не достаточно просто формально обозначить «цель спринта». Нужно выстраивать доверительные отношения и атмосферу взаимопомощи. Друзья, для следующего поста мне нужна ваша помощь: поделитесь в комментариях, с какими из этих дисфункций вы сталкивались? Как боролись? Как поняли, что ситуация улучшилась?

Yandex Scale — бесплатная конференция по облачным технологиям 25 сентября в Москве пройдет конференция, где будут выступать не только сотрудники Яндекса, но и спикеры из Райфа, Lamoda, Mindbox и других компаний. Конференция организована по всем канонам: целый день, 5 параллельных треков, перерывы для нетворкинга и афтерпати в завершение. Среди докладов меня заинтересовали: — Новые возможности PostgreSQL 17 — Сломать, чтобы починить: парадокс хаос-инжиниринга в действии — Новые горизонты платформы YDB: DWH, оптимизации, варианты поставки — Ускоряем построение высоконагруженных решений на базе serverless YDB Участие в конференции бесплатное, но требуется предварительная регистрация. Лично я планирую смотреть онлайн. А вы присоединитесь?

Podlodka Podcast: Авторизация Вышел эпизод подлодки со мной! Позвали рассказать про Авторизацию, а говорили 90% времени про Аутентификацию. Про то, насколько всё проклято, и какое нас ждёт светлое будущее без паролей. Ну и немного про авторизацию. И совсем чуть про технику. С Podlodka Crew мы дружим давно: в составе программного комитета я делал конференции HR Crew и несколько сезонов Teamlead Crew. А вот до подкаста дорос только сейчас. Все-таки Podlodka — это подкаст №1 в русскоязычном айти. Высший пилотаж, так сказать. Спасибо Егору и Жене, что позвали. Приятно поговорить с умными людьми 🙂 🎧 Послушать 👀 Посмотреть на ютубе