———

📝Встреча с задачей📝

У меня есть боль: между встречами — разрывы по 30–60 минут, в которых вроде бы можно что-то сделать…
Но сил нет, фокус не включается, а к вечеру смотрю на список задач и думаю: «ну вот, снова ничего не успел».

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

Недавно попробовал странно простую вещь: ставить задачи в календарь.
Прямо как встречи.

🔹 Так у задачи появляется конкретный слот времени — в него уже не влезет ещё один созвон.
🔹 Есть напоминалка за 15 минут до «встречи», помогает настроиться на задачу.
🔹 И, внезапно, появляется лёгкое чувство неловкости, если в этот слот делаешь не то.
Как будто прогуливаешь встречу с собой.

Инсайт этот не мой — наткнулся на пост Алексея Арефьева, автора канала @alexcouncil.

Суть простая:
Задачи — это тоже встречи. Только с собой.

Плюс — можно использовать цвета, чтобы понимать тип активности с первого взгляда:
🟢 регулярки, 🔴 разовые встречи, 🔵 задачи.

Я пока только начал пробовать — но кажется, это лучшее, что случалось с моим фокусом с начала года.

Давно читаю канал Алексея. Там еще и мемчики есть. Подписывайтесь 🙂

5 Уровней автономности сотрудника

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

Как сотруднику понять, с какими задачами идти к тимлиду, а какие решать самостоятельно?

Всё в той же статье HBR про «обезьяний менеджмент» выделяют 5 уровней автономности сотрудника.
Чем выше ваш уровень автономности, тем больше вам доверяют, тем интереснее задачи вы получаете и тем быстрее растёте карьерно.

1️⃣ Ждать указаний
— Вы не делаете ничего, пока менеджер не скажет конкретно, что и как делать.
— Инициатива и ответственность полностью на менеджере.

2️⃣ Спрашивать, как поступить
— У вас есть варианты решения, но вы ждёте, пока менеджер выберет один из них.
— Финальная ответственность на менеджере.

3️⃣ Консультироваться, затем действовать
— Вы самостоятельно придумываете решение, обсуждаете с менеджером и действуете, убедившись, что он не против.
— Ответственность уже ваша, менеджер только консультирует.

4️⃣ Действовать и сообщать о результате
— Вы самостоятельно принимаете решение, действуете, а менеджеру просто сообщаете, что именно сделали.
— Ответственность и инициатива полностью ваша, менеджер лишь информирован.

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

Пример:
Новая фича требует переделки архитектуры.

🔴 Уровень 1:
«Без тебя никак, скажи, что нам делать?»

🟠 Уровень 2:
«Есть два варианта, скажи, какой выбрать?»

⚪ Уровень 3:
«Подготовил пару решений, склоняюсь к первому. Хочу убедиться, что не упустил чего-то важного.»

🔵 Уровень 4:
«Мы обсудили и решили переделать архитектуру так-то и так-то. Работа уже идёт.»

🟢 Уровень 5:
«Переделали архитектуру, всё работает. Захочешь посмотреть — приходи.»

🛠️ Как применить модель на практике?

1. Обсудите с тимлидом текущий уровень автономности и комфортный для вас и команды следующий шаг.
2. Постепенно поднимайтесь: от «спрашивать, как поступить» до «действовать и сообщать» и далее.
3. Чем выше ваша автономность, тем больше свободы действий, интереснее задачи и заметнее вклад в общий результат.

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

Поделитесь в комментариях, на каком уровне чаще всего вы работаете сейчас?

🎯 Пособеситься — это тоже навык
Disclaimer: это реклама бесплатной консультации от Карьерного цеха

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

Но в этот раз нарушил правило, 3 года не практиковался.

И когда решил снова — понял, что растерял навык:
1. Меня не зовут
2. Не понимаю, кто я сейчас для рынка
3. Разучился внятно рассказывать про свой опыт
4. Неясно, как за 3 года изменились зарплаты

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

Чтобы понять, как вернуться в тонус, можно пойти на бесплатную консультацию в Карьерный Цех.

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

1. Разобраться, как вы выглядите для рынка сейчас.
2. Оценить навыки, сильные стороны и карьерные цели.
3. Понять, как упаковать опыт и где зарыты карьерные возможности.

Если дальше захотите сопровождение — можно будет вписаться. А если нет — просто уйдёте с пониманием, куда двигаться и как.

👉 Записаться на бесплатную консультацию

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

«Мы — молодцы, они — идиоты»

Наверняка вы встречали это на работе:

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

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

Когда-то конкуренция между группами обеспечивала выживание:

— «Мы» — своё племя, источник еды, тепла и безопасности. Умные, компетентные, правильные.
— «Они» — чужие, соперники за ресурсы, от которых нужно защищаться. Ленивые, глупые, опасные.

Сегодня ресурсы стали доступнее, но мозг за 100 000 лет привык видеть мир через эту оптику:

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

Эксперимент «Летний лагерь» (1954 год):
Группу 11-летних мальчиков разделили на две команды в летнем лагере и устроили между ними соревнования.

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

Главное открытие:
Чтобы разгорелся конфликт, было достаточно, чтобы одна группа увидела другую как соперника. Никаких других поводов не требовалось.
Это же часто происходит и на работе.

Почему это плохо?
Когда мы делим мир на «умные мы и глупые они»:

— Вместо решения задач, ищем виноватых.
— Исчезает взаимопонимание и падает продуктивность.
— Рабочая атмосфера становится токсичной.
— Мы перестаём учиться и развиваться, считая себя и так молодцами.

Старая прошивка мешает нам в современном мире.

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

Попробуйте вместо обвинений задать себе вопросы:

✅ Какую позитивную цель преследуют эти люди?
✅ Что они знают такого, чего не знаем мы?
✅ А вдруг это мы в чём-то ошибаемся?

Смените прошивку. Допустите, что они — не идиоты.

Конкретный пример: как это помогает в карьере

Разработчик получает нечёткое описание задачи от продакта. Первая реакция (старая прошивка): «Продакт не умеет нормально ставить задачи».

Старая прошивка:
— Раздражение и конфликты.
— Тратит время на споры.
— Продакт считает разработчика проблемным и избегает давать интересные задачи.

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

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

———

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

Как управлять людьми, а не чужими задачами

В последних двух постах мы обсуждали, как лидеру управлять командой, а не таскать на своих плечах чужие задачи.
Monkey Management, Servant Leadership, автономия сотрудников — это всё звучит классно, но как это выглядит на практике?

Узнаем на PeopleSense 2025!
Конфа специально для тех, кто управляет людьми и командами. Организаторы — те же ребята, кто делает топовую ProductSense.
Если вы тимлид, менеджер или хотите им стать — это точно для вас!

Примеры докладов:

📍 Как растить лидеров-решал? — Дмитрий Павлов
Очень интересно сравнить концепцию с Servant Leadership и Monkey Management 🙂

📍 Менеджмент 18+: сотрудник — не ребенок, менеджер — не родитель — Антон Бевзюк
С Антоном мы вместе работали в Райфе, он построил там крутое скрам-сообщество, поэтому я ему доверяю и буду рад послушать доклад

📍 Как перейти от управления людьми к управлению работой — Алексей Пименов
Спикера и так все знают, чисто ради Алексея можно на конфы ходить

Всего будет 32 доклада и 20 мастер-классов

Даты: 19–20 мая, Москва
👉Подробности и расписание тут

Servant Leadership vs. Обезьяний менеджмент

В комментах к прошлому посту — пожар 🙂
Основной посыл:
- Задача должна оставаться у сотрудника.
- Менеджер консультирует, направляет, помогает ресурсами, но не делает работу за сотрудника.
- Как результат — автономные сотрудники и свободное время менеджера на стратегические задачи.

Остался неотвеченным вопрос: что делать, если сотрудник объективно не может выполнить задачу самостоятельно?

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

«Лидер-слуга» существует для того, чтобы помогать команде. Разве это не значит, что менеджер и должен брать на себя задачи?

Основной посыл Servant Leadership:
— Устранять препятствия, создавать условия для эффективной работы, чтобы сотрудники могли спокойно делать свою работу.
— Давать ресурсы, полномочия и поддержку.

Лидер создаёт среду, в которой сотрудники могут максимально раскрыть свой потенциал.

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

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

❌ Неправильно: делать вместо сотрудника то, что он способен сделать сам (придумать решение, написать код, провести аналитику и т.д.).


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

🔹 Задача команды: качественно реализовать фичу.
🔸 Препятствие: внешнее ревью.

Тимлид идёт договариваться, чтобы выстроить процесс:
— Команда А будет заранее предупреждать о предстоящих изменениях
— Команда Б будет закладывать в спринт время на ревью
— Команда Б обязуется делать ревью за 1 рабочий день

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

…

Другая ситуация — разработчик приходит и говорит: «Нужно придумать архитектуру для фичи».

Здесь оба подхода совпадают:

— Менеджер помогает обсуждением и наставничеством, но не забирает задачу.
— Решение остаётся за сотрудником, иначе падает автономность.

🛠️ Итог:

Servant Leadership и Обезьяний менеджмент — не противоположные подходы.
Это скорее два взгляда на одну и ту же проблему с разными акцентами:

Servant Leadership — это умение вовремя убрать барьеры, чтобы команда могла автономно двигаться вперёд.

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

Что думаете?

Митап для тимлидов от HH
📍 3 апреля, офлайн в Москве, м. Белорусская

hh.ru собрал руководителей из Яндекса, Сбера, Т-Банка, VK и МТС, чтобы поговорить о том, как сейчас эффективно нанимать и оценивать сотрудников, чтобы потом не жалеть

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

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

Митап будет полезен для лидов разработки, аналитики, продукта, маркетинга и дизайна, HR и рекрутёров.

— 3 апреля, четверг, сбор гостей в 18:30
— Пространство Bounce: ст. м. Белорусская, 3-я ул. Ямского поля, д. 2 к. 6

Участие бесплатное, но количество мест ограничено — регистрируйтесь заранее и дождитесь подтверждения заявки.
👉 Зарегистрироваться

🐒 Обезьяний менеджмент

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

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

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

📌 Коротко о проблеме:

1. Менеджер часто берёт чужие задачи, не замечая, как это происходит.
2. Сотрудники привыкают к тому, что менеджер всегда подстрахует.
3. В итоге:
- менеджер перегружен,
- у сотрудников снижается ответственность и автономность,
- задачи затягиваются, команда менее эффективна.


📌 Правила управления обезьянами:

1️⃣ Определить владельца обезьяны.
Каждая задача должна принадлежать конкретному человеку:
— Ты отлично понимаешь контекст и знаешь задачу. Давай ты предложишь решение, а я помогу его обсудить и доработать.

2️⃣ Определить следующий шаг.
У задачи всегда должна быть следующая конкретная дата и шаг.
— Давай ты на этой неделе подготовишь возможные решения.

3️⃣ Задачи должны быть заботой сотрудников, а не менеджера.
Сотрудник должен сам приходить и рассказывать о результате, а не ждать, когда тимлид спросит.

4️⃣ Назначать чёткое время и место для обсуждений.
Не «потом посмотрю», а «сможешь завтра на груминге показать, что получилось?».
Это дисциплинирует сотрудников и вас самих.

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

📌 Как применять эти правила? Пример:

Разработчик:
— Нужно придумать новую архитектуру, без твоего мнения не продвинемся.

❌ Неправильно:
— Ладно, я посмотрю, вернусь к тебе. (Обезьяна перепрыгнула)

✅ Правильно:
— Ты знаешь задачу лучше всех. Предложи 2-3 варианта решения и приноси завтра на груминг обсудить. Выберем лучший вместе. (Обезьяна осталась на сотруднике)

📌 Что получаем на выходе?

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

———

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

Пост написал по мотивам статьи 1974 года в Harvard Business Review.
Примерно тогда же (1970г) появилась концепция Servant Leadership.

И сначала я подумал, что это два противоположных стиля менеджмента:
Servant Leadership предполагает, что руководитель служит команде. Но как служить команде и не брать на себя задачи?

Давайте в комментах подискутируем: где граница между Servant Leadership и Обезьяньим менеджментом?

🎧 Сходил в подкаст Frontend Weekend к Андрею Смирнову!

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

Отдельно хочу поделиться темой, которая для меня самого сейчас особенно актуальна:

Менеджер или индивидуальный контрибьютор?

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

Почему? Потому что, когда ты инженер, у тебя каждый день есть возможность получать удовольствие от быстрых и понятных результатов.
Вот ты написал код, отладил — работает! Сразу получил обратную связь и дофамин.
Чего-то не было — благодаря тебе теперь есть. Ты создал. Ты — созидатель.
Это мгновенная радость от понятного и ощутимого результата.

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

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

Выбор «менеджер или инженер» — это не про статус, а про то, какую работу ты больше любишь делать и от чего получаешь удовольствие.

———

Ещё из интересного, что мы обсудили:

📍 Почему полезно поработать в разных компаниях: стартапах, аутсорсе и крупных корпорациях, и как это делает тебя сильнее.
📍 Как жить в Испании, а работать на московский часовой пояс (сложно).
📍 Зачем мне права на прицеп, и как выглядит путешествие на машине длиной в 30 дней из Москвы до Валенсии.
📍 Как европейская бюрократия оказалась человечнее и дружелюбнее, чем российский паспортный стол.
📍 Какие принципы ведения телеграм-канала я нарушаю в @product_developer.
И ещё много всего полезного и личного.

Ссылка на выпуск 👉 Frontend Weekend

Кстати, вдогонку можно подписаться на канал Андрея — он делает отличные интервью!

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

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

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

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

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

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

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

Стоп. Это же были не софты, правда?

———

Это была затравочка из лонгрида, который я написал для очередного бесплатного марафона Стратоплана.

Всего будет 10 таких «вредных советов» — в формате лонгридов и 30-минутных вечерних эфиров.
Начинаем сегодня.

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

Вместе со мной будут тренеры Стратоплана и авторы тг-каналов: Евгений Антонов, Роман Ивлиев, Ольга Елисеева, и еще множество тех, кого вы, возможно, читаете.

p.s. Пару лет назад и представить себе не мог, что буду частью Стратоплана!

Регистрация тут. Бесплатно.

Shit tolerance — это софт скилл
Загадка: есть у джуна, нет у мидла, но нужно сеньору?

Нет, это не «стрессоустойчивость», не эмоциональный интеллект и не умение договариваться.

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

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

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

О чем речь?

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

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

А кому-то норм трекать время, потраченное на задачи, и заполнять таймшиты.

На любой shit есть три возможных варианта реакции:
1. Смириться
2. Уйти
3. Починить

Ну и распределение по грейдам примерно такое же:
1 — Джун  
2 — Мидл
3 — Сеньор

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

Как прокачать shit tolerance?

1️⃣ Переключиться с эмоций на действия. Вместо «это полный п#ц!» — «окей, как мы это разрулим?»

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

3️⃣ Оставлять энергию на главные вещи. Иногда лучший ответ на хаос — работать спокойно и делать своё.

Но!
Shit tolerance — не значит терпеть любой беспредел.
Если каждый день вызывает боль и ощущение бессмысленности — это не про гибкость, а про выгорание.
И да, сеньоры и лиды тоже имеют право на выход. Главное — не потерять себя и не стать частью болота.

P.S. Картинку к посту я позаимствовал из твиттера Евгения Кота. Тред замечательный, рекомендую к прочтению.

Какой у вас уровень shit tolerance? 😏

🎉 Мой новый Live-канал: про жизнь, путешествия и удалёнку без розовых очков
…каждый успешный блогер должен завести лайв-канал 😄️️️️

В Product Developer я стараюсь держать высокий уровень постов:

✅ Максимум пользы, минимум воды
✅ Только по делу — без личного и бытовухи
✅ Тщательная подготовка (иногда до 16 часов на пост)

Но вот один-единственный личный пост про Digital Nomad в Испании внезапно зашёл на 11К просмотров, 300 репостов и 300 реакций. Видимо, тема жизни и работы в других странах кому-то интересна. А мне хочется делиться таким без редакции и строгих рамок.

Поэтому мы с женой завели @sharelocations!

🏝️ О чём пишем?
— Испания без маркетинговых брошюр: переезд, быт, счета, страховки, местные законы
— Удалёнка и workation: как совместить работу и поездки без потери продуктивности
— Путешествия: 30-дневный переезд на машине из Москвы в Валенсию, маршрут на автодоме, север и юг Испании, Мадрид и деревни
— Эмиграция без розовых очков: интеграция, разница культур, локальные праздники

Последний пост — про workation: 30 дней в пути на машине, всего 4 дня отпуска, остальное — полноценная работа. Это было сложнее, чем казалось изначально.

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

Если интересно — подписывайтесь: @sharelocations

Avito Speak Up podcast

Мало кто знает, но я — петролхед. Люблю машины и мотоциклы 🙂

У меня были Subaru WRX, трехлитровые дизели от BMW и Audi, V8 6.2 от Chevy, Жигули для дрифта (2 шт), и еще 5 разных мотоциклов — от Honda Steed до BMW K1300R.

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

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

Ведущий подкаста — Женя Раев, мой коллега из Trust&Safety. 
Герой выпуска — Кирилл Вотяков, руководитель вертикали Авто. 

В выпуске ребята говорят про рынок автомобилей — историю, текущее состояние и будущее. 
Затронули тему «экономика владения vs экономика аренды», о трудностях каршеринга.
А еще о том, как развивалась и как внутри работает вертикаль Авто.

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

Avito Speak Up podcast

Кеширование — это ответ!
…а какой был ваш вопрос?

Все любят кеши.
Упираетесь в БД по количеству запросов? Кеш!
Нужно быстрее отдавать данные? Кеш!

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

1. Во-первых, кеш — это еще одна точка отказа.

Если кеш внешний, например Redis, то он вполне себе подвержен проблемам инфраструктурного характера: сеть, железки, «шумные соседи» на виртуалках, троттлинг отдельных компонентов по CPU.
А еще его нужно обслуживать: менять конфиги, обновлять с даунтаймом, …

Если ваше приложение уперлось в производительность БД, сможет ли оно выжить без кеша?
Как будете жить при недоступности Redis? Рейт-лимитер?
А насколько критично для потребителей получить отказ или задержку?

Если кеш in-memory, то как избежать повышенной нагрузки на БД при деплое?

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

2. Во-вторых, кеш — это еще одно усложнение потоков данных.
Инвалидация кеша — одна из трёх главных проблем IT, после нейминга переменных и race condition.

Готово ли ваше приложение к eventual consistency?
В каких сценариях данные в БД меняются и когда инвалидировать кеш?

3. В-третьих, кеш — это доп. затраты на поддержку.
Допустим, через год появится ещё один сценарий изменения данных.
Как гарантировать, что новый разработчик не забудет инвалидировать кеш?
Опять же, сам редис и библиотеки надо обновлять.

4. В-четвёртых, кеш никогда не даёт 100% hit rate.
Придётся экспериментировать, какие данные кешировать, чтобы hit rate был хотя бы 80%+.

5. А точно ли кеш будет быстрее, чем в PgSQL?
Во всех современных БД есть встроенные механики кеширования, и умные люди долго их оттачивали.
Парочка пруфов: Can Postgres replace Redis as a cache? + Benchmark: Postgres as cache vs Redis

Наш пример:
— Есть PostgreSQL с 300 млн записей
— Есть хорошо оптимизированный запрос, который держит 2 млн RPM и отрабатывает за 8-10 мс в 99 перцентиле. Очевидно, это тайминги без похода на диск.
— Утилизация CPU на БД уже 60%+, поэтому вводим кеш для подстраховки от пиков

И что? Время ответа выросло до 20 мс!

————

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

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

Change my mind.

Систематизация vs бюрократия

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

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

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

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

Но обычно люди в команде очень разные. И все они ошибаются.

И вот менеджер видит, что не все «достаточно талантливые», и начинает вводить процессы, чтобы подстраховать от ошибок.

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

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

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

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

Вы действительно оптимизируете работу?
Или пытаетесь защититься от некомпетентных и неуправляемых сотрудников?

Точно ли нужно строить работу с некомпетентными сотрудниками через внедрение процессов?
А когда вы в последний раз пересматривали или отменяли какой-то процесс?