Product Developer

2022-08-22 09:30:01 Как мы решили, что такое фича-драйвинг

Предпосылки такие:
1. есть непроработанный бэклог на год вперед, в нем 10 крупных фич
2. целевой состав — 2 команды, 2 тимлида, 2 продакта
3. в наличии — 2 команды, 1 тимлид, 1 продакт

Конечно, продакта и меня не хватает на две команы. Поэтому мы делегируем разработчикам проработку и техническое лидерство по фичам. Для нас это помощь, а для разработчиков — возможность проявить лидерство и вырасти.

Когда я только пришел в команду, ребята знали про фича-драйвинг, но не знали про ожидания.
В конфлюенсе мы нашли 5 похожих страниц с описанием ожиданий от фича-драйвера в разных юнитах, но всё не то. Ну и потом, это же чужие правила игры. Играть интереснее, когда сам устанавливаешь правила.
Нужно было провести брейшнторм-сессию, где ребята сами бы накидали пунктов, на что они готовы и что они ждут друг от друга как от фича-драйверов.

Проводили в формате 1-2-4-all:
Каждый накидал свои ожидания, потом объединяли их в двойках и в четверках, потом все вместе.
В конце всем вместе очень важно было отсечь те ожидания, которым не все были готовы соответствовать.
Это как с Definition of Done: если не выполнять хотя бы один пункт, то со временем весь DoD перестанет работать.

В итоге собрали такие ожидания от роли Feature Driver:

Ответственность за проработку — Mini Product Owner
• Точка входа для продакта
• Управляет проектом фичи: темп, сроки, исполнители, риски
• Следит за ОКР. Поддерживает и ведет измеримые параметры прогресса выполнения задачи
Коммуникация — Mini TeamLead
• Создает канал коммуникации и приглашает всех заинтересованных лиц
• Понимает, какой результат хотят получить стейкхолдеры фичи
• Взаимодействует с внешними командами / экспертами при работе над задачей
• Сообщает о проблемах команде, продакту и тимлиду
• Умеет представлять публичный результат
Техническое лидерство — Mini TechLead
• Прорабатывает верхнеуровневую схему проекта. Ведет бэклог фичи
• Организует груминги, брейнштормы. Приносит варианты на брейншторм
• Поддерживает декомпозицию и контролирует взаимодействие компонентов
• Приносит задачи на планирование. Контролирует порядок и сроки выполнения тасок

Сейчас все фичи и технические цели на ближайшие 1-2 квартала распределены по фича-драйверам.
При этом они сами получают кайф от ответственности и влияния на продукт.
А мне как тимлиду офигенно наблюдать за тем, как команда самостоятельно решает вопросики Открыть/Комментировать

2022-08-15 09:30:00 ​​Feature Leader — роль в команде разработчиков

Бывает вот такое, что разработчик считает фичу «своей». Не в плане того, что только он её кодит, а в плане ментальной принадлежности. Всячески её прорабатывает вместе с продактом, лидирует проработку-разработку с остальными инженерами. Координирует интеграцию разных компонентов и тестирование фичи. Потом катит в прод и смотрит, как зашло пользователям и как повлияло на метрики.

Я наблюдаю за таким явлением в продуктовой разработке вот уже 5-7 лет. Проявлялось явление на трех разных местах работы. Процесс и результат фича-лидерства может задействовать мотиваторы достижений, причастности, признания.

Кажется, что такое поведение каким-то образом самоподкрепляется человеческим мозгом. Кажется, что для компании это тоже очень полезно. Но я раньше не видел системного подкрепления фича-лидерства со стороны компании.

Ну то есть точечно видел, когда руководитель замечает и поощряет проактивных ребят. Но это не системно и не транслируется на уровне компании. А значит, явление зарождается случайно и так же может затухнуть.

И вот в Авито это явление нашло подкрепление на уровне ожиданий от инженера, выполнение которых влияет на оценку на перформанс ревью и повышение.
Конкретная строчка из Avito Playbook на уровне Е5 (сеньорный грейд):

Регулярно выступает в роли фича-лида. Отвечает за полную реализацию фичи: декомпозицию, контроль сроков и качества, доставку до пользователей.

Таким образом, мидл-инженер понимает, что фича-лидерство это прямой путь к промо. Но между мидлом и сеньором есть еще качественный сдвиг майндсета. Прикол в том, что фича-лидерство помогает этот сдвиг совершить, прокачивая ответственность за продукт, а не только за код.

Сейчас в разработке или ближайшем бэклоге 10+ крупных фич. Я как тимлид не справился бы все прорабатывать, поэтому все фичи распределены на ответственных инженеров.

В следующем посте напишу подробнее:
— как мы заводили фича-драйвинг в команде
— какие ожидания от фича-драйвера определила команда

Спойлер на скриншоте из Miro Открыть/Комментировать

2022-07-22 19:30:18 Попал в подкаст DevOne — Выпуск про развитие разработчика

Собрались как-то 4 мемеджера из QIWI, Авито и OZON, чтобы поговорить про горизонтальный и вертикальный рост в разработке. Как будто сами когда-то были инженерами и понимают что-то в росте инженеров)

Разобрались, чем отличается «вширь», «вглубь» и «в мемеджеры».
Задались экзистенциальным вопросом, сколько лет нужно для того чтобы стать сеньором: 10, 5 или 2.
А еще речь зашла про денежки и ожидания от сеньор-помидора в Авито

Послушать можно по ссылке:
https://devone.mave.digital/ep-3 Открыть/Комментировать

2022-07-12 19:38:54 ​​TeamLead Meetup

Давненько не было ламповых оффлайновых митапов. А тем более давненько я сам в оффлайне ничего не вёл. И вот Авито организует сходку тимлидов.

А я там буду ведущим и модератором дискуссий.

Доклады:

1. Чего ждут коллеги разных уровней от тимлида?
Будет полезен тимлидам, чтобы понять, чего же от них все хотят.

2. Как осознать себя в роли руководителя тимлидов?
Будет полезен тем, кто уже задумывается «а что там дальше?»

Приходите послушать ребят из Авито, СберЗдоровья, Skyeng, Тинькофф и Ozon! Всё бесплатно, будет онлайн и оффлайн. Для оффлайна нужно зарегистрироваться на timepad. Количество мест ограничено, спешите успеть!)

Офис Авито на Белорусской, 26 июля в 18:30 Открыть/Комментировать

2022-07-06 15:23:37 Бесплатный курс iOS QA Automation

Раз мы тут заговорили о роли QA в Авито, то вот отличный пример — QA инженер из соседней команды обучает автоматизации тестирования под iOS.

Борис делится экспертизой:
— Пишет статьи на хабре;
— Ведёт канал в телеге iOS Automation Testing;
— Выложил в открытый доступ свой курс iOS Automation. Этот курс создан для того, чтобы Manual QA поняли, как писать ui-тесты на iOS.

Во-первых, рекомендую подписаться на канал.
Во-вторых, с радостью рассмотрим опытных ручных тестировщиков, которые прошли курс Бориса

https://t.me/ios_automation_testing/189 Открыть/Комментировать

2022-07-04 19:06:38 Ищу Mobile QA к себе в команду

В продолжение предыдущего поста. Вот уже 3 месяца мы ищем редкого специалиста. Позволю себе впервые использовать канал с этой целью.

Кстати, наш iOS разработчик — один из олдов этого канала. Есть возможность составить ему хорошую компанию, ну и со мной поработать

Мы тут делаем Авито Паспорт. Это тектонический сдвиг в том, как Авито работает с аутентификацией и профилями пользователей.

У нас есть сильный QA с опытом в бэке и вебе.
А вот в мобилки мы не умеем.
Ищем человека, который научит.

От кандидата ждём:
— Желание и умение прорабатывать фичи на ранних этапах
— Опыт в тестировании мобилок, которым готов делиться
— Kotlin / Java и (или) Swift
— Желание делиться знаниями. Все фичи сам не протестишь

Про задачи, условия, плюшки и рефералку подробно расскажу в лс: @nikita_development

Почитать вакансию на карьерном сайте: https://www.avito.ru/company/job/qa_pssprt Открыть/Комментировать

2022-07-04 09:27:47 Разрабы vs. Тестеры

Вот мы делаем продукт. Все понимают: «Надо делать качественно».
Прикол в том, что это в этой фразе слово «качественно» — абстрактное понятие, которое каждый понимает по-своему.

Нипанятна. От меня вот фичу требуют, пойду лучше её запилю.

Ок, давайте наймём отдел QA. Пусть обеспечивают это самое качество. Им виднее, что это такое. На вход им дадим результат работы отдела разработки.

Наняли. Стало ли качественнее? Ну наверное. Релизы помедленнее стали выходить, вроде. Но вроде и да, багов меньше…

Как понять, что они свой хлеб не зря едят? Ну давайте KPI введем. Например, на количество найденных багов. Чем больше нашел, тем больше премия.

А программистам введем такой же KPI, только в обратную сторону. Чем больше багов, тем меньше премия.

И да начнётся битва, в которой не будет победителей!

Пока разрабы дерутся с тестерами за баги, пользователи грустят в ожидании фич, а бизнес теряет бабки на эту вот внутреннюю борьбу вместо того, чтобы зарабатывать их на новой фиче.

=============================

Agile Shift Left Testing

Чем раньше баг будет найден, тем он дешевле для бизнеса. Чем раньше фича будет выкачена в прод, — тем раньше бизнес начнет на ней зарабатывать бабки.

Последние несколько лет я думаю, как можно работать с QA на ранних этапах.
Пришел в Авито, а тут оказывается уже придумали.

Agile Shift Left Testing даёт максимально раннее обнаружение багов. В одном спринте нашли баги новой фичи, починили и покатили в релиз. Таким образом сокращаем Time To Market при сохранении качества.

Концепт звучит просто: QA — часть кроссфункциональной команды, и участвует на всех этапах жизненного цикла фичи, начиная с проработки задачи.

На деле всё чуть сложнее. Сходу упираемся в то, что в кроссфункциональной команде не помещаются несколько QA. Плюс, платформ дофига: 2 мобильных, десктоп и мобильный веб, а еще бэкенды. Один QA не вытащит это всё тестить руками или покрывать тестами.

Получается, надо вовлекать разработчиков.

QA инженер с точки зрения Agile Testing — главный стекхолдер качества внутри команды, который знает ответ на вопрос «что такое качество?».

При этом основная задача QA — не тестить всё самому, а:
— Менторить разработчиков в написании тест-кейсов
— Показывать своим примером, как нужно писать e2e тесты
— Следить, чтобы пирамида выглядела как пирамида

В наших командах разработчики уже сейчас пишут тест-кейсы на этапе декомпозиции фичи, а часть слоев тестов зафиксированы в Definition of Done. И пишут их не только QA, а все инженеры.

KPI при этом отстутствуют. Но есть квартальные планы, которые нужно разработать с заданным в DoD уровнем качества. А еще есть Zero Bug Policy. Это когда мы либо фиксим баг в ближайшее время, либо осознанно говорим, что не будем его исправлять.

Прямо своими глазами наблюдаю, как разработчики вовлекаются в это самое качество и закладывают время внутри спринта на написание тестов, ручное тестирование после интеграции и починку всплывших багов.

Кажется, Agile Testing — это ответ. А какой был ваш вопрос?

Подробнее можно почитать в стате на хабре:
https://habr.com/ru/company/avito/blog/458940/ Открыть/Комментировать

2022-06-21 21:05:17 Привет, есть две офигенные новости!


— Я тут вписался в программный комитет Podlodka Teamlead Crew: Change Management.

Это будет неделя качественных докладов про управление изменениями в команде. Поговорим о том, как понять, что изменения нужны и какие именно. Как их внедрять, работать с сопротивлениями и возражениями. Будут реальные инструменты и фреймворки. А еще будет сессия разбора фейлов. Приходите!)
Стартует 27 июня. Билеты тут: https://podlodka.io/tlcrew. Для своих есть промокод product_developer.


— В преддверии сезона мы делаем открытую бесплатную сессию — публичное собеседование на роль тимлида.
23 июня в 19:00.

Интервьюер — мой коллега, Женя Рейх из Авито.
Technical Cluster Lead, менеджер менеджеров тимлидов, Bar Raiser в собеседованиях тимлидов в Авито. Когда я собеседовался в Авито, эта секция мне понравилась больше всего. И я хочу показать миру, насколько круто собеседуют тимлидов в Авито

Кандидат — мой бывший коллега по Райфу и Слёрму, Лёша Ломаев.
Техлид трёх команд в Райффайзене. Человек, репортящий напрямую СТО. Адепт гибких методологий в продуктовой разработке.
Что примечательно — Лёша собеседовал меня в Райффайзен

В процессе интервью Женя будет рассказывать зрителям, зачем он задает такие вопросы. А Лёша даст свои комментарии, пошел бы он работать в компанию, где от кандидатов требуют такое.

Ссылка на трансляцию


Стартуем 23 июня в 19:00 Открыть/Комментировать

2022-05-30 09:30:01 Как развивать процессы в команде

В любой команде есть процессы, даже если они нигде не описаны. Это может быть процесс уровня "спросить у тимлида" по любому вопросу, но это тоже процесс.
При этом мало кому интересно работать в незрелой команде. Процессы — гигиенический фактор, отсутствие которого приводит к демотивации.

Даже если процессы отлажены и описаны, всегда можно что-то улучшить. Вопрос, что именно и как можно сделать лучше. Иногда мы находимся в зоне неосознанной некомпетентности по процессным вопросам, и не понимаем, что именно стоит улучшать и как именно.

Это может быть очевидно, прямо на кончиках пальцев. Например, "Мы не используем на фронте компоненты дизайн-системы, из-за этого дольше создаем компоненты, а потом тратим время на их поддержку". Очевидное решение — начать использовать компоненты дизайн-системы, если она есть. Или инициировать её создание в компании, если нет.

А может быть не так очевидно. Например, у нас потихоньку выгорает один из разработчиков из-за непонимания собственного вклада, но это никак не проявляется. Это можно выяснить на 1-1, а можно и проморгать. Решением могло бы быть внедрение короткого healthcheck-опросника перед ретроспективой. Мы третий спринт проводим такой опросник и за его результатами интересно наблюдать в динамике. Когда наберется хотя бы 5 результатов, поделюсь.

Уровень зрелости процессов в разных командах разный. И улучшения могут быть разные.

Team Maturity Model — модель зрелости команды, инструмент для осознания текущего уровня зрелости, понимания векторов развития и конкретных шагов по улучшению процессов.
Сейчас в Авито это реализовано как убер-экселька, в которой перечислены разные области командных процессов: InfoSec, QA, FE, BE, Perf., Delivery, Discovery, Analytics, Design.

Прошлый пост с Авитошной экселькой Windrose Template пошарили 54 раза (нифига себе).
Поэтому вот еще одна убер-экселька: Модель зрелости Авито в гугл-документе.
Как ею пользоваться — читайте в статье на хабре: Модель зрелости: как оценивать и растить инженерные команды Открыть/Комментировать

2022-05-24 09:30:00 Windrose template для собственного развития

В комментах к прошлому посту просили эксельку, в которой можно построить розу ветров, чтобы определить вектор развития. Я сначала думал, что Авитошная никому особо не пригодится, потому что везде свои матрицы компетенций. А вот фиг. За прошедшие 2 недели на hl++ и на tlconf общался с ребятами из разных компаний и узнал что 5 человек использовали Авитошные матрицы как референс. Значит, можно поделиться as is.

В общем, держите: Avito Windrose Template
Согласовать внутри это было легко. Особенно, с учетом того, что сами компетенции есть в публичном playbook на гитхабе.
Документ read-only, чтоб случайно не попортили.
Можно скопировать себе и заполнить, построить windrose и определить вектор развития Открыть/Комментировать