Product Developer

​​WebAuthN. Web Authentication API. Будущее аутентификации в вебе На всякий случай: это не реклама, потому что это как если бы я продавал вам механизм http, cookie и local storage. Это технология, которая уже в ваших устройствах. Это продолжение серии постов «​​SMS Two factor auth — плохая практика. Альтернативы» https://webauthn.io — демо-сайт, где я могу аутентифицироваться на десктопе, приложив палец к моему 6-летнему Huawei p20. Или посветив лицом в FaceID айфона. Или приложив палец к TouchID на макбуке — самый простой сценарий, состоит из 1 шага. Или воспользовавшись Yubikey, который поддержан WebAuthN. Технологию разрабатывали крутые дядьки из Google, Mozilla, MS и Yubico. Можно подискутировать, каким фактором называть WebAuthN. По сути это протокол между сайтом и устройствами пользователя, объединяющий второй и третий фактор, и позволяющий отказаться от первого. Да здравствует passwordless! Я очень жду распространения этой технологии. Она вышла в бету еще в 2019 году, тогда была сыровата и не имела достаточной поддержки на устройствах и в браузерах. Сейчас она готова к внедрению: поддерживается iOS 13.3+ и Android 7+, WebView, Safari, Chrome, Firefox, Edge, Opera. Список совместимых браузеров с версиями. «Это какая-то техногиковская хрень для хакатона!», скажете вы. А я приведу список сервисов, которые уже прикрутили WebAuthN, а в первом комменте накидаю скринов: - Google - PayPal - Apple - Microsoft - Facebook - Dropbox Из наших: - Mailru Почта - Яндекс ID (читай, все сервисы Яндекса) Плюсы: — Очень user-friendly. В самых простых кейсах не нужно даже вводить логин, т.к. он сохранен в браузере. То есть просто на сайте нажал кнопку «войти», приложил палец к сканеру на ноуте и вошел. Ни забытых паролей, ни ожидания смс. — Безопасность на уровне Yubikey, а то и выше. В отличие от ТОТП, не происходит обмена секретами. Так же как в случае с Yubikey, нет возможности фишинга ОТП-кода. А если украли телефон, то чтобы воспользоваться им нужно его разлочить. — Не нужно ставить и настраивать доп приложения, не нужно покупать доп девайсы. — Не нужно реализовывать доп сценарии в своих приложениях типа QR-кода или кнопки «да, это я». Уже всё реализовано в браузерном API и в нативе на мобилках. — Бесплатно. Не нужно платить за пакет СМСок. Нет проблем с «зарубежными номерами телефона». Минусы: — Новая технология, не сформирована привычка у пользователей, еще могут вылезать баги. — Если нет сканера отпечатков на ноуте, то задействуется телефон — а это таки лишнее движение. Мое мнение: За этой штукой будущее, но прямо сейчас делать это исключительным способом входа нельзя. У всех приведенных примеров этот способ — дополнительный. Хотя уже сейчас можно заходить в Google без пароля, но есть fallback-вариант в виде старых добрых «пароль + смс». Тем не менее, возможности которые эта технология дает, уже сейчас можно использовать. Например, если нужно защитить самые ценные учетки, и вы думали прикручивать TOTP — рассмотрите WebAuthN в качестве второго фактора. https://webauthn.guide/ — Почитать, лендос + дока https://webauthn.io/ — Потыкать самому, зарегистрироваться + залогиниться

​​Кнопка «Да, это я» / Вход по QR коду Продолжаем серию постов про альтернативы смс с кодами для 2фа. Предположим, у вашего продукта есть мобильное приложение, и пользователь там уже залогинен. Пользователь хочет войти на новом устройстве. Тогда можно использовать ту сессию пользователя как 2fa, проверку что он владеет устройством на котором уже инициирована сессия. Подсобрал такие примеры: — Кнопка «Да, это я». Этот вариант вы могли видеть в качестве второго фактора, когда заходили в сервисы гугла, и на вашем смартфоне появлялся экран подтверждения входа. — «Вход по картинке». Новый способ аутентификации от Яндекса. Вот статья от 31 окт 2023. По сути это вариация 2fa как в предыдущем варианте от Гугла, но без первого фактора (пароль вводить не надо) и с небольшой доп защитой — нужно выбрать правильную из 4 картинок в приложении, а не просто нажать «да». — QR-код, который вы сканируете из приложения, где уже залогинены. Этот вариант вы могли видеть в Whatsapp, когда логинитесь на десктопе. Из наших — в супераппе Яндекса. — Экран подтверждения транзакции в приложениях необанков. Из необычного — необанки N26 / Revolut / BBVA. Механика такая: при оплате вы попадаете на 3DS, но вместо ввода кода вам говорят: «иди в приложение». Когда открываете приложение — сразу попадаете на экран с описанием транзакции и с кнопкой «Подтвердить». Да, это не совсем про аутентификацию, но про авторизацию транзакции. Вход в приложение подтверждается по FaceID/TouchID. Получается такой гибрид 2 и 3 фактора (what you have + what you are). Скринов накидаю в комментарии. Плюсы: — UX простой и приятный, конверсия выше: в отличие от TOTP, приходит пуш, и не нужно вводить цифры — Бесплатно, опять же — Доставляемость больше, хотя и зависит от интернета у пользователя Минусы: — приложения может не быть у пользователя — не подходит для первичного входа в мобильное приложение. Большинство продуктов использует тут старую добрую смс, со всеми вытекающими. Безопасность — получается не выше чем у смс. — существуют сервисы без приложения в сторе, только с мобильной веб-версией ========== Проспойлерю завтрашний пост: Представьте, я логинюсь на десктопе, прикладывая палец к 6-летнему андроид-смартфону! А пока поделитесь в комментах, какие еще примеры in-app 2fa вы видели? Может быть, что-то такое делали в своих сервисах?

​​SMS Two factor auth — Альтернативы ч1 Cтараюсь придерживаться принципа «Критикуешь — предлагай», поэтому вот продолжение поста «​​SMS Two factor auth — плохая практика» Для справки, факторы аутентификации: 1. Something you know (например, пароль или пин) 2. Something you have (например, симка, на которую приходит смс с кодом) 3. Something you are (например, биометрия / FaceID) Альтернативы — не обязательно прямая замена второму фактору. Но все они призваны решить проблему «подтвердить, что пользователь легитимный». В один пост упаковать не получилось, поэтому разбил на три и запосчу по одному в пн, вт и ср. О чем будут посты: 1. TOTP приложения типа Google Authenticator, упомянутые в комментах к прошлому посту. Здесь же расскажу про Yubikey, — физическое устройство для генерации ТOTP. Торчит у меня в ноутбуке, кстати. 2. «Вход по QR-коду» Whatsapp / Яндекс, «Да, это я» Google и другие реализации с помощью приложения на мобиле, где пользователь уже залогинен 3. WebAuthN — Стандарт W3C, будущее аутентификации в вебе. Passkey как частная имплементация WebAuthN для биометрического passwordless. Чтобы рассказать про WebAuthN, я затевал эту серию постов) ======================== Time-based OneTime Password (TOTP) — это способ генерировать на клиенте коды для 2fa Это приложения — например Google Authenticator, Duo Mobile, … Или устройство Yubikey, которое вставляется в USB и имеет одну кнопку. 📲С приложением процесс выглядит так: - Пользователь открывает Google Authenticator на мобиле - Для первичной привязки приложения к сервису сайт показывает пользователю QR-код с секретным токеном В QR кодируется строка вида otpauth://totp/Yourlabel?secret=123&issuer=Yourservice - Пользователь сканирует этот QR-код приложением - Теперь приложение может генерировать OTP с помощью этого токена и метки временного диапазона - На странице сайте с 2fa пользователь вводит сгенерированный OTP - Сайт генерирует OTP с помощью этого же токена и временной метки на своей стороне, сравнивает с введенным пользователем. В данном случае второй фактор (what you have) — подтверждение владения устройством, на котором установлено и настроено приложение TOTP. Плюсы — это отсутствие минусов смс: - 100% «доставляемость», т.к. в отличие от смс они генерируются на клиенте. Работает даже в оффлайне! - Безопасность. Нельзя «восстановить» как симку. Нельзя перехватить как смску. - Бесплатность. Минусы: — Пользователь должен очень хотеть воспользоваться вашим сервисом, чтобы ради этого устанавливать и настраивать новое приложение — Нужно открывать приложение — это лишнее действие, в то время как код из смс можно взять из пуша ————————— 🤏Yubikey — тоже генерирует TOTP, но процесс чуть отличается. - Сервер сохраняет себе публичный ключ Yubikey, ассоциирует его с пользователем - Yubikey генерирует и подписывает OTP код с помощью секретного ключа, хранимого на устройстве. Генерируемый текст — шифротекст до 64 символов, не предназначен для ручного ввода - Через драйвер «USB-клавиатуры» Yubikey сам заполняет TOTP в поле ввода, в котором фокус - Сервер проверяет подпись с помощью публичного ключа. Так же как и в случае с приложением, второй фактор здесь заключается в подтверждении владения устройством с таким публичным ключом, сохраненным на сервере. Плюсы: — еще бóльшая безопасность. Можно сказать, максимальная — код генерируется одним нажатием, если юбик уже торчит в ноуте Минусы — еще бóльшая сложность для пользователя: — Тратить 30-60 баксов на девайс, ждать доставку, а потом его с собой везде таскать — если юбик не торчит в ноуте, то его надо будет найти и вставить в usb — можно потерять Мое мнение: способ безопасный, но не удобный. Массового пользователя не заставить им пользоваться. Можно вкручивать насильно, когда нужно защитить самые ценные аккаунты, а пользователь от вас точно никуда не уйдёт. Но если дать возможность альтернативно пройти 2fa через смс – то все бенефиты безопасности исчезают. Завтра расскажу про гораздо более user-friendly способы подтверждения.

​​SMS Two factor auth — плохая практика …но всё еще самая распространенная Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление. Кажется логичным, что раз у пользователя есть телефон и мы его знаем, то давайте на него отправлять одноразовые коды для всего. И это настолько привычно, что многие ни на секунду не задумываются о проблемах и альтернативах. Этим постом хочу подсветить очевидные (и не очень) проблемы. В следующем поделюсь некоторыми альтернативами. Почему плохо? 1️⃣ — Из очевидного, низкая конверсия в корректность ввода кода - Телефон может быть не под рукой / разряжен - Может быть плохое покрытие сотовой сети в подвале у вашего пользователя - Бывают проблемы с отправкой смс у сотовых операторов. Довольно часто, чуть ли не раз в месяц по часу. - Последнее, самое значимое: люди долбятся в глаза и не могут верно ввести код. Чтобы не было никому обидно — я среди этих людей, здравствуйте. Респект тем компаниям, кто научился генерировать легковводимые коды типа 7788. Из примеров — Тинькофф. Интересно было бы узнать, насколько это поднимает конверсию. В любом случае, на смс кодах отваливается до половины пользователей. Если у вас лучше — напишите в комментах, как добились 🙂 2️⃣ — Дорого для массовых сценариев Стоимость одной смски — 1.5-5 рублей. Представьте, что на вашем сайте каждый день регистрируется 10000 пользователей. Классно? Готовьтесь платить 1 млн рублей в месяц за смски в одном только сценарии регистрации. Существует отдельный вид вредительства — sms flooding. Если у вас нет никакой защиты от повторных запросов, — готовьтесь, рано или поздно вас настигнет огромный счет за смски. Делаете транзакции? Поздравляю, кроме комиссии за эквайринг платите еще оператору за смс. Как думаете, окупается ли транзакция на сумму 10 рублей? А если придёт негодяй и начнет закидывать вас такими транзакциями? Оптимизируете с помощью пуш-уведомлений в мобильное приложение? У пушей настолько хреновая доставляемость, что конверсия падает еще сильнее. А потом пуш не дошел и вы всё равно отправляете смс 🙂 3️⃣ — Номер телефона может сменить владельца Об этом мало кто задумывается, но это обычная часть жизненного цикла номера. Полгода неактивности -> полгода отлёживается -> попадает в пул и продается следующему владельцу. И это не то чтобы редкий кейс! Готовьтесь, что через три года работы продукта таких номеров у вас в базе будет 5-10%. И вы об этом никак не узнаете! До тех пор, пока не начнете взаимодействовать с операторами, но это отдельная сложная история, потому что операторы сами не могут дать 100% правдивую инфу. Особенно из-за кейсов перехода номера между операторами. А вы следите за актуальностью номеров телефонов пользователей? 4️⃣ — Это небезопасно! 1. Что если я скажу вам, что есть ребята, которые скупают номера телефонов чтобы потом проверить существование аккаунтов в популярных сервисах, зареганных на эти номера? См прошлый пункт — номер может сменить владельца и это эксплуатируют негодяи. 2. Социнженерией достать код из смс — изи-пизи. Служба безопасности Сбербанка, вечер в хату как говорится. 3. Что если я скажу вам, что сотрудник салона связи (не самая высокооплачиваемая работа) может согласиться немного подзаработать и «восстановить» вашу симку за некоторое вознаграждение. И вот ваш номер уже у негодяя на руках. 4. Сама по себе сотовая сеть и механика доставки SMS — весьма дырявая. В 2016 году ребята из Positive Technologies опубликовали отчет по уязвимости в SS7, с помощью которой было можно направлять смс на устройство хакера вместо легитимного устройства пользователя. ========= А вы используете коды из смс в своих продуктах? Задумывались когда-нибудь про смену владельца номера телефона? В следующем посте поделюсь альтернативами.

Soft Skills: как качать коммуникацию В Авито soft skills — часть ожиданий от инженеров не менее важная, чем hard skills. Стажер должен уметь аргументировать свою точку зрения, мидл — давать конструктивную обратную связь и презентовать результат своей работы, сеньор — фасилитировать и разрешать конфликты. Часто вижу, что говоря о soft skills, имеют в виду не навыки, а характер. Типа, «уравновешенный». Но каждый из перечисленных выше примеров — достаточно конкретный навык, который можно осознанно качать. Как обычно проходит прокачка hard skills? 1. Осознаём точку А. Например, проходим собеседование, на котором нам подсвечивают пробелы в базах данных. 2. Ставим цель — точку Б. Например, «научиться в масштабирование БД» 2. Составляем план. Подбираем теорию, задачи, ментора. 3. Идём по плану. Читаем статью про партиционирование, пилим задачу, получаем обратную связь от ментора. 4. Profit. Внезапно, soft skills можно и нужно качать так же. Если есть желание прокачать коммуникацию — завтра (11 декабря) стартует бесплатный практикум от Soft Skills Lab Саши Клименко (@normalno_delaj) и Юры Клименко (@razvorotkm). За 5 дней прокачать коммуникацию невозможно. Но можно определить точку А и составить план на следующий год. Практикум так и называется: «Ищем точки роста в коммуникации и составляем план развития на 2024». Бесплатно. 11-15 декабря. Реклама. ИП Клименко Александра Аркадьевна, ИНН 772077460576, erid: 2VtzqxTPMs8

​​Avito Tech Managers meetup #1 14 ноября 18:30 | в офисе на Лесной и онлайн Авито делает первый митап для тимлидов тимлидов. Для меня эта роль новая, поэтому интересно самому. Среди спикеров — Женя Рейх, с которым мы делали митап для тимлидов и публичное собеседование тимлида на подлодке. О чём поговорим: 🕚 запуск нового направления и его партнёрство с продуктом и бизнесом — Андрей Хышов, СберМаркет; 🕚 поиск и подготовка тимлидов — Александр Афенов, Авито; 🕚 управление командой без микроменеджмента — Евгений Рейх, Авито; 🕚 синдром самозванца у менеджера — Илья Прахт, IT-ментор. Между докладами будут кофе-брейки, а ценность мероприятия еще и в нетворкинге. Для участия офлайн нужно бесплатно зарегистрироваться. Онлайн-трансляция тоже будет. До встречи!

​​Как мы провели Kick-off за 8 часов и какие вынесли уроки Disclaimer: это не универсальная инструкция по проведению любой kick-off встречи. Ваш kick-off должен закрывать ваши потребности, которые вам же сначала нужно определить. В помощь для подготовки — предыдущий пост Kick-off встреча — это отсечка: «Всё, с этого момента работаем как две отдельные команды». Наполнение встречи может быть разным, и зависит от проблем и команды. Итак, подготовка к разделению дала такие вводные: — Есть предварительные составы команд — Видны дисфункции, которые можно побороть при сетапе новых команд: 📌 Задачи едут из спринта в спринт 📌 Бэки работают отдельно, клиенты — отдельно. Не понятно, в какой момент можно будет «пощупать» фичи на клиентах 📌 Ожидания продакта не всегда совпадают с тем, что получается на выходе С помощью Kick-off встречи я хотел: 1️⃣ — Окончательно сформировать составы команд и дать ребятам возможность коллаборации, чтобы начать срабатываться 2️⃣ — Придумать названия для новых команд 3️⃣ — Изменить подход к проработке задач. Внедрить нарезку задач по User-story с описанием критериев приемки Это должно решить проблему несовпадения ожиданий продакта и поставленного инкремента. 4️⃣ — Сформировать Definition of Ready Это должно порешать проблему с переезжанием задач. DoR — чеклист, прокликав который мы говорим: «Задача почти гарантированно может быть сделана за спринт» 5️⃣ — Сформировать Definition of Done Это должно обеспечить долгосрочное качество. 6️⃣ — Установить регулярные встречи — как финальный аккорд в установке процессов внутри команд и ответ на вопрос «что будет дальше». Как видите, хотел много. Получилось не всё 🙂 Что получилось хорошо: — Самое главное: состав и названия определили. Новые команды стартовали — До сих пор работает нарезка задач на целиковые User-Story, включающие в себя и бэк, и клиент, и QA — Одна из команд получилась супер автономной. Её я отпустил почти сразу, а скоро в ней вырос тимлид. Из неё не хотят уходить люди, даже когда заманивал их в платформенную core-команду Что было плохо: — Это была встреча на целый день, хоть и с перерывом на обед и перекурами. Это слишком много, мозг разработчиков отказывается работать в таком режиме. — Проводя Kick-off сейчас, я бы не стал делать DoR и DoD в тот же день. Это отъело часа 4, но использовалось так себе, и в последствии обе команды еще несколько раз пересмотрели эти чеклисты. С того дня прошел год. Одну из команд мы поделили еще раз, не повторив прошлых ошибок. На скрине — красивый шаблон, как можно за полтора часа сделать командообразующую kick-off встречу. Ниже положу ссылки на Miro-доску, на случай если что-то захотите взять себе. Шаблон Kick-off на целый день Шаблон Kick-off на полтора часа

Авторитет Кто-то может считать, что иметь авторитет = быть самой сильной обезьяной. А тимлидом становятся, победив предыдущего тимлида в честном кодревью 🙂 Я считаю, что авторитет — это кредит доверия. Когда вы можете приносить непопулярные идеи, и вас не пошлют, а выслушают. Потому что доверяют. А иногда кредит доверия позволяет срезать углы и бежать быстрее, не тратя время на объяснения. Но это крайний случай и портит кредитную историю. И не важно, выросли вы в тимлида изнутри или только онбордитесь, о кредитной истории надо заботиться, чтобы работать было проще. Представьте ситуацию: К вам приходит продакт и говорит, что появились новые вводные в задаче, которую вы собирались разрабатывать в следующем спринте. Учитывать новые вводные — потратить еще неделю на проработку задачи и пересмотреть техническую декомпозицию. Вы уточнили необходимость, убедились, что делать надо, и если сейчас не учесть, то потом придется переделывать. Вы говорите с командой и спрашиваете, кто хотел бы технически поисследовать несколько корнер-кейсов. На что слышите раздраженный ответ: — Блин, мы уже две недели потратили, чтобы прогрумить эту фичу в таком виде. Половину придется выкидывать. Тебе что, не жалко наше время? Что вы бы ответили в такой ситуации? Думаю, первый вариант, который приходит в голову — узнать, понимают ли ребята негативное влияние, если запилить так, как собирались. И это правда важно сделать, но не сразу, ведь перед нами не просто возражение, а манипуляция. Когда вы не видите манипуляции и поддаетесь на них, или если разрешаете себе не реагировать на них, ваш авторитет снижается. Жестко настоять на своем и забить на мнение ребят — тоже плохой вариант, при котором вы снижаете свой кредит доверия. Вы рискуете создать атмосферу, в которой люди будут бояться выражать свою точку зрения и получить демотивированную команду. Напишите в комментариях, что должен сделать хороший тимлид в такой ситуации. Мне нравится разбирать такие кейсы. Потренироваться будет возможность на бесплатном практикуме от Soft Skills Lab Саши Клименко (@normalno_delaj) и Юры Клименко (@razvorotkm). Практикум «Как мы нарабатываем авторитет и как мы его теряем?» проходит с 1 по 5 октября. За 5 дней практикума вы: ▫️ поймете, как формируется авторитет, что на него влияет ▫️ увидите, как он может влиять на зарплату и карьерный рост ▫️ освоите универсальные приемы выстраивания и защиты личных границ в играх-ролевках ▫️ научитесь выносить на переговоры нужные проблемы и использовать результативные управленческие воздействия Подробная инфа и регистрация — в канале Soft Skills Lab Бесплатно. Реклама. ИП Клименко Александра Аркадьевна, ИНН 772077460576, erid: 2VtzqucWuA2

Тегаешь коллегу — дай краткую вводную … тред в рабочем мессенджере на 100 сообщений … @ Nikita Khromushkin, поможешь тут? … Да, конечно! Сейчас, только прочитаю предыдущие 100 сообщений. (про себя: мне б кто помог) В последнее время выработал такой ответ: «Ребята, не смогу вгрузить весь тред, дайте краткую выжимку и что от меня требуется?» Идея простая: если тебе нужно, чтобы тебе помогли — помоги первый. Прояви заботу о получателе сообщения — увеличишь шансы, что он тебе поможет в ответ. Заодно свои мысли структурируешь, и поймешь, что на самом деле нужно от коллеги. Может быть, и призывать не придется. Упакуй свой запрос в удобную форму: 1️⃣ — О чем тред 2️⃣ — Какой возник вопрос 3️⃣ — Чего хотим от коллеги ============================ Пример Тред на 50 сообщений, где инженеры разбирают багу, которая на самом деле фича. Меня туда призвали формулировкой «Давайте призовем Никиту для контекста». Пришлось вгружать весь тред, чтобы полностью понять контекст и что с этим делать. Этот вопрос я переадресовал продакту, предварительно упаковав в удобно воспринимаемый формат: «Илья, нужно принять продуктовое решение по багу. Есть пользователи, у которых … Есть предположение, что таким пользователям нужен ... От тебя нужен концептуальный ответ, можем ли конвертировать баг в фича-реквест?» Это простая идея, которую я почерпнул в книге «Новые правила деловой переписки». Но этот пост пишу после какой-то адской недели призывов без контекста. Если вам что-то нужно от коллеги, — то упростите ему работу, позаботьтесь о нем. У вас контекст уже есть в голове и это займёт минуту, а коллеге сэкономит минут 15 чтобы вникнуть. Верю, что этот пост принесет пользу: кто-то позаботится о читателе, упакует информацию в удобном для коллеги виде, и получит в ответ то, что хочет.

​​Как подобрать состав команд при разделении Продолжаем цикл лонгридов про разделение команд. Первый пост тут. В идеальном мире продуктовые разработчики самоорганизуются на две идеальные команды. Но мы не в идеальном мире, и есть риск что составы получатся не оптимальные. Здесь нужна помощь человека который соберет все-все-все контексты с ребят и предложит оптимальный вариант. В идеальном мире вы хорошо знаете свою команду и в голове интуитивно уже подобрали состав. Но мы не в идеальном мире и есть риск что интуиция ошибается. Давайте попробуем систематизировать Нужно с помощью разработчиков ответить на ряд вопросов. Это не исчерпывающий список, буду рад предложениям в комментах. 📌 — Какие навыки нужны команде, кто из разработчиков что умеет и в каком направлении хочет развиваться Здесь поможет упражнение StarMap. Можно пройти его вместе с командой, а можно самому. Если проходить вместе, то рассчитывайте часа на 4 минимум. Дорого, зато у ребят появится командный артефакт, о котором они могут заботиться, и который может быть частью их самоидентификации. Если составлять индивидуально, вам всё равно придётся собирать информацию на 1-1, и суммарно времени потратите не меньше. 📌 — Кто какую роль занимает в команде сейчас и какую может занять в новой команде Здесь можно идти по интуиции и личному впечатлению от ребят. А если есть желание системно подойти к вопросу — посоветую хороший сборник статей: Работа в команде — модели, теории, алгоритмы В этом сборнике советую обратить внимание на профиль управления командой Маргерисона-Макканна. Чем-то похоже на модель Белбина, но расширяет её. Есть сложность — у нас только один тимлид и один продакт. Один из инженеров хочет расти в тимлида, но он только что пришел в компанию и прямо сейчас еще онбордится. Нужно дать ему возможность вырасти, а для этого команда должна быть сильной и более автономной. Недостаток тимлида и продакта будем компенсировать ролями координатора и исследователя. А взращивать будем с помощью практики фича-драйвинга. 📌 — Кто с кем хочет работать Здесь стоит учесть персональные связи участников. Не стоит разлучать ментора и менти. И наоборот: возможно, есть личная несовместимость между двумя разработчиками, и они не хотят друг с другом работать. 📌 — Кто какие фичи хочет делать. В одной команде большой объем новых client-facing фич. В другой — переделка корневых механик авторизации и управления данными, которые менее заметны клиенту, но более сложные. Приведу упрощенный пример нашего уравнения Disclaimer: все имена вымышленные. Вася — душа команды, уже взял на себя фича-драйвинг объемной фичи А, которая пойдёт в разработку в команду А. Антон — ценный мидл «педалёр», очень быстро пишет много качественного кода. Он хочет работать с Васей. И задачи команды А ему подходят. Петя — ментор Антона, супер-эксперт. Задачи команды А для него будут скучноваты. Костя — хороший интегратор, он фича-драйвер фичи Б, которая входит в скоуп команды Б. Фича Б — супер сложная и на ней нужен Петя. Антон хочет работать с Васей и не хочет работать с Костей. Допустим, есть еще несколько мидлов, которым не принципиально, с кем работать. Как бы вы распределили ребят по командам? Правильного ответа на этот вопрос нет, предлагаю порассуждать о вариантах действий в комментариях. P.S. У нас было 12 разработчиков и 3-4 вот таких коллизий как у Антона. По итогу все решили, и спустя год ребята не хотят менять состав 🙂

​​Этап 1. Подготовка к разделению команд. Итак, о чем точно стоит позаботиться заранее: 1. Определить потребность разделения 2. Проработать принцип разделения, предназначение команд 3. Подготовить разработчиков 4. Определить предварительный состав команд 5. Позаботиться о процессах в будущих командах Потребность должна быть надолго. Формирование команд — процесс дорогой и болезненный. Поэтому если у вас есть уверенность только на пару месяцев, а дальше полный туман — возможно стоит начать с подстройки процессов и / или рабочих групп внутри одной команды А еще потребность должна быть очевидной для всех, включая разработчиков в команде. Разделение должно решать проблемы. Например: «нас много, мы медленные», «слишком много контекстов». В нашем случае потребность виднелась на горизонте года, две команды были обоснованы проектом, который мы пилили, и на масштабе 12 человек ребята сами стали жаловаться на количество контекстов и коммуникаций. Принцип разделения — от продуктового направления У нас был проект размером в год. В нём два больших направления: «Управление профилями» и «Использование мультипрофиля». Вот это и стало основополагающим принципом: по доменным областям ответственности. Это было достаточно очевидным решением, которое поддержали продакты. У вас может быть другой принцип. Например, выделение платформенной core-команды, чтобы делать долгосрочные технические улучшения и ускорять работу продуктовых команд. Для выделения такой команды может понадобиться сильно договариваться с продактами. Подготовить разработчиков Тут нужно на 1-1 и на общих встречах спрашивать у ребят, видят ли они проблемы в текущем составе, и как можно их решить. Команда может быть консервативной: ребята сработались и не хотят терять связь друг с другом. Тогда они сами могут предложить концепт рабочих групп. Здесь можно подсветить, что рабочие группы могут стать слаженными «подкомандами» и разделение случится само собой. Это тоже рабочий вариант, тогда вернуться к вопросу можно будет через квартал или полгода. Определить состав команд Чтобы состав был авторизован командой, нужно учесть возможности и желания каждого. Скорее всего не получится все хотелки удовлетворить, но там где не получается — важно показать трейдофф и дать разработчику самому принять решение. Это очень интересное составное уравнение с кучей переменных. Получился такой лонгрид, что решил вынести его в следующий пост. =========================== В качестве иллюстрации к посту сделал MindMap подготовки к разделению. Картинка к посту получилась шакальная, поэтому вот ссылка на исходник в Miro.

​​Как мы команду делили Наверняка вы слышали про предельный размер команды: 2-pizza team, 7±2, 6±3 и экспоненциально растущее количество связей между людьми при росте команды. Последние 5 лет я работал в предельно больших командах и мне очень хотелось разделиться. В Авито мне повезло получить этот опыт, при чем дважды. Прошлым летом я делил команду сам, а этим летом помогал избежать моих ошибок тимлиду одной из команд. Предыстория такая: В марте 2022 я пришел тимлидить команду из 5 инженеров и у нас был активный найм и рост. К июню нас стало 10 и на подходе были еще +2. Стало очевидно сложно работать в рамках одной команды. Слишком много встреч, слишком много направлений работы, которые не может вместить в себя каждый участник команды. А впереди еще был найм 6 инженеров. Очевидно, пришло время делиться. В следующих постах я расскажу о том, как делил команду впервые в жизни. И на какие грабли наступил тоже обязательно расскажу 🙂 Посты разделил по этапам: 1️⃣ Подготовка. Принцип разделения и выбор состава команд На самом деле на этом этапе происходит 80% работы. О чем стоит позаботиться заранее: — Проработать потребность и принцип разделения — Подготовить разработчиков к будущему разделению — Определить предварительные составы команд — Позаботиться о процессах в будущих командах 2️⃣ Kick-off — «оставшиеся» 20% работы. Это встреча — отсечка запуска новых команд. Здесь каждый участник соглашается с составом команд и процессами. Здесь ребята вырабатывают первые командные договоренности. На картинке — один фрейм с доски этой встречи, где есть последний шанс поменять состав. Мы делились целый день, и это было выматывающе. За то сразу договорись о процессах, DoD и DoR. В следующий раз kick-off разбили на несколько этапов по 1,5 часа. Было сильно легче. 3️⃣ Первые спринты после запуска. А вот тут кроются еще 80% работы 🤪 Она заключается в помощи командам и работе над ошибками. Здесь вылезет всё, о чем не подумали на этапе 1. Например, банальное — На планировании надо куда-то накидывать задачи и стартовать спринт, но нет отдельных досок в джире, только общая, доставшаяся «в наследство». Но это мелочь, джира позволяет вести несколько параллельных спринтов на одной доске и не видеть задачи друг друга. Хуже было то, что мы не сразу завели отдельные чаты по командам, и писали о задачах вперемешку в общий чат. Из-за этого первое время ребятам было сложно «отпустить» задачи другой команды. Если вы уже проходили этот путь — поделитесь в комментах своим опытом. Интересен будет как взгляд изнутри, со стороны разработчика, так и со стороны тимлида / скрам-мастера. На что стоит обратить внимание? Какие ошибки совершили, как их можно было бы избежать?

⠀ Product Sense Прежде чем писать этот пост, я спросил у нашего принципал продакта: Илья, это ценная конфа? «Обычно да, так как довольно требовательно отбирают спикеров и темы. Я был один раз, но остались очень крутые впечатления от воркшопов» Поэтому я согласился порекламировать конфу. И да, Илья идёт на неё, а я буду смотреть в онлайне 🙂 4-5 сентября, оффлайн в Москве или онлайн Ключевые темы — об инструментах и «слепых зонах» в создании продукта, ожиданиях от менеджеров, управлении командой, бюджетом, собой. Смотрите, какие крутые спикеры и темы в расписании! Я бы сходил послушать @dsoloveev из QIWI про использование ИИ в работе. И Алёну Медведеву, юнитлида из Авито, про синдром самозванца. А еще на воркшоп про систематизацию продуктвой проработки задач от Никиты Ефимова, директора Яндекс.Практикум. Кстати, скоро будет бесплатный ютуб-воркшоп от Никиты. В общем, советую посмотреть темы и прикупить билетик, хотя бы на онлайн. Кстати, завтра (12 августа) обещают поднять цену. Вот ссылка на лендос конференции

Digital Nomad в Испании Мы получили одобрение внж Испании на 3 года! Теперь я официально Teletrabajador de caracter internacional. Disclaimer: этот канал не превращается в тревел-блог. Но это очень важный этап, которым хочу поделиться, и который возможно кого-то вдохновит на релокацию. Чтобы пост принёс пользу, приложу ссылки на ресурсы, с помощью которых я готовился к этому проекту: 💡База знаний на Notion, в которой всё-всё-всё про документы и процесс 📌@digitalnomadspain — Канал, где публикуют кейсы одобрений и самую актуальную инфу по получению документов. Вот ссылка на мой пост там. 📌 @chatfornomads — чат при том канале, можно поиском найти ответ на вообще любой вопрос. ============================ Итак, дано: 1. В Тбилиси классно, но хотим двигаться дальше 2. В идеале — в страну, где ребенок сможет претендовать на гражданство 3. Получить оффер и быть релоцированным Европейской компанией — простой путь. Но уходить из Авито не хочу. 4. Аргентина — не вариант, часовой пояс не даст работать И тут как раз Испания с этого года запускает выдачу резиденции для цифровых кочевников. 15 мая мы с супругой и собакой выехали из Тбилиси в Москву, чтобы собрать все документы и 3 июня стартовать в обратную сторону. Предстояло проехать 7500км через Россию, Грузию, Турцию, Грецию, на пароме в Италию, затем Франция и наконец Испания. За время пути я взял всего 4 дня отпуска, всё остальное время работал. По дороге были моменты грустные и веселые. За поездку мы жили в 24 разных апартах. Мы купались в трёх морях. Жрали осьминогов на гриле. Ночевали под горой Олимп. Ночевали с машиной на пароме. Гуляли по Риму. Были в Ватикане и Монако. Держали пизанскую башню. Ночью нам разбили окна в машине, чтобы вытащить багаж. Достали один чемодан, где был собачий корм, поводок и барахло. А второй чемодан с ценной электроникой и документами не пролез в разбитое окно, и они его оставили. Вот оно, везение 🙂 4 июля мы подали документы на рассмотрение, а 11 июля у нас истёк шенген. Пока ждали решение по внж, мы всё еще легально находились на территории Испании. Но в случае отказа — «первым прямым рейсом домой». А мы на машине, с собакой, супруга беременная так что уже на самолет не посадят, да и рейсов прямых нет 🙂 Короче, отказ не вариант. И вот, на днях пришло одобрение. Сейчас мы обосновались в Валенсии. Сняли квартиру на долгосрок, прописались, сдали отпечатки пальцев, ждём карточки резидента. Это был большой проект. И он успешно запущен. В процессе еще один большой проект, ради которого затевалась релокация — примерно в октябре я стану батей.

​​Управление рисками Все слышали, что бас-фактор=1 — это плохо. Это очевидный риск, на который все рекомендуют обращать внимание и устранять: писать документацию, распространять экспертизу внутри команды и растить замену единственному эксперту. А какие еще есть очевидные риски? А какие неочевидные? Редко встречал системное управление рисками. По сути всё, про что пишу — простые штуки из разряда «подумайте заранее, запишите и обращайте внимание в будущем. Вот пример». Очень простые истины, тем не менее до которых надо дойти своим умом. Но вот риск-менеджмент всегда звучал для меня как какой-то булшит. А оказывается, это простая штука про заранее предположить, где и что у вас отвалится, подумать как минимизировать вероятность что отвалится, и что делать если таки отвалится. Можно делать в формате брейншторма или футуроспективы всей командой. Можно делать индивидуально. Можно доверить инженерам проработку рисков по их части, в том числе по QA. Во что это воплощается — можно посмотреть на примере карты рисков, которую составил наш QA-инженер, который недавно получил промо в сеньора (кусочек на картинке, полная версия — в публичной гуглотаблице) В Авито проработка рисков — базовое ожидание от тимлида. 31 мая пройдет открытый бесплатный вебинар от Отуса «Риск-менеджмент для тимлидов». Отусу я доверяю, потому что там преподают люди, с которыми я работаю и которым доверяю. Я записался, рассчитываю систематизировать знания и узнать что-то новое. Заявлены такие тезисы: — В чем смысл рисков и зачем ими управлять — Зачем риск-менеджмент тимлиду — Как управлять рисками, чтобы в этом были смысл и польза — Управление рисками не в работе Вебинар бесплатный, записывайтесь по ссылке: https://otus.pw/qPcy/ 31 мая. 20:00 GMT+3.

Папка тимлидов Недавно я написал пост-знакомство про этот канал. Сказал, что цель канала — приносить пользу, а основная метрика — количество репостов. Всего лишь неделю назад я считал достижением и хвастался постом на 77 репостов. Прошлый пост «О чем спросить работодателя» собрал 245 репостов оО. Тут нужно сделать ремарку, что артефакты в этом посте — плод коллаборации четырех человек на Podlodka Teamlead Crew. А я всего лишь вел сессию, шарил экран, записывал со слов ребят и фасилитировал. К чему это я. Подписывайтесь на папку с тимлидскими каналами. Там такого добра навалом. 14 каналов, почти на все из них я уже был подписан, что-то даже репостил, поэтому могу смело рекомендовать. https://t.me/addlist/mDWR2gD6UEhlOWRi P.S. Этот пост я тоже считаю полезным. Несмотря на то что папки с каналами уже задолбали, кто-то найдет для себя пользу в конкретно этой папке 🙂

​​О чем спросить работодателя — чеклист Новый сотрудник — всегда двусторонняя инвестиция: — компания инвестирует деньги в собеседования, оформление, технику, зарплату сотрудника, его руководителя и бадди — руководитель и коллеги вкладывают в новичка свое время и ресурс — новичок инвестирует свое время и ресурс в прохождение интервью, увольняется из текущей компании, погружается в предметную область, технику и процессы новой компании. Короче, новый сотрудник = инвестиция дофига денег, времени и сил с обеих сторон. Поэтому для меня важно, чтобы люди задерживались с нами на несколько лет. Если сотрудник уходит через 3 месяца-полгода-год, то, скорее всего, инвестиция не окупается. Часть таких увольнений происходит из-за того, что в процессе найма кандидат не убедился в том, что ему подходит компания, позиция, продукт. Компании выстраивают мега-процессы найма, чтобы убедиться, что кандидат точно-точно подходит. На вопросы кандидата обычно закладывают 15 минут. Мне кажется, что пропорция «час на вопросы кандидату» : «15 минут на вопросы кандидата» не справедливая. Поэтому привет и спасибо ребятам из Авито, которых я в сумме мучил около 4-5 часов прежде чем принять оффер. О чем спрашивать — тема индивидуальная. Для кого-то важен продукт, для кого-то — процессы. Кто-то повидал некоторое дерьмо и ему важно убедиться, что такого не будет на новом месте. На позапрошлом сезоне Podlodka Teamlead Crew мы делали брейншторм «О чем спросить работодателя» На выходе получились два артефакта: 1⃣ Mindmap вопросов в Miro С разбиением по этапам и возможным развилкам: Предварительный поиск инфы, чтение вакансии, HR-скрининг, тех. интервью, встреча с руководителем. 2⃣ Чеклист вопросов в гуглодоке С разбиением по темам: компания, проект, подходы, метрики, задачи, полномочия, руководство, команда, техника, условия. Ну и само собой, есть запись сессии. Как член ПК, я не могу публиковать ссылку на видос, потому что он в закрытом плейлисте. Но участники сессии могут. Вот, Женя Антонов у себя в канале постил: https://t.me/general_it_talks/320

Пост-знакомство плюс бонус-контент Привет. Пару лет назад я написал пост про этот канал и повесил его в закреп. Сегодня подписалось как никогда много людей, а интро чутка устарело, поэтому пора обновить. Итак, Канал — о продуктовой разработке изнутри, глазами инженера. В душе я все еще инженер, хотя в трудовой — инжиниринг мемеджер. Меня зовут Никита Хромушкин, и я тимлид тимлидов в Авито. Пишу про образ мышления, роли, процессы, события и артефакты продуктовой разработки. Иногда про участников процесса. Иногда про найм с обеих сторон. Пост обычно рожаю часов за 16, с вычиткой, обратной связью от коллег и редактурой от жены. Изначально завел канал, чтобы формулировать свои идеи и доносить их в свою команду. С тех пор аудитория немного расширилась, но основная концепция осталась. Канал призван приносить пользу. Основная метрика, в которую целюсь — количество репостов. Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими. Например, ровно год назад я написал пост про ИПР, который репостнули 77 раз. Считаю, полезно получилось. Изюминкой канала считаю артефакты, которыми охотно делюсь: DoR, DoD, Windrose для плана развития, всякие рисуночки-графички, схемки. Чуть позже напилю навигатор по постам с артефактами. Вкратце, в общем, познакомились. Добро пожаловать, или снова здравствуйте. ========================= Бонус-контент для старичков канала Недавно меня позвали в масонскую ложу авторов каналов про продуктовую разработку. В чатике топовые ребята, эксперты индустрии, кладезь знаний и все с каналами. А на днях телега выпустила новую фичу — можно делиться целой папкой с каналами. Собсно, решили затестить. Для новоприбывших это уже не новость, а вот для старичков канала может быть полезно. Вот тут собраны топовые каналы топовых продактов и не только: https://t.me/addlist/YvmnHCHUp700Nzky Если не работает — повод обновить телегу. После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.

Product camp Это бесплатный анонс бесплатного мероприятия. Оно позиционируется как для продактов, но вы найдете интересные доклады даже если вы не продакт. Например, есть доклады в треках «Управление процессами и командой», «Коммуникация с командой», «Soft Skills». Мероприятие пройдёт через выходные, 15-16 апреля. Регистрация на сайте Суть кемпа в том, что это реально пионерлагерь на два дня в отеле в Подмосковье. Но будет и онлайн и записи. Собсно, записи прошлых кемпов уже есть, можно посмотреть чего примерно ожидать. Ну и понятно что не докладами едиными. На сайте выложен список спикеров и гостей, там какие-то вообще топовые господа из топовых компаний, типа Авито, Ozon, Tinkoff, Яндекса и других. В этот список можете попасть и вы. Я бы пошел только ради того, чтобы кем-то из них пообщаться. Ессно, потому что такой нетворкинг конвертится в трудоустройство, сейчас или в будущем. В прошлом году мы там себе продакта нашли 🙂 Для онлайн участия тоже надо зарегаться. Бесплатно. На сайте.

Зачем нужны тимлиды? В четверг будет подлодошный круглый стол на эту тему. Предлагаю чуть порассуждать заранее, а потом свериться с уважаемыми господами. Один из моих любимых вопросов на собеседовании — зачем тебе тимлид? Ответ по сути говорит о том, что инженер ждет от меня. Интервью ведь и нужно, чтобы прояснить взаимные ожидания. Прояснить всё, что тебе нужно — ответственность каждого участника интервью. Но не все кандидаты могут сформулировать правильные вопросы. Тем не менее, неловко будет нанять человека, которому я не смогу дать то, что он хочет. Поэтому я спрашиваю и уточняю. Самые частые ответы примерно такие: — Не знаю, не задумывался — не ответ, надо копать дальше другими вопросами. — Задачи заводить и распределять. Здесь еще важно узнать, какой гранулярности задачи хочет получать человек. Честно говоря, моя идеальная команда сама заводит таски в джире и сама их распределяет 🙂 Мне важно, чтобы крупные стримы размером с квартал оказались под крылом нужных людей. — Процессы налаживать. Если за этими словами стоит какой-то реальный образ, то вот это может быть ценный кандидат, повидавший некоторое дерьмо. Надо уточнить, какого рода процессы и как именно налаживать. Главное, опять же, чтобы кандидат не ожидал в лице тимлида видеть скрам-мастера. — Конфликты решать. Вот тут может быть либо конфликтный / притягивающий конфликты кандидат, либо опять же повидавший некоторое дерьмо. Лучше бы детальнее копнуть. В моей идеальной команде конфликты — конструктивные, возникают регулярно, приводят к улучшениям и проходят без участия тимлида. Но это мечты 🙂 Потом я доуточняю: «Это всё про команду. А вот тебе лично — зачем тимлид?» В ответ обычно: — Развитие, карьерный рост. Очевидно, но каким образом? А как кандидат сам развивается? — Обратная связь. Вот тут вопросов нет. На удивление редко это отвечают, кстати. Можно доуточнить кейс, где кандидату давали корректирующую обратную связь , и узнать, как он её применял. — Мне не нужен тимлид. Не путать с «не знаю». Это мой любимый, идеальный ответ. Человек, который так ответил, сейчас показывает всей команде ролевую модель. И собрал 70% оценок «выше ожиданий» от сокомандников на ревью. Сам находит себе инженерно сложные, развивающие челленджи. Может работать в неидеальных процессах. Если процессы совсем плохие — сам начнет их оптимизировать и команде продаст. Конфликты поворачивает в конструктивное русло. Разве что обратная связь иногда нужна, чтобы свериться, что в ту сторону гребет. Это не исчерпывающий список, но из ответов и моих комментариев можно проследить тренд: тимлиды не нужны. Вернее, так: хороший тимлид стремится сделать так, чтобы он был не нужен в команде. Чтобы если он уходит в отпуск, ничего не менялось. Если перформанс команды просядет, значит, что-то тащил на себе. Если перформанс улучшится, значит мешал. В общем, мой ответ такой: Тимлид нужен, чтобы привести команду в состояние, когда тимлид не нужен. А вы как считаете? Что ответили бы сами, или что вам отвечают кандидаты на вопрос «Зачем тебе тимлид?»