Product Developer

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 🙂

Попал в подкаст DevOne — Выпуск про развитие разработчика Собрались как-то 4 мемеджера из QIWI и OZON, чтобы поговорить про горизонтальный и вертикальный рост в разработке. Как будто сами когда-то были инженерами и понимают что-то в росте инженеров) Разобрались, чем отличается «вширь», «вглубь» и «в мемеджеры». Задались экзистенциальным вопросом, сколько лет нужно для того чтобы стать сеньором: 10, 5 или 2. А еще речь зашла про денежки и ожидания от сеньор-помидора в Авито 🙂 Послушать можно по ссылке: https://podcast.ru/e/3Ma4kSKg.v-

​​TeamLead Meetup Давненько не было ламповых оффлайновых митапов. А тем более давненько я сам в оффлайне ничего не вёл. И вот Авито организует сходку тимлидов. А я там буду ведущим и модератором дискуссий. Доклады: 1. Чего ждут коллеги разных уровней от тимлида? Будет полезен тимлидам, чтобы понять, чего же от них все хотят. 2. Как осознать себя в роли руководителя тимлидов? Будет полезен тем, кто уже задумывается «а что там дальше?» Приходите послушать ребят из Авито, СберЗдоровья, Skyeng, Тинькофф и Ozon! Всё бесплатно, будет онлайн и оффлайн. Для оффлайна нужно зарегистрироваться на timepad. Количество мест ограничено, спешите успеть!) Офис Авито на Белорусской, 26 июля в 18:30

Бесплатный курс iOS QA Automation Раз мы тут заговорили о роли QA в Авито, то вот отличный пример — QA инженер из соседней команды обучает автоматизации тестирования под iOS. Борис делится экспертизой: — Пишет статьи на хабре; — Ведёт канал в телеге iOS Automation Testing; — Выложил в открытый доступ свой курс iOS Automation. Этот курс создан для того, чтобы Manual QA поняли, как писать ui-тесты на iOS. Во-первых, рекомендую подписаться на канал. Во-вторых, с радостью рассмотрим опытных ручных тестировщиков, которые прошли курс Бориса 🙂 https://t.me/ios_automation_testing/189

Ищу Mobile QA к себе в команду В продолжение предыдущего поста. Вот уже 3 месяца мы ищем редкого специалиста. Позволю себе впервые использовать канал с этой целью. Кстати, наш iOS разработчик — один из олдов этого канала. Есть возможность составить ему хорошую компанию, ну и со мной поработать 🙂 Мы тут делаем Авито Паспорт. Это тектонический сдвиг в том, как Авито работает с аутентификацией и профилями пользователей. У нас есть сильный QA с опытом в бэке и вебе. А вот в мобилки мы не умеем. Ищем человека, который научит. От кандидата ждём: — Желание и умение прорабатывать фичи на ранних этапах — Опыт в тестировании мобилок, которым готов делиться — Kotlin / Java и (или) Swift — Желание делиться знаниями. Все фичи сам не протестишь 🙂 Про задачи, условия, плюшки и рефералку подробно расскажу в лс: @nikita_development Почитать вакансию на карьерном сайте: https://www.avito.ru/company/job/qa_pssprt

Разрабы vs. Тестеры Вот мы делаем продукт. Все понимают: «Надо делать качественно». Прикол в том, что это в этой фразе слово «качественно» — абстрактное понятие, которое каждый понимает по-своему. Нипанятна. От меня вот фичу требуют, пойду лучше её запилю. Ок, давайте наймём отдел QA. Пусть обеспечивают это самое качество. Им виднее, что это такое. На вход им дадим результат работы отдела разработки. Наняли. Стало ли качественнее? Ну наверное. Релизы помедленнее стали выходить, вроде. Но вроде и да, багов меньше… Как понять, что они свой хлеб не зря едят? Ну давайте KPI введем. Например, на количество найденных багов. Чем больше нашел, тем больше премия. А программистам введем такой же KPI, только в обратную сторону. Чем больше багов, тем меньше премия. И да начнётся битва, в которой не будет победителей! 😄 Пока разрабы дерутся с тестерами за баги, пользователи грустят в ожидании фич, а бизнес теряет бабки на эту вот внутреннюю борьбу вместо того, чтобы зарабатывать их на новой фиче. ============================= Agile Shift Left Testing Чем раньше баг будет найден, тем он дешевле для бизнеса. Чем раньше фича будет выкачена в прод, — тем раньше бизнес начнет на ней зарабатывать бабки. Последние несколько лет я думаю, как можно работать с QA на ранних этапах. Пришел в Авито, а тут оказывается уже придумали. Agile Shift Left Testing даёт максимально раннее обнаружение багов. В одном спринте нашли баги новой фичи, починили и покатили в релиз. Таким образом сокращаем Time To Market при сохранении качества. Концепт звучит просто: QA — часть кроссфункциональной команды, и участвует на всех этапах жизненного цикла фичи, начиная с проработки задачи. На деле всё чуть сложнее. Сходу упираемся в то, что в кроссфункциональной команде не помещаются несколько QA. Плюс, платформ дофига: 2 мобильных, десктоп и мобильный веб, а еще бэкенды. Один QA не вытащит это всё тестить руками или покрывать тестами. Получается, надо вовлекать разработчиков. QA инженер с точки зрения Agile Testing — главный стекхолдер качества внутри команды, который знает ответ на вопрос «что такое качество?». При этом основная задача QA — не тестить всё самому, а: 1️⃣ — Менторить разработчиков в написании тест-кейсов 2️⃣ — Показывать своим примером, как нужно писать e2e тесты 3️⃣ — Следить, чтобы пирамида выглядела как пирамида В наших командах разработчики уже сейчас пишут тест-кейсы на этапе декомпозиции фичи, а часть слоев тестов зафиксированы в Definition of Done. И пишут их не только QA, а все инженеры. KPI при этом отстутствуют. Но есть квартальные планы, которые нужно разработать с заданным в DoD уровнем качества. А еще есть Zero Bug Policy. Это когда мы либо фиксим баг в ближайшее время, либо осознанно говорим, что не будем его исправлять. Прямо своими глазами наблюдаю, как разработчики вовлекаются в это самое качество и закладывают время внутри спринта на написание тестов, ручное тестирование после интеграции и починку всплывших багов. Кажется, Agile Testing — это ответ. А какой был ваш вопрос? 🙂 Подробнее можно почитать в стате на хабре: https://habr.com/ru/company/avito/blog/458940/

Привет, есть две офигенные новости! 1️⃣ — Я тут вписался в программный комитет Podlodka Teamlead Crew: Change Management. Это будет неделя качественных докладов про управление изменениями в команде. Поговорим о том, как понять, что изменения нужны и какие именно. Как их внедрять, работать с сопротивлениями и возражениями. Будут реальные инструменты и фреймворки. А еще будет сессия разбора фейлов. Приходите!) Стартует 27 июня. Билеты тут: https://podlodka.io/tlcrew. Для своих есть промокод product_developer. 2️⃣ — В преддверии сезона мы делаем открытую бесплатную сессию — публичное собеседование на роль тимлида. 23 июня в 19:00. Интервьюер — мой коллега, Женя Рейх из Авито. Technical Cluster Lead, менеджер менеджеров тимлидов, Bar Raiser в собеседованиях тимлидов в Авито. Когда я собеседовался в Авито, эта секция мне понравилась больше всего. И я хочу показать миру, насколько круто собеседуют тимлидов в Авито 🙂 Кандидат — мой бывший коллега по Райфу и Слёрму, Лёша Ломаев. Техлид трёх команд в Райффайзене. Человек, репортящий напрямую СТО. Адепт гибких методологий в продуктовой разработке. Что примечательно — Лёша собеседовал меня в Райффайзен 🙂 В процессе интервью Женя будет рассказывать зрителям, зачем он задает такие вопросы. А Лёша даст свои комментарии, пошел бы он работать в компанию, где от кандидатов требуют такое. Ссылка на трансляцию https://youtu.be/P2-GwwJsfIM Стартуем 23 июня в 19:00

Как развивать процессы в команде В любой команде есть процессы, даже если они нигде не описаны. Это может быть процесс уровня "спросить у тимлида" по любому вопросу, но это тоже процесс. При этом мало кому интересно работать в незрелой команде. Процессы — гигиенический фактор, отсутствие которого приводит к демотивации. Даже если процессы отлажены и описаны, всегда можно что-то улучшить. Вопрос, что именно и как можно сделать лучше. Иногда мы находимся в зоне неосознанной некомпетентности по процессным вопросам, и не понимаем, что именно стоит улучшать и как именно. Это может быть очевидно, прямо на кончиках пальцев. Например, "Мы не используем на фронте компоненты дизайн-системы, из-за этого дольше создаем компоненты, а потом тратим время на их поддержку". Очевидное решение — начать использовать компоненты дизайн-системы, если она есть. Или инициировать её создание в компании, если нет. А может быть не так очевидно. Например, у нас потихоньку выгорает один из разработчиков из-за непонимания собственного вклада, но это никак не проявляется. Это можно выяснить на 1-1, а можно и проморгать. Решением могло бы быть внедрение короткого healthcheck-опросника перед ретроспективой. Мы третий спринт проводим такой опросник и за его результатами интересно наблюдать в динамике. Когда наберется хотя бы 5 результатов, поделюсь. Уровень зрелости процессов в разных командах разный. И улучшения могут быть разные. Team Maturity Model — модель зрелости команды, инструмент для осознания текущего уровня зрелости, понимания векторов развития и конкретных шагов по улучшению процессов. Сейчас в Авито это реализовано как убер-экселька, в которой перечислены разные области командных процессов: InfoSec, QA, FE, BE, Perf., Delivery, Discovery, Analytics, Design. Прошлый пост с Авитошной экселькой Windrose Template пошарили 54 раза (нифига себе). Поэтому вот еще одна убер-экселька: Модель зрелости Авито в гугл-документе. Как ею пользоваться — читайте в статье на хабре: Модель зрелости: как оценивать и растить инженерные команды🙂

Windrose template для собственного развития В комментах к прошлому посту просили эксельку, в которой можно построить розу ветров, чтобы определить вектор развития. Я сначала думал, что Авитошная никому особо не пригодится, потому что везде свои матрицы компетенций. А вот фиг. За прошедшие 2 недели на hl++ и на tlconf общался с ребятами из разных компаний и узнал что 5 человек использовали Авитошные матрицы как референс. Значит, можно поделиться as is. В общем, держите: Avito Windrose Template Согласовать внутри это было легко. Особенно, с учетом того, что сами компетенции есть в публичном playbook на гитхабе. Документ read-only, чтоб случайно не попортили. Можно скопировать себе и заполнить, построить windrose и определить вектор развития 😉