Product Developer

⠀ Product Sense Прежде чем писать этот пост, я спросил у нашего принципал продакта: Илья, это ценная конфа? «Обычно да, так как довольно требовательно отбирают спикеров и темы. Я был один раз, но остались очень крутые впечатления от воркшопов» Поэтому я согласился порекламировать конфу. И да, Илья идёт на неё, а я буду смотреть в онлайне 🙂 4-5 сентября, оффлайн в Москве или онлайн Ключевые темы — об инструментах и «слепых зонах» в создании продукта, ожиданиях от менеджеров, управлении командой, бюджетом, собой. Смотрите, какие крутые спикеры и темы в расписании! Я бы сходил послушать @dsoloveev из QIWI про использование ИИ в работе. И Алёну Медведеву, юнитлида из Авито, про синдром самозванца. А еще на воркшоп про систематизацию продуктвой проработки задач от Никиты Ефимова, директора Яндекс.Практикум. Кстати, скоро будет бесплатный ютуб-воркшоп от Никиты. В общем, советую посмотреть темы и прикупить билетик, хотя бы на онлайн. Кстати, завтра (12 августа) обещают поднять цену. Вот ссылка на лендос конференции

Digital Nomad в Испании Мы получили одобрение внж Испании на 3 года! Теперь я официально Teletrabajador de caracter internacional. Disclaimer: этот канал не превращается в тревел-блог. Но это очень важный этап, которым хочу поделиться, и который возможно кого-то вдохновит на релокацию. Чтобы пост принёс пользу, приложу ссылки на ресурсы, с помощью которых я готовился к этому проекту: 💡База знаний на Notion, в которой всё-всё-всё про документы и процесс 📌@digitalnomadspain — Канал, где публикуют кейсы одобрений и самую актуальную инфу по получению документов. Вот ссылка на мой пост там. 📌 @chatfornomads — чат при том канале, можно поиском найти ответ на вообще любой вопрос. ============================ Итак, дано: 1. В Тбилиси классно, но хотим двигаться дальше 2. В идеале — в страну, где ребенок сможет претендовать на гражданство 3. Получить оффер и быть релоцированным Европейской компанией — простой путь. Но уходить из Авито не хочу. 4. Аргентина — не вариант, часовой пояс не даст работать И тут как раз Испания с этого года запускает выдачу резиденции для цифровых кочевников. 15 мая мы с супругой и собакой выехали из Тбилиси в Москву, чтобы собрать все документы и 3 июня стартовать в обратную сторону. Предстояло проехать 7500км через Россию, Грузию, Турцию, Грецию, на пароме в Италию, затем Франция и наконец Испания. За время пути я взял всего 4 дня отпуска, всё остальное время работал. По дороге были моменты грустные и веселые. За поездку мы жили в 24 разных апартах. Мы купались в трёх морях. Жрали осьминогов на гриле. Ночевали под горой Олимп. Ночевали с машиной на пароме. Гуляли по Риму. Были в Ватикане и Монако. Держали пизанскую башню. Ночью нам разбили окна в машине, чтобы вытащить багаж. Достали один чемодан, где был собачий корм, поводок и барахло. А второй чемодан с ценной электроникой и документами не пролез в разбитое окно, и они его оставили. Вот оно, везение 🙂 4 июля мы подали документы на рассмотрение, а 11 июля у нас истёк шенген. Пока ждали решение по внж, мы всё еще легально находились на территории Испании. Но в случае отказа — «первым прямым рейсом домой». А мы на машине, с собакой, супруга беременная так что уже на самолет не посадят, да и рейсов прямых нет 🙂 Короче, отказ не вариант. И вот, на днях пришло одобрение. Сейчас мы обосновались в Валенсии. Сняли квартиру на долгосрок, прописались, сдали отпечатки пальцев, ждём карточки резидента. Это был большой проект. И он успешно запущен. В процессе еще один большой проект, ради которого затевалась релокация — примерно в октябре я стану батей.

​​Управление рисками Все слышали, что бас-фактор=1 — это плохо. Это очевидный риск, на который все рекомендуют обращать внимание и устранять: писать документацию, распространять экспертизу внутри команды и растить замену единственному эксперту. А какие еще есть очевидные риски? А какие неочевидные? Редко встречал системное управление рисками. По сути всё, про что пишу — простые штуки из разряда «подумайте заранее, запишите и обращайте внимание в будущем. Вот пример». Очень простые истины, тем не менее до которых надо дойти своим умом. Но вот риск-менеджмент всегда звучал для меня как какой-то булшит. А оказывается, это простая штука про заранее предположить, где и что у вас отвалится, подумать как минимизировать вероятность что отвалится, и что делать если таки отвалится. Можно делать в формате брейншторма или футуроспективы всей командой. Можно делать индивидуально. Можно доверить инженерам проработку рисков по их части, в том числе по QA. Во что это воплощается — можно посмотреть на примере карты рисков, которую составил наш QA-инженер, который недавно получил промо в сеньора (кусочек на картинке, полная версия — в публичной гуглотаблице) В Авито проработка рисков — базовое ожидание от тимлида. 31 мая пройдет открытый бесплатный вебинар от Отуса «Риск-менеджмент для тимлидов». Отусу я доверяю, потому что там преподают люди, с которыми я работаю и которым доверяю. Я записался, рассчитываю систематизировать знания и узнать что-то новое. Заявлены такие тезисы: — В чем смысл рисков и зачем ими управлять — Зачем риск-менеджмент тимлиду — Как управлять рисками, чтобы в этом были смысл и польза — Управление рисками не в работе Вебинар бесплатный, записывайтесь по ссылке: https://otus.pw/qPcy/ 31 мая. 20:00 GMT+3.

Папка тимлидов Недавно я написал пост-знакомство про этот канал. Сказал, что цель канала — приносить пользу, а основная метрика — количество репостов. Всего лишь неделю назад я считал достижением и хвастался постом на 77 репостов. Прошлый пост «О чем спросить работодателя» собрал 245 репостов оО. Тут нужно сделать ремарку, что артефакты в этом посте — плод коллаборации четырех человек на Podlodka Teamlead Crew. А я всего лишь вел сессию, шарил экран, записывал со слов ребят и фасилитировал. К чему это я. Подписывайтесь на папку с тимлидскими каналами. Там такого добра навалом. 14 каналов, почти на все из них я уже был подписан, что-то даже репостил, поэтому могу смело рекомендовать. https://t.me/addlist/mDWR2gD6UEhlOWRi P.S. Этот пост я тоже считаю полезным. Несмотря на то что папки с каналами уже задолбали, кто-то найдет для себя пользу в конкретно этой папке 🙂

​​О чем спросить работодателя — чеклист Новый сотрудник — всегда двусторонняя инвестиция: — компания инвестирует деньги в собеседования, оформление, технику, зарплату сотрудника, его руководителя и бадди — руководитель и коллеги вкладывают в новичка свое время и ресурс — новичок инвестирует свое время и ресурс в прохождение интервью, увольняется из текущей компании, погружается в предметную область, технику и процессы новой компании. Короче, новый сотрудник = инвестиция дофига денег, времени и сил с обеих сторон. Поэтому для меня важно, чтобы люди задерживались с нами на несколько лет. Если сотрудник уходит через 3 месяца-полгода-год, то, скорее всего, инвестиция не окупается. Часть таких увольнений происходит из-за того, что в процессе найма кандидат не убедился в том, что ему подходит компания, позиция, продукт. Компании выстраивают мега-процессы найма, чтобы убедиться, что кандидат точно-точно подходит. На вопросы кандидата обычно закладывают 15 минут. Мне кажется, что пропорция «час на вопросы кандидату» : «15 минут на вопросы кандидата» не справедливая. Поэтому привет и спасибо ребятам из Авито, которых я в сумме мучил около 4-5 часов прежде чем принять оффер. О чем спрашивать — тема индивидуальная. Для кого-то важен продукт, для кого-то — процессы. Кто-то повидал некоторое дерьмо и ему важно убедиться, что такого не будет на новом месте. На позапрошлом сезоне Podlodka Teamlead Crew мы делали брейншторм «О чем спросить работодателя» На выходе получились два артефакта: 1⃣ Mindmap вопросов в Miro С разбиением по этапам и возможным развилкам: Предварительный поиск инфы, чтение вакансии, HR-скрининг, тех. интервью, встреча с руководителем. 2⃣ Чеклист вопросов в гуглодоке С разбиением по темам: компания, проект, подходы, метрики, задачи, полномочия, руководство, команда, техника, условия. Ну и само собой, есть запись сессии. Как член ПК, я не могу публиковать ссылку на видос, потому что он в закрытом плейлисте. Но участники сессии могут. Вот, Женя Антонов у себя в канале постил: https://t.me/general_it_talks/320

Пост-знакомство плюс бонус-контент Привет. Пару лет назад я написал пост про этот канал и повесил его в закреп. Сегодня подписалось как никогда много людей, а интро чутка устарело, поэтому пора обновить. Итак, Канал — о продуктовой разработке изнутри, глазами инженера. В душе я все еще инженер, хотя в трудовой — инжиниринг мемеджер. Меня зовут Никита Хромушкин, и я тимлид тимлидов в Авито. Пишу про образ мышления, роли, процессы, события и артефакты продуктовой разработки. Иногда про участников процесса. Иногда про найм с обеих сторон. Пост обычно рожаю часов за 16, с вычиткой, обратной связью от коллег и редактурой от жены. Изначально завел канал, чтобы формулировать свои идеи и доносить их в свою команду. С тех пор аудитория немного расширилась, но основная концепция осталась. Канал призван приносить пользу. Основная метрика, в которую целюсь — количество репостов. Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими. Например, ровно год назад я написал пост про ИПР, который репостнули 77 раз. Считаю, полезно получилось. Изюминкой канала считаю артефакты, которыми охотно делюсь: DoR, DoD, Windrose для плана развития, всякие рисуночки-графички, схемки. Чуть позже напилю навигатор по постам с артефактами. Вкратце, в общем, познакомились. Добро пожаловать, или снова здравствуйте. ========================= Бонус-контент для старичков канала Недавно меня позвали в масонскую ложу авторов каналов про продуктовую разработку. В чатике топовые ребята, эксперты индустрии, кладезь знаний и все с каналами. А на днях телега выпустила новую фичу — можно делиться целой папкой с каналами. Собсно, решили затестить. Для новоприбывших это уже не новость, а вот для старичков канала может быть полезно. Вот тут собраны топовые каналы топовых продактов и не только: https://t.me/addlist/YvmnHCHUp700Nzky Если не работает — повод обновить телегу. После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.

Product camp Это бесплатный анонс бесплатного мероприятия. Оно позиционируется как для продактов, но вы найдете интересные доклады даже если вы не продакт. Например, есть доклады в треках «Управление процессами и командой», «Коммуникация с командой», «Soft Skills». Мероприятие пройдёт через выходные, 15-16 апреля. Регистрация на сайте Суть кемпа в том, что это реально пионерлагерь на два дня в отеле в Подмосковье. Но будет и онлайн и записи. Собсно, записи прошлых кемпов уже есть, можно посмотреть чего примерно ожидать. Ну и понятно что не докладами едиными. На сайте выложен список спикеров и гостей, там какие-то вообще топовые господа из топовых компаний, типа Авито, Ozon, Tinkoff, Яндекса и других. В этот список можете попасть и вы. Я бы пошел только ради того, чтобы кем-то из них пообщаться. Ессно, потому что такой нетворкинг конвертится в трудоустройство, сейчас или в будущем. В прошлом году мы там себе продакта нашли 🙂 Для онлайн участия тоже надо зарегаться. Бесплатно. На сайте.

Зачем нужны тимлиды? В четверг будет подлодошный круглый стол на эту тему. Предлагаю чуть порассуждать заранее, а потом свериться с уважаемыми господами. Один из моих любимых вопросов на собеседовании — зачем тебе тимлид? Ответ по сути говорит о том, что инженер ждет от меня. Интервью ведь и нужно, чтобы прояснить взаимные ожидания. Прояснить всё, что тебе нужно — ответственность каждого участника интервью. Но не все кандидаты могут сформулировать правильные вопросы. Тем не менее, неловко будет нанять человека, которому я не смогу дать то, что он хочет. Поэтому я спрашиваю и уточняю. Самые частые ответы примерно такие: — Не знаю, не задумывался — не ответ, надо копать дальше другими вопросами. — Задачи заводить и распределять. Здесь еще важно узнать, какой гранулярности задачи хочет получать человек. Честно говоря, моя идеальная команда сама заводит таски в джире и сама их распределяет 🙂 Мне важно, чтобы крупные стримы размером с квартал оказались под крылом нужных людей. — Процессы налаживать. Если за этими словами стоит какой-то реальный образ, то вот это может быть ценный кандидат, повидавший некоторое дерьмо. Надо уточнить, какого рода процессы и как именно налаживать. Главное, опять же, чтобы кандидат не ожидал в лице тимлида видеть скрам-мастера. — Конфликты решать. Вот тут может быть либо конфликтный / притягивающий конфликты кандидат, либо опять же повидавший некоторое дерьмо. Лучше бы детальнее копнуть. В моей идеальной команде конфликты — конструктивные, возникают регулярно, приводят к улучшениям и проходят без участия тимлида. Но это мечты 🙂 Потом я доуточняю: «Это всё про команду. А вот тебе лично — зачем тимлид?» В ответ обычно: — Развитие, карьерный рост. Очевидно, но каким образом? А как кандидат сам развивается? — Обратная связь. Вот тут вопросов нет. На удивление редко это отвечают, кстати. Можно доуточнить кейс, где кандидату давали корректирующую обратную связь , и узнать, как он её применял. — Мне не нужен тимлид. Не путать с «не знаю». Это мой любимый, идеальный ответ. Человек, который так ответил, сейчас показывает всей команде ролевую модель. И собрал 70% оценок «выше ожиданий» от сокомандников на ревью. Сам находит себе инженерно сложные, развивающие челленджи. Может работать в неидеальных процессах. Если процессы совсем плохие — сам начнет их оптимизировать и команде продаст. Конфликты поворачивает в конструктивное русло. Разве что обратная связь иногда нужна, чтобы свериться, что в ту сторону гребет. Это не исчерпывающий список, но из ответов и моих комментариев можно проследить тренд: тимлиды не нужны. Вернее, так: хороший тимлид стремится сделать так, чтобы он был не нужен в команде. Чтобы если он уходит в отпуск, ничего не менялось. Если перформанс команды просядет, значит, что-то тащил на себе. Если перформанс улучшится, значит мешал. В общем, мой ответ такой: Тимлид нужен, чтобы привести команду в состояние, когда тимлид не нужен. А вы как считаете? Что ответили бы сами, или что вам отвечают кандидаты на вопрос «Зачем тебе тимлид?»

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

Процессы как отмазка Disclaimer: в этом посте общественной пользы нет. Я люблю структурировать процессы. Испытываю эстетическое удовольствие, когда всё разложено по полочкам, всё идёт по плану. Я считаю, что любое повторяющееся действие должно быть структурировано, описано и закреплено процессом. Особенно, если это действие делают разные люди, чередуясь. Без описания это неформальная договоренность, возможность нафакапить и повод для будущего конфликта. НО. Меня люто бесят люди, которые облажались и не признают свой косяк, не делают выводов для себя и оправдываются отсутствием / недостаточной структурированностью процесса. Вы поймите правильно, я и процессы люблю и людей. И лажаю сам частенько. Очень радуюсь, когда кто-то как следует прикладывает прод, так чтобы разгребать было интересно, и в будущем мы никогда больше не приложили бы прод подобным образом. НО. Очень уж дофига человеколюбия в последнее время в этом нашем айти. Когда кто-то облажался, мы ищем ему оправдание в хреновости процесса и ищем системное решение в виде доработки процесса. На ретроспективах стараемся не шеймить человека, а предлагать решения в виде регламента, чеклиста, бота с напоминаниями, второй пары глаз, еще чего-то. Это поможет, если человек понимает, что облажался. Но бывает, что один и тот же человек находит изъяны всех ваших процессов. Находит способ облажаться в любом действии. В котором не лажают другие. Процессы всегда не идеальны. Структурированность процессов — баланс между бюрократическим оверхедом и стремлением снизить человеческий фактор. И ради одного персонажа вы из раза в раз добавляете оверхед в процессы. А он из раза в раз находит изъяны этого процесса. Что будете делать с таким человеком? Ведь он старается, работает, пользу приносит. Или вред?

Английский язык Вот я работаю всю жизнь в российских компаниях, но иногда случаются рабочие коммуникации на английском. Когда работал в Райфе, созванивались с головной компанией в Вене и говорили на английском. Сейчас работаю в Авито, дофига всего по-английски: эксельки, документы, защиты продуктовых стримов. Встречи бывают тоже. Заметил, что встречи на английском проходят менее эффективно: мы по 10 раз повторяем одно и то же разными словами, чтобы в итоге все всё поняли. Не то чтобы языковой барьер, но явно есть проблемки. Тогда я подумал, что быть мемеджером в зарубежной компании — стрёмно. Слишком большой оверхед на коммуникацию, слишком медленно всё будет. Потом я уехал в Грузию. Здесь либо хорошо говорят на русском, либо хорошо говорят на английском. Вдобавок окружил себя контентом на английском. Стал смотреть развлекательный контент типа сериалов и видосов на ютубе тоже на английском. Если реально нужно прокачать практический навык коммуникации, очень хорошо работает подход сериал+книга+занятия+практика. Синергия от использования всего и сразу очень сильно заметна с первых недель. Просто потому что так ты формируешь себе нативную (не требующую контроля) кривую запоминания. Рекламу даю супер редко, а тут ко мне пришли уважаемые господа из Практикума. С курсом прямо в сердечко — Английский для работы в IT. У ребят есть отдельные курсы для разработчиков, аналитиков и продакт-менеджеров. Когда я нанимал стажеров, единственные курсы, после которых был готов смотреть — Практикум. Жена проходила два курса — дизайнер интерфейсов и UX-исследователь. При расчетной нагрузке 20 часов в неделю по ощущениям это была нормальная такая фултайм работа. И проекты вполне реальные. Короче, мое увожение. Поэтому смело рекомендую — Английский для работы в IT А при покупке курса в марте вы бонусом получаете доступ к профессиональным разговорным клубам.

​​Как мы готовим задачи к спринту У нас болели груминги, но на самом деле болела неструктурированность подготовки задач. Бывало, что всей толпой обсуждали совсем сырую задачу без критериев приемки. Буквально 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. Это поможет описать процесс, структурировать его и возможно даже сразу улучшить.

Что такое груминг? За последние 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 description, 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/

Итоги года В прошлом году был пост 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+ (сеньор) инженера. Итог и пожелания В прошлом году я пожелал вам грести целенаправленно, а не плыть по течению. Составлять план развития, идти по нему. В этом году у меня был план, но не план профессионального развития, а план действий в изменяющихся внешних условиях. В какой момент, как и куда поехать. Что делать с ипотекой. Как обеспечить себя и семью на новом месте. Трудно было всем, но я заметил что проще иметь четкое понимание, какими будут твои действия при каком развитии событий. А в профессиональном плане я скорее плыл по течению и подгребал, когда были силы. Получилось неплохо, даже лучше ожиданий. В профессиональном плане. Желаю каждому иметь план действий и критерии применения. Тогда будет место в голове для мыслей о профессиональном развитии.

Каково это — приходить сразу тимлидом на новое место Стать тимлидом изнутри в каком-то смысле проще: ты всё знаешь внутри компании, тебя все знают. А вот прийти снаружи сразу на менеджерскую позицию — целый квест. 0. Как выбрать нового работодателя, если ты тимлид? В разных компаниях разные ожидания от тимлида и разные процессы. Никому не хочется попасть в место, где от тебя ожидают 80% управления людьми и 80% кодинга. 1. Вдруг команда не примет? Моего предшественника в Райфе ребята выперли в первый месяц 🙂 Мне повезло больше, но что в этом помогло? Что именно я сделал правильно? 2. Или не сможешь разобраться, как тут всё устроено? В корпорациях бывает так, что размывается ответственность между командами и часто нет единого источника знаний. Приходится выкручивать проактивность на максимум. Как выстроить приоритет для потребления информации? 3. Или не оправдаешь ожиданий руководителя? После выхода на работу в Авито мне нужно было сразу построить планы на квартал для команды, а критериями ИС было выполнение этих планов. А еще выполнение 90% целей спринтов и не более 20% Scope Drop. Я прошел через онбординг тимлидом в новую компанию. А теперь делаю про это сезон Podlodka Teamlead Crew в составе программного комитета. Стартуем 7 ноября. Онлайн. Сессии в 10 и в 19 по Москве. Лендос про конференцию и кнопка «Купить билет» Кстати, о чем бы вы спросили будущего работодателя? Пишите в комментах и получите бесплатную проходку на конфу.

Привет! Еще одно мероприятие в тему поста про OKR. Ребята из QIWI собирают бесплатный оффлайн-митап. Называется Server Party Soft Edition oO 22 сентября, 18:00, Москва, м. Автозаводская / ЗИЛ. Трансляция тоже будет. Судя по лайнапу, прицел в тимлидов, продактов и ведущих разработчиков. — OKR Почему понимание общей цели драйвит команду куда активнее, чем самый лучший менеджер. — T-Shape Чем отличается группа людей, работающих над задачей, от настоящей команды — Роли в команде разработчиков Ролевая модель Белбина, переложенная на команду разработчиков. Говорят, после доклада будет игра. Интересное, я зарегался 🙂 Для оффлайн посещения нужно зарегистрироваться на Timepad Онлайн трансляция на ютубе открыта без регистрации. До встречи!

Продуктовая аналитика Допустим, захотели планировать квартал с помощью Objectives & Key Results. Хотим растить метрику. 🤔Какую метрику? Почему именно эту? Как растить? Какие такие A/B тесты? Что такое контрметрики? Как понять, что вырастив целевую метрику, вы не уронили другие? Как вы знаете, я в ПК Podlodka TeamLead Crew. Иногда наблюдаю за тем, что делают ребята в соседних Crew. Не смог пройти мимо, потому что следующий сезон Product Crew — про аналитику! В спикерах Unit Lead A/B платформы Авито — Данила Ленков! И другие крутые ребята из Ozon, Tinkoff, Booking, Many Chat и др. Старт — 26 сентября. Podlodka Crew — это zoom-сессии в 10 утра и в 19 вечера по Мск. В конце сессии каждый может ворваться к спикерам и задать свой вопрос. Еще значимая часть конфы это нетворкинг в slack-пространстве. Сейчас ценник 4400р и это топ за свои деньги! 🙂 Купить билет можно на сайте.

​​OKR — Objectives & Key Results В комментах к прошлому посту спросили, что это за рунглиш такой — ОКР. В двух словах — квартальные планы. Сейчас как раз период планирования OKR на следующий квартал. Решил рассказать подробнее. Для меня как для разработчика всегда было важно, зачем я что-то разрабатываю. Как именно мой код превращается в профит для компании. Для этого мне нужно понимать, какой именно профит хочет компания. Большая компания — как живой организм с независимыми органами. Компании важно понимать, куда она развивается. Для этого ей нужно синхронизировать развитие отдельных органов. Компания может поставить глобальную цель. Например, «Рост лояльности и удержание аудитории». Каждый бизнес-юнит поставит себе более локальную цель, влияющую на общую цель компании. И декомпозирует её в ключевые результаты. Примеры: 1️⃣ Цель — Вырастить или сократить какую-то метрику. Ключевой результат: — Целевой показатель метрики. 2️⃣ Цель — Сэкономить на расходах по существующим фичам. Ключевой результат: — Цифра сокращения расходов, типа «Минус 1 млн/сутки на смс в сценарии Х» 3️⃣ Цель — Заработать на новой фиче «Х». Ключевые результаты: — Прототип фичи — Полный успешный сценарий — Обработка негативных сценариев и корнер-кейсов — Раскатка на массового пользователя * В теории каждый этап помещается в спринт и тогда ключевые результаты фактически становятся целями спринтов. Сейчас третий в моей жизни подход к формированию OKR. Могу сказать, что хорошо, когда есть процесс, который раз в квартал заставляет поднять голову от операционки, подумать стратегически и составить себе верхнеуровневый план на следующие 3 месяца. Это дает почву под ногами. Если вы подумываете завести в своей компании/команде OKR или думаете как улучшить текущие подходы к OKR, то советую конфу OKR-Форум. Там будут выступать уважаемые мной Денис Дудоров из Авито и Максим Спиридонов. https://okrforum.ru

Как мы решили, что такое фича-драйвинг Предпосылки такие: 1. есть непроработанный бэклог на год вперед, в нем 10 крупных фич 2. целевой состав — 2 команды, 2 тимлида, 2 продакта 3. в наличии — 2 команды, 1 тимлид, 1 продакт Конечно, продакта и меня не хватает на две команы. Поэтому мы делегируем разработчикам проработку и техническое лидерство по фичам. Для нас это помощь, а для разработчиков — возможность проявить лидерство и вырасти. Когда я только пришел в команду, ребята знали про фича-драйвинг, но не знали про ожидания. В конфлюенсе мы нашли 5 похожих страниц с описанием ожиданий от фича-драйвера в разных юнитах, но всё не то. Ну и потом, это же чужие правила игры. Играть интереснее, когда сам устанавливаешь правила. Нужно было провести брейшнторм-сессию, где ребята сами бы накидали пунктов, на что они готовы и что они ждут друг от друга как от фича-драйверов. Проводили в формате 1-2-4-all: Каждый накидал свои ожидания, потом объединяли их в двойках и в четверках, потом все вместе. В конце всем вместе очень важно было отсечь те ожидания, которым не все были готовы соответствовать. Это как с Definition of Done: если не выполнять хотя бы один пункт, то со временем весь DoD перестанет работать. В итоге собрали такие ожидания от роли Feature Driver: 1️⃣ Ответственность за проработку — Mini Product Owner • Точка входа для продакта • Управляет проектом фичи: темп, сроки, исполнители, риски • Следит за ОКР. Поддерживает и ведет измеримые параметры прогресса выполнения задачи 2️⃣ Коммуникация — Mini TeamLead • Создает канал коммуникации и приглашает всех заинтересованных лиц • Понимает, какой результат хотят получить стейкхолдеры фичи • Взаимодействует с внешними командами / экспертами при работе над задачей • Сообщает о проблемах команде, продакту и тимлиду • Умеет представлять публичный результат 3️⃣ Техническое лидерство — Mini TechLead • Прорабатывает верхнеуровневую схему проекта. Ведет бэклог фичи • Организует груминги, брейнштормы. Приносит варианты на брейншторм • Поддерживает декомпозицию и контролирует взаимодействие компонентов • Приносит задачи на планирование. Контролирует порядок и сроки выполнения тасок Сейчас все фичи и технические цели на ближайшие 1-2 квартала распределены по фича-драйверам. При этом они сами получают кайф от ответственности и влияния на продукт. А мне как тимлиду офигенно наблюдать за тем, как команда самостоятельно решает вопросики 🙂

​​Feature Leader — роль в команде разработчиков Бывает вот такое, что разработчик считает фичу «своей». Не в плане того, что только он её кодит, а в плане ментальной принадлежности. Всячески её прорабатывает вместе с продактом, лидирует проработку-разработку с остальными инженерами. Координирует интеграцию разных компонентов и тестирование фичи. Потом катит в прод и смотрит, как зашло пользователям и как повлияло на метрики. Я наблюдаю за таким явлением в продуктовой разработке вот уже 5-7 лет. Проявлялось явление на трех разных местах работы. Процесс и результат фича-лидерства может задействовать мотиваторы достижений, причастности, признания. Кажется, что такое поведение каким-то образом самоподкрепляется человеческим мозгом. Кажется, что для компании это тоже очень полезно. Но я раньше не видел системного подкрепления фича-лидерства со стороны компании. Ну то есть точечно видел, когда руководитель замечает и поощряет проактивных ребят. Но это не системно и не транслируется на уровне компании. А значит, явление зарождается случайно и так же может затухнуть. И вот в Авито это явление нашло подкрепление на уровне ожиданий от инженера, выполнение которых влияет на оценку на перформанс ревью и повышение. Конкретная строчка из Avito Playbook на уровне Е5 (сеньорный грейд): Регулярно выступает в роли фича-лида. Отвечает за полную реализацию фичи: декомпозицию, контроль сроков и качества, доставку до пользователей. Таким образом, мидл-инженер понимает, что фича-лидерство это прямой путь к промо. Но между мидлом и сеньором есть еще качественный сдвиг майндсета. Прикол в том, что фича-лидерство помогает этот сдвиг совершить, прокачивая ответственность за продукт, а не только за код. Сейчас в разработке или ближайшем бэклоге 10+ крупных фич. Я как тимлид не справился бы все прорабатывать, поэтому все фичи распределены на ответственных инженеров. В следующем посте напишу подробнее: — как мы заводили фича-драйвинг в команде — какие ожидания от фича-драйвера определила команда Спойлер на скриншоте из Miro 🙂