Процессы как отмазка
Disclaimer: в этом посте общественной пользы нет.
Я люблю структурировать процессы. Испытываю эстетическое удовольствие, когда всё разложено по полочкам, всё идёт по плану.
Я считаю, что любое повторяющееся действие должно быть структурировано, описано и закреплено процессом. Особенно, если это действие делают разные люди, чередуясь. Без описания это неформальная договоренность, возможность нафакапить и повод для будущего конфликта.
НО. Меня люто бесят люди, которые облажались и не признают свой косяк, не делают выводов для себя и оправдываются отсутствием / недостаточной структурированностью процесса.
Вы поймите правильно, я и процессы люблю и людей. И лажаю сам частенько. Очень радуюсь, когда кто-то как следует прикладывает прод, так чтобы разгребать было интересно, и в будущем мы никогда больше не приложили бы прод подобным образом.
НО. Очень уж дофига человеколюбия в последнее время в этом нашем айти. Когда кто-то облажался, мы ищем ему оправдание в хреновости процесса и ищем системное решение в виде доработки процесса. На ретроспективах стараемся не шеймить человека, а предлагать решения в виде регламента, чеклиста, бота с напоминаниями, второй пары глаз, еще чего-то. Это поможет, если человек понимает, что облажался.
Но бывает, что один и тот же человек находит изъяны всех ваших процессов. Находит способ облажаться в любом действии. В котором не лажают другие. Процессы всегда не идеальны. Структурированность процессов — баланс между бюрократическим оверхедом и стремлением снизить человеческий фактор. И ради одного персонажа вы из раза в раз добавляете оверхед в процессы. А он из раза в раз находит изъяны этого процесса.
Что будете делать с таким человеком? Ведь он старается, работает, пользу приносит. Или вред?
Disclaimer: в этом посте общественной пользы нет.
Я люблю структурировать процессы. Испытываю эстетическое удовольствие, когда всё разложено по полочкам, всё идёт по плану.
Я считаю, что любое повторяющееся действие должно быть структурировано, описано и закреплено процессом. Особенно, если это действие делают разные люди, чередуясь. Без описания это неформальная договоренность, возможность нафакапить и повод для будущего конфликта.
НО. Меня люто бесят люди, которые облажались и не признают свой косяк, не делают выводов для себя и оправдываются отсутствием / недостаточной структурированностью процесса.
Вы поймите правильно, я и процессы люблю и людей. И лажаю сам частенько. Очень радуюсь, когда кто-то как следует прикладывает прод, так чтобы разгребать было интересно, и в будущем мы никогда больше не приложили бы прод подобным образом.
НО. Очень уж дофига человеколюбия в последнее время в этом нашем айти. Когда кто-то облажался, мы ищем ему оправдание в хреновости процесса и ищем системное решение в виде доработки процесса. На ретроспективах стараемся не шеймить человека, а предлагать решения в виде регламента, чеклиста, бота с напоминаниями, второй пары глаз, еще чего-то. Это поможет, если человек понимает, что облажался.
Но бывает, что один и тот же человек находит изъяны всех ваших процессов. Находит способ облажаться в любом действии. В котором не лажают другие. Процессы всегда не идеальны. Структурированность процессов — баланс между бюрократическим оверхедом и стремлением снизить человеческий фактор. И ради одного персонажа вы из раза в раз добавляете оверхед в процессы. А он из раза в раз находит изъяны этого процесса.
Что будете делать с таким человеком? Ведь он старается, работает, пользу приносит. Или вред?
👍15🤣8🔥4🌚3❤2🐳1
Podlodka Teamlead crew #10: All Stars
Привет! Я делаю тимлидскую подлодку в составе программного комитета, вот уже третий раз.
В этот раз мы в ПК решили собрать топовых спикеров и дать им рассказать о том, что зудит сильнее всего. Наша суперсила в том, что в подлодошном комьюнити есть реально топовые спикеры.
Состав подобрали звездный, а сезон назвали All Stars. Евгений Антонов, Женя Кот, Глеб Михеев, Никита Дубко, Стас Цыганов, Саша Прокшина, Виталий Шароватов, Настя Абрашитова, Толя Панов.
10 апреля. 10й сезон. 10+ звезд.
А еще на ютубе будет открытая сессия 6го апреля в 19:00 Мск. Это будет круглый стол на холиварную тему «Зачем нужны тимлиды».
Я готовлю с ребятами и буду вести сессии:
1. Евгений Антонов — Демотивация. Страх и ненависть на работе
Евгений представит модель демотивации по Антонову, в противоположность модели мотивации Герцберга. И приведет примеры, в которых каждый сможет узнать себя. Я узнал и пообещал себе что больше так не буду делать со своими инженерами 🙂
2. Стас Цыганов — Продуктовый подход для тимлидов
Стас расскажет о том что каждый тимлид — продакт своей команды и технологий. Как отличить предлагаемые инженерами решения от их реальных болей. Как придумывать гипотезы для решения болей. Как понять что боль решена. Очень в тему этого канала, не находите?
Буду рад увидеть вас на неделе с 10 по 14 апреля. Онлайн, утром в 10 и вечером в 19 Мск.
Как всегда, для своих скидон по промику product_developer_tl10
https://podlodka.io/tlcrew
Привет! Я делаю тимлидскую подлодку в составе программного комитета, вот уже третий раз.
В этот раз мы в ПК решили собрать топовых спикеров и дать им рассказать о том, что зудит сильнее всего. Наша суперсила в том, что в подлодошном комьюнити есть реально топовые спикеры.
Состав подобрали звездный, а сезон назвали All Stars. Евгений Антонов, Женя Кот, Глеб Михеев, Никита Дубко, Стас Цыганов, Саша Прокшина, Виталий Шароватов, Настя Абрашитова, Толя Панов.
10 апреля. 10й сезон. 10+ звезд.
А еще на ютубе будет открытая сессия 6го апреля в 19:00 Мск. Это будет круглый стол на холиварную тему «Зачем нужны тимлиды».
Я готовлю с ребятами и буду вести сессии:
1. Евгений Антонов — Демотивация. Страх и ненависть на работе
Евгений представит модель демотивации по Антонову, в противоположность модели мотивации Герцберга. И приведет примеры, в которых каждый сможет узнать себя. Я узнал и пообещал себе что больше так не буду делать со своими инженерами 🙂
2. Стас Цыганов — Продуктовый подход для тимлидов
Стас расскажет о том что каждый тимлид — продакт своей команды и технологий. Как отличить предлагаемые инженерами решения от их реальных болей. Как придумывать гипотезы для решения болей. Как понять что боль решена. Очень в тему этого канала, не находите?
Буду рад увидеть вас на неделе с 10 по 14 апреля. Онлайн, утром в 10 и вечером в 19 Мск.
Как всегда, для своих скидон по промику product_developer_tl10
https://podlodka.io/tlcrew
podlodka.io
Онлайн-конференция Podlodka Teamlead Crew, сезон #16
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам тимлидства, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
🔥11👍3❤1
Зачем нужны тимлиды?
В четверг будет подлодошный круглый стол на эту тему. Предлагаю чуть порассуждать заранее, а потом свериться с уважаемыми господами.
Один из моих любимых вопросов на собеседовании — зачем тебе тимлид?
Ответ по сути говорит о том, что инженер ждет от меня. Интервью ведь и нужно, чтобы прояснить взаимные ожидания. Прояснить всё, что тебе нужно — ответственность каждого участника интервью. Но не все кандидаты могут сформулировать правильные вопросы. Тем не менее, неловко будет нанять человека, которому я не смогу дать то, что он хочет. Поэтому я спрашиваю и уточняю.
Самые частые ответы примерно такие:
— Не знаю, не задумывался — не ответ, надо копать дальше другими вопросами.
— Задачи заводить и распределять. Здесь еще важно узнать, какой гранулярности задачи хочет получать человек. Честно говоря, моя идеальная команда сама заводит таски в джире и сама их распределяет 🙂 Мне важно, чтобы крупные стримы размером с квартал оказались под крылом нужных людей.
— Процессы налаживать. Если за этими словами стоит какой-то реальный образ, то вот это может быть ценный кандидат, повидавший некоторое дерьмо. Надо уточнить, какого рода процессы и как именно налаживать. Главное, опять же, чтобы кандидат не ожидал в лице тимлида видеть скрам-мастера.
— Конфликты решать. Вот тут может быть либо конфликтный / притягивающий конфликты кандидат, либо опять же повидавший некоторое дерьмо. Лучше бы детальнее копнуть. В моей идеальной команде конфликты — конструктивные, возникают регулярно, приводят к улучшениям и проходят без участия тимлида. Но это мечты 🙂
Потом я доуточняю: «Это всё про команду. А вот тебе лично — зачем тимлид?»
В ответ обычно:
— Развитие, карьерный рост. Очевидно, но каким образом? А как кандидат сам развивается?
— Обратная связь. Вот тут вопросов нет. На удивление редко это отвечают, кстати. Можно доуточнить кейс, где кандидату давали корректирующую обратную связь , и узнать, как он её применял.
— Мне не нужен тимлид. Не путать с «не знаю». Это мой любимый, идеальный ответ. Человек, который так ответил, сейчас показывает всей команде ролевую модель. И собрал 70% оценок «выше ожиданий» от сокомандников на ревью.
Сам находит себе инженерно сложные, развивающие челленджи. Может работать в неидеальных процессах. Если процессы совсем плохие — сам начнет их оптимизировать и команде продаст. Конфликты поворачивает в конструктивное русло.
Разве что обратная связь иногда нужна, чтобы свериться, что в ту сторону гребет.
Это не исчерпывающий список, но из ответов и моих комментариев можно проследить тренд: тимлиды не нужны.
Вернее, так: хороший тимлид стремится сделать так, чтобы он был не нужен в команде. Чтобы если он уходит в отпуск, ничего не менялось.
Если перформанс команды просядет, значит, что-то тащил на себе.
Если перформанс улучшится, значит мешал.
В общем, мой ответ такой: Тимлид нужен, чтобы привести команду в состояние, когда тимлид не нужен.
А вы как считаете?
Что ответили бы сами, или что вам отвечают кандидаты на вопрос «Зачем тебе тимлид?»
В четверг будет подлодошный круглый стол на эту тему. Предлагаю чуть порассуждать заранее, а потом свериться с уважаемыми господами.
Один из моих любимых вопросов на собеседовании — зачем тебе тимлид?
Ответ по сути говорит о том, что инженер ждет от меня. Интервью ведь и нужно, чтобы прояснить взаимные ожидания. Прояснить всё, что тебе нужно — ответственность каждого участника интервью. Но не все кандидаты могут сформулировать правильные вопросы. Тем не менее, неловко будет нанять человека, которому я не смогу дать то, что он хочет. Поэтому я спрашиваю и уточняю.
Самые частые ответы примерно такие:
— Не знаю, не задумывался — не ответ, надо копать дальше другими вопросами.
— Задачи заводить и распределять. Здесь еще важно узнать, какой гранулярности задачи хочет получать человек. Честно говоря, моя идеальная команда сама заводит таски в джире и сама их распределяет 🙂 Мне важно, чтобы крупные стримы размером с квартал оказались под крылом нужных людей.
— Процессы налаживать. Если за этими словами стоит какой-то реальный образ, то вот это может быть ценный кандидат, повидавший некоторое дерьмо. Надо уточнить, какого рода процессы и как именно налаживать. Главное, опять же, чтобы кандидат не ожидал в лице тимлида видеть скрам-мастера.
— Конфликты решать. Вот тут может быть либо конфликтный / притягивающий конфликты кандидат, либо опять же повидавший некоторое дерьмо. Лучше бы детальнее копнуть. В моей идеальной команде конфликты — конструктивные, возникают регулярно, приводят к улучшениям и проходят без участия тимлида. Но это мечты 🙂
Потом я доуточняю: «Это всё про команду. А вот тебе лично — зачем тимлид?»
В ответ обычно:
— Развитие, карьерный рост. Очевидно, но каким образом? А как кандидат сам развивается?
— Обратная связь. Вот тут вопросов нет. На удивление редко это отвечают, кстати. Можно доуточнить кейс, где кандидату давали корректирующую обратную связь , и узнать, как он её применял.
— Мне не нужен тимлид. Не путать с «не знаю». Это мой любимый, идеальный ответ. Человек, который так ответил, сейчас показывает всей команде ролевую модель. И собрал 70% оценок «выше ожиданий» от сокомандников на ревью.
Сам находит себе инженерно сложные, развивающие челленджи. Может работать в неидеальных процессах. Если процессы совсем плохие — сам начнет их оптимизировать и команде продаст. Конфликты поворачивает в конструктивное русло.
Разве что обратная связь иногда нужна, чтобы свериться, что в ту сторону гребет.
Это не исчерпывающий список, но из ответов и моих комментариев можно проследить тренд: тимлиды не нужны.
Вернее, так: хороший тимлид стремится сделать так, чтобы он был не нужен в команде. Чтобы если он уходит в отпуск, ничего не менялось.
Если перформанс команды просядет, значит, что-то тащил на себе.
Если перформанс улучшится, значит мешал.
В общем, мой ответ такой: Тимлид нужен, чтобы привести команду в состояние, когда тимлид не нужен.
А вы как считаете?
Что ответили бы сами, или что вам отвечают кандидаты на вопрос «Зачем тебе тимлид?»
👍24🔥12❤2🌚1
Пост-знакомство плюс бонус-контент
Привет. Пару лет назад я написал пост про этот канал и повесил его в закреп. Сегодня подписалось как никогда много людей, а интро чутка устарело, поэтому пора обновить.
Итак, Канал — о продуктовой разработке изнутри, глазами инженера.
В душе я все еще инженер, хотя в трудовой — инжиниринг мемеджер.
Меня зовут Никита Хромушкин, и я тимлид тимлидов в Авито.
Пишу про образ мышления, роли, процессы, события и артефакты продуктовой разработки.
Иногда про участников процесса. Иногда про найм с обеих сторон.
Пост обычно рожаю часов за 16, с вычиткой, обратной связью от коллег и редактурой от жены.
Изначально завел канал, чтобы формулировать свои идеи и доносить их в свою команду. С тех пор аудитория немного расширилась, но основная концепция осталась.
Канал призван приносить пользу.
Основная метрика, в которую целюсь — количество репостов.
Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими. Например, ровно год назад я написал пост про ИПР, который репостнули 77 раз. Считаю, полезно получилось.
Изюминкой канала считаю артефакты, которыми охотно делюсь: DoR, DoD, Windrose для плана развития, всякие рисуночки-графички, схемки. Чуть позже напилю навигатор по постам с артефактами.
Вкратце, в общем, познакомились. Добро пожаловать, или снова здравствуйте.
=========================
Бонус-контент для старичков канала
Недавно меня позвали в масонскую ложу авторов каналов про продуктовую разработку. В чатике топовые ребята, эксперты индустрии, кладезь знаний и все с каналами.
А на днях телега выпустила новую фичу — можно делиться целой папкой с каналами.
Собсно, решили затестить. Для новоприбывших это уже не новость, а вот для старичков канала может быть полезно.
Вот тут собраны топовые каналы топовых продактов и не только:
https://news.1rj.ru/str/addlist/YvmnHCHUp700Nzky
Если не работает — повод обновить телегу.
После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.
Привет. Пару лет назад я написал пост про этот канал и повесил его в закреп. Сегодня подписалось как никогда много людей, а интро чутка устарело, поэтому пора обновить.
Итак, Канал — о продуктовой разработке изнутри, глазами инженера.
В душе я все еще инженер, хотя в трудовой — инжиниринг мемеджер.
Меня зовут Никита Хромушкин, и я тимлид тимлидов в Авито.
Пишу про образ мышления, роли, процессы, события и артефакты продуктовой разработки.
Иногда про участников процесса. Иногда про найм с обеих сторон.
Пост обычно рожаю часов за 16, с вычиткой, обратной связью от коллег и редактурой от жены.
Изначально завел канал, чтобы формулировать свои идеи и доносить их в свою команду. С тех пор аудитория немного расширилась, но основная концепция осталась.
Канал призван приносить пользу.
Основная метрика, в которую целюсь — количество репостов.
Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими. Например, ровно год назад я написал пост про ИПР, который репостнули 77 раз. Считаю, полезно получилось.
Изюминкой канала считаю артефакты, которыми охотно делюсь: DoR, DoD, Windrose для плана развития, всякие рисуночки-графички, схемки. Чуть позже напилю навигатор по постам с артефактами.
Вкратце, в общем, познакомились. Добро пожаловать, или снова здравствуйте.
=========================
Бонус-контент для старичков канала
Недавно меня позвали в масонскую ложу авторов каналов про продуктовую разработку. В чатике топовые ребята, эксперты индустрии, кладезь знаний и все с каналами.
А на днях телега выпустила новую фичу — можно делиться целой папкой с каналами.
Собсно, решили затестить. Для новоприбывших это уже не новость, а вот для старичков канала может быть полезно.
Вот тут собраны топовые каналы топовых продактов и не только:
https://news.1rj.ru/str/addlist/YvmnHCHUp700Nzky
Если не работает — повод обновить телегу.
После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.
❤18🔥7👍4❤🔥2
Product Developer pinned «Пост-знакомство плюс бонус-контент Привет. Пару лет назад я написал пост про этот канал и повесил его в закреп. Сегодня подписалось как никогда много людей, а интро чутка устарело, поэтому пора обновить. Итак, Канал — о продуктовой разработке изнутри, глазами…»
О чем спросить работодателя — чеклист
Новый сотрудник — всегда двусторонняя инвестиция:
— компания инвестирует деньги в собеседования, оформление, технику, зарплату сотрудника, его руководителя и бадди
— руководитель и коллеги вкладывают в новичка свое время и ресурс
— новичок инвестирует свое время и ресурс в прохождение интервью, увольняется из текущей компании, погружается в предметную область, технику и процессы новой компании.
Короче, новый сотрудник = инвестиция дофига денег, времени и сил с обеих сторон. Поэтому для меня важно, чтобы люди задерживались с нами на несколько лет.
Если сотрудник уходит через 3 месяца-полгода-год, то, скорее всего, инвестиция не окупается. Часть таких увольнений происходит из-за того, что в процессе найма кандидат не убедился в том, что ему подходит компания, позиция, продукт.
Компании выстраивают мега-процессы найма, чтобы убедиться, что кандидат точно-точно подходит. На вопросы кандидата обычно закладывают 15 минут.
Мне кажется, что пропорция «час на вопросы кандидату» : «15 минут на вопросы кандидата» не справедливая. Поэтому привет и спасибо ребятам из Авито, которых я в сумме мучил около 4-5 часов прежде чем принять оффер.
О чем спрашивать — тема индивидуальная. Для кого-то важен продукт, для кого-то — процессы. Кто-то повидал некоторое дерьмо и ему важно убедиться, что такого не будет на новом месте.
На позапрошлом сезоне Podlodka Teamlead Crew мы делали брейншторм «О чем спросить работодателя»
На выходе получились два артефакта:
1⃣ Mindmap вопросов в Miro
С разбиением по этапам и возможным развилкам:
Предварительный поиск инфы, чтение вакансии, HR-скрининг, тех. интервью, встреча с руководителем.
2⃣ Чеклист вопросов в гуглодоке
С разбиением по темам: компания, проект, подходы, метрики, задачи, полномочия, руководство, команда, техника, условия.
Ну и само собой, есть запись сессии. Как член ПК, я не могу публиковать ссылку на видос, потому что он в закрытом плейлисте. Но участники сессии могут. Вот, Женя Антонов у себя в канале постил: https://news.1rj.ru/str/general_it_talks/320
Новый сотрудник — всегда двусторонняя инвестиция:
— компания инвестирует деньги в собеседования, оформление, технику, зарплату сотрудника, его руководителя и бадди
— руководитель и коллеги вкладывают в новичка свое время и ресурс
— новичок инвестирует свое время и ресурс в прохождение интервью, увольняется из текущей компании, погружается в предметную область, технику и процессы новой компании.
Короче, новый сотрудник = инвестиция дофига денег, времени и сил с обеих сторон. Поэтому для меня важно, чтобы люди задерживались с нами на несколько лет.
Если сотрудник уходит через 3 месяца-полгода-год, то, скорее всего, инвестиция не окупается. Часть таких увольнений происходит из-за того, что в процессе найма кандидат не убедился в том, что ему подходит компания, позиция, продукт.
Компании выстраивают мега-процессы найма, чтобы убедиться, что кандидат точно-точно подходит. На вопросы кандидата обычно закладывают 15 минут.
Мне кажется, что пропорция «час на вопросы кандидату» : «15 минут на вопросы кандидата» не справедливая. Поэтому привет и спасибо ребятам из Авито, которых я в сумме мучил около 4-5 часов прежде чем принять оффер.
О чем спрашивать — тема индивидуальная. Для кого-то важен продукт, для кого-то — процессы. Кто-то повидал некоторое дерьмо и ему важно убедиться, что такого не будет на новом месте.
На позапрошлом сезоне Podlodka Teamlead Crew мы делали брейншторм «О чем спросить работодателя»
На выходе получились два артефакта:
1⃣ Mindmap вопросов в Miro
С разбиением по этапам и возможным развилкам:
Предварительный поиск инфы, чтение вакансии, HR-скрининг, тех. интервью, встреча с руководителем.
2⃣ Чеклист вопросов в гуглодоке
С разбиением по темам: компания, проект, подходы, метрики, задачи, полномочия, руководство, команда, техника, условия.
Ну и само собой, есть запись сессии. Как член ПК, я не могу публиковать ссылку на видос, потому что он в закрытом плейлисте. Но участники сессии могут. Вот, Женя Антонов у себя в канале постил: https://news.1rj.ru/str/general_it_talks/320
🔥78❤21👍17
Папка тимлидов
Недавно я написал пост-знакомство про этот канал. Сказал, что цель канала — приносить пользу, а основная метрика — количество репостов. Всего лишь неделю назад я считал достижением и хвастался постом на 77 репостов.
Прошлый пост «О чем спросить работодателя» собрал 245 репостов оО.
Тут нужно сделать ремарку, что артефакты в этом посте — плод коллаборации четырех человек на Podlodka Teamlead Crew.
А я всего лишь вел сессию, шарил экран, записывал со слов ребят и фасилитировал.
К чему это я. Подписывайтесь на папку с тимлидскими каналами. Там такого добра навалом.
14 каналов, почти на все из них я уже был подписан, что-то даже репостил, поэтому могу смело рекомендовать.
https://news.1rj.ru/str/addlist/mDWR2gD6UEhlOWRi
P.S. Этот пост я тоже считаю полезным. Несмотря на то что папки с каналами уже задолбали, кто-то найдет для себя пользу в конкретно этой папке 🙂
Недавно я написал пост-знакомство про этот канал. Сказал, что цель канала — приносить пользу, а основная метрика — количество репостов. Всего лишь неделю назад я считал достижением и хвастался постом на 77 репостов.
Прошлый пост «О чем спросить работодателя» собрал 245 репостов оО.
Тут нужно сделать ремарку, что артефакты в этом посте — плод коллаборации четырех человек на Podlodka Teamlead Crew.
А я всего лишь вел сессию, шарил экран, записывал со слов ребят и фасилитировал.
К чему это я. Подписывайтесь на папку с тимлидскими каналами. Там такого добра навалом.
14 каналов, почти на все из них я уже был подписан, что-то даже репостил, поэтому могу смело рекомендовать.
https://news.1rj.ru/str/addlist/mDWR2gD6UEhlOWRi
P.S. Этот пост я тоже считаю полезным. Несмотря на то что папки с каналами уже задолбали, кто-то найдет для себя пользу в конкретно этой папке 🙂
Telegram
Product Developer
Пост-знакомство плюс бонус-контент
Привет. Пару лет назад я написал пост про этот канал и повесил его в закреп. Сегодня подписалось как никогда много людей, а интро чутка устарело, поэтому пора обновить.
Итак, Канал — о продуктовой разработке изнутри, глазами…
Привет. Пару лет назад я написал пост про этот канал и повесил его в закреп. Сегодня подписалось как никогда много людей, а интро чутка устарело, поэтому пора обновить.
Итак, Канал — о продуктовой разработке изнутри, глазами…
❤18💯4🤩1🐳1
Управление рисками
Все слышали, что бас-фактор=1 — это плохо. Это очевидный риск, на который все рекомендуют обращать внимание и устранять: писать документацию, распространять экспертизу внутри команды и растить замену единственному эксперту.
А какие еще есть очевидные риски? А какие неочевидные? Редко встречал системное управление рисками.
По сути всё, про что пишу — простые штуки из разряда «подумайте заранее, запишите и обращайте внимание в будущем. Вот пример».
Очень простые истины, тем не менее до которых надо дойти своим умом. Но вот риск-менеджмент всегда звучал для меня как какой-то булшит. А оказывается, это простая штука про заранее предположить, где и что у вас отвалится, подумать как минимизировать вероятность что отвалится, и что делать если таки отвалится.
Можно делать в формате брейншторма или футуроспективы всей командой.
Можно делать индивидуально.
Можно доверить инженерам проработку рисков по их части, в том числе по QA.
Во что это воплощается — можно посмотреть на примере карты рисков, которую составил наш QA-инженер, который недавно получил промо в сеньора (кусочек на картинке, полная версия — в публичной гуглотаблице)
Все слышали, что бас-фактор=1 — это плохо. Это очевидный риск, на который все рекомендуют обращать внимание и устранять: писать документацию, распространять экспертизу внутри команды и растить замену единственному эксперту.
А какие еще есть очевидные риски? А какие неочевидные? Редко встречал системное управление рисками.
По сути всё, про что пишу — простые штуки из разряда «подумайте заранее, запишите и обращайте внимание в будущем. Вот пример».
Очень простые истины, тем не менее до которых надо дойти своим умом. Но вот риск-менеджмент всегда звучал для меня как какой-то булшит. А оказывается, это простая штука про заранее предположить, где и что у вас отвалится, подумать как минимизировать вероятность что отвалится, и что делать если таки отвалится.
Можно делать в формате брейншторма или футуроспективы всей командой.
Можно делать индивидуально.
Можно доверить инженерам проработку рисков по их части, в том числе по QA.
Во что это воплощается — можно посмотреть на примере карты рисков, которую составил наш QA-инженер, который недавно получил промо в сеньора (кусочек на картинке, полная версия — в публичной гуглотаблице)
👍31❤5🔥5🤩1
Digital Nomad в Испании
Мы получили одобрение внж Испании на 3 года! Теперь я официально Teletrabajador de caracter internacional.
Disclaimer: этот канал не превращается в тревел-блог. Но это очень важный этап, которым хочу поделиться, и который возможно кого-то вдохновит на релокацию.
Чтобы пост принёс пользу, приложу ссылки на ресурсы, с помощью которых я готовился к этому проекту:
💡База знаний на Notion, в которой всё-всё-всё про документы и процесс
📌@digitalnomadspain — Канал, где публикуют кейсы одобрений и самую актуальную инфу по получению документов. Вот ссылка на мой пост там.
📌 @chatfornomads — чат при том канале, можно поиском найти ответ на вообще любой вопрос.
============================
Итак, дано:
1. В Тбилиси классно, но хотим двигаться дальше
2. В идеале — в страну, где ребенок сможет претендовать на гражданство
3. Получить оффер и быть релоцированным Европейской компанией — простой путь. Но уходить из Авито не хочу.
4. Аргентина — не вариант, часовой пояс не даст работать
И тут как раз Испания с этого года запускает выдачу резиденции для цифровых кочевников.
15 мая мы с супругой и собакой выехали из Тбилиси в Москву, чтобы собрать все документы и 3 июня стартовать в обратную сторону.
Предстояло проехать 7500км через Россию, Грузию, Турцию, Грецию, на пароме в Италию, затем Франция и наконец Испания.
За время пути я взял всего 4 дня отпуска, всё остальное время работал. По дороге были моменты грустные и веселые. За поездку мы жили в 24 разных апартах. Мы купались в трёх морях. Жрали осьминогов на гриле. Ночевали под горой Олимп. Ночевали с машиной на пароме. Гуляли по Риму. Были в Ватикане и Монако. Держали пизанскую башню. Ночью нам разбили окна в машине, чтобы вытащить багаж. Достали один чемодан, где был собачий корм, поводок и барахло. А второй чемодан с ценной электроникой и документами не пролез в разбитое окно, и они его оставили. Вот оно, везение 🙂
4 июля мы подали документы на рассмотрение, а 11 июля у нас истёк шенген. Пока ждали решение по внж, мы всё еще легально находились на территории Испании. Но в случае отказа — «первым прямым рейсом домой». А мы на машине, с собакой, супруга беременная так что уже на самолет не посадят, да и рейсов прямых нет 🙂 Короче, отказ не вариант.
И вот, на днях пришло одобрение. Сейчас мы обосновались в Валенсии. Сняли квартиру на долгосрок, прописались, сдали отпечатки пальцев, ждём карточки резидента.
Это был большой проект. И он успешно запущен.
В процессе еще один большой проект, ради которого затевалась релокация — примерно в октябре я стану батей
Мы получили одобрение внж Испании на 3 года! Теперь я официально Teletrabajador de caracter internacional.
Disclaimer: этот канал не превращается в тревел-блог. Но это очень важный этап, которым хочу поделиться, и который возможно кого-то вдохновит на релокацию.
Чтобы пост принёс пользу, приложу ссылки на ресурсы, с помощью которых я готовился к этому проекту:
💡База знаний на Notion, в которой всё-всё-всё про документы и процесс
📌@digitalnomadspain — Канал, где публикуют кейсы одобрений и самую актуальную инфу по получению документов. Вот ссылка на мой пост там.
📌 @chatfornomads — чат при том канале, можно поиском найти ответ на вообще любой вопрос.
============================
Итак, дано:
1. В Тбилиси классно, но хотим двигаться дальше
2. В идеале — в страну, где ребенок сможет претендовать на гражданство
3. Получить оффер и быть релоцированным Европейской компанией — простой путь. Но уходить из Авито не хочу.
4. Аргентина — не вариант, часовой пояс не даст работать
И тут как раз Испания с этого года запускает выдачу резиденции для цифровых кочевников.
15 мая мы с супругой и собакой выехали из Тбилиси в Москву, чтобы собрать все документы и 3 июня стартовать в обратную сторону.
Предстояло проехать 7500км через Россию, Грузию, Турцию, Грецию, на пароме в Италию, затем Франция и наконец Испания.
За время пути я взял всего 4 дня отпуска, всё остальное время работал. По дороге были моменты грустные и веселые. За поездку мы жили в 24 разных апартах. Мы купались в трёх морях. Жрали осьминогов на гриле. Ночевали под горой Олимп. Ночевали с машиной на пароме. Гуляли по Риму. Были в Ватикане и Монако. Держали пизанскую башню. Ночью нам разбили окна в машине, чтобы вытащить багаж. Достали один чемодан, где был собачий корм, поводок и барахло. А второй чемодан с ценной электроникой и документами не пролез в разбитое окно, и они его оставили. Вот оно, везение 🙂
4 июля мы подали документы на рассмотрение, а 11 июля у нас истёк шенген. Пока ждали решение по внж, мы всё еще легально находились на территории Испании. Но в случае отказа — «первым прямым рейсом домой». А мы на машине, с собакой, супруга беременная так что уже на самолет не посадят, да и рейсов прямых нет 🙂 Короче, отказ не вариант.
И вот, на днях пришло одобрение. Сейчас мы обосновались в Валенсии. Сняли квартиру на долгосрок, прописались, сдали отпечатки пальцев, ждём карточки резидента.
Это был большой проект. И он успешно запущен.
В процессе еще один большой проект, ради которого затевалась релокация — примерно в октябре я стану батей
🔥225❤50👍35🎉15🐳2
Как мы команду делили
Наверняка вы слышали про предельный размер команды: 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.
Например, банальное — На планировании надо куда-то накидывать задачи и стартовать спринт, но нет отдельных досок в джире, только общая, доставшаяся «в наследство». Но это мелочь, джира позволяет вести несколько параллельных спринтов на одной доске и не видеть задачи друг друга. Хуже было то, что мы не сразу завели отдельные чаты по командам, и писали о задачах вперемешку в общий чат. Из-за этого первое время ребятам было сложно «отпустить» задачи другой команды.
Если вы уже проходили этот путь — поделитесь в комментах своим опытом. Интересен будет как взгляд изнутри, со стороны разработчика, так и со стороны тимлида / скрам-мастера. На что стоит обратить внимание? Какие ошибки совершили, как их можно было бы избежать?
Наверняка вы слышали про предельный размер команды: 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.
Например, банальное — На планировании надо куда-то накидывать задачи и стартовать спринт, но нет отдельных досок в джире, только общая, доставшаяся «в наследство». Но это мелочь, джира позволяет вести несколько параллельных спринтов на одной доске и не видеть задачи друг друга. Хуже было то, что мы не сразу завели отдельные чаты по командам, и писали о задачах вперемешку в общий чат. Из-за этого первое время ребятам было сложно «отпустить» задачи другой команды.
Если вы уже проходили этот путь — поделитесь в комментах своим опытом. Интересен будет как взгляд изнутри, со стороны разработчика, так и со стороны тимлида / скрам-мастера. На что стоит обратить внимание? Какие ошибки совершили, как их можно было бы избежать?
🔥23❤10👍7
Этап 1. Подготовка к разделению команд.
Итак, о чем точно стоит позаботиться заранее:
1. Определить потребность разделения
2. Проработать принцип разделения, предназначение команд
3. Подготовить разработчиков
4. Определить предварительный состав команд
5. Позаботиться о процессах в будущих командах
Потребность должна быть надолго. Формирование команд — процесс дорогой и болезненный. Поэтому если у вас есть уверенность только на пару месяцев, а дальше полный туман — возможно стоит начать с подстройки процессов и / или рабочих групп внутри одной команды
А еще потребность должна быть очевидной для всех, включая разработчиков в команде. Разделение должно решать проблемы. Например: «нас много, мы медленные», «слишком много контекстов».
В нашем случае потребность виднелась на горизонте года, две команды были обоснованы проектом, который мы пилили, и на масштабе 12 человек ребята сами стали жаловаться на количество контекстов и коммуникаций.
Принцип разделения — от продуктового направления
У нас был проект размером в год. В нём два больших направления: «Управление профилями» и «Использование мультипрофиля».
Вот это и стало основополагающим принципом: по доменным областям ответственности. Это было достаточно очевидным решением, которое поддержали продакты.
У вас может быть другой принцип. Например, выделение платформенной core-команды, чтобы делать долгосрочные технические улучшения и ускорять работу продуктовых команд. Для выделения такой команды может понадобиться сильно договариваться с продактами.
Подготовить разработчиков
Тут нужно на 1-1 и на общих встречах спрашивать у ребят, видят ли они проблемы в текущем составе, и как можно их решить.
Команда может быть консервативной: ребята сработались и не хотят терять связь друг с другом. Тогда они сами могут предложить концепт рабочих групп.
Здесь можно подсветить, что рабочие группы могут стать слаженными «подкомандами» и разделение случится само собой. Это тоже рабочий вариант, тогда вернуться к вопросу можно будет через квартал или полгода.
Определить состав команд
Чтобы состав был авторизован командой, нужно учесть возможности и желания каждого. Скорее всего не получится все хотелки удовлетворить, но там где не получается — важно показать трейдофф и дать разработчику самому принять решение.
Это очень интересное составное уравнение с кучей переменных. Получился такой лонгрид, что решил вынести его в следующий пост.
===========================
В качестве иллюстрации к посту сделал MindMap подготовки к разделению. Картинка к посту получилась шакальная, поэтому вот ссылка на исходник в Miro.
Итак, о чем точно стоит позаботиться заранее:
1. Определить потребность разделения
2. Проработать принцип разделения, предназначение команд
3. Подготовить разработчиков
4. Определить предварительный состав команд
5. Позаботиться о процессах в будущих командах
Потребность должна быть надолго. Формирование команд — процесс дорогой и болезненный. Поэтому если у вас есть уверенность только на пару месяцев, а дальше полный туман — возможно стоит начать с подстройки процессов и / или рабочих групп внутри одной команды
А еще потребность должна быть очевидной для всех, включая разработчиков в команде. Разделение должно решать проблемы. Например: «нас много, мы медленные», «слишком много контекстов».
В нашем случае потребность виднелась на горизонте года, две команды были обоснованы проектом, который мы пилили, и на масштабе 12 человек ребята сами стали жаловаться на количество контекстов и коммуникаций.
Принцип разделения — от продуктового направления
У нас был проект размером в год. В нём два больших направления: «Управление профилями» и «Использование мультипрофиля».
Вот это и стало основополагающим принципом: по доменным областям ответственности. Это было достаточно очевидным решением, которое поддержали продакты.
У вас может быть другой принцип. Например, выделение платформенной core-команды, чтобы делать долгосрочные технические улучшения и ускорять работу продуктовых команд. Для выделения такой команды может понадобиться сильно договариваться с продактами.
Подготовить разработчиков
Тут нужно на 1-1 и на общих встречах спрашивать у ребят, видят ли они проблемы в текущем составе, и как можно их решить.
Команда может быть консервативной: ребята сработались и не хотят терять связь друг с другом. Тогда они сами могут предложить концепт рабочих групп.
Здесь можно подсветить, что рабочие группы могут стать слаженными «подкомандами» и разделение случится само собой. Это тоже рабочий вариант, тогда вернуться к вопросу можно будет через квартал или полгода.
Определить состав команд
Чтобы состав был авторизован командой, нужно учесть возможности и желания каждого. Скорее всего не получится все хотелки удовлетворить, но там где не получается — важно показать трейдофф и дать разработчику самому принять решение.
Это очень интересное составное уравнение с кучей переменных. Получился такой лонгрид, что решил вынести его в следующий пост.
===========================
В качестве иллюстрации к посту сделал MindMap подготовки к разделению. Картинка к посту получилась шакальная, поэтому вот ссылка на исходник в Miro.
🔥21👍10❤6
Как подобрать состав команд при разделении
Продолжаем цикл лонгридов про разделение команд. Первый пост тут.
В идеальном мире продуктовые разработчики самоорганизуются на две идеальные команды.
Но мы не в идеальном мире, и есть риск что составы получатся не оптимальные.
Здесь нужна помощь человека который соберет все-все-все контексты с ребят и предложит оптимальный вариант.
В идеальном мире вы хорошо знаете свою команду и в голове интуитивно уже подобрали состав.
Но мы не в идеальном мире и есть риск что интуиция ошибается.
Давайте попробуем систематизировать
Нужно с помощью разработчиков ответить на ряд вопросов.
Это не исчерпывающий список, буду рад предложениям в комментах.
📌 — Какие навыки нужны команде, кто из разработчиков что умеет и в каком направлении хочет развиваться
Здесь поможет упражнение StarMap. Можно пройти его вместе с командой, а можно самому. Если проходить вместе, то рассчитывайте часа на 4 минимум. Дорого, зато у ребят появится командный артефакт, о котором они могут заботиться, и который может быть частью их самоидентификации. Если составлять индивидуально, вам всё равно придётся собирать информацию на 1-1, и суммарно времени потратите не меньше.
📌 — Кто какую роль занимает в команде сейчас и какую может занять в новой команде
Здесь можно идти по интуиции и личному впечатлению от ребят. А если есть желание системно подойти к вопросу — посоветую хороший сборник статей: Работа в команде — модели, теории, алгоритмы
В этом сборнике советую обратить внимание на профиль управления командой Маргерисона-Макканна. Чем-то похоже на модель Белбина, но расширяет её.
Есть сложность — у нас только один тимлид и один продакт. Один из инженеров хочет расти в тимлида, но он только что пришел в компанию и прямо сейчас еще онбордится. Нужно дать ему возможность вырасти, а для этого команда должна быть сильной и более автономной. Недостаток тимлида и продакта будем компенсировать ролями координатора и исследователя. А взращивать будем с помощью практики фича-драйвинга.
📌 — Кто с кем хочет работать
Здесь стоит учесть персональные связи участников. Не стоит разлучать ментора и менти. И наоборот: возможно, есть личная несовместимость между двумя разработчиками, и они не хотят друг с другом работать.
📌 — Кто какие фичи хочет делать.
В одной команде большой объем новых client-facing фич. В другой — переделка корневых механик авторизации и управления данными, которые менее заметны клиенту, но более сложные.
Приведу упрощенный пример нашего уравнения
Disclaimer: все имена вымышленные.
Вася — душа команды, уже взял на себя фича-драйвинг объемной фичи А, которая пойдёт в разработку в команду А.
Антон — ценный мидл «педалёр», очень быстро пишет много качественного кода. Он хочет работать с Васей. И задачи команды А ему подходят.
Петя — ментор Антона, супер-эксперт. Задачи команды А для него будут скучноваты.
Костя — хороший интегратор, он фича-драйвер фичи Б, которая входит в скоуп команды Б. Фича Б — супер сложная и на ней нужен Петя.
Антон хочет работать с Васей и не хочет работать с Костей.
Допустим, есть еще несколько мидлов, которым не принципиально, с кем работать.
Как бы вы распределили ребят по командам? Правильного ответа на этот вопрос нет, предлагаю порассуждать о вариантах действий в комментариях.
P.S. У нас было 12 разработчиков и 3-4 вот таких коллизий как у Антона. По итогу все решили, и спустя год ребята не хотят менять состав 🙂
Продолжаем цикл лонгридов про разделение команд. Первый пост тут.
В идеальном мире продуктовые разработчики самоорганизуются на две идеальные команды.
Но мы не в идеальном мире, и есть риск что составы получатся не оптимальные.
Здесь нужна помощь человека который соберет все-все-все контексты с ребят и предложит оптимальный вариант.
В идеальном мире вы хорошо знаете свою команду и в голове интуитивно уже подобрали состав.
Но мы не в идеальном мире и есть риск что интуиция ошибается.
Давайте попробуем систематизировать
Нужно с помощью разработчиков ответить на ряд вопросов.
Это не исчерпывающий список, буду рад предложениям в комментах.
📌 — Какие навыки нужны команде, кто из разработчиков что умеет и в каком направлении хочет развиваться
Здесь поможет упражнение StarMap. Можно пройти его вместе с командой, а можно самому. Если проходить вместе, то рассчитывайте часа на 4 минимум. Дорого, зато у ребят появится командный артефакт, о котором они могут заботиться, и который может быть частью их самоидентификации. Если составлять индивидуально, вам всё равно придётся собирать информацию на 1-1, и суммарно времени потратите не меньше.
📌 — Кто какую роль занимает в команде сейчас и какую может занять в новой команде
Здесь можно идти по интуиции и личному впечатлению от ребят. А если есть желание системно подойти к вопросу — посоветую хороший сборник статей: Работа в команде — модели, теории, алгоритмы
В этом сборнике советую обратить внимание на профиль управления командой Маргерисона-Макканна. Чем-то похоже на модель Белбина, но расширяет её.
Есть сложность — у нас только один тимлид и один продакт. Один из инженеров хочет расти в тимлида, но он только что пришел в компанию и прямо сейчас еще онбордится. Нужно дать ему возможность вырасти, а для этого команда должна быть сильной и более автономной. Недостаток тимлида и продакта будем компенсировать ролями координатора и исследователя. А взращивать будем с помощью практики фича-драйвинга.
📌 — Кто с кем хочет работать
Здесь стоит учесть персональные связи участников. Не стоит разлучать ментора и менти. И наоборот: возможно, есть личная несовместимость между двумя разработчиками, и они не хотят друг с другом работать.
📌 — Кто какие фичи хочет делать.
В одной команде большой объем новых client-facing фич. В другой — переделка корневых механик авторизации и управления данными, которые менее заметны клиенту, но более сложные.
Приведу упрощенный пример нашего уравнения
Disclaimer: все имена вымышленные.
Вася — душа команды, уже взял на себя фича-драйвинг объемной фичи А, которая пойдёт в разработку в команду А.
Антон — ценный мидл «педалёр», очень быстро пишет много качественного кода. Он хочет работать с Васей. И задачи команды А ему подходят.
Петя — ментор Антона, супер-эксперт. Задачи команды А для него будут скучноваты.
Костя — хороший интегратор, он фича-драйвер фичи Б, которая входит в скоуп команды Б. Фича Б — супер сложная и на ней нужен Петя.
Антон хочет работать с Васей и не хочет работать с Костей.
Допустим, есть еще несколько мидлов, которым не принципиально, с кем работать.
Как бы вы распределили ребят по командам? Правильного ответа на этот вопрос нет, предлагаю порассуждать о вариантах действий в комментариях.
P.S. У нас было 12 разработчиков и 3-4 вот таких коллизий как у Антона. По итогу все решили, и спустя год ребята не хотят менять состав 🙂
👍12❤4🔥4
Тегаешь коллегу — дай краткую вводную
…
тред в рабочем мессенджере на 100 сообщений
…
@ Nikita Khromushkin, поможешь тут?
…
Да, конечно! Сейчас, только прочитаю предыдущие 100 сообщений.
(про себя: мне б кто помог)
В последнее время выработал такой ответ:
«Ребята, не смогу вгрузить весь тред, дайте краткую выжимку и что от меня требуется?»
Идея простая: если тебе нужно, чтобы тебе помогли — помоги первый. Прояви заботу о получателе сообщения — увеличишь шансы, что он тебе поможет в ответ.
Заодно свои мысли структурируешь, и поймешь, что на самом деле нужно от коллеги. Может быть, и призывать не придется.
Упакуй свой запрос в удобную форму:
1️⃣ — О чем тред
2️⃣ — Какой возник вопрос
3️⃣ — Чего хотим от коллеги
============================
Пример
Тред на 50 сообщений, где инженеры разбирают багу, которая на самом деле фича. Меня туда призвали формулировкой «Давайте призовем Никиту для контекста».
Пришлось вгружать весь тред, чтобы полностью понять контекст и что с этим делать.
Этот вопрос я переадресовал продакту, предварительно упаковав в удобно воспринимаемый формат:
«Илья, нужно принять продуктовое решение по багу.
Есть пользователи, у которых …
Есть предположение, что таким пользователям нужен ...
От тебя нужен концептуальный ответ, можем ли конвертировать баг в фича-реквест?»
Это простая идея, которую я почерпнул в книге «Новые правила деловой переписки».
Но этот пост пишу после какой-то адской недели призывов без контекста.
Если вам что-то нужно от коллеги, — то упростите ему работу, позаботьтесь о нем.
У вас контекст уже есть в голове и это займёт минуту, а коллеге сэкономит минут 15 чтобы вникнуть.
Верю, что этот пост принесет пользу: кто-то позаботится о читателе, упакует информацию в удобном для коллеги виде, и получит в ответ то, что хочет.
…
тред в рабочем мессенджере на 100 сообщений
…
@ Nikita Khromushkin, поможешь тут?
…
Да, конечно! Сейчас, только прочитаю предыдущие 100 сообщений.
(про себя: мне б кто помог)
В последнее время выработал такой ответ:
«Ребята, не смогу вгрузить весь тред, дайте краткую выжимку и что от меня требуется?»
Идея простая: если тебе нужно, чтобы тебе помогли — помоги первый. Прояви заботу о получателе сообщения — увеличишь шансы, что он тебе поможет в ответ.
Заодно свои мысли структурируешь, и поймешь, что на самом деле нужно от коллеги. Может быть, и призывать не придется.
Упакуй свой запрос в удобную форму:
1️⃣ — О чем тред
2️⃣ — Какой возник вопрос
3️⃣ — Чего хотим от коллеги
============================
Пример
Тред на 50 сообщений, где инженеры разбирают багу, которая на самом деле фича. Меня туда призвали формулировкой «Давайте призовем Никиту для контекста».
Пришлось вгружать весь тред, чтобы полностью понять контекст и что с этим делать.
Этот вопрос я переадресовал продакту, предварительно упаковав в удобно воспринимаемый формат:
«Илья, нужно принять продуктовое решение по багу.
Есть пользователи, у которых …
Есть предположение, что таким пользователям нужен ...
От тебя нужен концептуальный ответ, можем ли конвертировать баг в фича-реквест?»
Это простая идея, которую я почерпнул в книге «Новые правила деловой переписки».
Но этот пост пишу после какой-то адской недели призывов без контекста.
Если вам что-то нужно от коллеги, — то упростите ему работу, позаботьтесь о нем.
У вас контекст уже есть в голове и это займёт минуту, а коллеге сэкономит минут 15 чтобы вникнуть.
Верю, что этот пост принесет пользу: кто-то позаботится о читателе, упакует информацию в удобном для коллеги виде, и получит в ответ то, что хочет.
💯106❤43👍28🔥16👎1
Авторитет
Кто-то может считать, что иметь авторитет = быть самой сильной обезьяной.
А тимлидом становятся, победив предыдущего тимлида в честном кодревью 🙂
Я считаю, что авторитет — это кредит доверия. Когда вы можете приносить непопулярные идеи, и вас не пошлют, а выслушают. Потому что доверяют. А иногда кредит доверия позволяет срезать углы и бежать быстрее, не тратя время на объяснения. Но это крайний случай и портит кредитную историю.
И не важно, выросли вы в тимлида изнутри или только онбордитесь, о кредитной истории надо заботиться, чтобы работать было проще.
Представьте ситуацию: К вам приходит продакт и говорит, что появились новые вводные в задаче, которую вы собирались разрабатывать в следующем спринте. Учитывать новые вводные — потратить еще неделю на проработку задачи и пересмотреть техническую декомпозицию. Вы уточнили необходимость, убедились, что делать надо, и если сейчас не учесть, то потом придется переделывать.
Вы говорите с командой и спрашиваете, кто хотел бы технически поисследовать несколько корнер-кейсов. На что слышите раздраженный ответ:
— Блин, мы уже две недели потратили, чтобы прогрумить эту фичу в таком виде. Половину придется выкидывать. Тебе что, не жалко наше время?
Что вы бы ответили в такой ситуации?
Думаю, первый вариант, который приходит в голову — узнать, понимают ли ребята негативное влияние, если запилить так, как собирались. И это правда важно сделать, но не сразу, ведь перед нами не просто возражение, а манипуляция.
Когда вы не видите манипуляции и поддаетесь на них, или если разрешаете себе не реагировать на них, ваш авторитет снижается.
Жестко настоять на своем и забить на мнение ребят — тоже плохой вариант, при котором вы снижаете свой кредит доверия. Вы рискуете создать атмосферу, в которой люди будут бояться выражать свою точку зрения и получить демотивированную команду.
Напишите в комментариях, что должен сделать хороший тимлид в такой ситуации.
Кто-то может считать, что иметь авторитет = быть самой сильной обезьяной.
А тимлидом становятся, победив предыдущего тимлида в честном кодревью 🙂
Я считаю, что авторитет — это кредит доверия. Когда вы можете приносить непопулярные идеи, и вас не пошлют, а выслушают. Потому что доверяют. А иногда кредит доверия позволяет срезать углы и бежать быстрее, не тратя время на объяснения. Но это крайний случай и портит кредитную историю.
И не важно, выросли вы в тимлида изнутри или только онбордитесь, о кредитной истории надо заботиться, чтобы работать было проще.
Представьте ситуацию: К вам приходит продакт и говорит, что появились новые вводные в задаче, которую вы собирались разрабатывать в следующем спринте. Учитывать новые вводные — потратить еще неделю на проработку задачи и пересмотреть техническую декомпозицию. Вы уточнили необходимость, убедились, что делать надо, и если сейчас не учесть, то потом придется переделывать.
Вы говорите с командой и спрашиваете, кто хотел бы технически поисследовать несколько корнер-кейсов. На что слышите раздраженный ответ:
— Блин, мы уже две недели потратили, чтобы прогрумить эту фичу в таком виде. Половину придется выкидывать. Тебе что, не жалко наше время?
Что вы бы ответили в такой ситуации?
Думаю, первый вариант, который приходит в голову — узнать, понимают ли ребята негативное влияние, если запилить так, как собирались. И это правда важно сделать, но не сразу, ведь перед нами не просто возражение, а манипуляция.
Когда вы не видите манипуляции и поддаетесь на них, или если разрешаете себе не реагировать на них, ваш авторитет снижается.
Жестко настоять на своем и забить на мнение ребят — тоже плохой вариант, при котором вы снижаете свой кредит доверия. Вы рискуете создать атмосферу, в которой люди будут бояться выражать свою точку зрения и получить демотивированную команду.
Напишите в комментариях, что должен сделать хороший тимлид в такой ситуации.
👍16🔥11❤4🤩4❤🔥2👎2
Как мы провели 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 на полтора часа
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 на полтора часа
🔥30❤3👍2
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, с помощью которой было можно направлять смс на устройство хакера вместо легитимного устройства пользователя.
=========
А вы используете коды из смс в своих продуктах? Задумывались когда-нибудь про смену владельца номера телефона?
В следующем посте поделюсь альтернативами.
…но всё еще самая распространенная
Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление.
Кажется логичным, что раз у пользователя есть телефон и мы его знаем, то давайте на него отправлять одноразовые коды для всего.
И это настолько привычно, что многие ни на секунду не задумываются о проблемах и альтернативах.
Этим постом хочу подсветить очевидные (и не очень) проблемы.
В следующем поделюсь некоторыми альтернативами.
Почему плохо?
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, с помощью которой было можно направлять смс на устройство хакера вместо легитимного устройства пользователя.
=========
А вы используете коды из смс в своих продуктах? Задумывались когда-нибудь про смену владельца номера телефона?
В следующем посте поделюсь альтернативами.
👍62💯12❤10👎1🌚1
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 способы подтверждения.
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 способы подтверждения.
👍21🔥8❤4
Кнопка «Да, это я» / Вход по 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 вы видели? Может быть, что-то такое делали в своих сервисах?
Продолжаем серию постов про альтернативы смс с кодами для 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 вы видели? Может быть, что-то такое делали в своих сервисах?
👍10❤6🔥1
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/ — Потыкать самому, зарегистрироваться + залогиниться
На всякий случай: это не реклама, потому что это как если бы я продавал вам механизм 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, а в первом комменте накидаю скринов:
- PayPal
- Apple
- Microsoft
- 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/ — Потыкать самому, зарегистрироваться + залогиниться
👍17🔥14❤5🌚1
Кто хочет вашу цель спринта?
«Цель спринта» — концепция простая с первого взгляда, но с кучей подводных камней. Мы с командами знатно походили по граблям, но все равно продолжаем ставить цели спринтов. Каждый раз, наступая на грабли, я страдал и через страдания делал некоторые умозаключения.
Вот решил поделиться.
Disclaimer: не навязываю никому «этот ваш скрам». В моем юните 3 команды работают двухнедельными спринтами и одна — по канбану. Этот пост — послание самому себе на 5 лет назад, чтобы меньше фрустрировать.
———
Говорят, что команда отличается от рабочей группы тем, что у команды есть общая Цель.
В идеале — вся команда объединяет усилия, чтобы за спринт родить эту Цель.
Цель мечты — качественную, отвечающую всем критериям приемки и доделанную до Definition of Done.
Работа в таких командах доставляет истинное удовольствие. Коллаборация — один из самых сильных мотиваторов для меня.
Но в какой-то момент формирование и достижение Цели стало для меня самоцелью работы. Каждые две недели — подведение итогов по прошлой цели и формирование новой.
Если не получалось достичь цели — разбирали на ретроспективе.
А вот когда не получалось сформулировать такую цель, не разбирали.
На ретро довольно сложно поднять вопрос «почему наши цели спринта не объединяют работу команды».
А даже если и поднять такой вопрос, то большой риск огрести: «этот ваш скрам не работает», «вот у нас такие особенные обстоятельства».
Причины могут быть разными:
— либо нет такого запроса от продакта, чтобы за один спринт взять и зафигачить
— либо цель недостаточно трудозатратная, чтобы задействовать всех инженеров в спринте
— или не смогли достаточно распараллелить, и в итоге фича занимает несколько спринтов, а цели получаются типа «написать ручку на бэкенде» и «сверстать экран».
Так появляются две цели. Три цели. Шесть целей. Отдельные цели у фронтендеров и бэкендеров.
Зачастую инженеры сначала набирают задачи в спринт, а потом пытаются из этого родить цель.
Так в одном спринте появляются цели типа
1. «Три ручки из пяти под фичу Х»
2. «Верстка экранов + интеграция с бэком под фичу Y».
3. «Раскатка фичи Й»
Выглядит как мини-вотерфолл по трём проектам.
Нахрена нам кросс-функциональная команда?
Кому нужны такие цели?
Захочет ли продакт участвовать в жизни команды, которая занимается тем что напиливает ручки и верстает экраны?
На что ему смотреть на ревью спринта?
———
Последовательность планирования спринта должна быть другой: сначала обозначается цель, а затем набираются задачи для её решения.
Не можем сделать целиком сценарий фичи, напилив 5 ручек?
Тогда цель может быть: «Короткий успешный сценарий фичи Х».
А DoD может включать пункт «Реализовано на всех платформах».
Часть сценария тоже может принести пользу: так мы сможем посмотреть на сценарий целиком на ревью спринта и получить первую обратную связь от продакта, от пользователей, да и друг от друга.
Можно убедить продакта: «Сценарий целиком займёт 3 спринта», и потерять его из жизни команды на 1.5 месяца.
А можно найти способ получить промежуточную обратную связь: спросить, хочет ли он посмотреть короткий успешный сценарий — он скорее всего обрадуется.
А если спросить, хочет ли он посмотреть на три из пяти ручек — скорее всего не поймёт.
Наличие стейкхолдера у цели спринта — хороший критерий качественной цели.
В следующий раз, когда будете формировать цель спринта, попробуйте задать вопрос:
Кто хочет эту цель спринта?
И постарайтесь сделать так, чтобы каждую цель кто-то явно хотел.
P.S. В следующем посте расскажу, какие еще лайфхаки разбивки целей бывают, чтобы делать за спринт то, что кому-то нужно. На картинке — один из таких примеров.
«Цель спринта» — концепция простая с первого взгляда, но с кучей подводных камней. Мы с командами знатно походили по граблям, но все равно продолжаем ставить цели спринтов. Каждый раз, наступая на грабли, я страдал и через страдания делал некоторые умозаключения.
Вот решил поделиться.
Disclaimer: не навязываю никому «этот ваш скрам». В моем юните 3 команды работают двухнедельными спринтами и одна — по канбану. Этот пост — послание самому себе на 5 лет назад, чтобы меньше фрустрировать.
———
Говорят, что команда отличается от рабочей группы тем, что у команды есть общая Цель.
В идеале — вся команда объединяет усилия, чтобы за спринт родить эту Цель.
Цель мечты — качественную, отвечающую всем критериям приемки и доделанную до Definition of Done.
Работа в таких командах доставляет истинное удовольствие. Коллаборация — один из самых сильных мотиваторов для меня.
Но в какой-то момент формирование и достижение Цели стало для меня самоцелью работы. Каждые две недели — подведение итогов по прошлой цели и формирование новой.
Если не получалось достичь цели — разбирали на ретроспективе.
А вот когда не получалось сформулировать такую цель, не разбирали.
На ретро довольно сложно поднять вопрос «почему наши цели спринта не объединяют работу команды».
А даже если и поднять такой вопрос, то большой риск огрести: «этот ваш скрам не работает», «вот у нас такие особенные обстоятельства».
Причины могут быть разными:
— либо нет такого запроса от продакта, чтобы за один спринт взять и зафигачить
— либо цель недостаточно трудозатратная, чтобы задействовать всех инженеров в спринте
— или не смогли достаточно распараллелить, и в итоге фича занимает несколько спринтов, а цели получаются типа «написать ручку на бэкенде» и «сверстать экран».
Так появляются две цели. Три цели. Шесть целей. Отдельные цели у фронтендеров и бэкендеров.
Зачастую инженеры сначала набирают задачи в спринт, а потом пытаются из этого родить цель.
Так в одном спринте появляются цели типа
1. «Три ручки из пяти под фичу Х»
2. «Верстка экранов + интеграция с бэком под фичу Y».
3. «Раскатка фичи Й»
Выглядит как мини-вотерфолл по трём проектам.
Нахрена нам кросс-функциональная команда?
Кому нужны такие цели?
Захочет ли продакт участвовать в жизни команды, которая занимается тем что напиливает ручки и верстает экраны?
На что ему смотреть на ревью спринта?
———
Последовательность планирования спринта должна быть другой: сначала обозначается цель, а затем набираются задачи для её решения.
Не можем сделать целиком сценарий фичи, напилив 5 ручек?
Тогда цель может быть: «Короткий успешный сценарий фичи Х».
А DoD может включать пункт «Реализовано на всех платформах».
Часть сценария тоже может принести пользу: так мы сможем посмотреть на сценарий целиком на ревью спринта и получить первую обратную связь от продакта, от пользователей, да и друг от друга.
Можно убедить продакта: «Сценарий целиком займёт 3 спринта», и потерять его из жизни команды на 1.5 месяца.
А можно найти способ получить промежуточную обратную связь: спросить, хочет ли он посмотреть короткий успешный сценарий — он скорее всего обрадуется.
А если спросить, хочет ли он посмотреть на три из пяти ручек — скорее всего не поймёт.
Наличие стейкхолдера у цели спринта — хороший критерий качественной цели.
В следующий раз, когда будете формировать цель спринта, попробуйте задать вопрос:
Кто хочет эту цель спринта?
И постарайтесь сделать так, чтобы каждую цель кто-то явно хотел.
P.S. В следующем посте расскажу, какие еще лайфхаки разбивки целей бывают, чтобы делать за спринт то, что кому-то нужно. На картинке — один из таких примеров.
❤32👍11👎2❤🔥1🔥1🌚1
Дайджест полезностей в продуктовой папке
Как-то я затесался в тусовку авторов каналов про продукты, а этот канал попал в папку с каналами 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, чтобы читать такие полезности.
После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.
Как-то я затесался в тусовку авторов каналов про продукты, а этот канал попал в папку с каналами 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, чтобы читать такие полезности.
После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.
Telegram
Product Developer
SMS Two factor auth — плохая практика
…но всё еще самая распространенная
Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление.…
…но всё еще самая распространенная
Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление.…
❤4👍4🔥3🐳1