Попал в подкаст DevOne — Выпуск про развитие разработчика

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

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

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

​​Feature Leader — роль в команде разработчиков

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

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

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

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

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

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

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

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

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

Спойлер на скриншоте из Miro 🙂

Как мы решили, что такое фича-драйвинг

Предпосылки такие:
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 квартала распределены по фича-драйверам.
При этом они сами получают кайф от ответственности и влияния на продукт.
А мне как тимлиду офигенно наблюдать за тем, как команда самостоятельно решает вопросики 🙂

​​OKR — Objectives & Key Results

В комментах к прошлому посту спросили, что это за рунглиш такой — ОКР.
В двух словах — квартальные планы. Сейчас как раз период планирования OKR на следующий квартал. Решил рассказать подробнее.

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

Большая компания — как живой организм с независимыми органами. Компании важно понимать, куда она развивается. Для этого ей нужно синхронизировать развитие отдельных органов.

Компания может поставить глобальную цель. Например, «Рост лояльности и удержание аудитории». Каждый бизнес-юнит поставит себе более локальную цель, влияющую на общую цель компании. И декомпозирует её в ключевые результаты.

Примеры:

1️⃣ Цель — Вырастить или сократить какую-то метрику.
Ключевой результат:
— Целевой показатель метрики.

2️⃣ Цель — Сэкономить на расходах по существующим фичам.
Ключевой результат:
— Цифра сокращения расходов, типа «Минус 1 млн/сутки на смс в сценарии Х»

3️⃣ Цель — Заработать на новой фиче «Х».
Ключевые результаты:
— Прототип фичи
— Полный успешный сценарий
— Обработка негативных сценариев и корнер-кейсов
— Раскатка на массового пользователя
* В теории каждый этап помещается в спринт и тогда ключевые результаты фактически становятся целями спринтов.


Сейчас третий в моей жизни подход к формированию OKR. Могу сказать, что хорошо, когда есть процесс, который раз в квартал заставляет поднять голову от операционки, подумать стратегически и составить себе верхнеуровневый план на следующие 3 месяца. Это дает почву под ногами.

Каково это — приходить сразу тимлидом на новое место

Стать тимлидом изнутри в каком-то смысле проще: ты всё знаешь внутри компании, тебя все знают.
А вот прийти снаружи сразу на менеджерскую позицию — целый квест.

0. Как выбрать нового работодателя, если ты тимлид?
В разных компаниях разные ожидания от тимлида и разные процессы. Никому не хочется попасть в место, где от тебя ожидают 80% управления людьми и 80% кодинга.

1. Вдруг команда не примет?
Моего предшественника в Райфе ребята выперли в первый месяц 🙂
Мне повезло больше, но что в этом помогло? Что именно я сделал правильно?

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

3. Или не оправдаешь ожиданий руководителя?
После выхода на работу в Авито мне нужно было сразу построить планы на квартал для команды, а критериями ИС было выполнение этих планов. А еще выполнение 90% целей спринтов и не более 20% Scope Drop.

Я прошел через онбординг тимлидом в новую компанию. А теперь делаю про это сезон Podlodka Teamlead Crew в составе программного комитета.

Стартуем 7 ноября. Онлайн. Сессии в 10 и в 19 по Москве.

Лендос про конференцию и кнопка «Купить билет»

Кстати, о чем бы вы спросили будущего работодателя?
Пишите в комментах и получите бесплатную проходку на конфу.

Итоги года

В прошлом году был пост 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+ (сеньор) инженера.

Итог и пожелания

В прошлом году я пожелал вам грести целенаправленно, а не плыть по течению. Составлять план развития, идти по нему.

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

Трудно было всем, но я заметил что проще иметь четкое понимание, какими будут твои действия при каком развитии событий.

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

Желаю каждому иметь план действий и критерии применения. Тогда будет место в голове для мыслей о профессиональном развитии.

Что такое груминг?

За последние 5 лет повидал около 5 разных вариантов груминга. Подумалось тут, что этот процесс у меня болел всегда. Всегда был чем-то неидеален и кому-то из участников не нравился. Участники видят этот процесс по-разному, потому что каждый тащит за собой багаж прошлого опыта и убеждений. Например «на груминге мы должны оценивать задачу. Если задача не готова к оценке — нельзя тратить на нее время. Так в этом вашем скраме написано». Кек, не написано. Вообще в скрамгайде ничего про груминг не написано.

Если честно, ненавижу слово груминг. Кто-то счёл разумным назвать процесс «причесыванием бэклога», по аналогии с уходом за животными. (англ groom — ухаживать). У меня каждый раз ассоциация только с тем как обезьяны чистят шерсть друг друга от паразитов. Это реальный первоисточник термина груминг, погуглите. А еще можно нагуглить "Cyber Grooming», это что-то из разряда «ЦП в ЛС». Короче, не нравится мне слово груминг.

Термин из книги — Product Backlog Refinement (PBR).
Уточнение бэклога. Непонятно. И в скрамгайде всего одно упоминание (sic!):
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a denoscription, order, and size. Attributes often vary with the domain of work.

Окей, PBR = декомпозиция и уточнение деталей: описания, порядка и размера. Всё, дальше сами.

Ну давайте решать. Только решать надо всей командой, чтобы все понимали, зачем этот груминг и что на нем должно происходить.
Что нам нужно чтобы взять задачу в спринт? Описание поведения, критерии приемки, тест-кейсы, техническая декомпозиция до уровня «написать функцию myFunc() в классе MyClass».

Вот это перечисление — чеклист Definition of Ready.
Оценка задачи — конечный этап, на котором мы должны посмотреть в это перечисление, решить что всё понятно и сойтись в том, на какую из предыдущих задач эта похожа по объему.
Если у вас болит груминг, и вы никак не можете сойтись в оценке — скорее всего, болит не грумминг, а процесс подготовки задачи к спринту. Точнее, его неструктурированность. Непонятно — кто, что и в какой момент должен сделать.

Короче, предлагаю:
1️⃣ — Груминг называть PBR.
2️⃣ — Делать в рамках PBR всё что угодно, чтобы из абстрактных элементов продуктового бэклога подготовить конкретные элементы бэклога спринта.
3️⃣ — Не фреймиться на встречу для PBR. Это процесс. По большей части асинхронный, зачастую индивидуальный.

В следующем посте расскажу, из чего этот процесс состоит у нас, и что делаем на PBR.
Пока можете почитать опыт ребят из InDrive, у меня похожие боли и похожий путь их преодоления.
https://habr.com/ru/company/inDrive/blog/682806/

​​Как мы готовим задачи к спринту

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

Процессы как отмазка
Disclaimer: в этом посте общественной пользы нет.

Я люблю структурировать процессы. Испытываю эстетическое удовольствие, когда всё разложено по полочкам, всё идёт по плану.

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

НО. Меня люто бесят люди, которые облажались и не признают свой косяк, не делают выводов для себя и оправдываются отсутствием / недостаточной структурированностью процесса.

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

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

Но бывает, что один и тот же человек находит изъяны всех ваших процессов. Находит способ облажаться в любом действии. В котором не лажают другие. Процессы всегда не идеальны. Структурированность процессов — баланс между бюрократическим оверхедом и стремлением снизить человеческий фактор. И ради одного персонажа вы из раза в раз добавляете оверхед в процессы. А он из раза в раз находит изъяны этого процесса.

Что будете делать с таким человеком? Ведь он старается, работает, пользу приносит. Или вред?

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

Зачем нужны тимлиды?

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

Один из моих любимых вопросов на собеседовании — зачем тебе тимлид?

Ответ по сути говорит о том, что инженер ждет от меня. Интервью ведь и нужно, чтобы прояснить взаимные ожидания. Прояснить всё, что тебе нужно — ответственность каждого участника интервью. Но не все кандидаты могут сформулировать правильные вопросы. Тем не менее, неловко будет нанять человека, которому я не смогу дать то, что он хочет. Поэтому я спрашиваю и уточняю.

Самые частые ответы примерно такие:

— Не знаю, не задумывался — не ответ, надо копать дальше другими вопросами.

— Задачи заводить и распределять. Здесь еще важно узнать, какой гранулярности задачи хочет получать человек. Честно говоря, моя идеальная команда сама заводит таски в джире и сама их распределяет 🙂 Мне важно, чтобы крупные стримы размером с квартал оказались под крылом нужных людей.

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

— Конфликты решать. Вот тут может быть либо конфликтный / притягивающий конфликты кандидат, либо опять же повидавший некоторое дерьмо. Лучше бы детальнее копнуть. В моей идеальной команде конфликты — конструктивные, возникают регулярно, приводят к улучшениям и проходят без участия тимлида. Но это мечты 🙂

Потом я доуточняю: «Это всё про команду. А вот тебе лично — зачем тимлид?»
В ответ обычно:

— Развитие, карьерный рост. Очевидно, но каким образом? А как кандидат сам развивается?

— Обратная связь. Вот тут вопросов нет. На удивление редко это отвечают, кстати. Можно доуточнить кейс, где кандидату давали корректирующую обратную связь , и узнать, как он её применял.

— Мне не нужен тимлид. Не путать с «не знаю». Это мой любимый, идеальный ответ. Человек, который так ответил, сейчас показывает всей команде ролевую модель. И собрал 70% оценок «выше ожиданий» от сокомандников на ревью.
Сам находит себе инженерно сложные, развивающие челленджи. Может работать в неидеальных процессах. Если процессы совсем плохие — сам начнет их оптимизировать и команде продаст. Конфликты поворачивает в конструктивное русло.
Разве что обратная связь иногда нужна, чтобы свериться, что в ту сторону гребет.

Это не исчерпывающий список, но из ответов и моих комментариев можно проследить тренд: тимлиды не нужны.

Вернее, так: хороший тимлид стремится сделать так, чтобы он был не нужен в команде. Чтобы если он уходит в отпуск, ничего не менялось.
Если перформанс команды просядет, значит, что-то тащил на себе.
Если перформанс улучшится, значит мешал.

В общем, мой ответ такой: Тимлид нужен, чтобы привести команду в состояние, когда тимлид не нужен.

А вы как считаете?
Что ответили бы сами, или что вам отвечают кандидаты на вопрос «Зачем тебе тимлид?»

Пост-знакомство плюс бонус-контент

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

Итак, Канал — о продуктовой разработке изнутри, глазами инженера.

В душе я все еще инженер, хотя в трудовой — инжиниринг мемеджер.
Меня зовут Никита Хромушкин, и я тимлид тимлидов в Авито.

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

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

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

Канал призван приносить пользу.
Основная метрика, в которую целюсь — количество репостов.
Хорошим считаю такой пост, который люди сочли полезным для себя достаточно, чтобы поделиться им с другими. Например, ровно год назад я написал пост про ИПР, который репостнули 77 раз. Считаю, полезно получилось.

Изюминкой канала считаю артефакты, которыми охотно делюсь: DoR, DoD, Windrose для плана развития, всякие рисуночки-графички, схемки. Чуть позже напилю навигатор по постам с артефактами.

Вкратце, в общем, познакомились. Добро пожаловать, или снова здравствуйте.

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

Бонус-контент для старичков канала

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

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

Вот тут собраны топовые каналы топовых продактов и не только:
https://news.1rj.ru/str/addlist/YvmnHCHUp700Nzky

Если не работает — повод обновить телегу.

После добавления папка становится вашей, вы можете отписаться от каких-то каналов или добавить свои любимые.

​​О чем спросить работодателя — чеклист

Новый сотрудник — всегда двусторонняя инвестиция:

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

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

Если сотрудник уходит через 3 месяца-полгода-год, то, скорее всего, инвестиция не окупается. Часть таких увольнений происходит из-за того, что в процессе найма кандидат не убедился в том, что ему подходит компания, позиция, продукт.

Компании выстраивают мега-процессы найма, чтобы убедиться, что кандидат точно-точно подходит. На вопросы кандидата обычно закладывают 15 минут.

Мне кажется, что пропорция «час на вопросы кандидату» : «15 минут на вопросы кандидата» не справедливая. Поэтому привет и спасибо ребятам из Авито, которых я в сумме мучил около 4-5 часов прежде чем принять оффер.

О чем спрашивать — тема индивидуальная. Для кого-то важен продукт, для кого-то — процессы. Кто-то повидал некоторое дерьмо и ему важно убедиться, что такого не будет на новом месте.

На позапрошлом сезоне Podlodka Teamlead Crew мы делали брейншторм «О чем спросить работодателя»

На выходе получились два артефакта:

1⃣ Mindmap вопросов в Miro
С разбиением по этапам и возможным развилкам:
Предварительный поиск инфы, чтение вакансии, HR-скрининг, тех. интервью, встреча с руководителем.

2⃣ Чеклист вопросов в гуглодоке
С разбиением по темам: компания, проект, подходы, метрики, задачи, полномочия, руководство, команда, техника, условия.

Ну и само собой, есть запись сессии. Как член ПК, я не могу публиковать ссылку на видос, потому что он в закрытом плейлисте. Но участники сессии могут. Вот, Женя Антонов у себя в канале постил: https://news.1rj.ru/str/general_it_talks/320

Папка тимлидов

Недавно я написал пост-знакомство про этот канал. Сказал, что цель канала — приносить пользу, а основная метрика — количество репостов. Всего лишь неделю назад я считал достижением и хвастался постом на 77 репостов.

Прошлый пост «О чем спросить работодателя» собрал 245 репостов оО.
Тут нужно сделать ремарку, что артефакты в этом посте — плод коллаборации четырех человек на Podlodka Teamlead Crew.
А я всего лишь вел сессию, шарил экран, записывал со слов ребят и фасилитировал.

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

https://news.1rj.ru/str/addlist/mDWR2gD6UEhlOWRi

P.S. Этот пост я тоже считаю полезным. Несмотря на то что папки с каналами уже задолбали, кто-то найдет для себя пользу в конкретно этой папке 🙂

​​Управление рисками

Все слышали, что бас-фактор=1 — это плохо. Это очевидный риск, на который все рекомендуют обращать внимание и устранять: писать документацию, распространять экспертизу внутри команды и растить замену единственному эксперту.

А какие еще есть очевидные риски? А какие неочевидные? Редко встречал системное управление рисками.

По сути всё, про что пишу — простые штуки из разряда «подумайте заранее, запишите и обращайте внимание в будущем. Вот пример».

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

Можно делать в формате брейншторма или футуроспективы всей командой.
Можно делать индивидуально.
Можно доверить инженерам проработку рисков по их части, в том числе по QA.

Во что это воплощается — можно посмотреть на примере карты рисков, которую составил наш QA-инженер, который недавно получил промо в сеньора (кусочек на картинке, полная версия — в публичной гуглотаблице)

Digital Nomad в Испании

Мы получили одобрение внж Испании на 3 года! Теперь я официально Teletrabajador de caracter internacional.

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

Чтобы пост принёс пользу, приложу ссылки на ресурсы, с помощью которых я готовился к этому проекту:

💡База знаний на Notion, в которой всё-всё-всё про документы и процесс
📌@digitalnomadspain — Канал, где публикуют кейсы одобрений и самую актуальную инфу по получению документов. Вот ссылка на мой пост там.
📌 @chatfornomads — чат при том канале, можно поиском найти ответ на вообще любой вопрос.

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

Итак, дано:
1. В Тбилиси классно, но хотим двигаться дальше
2. В идеале — в страну, где ребенок сможет претендовать на гражданство
3. Получить оффер и быть релоцированным Европейской компанией — простой путь. Но уходить из Авито не хочу.
4. Аргентина — не вариант, часовой пояс не даст работать

И тут как раз Испания с этого года запускает выдачу резиденции для цифровых кочевников.

15 мая мы с супругой и собакой выехали из Тбилиси в Москву, чтобы собрать все документы и 3 июня стартовать в обратную сторону.

Предстояло проехать 7500км через Россию, Грузию, Турцию, Грецию, на пароме в Италию, затем Франция и наконец Испания.

За время пути я взял всего 4 дня отпуска, всё остальное время работал. По дороге были моменты грустные и веселые. За поездку мы жили в 24 разных апартах. Мы купались в трёх морях. Жрали осьминогов на гриле. Ночевали под горой Олимп. Ночевали с машиной на пароме. Гуляли по Риму. Были в Ватикане и Монако. Держали пизанскую башню. Ночью нам разбили окна в машине, чтобы вытащить багаж. Достали один чемодан, где был собачий корм, поводок и барахло. А второй чемодан с ценной электроникой и документами не пролез в разбитое окно, и они его оставили. Вот оно, везение 🙂

4 июля мы подали документы на рассмотрение, а 11 июля у нас истёк шенген. Пока ждали решение по внж, мы всё еще легально находились на территории Испании. Но в случае отказа — «первым прямым рейсом домой». А мы на машине, с собакой, супруга беременная так что уже на самолет не посадят, да и рейсов прямых нет 🙂 Короче, отказ не вариант.

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

Это был большой проект. И он успешно запущен.
В процессе еще один большой проект, ради которого затевалась релокация — примерно в октябре я стану батей

​​Как мы команду делили

Наверняка вы слышали про предельный размер команды: 2-pizza team, 7±2, 6±3 и экспоненциально растущее количество связей между людьми при росте команды.

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

Предыстория такая:
В марте 2022 я пришел тимлидить команду из 5 инженеров и у нас был активный найм и рост. К июню нас стало 10 и на подходе были еще +2. Стало очевидно сложно работать в рамках одной команды. Слишком много встреч, слишком много направлений работы, которые не может вместить в себя каждый участник команды.

А впереди еще был найм 6 инженеров. Очевидно, пришло время делиться.

В следующих постах я расскажу о том, как делил команду впервые в жизни. И на какие грабли наступил тоже обязательно расскажу 🙂

Посты разделил по этапам:

1️⃣ Подготовка. Принцип разделения и выбор состава команд

На самом деле на этом этапе происходит 80% работы.

О чем стоит позаботиться заранее:

— Проработать потребность и принцип разделения
— Подготовить разработчиков к будущему разделению
— Определить предварительные составы команд
— Позаботиться о процессах в будущих командах

2️⃣ Kick-off — «оставшиеся» 20% работы.
Это встреча — отсечка запуска новых команд. Здесь каждый участник соглашается с составом команд и процессами. Здесь ребята вырабатывают первые командные договоренности. На картинке — один фрейм с доски этой встречи, где есть последний шанс поменять состав.

Мы делились целый день, и это было выматывающе. За то сразу договорись о процессах, DoD и DoR. В следующий раз kick-off разбили на несколько этапов по 1,5 часа. Было сильно легче.


3️⃣ Первые спринты после запуска.
А вот тут кроются еще 80% работы 🤪

Она заключается в помощи командам и работе над ошибками. Здесь вылезет всё, о чем не подумали на этапе 1.

Например, банальное — На планировании надо куда-то накидывать задачи и стартовать спринт, но нет отдельных досок в джире, только общая, доставшаяся «в наследство». Но это мелочь, джира позволяет вести несколько параллельных спринтов на одной доске и не видеть задачи друг друга. Хуже было то, что мы не сразу завели отдельные чаты по командам, и писали о задачах вперемешку в общий чат. Из-за этого первое время ребятам было сложно «отпустить» задачи другой команды.

Если вы уже проходили этот путь — поделитесь в комментах своим опытом. Интересен будет как взгляд изнутри, со стороны разработчика, так и со стороны тимлида / скрам-мастера. На что стоит обратить внимание? Какие ошибки совершили, как их можно было бы избежать?

​​Этап 1. Подготовка к разделению команд.

Итак, о чем точно стоит позаботиться заранее:
1. Определить потребность разделения
2. Проработать принцип разделения, предназначение команд
3. Подготовить разработчиков
4. Определить предварительный состав команд
5. Позаботиться о процессах в будущих командах

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

А еще потребность должна быть очевидной для всех, включая разработчиков в команде. Разделение должно решать проблемы. Например: «нас много, мы медленные», «слишком много контекстов».

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

Принцип разделения — от продуктового направления

У нас был проект размером в год. В нём два больших направления: «Управление профилями» и «Использование мультипрофиля».

Вот это и стало основополагающим принципом: по доменным областям ответственности. Это было достаточно очевидным решением, которое поддержали продакты.

У вас может быть другой принцип. Например, выделение платформенной core-команды, чтобы делать долгосрочные технические улучшения и ускорять работу продуктовых команд. Для выделения такой команды может понадобиться сильно договариваться с продактами.

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

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

Здесь можно подсветить, что рабочие группы могут стать слаженными «подкомандами» и разделение случится само собой. Это тоже рабочий вариант, тогда вернуться к вопросу можно будет через квартал или полгода.

Определить состав команд

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

Это очень интересное составное уравнение с кучей переменных. Получился такой лонгрид, что решил вынести его в следующий пост.

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

В качестве иллюстрации к посту сделал MindMap подготовки к разделению. Картинка к посту получилась шакальная, поэтому вот ссылка на исходник в Miro.

​​Как подобрать состав команд при разделении

Продолжаем цикл лонгридов про разделение команд. Первый пост тут.

В идеальном мире продуктовые разработчики самоорганизуются на две идеальные команды.
Но мы не в идеальном мире, и есть риск что составы получатся не оптимальные.

Здесь нужна помощь человека который соберет все-все-все контексты с ребят и предложит оптимальный вариант.

В идеальном мире вы хорошо знаете свою команду и в голове интуитивно уже подобрали состав.
Но мы не в идеальном мире и есть риск что интуиция ошибается.

Давайте попробуем систематизировать

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

📌 — Какие навыки нужны команде, кто из разработчиков что умеет и в каком направлении хочет развиваться
Здесь поможет упражнение StarMap. Можно пройти его вместе с командой, а можно самому. Если проходить вместе, то рассчитывайте часа на 4 минимум. Дорого, зато у ребят появится командный артефакт, о котором они могут заботиться, и который может быть частью их самоидентификации. Если составлять индивидуально, вам всё равно придётся собирать информацию на 1-1, и суммарно времени потратите не меньше.

📌 — Кто какую роль занимает в команде сейчас и какую может занять в новой команде
Здесь можно идти по интуиции и личному впечатлению от ребят. А если есть желание системно подойти к вопросу — посоветую хороший сборник статей: Работа в команде — модели, теории, алгоритмы
В этом сборнике советую обратить внимание на профиль управления командой Маргерисона-Макканна. Чем-то похоже на модель Белбина, но расширяет её.

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

📌 — Кто с кем хочет работать
Здесь стоит учесть персональные связи участников. Не стоит разлучать ментора и менти. И наоборот: возможно, есть личная несовместимость между двумя разработчиками, и они не хотят друг с другом работать.

📌 — Кто какие фичи хочет делать.
В одной команде большой объем новых client-facing фич. В другой — переделка корневых механик авторизации и управления данными, которые менее заметны клиенту, но более сложные.

Приведу упрощенный пример нашего уравнения
Disclaimer: все имена вымышленные.

Вася — душа команды, уже взял на себя фича-драйвинг объемной фичи А, которая пойдёт в разработку в команду А.

Антон — ценный мидл «педалёр», очень быстро пишет много качественного кода. Он хочет работать с Васей. И задачи команды А ему подходят.

Петя — ментор Антона, супер-эксперт. Задачи команды А для него будут скучноваты.

Костя — хороший интегратор, он фича-драйвер фичи Б, которая входит в скоуп команды Б. Фича Б — супер сложная и на ней нужен Петя.

Антон хочет работать с Васей и не хочет работать с Костей.

Допустим, есть еще несколько мидлов, которым не принципиально, с кем работать.

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

P.S. У нас было 12 разработчиков и 3-4 вот таких коллизий как у Антона. По итогу все решили, и спустя год ребята не хотят менять состав 🙂

Тегаешь коллегу — дай краткую вводную

…
тред в рабочем мессенджере на 100 сообщений
…
@ Nikita Khromushkin, поможешь тут?
…
Да, конечно! Сейчас, только прочитаю предыдущие 100 сообщений.
(про себя: мне б кто помог)

В последнее время выработал такой ответ:
«Ребята, не смогу вгрузить весь тред, дайте краткую выжимку и что от меня требуется?»

Идея простая: если тебе нужно, чтобы тебе помогли — помоги первый. Прояви заботу о получателе сообщения — увеличишь шансы, что он тебе поможет в ответ.
Заодно свои мысли структурируешь, и поймешь, что на самом деле нужно от коллеги. Может быть, и призывать не придется.

Упакуй свой запрос в удобную форму:
1️⃣ — О чем тред
2️⃣ — Какой возник вопрос
3️⃣ — Чего хотим от коллеги

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

Пример

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

Этот вопрос я переадресовал продакту, предварительно упаковав в удобно воспринимаемый формат:
«Илья, нужно принять продуктовое решение по багу.
Есть пользователи, у которых …
Есть предположение, что таким пользователям нужен ...
От тебя нужен концептуальный ответ, можем ли конвертировать баг в фича-реквест?»

Это простая идея, которую я почерпнул в книге «Новые правила деловой переписки».
Но этот пост пишу после какой-то адской недели призывов без контекста.

Если вам что-то нужно от коллеги, — то упростите ему работу, позаботьтесь о нем.
У вас контекст уже есть в голове и это займёт минуту, а коллеге сэкономит минут 15 чтобы вникнуть.
Верю, что этот пост принесет пользу: кто-то позаботится о читателе, упакует информацию в удобном для коллеги виде, и получит в ответ то, что хочет.