Каково это — приходить сразу тимлидом на новое место
Стать тимлидом изнутри в каком-то смысле проще: ты всё знаешь внутри компании, тебя все знают.
А вот прийти снаружи сразу на менеджерскую позицию — целый квест.
0. Как выбрать нового работодателя, если ты тимлид?
В разных компаниях разные ожидания от тимлида и разные процессы. Никому не хочется попасть в место, где от тебя ожидают 80% управления людьми и 80% кодинга.
1. Вдруг команда не примет?
Моего предшественника в Райфе ребята выперли в первый месяц 🙂
Мне повезло больше, но что в этом помогло? Что именно я сделал правильно?
2. Или не сможешь разобраться, как тут всё устроено?
В корпорациях бывает так, что размывается ответственность между командами и часто нет единого источника знаний. Приходится выкручивать проактивность на максимум. Как выстроить приоритет для потребления информации?
3. Или не оправдаешь ожиданий руководителя?
После выхода на работу в Авито мне нужно было сразу построить планы на квартал для команды, а критериями ИС было выполнение этих планов. А еще выполнение 90% целей спринтов и не более 20% Scope Drop.
Я прошел через онбординг тимлидом в новую компанию. А теперь делаю про это сезон Podlodka Teamlead Crew в составе программного комитета.
Стартуем 7 ноября. Онлайн. Сессии в 10 и в 19 по Москве.
Лендос про конференцию и кнопка «Купить билет»
Кстати, о чем бы вы спросили будущего работодателя?
Пишите в комментах и получите бесплатную проходку на конфу.
Стать тимлидом изнутри в каком-то смысле проще: ты всё знаешь внутри компании, тебя все знают.
А вот прийти снаружи сразу на менеджерскую позицию — целый квест.
0. Как выбрать нового работодателя, если ты тимлид?
В разных компаниях разные ожидания от тимлида и разные процессы. Никому не хочется попасть в место, где от тебя ожидают 80% управления людьми и 80% кодинга.
1. Вдруг команда не примет?
Моего предшественника в Райфе ребята выперли в первый месяц 🙂
Мне повезло больше, но что в этом помогло? Что именно я сделал правильно?
2. Или не сможешь разобраться, как тут всё устроено?
В корпорациях бывает так, что размывается ответственность между командами и часто нет единого источника знаний. Приходится выкручивать проактивность на максимум. Как выстроить приоритет для потребления информации?
3. Или не оправдаешь ожиданий руководителя?
После выхода на работу в Авито мне нужно было сразу построить планы на квартал для команды, а критериями ИС было выполнение этих планов. А еще выполнение 90% целей спринтов и не более 20% Scope Drop.
Я прошел через онбординг тимлидом в новую компанию. А теперь делаю про это сезон Podlodka Teamlead Crew в составе программного комитета.
Стартуем 7 ноября. Онлайн. Сессии в 10 и в 19 по Москве.
Лендос про конференцию и кнопка «Купить билет»
Кстати, о чем бы вы спросили будущего работодателя?
Пишите в комментах и получите бесплатную проходку на конфу.
podlodka.io
Онлайн-конференция Podlodka Teamlead Crew, сезон #16
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам тимлидства, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
👍10❤7🔥4👎2
Итоги года
В прошлом году был пост Data-driven итоги года.
В этом году будет безdata’ый пост)
Год удивлений, потрясений и непредсказуемых событий.
Тем не менее, хочу зафиксировать факты для истории.
1. В марте перешел в Авито тимлидом команды из 6 инженеров. Прошел для этого 5 интервью. Получил оценки senior на алгоритмах и systems design. Получил пару желтых флагов на менеджерской секции: у меня не было опыта средне- и долгосрочное планирования и проведения перформанс ревью. Буквально в первые недели работы появилась возможность этот опыт получить: составил роадмап проекта на год и провел перфревью для команды.
2. К июню собрал большую команду. Провел разделение на две не такие большие. Донабрал людей. Всего за год провел около 90 интервью. Сейчас в сумме 17 инженеров работают над общим проектом, который перевернет парадигму работы с профилями и авторизацией. В январе будет закрытый альфа-тест. Если хотите попробовать и дать первую обратную связь — нам это очень поможет.
3. Стал техническим руководителем юнита из трех команд. Если вы не можете зарегистрироваться, войти или восстановить доступ, либо если у вас не привязывается телефон — значит, мы что-то сломали и отвечать за это мне 🙂
4. Переехал в Грузию, живем в доме с бывалым тимлидом первой команды, из которой вырос весь юнит. Это удобно для работы, но так работа проникает слишком сильно в мою жизнь.
5. Меня как тимлида не хватало на две команды. Поэтому обосновал необходимость найма, составил профиль кандидата, провел 15 интервью и 23 декабря вывел тимлида во вторую команду. Уделил мало внимания онбордингу в прошедшую первую неделю нового тимлида. Обещаю исправиться в следующем году. Начну с того, что составлю полноценный чеклист онбординга.
6. Помог инженеру вырасти в тимлида в третьей команде. Эта команда — моя гордость. Сразу после формирования команды ребята нашли общий язык и вышли на перформинг. Поэтому рост изнутри в этом случае — гораздо лучше, чем внешний найм. Таким образом не меняется состав команды, а инженер, которого команда авторизовала как лидера, становится им.
7. Провёл две тимлидских подлодки в составе программного комитета. Тема первой — change management. Тема второй — переход тимлида в другую компанию. Обе темы мне очень близки и вложился как мог. Горжусь сессией «как тимлиду собеседовать работодателя». Даю ссылку на канал Жени Антонова, потому что ему можно выкладывать запись сессии в паблик 🙂 Ну и потому что хороший канал, чего уж.
8. Сходил на подкаст DevOne к бывшим коллегам. Поболтали про T-Shape. Рассказал о том, как матрица компетенций Авито ожидает T-Shape от E5+ (сеньор) инженера.
Итог и пожелания
В прошлом году я пожелал вам грести целенаправленно, а не плыть по течению. Составлять план развития, идти по нему.
В этом году у меня был план, но не план профессионального развития, а план действий в изменяющихся внешних условиях. В какой момент, как и куда поехать. Что делать с ипотекой. Как обеспечить себя и семью на новом месте.
Трудно было всем, но я заметил что проще иметь четкое понимание, какими будут твои действия при каком развитии событий.
А в профессиональном плане я скорее плыл по течению и подгребал, когда были силы. Получилось неплохо, даже лучше ожиданий. В профессиональном плане.
Желаю каждому иметь план действий и критерии применения. Тогда будет место в голове для мыслей о профессиональном развитии.
В прошлом году был пост Data-driven итоги года.
В этом году будет безdata’ый пост)
Год удивлений, потрясений и непредсказуемых событий.
Тем не менее, хочу зафиксировать факты для истории.
1. В марте перешел в Авито тимлидом команды из 6 инженеров. Прошел для этого 5 интервью. Получил оценки senior на алгоритмах и systems design. Получил пару желтых флагов на менеджерской секции: у меня не было опыта средне- и долгосрочное планирования и проведения перформанс ревью. Буквально в первые недели работы появилась возможность этот опыт получить: составил роадмап проекта на год и провел перфревью для команды.
2. К июню собрал большую команду. Провел разделение на две не такие большие. Донабрал людей. Всего за год провел около 90 интервью. Сейчас в сумме 17 инженеров работают над общим проектом, который перевернет парадигму работы с профилями и авторизацией. В январе будет закрытый альфа-тест. Если хотите попробовать и дать первую обратную связь — нам это очень поможет.
3. Стал техническим руководителем юнита из трех команд. Если вы не можете зарегистрироваться, войти или восстановить доступ, либо если у вас не привязывается телефон — значит, мы что-то сломали и отвечать за это мне 🙂
4. Переехал в Грузию, живем в доме с бывалым тимлидом первой команды, из которой вырос весь юнит. Это удобно для работы, но так работа проникает слишком сильно в мою жизнь.
5. Меня как тимлида не хватало на две команды. Поэтому обосновал необходимость найма, составил профиль кандидата, провел 15 интервью и 23 декабря вывел тимлида во вторую команду. Уделил мало внимания онбордингу в прошедшую первую неделю нового тимлида. Обещаю исправиться в следующем году. Начну с того, что составлю полноценный чеклист онбординга.
6. Помог инженеру вырасти в тимлида в третьей команде. Эта команда — моя гордость. Сразу после формирования команды ребята нашли общий язык и вышли на перформинг. Поэтому рост изнутри в этом случае — гораздо лучше, чем внешний найм. Таким образом не меняется состав команды, а инженер, которого команда авторизовала как лидера, становится им.
7. Провёл две тимлидских подлодки в составе программного комитета. Тема первой — change management. Тема второй — переход тимлида в другую компанию. Обе темы мне очень близки и вложился как мог. Горжусь сессией «как тимлиду собеседовать работодателя». Даю ссылку на канал Жени Антонова, потому что ему можно выкладывать запись сессии в паблик 🙂 Ну и потому что хороший канал, чего уж.
8. Сходил на подкаст DevOne к бывшим коллегам. Поболтали про T-Shape. Рассказал о том, как матрица компетенций Авито ожидает T-Shape от E5+ (сеньор) инженера.
Итог и пожелания
В прошлом году я пожелал вам грести целенаправленно, а не плыть по течению. Составлять план развития, идти по нему.
В этом году у меня был план, но не план профессионального развития, а план действий в изменяющихся внешних условиях. В какой момент, как и куда поехать. Что делать с ипотекой. Как обеспечить себя и семью на новом месте.
Трудно было всем, но я заметил что проще иметь четкое понимание, какими будут твои действия при каком развитии событий.
А в профессиональном плане я скорее плыл по течению и подгребал, когда были силы. Получилось неплохо, даже лучше ожиданий. В профессиональном плане.
Желаю каждому иметь план действий и критерии применения. Тогда будет место в голове для мыслей о профессиональном развитии.
🔥23❤17👍6🎉4
Что такое груминг?
За последние 5 лет повидал около 5 разных вариантов груминга. Подумалось тут, что этот процесс у меня болел всегда. Всегда был чем-то неидеален и кому-то из участников не нравился. Участники видят этот процесс по-разному, потому что каждый тащит за собой багаж прошлого опыта и убеждений. Например «на груминге мы должны оценивать задачу. Если задача не готова к оценке — нельзя тратить на нее время. Так в этом вашем скраме написано». Кек, не написано. Вообще в скрамгайде ничего про груминг не написано.
Если честно, ненавижу слово груминг. Кто-то счёл разумным назвать процесс «причесыванием бэклога», по аналогии с уходом за животными. (англ groom — ухаживать). У меня каждый раз ассоциация только с тем как обезьяны чистят шерсть друг друга от паразитов. Это реальный первоисточник термина груминг, погуглите. А еще можно нагуглить "Cyber Grooming», это что-то из разряда «ЦП в ЛС». Короче, не нравится мне слово груминг.
Термин из книги — Product Backlog Refinement (PBR).
Уточнение бэклога. Непонятно. И в скрамгайде всего одно упоминание (sic!):
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a denoscription, order, and size. Attributes often vary with the domain of work.
Окей, PBR = декомпозиция и уточнение деталей: описания, порядка и размера. Всё, дальше сами.
Ну давайте решать. Только решать надо всей командой, чтобы все понимали, зачем этот груминг и что на нем должно происходить.
Что нам нужно чтобы взять задачу в спринт? Описание поведения, критерии приемки, тест-кейсы, техническая декомпозиция до уровня «написать функцию myFunc() в классе MyClass».
Вот это перечисление — чеклист Definition of Ready.
Оценка задачи — конечный этап, на котором мы должны посмотреть в это перечисление, решить что всё понятно и сойтись в том, на какую из предыдущих задач эта похожа по объему.
Если у вас болит груминг, и вы никак не можете сойтись в оценке — скорее всего, болит не грумминг, а процесс подготовки задачи к спринту. Точнее, его неструктурированность. Непонятно — кто, что и в какой момент должен сделать.
Короче, предлагаю:
1️⃣ — Груминг называть PBR.
2️⃣ — Делать в рамках PBR всё что угодно, чтобы из абстрактных элементов продуктового бэклога подготовить конкретные элементы бэклога спринта.
3️⃣ — Не фреймиться на встречу для PBR. Это процесс. По большей части асинхронный, зачастую индивидуальный.
В следующем посте расскажу, из чего этот процесс состоит у нас, и что делаем на PBR.
Пока можете почитать опыт ребят из InDrive, у меня похожие боли и похожий путь их преодоления.
https://habr.com/ru/company/inDrive/blog/682806/
За последние 5 лет повидал около 5 разных вариантов груминга. Подумалось тут, что этот процесс у меня болел всегда. Всегда был чем-то неидеален и кому-то из участников не нравился. Участники видят этот процесс по-разному, потому что каждый тащит за собой багаж прошлого опыта и убеждений. Например «на груминге мы должны оценивать задачу. Если задача не готова к оценке — нельзя тратить на нее время. Так в этом вашем скраме написано». Кек, не написано. Вообще в скрамгайде ничего про груминг не написано.
Если честно, ненавижу слово груминг. Кто-то счёл разумным назвать процесс «причесыванием бэклога», по аналогии с уходом за животными. (англ groom — ухаживать). У меня каждый раз ассоциация только с тем как обезьяны чистят шерсть друг друга от паразитов. Это реальный первоисточник термина груминг, погуглите. А еще можно нагуглить "Cyber Grooming», это что-то из разряда «ЦП в ЛС». Короче, не нравится мне слово груминг.
Термин из книги — Product Backlog Refinement (PBR).
Уточнение бэклога. Непонятно. И в скрамгайде всего одно упоминание (sic!):
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a denoscription, order, and size. Attributes often vary with the domain of work.
Окей, PBR = декомпозиция и уточнение деталей: описания, порядка и размера. Всё, дальше сами.
Ну давайте решать. Только решать надо всей командой, чтобы все понимали, зачем этот груминг и что на нем должно происходить.
Что нам нужно чтобы взять задачу в спринт? Описание поведения, критерии приемки, тест-кейсы, техническая декомпозиция до уровня «написать функцию myFunc() в классе MyClass».
Вот это перечисление — чеклист Definition of Ready.
Оценка задачи — конечный этап, на котором мы должны посмотреть в это перечисление, решить что всё понятно и сойтись в том, на какую из предыдущих задач эта похожа по объему.
Если у вас болит груминг, и вы никак не можете сойтись в оценке — скорее всего, болит не грумминг, а процесс подготовки задачи к спринту. Точнее, его неструктурированность. Непонятно — кто, что и в какой момент должен сделать.
Короче, предлагаю:
1️⃣ — Груминг называть PBR.
2️⃣ — Делать в рамках PBR всё что угодно, чтобы из абстрактных элементов продуктового бэклога подготовить конкретные элементы бэклога спринта.
3️⃣ — Не фреймиться на встречу для PBR. Это процесс. По большей части асинхронный, зачастую индивидуальный.
В следующем посте расскажу, из чего этот процесс состоит у нас, и что делаем на PBR.
Пока можете почитать опыт ребят из InDrive, у меня похожие боли и похожий путь их преодоления.
https://habr.com/ru/company/inDrive/blog/682806/
scrumguides.org
Scrum Guide | Scrum Guides
The Scrum Guide provided in HTML format on the web.
👍18🔥5💯1
Как мы готовим задачи к спринту
У нас болели груминги, но на самом деле болела неструктурированность подготовки задач.
Бывало, что всей толпой обсуждали совсем сырую задачу без критериев приемки. Буквально 10 человек смотрели, как один заводит задачу, и вместе рожали туда из головы критерии приемки.
В идеале фича-драйвер приносил на общую встречу уже первично описанную задачу с критериями и декомпозицией. Но это держалось на энтузиазме и проактивности фича-драйвера, и процесс подготовки задач отличался по каждому направлению.
Пришло время структурировать процесс.
Как писал в прошлом посте, начать стоит с вопроса: а что такое готовая к спринту задача? Собраться всей командой и набрейнштормить себе чеклист Definition of Ready for sprint.
Допустим, в DoR входят продуктовые критерии приемки, декомпозиция на подзадачи, контракты между бэком и фронтом и оценка.
Нужны ли все вместе на одной встрече, чтобы подготовить всё это?
Полагаю, что нет. Сначала есть асинхронная работа:
1. Продакт может подготовить критерии приемки сам и обсудить их с фича-драйвером.
2. Фича-драйвер может сделать первичную декомпозицию задачи и подготовить черновик контрактов.
Вот это можно уже приносить всей команде на доуточнение и оценку. Совместными усилиями можно нагенерить еще корнер-кейсов или придумать, как удешевить разработку в 10 раз.
Её мы обычно разбиваем на этапы. Простейший и самый распространенный вариант — To Do, In Progress, In Review, Done.
Подготовку задачи так же можно разбить на этапы и отразить этот процесс на канбан-доске.
Для своих команд я вижу такой идеальный процесс подготовки задач к спринту:
1️⃣ — Продуктовая проработка. На этом этапе продакт сам или вместе с фича-лидом описывает, зачем и что нужно сделать. На что это повлияет с точки зрения пользователя и бизнеса. Как продакт видит задачу завершенной — критерии приемки. Тесткейсы тоже могут появиться на этом этапе, с привлечением QA.
2️⃣ — Техническая проработка. На этом этапе фича-лид сам или с привлечением других экспертов описывают задачу технически. Если нужно, можно собрать брейншторм всей командой. Или взять ресерч в спринт.
3️⃣ — Оценка. Это тот самый этап, когда каждый член команды может оценить задачу, и оценки должны сойтись. Не принципиально, будут это майки или стори-поинты. Главное — это этап принятия командой задачи как готовой к спринту.
4️⃣ — Готово к спринту. Здесь самое время прокликать чеклист DoR и увидеть, не пропустили ли какой-то из этапов подготовки. Можно сказать, в момент перетаскивания задачи в эту колонку команда коммитится, что может сделать задачу за понятное время.
В общем случае, стоит доводить до конца уже начатую работу. Если есть задачи, готовые к оценке — в первую очередь оценить их.
Если таких задач нет, — возможно совместно декомпозировать, докидать технических деталей, или продуктовых критериев приемки. Но скорее всего, для этого собирать всю команду не нужно.
Мы пришли к тому, что встречу-PBR собираем в случаях, если нужен совместный брейншторм или уже можно оценить задачу. Но первично её уже кто-то должен был проработать.
В отдельном посте напишу подробнее, как инженеры прорабатывают задачи в спринте. В двух словах:
Чтобы проработка тоже считалась полноценной работой инженера, заводим таску-ресерч на фича-драйвера в спринт. В таске на ресерч тоже прописываем критерии приемки: на выходе с ресерча должны получить артефакт в виде схемы в миро и оцененные задачи.
На скрине наша канбан-доска, которая отражает процесс, описанный выше.
Если у вас болит проработка задач, советую описать ваш процесс, нарисовать свою доску и использовать её на PBR.
Это поможет описать процесс, структурировать его и возможно даже сразу улучшить.
У нас болели груминги, но на самом деле болела неструктурированность подготовки задач.
Бывало, что всей толпой обсуждали совсем сырую задачу без критериев приемки. Буквально 10 человек смотрели, как один заводит задачу, и вместе рожали туда из головы критерии приемки.
В идеале фича-драйвер приносил на общую встречу уже первично описанную задачу с критериями и декомпозицией. Но это держалось на энтузиазме и проактивности фича-драйвера, и процесс подготовки задач отличался по каждому направлению.
Пришло время структурировать процесс.
Как писал в прошлом посте, начать стоит с вопроса: а что такое готовая к спринту задача? Собраться всей командой и набрейнштормить себе чеклист Definition of Ready for sprint.
Допустим, в DoR входят продуктовые критерии приемки, декомпозиция на подзадачи, контракты между бэком и фронтом и оценка.
Нужны ли все вместе на одной встрече, чтобы подготовить всё это?
Полагаю, что нет. Сначала есть асинхронная работа:
1. Продакт может подготовить критерии приемки сам и обсудить их с фича-драйвером.
2. Фича-драйвер может сделать первичную декомпозицию задачи и подготовить черновик контрактов.
Вот это можно уже приносить всей команде на доуточнение и оценку. Совместными усилиями можно нагенерить еще корнер-кейсов или придумать, как удешевить разработку в 10 раз.
Её мы обычно разбиваем на этапы. Простейший и самый распространенный вариант — To Do, In Progress, In Review, Done.
Подготовку задачи так же можно разбить на этапы и отразить этот процесс на канбан-доске.
Для своих команд я вижу такой идеальный процесс подготовки задач к спринту:
1️⃣ — Продуктовая проработка. На этом этапе продакт сам или вместе с фича-лидом описывает, зачем и что нужно сделать. На что это повлияет с точки зрения пользователя и бизнеса. Как продакт видит задачу завершенной — критерии приемки. Тесткейсы тоже могут появиться на этом этапе, с привлечением QA.
2️⃣ — Техническая проработка. На этом этапе фича-лид сам или с привлечением других экспертов описывают задачу технически. Если нужно, можно собрать брейншторм всей командой. Или взять ресерч в спринт.
3️⃣ — Оценка. Это тот самый этап, когда каждый член команды может оценить задачу, и оценки должны сойтись. Не принципиально, будут это майки или стори-поинты. Главное — это этап принятия командой задачи как готовой к спринту.
4️⃣ — Готово к спринту. Здесь самое время прокликать чеклист DoR и увидеть, не пропустили ли какой-то из этапов подготовки. Можно сказать, в момент перетаскивания задачи в эту колонку команда коммитится, что может сделать задачу за понятное время.
В общем случае, стоит доводить до конца уже начатую работу. Если есть задачи, готовые к оценке — в первую очередь оценить их.
Если таких задач нет, — возможно совместно декомпозировать, докидать технических деталей, или продуктовых критериев приемки. Но скорее всего, для этого собирать всю команду не нужно.
Мы пришли к тому, что встречу-PBR собираем в случаях, если нужен совместный брейншторм или уже можно оценить задачу. Но первично её уже кто-то должен был проработать.
В отдельном посте напишу подробнее, как инженеры прорабатывают задачи в спринте. В двух словах:
Чтобы проработка тоже считалась полноценной работой инженера, заводим таску-ресерч на фича-драйвера в спринт. В таске на ресерч тоже прописываем критерии приемки: на выходе с ресерча должны получить артефакт в виде схемы в миро и оцененные задачи.
На скрине наша канбан-доска, которая отражает процесс, описанный выше.
Если у вас болит проработка задач, советую описать ваш процесс, нарисовать свою доску и использовать её на PBR.
Это поможет описать процесс, структурировать его и возможно даже сразу улучшить.
👍16🔥5❤2
Процессы как отмазка
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