​​Как и зачем декомпозировать User Story — 21 шаблон

Давайте представим, что мы делаем некий MVP. На дискавери потрачено 3 месяца. Скоуп определен, дизайны отрисованы и требования подробно описаны. На разработку заложено еще 3 месяца. Катить на пользователей что-то меньшее, чем этот скоуп — бессмысленно. Например, зачем видеть список товаров, если корзины нет и оплатить невозможно.

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

…

Следующий кадр: прошло 3 месяца, продакт смотрит, что получилось.

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

«Программисты виноваты!» — скажете вы.
«Какое тз, такой и результат!» — ответят программисты.

Всем плохо: программисты без премии, продакт с кривым MVP, которое уже никому не нужно.

Можно ли было помочь и команде и продакту? — Да!

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

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

Вот как мог бы выглядеть процесс разработки нашего MVP по спринтам:

0️⃣ — Для старта проекта нам нужно хоть какое-то описание первой функции. Быстренько дискаверим, как должен выглядеть список товаров. Пока пофиг на фильтры и поиск. И пофиг что будет не идеально. Посмотрим вживую, потом поправим.

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

2️⃣ спринт — приделаем фильтры и поиск. А дискавери работает на следующий спринт: как должна выглядеть корзина.

3️⃣ спринт — сделаем корзину и возможность добавлять туда товары. Параллельно дискаверим оплату.

4️⃣ спринт — сделаем процесс оплаты на моках, и только успешный сценарий, без корнер-кейсов, неудачной оплаты и возвратов.

…

И так далее — до момента, когда уже можно релизить.

Да, нет смысла катить на пользователя экран со списком товаров без возможности поиска.
Но есть смысл декомпозировать MVP на мелкие User Story не больше 2 недель в разработке. И одной из таких User Story может быть «видеть список всех товаров».

Так мы решаем сразу обе проблемы:

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

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

Я призываю продактов помогать командам декомпозировать User Story на более мелкие, даже если катить на пользователя еще рано.
Почитать больше можно в статье Кента Макдональда.

Презентация к посту выше — «Как и зачем декомпозировать User story — 21 шаблон».

Иногда кажется, что декомпозировать юзер стори уже некуда. В таком случае идеи можно почерпнуть из презентации в аттаче — 21 шаблон декомпозиции пользовательских историй. Там можно найти лайфхаки, по типу «сделать сначала короткий успешный сценарий, а затем негативные и корнер-кейсы».

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

Про баланс в работе продакта

Каждая компания по-своему понимает роль продакта, но от любого продакта постоянно все чего-то хотят 🙂

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

При этом деливери расценивает как внутренний аутсорс:
— «сгружает» эпики размером в квартал без декомпозиции на User Story
— не ходит на планирования, PBR, дейлики
— не интересуется результатом на ревью спринта, не дает обратную связь
— не доносит команде ценность для бизнеса и эффект от фич

Так продакт теряет роль Product Owner.

Бывает и обратная ситуация: продакт руководит командой разработки вместо тимлида, при этом упуская метрики, аналитику и ux-исследования.

Специально привёл две крайности. Но на самом деле продакту очень легко что-то упустить в своей работе.

Ангелина Зинченко из Авито написала статью «Как продакту выстраивать коммуникацию со стейкхолдерами и командой»

В ней она приводит примеры ошибок и хороших практик для продактов в разных аспектах работы:
— с дискавери командой
— с деливери командой
— с маркетингом, отделом продаж
— с клиентской и технической поддержкой
— с руководителем, СРО, СЕО или инвестором

Советую к прочтению, своим продактам тоже скину. Они очень хорошие!
Но мне кажется, что в статье каждый может узнать себя в одном из пунктов 🙂

​​ProductCamp — в следующие выходные!

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

По поводу ProductCamp я спросил мнения нашего продакт-кластер-лида:
— Они хорошие, я и выступал когда-то там и участвую во многих конфах. Нетворк прекрасно выстроен.

Потом я посмотрел темы докладов и мне откликнулись:

— 5 факапов, которые сделали меня директором по продукту (Ксюша Стрельникова, Райффайзенбанк, Директор по продукту) 

— Когнитивные ошибки в продакт менеджменте (Иван Меркурьев, Яндекс, Менеджер проектов) 

— 15 Soft Skills менеджера продукта и как их качать на самом деле (ex Head of product developmet MTS, exYandex, exTinkoff) (Сергей Паращенко, Product Vision, Директор по образовательным продуктам) 

— Выгореть, выжить, вернуться: от убивающей продуктивности к эффективной (Анна Динельт, Яндекс Афиша, Руководитель продукта) 

———

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

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

Когда: 19-21 апреля
Где: Парк-отель «Ареал» и онлайн на ProductLand

Реклама. ООО "Глобалкэмп". ИНН 7806594627. erid LjN8KKtRL

Топ постов в этом канале для 10.000 подписчиков! 🥳
Привет, десять тысяч подписчиков! Это отличный повод обновить интро, и добавить в него полезностей.

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

Меня зовут Никита Хромушкин, и я инжиниринг мемеджер в Авито.
В душе я все еще инженер, хотя в трудовой — Head of Development of AvitoID unit.
В 2023 переехал в Испанию и стал отцом.

@sharelocations — лайв-канал про всякое личное, он еще совсем малыш, но туда тоже можно подписаться :)

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

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

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

🎉 Давайте отметим 10к подписчиков топом полезных постов! 🎉

1️⃣ — О чем спросить будущего работодателя — чеклист, собрал 1к+ репостов и 15к просмотров. Чеклист мы делали вживую на круглом столе на Podlodka Teamlead Crew. Вложились Евгений Кателла, Евгений Антонов и Татьяна Аква, я был в роли ведущего.

2️⃣ — Digital Nomad в Испании — 266 репостов и 9.3к просмотров. Забавное из обсуждения поста в одном там чате: «История лютая, ппц. На большом сроке решиться на такую авантюру. Если б что не так, то сидели бы они в миграционной тюрьме с марроканцами». Это байопик нашего переезда в Испанию на машине, первый и единственный lifestyle-пост. Тем не менее, и он оказался полезным: в нем ссылки на базу знаний на Notion, которой я пользовался при подготовке документов.

3️⃣ — Как мы готовим задачи к спринту, поделились 86 раз и посмотрели 3,1к человек. Этот пост про то, что процесс подготовки задачи к разработке тоже можно структурировать и описать. В эту же тему будет ранний пост про Dual-track development. У канала тогда было 100 подписчиков, я работал в QIWI, но уже тырил лучшие практики из Авито 🙂

4️⃣ — Как и зачем декомпозировать User Story + 21 шаблон декомпозиции, вдвоем набрали 244 репоста и 4.2к просмотров. Эти посты про то, как декомпозировать недекомпозируемое. Могут помочь продактам/бизнес-аналитикам и командам делать более частые и маленькие инкременты и быстрее получать обратную связь.

5️⃣ — Как понять, в ту ли сторону ты развиваешься, чтобы получить повышение? + Windrose template для собственного развития — вдвоем набрали 218 репостов и 7,5к просмотров. Это про Авитошную матрицу компетенций. Если у вас в компании нет матрицы, а решения о промо принимаются на уровне команды, то можно позаимствовать матрицу Авито и использовать её внутри своей команды.

6️⃣ — Серия из 3 постов Как мы команду делили + Как мы провели Kick-off за 8 часов и какие вынесли уроки — вся серия набрала 305 репостов и 27,1к просмотров. Полезно, если у вас команда предельного размера (~9+ человек) и связанные с этим страдания — долгие стендапы, грумминги, общий расфокус, и невозможность уследить за всем что происходит.

7️⃣ — SMS Two factor auth — плохая практика и серия постов про альтернативы, заканчивающаяяся постом про Будущее аутентификации в вебе — вся серия набрала 206 репостов и 13.5к просмотров

===

В конце поделюсь ранним творчеством:
8️⃣ — StarMap — карта компетенций команды — если нужно собрать воедино картинку: кто что знает, чему готов научить и чему хочет учиться. Поможет обнаружить низкий бас-фактор или недостаточность экспертизы для каких-то фич.
9️⃣ — Чеклист Definition Of Done — Как всем одинаково понять, что задача сделана.
🔟 — Чеклист Definition Of Ready (for Sprint) — Как понять, что задача проработана.

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

​​Четырехдневка, доступная каждому
… за которую еще и доплатят 🙂

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

Итак, если:
1. Хотите попробовать четырехдневную рабочую неделю
2. При этом сохранить погружение в контекст, ходить на планирования по понедельникам и ретроспективы по пятницам
3. Работаете итерациями в 2+ недели
4. Готовы потратить несколько отпускных дней чтобы поднабраться сил

То представляю вам уникальный авторский концепт:
Отпуск с пятницы по понедельник в середине спринта
* имеются противопоказания, проконсультируйтесь с руководителем

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

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

Писать ли отпуск на выходные — по желанию и согласованию с компанией. Если у вас накопилось 20+ дней отпуска — это отличный способ обналичить отпускные. Но если вы копите отпускные, то можно и не писать. Можно просто в пятницу и понедельник.

Концепт крайне рекомендован тем, кто подвыгорел и не может уйти в отпуск, потому что все развалится. За один день в неделю не развалится.

Всем своим многоотпускникам советую, и вы попробуйте!

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

P.S. Обращение к ребятам, кто копит, «инвестирует» свои отпускные дни.

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

Во-первых, за год инфляция съест этот прирост, а вам дадут еще одно повышение зарплаты.

Во-вторых, повышение зп чаще получают те, кто хорошо отдыхает и продуктивно работает.

Поэтому потратить отпускные дни = инвестировать в себя.
А копить отпуск = продавать свое здоровье по цене отпускного дня.

Сходите уже отдохнуть.

​​Что такое Data-driven принятие решений

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

Разберем на примере Авито. На картинке — один из тысяч A/Б-тестов в нашей «АБшнице».

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

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

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

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

Основные плюсы data-driven культуры:
— Решения принимаются точнее, компания легче отказывается от бесполезных идей и поддерживает полезные
— Снижается зависимость от «экспертного» мнения, компания чуть лучше защищена от некомпетентных менеджеров
— Развивается культура «экологичного» челленджа, повышается прозрачность принимаемых решений

Однако, конечно, у такого подхода есть ряд минусов:
— Команды могут начать перестраховываться — появляется «аналитический паралич», из-за чего ухудшается ТТМ
— Некоторым менеджерам становится труднее принимать решения, когда результаты теста не однозначные

… и ограничений:
— Компании нужно развивать аналитические компетенции в большом объеме — это дорого
— Нужно строить инфраструкту данных и развивать data-инженерные компетенции — это дорого и сложно

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

Это был гостевой пост Алексея Малинского, руководителя категорийной аналитики в Авито Товарах.

Больше постов про аналитику — Avito Data Tech

Авторизация — больше чем логин/пароль

^^ К репосту выше ^^

Не так давно я оформил серию постов про альтернативы 2fa в презентацию и выступил первый раз за 2 года.

Спасибо ребятам из Mad Brains, что позвали.

И отдельное спасибо за то, что смонтировали видос.
А серия постов тут, начинается с «SMS — плохой способ 2fa».

Так может и выступать начну опять.

Процесс найма — несправедливый, как ни старайся

Читаю «Work Rules!» от бывшего главы HR Google.

Корпорация добра проводит A/B тесты во внутренних процессах, в том числе в найме. Вот как разные методы отбора кандидатов влияют на будущую успешность сотрудника:

• Отсев по количеству лет опыта — 3%
• Сбор фидбеков с прошлых мест — 7%
• Неструктурированные интервью — 14%
• Структурированные интервью — 26%
• Тест на общие когнитивные способности (внезапно) — 26%
• Практическое задание — 29%

Разные компании комбинируют эти методы, но ни один из них по отдельности не гарантирует более 30% успеха!

———

Когда после 5 лет работы в QIWI решил «пособеситься ради интереса», оказалось что это целый новый мир, не похожий на то, что я делал в каждодневной работе.

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

Было бы здорово мне тогда сходить на консультацию к кому-то, кто в этой теме работает постоянно. Это помогло бы сэкономить время и силы, и меньше стрессовать.

Этот пост — реклама Карьерного Цеха. Ребята предлагают бесплатную консультацию для тех, кто подумывает искать работу.

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

Записывайтесь на бесплатную консультацию и получите индивидуальный план поиска работы, который приведет вас к офферу.

Реклама. ИП Федоров Е.П.
ИНН 532008901966

​​Low-context vs High-context коммуникация

Читаю The Culture Map — книгу про культурные различия. Заходит настолько, что буду приносить сюда кое-какие концепты.

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

У нас принято «читать между строк». Аналогично в Испании, Турции и многих других странах.
В Японии и Китае это же называется «слушать воздух».

High-context пример: На дейли тимлид говорит «надо подумать, как оптимизировать запрос». В нашей культуре это может означать просьбу к конкретному разработчику заняться оптимизацией, но напрямую это не озвучено.

Могут возникнуть недопонимания:
🤏 конкретный разработчик может не понять, что эта просьба — к нему, и продолжить работать по своей задаче. А когда неоптимальный запрос станет проблемой — это будет его проблема, потому что у тимлида были ожидания.
🤏 сразу несколько ребят бросят свои задачи и, не синхронизируясь, займутся оптимизацией. Другая работа не будет сделана, а потом еще и спорить будут, чья оптимизация круче 🙂

==========

Напротив, молодые «экспатские» страны, вроде Австралии, не имели возможности развить high-context культуру. Чтобы выходцы из разных стран могли сосуществовать, они стараются не закладывать доп смыслов в свои сообщения и выражаются прямо и детализированно.

В следующем посте расскажу про Low-context коммуникацию, почему она лучше подходит для рабочих отношений.

Как вы думаете, где больше пространства для недопониманий?

1️⃣ — Между двумя представителями разных Low-context стран, например Австралия и Канада
2️⃣ — Между Low-context из США и High-context из Китая
3️⃣ — Между High-context из России и High-context из Индии

Буду рад обсудить в комментах 🙂

Yet Another Level: TeamLead — Митап для тимлидов от Яндекса.
25 июля. Бесплатно.

Митап из серии мероприятий про жизнь в IT-индустрии. В этот раз о тимлидах, их софт скилах и карьерных треках.
Будут выступать уважаемые господа:

📌 Евгений Антонов, мой товарищ, технический менеджер в Yandex Infrastructure.
«Играющий тренер: выиграет или проиграет?» — Поговорим о том, как начинающие тимлиды 80% пишут код и 80% занимаются менеджментом.

📌 Александр Афенов, мой коллега, Technical Cluster Lead в Авито Доставке.
«Жока и Бока: две очень разные судьбы тимлидов». Ожидаю классный сторителлинг, где каждый сможет узнать себя.

📌 Руслан Остропольский, CPO в Test IT.
«Как завоевать доверие тимлиду» Разберёмся, что такое доверие, как оно формируется и как его не потерять. А ещё обсудим, есть ли разница между доверием и авторитетом.

Митап пройдёт 25 июля онлайн и офлайн в Москве — участие бесплатное, но нужно зарегистрироваться

Присоединяйтесь к чату сообщества в tg https://news.1rj.ru/str/Yet_Another_Level

​​Low-context коммуникация и обратная связь

Правильный ответ на вопрос из прошлого поста — 3️⃣

C большей вероятностью представители двух разных High-context культур могут неправильно считывать «между строк» сообщения друг друга. Потому что их культура формировалась независимо в разном историческом контексте. Даже внутри одной страны есть риск неправильного считывания «между строк». Сейчас в распределенных командах работают ребята из разных регионов, и у каждого свой high-context.

Поэтому простое правило — в рабочей коммуникации использовать Low-context.

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

Давать максимум контекста: над чем работаешь и детали для правильного понимания ситуации. Объяснять, почему задаешь тот или иной вопрос. Да, иногда придется повторяться. Но лучше повторить, чем быть неправильно понятым.

А еще — не закладывать намёков и смыслов «между строк» в своей коммуникации и не пытаться найти их в словах собеседника.

Но из любого правила есть исключения.

Самое важное исключение — обратная связь.

Удивительно, но многие Low-context страны имеют культуру смягчения корректирующей обратной связи. Например, в Америке, UK и Канаде принято давать фидбек в формате «сендвича»: «несколько положительных аспектов, затем мягко упомянуть о том, что можно улучшить, и снова похвалить».

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

Теперь я стараюсь использовать Low-context коммуникацию, сохраняя при этом прямой стиль обратной связи.

На картинке — позиционирование стран в координатах «Коммуникация / Обратная связь».
Мы с вами находимся в квадранте «High-context / Direct negative feedback». Из этого делаем вывод, что в общем случае мы можем общаться намёками и рассчитывать, что собеседник поймёт наш посыл «между строк». Но при этом если код — 💩, то так и будет сказано.

Намёк может быть понят неправильно, поэтому стоит помнить об этой склонности и возвращаться к Low-context.

Однако не стоит ориентироваться на Америку в части обратной связи. Конечно, не стоит говорить «твой код — говно». Но и формат «ты, конечно, молодец, но код — говно. Но ты, конечно, молодец» — не поможет.

И да, «хвали публично / ругай лично» 🙂

Исследование тимлидов

В 23 году прошел большой опрос тимлидов от DevCrowd. Поделюсь интересностями оттуда.

Этот пост — призыв пройти опрос текущего года. Это некоммерческая история, мне не платили за этот пост, и да, опрос я прошел.

Прохождение займёт у вас ~1-5 минут. В сентябре ребята подобьют результаты и выложат в виде красивой инфографики.

В прошлом опросе приняло участие 570 человек, из которых:
- 68% – тимлиды
- 22% – менеджеры менеджеров
- 9% – директора

📌 90% перешли в менеджмент в той же компании, где работали инженерами.

📌 Топ-3 обязанности руководителей любого уровня:
1️⃣ Собеседования,
2️⃣ Развитие людей в команде
3️⃣ Оценка их перфоманса.

📌 — 80% тимлидов считают себя сильнее большинства инженеров в своей команде.

📌— Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени.

📌 — Активно ищет работу только каждый десятый тимлид.

Подробнее, с инфографикой и даже видосом от Егора Толстого — Ссылка на результаты 2023.

———

P.S. там есть вопрос про медиа, которые вы читаете. Среди вариантов нет Product Developer, но есть поле «другое». Ну вы знаете, что туда написать 🙂

Пройти опрос.

Почему я продолжаю работать в Авито из Испании

Прошел год с написания поста Digital Nomad в Испании, а я всё еще работаю в Авито. Кстати, советую прочитать тот байопик нашего переезда :)

Раньше идея релокации для меня была сопряжена со сменой работы. До ковида и всеобщей удалёнки других вариантов и не было. Да и зарплата в рублях была маленькой для Европы. К тому же при релокации работодатель помогал с документами, билетами и арендой на первое время.

Но вот в прошлом году я релоцировался, сохранив работу. Почему?

0️⃣ Появилась такая возможность. Удалёнка стала нормой, а загнивающая Европа привлекает к себе молодых и талантливых с помощью новых типов внж.

1️⃣ Уровень зарплат выровнялся. Серьезно, посмотрите levels.fyi. Возьмем за пример немецкий Тинькофф — необанк N26. Медианная gross зп сеньора в Германии — €87K/год. Это ~€4.5k в месяц на руки после налогов. Сеньор-помидоры в РФ просят столько же. C тимлидскими позициями ситуация даже хуже.

2️⃣ Мне интересно в Авито. Потихоньку приближаюсь к ощущению, что работаю здесь уже достаточное время, чтобы что-то понимать и наносить пользу. И очень здорово, что есть островок стабильности в виде работы, который помогает заземлиться во время переезда и рождения ребенка.

3️⃣ В России рынок кандидата. Компании конкурируют за толковых ребят, процесс найма относительно лайтовый (да, даже если это несколько секций включая алгосы). В Европе — рынок работодателя. Кандидатов много больше, чем вакансий. Тестовое задание на день-два работы — норма. Трудоустроиться в европейскую компанию — не так-то просто.

4️⃣ Сейчас мой тип ВНЖ не привязан к работодателю. Если переходить работать на местную компанию — нужно менять тип ВНЖ и стану привязан. В случае увольнения будет всего месяц на поиски.

5️⃣ Работать в русскоязычной компании — понятнее. И дело даже не в твоём плохом английском, а в менталитете и плохом английском всей команды. Серьёзно, я знаю истории, когда ребята на созвоне не могли договориться, потому что не понимали речь друг друга, и уходили в текстовое обсуждение.

Чтоб жизнь малиной не казалась — расскажу про риски и минусы:

0️⃣ Собирать доки и подаваться на ВНЖ нужно самому, есть риск отказа. Мы приехали на машине с беременной женой и собакой по шенгену. Виза закончилась во время рассмотрения ВНЖ. Отказ был бы очень некстати в такой ситуации.
1️⃣ Курсы валют. Если рубль просядет к евро — мой доход снизится. Честно говоря, укрепления рубля я не жду. А вот зарплаты в рублях растут. Главное — иметь подушку безопасности и план.
2️⃣ Высокая цена «подписки на страну». Сюда я включаю прогрессивную ставку налога, цены на аренду жилья и на услуги. Стоит ли оно того — каждый решает сам.
3️⃣ Повидаться с роднёй или приехать на общекомандный сбор стало сильно дороже и сложнее, нужно закладывать два дня на дорогу.

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

Наконец-то можно планировать жизнь на несколько лет вперед.

Technical Design Review (TDR)

Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.

Но у кодревью есть один большой минус: код уже написан. Когда появляются критичные комменты по архитектуре и нужно всё переписывать — очень демотивирует и может возникнуть конфликт.

Эту проблему решает TDR — Technical Design Review.
Это как кодревью, но про архитектуру и заранее: инженер описывает в Confluence предлагаемое решение и собирает обратную связь с команды и внешних ребят.

Как и в кодревью, есть плюсы, минусы и подводные камни.

Плюсы:

1️⃣ Более проработанное решение будет быстрее разработано и с меньшими проблемами.
Серьёзная проработка архитектуры до старта разработки даёт возможность полноценно попроектировать и учесть обратную связь.

2️⃣ Обмен знаниями и гарантия документирования.
Есть возможность научиться проектировать архитектуру у более опытных ребят. Проектировать может один, а разрабатывать — другой. Полноценная дока появляется еще до старта разработки.

3️⃣ Осведомленность команды и соседей.
При разработке будет меньше вопросов. Не будет проблем с интеграцией и вопросов «а что это вы тут делаете?». Не возникнет блокирующих рисков.

Минусы:

1️⃣ Увеличивает Time2market
Это компенсируется временем, сэкономленным на поддержке и рефакторингах. TDR = контроль за техдолгом.

Но есть подводные камни. TDR может «застрять на ревью» как задача на кодревью.
Причины могут быть разные, но результат — задержка реализации.

Способы решения этой проблемы — аналогичные для долгих кодревью:
— Договориться о сроках с ревьюерами.
— Определить в команде приоритет. В идеале, ревью кода и ревью TDR — приоритетнее, чем написание нового кода по своим задачам.
«Сел утром за работу — посмотри пулл реквесты и TDR».
— Заранее предупреждать о предстоящем ревью в следующем спринте. Просить запланировать ревью.
— Иметь четкую систему оценок и критичности комментов: что обязательно к исправлению, а что опционально.
— Иметь гайдлайны о том, что должно быть в TDR: компонентные и sequence-диаграммы, оценки объема данных и нагрузки, оценки рисков, план миграции, план отката. Это снимет часть вопросов, возникающих на большинстве TDR.


2️⃣ Иногда TDR делают там, где он не нужен, замедляя разработку. А иногда не делают там, где нужен, порождают риски.
Проблема в отсутствии договоренностей, какие изменения должны проходить через TDR.

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


Итог

Мы провели около 10 TDR за полгода.

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

Но в целом польза от TDR точно перевешивает.
Советую ли я читателю TDR?
— Однозначно, стоит попробовать!

Если у вас есть похожий опыт — делитесь в комментариях.

ProductSense

Прежде чем писать этот пост, я спросил у нашего продакта: Илья, это ценная конфа?

«Обычно да, так как довольно требовательно отбирают спикеров и темы. Я был один раз, но остались очень крутые впечатления от воркшопов»

Поэтому я согласился порекламировать в обмен на билет.
И да, Илья идёт на неё, а я буду смотреть в онлайне 🙂

5-6 сентября, оффлайн в Москве или онлайн

Конфа для продактов и не только: есть доклады и про управление командой и проектом, а еще про взаимодействие Discovery <-> Delivery.

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

Я бы сходил послушать Александра Вазюкова из Т-Банка с докладом “Приключение на 20 минут, или прогнозирование сроков проекта” (спойлер: прогнозирование не ради самого прогноза, а ради рефлексии)

А еще Александру Клименко из Soft Skills Lab — с докладом “Продакту не нужны софт скиллы?”. Кстати, еще у них будет воркшоп про переговоры.

В общем, советую посмотреть темы и прикупить билетик, хотя бы на онлайн.

17 августа подняли цены на билеты, но у меня есть промокод для билетов Digital Pass и Professional, который возвращает цену к прошлой. Промокод действует три дня, пишите мне в личку @engineering_memeger.

Вот ссылка на лендос конференции

Культура код-ревью: приоритеты и скорость

Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект

Альтернативы есть: парное программирование или TDR. Но они подходят не всем.

Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.

Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.

👨‍💻 Удовлетворение на этапе открытия PR

Speed of Code Reviews

Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?

Так происходит, если написание нового кода поощряется больше, чем ревью.

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

А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»

🤌 Огромные PR

Why Write Small CLs

Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.

- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения

Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.

🏓 Ревью-пинг-понг

Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?

1️⃣ — Новые комменты к нетронутому коду

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

Так может происходить, если ревьювер цепляется то за одно, то за другое.

Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».

Могут помочь статьи What to look for in a code review и Navigating in ChangeList.

2️⃣ — Комменты к исправлениям

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

- Стоит объяснять, почему просишь изменений.

- Стоит разделять обязательные к исправлению пункты и опциональные.

- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».

How to write Review Comments

===

Итог

Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.

Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?

DevOps в продуктовой разработке: outsource vs in-house

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

Продуктовая разработка и аутсорс DevOps могут показаться несовместимыми. На первый взгляд, это даже антонимы 🙂
Ведь DevOps — это не профессия, а культура совместной работы разработки и эксплуатации.
Однако давайте взглянем на это с другой стороны.

В Авито, например, есть внутренняя PaaS (Platform as a Service). Она позволяет разработчикам сосредоточиться на бизнес-логике, абстрагируясь от нюансов инфраструктуры в большинстве случаев.

$ avito service create
И вот — новый микросервис в 3 кластерах с настроенным CI/CD, логами, метриками и трассировкой.

$ avito service add postgresql
Готово — PgSQL развернут, секреты в Vault, подключения настроены.

Это экономит кучу времени и ускоряет разработку. Но не отменяет DevOps культуру. Доступ ко всем конфигам кубера в наличии, а с постгресом можно работать в режиме full access, если очень нужно.

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

В том, чтобы отдать инфру на аутсорс, есть куча плюсов:

1. Фокус разработчиков на продукте: Разработчики сосредоточены на продуктовом коде, не отвлекаясь на инфраструктурные задачи.

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

3. Экономия ресурсов: Не нужно содержать штат инженеров инфраструктуры. Аутсорсер заботится о найме, мотивации, обучении, отпусках, рабочем ноутбуке и пенсионных отчислениях.

4. Финансовая ответственность за SLA: при проседании ниже 99.95% аутсорсер выплачивает компенсацию.

Оптимальное решение часто находится посередине. Базовую инфраструктуру можно отдать на аутсорс, сохранив при этом in-house команду для критичных компонентов и поддержания DevOps-культуры.

Важно помнить: DevOps — это про людей и процессы, а не только про инструменты.

Подробнее — на лендосе DevOps-as-a-Service.

Поделитесь в комментах — насколько вы погружены в инфру? Сколько % времени разработки занимает DevOps?

———
Реклама АО «Селектел». ИНН: 7810962785 Erid:2VtzqvYLck5

Как подготовиться к собесу на тимлида?
… в продолжение к предыдущему посту.

Читать каналы из тимлидской папки, конечно же!

☀️Мой любимый Роадмап тимлида в канале Teamlead Good Reads — огромная база знаний по разным аспектам работы тимлида. Это очень толковый инструмент для собственного развития. А для собеса Роадмап поможет структурировать рассказ о себе.

☀️ Тимлид Очевидность — кладезь опыта. Ведет мой товарищ — Евгений Антонов. С удовольствием читаю сам и 100% могу рекомендовать.
— Как тимлиду собеседовать работодателя
— Подготовка к собеседованию по STAR
— Как оценить результат работы тимлида — эпизод подкаста, который поможетосознать свои заслуги и толково о них рассказать.

☀️ Ув. тов. Шароватов. — Вопросы работодателю на собесе. Невероятно харизматичный тимлид и просто аутентичный человек, с которым приятно общаться и перенимать опыт.

☀️TeamLead. С места в career. — Собеседование руководителей. К Ольге я приходил за советом еще когда стартовал свой канал 🙂 Точно рекомендую.

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

Подписывайтесь: https://news.1rj.ru/str/addlist/CidpeALk4WJiODJi