​​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

Из наших:
- VK ID (Плюс OK и Mail)
- Яндекс ID (читай, все сервисы Яндекса)
- Плюс все, кто прикрутил вход через VK ID / Яндекс ID на свои сервисы

Плюсы:
— Очень user-friendly. В самых простых кейсах не нужно даже вводить логин, т.к. он сохранен в браузере. То есть просто на сайте нажал кнопку «войти», приложил палец к сканеру на ноуте и вошел. Ни забытых паролей, ни ожидания смс.
— Безопасность на уровне Yubikey, а то и выше. В отличие от ТОТП, не происходит обмена секретами. Так же как в случае с Yubikey, нет возможности фишинга ОТП-кода. А если украли телефон, то чтобы воспользоваться им нужно его разлочить.
— Не нужно ставить и настраивать доп приложения, не нужно покупать доп девайсы.
— Не нужно реализовывать доп сценарии в своих приложениях типа QR-кода или кнопки «да, это я». Уже всё реализовано в браузерном API и в нативе на мобилках.
— Бесплатно. Не нужно платить за пакет СМСок. Нет проблем с «зарубежными номерами телефона».

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

Мое мнение:
За этой штукой будущее, но прямо сейчас делать это исключительным способом входа нельзя. У всех приведенных примеров этот способ — дополнительный. Хотя уже сейчас можно заходить в Google без пароля, но есть fallback-вариант в виде старых добрых «пароль + смс».

Тем не менее, возможности которые эта технология дает, уже сейчас можно использовать. Например, если нужно защитить самые ценные учетки, и вы думали прикручивать TOTP — рассмотрите WebAuthN в качестве второго фактора.

https://webauthn.guide/ — Почитать, лендос + дока
https://webauthn.io/ — Потыкать самому, зарегистрироваться + залогиниться

​​Кто хочет вашу цель спринта?

«Цель спринта» — концепция простая с первого взгляда, но с кучей подводных камней. Мы с командами знатно походили по граблям, но все равно продолжаем ставить цели спринтов. Каждый раз, наступая на грабли, я страдал и через страдания делал некоторые умозаключения.
Вот решил поделиться.

Disclaimer: не навязываю никому «этот ваш скрам». В моем юните 3 команды работают двухнедельными спринтами и одна — по канбану. Этот пост — послание самому себе на 5 лет назад, чтобы меньше фрустрировать.

———

Говорят, что команда отличается от рабочей группы тем, что у команды есть общая Цель.
В идеале — вся команда объединяет усилия, чтобы за спринт родить эту Цель.
Цель мечты — качественную, отвечающую всем критериям приемки и доделанную до Definition of Done.

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

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

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

Так появляются две цели. Три цели. Шесть целей. Отдельные цели у фронтендеров и бэкендеров.

Зачастую инженеры сначала набирают задачи в спринт, а потом пытаются из этого родить цель.
Так в одном спринте появляются цели типа
1. «Три ручки из пяти под фичу Х»
2. «Верстка экранов + интеграция с бэком под фичу Y».
3. «Раскатка фичи Й»

Выглядит как мини-вотерфолл по трём проектам.
Нахрена нам кросс-функциональная команда?
Кому нужны такие цели?

Захочет ли продакт участвовать в жизни команды, которая занимается тем что напиливает ручки и верстает экраны?
На что ему смотреть на ревью спринта?

———

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

Не можем сделать целиком сценарий фичи, напилив 5 ручек?
Тогда цель может быть: «Короткий успешный сценарий фичи Х».
А DoD может включать пункт «Реализовано на всех платформах».

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

Можно убедить продакта: «Сценарий целиком займёт 3 спринта», и потерять его из жизни команды на 1.5 месяца.

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

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

Кто хочет эту цель спринта?

И постарайтесь сделать так, чтобы каждую цель кто-то явно хотел.

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

Дайджест полезностей в продуктовой папке

Как-то я затесался в тусовку авторов каналов про продукты, а этот канал попал в папку с каналами Products. Внутри — куча полезностей, и не только от продактов.

📌 В канале Фичизм нашел подтверждение актуальности проблемы «угона» сим-карт, о которой я писал раньше — Билайн сделал второй фактор по емейлу при «восстановлении» симки. После прочтения сразу нашел в настройках, включил и вам советую 🙂 https://news.1rj.ru/str/fichism/51.

📌 Менеджер от боженьки рассказывает, как выбрать, что рефакторить. https://news.1rj.ru/str/pm_god/424

📌 Владимир Меркушев разбирает кейсы из продуктовой разработки, недавно был про A/B тест длительностью 2 часа. https://news.1rj.ru/str/vladimir_merkushev/2089

📌 Fresh Product Manager запостил ссылку на статью про коммуникацию продакта с командой от Ангелины Зинченко из Авито https://news.1rj.ru/str/FreshProductGo/1025

📌 Саша Клименко проводит вебинары про работу с манипуляциями и отстаивание своих интересов: https://news.1rj.ru/str/normalno_delaj/564

📌 Михаил Греков нашел еще одно отличие продукта от проекта: в продукте нужна смекалка! Приводит прикольные кейсы её проявления, например хак оптовых заказов на заре Амазона: https://news.1rj.ru/str/proudobstvo/1212

Подписывайтесь на папку Products, чтобы читать такие полезности.
После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.

​​Как и зачем декомпозировать User Story — 21 шаблон

Давайте представим, что мы делаем некий MVP. На дискавери потрачено 3 месяца. Скоуп определен, дизайны отрисованы и требования подробно описаны. На разработку заложено еще 3 месяца. Катить на пользователей что-то меньшее, чем этот скоуп — бессмысленно. Например, зачем видеть список товаров, если корзины нет и оплатить невозможно.

Итак, тз описано и срок в три месяца на разработку начал тикать.
Продакт может отойти и не мешать. Ведь никто не любит, когда заглядывают за плечо и спрашивают «ну когда». А он же хороший руководитель и доверяет своей команде!

…

Следующий кадр: прошло 3 месяца, продакт смотрит, что получилось.

А получилось, что параллельно делали всё, закопались и ни один сценарий целиком не успели.
Команда говорит, что показать промежуточный результат не могут и нужен еще 1 месяц.
А через месяц нужен еще 1 месяц.
В итоге через 5 месяцев сдают проект. И вроде бы всё по тз, но «не то».

«Программисты виноваты!» — скажете вы.
«Какое тз, такой и результат!» — ответят программисты.

Всем плохо: программисты без премии, продакт с кривым MVP, которое уже никому не нужно.

Можно ли было помочь и команде и продакту? — Да!

Очень часто в продуктовой разработке мы изобретаем водопадные процессы.
Долго и тщательно дискаверим, по мере уточнения требований предполагаемый срок деливери увеличивается.
В итоге пилим проект, размером в квартал/полугодие/год.
А чем дольше горизонт планирования, тем больше вероятность не попасть в оценки.

Поэтому есть простое решение, как лучше попадать в сроки и делать «то», благодаря более частой обратной связи:
Вместо долгого дискавери, мелко декомпозировать и начинать деливери.
А параллельно доделывать дискавери по другим частям.

Вот как мог бы выглядеть процесс разработки нашего MVP по спринтам:

0️⃣ — Для старта проекта нам нужно хоть какое-то описание первой функции. Быстренько дискаверим, как должен выглядеть список товаров. Пока пофиг на фильтры и поиск. И пофиг что будет не идеально. Посмотрим вживую, потом поправим.

1️⃣ спринт — разработаем список товаров без поиска и фильтрации. Параллельно будем дискаверить фильтры и поиск.
К концу спринта смотрим, как выглядит вживую список товаров. Даем команде обратную связь, чтобы учесть правки в следующем спринте, либо отложить их на конец.

2️⃣ спринт — приделаем фильтры и поиск. А дискавери работает на следующий спринт: как должна выглядеть корзина.

3️⃣ спринт — сделаем корзину и возможность добавлять туда товары. Параллельно дискаверим оплату.

4️⃣ спринт — сделаем процесс оплаты на моках, и только успешный сценарий, без корнер-кейсов, неудачной оплаты и возвратов.

…

И так далее — до момента, когда уже можно релизить.

Да, нет смысла катить на пользователя экран со списком товаров без возможности поиска.
Но есть смысл декомпозировать MVP на мелкие User Story не больше 2 недель в разработке. И одной из таких User Story может быть «видеть список всех товаров».

Так мы решаем сразу обе проблемы:

— Нафакапиться по срокам на коротком отрезке сложнее. А в случае, если сроки поехали — мы узнаем об этом через 2 недели, а не через 3 месяца, и сможем своевременно отреагировать.

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

Я призываю продактов помогать командам декомпозировать User Story на более мелкие, даже если катить на пользователя еще рано.
Почитать больше можно в статье Кента Макдональда.

Презентация к посту выше — «Как и зачем декомпозировать User story — 21 шаблон».

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

Это перевод презентации из статьи Кента Макдональда. Перевод за авторством группы ребят, среди которых Сергей Кузин — Agile коуч всея Авито, и с его разрешения публикую эту презентацию.

Про баланс в работе продакта

Каждая компания по-своему понимает роль продакта, но от любого продакта постоянно все чего-то хотят 🙂

Бывает, что продакт-менеджер становится дискавери-менеджером. Всё время тратит на распределение работы по аналитике и исследованиям, выверяет метрики, формирует гипотезы.

При этом деливери расценивает как внутренний аутсорс:
— «сгружает» эпики размером в квартал без декомпозиции на User Story
— не ходит на планирования, PBR, дейлики
— не интересуется результатом на ревью спринта, не дает обратную связь
— не доносит команде ценность для бизнеса и эффект от фич

Так продакт теряет роль Product Owner.

Бывает и обратная ситуация: продакт руководит командой разработки вместо тимлида, при этом упуская метрики, аналитику и ux-исследования.

Специально привёл две крайности. Но на самом деле продакту очень легко что-то упустить в своей работе.

Ангелина Зинченко из Авито написала статью «Как продакту выстраивать коммуникацию со стейкхолдерами и командой»

В ней она приводит примеры ошибок и хороших практик для продактов в разных аспектах работы:
— с дискавери командой
— с деливери командой
— с маркетингом, отделом продаж
— с клиентской и технической поддержкой
— с руководителем, СРО, СЕО или инвестором

Советую к прочтению, своим продактам тоже скину. Они очень хорошие!
Но мне кажется, что в статье каждый может узнать себя в одном из пунктов 🙂

​​ProductCamp — в следующие выходные!

Когда я что-то рекламирую, стараюсь чтобы это было полезно и бесплатно. Тут два в одном!

По поводу ProductCamp я спросил мнения нашего продакт-кластер-лида:
— Они хорошие, я и выступал когда-то там и участвую во многих конфах. Нетворк прекрасно выстроен.

Потом я посмотрел темы докладов и мне откликнулись:

— 5 факапов, которые сделали меня директором по продукту (Ксюша Стрельникова, Райффайзенбанк, Директор по продукту) 

— Когнитивные ошибки в продакт менеджменте (Иван Меркурьев, Яндекс, Менеджер проектов) 

— 15 Soft Skills менеджера продукта и как их качать на самом деле (ex Head of product developmet MTS, exYandex, exTinkoff) (Сергей Паращенко, Product Vision, Директор по образовательным продуктам) 

— Выгореть, выжить, вернуться: от убивающей продуктивности к эффективной (Анна Динельт, Яндекс Афиша, Руководитель продукта) 

———

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

Чтобы присоединится, нужно заполнить форму на сайте ProductCamp. Там же можно зарегистрироваться на онлайн.

Когда: 19-21 апреля
Где: Парк-отель «Ареал» и онлайн на ProductLand

Реклама. ООО "Глобалкэмп". ИНН 7806594627. erid LjN8KKtRL

Топ постов в этом канале для 10.000 подписчиков! 🥳
Привет, десять тысяч подписчиков! Это отличный повод обновить интро, и добавить в него полезностей.

Канал — о продуктовой разработке изнутри, глазами инженера.

Меня зовут Никита Хромушкин, и я инжиниринг мемеджер в Авито.
В душе я все еще инженер, хотя в трудовой — Head of Development of AvitoID unit.
В 2023 переехал в Испанию и стал отцом.

@sharelocations — лайв-канал про всякое личное, он еще совсем малыш, но туда тоже можно подписаться :)

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

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

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

🎉 Давайте отметим 10к подписчиков топом полезных постов! 🎉

1️⃣ — О чем спросить будущего работодателя — чеклист, собрал 1к+ репостов и 15к просмотров. Чеклист мы делали вживую на круглом столе на Podlodka Teamlead Crew. Вложились Евгений Кателла, Евгений Антонов и Татьяна Аква, я был в роли ведущего.

2️⃣ — Digital Nomad в Испании — 266 репостов и 9.3к просмотров. Забавное из обсуждения поста в одном там чате: «История лютая, ппц. На большом сроке решиться на такую авантюру. Если б что не так, то сидели бы они в миграционной тюрьме с марроканцами». Это байопик нашего переезда в Испанию на машине, первый и единственный lifestyle-пост. Тем не менее, и он оказался полезным: в нем ссылки на базу знаний на Notion, которой я пользовался при подготовке документов.

3️⃣ — Как мы готовим задачи к спринту, поделились 86 раз и посмотрели 3,1к человек. Этот пост про то, что процесс подготовки задачи к разработке тоже можно структурировать и описать. В эту же тему будет ранний пост про Dual-track development. У канала тогда было 100 подписчиков, я работал в QIWI, но уже тырил лучшие практики из Авито 🙂

4️⃣ — Как и зачем декомпозировать User Story + 21 шаблон декомпозиции, вдвоем набрали 244 репоста и 4.2к просмотров. Эти посты про то, как декомпозировать недекомпозируемое. Могут помочь продактам/бизнес-аналитикам и командам делать более частые и маленькие инкременты и быстрее получать обратную связь.

5️⃣ — Как понять, в ту ли сторону ты развиваешься, чтобы получить повышение? + Windrose template для собственного развития — вдвоем набрали 218 репостов и 7,5к просмотров. Это про Авитошную матрицу компетенций. Если у вас в компании нет матрицы, а решения о промо принимаются на уровне команды, то можно позаимствовать матрицу Авито и использовать её внутри своей команды.

6️⃣ — Серия из 3 постов Как мы команду делили + Как мы провели Kick-off за 8 часов и какие вынесли уроки — вся серия набрала 305 репостов и 27,1к просмотров. Полезно, если у вас команда предельного размера (~9+ человек) и связанные с этим страдания — долгие стендапы, грумминги, общий расфокус, и невозможность уследить за всем что происходит.

7️⃣ — SMS Two factor auth — плохая практика и серия постов про альтернативы, заканчивающаяяся постом про Будущее аутентификации в вебе — вся серия набрала 206 репостов и 13.5к просмотров

===

В конце поделюсь ранним творчеством:
8️⃣ — StarMap — карта компетенций команды — если нужно собрать воедино картинку: кто что знает, чему готов научить и чему хочет учиться. Поможет обнаружить низкий бас-фактор или недостаточность экспертизы для каких-то фич.
9️⃣ — Чеклист Definition Of Done — Как всем одинаково понять, что задача сделана.
🔟 — Чеклист Definition Of Ready (for Sprint) — Как понять, что задача проработана.

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

​​Четырехдневка, доступная каждому
… за которую еще и доплатят 🙂

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

Итак, если:
1. Хотите попробовать четырехдневную рабочую неделю
2. При этом сохранить погружение в контекст, ходить на планирования по понедельникам и ретроспективы по пятницам
3. Работаете итерациями в 2+ недели
4. Готовы потратить несколько отпускных дней чтобы поднабраться сил

То представляю вам уникальный авторский концепт:
Отпуск с пятницы по понедельник в середине спринта
* имеются противопоказания, проконсультируйтесь с руководителем

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

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

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

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

Всем своим многоотпускникам советую, и вы попробуйте!

==============

P.S. Обращение к ребятам, кто копит, «инвестирует» свои отпускные дни.

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

Во-первых, за год инфляция съест этот прирост, а вам дадут еще одно повышение зарплаты.

Во-вторых, повышение зп чаще получают те, кто хорошо отдыхает и продуктивно работает.

Поэтому потратить отпускные дни = инвестировать в себя.
А копить отпуск = продавать свое здоровье по цене отпускного дня.

Сходите уже отдохнуть.

​​Что такое Data-driven принятие решений

Одним предложением — это процесс принятия продуктовых и бизнесовых решений, основанных на конкретных оценках и измерениях.

Разберем на примере Авито. На картинке — один из тысяч A/Б-тестов в нашей «АБшнице».

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

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

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

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

Основные плюсы data-driven культуры:
— Решения принимаются точнее, компания легче отказывается от бесполезных идей и поддерживает полезные
— Снижается зависимость от «экспертного» мнения, компания чуть лучше защищена от некомпетентных менеджеров
— Развивается культура «экологичного» челленджа, повышается прозрачность принимаемых решений

Однако, конечно, у такого подхода есть ряд минусов:
— Команды могут начать перестраховываться — появляется «аналитический паралич», из-за чего ухудшается ТТМ
— Некоторым менеджерам становится труднее принимать решения, когда результаты теста не однозначные

… и ограничений:
— Компании нужно развивать аналитические компетенции в большом объеме — это дорого
— Нужно строить инфраструкту данных и развивать data-инженерные компетенции — это дорого и сложно

Последнее здесь стоит особняком: без данных — нет аналитики и не будет никакой культуры. Именно с этого надо начать и в это нужно проинвестировать, если вы хотите достичь data-зрелости в принимаемых решениях.

Это был гостевой пост Алексея Малинского, руководителя категорийной аналитики в Авито Товарах.

Больше постов про аналитику — Avito Data Tech

Авторизация — больше чем логин/пароль

^^ К репосту выше ^^

Не так давно я оформил серию постов про альтернативы 2fa в презентацию и выступил первый раз за 2 года.

Спасибо ребятам из Mad Brains, что позвали.

И отдельное спасибо за то, что смонтировали видос.
А серия постов тут, начинается с «SMS — плохой способ 2fa».

Так может и выступать начну опять.

Процесс найма — несправедливый, как ни старайся

Читаю «Work Rules!» от бывшего главы HR Google.

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

• Отсев по количеству лет опыта — 3%
• Сбор фидбеков с прошлых мест — 7%
• Неструктурированные интервью — 14%
• Структурированные интервью — 26%
• Тест на общие когнитивные способности (внезапно) — 26%
• Практическое задание — 29%

Разные компании комбинируют эти методы, но ни один из них по отдельности не гарантирует более 30% успеха!

———

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

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

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

Этот пост — реклама Карьерного Цеха. Ребята предлагают бесплатную консультацию для тех, кто подумывает искать работу.

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

Записывайтесь на бесплатную консультацию и получите индивидуальный план поиска работы, который приведет вас к офферу.

Реклама. ИП Федоров Е.П.
ИНН 532008901966

​​Low-context vs High-context коммуникация

Читаю The Culture Map — книгу про культурные различия. Заходит настолько, что буду приносить сюда кое-какие концепты.

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

У нас принято «читать между строк». Аналогично в Испании, Турции и многих других странах.
В Японии и Китае это же называется «слушать воздух».

High-context пример: На дейли тимлид говорит «надо подумать, как оптимизировать запрос». В нашей культуре это может означать просьбу к конкретному разработчику заняться оптимизацией, но напрямую это не озвучено.

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

==========

Напротив, молодые «экспатские» страны, вроде Австралии, не имели возможности развить high-context культуру. Чтобы выходцы из разных стран могли сосуществовать, они стараются не закладывать доп смыслов в свои сообщения и выражаются прямо и детализированно.

В следующем посте расскажу про Low-context коммуникацию, почему она лучше подходит для рабочих отношений.

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

1️⃣ — Между двумя представителями разных Low-context стран, например Австралия и Канада
2️⃣ — Между Low-context из США и High-context из Китая
3️⃣ — Между High-context из России и High-context из Индии

Буду рад обсудить в комментах 🙂

Yet Another Level: TeamLead — Митап для тимлидов от Яндекса.
25 июля. Бесплатно.

Митап из серии мероприятий про жизнь в IT-индустрии. В этот раз о тимлидах, их софт скилах и карьерных треках.
Будут выступать уважаемые господа:

📌 Евгений Антонов, мой товарищ, технический менеджер в Yandex Infrastructure.
«Играющий тренер: выиграет или проиграет?» — Поговорим о том, как начинающие тимлиды 80% пишут код и 80% занимаются менеджментом.

📌 Александр Афенов, мой коллега, Technical Cluster Lead в Авито Доставке.
«Жока и Бока: две очень разные судьбы тимлидов». Ожидаю классный сторителлинг, где каждый сможет узнать себя.

📌 Руслан Остропольский, CPO в Test IT.
«Как завоевать доверие тимлиду» Разберёмся, что такое доверие, как оно формируется и как его не потерять. А ещё обсудим, есть ли разница между доверием и авторитетом.

Митап пройдёт 25 июля онлайн и офлайн в Москве — участие бесплатное, но нужно зарегистрироваться

Присоединяйтесь к чату сообщества в tg https://news.1rj.ru/str/Yet_Another_Level

​​Low-context коммуникация и обратная связь

Правильный ответ на вопрос из прошлого поста — 3️⃣

C большей вероятностью представители двух разных High-context культур могут неправильно считывать «между строк» сообщения друг друга. Потому что их культура формировалась независимо в разном историческом контексте. Даже внутри одной страны есть риск неправильного считывания «между строк». Сейчас в распределенных командах работают ребята из разных регионов, и у каждого свой high-context.

Поэтому простое правило — в рабочей коммуникации использовать Low-context.

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

Давать максимум контекста: над чем работаешь и детали для правильного понимания ситуации. Объяснять, почему задаешь тот или иной вопрос. Да, иногда придется повторяться. Но лучше повторить, чем быть неправильно понятым.

А еще — не закладывать намёков и смыслов «между строк» в своей коммуникации и не пытаться найти их в словах собеседника.

Но из любого правила есть исключения.

Самое важное исключение — обратная связь.

Удивительно, но многие Low-context страны имеют культуру смягчения корректирующей обратной связи. Например, в Америке, UK и Канаде принято давать фидбек в формате «сендвича»: «несколько положительных аспектов, затем мягко упомянуть о том, что можно улучшить, и снова похвалить».

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

Теперь я стараюсь использовать Low-context коммуникацию, сохраняя при этом прямой стиль обратной связи.

На картинке — позиционирование стран в координатах «Коммуникация / Обратная связь».
Мы с вами находимся в квадранте «High-context / Direct negative feedback». Из этого делаем вывод, что в общем случае мы можем общаться намёками и рассчитывать, что собеседник поймёт наш посыл «между строк». Но при этом если код — 💩, то так и будет сказано.

Намёк может быть понят неправильно, поэтому стоит помнить об этой склонности и возвращаться к Low-context.

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

И да, «хвали публично / ругай лично» 🙂

Исследование тимлидов

В 23 году прошел большой опрос тимлидов от DevCrowd. Поделюсь интересностями оттуда.

Этот пост — призыв пройти опрос текущего года. Это некоммерческая история, мне не платили за этот пост, и да, опрос я прошел.

Прохождение займёт у вас ~1-5 минут. В сентябре ребята подобьют результаты и выложат в виде красивой инфографики.

В прошлом опросе приняло участие 570 человек, из которых:
- 68% – тимлиды
- 22% – менеджеры менеджеров
- 9% – директора

📌 90% перешли в менеджмент в той же компании, где работали инженерами.

📌 Топ-3 обязанности руководителей любого уровня:
1️⃣ Собеседования,
2️⃣ Развитие людей в команде
3️⃣ Оценка их перфоманса.

📌 — 80% тимлидов считают себя сильнее большинства инженеров в своей команде.

📌— Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени.

📌 — Активно ищет работу только каждый десятый тимлид.

Подробнее, с инфографикой и даже видосом от Егора Толстого — Ссылка на результаты 2023.

———

P.S. там есть вопрос про медиа, которые вы читаете. Среди вариантов нет Product Developer, но есть поле «другое». Ну вы знаете, что туда написать 🙂

Пройти опрос.

Почему я продолжаю работать в Авито из Испании

Прошел год с написания поста Digital Nomad в Испании, а я всё еще работаю в Авито. Кстати, советую прочитать тот байопик нашего переезда :)

Раньше идея релокации для меня была сопряжена со сменой работы. До ковида и всеобщей удалёнки других вариантов и не было. Да и зарплата в рублях была маленькой для Европы. К тому же при релокации работодатель помогал с документами, билетами и арендой на первое время.

Но вот в прошлом году я релоцировался, сохранив работу. Почему?

0️⃣ Появилась такая возможность. Удалёнка стала нормой, а загнивающая Европа привлекает к себе молодых и талантливых с помощью новых типов внж.

1️⃣ Уровень зарплат выровнялся. Серьезно, посмотрите levels.fyi. Возьмем за пример немецкий Тинькофф — необанк N26. Медианная gross зп сеньора в Германии — €87K/год. Это ~€4.5k в месяц на руки после налогов. Сеньор-помидоры в РФ просят столько же. C тимлидскими позициями ситуация даже хуже.

2️⃣ Мне интересно в Авито. Потихоньку приближаюсь к ощущению, что работаю здесь уже достаточное время, чтобы что-то понимать и наносить пользу. И очень здорово, что есть островок стабильности в виде работы, который помогает заземлиться во время переезда и рождения ребенка.

3️⃣ В России рынок кандидата. Компании конкурируют за толковых ребят, процесс найма относительно лайтовый (да, даже если это несколько секций включая алгосы). В Европе — рынок работодателя. Кандидатов много больше, чем вакансий. Тестовое задание на день-два работы — норма. Трудоустроиться в европейскую компанию — не так-то просто.

4️⃣ Сейчас мой тип ВНЖ не привязан к работодателю. Если переходить работать на местную компанию — нужно менять тип ВНЖ и стану привязан. В случае увольнения будет всего месяц на поиски.

5️⃣ Работать в русскоязычной компании — понятнее. И дело даже не в твоём плохом английском, а в менталитете и плохом английском всей команды. Серьёзно, я знаю истории, когда ребята на созвоне не могли договориться, потому что не понимали речь друг друга, и уходили в текстовое обсуждение.

Чтоб жизнь малиной не казалась — расскажу про риски и минусы:

0️⃣ Собирать доки и подаваться на ВНЖ нужно самому, есть риск отказа. Мы приехали на машине с беременной женой и собакой по шенгену. Виза закончилась во время рассмотрения ВНЖ. Отказ был бы очень некстати в такой ситуации.
1️⃣ Курсы валют. Если рубль просядет к евро — мой доход снизится. Честно говоря, укрепления рубля я не жду. А вот зарплаты в рублях растут. Главное — иметь подушку безопасности и план.
2️⃣ Высокая цена «подписки на страну». Сюда я включаю прогрессивную ставку налога, цены на аренду жилья и на услуги. Стоит ли оно того — каждый решает сам.
3️⃣ Повидаться с роднёй или приехать на общекомандный сбор стало сильно дороже и сложнее, нужно закладывать два дня на дорогу.

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

Наконец-то можно планировать жизнь на несколько лет вперед.

Technical Design Review (TDR)

Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.

Но у кодревью есть один большой минус: код уже написан. Когда появляются критичные комменты по архитектуре и нужно всё переписывать — очень демотивирует и может возникнуть конфликт.

Эту проблему решает TDR — Technical Design Review.
Это как кодревью, но про архитектуру и заранее: инженер описывает в Confluence предлагаемое решение и собирает обратную связь с команды и внешних ребят.

Как и в кодревью, есть плюсы, минусы и подводные камни.

Плюсы:

1️⃣ Более проработанное решение будет быстрее разработано и с меньшими проблемами.
Серьёзная проработка архитектуры до старта разработки даёт возможность полноценно попроектировать и учесть обратную связь.

2️⃣ Обмен знаниями и гарантия документирования.
Есть возможность научиться проектировать архитектуру у более опытных ребят. Проектировать может один, а разрабатывать — другой. Полноценная дока появляется еще до старта разработки.

3️⃣ Осведомленность команды и соседей.
При разработке будет меньше вопросов. Не будет проблем с интеграцией и вопросов «а что это вы тут делаете?». Не возникнет блокирующих рисков.

Минусы:

1️⃣ Увеличивает Time2market
Это компенсируется временем, сэкономленным на поддержке и рефакторингах. TDR = контроль за техдолгом.

Но есть подводные камни. TDR может «застрять на ревью» как задача на кодревью.
Причины могут быть разные, но результат — задержка реализации.

Способы решения этой проблемы — аналогичные для долгих кодревью:
— Договориться о сроках с ревьюерами.
— Определить в команде приоритет. В идеале, ревью кода и ревью TDR — приоритетнее, чем написание нового кода по своим задачам.
«Сел утром за работу — посмотри пулл реквесты и TDR».
— Заранее предупреждать о предстоящем ревью в следующем спринте. Просить запланировать ревью.
— Иметь четкую систему оценок и критичности комментов: что обязательно к исправлению, а что опционально.
— Иметь гайдлайны о том, что должно быть в TDR: компонентные и sequence-диаграммы, оценки объема данных и нагрузки, оценки рисков, план миграции, план отката. Это снимет часть вопросов, возникающих на большинстве TDR.


2️⃣ Иногда TDR делают там, где он не нужен, замедляя разработку. А иногда не делают там, где нужен, порождают риски.
Проблема в отсутствии договоренностей, какие изменения должны проходить через TDR.

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


Итог

Мы провели около 10 TDR за полгода.

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

Но в целом польза от TDR точно перевешивает.
Советую ли я читателю TDR?
— Однозначно, стоит попробовать!

Если у вас есть похожий опыт — делитесь в комментариях.

ProductSense

Прежде чем писать этот пост, я спросил у нашего продакта: Илья, это ценная конфа?

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

Поэтому я согласился порекламировать в обмен на билет.
И да, Илья идёт на неё, а я буду смотреть в онлайне 🙂

5-6 сентября, оффлайн в Москве или онлайн

Конфа для продактов и не только: есть доклады и про управление командой и проектом, а еще про взаимодействие Discovery <-> Delivery.

Спикеры и темы в расписании

Я бы сходил послушать Александра Вазюкова из Т-Банка с докладом “Приключение на 20 минут, или прогнозирование сроков проекта” (спойлер: прогнозирование не ради самого прогноза, а ради рефлексии)

А еще Александру Клименко из Soft Skills Lab — с докладом “Продакту не нужны софт скиллы?”. Кстати, еще у них будет воркшоп про переговоры.

В общем, советую посмотреть темы и прикупить билетик, хотя бы на онлайн.

17 августа подняли цены на билеты, но у меня есть промокод для билетов Digital Pass и Professional, который возвращает цену к прошлой. Промокод действует три дня, пишите мне в личку @engineering_memeger.

Вот ссылка на лендос конференции