Как подобрать состав команд при разделении
Продолжаем цикл лонгридов про разделение команд. Первый пост тут.
В идеальном мире продуктовые разработчики самоорганизуются на две идеальные команды.
Но мы не в идеальном мире, и есть риск что составы получатся не оптимальные.
Здесь нужна помощь человека который соберет все-все-все контексты с ребят и предложит оптимальный вариант.
В идеальном мире вы хорошо знаете свою команду и в голове интуитивно уже подобрали состав.
Но мы не в идеальном мире и есть риск что интуиция ошибается.
Давайте попробуем систематизировать
Нужно с помощью разработчиков ответить на ряд вопросов.
Это не исчерпывающий список, буду рад предложениям в комментах.
📌 — Какие навыки нужны команде, кто из разработчиков что умеет и в каком направлении хочет развиваться
Здесь поможет упражнение StarMap. Можно пройти его вместе с командой, а можно самому. Если проходить вместе, то рассчитывайте часа на 4 минимум. Дорого, зато у ребят появится командный артефакт, о котором они могут заботиться, и который может быть частью их самоидентификации. Если составлять индивидуально, вам всё равно придётся собирать информацию на 1-1, и суммарно времени потратите не меньше.
📌 — Кто какую роль занимает в команде сейчас и какую может занять в новой команде
Здесь можно идти по интуиции и личному впечатлению от ребят. А если есть желание системно подойти к вопросу — посоветую хороший сборник статей: Работа в команде — модели, теории, алгоритмы
В этом сборнике советую обратить внимание на профиль управления командой Маргерисона-Макканна. Чем-то похоже на модель Белбина, но расширяет её.
Есть сложность — у нас только один тимлид и один продакт. Один из инженеров хочет расти в тимлида, но он только что пришел в компанию и прямо сейчас еще онбордится. Нужно дать ему возможность вырасти, а для этого команда должна быть сильной и более автономной. Недостаток тимлида и продакта будем компенсировать ролями координатора и исследователя. А взращивать будем с помощью практики фича-драйвинга.
📌 — Кто с кем хочет работать
Здесь стоит учесть персональные связи участников. Не стоит разлучать ментора и менти. И наоборот: возможно, есть личная несовместимость между двумя разработчиками, и они не хотят друг с другом работать.
📌 — Кто какие фичи хочет делать.
В одной команде большой объем новых client-facing фич. В другой — переделка корневых механик авторизации и управления данными, которые менее заметны клиенту, но более сложные.
Приведу упрощенный пример нашего уравнения
Disclaimer: все имена вымышленные.
Вася — душа команды, уже взял на себя фича-драйвинг объемной фичи А, которая пойдёт в разработку в команду А.
Антон — ценный мидл «педалёр», очень быстро пишет много качественного кода. Он хочет работать с Васей. И задачи команды А ему подходят.
Петя — ментор Антона, супер-эксперт. Задачи команды А для него будут скучноваты.
Костя — хороший интегратор, он фича-драйвер фичи Б, которая входит в скоуп команды Б. Фича Б — супер сложная и на ней нужен Петя.
Антон хочет работать с Васей и не хочет работать с Костей.
Допустим, есть еще несколько мидлов, которым не принципиально, с кем работать.
Как бы вы распределили ребят по командам? Правильного ответа на этот вопрос нет, предлагаю порассуждать о вариантах действий в комментариях.
P.S. У нас было 12 разработчиков и 3-4 вот таких коллизий как у Антона. По итогу все решили, и спустя год ребята не хотят менять состав 🙂
Продолжаем цикл лонгридов про разделение команд. Первый пост тут.
В идеальном мире продуктовые разработчики самоорганизуются на две идеальные команды.
Но мы не в идеальном мире, и есть риск что составы получатся не оптимальные.
Здесь нужна помощь человека который соберет все-все-все контексты с ребят и предложит оптимальный вариант.
В идеальном мире вы хорошо знаете свою команду и в голове интуитивно уже подобрали состав.
Но мы не в идеальном мире и есть риск что интуиция ошибается.
Давайте попробуем систематизировать
Нужно с помощью разработчиков ответить на ряд вопросов.
Это не исчерпывающий список, буду рад предложениям в комментах.
📌 — Какие навыки нужны команде, кто из разработчиков что умеет и в каком направлении хочет развиваться
Здесь поможет упражнение StarMap. Можно пройти его вместе с командой, а можно самому. Если проходить вместе, то рассчитывайте часа на 4 минимум. Дорого, зато у ребят появится командный артефакт, о котором они могут заботиться, и который может быть частью их самоидентификации. Если составлять индивидуально, вам всё равно придётся собирать информацию на 1-1, и суммарно времени потратите не меньше.
📌 — Кто какую роль занимает в команде сейчас и какую может занять в новой команде
Здесь можно идти по интуиции и личному впечатлению от ребят. А если есть желание системно подойти к вопросу — посоветую хороший сборник статей: Работа в команде — модели, теории, алгоритмы
В этом сборнике советую обратить внимание на профиль управления командой Маргерисона-Макканна. Чем-то похоже на модель Белбина, но расширяет её.
Есть сложность — у нас только один тимлид и один продакт. Один из инженеров хочет расти в тимлида, но он только что пришел в компанию и прямо сейчас еще онбордится. Нужно дать ему возможность вырасти, а для этого команда должна быть сильной и более автономной. Недостаток тимлида и продакта будем компенсировать ролями координатора и исследователя. А взращивать будем с помощью практики фича-драйвинга.
📌 — Кто с кем хочет работать
Здесь стоит учесть персональные связи участников. Не стоит разлучать ментора и менти. И наоборот: возможно, есть личная несовместимость между двумя разработчиками, и они не хотят друг с другом работать.
📌 — Кто какие фичи хочет делать.
В одной команде большой объем новых client-facing фич. В другой — переделка корневых механик авторизации и управления данными, которые менее заметны клиенту, но более сложные.
Приведу упрощенный пример нашего уравнения
Disclaimer: все имена вымышленные.
Вася — душа команды, уже взял на себя фича-драйвинг объемной фичи А, которая пойдёт в разработку в команду А.
Антон — ценный мидл «педалёр», очень быстро пишет много качественного кода. Он хочет работать с Васей. И задачи команды А ему подходят.
Петя — ментор Антона, супер-эксперт. Задачи команды А для него будут скучноваты.
Костя — хороший интегратор, он фича-драйвер фичи Б, которая входит в скоуп команды Б. Фича Б — супер сложная и на ней нужен Петя.
Антон хочет работать с Васей и не хочет работать с Костей.
Допустим, есть еще несколько мидлов, которым не принципиально, с кем работать.
Как бы вы распределили ребят по командам? Правильного ответа на этот вопрос нет, предлагаю порассуждать о вариантах действий в комментариях.
P.S. У нас было 12 разработчиков и 3-4 вот таких коллизий как у Антона. По итогу все решили, и спустя год ребята не хотят менять состав 🙂
Тегаешь коллегу — дай краткую вводную
…
тред в рабочем мессенджере на 100 сообщений
…
@ Nikita Khromushkin, поможешь тут?
…
Да, конечно! Сейчас, только прочитаю предыдущие 100 сообщений.
(про себя: мне б кто помог)
В последнее время выработал такой ответ:
«Ребята, не смогу вгрузить весь тред, дайте краткую выжимку и что от меня требуется?»
Идея простая: если тебе нужно, чтобы тебе помогли — помоги первый. Прояви заботу о получателе сообщения — увеличишь шансы, что он тебе поможет в ответ.
Заодно свои мысли структурируешь, и поймешь, что на самом деле нужно от коллеги. Может быть, и призывать не придется.
Упакуй свой запрос в удобную форму:
1️⃣ — О чем тред
2️⃣ — Какой возник вопрос
3️⃣ — Чего хотим от коллеги
============================
Пример
Тред на 50 сообщений, где инженеры разбирают багу, которая на самом деле фича. Меня туда призвали формулировкой «Давайте призовем Никиту для контекста».
Пришлось вгружать весь тред, чтобы полностью понять контекст и что с этим делать.
Этот вопрос я переадресовал продакту, предварительно упаковав в удобно воспринимаемый формат:
«Илья, нужно принять продуктовое решение по багу.
Есть пользователи, у которых …
Есть предположение, что таким пользователям нужен ...
От тебя нужен концептуальный ответ, можем ли конвертировать баг в фича-реквест?»
Это простая идея, которую я почерпнул в книге «Новые правила деловой переписки».
Но этот пост пишу после какой-то адской недели призывов без контекста.
Если вам что-то нужно от коллеги, — то упростите ему работу, позаботьтесь о нем.
У вас контекст уже есть в голове и это займёт минуту, а коллеге сэкономит минут 15 чтобы вникнуть.
Верю, что этот пост принесет пользу: кто-то позаботится о читателе, упакует информацию в удобном для коллеги виде, и получит в ответ то, что хочет.
…
тред в рабочем мессенджере на 100 сообщений
…
@ Nikita Khromushkin, поможешь тут?
…
Да, конечно! Сейчас, только прочитаю предыдущие 100 сообщений.
(про себя: мне б кто помог)
В последнее время выработал такой ответ:
«Ребята, не смогу вгрузить весь тред, дайте краткую выжимку и что от меня требуется?»
Идея простая: если тебе нужно, чтобы тебе помогли — помоги первый. Прояви заботу о получателе сообщения — увеличишь шансы, что он тебе поможет в ответ.
Заодно свои мысли структурируешь, и поймешь, что на самом деле нужно от коллеги. Может быть, и призывать не придется.
Упакуй свой запрос в удобную форму:
1️⃣ — О чем тред
2️⃣ — Какой возник вопрос
3️⃣ — Чего хотим от коллеги
============================
Пример
Тред на 50 сообщений, где инженеры разбирают багу, которая на самом деле фича. Меня туда призвали формулировкой «Давайте призовем Никиту для контекста».
Пришлось вгружать весь тред, чтобы полностью понять контекст и что с этим делать.
Этот вопрос я переадресовал продакту, предварительно упаковав в удобно воспринимаемый формат:
«Илья, нужно принять продуктовое решение по багу.
Есть пользователи, у которых …
Есть предположение, что таким пользователям нужен ...
От тебя нужен концептуальный ответ, можем ли конвертировать баг в фича-реквест?»
Это простая идея, которую я почерпнул в книге «Новые правила деловой переписки».
Но этот пост пишу после какой-то адской недели призывов без контекста.
Если вам что-то нужно от коллеги, — то упростите ему работу, позаботьтесь о нем.
У вас контекст уже есть в голове и это займёт минуту, а коллеге сэкономит минут 15 чтобы вникнуть.
Верю, что этот пост принесет пользу: кто-то позаботится о читателе, упакует информацию в удобном для коллеги виде, и получит в ответ то, что хочет.
Авторитет
Кто-то может считать, что иметь авторитет = быть самой сильной обезьяной.
А тимлидом становятся, победив предыдущего тимлида в честном кодревью 🙂
Я считаю, что авторитет — это кредит доверия. Когда вы можете приносить непопулярные идеи, и вас не пошлют, а выслушают. Потому что доверяют. А иногда кредит доверия позволяет срезать углы и бежать быстрее, не тратя время на объяснения. Но это крайний случай и портит кредитную историю.
И не важно, выросли вы в тимлида изнутри или только онбордитесь, о кредитной истории надо заботиться, чтобы работать было проще.
Представьте ситуацию: К вам приходит продакт и говорит, что появились новые вводные в задаче, которую вы собирались разрабатывать в следующем спринте. Учитывать новые вводные — потратить еще неделю на проработку задачи и пересмотреть техническую декомпозицию. Вы уточнили необходимость, убедились, что делать надо, и если сейчас не учесть, то потом придется переделывать.
Вы говорите с командой и спрашиваете, кто хотел бы технически поисследовать несколько корнер-кейсов. На что слышите раздраженный ответ:
— Блин, мы уже две недели потратили, чтобы прогрумить эту фичу в таком виде. Половину придется выкидывать. Тебе что, не жалко наше время?
Что вы бы ответили в такой ситуации?
Думаю, первый вариант, который приходит в голову — узнать, понимают ли ребята негативное влияние, если запилить так, как собирались. И это правда важно сделать, но не сразу, ведь перед нами не просто возражение, а манипуляция.
Когда вы не видите манипуляции и поддаетесь на них, или если разрешаете себе не реагировать на них, ваш авторитет снижается.
Жестко настоять на своем и забить на мнение ребят — тоже плохой вариант, при котором вы снижаете свой кредит доверия. Вы рискуете создать атмосферу, в которой люди будут бояться выражать свою точку зрения и получить демотивированную команду.
Напишите в комментариях, что должен сделать хороший тимлид в такой ситуации.
Кто-то может считать, что иметь авторитет = быть самой сильной обезьяной.
А тимлидом становятся, победив предыдущего тимлида в честном кодревью 🙂
Я считаю, что авторитет — это кредит доверия. Когда вы можете приносить непопулярные идеи, и вас не пошлют, а выслушают. Потому что доверяют. А иногда кредит доверия позволяет срезать углы и бежать быстрее, не тратя время на объяснения. Но это крайний случай и портит кредитную историю.
И не важно, выросли вы в тимлида изнутри или только онбордитесь, о кредитной истории надо заботиться, чтобы работать было проще.
Представьте ситуацию: К вам приходит продакт и говорит, что появились новые вводные в задаче, которую вы собирались разрабатывать в следующем спринте. Учитывать новые вводные — потратить еще неделю на проработку задачи и пересмотреть техническую декомпозицию. Вы уточнили необходимость, убедились, что делать надо, и если сейчас не учесть, то потом придется переделывать.
Вы говорите с командой и спрашиваете, кто хотел бы технически поисследовать несколько корнер-кейсов. На что слышите раздраженный ответ:
— Блин, мы уже две недели потратили, чтобы прогрумить эту фичу в таком виде. Половину придется выкидывать. Тебе что, не жалко наше время?
Что вы бы ответили в такой ситуации?
Думаю, первый вариант, который приходит в голову — узнать, понимают ли ребята негативное влияние, если запилить так, как собирались. И это правда важно сделать, но не сразу, ведь перед нами не просто возражение, а манипуляция.
Когда вы не видите манипуляции и поддаетесь на них, или если разрешаете себе не реагировать на них, ваш авторитет снижается.
Жестко настоять на своем и забить на мнение ребят — тоже плохой вариант, при котором вы снижаете свой кредит доверия. Вы рискуете создать атмосферу, в которой люди будут бояться выражать свою точку зрения и получить демотивированную команду.
Напишите в комментариях, что должен сделать хороший тимлид в такой ситуации.
Как мы провели 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 на полтора часа
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, с помощью которой было можно направлять смс на устройство хакера вместо легитимного устройства пользователя.
=========
А вы используете коды из смс в своих продуктах? Задумывались когда-нибудь про смену владельца номера телефона?
В следующем посте поделюсь альтернативами.
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 способы подтверждения.
Кнопка «Да, это я» / Вход по 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 вы видели? Может быть, что-то такое делали в своих сервисах?
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/ — Потыкать самому, зарегистрироваться + залогиниться
Кто хочет вашу цель спринта?
«Цель спринта» — концепция простая с первого взгляда, но с кучей подводных камней. Мы с командами знатно походили по граблям, но все равно продолжаем ставить цели спринтов. Каждый раз, наступая на грабли, я страдал и через страдания делал некоторые умозаключения.
Вот решил поделиться.
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. В следующем посте расскажу, какие еще лайфхаки разбивки целей бывают, чтобы делать за спринт то, что кому-то нужно. На картинке — один из таких примеров.
Дайджест полезностей в продуктовой папке
Как-то я затесался в тусовку авторов каналов про продукты, а этот канал попал в папку с каналами Products. Внутри — куча полезностей, и не только от продактов.
📌 В канале Фичизм нашел подтверждение актуальности проблемы «угона» сим-карт, о которой я писал раньше — Билайн сделал второй фактор по емейлу при «восстановлении» симки. После прочтения сразу нашел в настройках, включил и вам советую 🙂 https://www.tg-me.com/fichism/51.
📌 Менеджер от боженьки рассказывает, как выбрать, что рефакторить. https://www.tg-me.com/pm_god/424
📌 Владимир Меркушев разбирает кейсы из продуктовой разработки, недавно был про A/B тест длительностью 2 часа. https://www.tg-me.com/vladimir_merkushev/2089
📌 Fresh Product Manager запостил ссылку на статью про коммуникацию продакта с командой от Ангелины Зинченко из Авито https://www.tg-me.com/FreshProductGo/1025
📌 Саша Клименко проводит вебинары про работу с манипуляциями и отстаивание своих интересов: https://www.tg-me.com/normalno_delaj/564
📌 Михаил Греков нашел еще одно отличие продукта от проекта: в продукте нужна смекалка! Приводит прикольные кейсы её проявления, например хак оптовых заказов на заре Амазона: https://www.tg-me.com/proudobstvo/1212
Подписывайтесь на папку Products, чтобы читать такие полезности.
После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.
Как-то я затесался в тусовку авторов каналов про продукты, а этот канал попал в папку с каналами Products. Внутри — куча полезностей, и не только от продактов.
📌 В канале Фичизм нашел подтверждение актуальности проблемы «угона» сим-карт, о которой я писал раньше — Билайн сделал второй фактор по емейлу при «восстановлении» симки. После прочтения сразу нашел в настройках, включил и вам советую 🙂 https://www.tg-me.com/fichism/51.
📌 Менеджер от боженьки рассказывает, как выбрать, что рефакторить. https://www.tg-me.com/pm_god/424
📌 Владимир Меркушев разбирает кейсы из продуктовой разработки, недавно был про A/B тест длительностью 2 часа. https://www.tg-me.com/vladimir_merkushev/2089
📌 Fresh Product Manager запостил ссылку на статью про коммуникацию продакта с командой от Ангелины Зинченко из Авито https://www.tg-me.com/FreshProductGo/1025
📌 Саша Клименко проводит вебинары про работу с манипуляциями и отстаивание своих интересов: https://www.tg-me.com/normalno_delaj/564
📌 Михаил Греков нашел еще одно отличие продукта от проекта: в продукте нужна смекалка! Приводит прикольные кейсы её проявления, например хак оптовых заказов на заре Амазона: https://www.tg-me.com/proudobstvo/1212
Подписывайтесь на папку Products, чтобы читать такие полезности.
После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.
Telegram
Product Developer
SMS Two factor auth — плохая практика
…но всё еще самая распространенная
Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление.…
…но всё еще самая распространенная
Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление.…
Как и зачем декомпозировать User Story — 21 шаблон
Давайте представим, что мы делаем некий MVP. На дискавери потрачено 3 месяца. Скоуп определен, дизайны отрисованы и требования подробно описаны. На разработку заложено еще 3 месяца. Катить на пользователей что-то меньшее, чем этот скоуп — бессмысленно. Например, зачем видеть список товаров, если корзины нет и оплатить невозможно.
Итак, тз описано и срок в три месяца на разработку начал тикать.
Продакт может отойти и не мешать. Ведь никто не любит, когда заглядывают за плечо и спрашивают «ну когда». А он же хороший руководитель и доверяет своей команде!
…
Следующий кадр: прошло 3 месяца, продакт смотрит, что получилось.
А получилось, что параллельно делали всё, закопались и ни один сценарий целиком не успели.
Команда говорит, что показать промежуточный результат не могут и нужен еще 1 месяц.
А через месяц нужен еще 1 месяц.
В итоге через 5 месяцев сдают проект. И вроде бы всё по тз, но «не то».
«Программисты виноваты!» — скажете вы.
«Какое тз, такой и результат!» — ответят программисты.
Всем плохо: программисты без премии, продакт с кривым MVP, которое уже никому не нужно.
Можно ли было помочь и команде и продакту? — Да!
Очень часто в продуктовой разработке мы изобретаем водопадные процессы.
Долго и тщательно дискаверим, по мере уточнения требований предполагаемый срок деливери увеличивается.
В итоге пилим проект, размером в квартал/полугодие/год.
А чем дольше горизонт планирования, тем больше вероятность не попасть в оценки.
Поэтому есть простое решение, как лучше попадать в сроки и делать «то», благодаря более частой обратной связи:
Вместо долгого дискавери, мелко декомпозировать и начинать деливери.
А параллельно доделывать дискавери по другим частям.
Вот как мог бы выглядеть процесс разработки нашего MVP по спринтам:
0️⃣ — Для старта проекта нам нужно хоть какое-то описание первой функции. Быстренько дискаверим, как должен выглядеть список товаров. Пока пофиг на фильтры и поиск. И пофиг что будет не идеально. Посмотрим вживую, потом поправим.
1️⃣ спринт — разработаем список товаров без поиска и фильтрации. Параллельно будем дискаверить фильтры и поиск.
К концу спринта смотрим, как выглядит вживую список товаров. Даем команде обратную связь, чтобы учесть правки в следующем спринте, либо отложить их на конец.
2️⃣ спринт — приделаем фильтры и поиск. А дискавери работает на следующий спринт: как должна выглядеть корзина.
3️⃣ спринт — сделаем корзину и возможность добавлять туда товары. Параллельно дискаверим оплату.
4️⃣ спринт — сделаем процесс оплаты на моках, и только успешный сценарий, без корнер-кейсов, неудачной оплаты и возвратов.
…
И так далее — до момента, когда уже можно релизить.
Да, нет смысла катить на пользователя экран со списком товаров без возможности поиска.
Но есть смысл декомпозировать MVP на мелкие User Story не больше 2 недель в разработке. И одной из таких User Story может быть «видеть список всех товаров».
Так мы решаем сразу обе проблемы:
— Нафакапиться по срокам на коротком отрезке сложнее. А в случае, если сроки поехали — мы узнаем об этом через 2 недели, а не через 3 месяца, и сможем своевременно отреагировать.
— Можно будет регулярно смотреть на прогресс. Видеть, как из кубиков строится наш MVP. Во время лайв-демо понимать, как оно выглядит для конечного пользователя и корректировать в следующих итерациях.
Я призываю продактов помогать командам декомпозировать User Story на более мелкие, даже если катить на пользователя еще рано.
Почитать больше можно в статье Кента Макдональда.
Давайте представим, что мы делаем некий MVP. На дискавери потрачено 3 месяца. Скоуп определен, дизайны отрисованы и требования подробно описаны. На разработку заложено еще 3 месяца. Катить на пользователей что-то меньшее, чем этот скоуп — бессмысленно. Например, зачем видеть список товаров, если корзины нет и оплатить невозможно.
Итак, тз описано и срок в три месяца на разработку начал тикать.
Продакт может отойти и не мешать. Ведь никто не любит, когда заглядывают за плечо и спрашивают «ну когда». А он же хороший руководитель и доверяет своей команде!
…
Следующий кадр: прошло 3 месяца, продакт смотрит, что получилось.
А получилось, что параллельно делали всё, закопались и ни один сценарий целиком не успели.
Команда говорит, что показать промежуточный результат не могут и нужен еще 1 месяц.
А через месяц нужен еще 1 месяц.
В итоге через 5 месяцев сдают проект. И вроде бы всё по тз, но «не то».
«Программисты виноваты!» — скажете вы.
«Какое тз, такой и результат!» — ответят программисты.
Всем плохо: программисты без премии, продакт с кривым MVP, которое уже никому не нужно.
Можно ли было помочь и команде и продакту? — Да!
Очень часто в продуктовой разработке мы изобретаем водопадные процессы.
Долго и тщательно дискаверим, по мере уточнения требований предполагаемый срок деливери увеличивается.
В итоге пилим проект, размером в квартал/полугодие/год.
А чем дольше горизонт планирования, тем больше вероятность не попасть в оценки.
Поэтому есть простое решение, как лучше попадать в сроки и делать «то», благодаря более частой обратной связи:
Вместо долгого дискавери, мелко декомпозировать и начинать деливери.
А параллельно доделывать дискавери по другим частям.
Вот как мог бы выглядеть процесс разработки нашего MVP по спринтам:
0️⃣ — Для старта проекта нам нужно хоть какое-то описание первой функции. Быстренько дискаверим, как должен выглядеть список товаров. Пока пофиг на фильтры и поиск. И пофиг что будет не идеально. Посмотрим вживую, потом поправим.
1️⃣ спринт — разработаем список товаров без поиска и фильтрации. Параллельно будем дискаверить фильтры и поиск.
К концу спринта смотрим, как выглядит вживую список товаров. Даем команде обратную связь, чтобы учесть правки в следующем спринте, либо отложить их на конец.
2️⃣ спринт — приделаем фильтры и поиск. А дискавери работает на следующий спринт: как должна выглядеть корзина.
3️⃣ спринт — сделаем корзину и возможность добавлять туда товары. Параллельно дискаверим оплату.
4️⃣ спринт — сделаем процесс оплаты на моках, и только успешный сценарий, без корнер-кейсов, неудачной оплаты и возвратов.
…
И так далее — до момента, когда уже можно релизить.
Да, нет смысла катить на пользователя экран со списком товаров без возможности поиска.
Но есть смысл декомпозировать MVP на мелкие User Story не больше 2 недель в разработке. И одной из таких User Story может быть «видеть список всех товаров».
Так мы решаем сразу обе проблемы:
— Нафакапиться по срокам на коротком отрезке сложнее. А в случае, если сроки поехали — мы узнаем об этом через 2 недели, а не через 3 месяца, и сможем своевременно отреагировать.
— Можно будет регулярно смотреть на прогресс. Видеть, как из кубиков строится наш MVP. Во время лайв-демо понимать, как оно выглядит для конечного пользователя и корректировать в следующих итерациях.
Я призываю продактов помогать командам декомпозировать User Story на более мелкие, даже если катить на пользователя еще рано.
Почитать больше можно в статье Кента Макдональда.
21_шаблон_декомпозиции_пользовательских_историй.pdf
5.2 MB
Презентация к посту выше — «Как и зачем декомпозировать User story — 21 шаблон».
Иногда кажется, что декомпозировать юзер стори уже некуда. В таком случае идеи можно почерпнуть из презентации в аттаче — 21 шаблон декомпозиции пользовательских историй. Там можно найти лайфхаки, по типу «сделать сначала короткий успешный сценарий, а затем негативные и корнер-кейсы».
Это перевод презентации из статьи Кента Макдональда. Перевод за авторством группы ребят, среди которых Сергей Кузин — Agile коуч всея Авито, и с его разрешения публикую эту презентацию.
Иногда кажется, что декомпозировать юзер стори уже некуда. В таком случае идеи можно почерпнуть из презентации в аттаче — 21 шаблон декомпозиции пользовательских историй. Там можно найти лайфхаки, по типу «сделать сначала короткий успешный сценарий, а затем негативные и корнер-кейсы».
Это перевод презентации из статьи Кента Макдональда. Перевод за авторством группы ребят, среди которых Сергей Кузин — Agile коуч всея Авито, и с его разрешения публикую эту презентацию.
Про баланс в работе продакта
Каждая компания по-своему понимает роль продакта, но от любого продакта постоянно все чего-то хотят 🙂
Бывает, что продакт-менеджер становится дискавери-менеджером. Всё время тратит на распределение работы по аналитике и исследованиям, выверяет метрики, формирует гипотезы.
При этом деливери расценивает как внутренний аутсорс:
— «сгружает» эпики размером в квартал без декомпозиции на User Story
— не ходит на планирования, PBR, дейлики
— не интересуется результатом на ревью спринта, не дает обратную связь
— не доносит команде ценность для бизнеса и эффект от фич
Так продакт теряет роль Product Owner.
Бывает и обратная ситуация: продакт руководит командой разработки вместо тимлида, при этом упуская метрики, аналитику и ux-исследования.
Специально привёл две крайности. Но на самом деле продакту очень легко что-то упустить в своей работе.
Ангелина Зинченко из Авито написала статью «Как продакту выстраивать коммуникацию со стейкхолдерами и командой»
В ней она приводит примеры ошибок и хороших практик для продактов в разных аспектах работы:
— с дискавери командой
— с деливери командой
— с маркетингом, отделом продаж
— с клиентской и технической поддержкой
— с руководителем, СРО, СЕО или инвестором
Советую к прочтению, своим продактам тоже скину. Они очень хорошие!
Но мне кажется, что в статье каждый может узнать себя в одном из пунктов 🙂
Каждая компания по-своему понимает роль продакта, но от любого продакта постоянно все чего-то хотят 🙂
Бывает, что продакт-менеджер становится дискавери-менеджером. Всё время тратит на распределение работы по аналитике и исследованиям, выверяет метрики, формирует гипотезы.
При этом деливери расценивает как внутренний аутсорс:
— «сгружает» эпики размером в квартал без декомпозиции на User Story
— не ходит на планирования, PBR, дейлики
— не интересуется результатом на ревью спринта, не дает обратную связь
— не доносит команде ценность для бизнеса и эффект от фич
Так продакт теряет роль Product Owner.
Бывает и обратная ситуация: продакт руководит командой разработки вместо тимлида, при этом упуская метрики, аналитику и ux-исследования.
Специально привёл две крайности. Но на самом деле продакту очень легко что-то упустить в своей работе.
Ангелина Зинченко из Авито написала статью «Как продакту выстраивать коммуникацию со стейкхолдерами и командой»
В ней она приводит примеры ошибок и хороших практик для продактов в разных аспектах работы:
— с дискавери командой
— с деливери командой
— с маркетингом, отделом продаж
— с клиентской и технической поддержкой
— с руководителем, СРО, СЕО или инвестором
Советую к прочтению, своим продактам тоже скину. Они очень хорошие!
Но мне кажется, что в статье каждый может узнать себя в одном из пунктов 🙂
vc.ru
Нормально делай, нормально будет — как продакту выстраивать коммуникацию со стейкхолдерами и командой — Личный опыт на vc.ru
Авито Личный опыт28 мар
ProductCamp — в следующие выходные!
Когда я что-то рекламирую, стараюсь чтобы это было полезно и бесплатно. Тут два в одном!
По поводу ProductCamp я спросил мнения нашего продакт-кластер-лида:
— Они хорошие, я и выступал когда-то там и участвую во многих конфах. Нетворк прекрасно выстроен.
Потом я посмотрел темы докладов и мне откликнулись:
— 5 факапов, которые сделали меня директором по продукту (Ксюша Стрельникова, Райффайзенбанк, Директор по продукту)
— Когнитивные ошибки в продакт менеджменте (Иван Меркурьев, Яндекс, Менеджер проектов)
— 15 Soft Skills менеджера продукта и как их качать на самом деле (ex Head of product developmet MTS, exYandex, exTinkoff) (Сергей Паращенко, Product Vision, Директор по образовательным продуктам)
— Выгореть, выжить, вернуться: от убивающей продуктивности к эффективной (Анна Динельт, Яндекс Афиша, Руководитель продукта)
———
На это мероприятие невозможно купить билет, на него можно попасть только в качестве волонтёра или спикера. Мероприятие создают сами участники.
Чтобы присоединится, нужно заполнить форму на сайте ProductCamp. Там же можно зарегистрироваться на онлайн.
Когда: 19-21 апреля
Где: Парк-отель «Ареал» и онлайн на ProductLand
Реклама. ООО "Глобалкэмп". ИНН 7806594627. erid LjN8KKtRL
Когда я что-то рекламирую, стараюсь чтобы это было полезно и бесплатно. Тут два в одном!
По поводу ProductCamp я спросил мнения нашего продакт-кластер-лида:
— Они хорошие, я и выступал когда-то там и участвую во многих конфах. Нетворк прекрасно выстроен.
Потом я посмотрел темы докладов и мне откликнулись:
— 5 факапов, которые сделали меня директором по продукту (Ксюша Стрельникова, Райффайзенбанк, Директор по продукту)
— Когнитивные ошибки в продакт менеджменте (Иван Меркурьев, Яндекс, Менеджер проектов)
— 15 Soft Skills менеджера продукта и как их качать на самом деле (ex Head of product developmet MTS, exYandex, exTinkoff) (Сергей Паращенко, Product Vision, Директор по образовательным продуктам)
— Выгореть, выжить, вернуться: от убивающей продуктивности к эффективной (Анна Динельт, Яндекс Афиша, Руководитель продукта)
———
На это мероприятие невозможно купить билет, на него можно попасть только в качестве волонтёра или спикера. Мероприятие создают сами участники.
Чтобы присоединится, нужно заполнить форму на сайте ProductCamp. Там же можно зарегистрироваться на онлайн.
Когда: 19-21 апреля
Где: Парк-отель «Ареал» и онлайн на ProductLand
Реклама. ООО "Глобалкэмп". ИНН 7806594627. erid LjN8KKtRL
Топ постов в этом канале для 10.000 подписчиков! 🥳
Привет, десять тысяч подписчиков! Это отличный повод обновить интро, и добавить в него полезностей.
Канал — о продуктовой разработке изнутри, глазами инженера.
Меня зовут Никита Хромушкин, и я инжиниринг мемеджер в Авито.
В душе я все еще инженер, хотя в трудовой — Head of Development of AvitoID unit.
В 2023 переехал в Испанию и стал отцом.
@sharelocations — лайв-канал про всякое личное, он еще совсем малыш, но туда тоже можно подписаться :)
Сюда пишу обычно лонгриды, стабильного графика постов и контент-плана не имею.
Однако, если здесь появляется пост — то о чем-то стоящем: про образ мышления, роли, процессы, события и артефакты продуктовой разработки.
Иногда про участников процесса. Иногда про найм с обеих сторон.
Изначально завел канал, чтобы формулировать свои идеи и доносить их в свою команду. С тех пор аудитория расширилась, но основная концепция осталась.
Канал призван приносить пользу.
Основная метрика, в которую целюсь — количество репостов.
Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими.
🎉 Давайте отметим 10к подписчиков топом полезных постов! 🎉
1️⃣ — О чем спросить будущего работодателя — чеклист, собрал 1к+ репостов и 15к просмотров. Чеклист мы делали вживую на круглом столе на Podlodka Teamlead Crew. Вложились Евгений Кателла, Евгений Антонов и Татьяна Аква, я был в роли ведущего.
2️⃣ — Digital Nomad в Испании — 266 репостов и 9.3к просмотров. Забавное из обсуждения поста в одном там чате: «История лютая, ппц. На большом сроке решиться на такую авантюру. Если б что не так, то сидели бы они в миграционной тюрьме с марроканцами». Это байопик нашего переезда в Испанию на машине, первый и единственный lifestyle-пост. Тем не менее, и он оказался полезным: в нем ссылки на базу знаний на Notion, которой я пользовался при подготовке документов.
3️⃣ — Как мы готовим задачи к спринту, поделились 86 раз и посмотрели 3,1к человек. Этот пост про то, что процесс подготовки задачи к разработке тоже можно структурировать и описать. В эту же тему будет ранний пост про Dual-track development. У канала тогда было 100 подписчиков, я работал в QIWI, но уже тырил лучшие практики из Авито 🙂
4️⃣ — Как и зачем декомпозировать User Story + 21 шаблон декомпозиции, вдвоем набрали 244 репоста и 4.2к просмотров. Эти посты про то, как декомпозировать недекомпозируемое. Могут помочь продактам/бизнес-аналитикам и командам делать более частые и маленькие инкременты и быстрее получать обратную связь.
5️⃣ — Как понять, в ту ли сторону ты развиваешься, чтобы получить повышение? + Windrose template для собственного развития — вдвоем набрали 218 репостов и 7,5к просмотров. Это про Авитошную матрицу компетенций. Если у вас в компании нет матрицы, а решения о промо принимаются на уровне команды, то можно позаимствовать матрицу Авито и использовать её внутри своей команды.
6️⃣ — Серия из 3 постов Как мы команду делили + Как мы провели Kick-off за 8 часов и какие вынесли уроки — вся серия набрала 305 репостов и 27,1к просмотров. Полезно, если у вас команда предельного размера (~9+ человек) и связанные с этим страдания — долгие стендапы, грумминги, общий расфокус, и невозможность уследить за всем что происходит.
7️⃣ — SMS Two factor auth — плохая практика и серия постов про альтернативы, заканчивающаяяся постом про Будущее аутентификации в вебе — вся серия набрала 206 репостов и 13.5к просмотров
===
В конце поделюсь ранним творчеством:
8️⃣ — StarMap — карта компетенций команды — если нужно собрать воедино картинку: кто что знает, чему готов научить и чему хочет учиться. Поможет обнаружить низкий бас-фактор или недостаточность экспертизы для каких-то фич.
9️⃣ — Чеклист Definition Of Done — Как всем одинаково понять, что задача сделана.
🔟 — Чеклист Definition Of Ready (for Sprint) — Как понять, что задача проработана.
Верю, что один из этих постов окажется для вас полезным.
Добро пожаловать, или снова здравствуйте!👋
Привет, десять тысяч подписчиков! Это отличный повод обновить интро, и добавить в него полезностей.
Канал — о продуктовой разработке изнутри, глазами инженера.
Меня зовут Никита Хромушкин, и я инжиниринг мемеджер в Авито.
В душе я все еще инженер, хотя в трудовой — Head of Development of AvitoID unit.
В 2023 переехал в Испанию и стал отцом.
@sharelocations — лайв-канал про всякое личное, он еще совсем малыш, но туда тоже можно подписаться :)
Сюда пишу обычно лонгриды, стабильного графика постов и контент-плана не имею.
Однако, если здесь появляется пост — то о чем-то стоящем: про образ мышления, роли, процессы, события и артефакты продуктовой разработки.
Иногда про участников процесса. Иногда про найм с обеих сторон.
Изначально завел канал, чтобы формулировать свои идеи и доносить их в свою команду. С тех пор аудитория расширилась, но основная концепция осталась.
Канал призван приносить пользу.
Основная метрика, в которую целюсь — количество репостов.
Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими.
🎉 Давайте отметим 10к подписчиков топом полезных постов! 🎉
1️⃣ — О чем спросить будущего работодателя — чеклист, собрал 1к+ репостов и 15к просмотров. Чеклист мы делали вживую на круглом столе на Podlodka Teamlead Crew. Вложились Евгений Кателла, Евгений Антонов и Татьяна Аква, я был в роли ведущего.
2️⃣ — Digital Nomad в Испании — 266 репостов и 9.3к просмотров. Забавное из обсуждения поста в одном там чате: «История лютая, ппц. На большом сроке решиться на такую авантюру. Если б что не так, то сидели бы они в миграционной тюрьме с марроканцами». Это байопик нашего переезда в Испанию на машине, первый и единственный lifestyle-пост. Тем не менее, и он оказался полезным: в нем ссылки на базу знаний на Notion, которой я пользовался при подготовке документов.
3️⃣ — Как мы готовим задачи к спринту, поделились 86 раз и посмотрели 3,1к человек. Этот пост про то, что процесс подготовки задачи к разработке тоже можно структурировать и описать. В эту же тему будет ранний пост про Dual-track development. У канала тогда было 100 подписчиков, я работал в QIWI, но уже тырил лучшие практики из Авито 🙂
4️⃣ — Как и зачем декомпозировать User Story + 21 шаблон декомпозиции, вдвоем набрали 244 репоста и 4.2к просмотров. Эти посты про то, как декомпозировать недекомпозируемое. Могут помочь продактам/бизнес-аналитикам и командам делать более частые и маленькие инкременты и быстрее получать обратную связь.
5️⃣ — Как понять, в ту ли сторону ты развиваешься, чтобы получить повышение? + Windrose template для собственного развития — вдвоем набрали 218 репостов и 7,5к просмотров. Это про Авитошную матрицу компетенций. Если у вас в компании нет матрицы, а решения о промо принимаются на уровне команды, то можно позаимствовать матрицу Авито и использовать её внутри своей команды.
6️⃣ — Серия из 3 постов Как мы команду делили + Как мы провели Kick-off за 8 часов и какие вынесли уроки — вся серия набрала 305 репостов и 27,1к просмотров. Полезно, если у вас команда предельного размера (~9+ человек) и связанные с этим страдания — долгие стендапы, грумминги, общий расфокус, и невозможность уследить за всем что происходит.
7️⃣ — SMS Two factor auth — плохая практика и серия постов про альтернативы, заканчивающаяяся постом про Будущее аутентификации в вебе — вся серия набрала 206 репостов и 13.5к просмотров
===
В конце поделюсь ранним творчеством:
8️⃣ — StarMap — карта компетенций команды — если нужно собрать воедино картинку: кто что знает, чему готов научить и чему хочет учиться. Поможет обнаружить низкий бас-фактор или недостаточность экспертизы для каких-то фич.
9️⃣ — Чеклист Definition Of Done — Как всем одинаково понять, что задача сделана.
🔟 — Чеклист Definition Of Ready (for Sprint) — Как понять, что задача проработана.
Верю, что один из этих постов окажется для вас полезным.
Добро пожаловать, или снова здравствуйте!👋
Telegram
Product Developer
О чем спросить работодателя — чеклист
Новый сотрудник — всегда двусторонняя инвестиция:
— компания инвестирует деньги в собеседования, оформление, технику, зарплату сотрудника, его руководителя и бадди
— руководитель и коллеги вкладывают в новичка свое…
Новый сотрудник — всегда двусторонняя инвестиция:
— компания инвестирует деньги в собеседования, оформление, технику, зарплату сотрудника, его руководителя и бадди
— руководитель и коллеги вкладывают в новичка свое…
Product Developer pinned «Топ постов в этом канале для 10.000 подписчиков! 🥳 Привет, десять тысяч подписчиков! Это отличный повод обновить интро, и добавить в него полезностей. Канал — о продуктовой разработке изнутри, глазами инженера. Меня зовут Никита Хромушкин, и я инжиниринг…»
Четырехдневка, доступная каждому
… за которую еще и доплатят 🙂
Кто-то мог подумать, что я начинаю агрессивно хантить людей. Но нет, я пришел рассказать про концепцию, к которой пришел сам (но наверняка был не первым)
Итак, если:
1. Хотите попробовать четырехдневную рабочую неделю
2. При этом сохранить погружение в контекст, ходить на планирования по понедельникам и ретроспективы по пятницам
3. Работаете итерациями в 2+ недели
4. Готовы потратить несколько отпускных дней чтобы поднабраться сил
То представляю вам уникальный авторский концепт:
Отпуск с пятницы по понедельник в середине спринта
* имеются противопоказания, проконсультируйтесь с руководителем
Так вы не пропустите мероприятия начала и конца спринта, и не будете выпадать надолго. Но получите 4 рабочих дня, за которыми следуют 4 выходных, и затем еще 4 рабочих.
Это гораздо лучше последней «четырехдневки» 12 июня, когда разрыв контекста произошел посередине недели. Следующие два дня ушли на восстановление работы, а затем опять выходные.
Писать ли отпуск на выходные — по желанию и согласованию с компанией. Если у вас накопилось 20+ дней отпуска — это отличный способ обналичить отпускные. Но если вы копите отпускные, то можно и не писать. Можно просто в пятницу и понедельник.
Концепт крайне рекомендован тем, кто подвыгорел и не может уйти в отпуск, потому что все развалится. За один день в неделю не развалится.
Всем своим многоотпускникам советую, и вы попробуйте!
==============
P.S. Обращение к ребятам, кто копит, «инвестирует» свои отпускные дни.
На первый взгляд, тратить их не выгодно: если сейчас дадут повышение зарплаты, то через год за день отпуска заплатят больше.
Но это только на первый взгляд.
Во-первых, за год инфляция съест этот прирост, а вам дадут еще одно повышение зарплаты.
Во-вторых, повышение зп чаще получают те, кто хорошо отдыхает и продуктивно работает.
Поэтому потратить отпускные дни = инвестировать в себя.
А копить отпуск = продавать свое здоровье по цене отпускного дня.
Сходите уже отдохнуть.
… за которую еще и доплатят 🙂
Кто-то мог подумать, что я начинаю агрессивно хантить людей. Но нет, я пришел рассказать про концепцию, к которой пришел сам (но наверняка был не первым)
Итак, если:
1. Хотите попробовать четырехдневную рабочую неделю
2. При этом сохранить погружение в контекст, ходить на планирования по понедельникам и ретроспективы по пятницам
3. Работаете итерациями в 2+ недели
4. Готовы потратить несколько отпускных дней чтобы поднабраться сил
То представляю вам уникальный авторский концепт:
Отпуск с пятницы по понедельник в середине спринта
* имеются противопоказания, проконсультируйтесь с руководителем
Так вы не пропустите мероприятия начала и конца спринта, и не будете выпадать надолго. Но получите 4 рабочих дня, за которыми следуют 4 выходных, и затем еще 4 рабочих.
Это гораздо лучше последней «четырехдневки» 12 июня, когда разрыв контекста произошел посередине недели. Следующие два дня ушли на восстановление работы, а затем опять выходные.
Писать ли отпуск на выходные — по желанию и согласованию с компанией. Если у вас накопилось 20+ дней отпуска — это отличный способ обналичить отпускные. Но если вы копите отпускные, то можно и не писать. Можно просто в пятницу и понедельник.
Концепт крайне рекомендован тем, кто подвыгорел и не может уйти в отпуск, потому что все развалится. За один день в неделю не развалится.
Всем своим многоотпускникам советую, и вы попробуйте!
==============
P.S. Обращение к ребятам, кто копит, «инвестирует» свои отпускные дни.
На первый взгляд, тратить их не выгодно: если сейчас дадут повышение зарплаты, то через год за день отпуска заплатят больше.
Но это только на первый взгляд.
Во-первых, за год инфляция съест этот прирост, а вам дадут еще одно повышение зарплаты.
Во-вторых, повышение зп чаще получают те, кто хорошо отдыхает и продуктивно работает.
Поэтому потратить отпускные дни = инвестировать в себя.
А копить отпуск = продавать свое здоровье по цене отпускного дня.
Сходите уже отдохнуть.
Что такое Data-driven принятие решений
Одним предложением — это процесс принятия продуктовых и бизнесовых решений, основанных на конкретных оценках и измерениях.
Разберем на примере Авито. На картинке — один из тысяч A/Б-тестов в нашей «АБшнице».
Изменение десятой доли процента любой метрики может привести как к повышению доходов, так и к потерям. Поэтому, раскатывая новый интерфейс в личном кабинете, мы предварительно проводим цепочку А/Б-тестов.
Так мы узнаем точно, сколько людей от нас уйдет из-за изменения, а сколько начнет пользоваться продуктом чаще. Видя все числа перед глазами, бизнес принимает решения точнее и легче. Эффект «экспертного» мнения и зависимость от компетенций конкретного менеджера не исчезает, но сводится к минимуму.
Все раскатки и принимаемые решения должны иметь под собой числовое обоснование. Где-то это маркетсайзинг, где-то конкретные А/Б-тесты и исследования поведения пользователей. Все сильно зависит от этапа развития, на котором находится конкретная гипотеза или идея.
Рассказывая о прогрессе заказчикам, вы обязательно получите вопросы: «что это дало?», «какой был отток?», «какой ещё потенциал у этой фичи?». Наша внутренняя культура позволяет любому задавать такие вопросы и готовит всех относиться к ним с благодарностью.
Основные плюсы data-driven культуры:
— Решения принимаются точнее, компания легче отказывается от бесполезных идей и поддерживает полезные
— Снижается зависимость от «экспертного» мнения, компания чуть лучше защищена от некомпетентных менеджеров
— Развивается культура «экологичного» челленджа, повышается прозрачность принимаемых решений
Однако, конечно, у такого подхода есть ряд минусов:
— Команды могут начать перестраховываться — появляется «аналитический паралич», из-за чего ухудшается ТТМ
— Некоторым менеджерам становится труднее принимать решения, когда результаты теста не однозначные
… и ограничений:
— Компании нужно развивать аналитические компетенции в большом объеме — это дорого
— Нужно строить инфраструкту данных и развивать data-инженерные компетенции — это дорого и сложно
Последнее здесь стоит особняком: без данных — нет аналитики и не будет никакой культуры. Именно с этого надо начать и в это нужно проинвестировать, если вы хотите достичь data-зрелости в принимаемых решениях.
Это был гостевой пост Алексея Малинского, руководителя категорийной аналитики в Авито Товарах.
Больше постов про аналитику — Avito Data Tech
Одним предложением — это процесс принятия продуктовых и бизнесовых решений, основанных на конкретных оценках и измерениях.
Разберем на примере Авито. На картинке — один из тысяч A/Б-тестов в нашей «АБшнице».
Изменение десятой доли процента любой метрики может привести как к повышению доходов, так и к потерям. Поэтому, раскатывая новый интерфейс в личном кабинете, мы предварительно проводим цепочку А/Б-тестов.
Так мы узнаем точно, сколько людей от нас уйдет из-за изменения, а сколько начнет пользоваться продуктом чаще. Видя все числа перед глазами, бизнес принимает решения точнее и легче. Эффект «экспертного» мнения и зависимость от компетенций конкретного менеджера не исчезает, но сводится к минимуму.
Все раскатки и принимаемые решения должны иметь под собой числовое обоснование. Где-то это маркетсайзинг, где-то конкретные А/Б-тесты и исследования поведения пользователей. Все сильно зависит от этапа развития, на котором находится конкретная гипотеза или идея.
Рассказывая о прогрессе заказчикам, вы обязательно получите вопросы: «что это дало?», «какой был отток?», «какой ещё потенциал у этой фичи?». Наша внутренняя культура позволяет любому задавать такие вопросы и готовит всех относиться к ним с благодарностью.
Основные плюсы data-driven культуры:
— Решения принимаются точнее, компания легче отказывается от бесполезных идей и поддерживает полезные
— Снижается зависимость от «экспертного» мнения, компания чуть лучше защищена от некомпетентных менеджеров
— Развивается культура «экологичного» челленджа, повышается прозрачность принимаемых решений
Однако, конечно, у такого подхода есть ряд минусов:
— Команды могут начать перестраховываться — появляется «аналитический паралич», из-за чего ухудшается ТТМ
— Некоторым менеджерам становится труднее принимать решения, когда результаты теста не однозначные
… и ограничений:
— Компании нужно развивать аналитические компетенции в большом объеме — это дорого
— Нужно строить инфраструкту данных и развивать data-инженерные компетенции — это дорого и сложно
Последнее здесь стоит особняком: без данных — нет аналитики и не будет никакой культуры. Именно с этого надо начать и в это нужно проинвестировать, если вы хотите достичь data-зрелости в принимаемых решениях.
Это был гостевой пост Алексея Малинского, руководителя категорийной аналитики в Авито Товарах.
Больше постов про аналитику — Avito Data Tech
Forwarded from MADs
Всем привеееет! 😃
Каждую пятницу в Mad Brains проходят «Техно» — митапы, где наши сотрудники и друзья компании выступают с докладами.
💪 В этот раз к нам пришел Никита из «Авито», технический руководитель юнита Avito ID и автор крутого блога о продуктовой разработке изнутри Product Develоper.
👀 Скорей смотри ролик, в нем Никита рассказывает про боли авторизации, ее факторы и светлое будущее, которое не за горами.
#madbrains_tekhno
Каждую пятницу в Mad Brains проходят «Техно» — митапы, где наши сотрудники и друзья компании выступают с докладами.
💪 В этот раз к нам пришел Никита из «Авито», технический руководитель юнита Avito ID и автор крутого блога о продуктовой разработке изнутри Product Develоper.
#madbrains_tekhno
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Авторизация — это больше, чем логин/пароль | Mad Brains Техно
В докладе Никита Хромушкин, технический руководитель юнита Avito ID, рассказал о том, почему идентификацию, авторизацию, аутентификацию часто путают. Почему пароли — это боль и какие альтернативные решения придут в скором будущем.
Техно — это внутренний…
Техно — это внутренний…
Авторизация — больше чем логин/пароль
^^ К репосту выше ^^
Не так давно я оформил серию постов про альтернативы 2fa в презентацию и выступил первый раз за 2 года.
Спасибо ребятам из Mad Brains, что позвали.
И отдельное спасибо за то, что смонтировали видос.
А серия постов тут, начинается с «SMS — плохой способ 2fa».
Так может и выступать начну опять.
^^ К репосту выше ^^
Не так давно я оформил серию постов про альтернативы 2fa в презентацию и выступил первый раз за 2 года.
Спасибо ребятам из Mad Brains, что позвали.
И отдельное спасибо за то, что смонтировали видос.
А серия постов тут, начинается с «SMS — плохой способ 2fa».
Так может и выступать начну опять.
Telegram
Product Developer
SMS Two factor auth — плохая практика
…но всё еще самая распространенная
Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление.…
…но всё еще самая распространенная
Во многих продуктах номер телефона — ключевой идентификатор пользователя и на него завязаны критичные сценарии. Так и в Авито: без номера телефона нельзя ни войти, ни разместить объявление.…