Ищу Mobile QA к себе в команду

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

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

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

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

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

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

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

Бесплатный курс iOS QA Automation

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

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

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

https://t.me/ios_automation_testing/189

​​TeamLead Meetup

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

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

Доклады:

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

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

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

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

Попал в подкаст 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 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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://t.me/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 июля у нас истёк шенген. Пока ждали решение по внж, мы всё еще легально находились на территории Испании. Но в случае отказа — «первым прямым рейсом домой». А мы на машине, с собакой, супруга беременная так что уже на самолет не посадят, да и рейсов прямых нет 🙂 Короче, отказ не вариант.

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

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