Product Developer

Исследование тимлидов В 23 году прошел большой опрос тимлидов от DevCrowd. Поделюсь интересностями оттуда. Этот пост — призыв пройти опрос текущего года. Это некоммерческая история, мне не платили за этот пост, и да, опрос я прошел. Прохождение займёт у вас ~1-5 минут. В сентябре ребята подобьют результаты и выложат в виде красивой инфографики. В прошлом опросе приняло участие 570 человек, из которых: - 68% – тимлиды - 22% – менеджеры менеджеров - 9% – директора 📌 90% перешли в менеджмент в той же компании, где работали инженерами. 📌 Топ-3 обязанности руководителей любого уровня: 1️⃣ Собеседования, 2️⃣ Развитие людей в команде 3️⃣ Оценка их перфоманса. 📌 — 80% тимлидов считают себя сильнее большинства инженеров в своей команде. 📌— Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени. 📌 — Активно ищет работу только каждый десятый тимлид. Подробнее, с инфографикой и даже видосом от Егора Толстого — Ссылка на результаты 2023. ——— P.S. там есть вопрос про медиа, которые вы читаете. Среди вариантов нет Product Developer, но есть поле «другое». Ну вы знаете, что туда написать 🙂 Пройти опрос.

​​Low-context коммуникация и обратная связь Правильный ответ на вопрос из прошлого поста — 3️⃣ C большей вероятностью представители двух разных High-context культур могут неправильно считывать «между строк» сообщения друг друга. Потому что их культура формировалась независимо в разном историческом контексте. Даже внутри одной страны есть риск неправильного считывания «между строк». Сейчас в распределенных командах работают ребята из разных регионов, и у каждого свой high-context. Поэтому простое правило — в рабочей коммуникации использовать Low-context. Самому выражаться максимально четко и детализированно и переспрашивать у собеседника, если начинаешь додумывать. Давать максимум контекста: над чем работаешь и детали для правильного понимания ситуации. Объяснять, почему задаешь тот или иной вопрос. Да, иногда придется повторяться. Но лучше повторить, чем быть неправильно понятым. А еще — не закладывать намёков и смыслов «между строк» в своей коммуникации и не пытаться найти их в словах собеседника. Но из любого правила есть исключения. Самое важное исключение — обратная связь. Удивительно, но многие Low-context страны имеют культуру смягчения корректирующей обратной связи. Например, в Америке, UK и Канаде принято давать фидбек в формате «сендвича»: «несколько положительных аспектов, затем мягко упомянуть о том, что можно улучшить, и снова похвалить». Раньше я давал фидбек именно так, считая это правильным. Но один разработчик назвал это «буллшит-бургером», и я понял, что такой подход может восприниматься как неискренний: положительная часть обесценивается, а корректирующая не воспринимается должным образом. Теперь я стараюсь использовать Low-context коммуникацию, сохраняя при этом прямой стиль обратной связи. На картинке — позиционирование стран в координатах «Коммуникация / Обратная связь». Мы с вами находимся в квадранте «High-context / Direct negative feedback». Из этого делаем вывод, что в общем случае мы можем общаться намёками и рассчитывать, что собеседник поймёт наш посыл «между строк». Но при этом если код — 💩, то так и будет сказано. Намёк может быть понят неправильно, поэтому стоит помнить об этой склонности и возвращаться к Low-context. Однако не стоит ориентироваться на Америку в части обратной связи. Конечно, не стоит говорить «твой код — говно». Но и формат «ты, конечно, молодец, но код — говно. Но ты, конечно, молодец» — не поможет. И да, «хвали публично / ругай лично» 🙂

Yet Another Level: TeamLead — Митап для тимлидов от Яндекса. 25 июля. Бесплатно. Митап из серии мероприятий про жизнь в IT-индустрии. В этот раз о тимлидах, их софт скилах и карьерных треках. Будут выступать уважаемые господа: 📌 Евгений Антонов, мой товарищ, технический менеджер в Yandex Infrastructure. «Играющий тренер: выиграет или проиграет?» — Поговорим о том, как начинающие тимлиды 80% пишут код и 80% занимаются менеджментом. 📌 Александр Афенов, мой коллега, Technical Cluster Lead в Авито Доставке. «Жока и Бока: две очень разные судьбы тимлидов». Ожидаю классный сторителлинг, где каждый сможет узнать себя. 📌 Руслан Остропольский, CPO в Test IT. «Как завоевать доверие тимлиду» Разберёмся, что такое доверие, как оно формируется и как его не потерять. А ещё обсудим, есть ли разница между доверием и авторитетом. Митап пройдёт 25 июля онлайн и офлайн в Москве — участие бесплатное, но нужно зарегистрироваться Присоединяйтесь к чату сообщества в tg https://t.me/Yet_Another_Level

​​Low-context vs High-context коммуникация Читаю The Culture Map — книгу про культурные различия. Заходит настолько, что буду приносить сюда кое-какие концепты. Страны с богатой историей и традициями выражают больше смыслов меньшим количеством слов, что экономит время и помогает сохранить отношения. Это называется high-context коммуникацией. У нас принято «читать между строк». Аналогично в Испании, Турции и многих других странах. В Японии и Китае это же называется «слушать воздух». High-context пример: На дейли тимлид говорит «надо подумать, как оптимизировать запрос». В нашей культуре это может означать просьбу к конкретному разработчику заняться оптимизацией, но напрямую это не озвучено. Могут возникнуть недопонимания: 🤏 конкретный разработчик может не понять, что эта просьба — к нему, и продолжить работать по своей задаче. А когда неоптимальный запрос станет проблемой — это будет его проблема, потому что у тимлида были ожидания. 🤏 сразу несколько ребят бросят свои задачи и, не синхронизируясь, займутся оптимизацией. Другая работа не будет сделана, а потом еще и спорить будут, чья оптимизация круче 🙂 ========== Напротив, молодые «экспатские» страны, вроде Австралии, не имели возможности развить high-context культуру. Чтобы выходцы из разных стран могли сосуществовать, они стараются не закладывать доп смыслов в свои сообщения и выражаются прямо и детализированно. В следующем посте расскажу про Low-context коммуникацию, почему она лучше подходит для рабочих отношений. Как вы думаете, где больше пространства для недопониманий? 1️⃣ — Между двумя представителями разных Low-context стран, например Австралия и Канада 2️⃣ — Между Low-context из США и High-context из Китая 3️⃣ — Между High-context из России и High-context из Индии Буду рад обсудить в комментах 🙂

Процесс найма — несправедливый, как ни старайся Читаю «Work Rules!» от бывшего главы HR Google. Корпорация добра проводит A/B тесты во внутренних процессах, в том числе в найме. Вот как разные методы отбора кандидатов влияют на будущую успешность сотрудника: • Отсев по количеству лет опыта — 3% • Сбор фидбеков с прошлых мест — 7% • Неструктурированные интервью — 14% • Структурированные интервью — 26% • Тест на общие когнитивные способности (внезапно) — 26% • Практическое задание — 29% Разные компании комбинируют эти методы, но ни один из них по отдельности не гарантирует более 30% успеха! ——— Когда после 5 лет работы в QIWI решил «пособеситься ради интереса», оказалось что это целый новый мир, не похожий на то, что я делал в каждодневной работе. У людей, кто работает на одном месте несколько лет и не смотрит на рынок, могут возникнуть трудности: — Как оценить свой опыт, — Как проходить собеседования, — Какая зарплата считается рыночной. Было бы здорово мне тогда сходить на консультацию к кому-то, кто в этой теме работает постоянно. Это помогло бы сэкономить время и силы, и меньше стрессовать. Этот пост — реклама Карьерного Цеха. Ребята предлагают бесплатную консультацию для тех, кто подумывает искать работу. На консультации помогут сориентироваться в рынке, составить резюме, оценить навыки. Расскажут, как правильно готовиться и проходить собеседования. А еще ребята организуют тусовку, где можно найти нетворк для поиска работы. Записывайтесь на бесплатную консультацию и получите индивидуальный план поиска работы, который приведет вас к офферу. Реклама. ИП Федоров Е.П. ИНН 532008901966

Авторизация — больше чем логин/пароль ^^ К репосту выше ^^ Не так давно я оформил серию постов про альтернативы 2fa в презентацию и выступил первый раз за 2 года. Спасибо ребятам из Mad Brains, что позвали. И отдельное спасибо за то, что смонтировали видос. А серия постов тут, начинается с «SMS — плохой способ 2fa». Так может и выступать начну опять.

Всем привеееет! 😃 Каждую пятницу в Mad Brains проходят «Техно» — митапы, где наши сотрудники и друзья компании выступают с докладами. 💪 В этот раз к нам пришел Никита из «Авито», технический руководитель юнита Avito ID и автор крутого блога о продуктовой разработке изнутри Product Develоper. 👀 Скорей смотри ролик, в нем Никита рассказывает про боли авторизации, ее факторы и светлое будущее, которое не за горами. #madbrains_tekhno

​​Что такое Data-driven принятие решений Одним предложением — это процесс принятия продуктовых и бизнесовых решений, основанных на конкретных оценках и измерениях. Разберем на примере Авито. На картинке — один из тысяч A/Б-тестов в нашей «АБшнице». Изменение десятой доли процента любой метрики может привести как к повышению доходов, так и к потерям. Поэтому, раскатывая новый интерфейс в личном кабинете, мы предварительно проводим цепочку А/Б-тестов. Так мы узнаем точно, сколько людей от нас уйдет из-за изменения, а сколько начнет пользоваться продуктом чаще. Видя все числа перед глазами, бизнес принимает решения точнее и легче. Эффект «экспертного» мнения и зависимость от компетенций конкретного менеджера не исчезает, но сводится к минимуму. Все раскатки и принимаемые решения должны иметь под собой числовое обоснование. Где-то это маркетсайзинг, где-то конкретные А/Б-тесты и исследования поведения пользователей. Все сильно зависит от этапа развития, на котором находится конкретная гипотеза или идея. Рассказывая о прогрессе заказчикам, вы обязательно получите вопросы: «что это дало?», «какой был отток?», «какой ещё потенциал у этой фичи?». Наша внутренняя культура позволяет любому задавать такие вопросы и готовит всех относиться к ним с благодарностью. Основные плюсы data-driven культуры: — Решения принимаются точнее, компания легче отказывается от бесполезных идей и поддерживает полезные — Снижается зависимость от «экспертного» мнения, компания чуть лучше защищена от некомпетентных менеджеров — Развивается культура «экологичного» челленджа, повышается прозрачность принимаемых решений Однако, конечно, у такого подхода есть ряд минусов: — Команды могут начать перестраховываться — появляется «аналитический паралич», из-за чего ухудшается ТТМ — Некоторым менеджерам становится труднее принимать решения, когда результаты теста не однозначные … и ограничений: — Компании нужно развивать аналитические компетенции в большом объеме — это дорого — Нужно строить инфраструкту данных и развивать data-инженерные компетенции — это дорого и сложно Последнее здесь стоит особняком: без данных — нет аналитики и не будет никакой культуры. Именно с этого надо начать и в это нужно проинвестировать, если вы хотите достичь data-зрелости в принимаемых решениях. Это был гостевой пост Алексея Малинского, руководителя категорийной аналитики в Авито Товарах. Больше постов про аналитику — Avito Data Tech

Четырехдневка, доступная каждому … за которую еще и доплатят 🙂 Кто-то мог подумать, что я начинаю агрессивно хантить людей. Но нет, я пришел рассказать про концепцию, к которой пришел сам (но наверняка был не первым) Итак, если: 1. Хотите попробовать четырехдневную рабочую неделю 2. При этом сохранить погружение в контекст, ходить на планирования по понедельникам и ретроспективы по пятницам 3. Работаете итерациями в 2+ недели 4. Готовы потратить несколько отпускных дней чтобы поднабраться сил То представляю вам уникальный авторский концепт: Отпуск с пятницы по понедельник в середине спринта * имеются противопоказания, проконсультируйтесь с руководителем Так вы не пропустите мероприятия начала и конца спринта, и не будете выпадать надолго. Но получите 4 рабочих дня, за которыми следуют 4 выходных, и затем еще 4 рабочих. Это гораздо лучше последней «четырехдневки» 12 июня, когда разрыв контекста произошел посередине недели. Следующие два дня ушли на восстановление работы, а затем опять выходные. Писать ли отпуск на выходные — по желанию и согласованию с компанией. Если у вас накопилось 20+ дней отпуска — это отличный способ обналичить отпускные. Но если вы копите отпускные, то можно и не писать. Можно просто в пятницу и понедельник. Концепт крайне рекомендован тем, кто подвыгорел и не может уйти в отпуск, потому что все развалится. За один день в неделю не развалится. Всем своим многоотпускникам советую, и вы попробуйте! ============== P.S. Обращение к ребятам, кто копит, «инвестирует» свои отпускные дни. На первый взгляд, тратить их не выгодно: если сейчас дадут повышение зарплаты, то через год за день отпуска заплатят больше. Но это только на первый взгляд. Во-первых, за год инфляция съест этот прирост, а вам дадут еще одно повышение зарплаты. Во-вторых, повышение зп чаще получают те, кто хорошо отдыхает и продуктивно работает. Поэтому потратить отпускные дни = инвестировать в себя. А копить отпуск = продавать свое здоровье по цене отпускного дня. Сходите уже отдохнуть.

​​Podlodka Soft Skills Crew. Про собесы. В Авито я провожу интервью оценки опыта для кандидатов-тимлидов, где один из вопросов — про найм: Как нанимаешь? На что смотришь? Зачастую, когда речь заходит о софт скиллз, ответ — «ну чтоб адекватный был, чтоб комфортно было общаться». Расхожее суждение, что софты — это про характер кандидата. Вот с этим расхожим суждением я борюсь как могу: пишу посты, рекламирую профильные конференции 🙂 13 мая родная подлодка стартует конфу про Soft Skills при найме, со стороны кандидата. Ребята будут на практике показывать: — Как задавать правильные вопросы, чтобы не разочароваться после найма. Евгений Антонов проведет публичное собеседование «наоборот» — будет расспрашивать Настю Абрашитову о позиции. — Как демонстрировать гибкие навыки на техсобесе. Алексей Шаграев разберет реальный кейс одного из зрителей и даст развернутый фидбек. — Что такое behavioral culture interview. Также Алексей Шаграев, проведет публичное интервью для проверки soft skills кандидата. Мне очень интересно посмотреть на опыт Алексея с этой стороны, ведь он проводил такие интервью в Яндексе и Google. — Как компании нанимают людей. Общепринятые практики, необоснованные требования, странные вопросы, но откуда они берутся? Ярослав Астафьев расскажет, как формируются эти "правила игры", развеет популярные мифы о собеседованиях и даст практические рекомендации по успешному прохождению интервью. На сайте конференции — больше деталей о конфе, инфа про остальные доклады, и самое главное — билетики! 13 мая. Неделя. Онлайн, утром и вечером.

Топ постов в этом канале для 10.000 подписчиков! 🥳 Привет, десять тысяч подписчиков! Это отличный повод обновить интро, и добавить в него полезностей. Канал — о продуктовой разработке изнутри, глазами инженера. Меня зовут Никита Хромушкин, и я инжиниринг мемеджер в Авито. В душе я все еще инженер, хотя в трудовой — Head of Development of AvitoID unit. В 2023 переехал в Испанию и стал отцом. Пишу обычно лонгриды, стабильного графика постов и контент-плана не имею. Однако, если здесь появляется пост — то о чем-то стоящем: про образ мышления, роли, процессы, события и артефакты продуктовой разработки. Иногда про участников процесса. Иногда про найм с обеих сторон. Изначально завел канал, чтобы формулировать свои идеи и доносить их в свою команду. С тех пор аудитория расширилась, но основная концепция осталась. Канал призван приносить пользу. Основная метрика, в которую целюсь — количество репостов. Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими. 🎉 Давайте отметим 10к подписчиков топом полезных постов! 🎉 1️⃣ — О чем спросить будущего работодателя — чеклист, собрал 582 репоста и 12к просмотров. Чеклист мы делали вживую на круглом столе на Podlodka Teamlead Crew. Вложились Евгений Кателла, Евгений Антонов и Татьяна Аква, я был в роли ведущего. 2️⃣ — Digital Nomad в Испании — 266 репостов и 9.3к просмотров. Забавное из обсуждения поста в одном там чате: «История лютая, ппц. На большом сроке решиться на такую авантюру. Если б что не так, то сидели бы они в миграционной тюрьме с марроканцами». Это байопик нашего переезда в Испанию на машине, первый и единственный lifestyle-пост. Тем не менее, и он оказался полезным: в нем ссылки на базу знаний на Notion, которой я пользовался при подготовке документов. 3️⃣ — Как мы готовим задачи к спринту, поделились 86 раз и посмотрели 3,1к человек. Этот пост про то, что процесс подготовки задачи к разработке тоже можно структурировать и описать. В эту же тему будет ранний пост про Dual-track development. У канала тогда было 100 подписчиков, я работал в QIWI, но уже тырил лучшие практики из Авито 🙂 4️⃣ — Как и зачем декомпозировать User Story + 21 шаблон декомпозиции, вдвоем набрали 244 репоста и 4.2к просмотров. Эти посты про то, как декомпозировать недекомпозируемое. Могут помочь продактам/бизнес-аналитикам и командам делать более частые и маленькие инкременты и быстрее получать обратную связь. 5️⃣ — Как понять, в ту ли сторону ты развиваешься, чтобы получить повышение? + Windrose template для собственного развития — вдвоем набрали 218 репостов и 7,5к просмотров. Это про Авитошную матрицу компетенций. Если у вас в компании нет матрицы, а решения о промо принимаются на уровне команды, то можно позаимствовать матрицу Авито и использовать её внутри своей команды. 6️⃣ — Серия из 3 постов Как мы команду делили + Как мы провели Kick-off за 8 часов и какие вынесли уроки — вся серия набрала 305 репостов и 27,1к просмотров. Полезно, если у вас команда предельного размера (~9+ человек) и связанные с этим страдания — долгие стендапы, грумминги, общий расфокус, и невозможность уследить за всем что происходит. 7️⃣ — SMS Two factor auth — плохая практика и серия постов про альтернативы, заканчивающаяяся постом про Будущее аутентификации в вебе — вся серия набрала 206 репостов и 13.5к просмотров === В конце поделюсь ранними постами. Тогда подписчиков было 100-1000, поэтому они не набрали достаточно репостов, чтобы конкурировать с последними. 8️⃣ — StarMap — карта компетенций команды, 74 репоста, 1.8к просмотров — если нужно собрать воедино картинку: кто что знает, чему готов научить и чему хочет учиться. Поможет обнаружить низкий бас-фактор или недостаточность экспертизы для каких-то фич. 9️⃣ — Чеклист Definition Of Done — Как всем одинаково понять, что задача сделана. 58 читателей задумались о внедрении DoD. 🔟 — Чеклист Definition Of Ready (for Sprint) — Как понять, что задача проработана, 50 репостов, 1.8к просмотров. Верю, что один из этих постов окажется для вас полезным. Добро пожаловать, или снова здравствуйте!👋

​​ProductCamp — в следующие выходные! Когда я что-то рекламирую, стараюсь чтобы это было полезно и бесплатно. Тут два в одном! По поводу ProductCamp я спросил мнения нашего продакт-кластер-лида: — Они хорошие, я и выступал когда-то там и участвую во многих конфах. Нетворк прекрасно выстроен. Потом я посмотрел темы докладов и мне откликнулись: — 5 факапов, которые сделали меня директором по продукту (Ксюша Стрельникова, Райффайзенбанк, Директор по продукту)  — Когнитивные ошибки в продакт менеджменте (Иван Меркурьев, Яндекс, Менеджер проектов)  — 15 Soft Skills менеджера продукта и как их качать на самом деле (ex Head of product developmet MTS, exYandex, exTinkoff) (Сергей Паращенко, Product Vision, Директор по образовательным продуктам)  — Выгореть, выжить, вернуться: от убивающей продуктивности к эффективной (Анна Динельт, Яндекс Афиша, Руководитель продукта)  ——— На это мероприятие невозможно купить билет, на него можно попасть только в качестве волонтёра или спикера. Мероприятие создают сами участники. Чтобы присоединится, нужно заполнить форму на сайте ProductCamp. Там же можно зарегистрироваться на онлайн. Когда: 19-21 апреля Где: Парк-отель «Ареал» и онлайн на ProductLand

Про баланс в работе продакта Каждая компания по-своему понимает роль продакта, но от любого продакта постоянно все чего-то хотят 🙂 Бывает, что продакт-менеджер становится дискавери-менеджером. Всё время тратит на распределение работы по аналитике и исследованиям, выверяет метрики, формирует гипотезы. При этом деливери расценивает как внутренний аутсорс: — «сгружает» эпики размером в квартал без декомпозиции на User Story — не ходит на планирования, PBR, дейлики — не интересуется результатом на ревью спринта, не дает обратную связь — не доносит команде ценность для бизнеса и эффект от фич Так продакт теряет роль Product Owner. Бывает и обратная ситуация: продакт руководит командой разработки вместо тимлида, при этом упуская метрики, аналитику и ux-исследования. Специально привёл две крайности. Но на самом деле продакту очень легко что-то упустить в своей работе. Ангелина Зинченко из Авито написала статью «Как продакту выстраивать коммуникацию со стейкхолдерами и командой» В ней она приводит примеры ошибок и хороших практик для продактов в разных аспектах работы: — с дискавери командой — с деливери командой — с маркетингом, отделом продаж — с клиентской и технической поддержкой — с руководителем, СРО, СЕО или инвестором Советую к прочтению, своим продактам тоже скину. Они очень хорошие! Но мне кажется, что в статье каждый может узнать себя в одном из пунктов 🙂

​​Как и зачем декомпозировать User Story — 21 шаблон Давайте представим, что мы делаем некий MVP. На дискавери потрачено 3 месяца. Скоуп определен, дизайны отрисованы и требования подробно описаны. На разработку заложено еще 3 месяца. Катить на пользователей что-то меньшее, чем этот скоуп — бессмысленно. Например, зачем видеть список товаров, если корзины нет и оплатить невозможно. Итак, тз описано и срок в три месяца на разработку начал тикать. Продакт может отойти и не мешать. Ведь никто не любит, когда заглядывают за плечо и спрашивают «ну когда». А он же хороший руководитель и доверяет своей команде! … Следующий кадр: прошло 3 месяца, продакт смотрит, что получилось. А получилось, что параллельно делали всё, закопались и ни один сценарий целиком не успели. Команда говорит, что показать промежуточный результат не могут и нужен еще 1 месяц. А через месяц нужен еще 1 месяц. В итоге через 5 месяцев сдают проект. И вроде бы всё по тз, но «не то». «Программисты виноваты!» — скажете вы. «Какое тз, такой и результат!» — ответят программисты. Всем плохо: программисты без премии, продакт с кривым MVP, которое уже никому не нужно. Можно ли было помочь и команде и продакту? — Да! Очень часто в продуктовой разработке мы изобретаем водопадные процессы. Долго и тщательно дискаверим, по мере уточнения требований предполагаемый срок деливери увеличивается. В итоге пилим проект, размером в квартал/полугодие/год. А чем дольше горизонт планирования, тем больше вероятность не попасть в оценки. Поэтому есть простое решение, как лучше попадать в сроки и делать «то», благодаря более частой обратной связи: Вместо долгого дискавери, мелко декомпозировать и начинать деливери. А параллельно доделывать дискавери по другим частям. Вот как мог бы выглядеть процесс разработки нашего MVP по спринтам: 0️⃣ — Для старта проекта нам нужно хоть какое-то описание первой функции. Быстренько дискаверим, как должен выглядеть список товаров. Пока пофиг на фильтры и поиск. И пофиг что будет не идеально. Посмотрим вживую, потом поправим. 1️⃣ спринт — разработаем список товаров без поиска и фильтрации. Параллельно будем дискаверить фильтры и поиск. К концу спринта смотрим, как выглядит вживую список товаров. Даем команде обратную связь, чтобы учесть правки в следующем спринте, либо отложить их на конец. 2️⃣ спринт — приделаем фильтры и поиск. А дискавери работает на следующий спринт: как должна выглядеть корзина. 3️⃣ спринт — сделаем корзину и возможность добавлять туда товары. Параллельно дискаверим оплату. 4️⃣ спринт — сделаем процесс оплаты на моках, и только успешный сценарий, без корнер-кейсов, неудачной оплаты и возвратов. … И так далее — до момента, когда уже можно релизить. Да, нет смысла катить на пользователя экран со списком товаров без возможности поиска. Но есть смысл декомпозировать MVP на мелкие User Story не больше 2 недель в разработке. И одной из таких User Story может быть «видеть список всех товаров». Так мы решаем сразу обе проблемы: — Нафакапиться по срокам на коротком отрезке сложнее. А в случае, если сроки поехали — мы узнаем об этом через 2 недели, а не через 3 месяца, и сможем своевременно отреагировать. — Можно будет регулярно смотреть на прогресс. Видеть, как из кубиков строится наш MVP. Во время лайв-демо понимать, как оно выглядит для конечного пользователя и корректировать в следующих итерациях. Я призываю продактов помогать командам декомпозировать User Story на более мелкие, даже если катить на пользователя еще рано. Почитать больше можно в статье Кента Макдональда.

Дайджест полезностей в продуктовой папке Как-то я затесался в тусовку авторов каналов про продукты, а этот канал попал в папку с каналами Products. Внутри — куча полезностей, и не только от продактов. 📌 В канале Фичизм нашел подтверждение актуальности проблемы «угона» сим-карт, о которой я писал раньше — Билайн сделал второй фактор по емейлу при «восстановлении» симки. После прочтения сразу нашел в настройках, включил и вам советую 🙂 https://t.me/fichism/51. 📌 Менеджер от боженьки рассказывает, как выбрать, что рефакторить. https://t.me/pm_god/424 📌 Владимир Меркушев разбирает кейсы из продуктовой разработки, недавно был про A/B тест длительностью 2 часа. https://t.me/vladimir_merkushev/2089 📌 Fresh Product Manager запостил ссылку на статью про коммуникацию продакта с командой от Ангелины Зинченко из Авито https://t.me/FreshProductGo/1025 📌 Саша Клименко проводит вебинары про работу с манипуляциями и отстаивание своих интересов: https://t.me/normalno_delaj/564 📌 Михаил Греков нашел еще одно отличие продукта от проекта: в продукте нужна смекалка! Приводит прикольные кейсы её проявления, например хак оптовых заказов на заре Амазона: https://t.me/proudobstvo/1212 Подписывайтесь на папку Products, чтобы читать такие полезности. После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.

​​Кто хочет вашу цель спринта? «Цель спринта» — концепция простая с первого взгляда, но с кучей подводных камней. Мы с командами знатно походили по граблям, но все равно продолжаем ставить цели спринтов. Каждый раз, наступая на грабли, я страдал и через страдания делал некоторые умозаключения. Вот решил поделиться. Disclaimer: не навязываю никому «этот ваш скрам». В моем юните 3 команды работают двухнедельными спринтами и одна — по канбану. Этот пост — послание самому себе на 5 лет назад, чтобы меньше фрустрировать. ——— Говорят, что команда отличается от рабочей группы тем, что у команды есть общая Цель. В идеале — вся команда объединяет усилия, чтобы за спринт родить эту Цель. Цель мечты — качественную, отвечающую всем критериям приемки и доделанную до Definition of Done. Работа в таких командах доставляет истинное удовольствие. Коллаборация — один из самых сильных мотиваторов для меня. Но в какой-то момент формирование и достижение Цели стало для меня самоцелью работы. Каждые две недели — подведение итогов по прошлой цели и формирование новой. Если не получалось достичь цели — разбирали на ретроспективе. А вот когда не получалось сформулировать такую цель, не разбирали. На ретро довольно сложно поднять вопрос «почему наши цели спринта не объединяют работу команды». А даже если и поднять такой вопрос, то большой риск огрести: «этот ваш скрам не работает», «вот у нас такие особенные обстоятельства». Причины могут быть разными: — либо нет такого запроса от продакта, чтобы за один спринт взять и зафигачить — либо цель недостаточно трудозатратная, чтобы задействовать всех инженеров в спринте — или не смогли достаточно распараллелить, и в итоге фича занимает несколько спринтов, а цели получаются типа «написать ручку на бэкенде» и «сверстать экран». Так появляются две цели. Три цели. Шесть целей. Отдельные цели у фронтендеров и бэкендеров. Зачастую инженеры сначала набирают задачи в спринт, а потом пытаются из этого родить цель. Так в одном спринте появляются цели типа 1. «Три ручки из пяти под фичу Х» 2. «Верстка экранов + интеграция с бэком под фичу Y». 3. «Раскатка фичи Й» Выглядит как мини-вотерфолл по трём проектам. Нахрена нам кросс-функциональная команда? Кому нужны такие цели? Захочет ли продакт участвовать в жизни команды, которая занимается тем что напиливает ручки и верстает экраны? На что ему смотреть на ревью спринта? ——— Последовательность планирования спринта должна быть другой: сначала обозначается цель, а затем набираются задачи для её решения. Не можем сделать целиком сценарий фичи, напилив 5 ручек? Тогда цель может быть: «Короткий успешный сценарий фичи Х». А DoD может включать пункт «Реализовано на всех платформах». Часть сценария тоже может принести пользу: так мы сможем посмотреть на сценарий целиком на ревью спринта и получить первую обратную связь от продакта, от пользователей, да и друг от друга. Можно убедить продакта: «Сценарий целиком займёт 3 спринта», и потерять его из жизни команды на 1.5 месяца. А можно найти способ получить промежуточную обратную связь: спросить, хочет ли он посмотреть короткий успешный сценарий — он скорее всего обрадуется. А если спросить, хочет ли он посмотреть на три из пяти ручек — скорее всего не поймёт. Наличие стейкхолдера у цели спринта — хороший критерий качественной цели. В следующий раз, когда будете формировать цель спринта, попробуйте задать вопрос: Кто хочет эту цель спринта? И постарайтесь сделать так, чтобы каждую цель кто-то явно хотел. P.S. В следующем посте расскажу, какие еще лайфхаки разбивки целей бывают, чтобы делать за спринт то, что кому-то нужно. На картинке — один из таких примеров.

​​Podlodka Product Crew: AI & ML До сих пор я не затрагивал в постах хайповую тему AI. Потому что слишком много инфошума, а я не эксперт в теме. Конференциям Podlodka Crew я доверяю, в частности потому что делал несколько сезонов в составе ПК. Поэтому рад, что появилась конфа про AI, и представляю вам первый пост про AI в этом канале 🙂 Особенно рад, что конфа не про хайп, но про прагматичность: Галя Ширанкова, Unit Lead из Авито: «ML — это не магия: разбираем мифы про искусственый интеллект» Из доклада узнаете: - как на самом деле работают голосовые помощники - три мифа про AI, в которые вы наверняка еще верите - как много ручного труда стоит за созданием AI-продуктов Игорь Котенков: «Куда идут LLM: когда и чего можно ожидать» На сессии развеем несколько мифов об AI, расскажем, чего уже добились языковые модели и как они влияют на мир и опишем основные направления дальнейшего развития AI-моделей. Также будут конкретные кейсы использования AI в продуктах: Александр Сафронов расскажет про рекомендации в Яндекс Музыке: о том, какие есть особенности при разработке рекомендательных систем, на какие метрики смотреть, как понять, что рекомендательная система работает хорошо Мария Леонова расскажет про модерацию в ЦИАНе: - как замещать ручные процессы так, чтобы метрики не упали, а EBITDA росла - как с помощью AI можно расширить возможности своего продукта и повысить его ценность - как понять, стоит ли вообще применять AI Как по мне, Podlodka Crew — топ за свои деньги. Ребята вкладывают тонну человеко-часов в контент, и продают его по цене дешевле одного часа менторинг-сессии со спикерами такого уровня. Сегодня (11 марта, в 19-00 Мск) будет бесплатная открытая сессия на ютубе: Как применяют ML/AI и что делать, если ты продакт в 2к24. Ребята поговорят о том, что в эпоху хайпа не нужно бежать просто за ИИ, что бывает кроме LLM/imagen, и что чат — не единственный интерфейс взаимодействия. А билетики на конфу тут: https://podlodka.io/productcrew Реклама. ИП Толстая Елена Петровна ИНН:507503278104, erid:2SDnjcAgN3J