11918
Канал о продуктовой разработке изнутри. Открыт для связи: @engineering_memeger
Неудобные разговоры — неприятная работа тимлида
Знаете ощущение перед таким разговором, когда придется говорить неприятные собеседнику вещи?
— Когда заказчик просит невозможного. Или хуже — когда заказчику уже продали невозможное.
— Когда кто-то накосячил и нужно донести обратную связь
— Когда сотрудник просит роста, но не особо перформит.
— Когда сверху прилетают неудобные ограничения, разнарядки и задачи, которые нужно донести команде, сохранив и авторитет компании, и свой собственный.
Ощущение такое..
«сейчас я испорчу себе карму и меня будут считать говнюком».
Опытный тимлид решает такие задачи честно и прямо. Да, кто-то останется недовольным. Но правильный подход позволяет донести позицию так, чтобы не остаться тем самым говнюком и не испортить карму.
А вот неопытный или неуверенный тимлид в таких ситуациях начинает извиваться как уж на сковородке: пытается быть «хорошим» для всех, но в итоге не решает проблему и теряет уважение команды.
Главная беда в том, что никто не рождается с навыком вести неудобные разговоры. Этому учатся — обычно через ошибки и боль.
4 июня в 20:00 (мск) Soft Skills Lab проводит бесплатный вебинар как раз на эту тему:
Как вести неудобные разговоры с командой и стейкхолдерами
Разберём на реальных кейсах:
— Как переводить эмоции в конструктив
— Как говорить неприятные вещи, не теряя контакт
— Как сохранять авторитет и держать лицо, когда на тебя давят
Ведёт Нелли Григорьева — преподаватель переговоров в ВШЭ, консультант техкомпаний, бывший маркетинг-директор международных стартапов.
📌 Zoom, можно прийти со своими вопросами.
📌 Бесплатно. Запустите бота, чтобы получить ссылку
Если вы тоже ловили себя на желании «извернуться» и сгладить углы вместо того, чтобы вести неудобный разговор прямо, — возможно, будет полезно.
Я пойду.
Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqw59Feu
🎭 Игры, в которые играют разработчики
В прошлом посте я привел пример игры «а я же говорил» — это одна из игр, описанных Эриком Берном в книге «Игры, в которые играют люди».
Когда читал, было странное чувство: как будто Берн писал не про абстрактную психотерапию, а про работу в команде разработчиков.
Это не игры ради веселья. Это поведенческие сценарии, в которых:
— есть знакомые роли (жертва, спасатель, агрессор),
— повторяются типовые ходы,
— а в финале всегда есть «выигрыш».
Что за «выигрыш»?
В русскоязычной литературе это называют «психологическим поглаживанием».
Мне больше нравится термин attention unit: единица внимания, подтверждающая наше существование.
В оригинале — strokes — единица социального/эмоционального признания:
“A stroke is a unit of recognition.”
Берн выбрал это слово, потому что исходно описывал физическое прикосновение (поглаживание) как форму признания младенца.
Отсюда и идея, что взрослые продолжают искать такие же «эмоциональные прикосновения» — в форме внимания, похвалы, критики, …
«Я тут один всё делаю!»
«Вы даже не замечаете, сколько я вкладываю!»
«Разгребать, конечно, как всегда всё мне!»
Disagree and Commit
Disclaimer: тема спорная, мнение непопулярное, призываю к срачу в комментах 🙂
Ситуация:
На встрече обсуждают подход к сложной задаче.
Один из разработчиков считает, что идея плохая. Он аргументирует, предлагает альтернативы. Но команда (или руководитель) выбирает другой вариант.
Какие есть варианты поведения?
Вариант 1. Сделать «по кривому ТЗ», чтобы потом сказать: «Ну, я предупреждал»
На первый взгляд, выглядит логично: разработчик честно указал на проблему, а теперь просто делает работу как ему сказали.
Но на деле это превращается в психологическую игру по Эрику Берну — «А я же говорил»:
— Человек берёт задачу в работу без желания и делает минимально, без инициативы.
— Малейшие трудности и не предусмотренные при обсуждении проблемы он не решает, а использует как лишний аргумент против принятого решения.
— Подсознательно он ждёт неудачи, чтобы потом показать, что был прав («Ну что, кто теперь виноват?»).
В краткосрочной перспективе человек получает чувство превосходства и подтверждение своей правоты («психологическое поглаживание»).
Но доверие в команде портится, коллеги начинают воспринимать его как токсичного и несговорчивого.
Вариант 2. Продолжать спорить, пока не достигнут полного согласия
Звучит как зрелый подход: ведь все должны быть согласны, прежде чем двигаться дальше.
Но это часто ведет в «ловушку консенсуса»:
— Обсуждения становятся бесконечными, никто не хочет брать ответственность за финальное решение.
— В итоге команда договаривается о компромиссе, который никому не нравится до конца и даст хреновенький результат.
Вариант 3. Disagree and Commit — не согласен, но обязуюсь сделать
Amazon и другие компании используют подход Disagree and Commit, чтобы избежать первых двух проблем.
Подход простой:
1. Пока решение не принято — нужно спорить, задавать неудобные вопросы, предлагать альтернативы.
2. Когда решение принято — вся команда действует так, словно это решение было общим и наилучшим, даже если кто-то с ним не согласен:
«Я не согласен, но понимаю, почему выбрали этот вариант. Сделаю задачу максимально хорошо, как если бы сам был её сторонником».
Обе части критично важны:
Нужно открыто высказываться, спорить и аргументировать до принятия решения.
После принятия — брать ответственность за общий результат.
Подход не заработает, если в команде нет доверия и открытости (см пост про 5 пороков команды).
Профит:
🧠 Принимаем сильные решения, иногда непопулярные. Избегаем ловушки консенсуса и посредственных решений.
⏱️ Двигаемся вперёд, команда не буксует. Экономим время. Нет откатов и «давайте ещё подумаем».
🤝 Повышаем доверие. Умеем спорить — и умеем поддержать общее решение.
🔁 И главное: а вдруг ты не прав? Решение группы может оказаться лучше твоего. Это нормально.
Когда этот подход не работает?
— Если решения принимаются в стиле «я начальник — ты дурак».
— Если нет доверия, и люди боятся высказываться.
— Если ошибка критична и затрагивает безопасность, финансы или здоровье людей — в этом случае лучше спокойно эскалировать по фактам.
TL;DR:
— До принятия решения — спорим, аргументируем, ищем лучшее решение.
— После принятия — работаем как единая команда на общий результат.
— Не играем в «А я же говорил»: это портит отношения и разрушает доверие.
— Допускаем, что коллективное решение может быть лучше личного мнения одного человека.
Закидывайте в комменты свои истории из разряда «а я же говорил» 🙂
Почему люди не оправдывают наших ожиданий?
Когда коллега не делает задачу или делает её совсем не так, первая реакция обычно негативная:
«Ну понятно, опять ему всё равно. Не старается, наплевательски относится».
5 Уровней автономности сотрудника
В прошлых постах я рассказывал, почему менеджеру не стоит забирать задачи сотрудников. Теперь рассмотрим этот вопрос с другой стороны:
Как сотруднику понять, с какими задачами идти к тимлиду, а какие решать самостоятельно?
Всё в той же статье HBR про «обезьяний менеджмент» выделяют 5 уровней автономности сотрудника.
Чем выше ваш уровень автономности, тем больше вам доверяют, тем интереснее задачи вы получаете и тем быстрее растёте карьерно.
1️⃣ Ждать указаний
— Вы не делаете ничего, пока менеджер не скажет конкретно, что и как делать.
— Инициатива и ответственность полностью на менеджере.
2️⃣ Спрашивать, как поступить
— У вас есть варианты решения, но вы ждёте, пока менеджер выберет один из них.
— Финальная ответственность на менеджере.
3️⃣ Консультироваться, затем действовать
— Вы самостоятельно придумываете решение, обсуждаете с менеджером и действуете, убедившись, что он не против.
— Ответственность уже ваша, менеджер только консультирует.
4️⃣ Действовать и сообщать о результате
— Вы самостоятельно принимаете решение, действуете, а менеджеру просто сообщаете, что именно сделали.
— Ответственность и инициатива полностью ваша, менеджер лишь информирован.
5️⃣ Действовать полностью автономно
— Вы полностью самостоятельны и берёте ответственность за задачи без обязательного уведомления менеджера.
— Обычно это область, где у вас максимальная экспертиза и полное доверие руководителя.
Пример:
Новая фича требует переделки архитектуры.
🔴 Уровень 1:
«Без тебя никак, скажи, что нам делать?»
🟠 Уровень 2:
«Есть два варианта, скажи, какой выбрать?»
⚪ Уровень 3:
«Подготовил пару решений, склоняюсь к первому. Хочу убедиться, что не упустил чего-то важного.»
🔵 Уровень 4:
«Мы обсудили и решили переделать архитектуру так-то и так-то. Работа уже идёт.»
🟢 Уровень 5:
«Переделали архитектуру, всё работает. Захочешь посмотреть — приходи.»
🛠️ Как применить модель на практике?
1. Обсудите с тимлидом текущий уровень автономности и комфортный для вас и команды следующий шаг.
2. Постепенно поднимайтесь: от «спрашивать, как поступить» до «действовать и сообщать» и далее.
3. Чем выше ваша автономность, тем больше свободы действий, интереснее задачи и заметнее вклад в общий результат.
Сотрудники с высоким уровнем автономности чаще получают продвижение, становятся ключевыми экспертами и делают карьеру быстрее.
📌 Важно помнить, что уровни автономности не фиксированы навсегда и зависят от конкретной задачи и вашего опыта в ней.
Поделитесь в комментариях, на каком уровне чаще всего вы работаете сейчас?
«Мы — молодцы, они — идиоты»
Наверняка вы встречали это на работе:
— Заказчики сами не понимают, чего хотят, ставят нереалистичные задачи и постоянно меняют требования.
— Продакты уверены, что разработчики усложняют ради «красивой архитектуры и постоянно факапят сроки.
— Команда фронта думает, что бэкенд тормозит работу, а бэкенд считает, что фронт не способен сформулировать задачу внятно.
Это явление называется ингрупповой фаворитизм — устаревшая прошивка нашего мозга, доставшаяся от предков.
Когда-то конкуренция между группами обеспечивала выживание:
— «Мы» — своё племя, источник еды, тепла и безопасности. Умные, компетентные, правильные.
— «Они» — чужие, соперники за ресурсы, от которых нужно защищаться. Ленивые, глупые, опасные.
Сегодня ресурсы стали доступнее, но мозг за 100 000 лет привык видеть мир через эту оптику:
— Подсознательно мы боимся потерять работу, статус и деньги — «стать бомжом и умереть под мостом от голода».
— Мы конкурируем за зарплату, повышение и статус.
— Проще сплотить команду, найдя «общего врага», чем честно признать свои ошибки или сложности.
Эксперимент «Летний лагерь» (1954 год):
Группу 11-летних мальчиков разделили на две команды в летнем лагере и устроили между ними соревнования.
Почти сразу между командами начались конфликты:
— Они обзывались, придумывали друг другу обидные прозвища.
— Начали портить вещи соперников и даже драться.
Главное открытие:
Чтобы разгорелся конфликт, было достаточно, чтобы одна группа увидела другую как соперника. Никаких других поводов не требовалось.
Servant Leadership vs. Обезьяний менеджмент
В комментах к прошлому посту — пожар 🙂
Основной посыл:
- Задача должна оставаться у сотрудника.
- Менеджер консультирует, направляет, помогает ресурсами, но не делает работу за сотрудника.
- Как результат — автономные сотрудники и свободное время менеджера на стратегические задачи.
Остался неотвеченным вопрос: что делать, если сотрудник объективно не может выполнить задачу самостоятельно?
«Обезьяний менеджмент» призывает отказываться решать задачи сотрудников, возвращая ответственность обратно.
«Лидер-слуга» существует для того, чтобы помогать команде. Разве это не значит, что менеджер и должен брать на себя задачи?
Основной посыл Servant Leadership:
— Устранять препятствия, создавать условия для эффективной работы, чтобы сотрудники могли спокойно делать свою работу.
— Давать ресурсы, полномочия и поддержку.
Лидер создаёт среду, в которой сотрудники могут максимально раскрыть свой потенциал.
Лидер берёт на себя задачи, которые команда не может решить без него.
Но это не значит делать за сотрудников их работу.
✅ Правильно: вовремя предоставить необходимые ресурсы и снять административные блокеры.
❌ Неправильно: делать вместо сотрудника то, что он способен сделать сам (придумать решение, написать код, провести аналитику и т.д.).
📌 Конкретный пример
Команда А пилит фичу, затрагивающую чужие сервисы.
Разработчик приходит к тимлиду и говорит: «Команда Б затягивает кодревью».
🔹 Задача команды: качественно реализовать фичу.
🔸 Препятствие: внешнее ревью.
Тимлид идёт договариваться, чтобы выстроить процесс:
— Команда А будет заранее предупреждать о предстоящих изменениях
— Команда Б будет закладывать в спринт время на ревью
— Команда Б обязуется делать ревью за 1 рабочий день
Это не чужая обезьяна, а как раз то препятствие, которое лидер обязан устранить.
…
Другая ситуация — разработчик приходит и говорит: «Нужно придумать архитектуру для фичи».
Здесь оба подхода совпадают:
— Менеджер помогает обсуждением и наставничеством, но не забирает задачу.
— Решение остаётся за сотрудником, иначе падает автономность.
🛠️ Итог:
Servant Leadership и Обезьяний менеджмент — не противоположные подходы.
Это скорее два взгляда на одну и ту же проблему с разными акцентами:
Servant Leadership — это умение вовремя убрать барьеры, чтобы команда могла автономно двигаться вперёд.
Обезьяний менеджмент — это умение не брать на себя задачи, которые команда способна решить сама.
Что думаете?
🐒 Обезьяний менеджмент
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.
Разработчик только что поставил тимлиду задачу, а он её положил в свой бесконечный бэклог.
Теперь ему придется её «приоритизировать» с другими такими же, а потом страдать, когда будет всё не успевать.
Представьте себе метафору: задача — обезьяна на плечах. Она перепрыгнула с разработчика на тимлида. К концу дня у него на плечах сидит целый зоопарк. Он занят чужой работой, а его сотрудники простаивают, потому что «ждут ответа».
📌 Коротко о проблеме:
1. Менеджер часто берёт чужие задачи, не замечая, как это происходит.
2. Сотрудники привыкают к тому, что менеджер всегда подстрахует.
3. В итоге:
- менеджер перегружен,
- у сотрудников снижается ответственность и автономность,
- задачи затягиваются, команда менее эффективна.
📌 Правила управления обезьянами:
1️⃣ Определить владельца обезьяны.
Каждая задача должна принадлежать конкретному человеку:
— Ты отлично понимаешь контекст и знаешь задачу. Давай ты предложишь решение, а я помогу его обсудить и доработать.
2️⃣ Определить следующий шаг.
У задачи всегда должна быть следующая конкретная дата и шаг.
— Давай ты на этой неделе подготовишь возможные решения.
3️⃣ Задачи должны быть заботой сотрудников, а не менеджера.
Сотрудник должен сам приходить и рассказывать о результате, а не ждать, когда тимлид спросит.
4️⃣ Назначать чёткое время и место для обсуждений.
Не «потом посмотрю», а «сможешь завтра на груминге показать, что получилось?».
Это дисциплинирует сотрудников и вас самих.
5️⃣ Использовать личное время для работы над личными задачами.
Не перерабатывайте. Не позволяйте чужим обезьянам съедать ваши вечера и выходные. Иначе вы будете выгорать, а команда — деградировать.
📌 Как применять эти правила? Пример:
Разработчик:
— Нужно придумать новую архитектуру, без твоего мнения не продвинемся.
❌ Неправильно:
— Ладно, я посмотрю, вернусь к тебе. (Обезьяна перепрыгнула)
✅ Правильно:
— Ты знаешь задачу лучше всех. Предложи 2-3 варианта решения и приноси завтра на груминг обсудить. Выберем лучший вместе. (Обезьяна осталась на сотруднике)
📌 Что получаем на выходе?
✅ Сотрудники учатся принимать решения и нести за них ответственность.
✅ Вы освобождаете своё время на стратегически важные задачи.
✅ Растёт автономность и мотивация команды.
———
🐵 Итог: не позволяйте чужим задачам прыгать к вам на плечи.
Каждая обезьяна должна иметь своего хозяина, а менеджер должен следить за зоопарком, а не кормить каждую зверюшку лично.
Пост написал по мотивам статьи 1974 года в Harvard Business Review.
Примерно тогда же (1970г) появилась концепция Servant Leadership.
И сначала я подумал, что это два противоположных стиля менеджмента:
Servant Leadership предполагает, что руководитель служит команде. Но как служить команде и не брать на себя задачи?
Давайте в комментах подискутируем: где граница между Servant Leadership и Обезьяньим менеджментом?
Софты нужны тем, у кого не всё в порядке с хардами
… Болтать — не мешки ворочать! Лучше б делом занялись.
В IT ты крутой эксперт, если глубоко разбираешься в технологиях: умеешь шардировать БД, оптимизировать SQL запросы, тушить пожары на проде.
А всё остальное, особенно те самые «софт-скиллы», многие считают чем-то второстепенным.
Ну, типа… харизма, характер, общительность, презентации… менеджерская фигня, короче.
У меня был знакомый тимлид, который думал именно так.
И вот как-то в его команде сеньор-инженер три месяца упорно трудился, пилил мегасложную фичу, но про статус работы особо никому не рассказывал. Тимлид тоже не любил лезть с «глупыми вопросами», он и так видел все коммиты и думал: «Всё под контролем, что может пойти не так?»
За пару дней до релиза оказалось, что сеньор прекрасно решил задачу. Но не ту, что просил бизнес. Да и архитектура была красивая, мощная и совершенно несовместимая с текущим продом.
Тимлид не растерялся и решил проблему единственно правильным способом:
Он лично сел и идеально переписал весь код за выходные, согласовал изменения с бизнесом, и даже потратил ещё несколько ночей на деплой и поддержку после релиза. Ну да, немножечко переработал, но зато всё идеально.
А что сеньор?
Сеньора уволили, а вместо него наняли другого.
Теперь уже такого, который умеет и требования согласовать, и статус по задачам регулярно давать, и риски озвучивать.
И тимлида потом тоже уволили, потому что он все пожары тушил сам и в итоге не справился. А вместо него наняли другого.
Который умеет управлять рисками, делегировать и доносить обратную связь.
Стоп. Это же были не софты, правда?
———
Это была затравочка из лонгрида, который я написал для очередного бесплатного марафона Стратоплана.
Всего будет 10 таких «вредных советов» — в формате лонгридов и 30-минутных вечерних эфиров.
Начинаем сегодня.
Примеры тем:
– делай всё сразу: кто сказал, что многозадачность неэффективна?
– кому надо, тот поймет. Никогда не давайте обратную связь
– планировать — это для средних умов, гении господствуют над хаосом
Вместе со мной будут тренеры Стратоплана и авторы тг-каналов: Евгений Антонов, Роман Ивлиев, Ольга Елисеева, и еще множество тех, кого вы, возможно, читаете.
p.s. Пару лет назад и представить себе не мог, что буду частью Стратоплана!
Регистрация тут. Бесплатно.
🎉 Мой новый Live-канал: про жизнь, путешествия и удалёнку без розовых очков
…каждый успешный блогер должен завести лайв-канал 😄️️️️
В Product Developer я стараюсь держать высокий уровень постов:
✅ Максимум пользы, минимум воды
✅ Только по делу — без личного и бытовухи
✅ Тщательная подготовка (иногда до 16 часов на пост)
Но вот один-единственный личный пост про Digital Nomad в Испании внезапно зашёл на 11К просмотров, 300 репостов и 300 реакций. Видимо, тема жизни и работы в других странах кому-то интересна. А мне хочется делиться таким без редакции и строгих рамок.
Поэтому мы с женой завели @sharelocations!
🏝️ О чём пишем?
— Испания без маркетинговых брошюр: переезд, быт, счета, страховки, местные законы
— Удалёнка и workation: как совместить работу и поездки без потери продуктивности
— Путешествия: 30-дневный переезд на машине из Москвы в Валенсию, маршрут на автодоме, север и юг Испании, Мадрид и деревни
— Эмиграция без розовых очков: интеграция, разница культур, локальные праздники
Последний пост — про workation: 30 дней в пути на машине, всего 4 дня отпуска, остальное — полноценная работа. Это было сложнее, чем казалось изначально.
P.S. Испытываю эмоции, как 4 года назад, когда этот канал был еще совсем малыш. Очень приятное чувство нового начала.. Смесь энтузиазма и опасений, что ничего не получится, но вера и желание писать. 🙂
Если интересно — подписывайтесь: @sharelocations
Систематизация vs бюрократия
Талантливые ребята обычно умеют систематизировать, даже если делают это интуитивно.
Здесь под словом «систематизация» я имею в виду создание логической структуры, чтобы любой процесс или информация стали понятными, воспроизводимыми и управляемыми.
И тут ключевое слово — управляемыми.
Потому что если ты не можешь управлять чем-то, ты либо оставляешь это на волю случая, либо начинаешь реагировать на пожар, а не предупреждать его.
Круто, когда ваша команда состоит сплошь из талантливых ребят. Они могут работать без процессов и делать дело, пока другие занимаются своими сторипоинтами и ретроспективами.
Но обычно люди в команде очень разные. И все они ошибаются.
И вот менеджер видит, что не все «достаточно талантливые», и начинает вводить процессы, чтобы подстраховать от ошибок.
Я не встречал менеджеров, которые вводят процессы, чтобы усложнить жизнь сотрудникам.
Обычно цель благая — сделать продукт лучше, несмотря на риски и человеческий фактор.
Пример: в пятницу вечером кто-то деплоит неработающий код. В выходные сайт лежит, пользователи страдают, а компания теряет деньги.
Чтобы от этого застраховаться мы вводим линтеры, код-ревью, автотесты, релизные часы, дежурства, мониторинг, алерты, …
И это как будто бы нормально. Редко кто против линтеров и код-ревью.
Но бывают процессы, которые приносят боль. У всех это разное: кому-то не нравится оценка задач в сторипоинтах, кого-то выворачивает от потребности планировать спринты на две недели и потом оправдываться за скоуп-дроп.
Системность легко превращается в избыточную бюрократию.
Если ваша команда тратит слишком много времени на процессы, задайте себе вопрос:
Вы действительно оптимизируете работу?
Или пытаетесь защититься от некомпетентных и неуправляемых сотрудников?
Точно ли нужно строить работу с некомпетентными сотрудниками через внедрение процессов?
А когда вы в последний раз пересматривали или отменяли какой-то процесс?
10 привычек растущих сотрудников
К слову о привычках.
Я вписался в 9-месячный курс от Стратоплана за дохрена денег. Проходной балл высокий: не достаточно заплатить, — нужно еще сделать тестовый кейс и пройти собеседование.
Стратоплан — господа уважаемые. Могут себе позволить, так сказать 🙂
В общем, кейс я решил и собес прошел, поэтому иногда буду писать свою рефлексию на тему материалов курса.
А пока — приношу бесплатную полезность: 2х-недельный марафон, который подойдет вообще всем: инженерам и тимлидам, аналитикам, продактам, СТО и фаундерам.
Начнется 13 января.
Спикерами и авторами будут команда тренеров Стратоплана, а также уважаемые товарищи по телеграм-каналам: Евгений Антонов («Тимлид очевидность»), Ольга Елисеева («Teamlead с места в career»), Александра Баптизманская («Нестыдная фасилитация»).
Каждый день будет либо эфир, либо лонгрид.
Вот некоторые привычки:
— Прояснять мотивы и потребности, ожидания других людей
— Регулярность и дисциплина
— Обращать внимание на мелкие детали
— Запрашивать и давать обратную связь
— Работать над личным брендом и своим визабилити
— Послать дела нахрен, чтобы успеть их вовремя
О каждой расскажут не только, почему она полезная, но и как её себе привить.
Участие бесплатное, доступ ко всем материалам останется навсегда.
Нужно только зарегистрироваться: https://stratoplan-school.com/habits/
13-25 января.
P.S. за этот пост мне не платили
Решение проблемы плохого WiFi
Пост не совсем про продуктовую разработку, но очень хочу поделиться.
На каждой работе у меня был коллега_с_хреновым_интернетом.
Кажется, это мелочь и его личная проблема. В конце концов, код пишется и дело делается, так что можно и потерпеть.
Но на самом деле плохой интернет сказывается на эффективности встреч, отношении к человеку и, как следствие, его карьерном росте.
Работать с таким человеком просто неприятно: размытая картинка, пропадающий голос, непонятно, услышал он тебя или нет. А ещё постоянные вылеты со встреч.
Привет, последние полтора года это я 😅
Я борюсь за интернет с соседями.
На прошлой неделе наконец-то победил!
Живу в многоквартирном доме, где ноут видит 20+ WiFi сетей. Ethernet розеток нет, а вход для роутера закладывался в одном месте во всех квартирах. Поэтому все роутеры соседей стоят в одном углу, а стены у нас тонкие.
Из-за этого WiFi нестабильный даже рядом с роутером.
И это люто бесит.
Расскажу, как боролся и как победил.
Помогло решение, к которому шел 1.5 года:
Ethernet over Powerline.
Устройство преобразует цифровой Ethernet в радио сигнал, и пуляет его в розетку, используя провода под напряжением как среду для передачи сигнала.
На другой стороне приёмник проделывает обратное преобразование: ловит радио сигнал из розетки и преобразует его в цифровой Ethernet.
Я слышал об этом еще лет 15 назад, но тогда подумал, что это какая-то хрень и работать нормально не будет.
А тут уже перепробовал все варианты и терять было нечего, поэтому заказал.
Как же я охренел, когда это завелось.
Просто воткнул девайс в розетку, а Ethernet кабель в роутер и в ноут. И теперь ноут думает, что он напрямую подключен в роутер.
Да, обещанного 1ГБит не дало, но пинг до гугла 9мс и speedtest показал симметричные 170МБит.
Теперь это мой мастхэв для съемного жилья.
Потому что провод всегда стабильнее чем Wi-Fi!
———
Как пришел к этому решению?
Расскажу путь, чтобы вы могли его не повторять 🙂
1. Выбор канала WiFi.
В WiFi 2.4Ghz есть 100MHz и 11 каналов. При этом каждому каналу нужно минимум 20Mhz для модуляции сигнала. Получается, что каналы работают с перекрытием.
Поэтому по факту выбор стоит между 1, 6 и 11.
Если рядом стоят три и более роутера — они друг другу мешают.
Большинство роутеров используют автовыбор, но соседские сети не дают нормально работать даже при ручной настройке.
В MacOS есть встроенная утилита «Беспроводная диагностика» (в меню «Окно» -> «Сканирование»), которая помогает найти менее зашумленный канал.
Cначала мне показалось, что выбор правильного канала помог. Но потом какой-то из соседских роутеров решил, что этот канал ему тоже нравится, и стало опять плохо.
2. Смена роутера на WiFi 5GHz
Решил я попробовать современные технологии — WiFi 5GHz
Каналов больше, проблемы шумных соседей быть не должно.
Прекрасно, подумал я, и заказал новый роутер.
Но оказалось что до дальнего конца квартиры, где я работаю, WiFi 5 не долетает.
3. Провод
По квартире разведены телефонные розетки. Прекрасно, подумал я, и купил обжимку + 4-жильный телефонный кабель + горстку RJ45 и RJ11 коннекторов.
Я осознавал сразу, что это тупиковый путь, но всё равно решил попробовать Вот, пишу, можете не пробовать 🙂
Телефонные провода, даже 4-жильные, не подходят для передачи Ethernet сигнала. То ли изоляции нет и наводки слишком сильные, то ли кабель с большим сопротивлением.
В общем, устройства друг друга не видели.
Дальше думал уже ставить WiFi репитер, но идея использовать провод меня не отпускала.
———
Короче, если мучаетесь с WiFi — попробуйте Poweline Adapter!
Оно того стоит.
P.S. Поделитесь в комментах, какие еще есть варианты решения проблемы, которые я не попробовал?
Стиль менеджмента Linux kernel
«Прежде всего, я бы посоветовал купить “Семь навыков высокоэффективных людей” и не читать. Сожгите, это отличный символический жест.»
Сижу хихикаю со статьи Линуса Торвальдса про менеджерские практики в разработке ядра линукса.
Персонаж эпотажный, запомнился мне словами «Nvidia, fuck you».
Статья, соответственно, написана в таком же стиле.
———
1️⃣ — Решения
Все думают, что менеджеры принимают решения. Чем серьезнее решение, тем круче должен быть менеджер, чтобы его принять. Это очень глубоко и очевидно, но на самом деле это не так.
Если кто-то говорит вам: “выбирайте (а) или (б), нам нужно, чтобы вы приняли решение”, — у вас проблема. Люди, которыми вы руководите, лучше знают детали, чем вы. Поэтому, если они обратятся к вам за техническим решением, вы не должны принимать это решение за них.
…
Любое большое решение стоит декомпозировать на небольшие и исправимые. Следите за тем, чтобы, если вы будете неправы (а вы будете), вы смогли бы исправить ущерб. Внезапно вы становитесь менеджером вдвойне, принимая два решения - неправильное и затем правильное.
И люди даже будут воспринимать это как истинное лидерство (кхе-кхе, чушь собачья).
2️⃣ — Люди
Большинство людей — идиоты. Быть менеджером означает, что вам придется иметь с ними дело, и, что более важно, — им придется иметь дело с вами.
Оказывается, что посраться с людьми довольно легко, а вот завоевать доверие — сложно. Таким образом, срач немедленно подпадает под категорию “необратимых” решений и становится запретным в соответствии с п. 1. Решения.
Здесь есть всего несколько простых правил:
1. не называйте людей придурками (по крайней мере, публично)
2. научитесь извиняться, если забыли правило (1)
3. уважайте всех в равной степени, чтобы никто не чувствовал себя несправедливо обиженным
На самом деле, не существует возможности быть неизменно вежливым. Никто не будет доверять тому, кто так явно скрывает свой истинный характер.
3️⃣ — Люди — хорошие
Большинство людей - идиоты, и как следствие — вы тоже.
Поэтому всегда найдётся кто-то умнее.
Убедитесь, что вы используете умных людей в своих интересах. Подлизывайтесь к ним, потому что именно они облегчат вашу работу.
Когда вы найдете кого-то умнее себя, ваши управленческие обязанности сводятся к тому, чтобы говорить: «Звучит как хорошая идея — дерзайте» или «Звучит хорошо, но что если xxx?»
Вторая версия, в частности, является отличным способом либо узнать что-то новое об «xxx», либо проявить себя как руководитель, указав на то, о чем более умный человек не подумал. В любом случае вы выигрываете.
4️⃣ — Поиск крайнего
Что-то обязательно пойдет не так, и люди захотят кого-нибудь обвинить. Это будете вы.
На самом деле, принять вину на себя не так уж и сложно, особенно если люди понимают, что это была не только ваша вина. Что подводит нас к лучшему способу взять вину на себя: сделайте это для другого парня.
Вам будет приятно, что вы взяли вину на себя, ему будет приятно, что его не обвинили, а парень, который потерял всю свою коллекцию порно из-за вашей некомпетентности, неохотно признает, что вы, по крайней мере, не пытались увильнуть от этого.
Затем лично сообщите разработчику, который на самом деле облажался, что он облажался. Не только для того, чтобы он мог избежать этого в будущем, но и чтобы он знал, что он у вас в долгу. И, что еще важнее, — он, скорее всего, тот человек, который может это исправить. Потому что, давайте посмотрим правде в глаза, это точно не вы.
В первую очередь, именно поэтому вы становитесь менеджером, беря вину на себя. Это часть того, что заставляет людей доверять вам и дает вам возможность прославиться, потому что именно вы можете сказать: «Я облажался».
———
Это не все пункты, советую почитать оригинал.
Я не со всем согласен, местами у самого горит.
Должен ли менеджер принимать решения?
Должен ли разработчик нести ответственность за свои косяки?
Давайте обсудим в комментах 🙂
Идемпотентность
… То, о чем многие слышали, но стеснялись спросить 😁
Разбавим менеджерские посты и немножко попроектируем, чтобы разобраться с понятием идемпотентности.
Приведу типичный диалог с Systems Design интервью.
Делаем платёжную систему.
Пользователь хочет отправить другу 1000р.
Но вдруг дрогнула рука, и он дважды нажал кнопку «оплатить».
В итоге отправилось два запроса и с карты списалось дважды.
Что делать?
— «Давайте отключать кнопку после первого нажатия!»
Это первое, что приходит на ум. Вариант хороший с точки зрения UX, но проблему решает не полностью.
Допустим, запрос на сервер пришел, сервер его корректно обработал, но из-за сетевых проблем ответ не вернулся.
Клиент видит сообщение «что-то пошло не так, попробуйте еще раз», нажимает повторно — и списываются ещё 1000р.
— «Давайте дедуплицировать запросы по сумме и назначению!»
Вот мы и подобрались к понятию идемпотентности, но еще пока не совсем с правильной стороны.
Идемпотентность — это свойство операции, при котором повторное выполнение будет давать тот же результат, что и первое.
Простыми словами: даже если клиент отправит один и тот же запрос 10 раз, результат будет один и без дополнительных сайд-эффектов.
Казалось бы, можно пост на этом заканчивать.
Но подождите, есть еще не обработанные ситуации:
— Что, если пользователь реально хочет отправить еще тыщу?
— Что делать партнёру, который интегрировался с нашим платёжным шлюзом по API и автоматизировал выплаты своим клиентам?
Ему надо отправить 1000р сейчас и еще 1000р через минуту.
Попытки дедуплицировать по параметрам усложняют логику:
— Сколько времени хранить историю запросов?
— Что делать, если в запросе 100 параметров?
— Что если реально надо отправить подряд три транзакции по 1000р?
Ключ идемпотентности помогает решить эту проблему.
Идея простая:
1. Клиент генерирует уникальный ключ (например, UUID) для каждого запроса.
2. Все повторные попытки отправляются с этим же ключом.
3. Сервер хранит результат выполнения операции по этому ключу и возвращает его при повторных запросах.
Реализовать идемпотентность можно по-разному. Самое простое — кеширование ответов по ключу идемпотентности. Так, например, сделано у Stripe.
На картинке sequence-диаграмма с более сложным, но персистентным вариантом — ключ идемпотентности прикапывается в нашу транзакцию.
В качестве бонус-контента дам ссылку на моё любимое видео — Идемпотентность на коровах.
В двух словах — «Беременную корову нельзя осеменить повторно».
———
Надеюсь, я своими менеджерскими постами еще не всех подписчиков-технарей растерял 🙃
Надо бы почаще писать про всякое техническое.
А вы учитываете идемпотентность при проектировании?
Не становись тимлидом, не совершай ошибку
Обычно, когда разработчик становится тимлидом, про него говорят «вырос».
Но я не считаю это ростом. Мне больше нравится слово «переход».
Сейчас объясню, почему.
К грейдам разработчиков все привыкли: джун, мидл, сеньор.
Почему никто не говорит про грейды тимлидов? Ведь бывают начинающие тимлиды, уверенные и бывалые.
Да-да, тимлид тоже бывает джун, а бывает сеньор.
❓ Как думаете, когда сеньор-разработчик «вырастает в тимлиды», каким тимлидом он становится?
Правильно, джуном.
Снова появляется гамма ощущений из детства джунства:
— 😰 Сталкиваешься с неизвестной тебе проблемой и даже не знаешь, куда копать. Только рядом нет сеньора, которого можно было бы спросить.
— 🚨 Боишься накосячить. Только теперь цена ошибки гораздо выше: раздрай в команде, увольнения, сорванные сроки по проекту.
— 😕 Вокруг происходят непонятные тебе вещи, взрослые дяди говорят на взрослом языке, и ты вроде понимаешь, что это важно, а поучаствовать в разговоре не можешь.
Рост ли это?
Сомнительно.
Много ли от этого удовольствия?
Меньше, чем от разработки.
…
📌 Есть и другие неприятные моменты работы тимлидом:
— 😩 Постоянное нытьё. Когда ты внутри команды, это не заметно. Но у каждого есть свои проблемы, и ты как тимлид становишься той самой жилеткой. Ты будешь в контексте всего, что происходит у 9 человек. У тебя теперь в 9 раз больше личных и рабочих проблем. При этом ты не сможешь помочь всем и каждому. И от этого можно сойти с ума.
— 🤬 Люди косячат, и ты должен доносить им корректирующую обратную связь. Им неприятно. Тебе неприятно. А в какой-то момент ты должен будешь кого-то уволить. Может быть не в первый год, но этот момент точно наступит.
— 📑 Бюрократия и бесконечные отчёты. Даже в компаниях «без бюрократии», ты поймешь, что количество бумажной рутины выросло.
— 🎭 Окунание в корпоративные политические игры. Даже в «бирюзовых организациях» есть политика. Просто её сложнее будет увидеть.
— 📲 Встречи. Календарь превращается в сплошную портянку митингов.
— 💬 Контексты, контексты, контексты. Постоянное переключение между задачами, темами и людьми. Для разработчика это неприемлемо. Для тимлида — это норма.
— 🤥 Ответственность. Не всегда и не все ошибки команды можно и нужно предотвращать. Команде нужно давать возможность учиться на ошибках. Но отвечать за них всё равно тимлиду.
…
Потом потихоньку адаптируешься, начинаешь понимать, что происходит. Становишься тимлидом-мидлом.
Только удовольствие от работы почему-то не возвращается.
Когда ты был разработчиком, ты каждый день что-то созидал: утром не было какой-то фичи, ты её написал, и вечером она уже в проде. Ты — созидатель. Это даёт дофамин каждый день.
У каждого своё соотношение задач приятных и не очень.
🎯 Для меня лично, когда был разработчиком, соотношение задач было около 80% / 20% приятных / нейтральных или неприятных.
Если меньше — надо что-то менять.
Когда стал менеджером, понял, что минимально комфортное соотношение упало до 30% / 70 %.
Скажете — мало? А больше на рынке тупо нет. Везде работа тимлидом — это напряги, стресс и рутина.
Но менеджерский кайф есть. Он другой. Отложенный и трудно уловимый, но совершенно другого уровня.
Вот ты хочешь что-то поменять в процессах, решить какую-то боль.
Сначала потратишь не один день, чтобы придумать, как именно.
Потом будешь 2 недели преодолевать сопротивление изменениям в команде.
Потом месяц будешь наблюдать за тем, стало ли лучше.
И вот спустя 3 месяца тебе надо будет остановиться, посмотреть назад, увидеть «было/стало», и как следует от этого кайфануть.
В одиночестве.
И никому особо не похвастаешься: как было хреново, уже не помнят. Как хорошо стало — не видят: для команды это новая «нормальность» и в ней есть проблемы.
Готовы ли вы ждать месяцы ради такого призрачного кайфа?
Подумайте хорошенько, прежде чем идти в тимлиды.
South HUB — кэмп для C-Level
Сегодня у нас премиум-интеграция 🙂
Когда я был разработчиком — любое решение можно было обсудить с соседями по команде. Подойти, подкинуть идею, услышать честную реакцию.
А если тема сложная и в команде идеи кончились — есть куча конференций под любую проблему.
Стал тимлидом и в какой-то момент почувствовал, что перестал быть своим — «отъехал». Новые решения и ответственность, и не всё уже можно обсудить с ребятами.
Благо, есть конференции для тимлидов, где можно перенять опыт и поделиться болью с такими же «отъехавшими».
Потом по мере роста в менеджменте встреч стало больше, а людей видел всё меньше. Задачи стали крупнее, результат более отсроченным, а последствия — тяжелее. А ещё всё чаще чувствовал, что остаюсь с решениями один на один.
А с конференциями стало уже совсем туго.
Когда мне рассказали про South HUB, я думал, это что-то вроде выставки-продажи, куда C-level приходят за партнёрами и сделками. Но оказалось, это вообще другая история.
South HUB — это кэмп. Живой, тёплый, честный. С хайкингом, костром и теми, кто понимает. Это конференция, где топ-менеджеры и руководители могут спокойно обмениваться опытом и обсуждать важное с теми, кто проходит через похожие вызовы.
В программном комитете ребята, которым доверяю. Например, ув. тов. Владимир Коноплев — с ним мы делали воркшопы про тимлидское, а сейчас он СТО в Т-Банке.
Что будет:
— 2/3 участников — C-level, ещё четверть — хеды и руководители направлений.
— Спикеры, которых хочется слушать. Например, Андрей Рыбинцев из Авито, который был моим продуктовым директором, когда я только пришел в Авито.
— Живые кейсы и обсуждение ситуаций, через которые топы проходят прямо сейчас.
— Хайкинг, лекции, игры и костры — чтобы перезагрузиться и восстановить баланс.
— И самое важное — доверительный нетворк, который остаётся надолго.
📍 11–15 июня, Газпром Поляна
🌐 билеты southhub.ru
🔗 tg-канал @sthhb
Technical Product Manager — редкий зверь
Представьте, что вы — продакт, отвечающий за развитие… русского языка.
Какие у вас цели? Улучшить UX? Сократить технический долг? Убрать букву «ы»?
Как собрать фидбэк? Как мерить метрики?
Артём руководит продуктовым офисом в Яндексе и делает платформу для разработчиков.
Его команда решает похожие задачи — только не с алфавитом, а с языками программирования, процессами разработки и внутренними инструментами.
Я читаю его канал @badtechproject, потому что он пишет про сложные вещи без буллшита. Вот несколько постов, которые особенно зацепили:
🛠 Про систем-дизайн на собесах
Артём вводит систем-дизайн как обязательную часть интервью для project-менеджеров. И это логично: если ты управляешь командой, неплохо бы понимать, как устроена система. В посте — разминка «спроектируй Twitter», советы и книга, которую стоит прочитать, даже если ты не инженер.
💬 Про "интервью наоборот"
Хороший чеклист «О чем спросить работодателя». Артём так же считает, что хорошее собеседование — это разговор двух взрослых людей, а не экзамен. И умение задавать вопросы — это навык, который повышает шансы получить сильную команду, а не просто оффер.
🔥 Про выгорание — в формате вредных советов
Очень жизненно. Я нашёл там пару пунктов, по которым проходил лично. Формат ироничный, но содержательный: как раз для тех, кто не любит душных лекций про баланс и ресурсное состояние.
Если вы project, product или тимлид и хотите:
— лучше понимать технику,
— разбираться в процессе найма,
— не выгореть в попытке быть идеальным,
подписывайтесь на @badtechproject. Канал — живой, честный и с пользой.
———
📝Встреча с задачей📝
У меня есть боль: между встречами — разрывы по 30–60 минут, в которых вроде бы можно что-то сделать…
Но сил нет, фокус не включается, а к вечеру смотрю на список задач и думаю: «ну вот, снова ничего не успел».
Хотя список задач есть. Он даже приоритизирован. Но до него руки не доходят, пока задачи не становятся срочными. А если и доходят — уходит время на разогрев.
Недавно попробовал странно простую вещь: ставить задачи в календарь.
Прямо как встречи.
🔹 Так у задачи появляется конкретный слот времени — в него уже не влезет ещё один созвон.
🔹 Есть напоминалка за 15 минут до «встречи», помогает настроиться на задачу.
🔹 И, внезапно, появляется лёгкое чувство неловкости, если в этот слот делаешь не то.
Как будто прогуливаешь встречу с собой.
Инсайт этот не мой — наткнулся на пост Алексея Арефьева, автора канала @alexcouncil.
Суть простая:
Задачи — это тоже встречи. Только с собой.
Плюс — можно использовать цвета, чтобы понимать тип активности с первого взгляда:
🟢 регулярки, 🔴 разовые встречи, 🔵 задачи.
Я пока только начал пробовать — но кажется, это лучшее, что случалось с моим фокусом с начала года.
Давно читаю канал Алексея. Там еще и мемчики есть. Подписывайтесь 🙂
🎯 Пособеситься — это тоже навык
Disclaimer: это реклама бесплатной консультации от Карьерного цеха
Раз в год-два я хожу на рынок «пособеситься». Не чтобы уходить, а чтобы свериться с реальностью: чего я стою, как звучит мой опыт, какие сейчас ожидания у компаний.
Но в этот раз нарушил правило, 3 года не практиковался.
И когда решил снова — понял, что растерял навык:
1. Меня не зовут
2. Не понимаю, кто я сейчас для рынка
3. Разучился внятно рассказывать про свой опыт
4. Неясно, как за 3 года изменились зарплаты
И тут приходит простая, но неприятная мысль:
собеседование — это экзамен.
Не самый честный и не самый логичный, но экзамен.
А если ты давно не сдавал экзамены — можешь забыть, как это делается.
Чтобы понять, как вернуться в тонус, можно пойти на бесплатную консультацию в Карьерный Цех.
Карьерное сопровождение — это не волшебная таблетка. Просто нормальная, внятная точка входа, где помогут:
1. Разобраться, как вы выглядите для рынка сейчас.
2. Оценить навыки, сильные стороны и карьерные цели.
3. Понять, как упаковать опыт и где зарыты карьерные возможности.
Если дальше захотите сопровождение — можно будет вписаться. А если нет — просто уйдёте с пониманием, куда двигаться и как.
👉 Записаться на бесплатную консультацию
Реклама. ИП Федоров Е.П.
ИНН 532008901966
Как управлять людьми, а не чужими задачами
В последних двух постах мы обсуждали, как лидеру управлять командой, а не таскать на своих плечах чужие задачи.
Monkey Management, Servant Leadership, автономия сотрудников — это всё звучит классно, но как это выглядит на практике?
Узнаем на PeopleSense 2025!
Конфа специально для тех, кто управляет людьми и командами. Организаторы — те же ребята, кто делает топовую ProductSense.
Если вы тимлид, менеджер или хотите им стать — это точно для вас!
Примеры докладов:
📍 Как растить лидеров-решал? — Дмитрий Павлов
Очень интересно сравнить концепцию с Servant Leadership и Monkey Management 🙂
📍 Менеджмент 18+: сотрудник — не ребенок, менеджер — не родитель — Антон Бевзюк
С Антоном мы вместе работали в Райфе, он построил там крутое скрам-сообщество, поэтому я ему доверяю и буду рад послушать доклад
📍 Как перейти от управления людьми к управлению работой — Алексей Пименов
Спикера и так все знают, чисто ради Алексея можно на конфы ходить
Всего будет 32 доклада и 20 мастер-классов
Даты: 19–20 мая, Москва
👉Подробности и расписание тут
Митап для тимлидов от HH
📍 3 апреля, офлайн в Москве, м. Белорусская
hh.ru собрал руководителей из Яндекса, Сбера, Т-Банка, VK и МТС, чтобы поговорить о том, как сейчас эффективно нанимать и оценивать сотрудников, чтобы потом не жалеть
📌 Что обсудят:
— Как выявлять кандидатов, которые умеют красиво проходить собеседования, но не умеют работать.
— Почему оценка навыков полезна не только на собеседованиях, но и в развитии сотрудников.
— Как AI-скрининг и нейросети меняют подходы к подбору, и как это использовать с пользой, а не для хайпа.
📌 Почему я бы пошёл:
— Найм и оценка — это часто про какие-то остренькие истории, а здесь будут разбирать именно кейсы и конкретные примеры.
— Интересно, какие подходы и инструменты реально работают, а что — бесполезный хайп.
— Ценно услышать про проблемы и решения от тех, кто много нанимает, а потом обсудить всё это за бокалом вина.
Митап будет полезен для лидов разработки, аналитики, продукта, маркетинга и дизайна, HR и рекрутёров.
— 3 апреля, четверг, сбор гостей в 18:30
— Пространство Bounce: ст. м. Белорусская, 3-я ул. Ямского поля, д. 2 к. 6
Участие бесплатное, но количество мест ограничено — регистрируйтесь заранее и дождитесь подтверждения заявки.
👉 Зарегистрироваться
🎧 Сходил в подкаст Frontend Weekend к Андрею Смирнову!
Разговор получился глубокий, душевный и очень личный. Обсудили мой карьерный путь, переезд в Испанию, ведение телеграм-канала и даже немного про Digital Nomad и жизнь в Испании.
Отдельно хочу поделиться темой, которая для меня самого сейчас особенно актуальна:
Менеджер или индивидуальный контрибьютор?
Последние 2 года в Авито я руководил юнитом, а недавно стал руководителем кластера.
Работа менеджером мне действительно нравится, но я не считаю зазорным или странным снова вернуться в разработку.
Почему? Потому что, когда ты инженер, у тебя каждый день есть возможность получать удовольствие от быстрых и понятных результатов.
Вот ты написал код, отладил — работает! Сразу получил обратную связь и дофамин.
Чего-то не было — благодаря тебе теперь есть. Ты создал. Ты — созидатель.
Это мгновенная радость от понятного и ощутимого результата.
У менеджера всё не так. Результаты твоих решений и действий проявляются через месяцы, а иногда и полгода спустя.
И чтобы увидеть их и порадоваться, нужно прилагать отдельные усилия и специально рефлексировать.
Многие разработчики по инерции становятся тимлидами, не до конца понимая, что это совсем другая роль с другими правилами игры. Я очень рекомендую задуматься, подходит ли она вам, или вы просто следуете общепринятому карьерному росту.
Выбор «менеджер или инженер» — это не про статус, а про то, какую работу ты больше любишь делать и от чего получаешь удовольствие.
———
Ещё из интересного, что мы обсудили:
📍 Почему полезно поработать в разных компаниях: стартапах, аутсорсе и крупных корпорациях, и как это делает тебя сильнее.
📍 Как жить в Испании, а работать на московский часовой пояс (сложно).
📍 Зачем мне права на прицеп, и как выглядит путешествие на машине длиной в 30 дней из Москвы до Валенсии.
📍 Как европейская бюрократия оказалась человечнее и дружелюбнее, чем российский паспортный стол.
📍 Какие принципы ведения телеграм-канала я нарушаю в @product_developer.
И ещё много всего полезного и личного.
Ссылка на выпуск 👉 Frontend Weekend
Кстати, вдогонку можно подписаться на канал Андрея — он делает отличные интервью!
Shit tolerance — это софт скилл
Загадка: есть у джуна, нет у мидла, но нужно сеньору?
Нет, это не «стрессоустойчивость», не эмоциональный интеллект и не умение договариваться.
Это совершенно отдельный навык, «врожденный» у джуна, а затем падающий в нули у мидла по мере повышения насмотренности и осознания количества предложений на рынке.
Можно, конечно, попрыгать по нескольким компаниям. Даже получить лычку «сеньора» с точки зрения технических навыков. Но этот навык мидл должен прокачивать, чтобы реально стать сеньором и расти дальше в ведущего или перйти в тимлида.
Сеньор — это не просто «эксперт, который кодит». Это человек, который понимает, что хаос неизбежен, но вместо нытья думает, как его минимизировать.
О чем речь?
Shit tolerance — это способность сохранять продуктивность, когда процессы неидеальны, задачи не всегда чёткие, а идеальный мир существует только в фантазиях.
В любой работе есть неидеальность. Где-то это процессы (или их отсутствие). Например, кого-то шокирует отсутствие код-ревью. Где-то это техническая составляющая или стабильность сервисов. Кого-то может шокировать пожар на проде. Кого-то — потребность оценивать задачи и попадать в оценки.
А кому-то норм трекать время, потраченное на задачи, и заполнять таймшиты.
На любой shit есть три возможных варианта реакции:
1. Смириться
2. Уйти
3. Починить
Ну и распределение по грейдам примерно такое же:
1 — Джун
2 — Мидл
3 — Сеньор
Если нет код-ревью и видна потребность — сеньор предложит, продаст команде, и внедрит.
Если прод горит — сеньор спокойно пойдёт чинить.
Если надо выполнять задачи, взятые в спринт, — сеньор проанализирует причины и решит проблемы: улучшит процесс подготовки задач, договорится со смежниками, …
Как прокачать shit tolerance?
1️⃣ Переключиться с эмоций на действия. Вместо «это полный п#ц!» — «окей, как мы это разрулим?»
2️⃣ Отделять важное от неважного. Не все проблемы стоит решать. Нужно отличать:
— Рабочий шум, который можно фильтровать. Например, срочные задачи, которые всегда срочные.
— Системные проблемы, которые нужно решать. Например, бардак в процессах, мешающий работать.
3️⃣ Оставлять энергию на главные вещи. Иногда лучший ответ на хаос — работать спокойно и делать своё.
Но!
Shit tolerance — не значит терпеть любой беспредел.
Если каждый день вызывает боль и ощущение бессмысленности — это не про гибкость, а про выгорание.
И да, сеньоры и лиды тоже имеют право на выход. Главное — не потерять себя и не стать частью болота.
P.S. Картинку к посту я позаимствовал из твиттера Евгения Кота. Тред замечательный, рекомендую к прочтению.
Какой у вас уровень shit tolerance? 😏
Кеширование — это ответ!
…а какой был ваш вопрос?
Все любят кеши.
Упираетесь в БД по количеству запросов? Кеш!
Нужно быстрее отдавать данные? Кеш!
Но не все так просто.
В этом посте накидаю вопросов, на которые стоит ответить, если хотите добавить кеширующий слой.
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.
StarMap — карта компетенций команды
Шаблон
Забрать себе: File -> Make a copy
В двух словах — это экселька, где строки — компетенции, столбцы — ФИО, а значения в ячейках — степень владения компетенцией:
— 0 — нет навыка
— 1 — учится
— 2 — умеет самостоятельно
— 3 — может учить
А еще в этом шаблоне автоматически считается бас-фактор и риски.
Зачем вам стармап?
Для инженера:
— понять, какие навыки прокачивать, чтобы это было полезно команде
— увидеть, где можно выступить ментором
— сориентироваться, к кому идти за советом
Для тимлида:
— составить портрет команды «as is»
— увидеть бас-фактор и ботлнеки
— составить картинку «to be», целевой портрет
— проактивно пойти к разработчикам с запросом на прокачку конкретных навыков
— составить профиль кандидата для найма
———
4 года назад я уже писал пост про стармап — тогда это был способ продать его инженерам в моей команде с точки зрения пользы для них 🙂
С тех пор ни разу не заставил команду заполнять стармап, но сам как тимлид заполнил три стармапа для разных команд. По пути переосмыслил применимость инструмента.
Вот к чему я пришел:
1. Составлять стармап командой — дорого.
Не подумайте, я не отговариваю вас. Если команда сама хочет — буду только рад!
Но обычно разработчики не покупают это «менеджерское» упражнение. Приятнее фичу напилить 🙂
— Если инженер хочет что-то прокачивать и не знает что — проще прийти к тимлиду и спросить.
— Когда кого-то в команде нужно менторить — тимлид сам приходит к будущему ментору и договаривается.
— Если нужен онбординг, — выделенный бадди + хорошая дока будут эффективнее.
2. Составлять тимлидом — дешевле, и в большинстве случаев эффективнее
Во-первых, это оказался супер полезный инструмент для онбординга тимлида в новую команду.
Во-вторых, это способ систематизировать работу с командой. Каждый раз я открывал для себя какие-то неочевидные штуки, которые упустил бы, если бы не выложил «на бумагу».
Но есть минусы: без команды можно упустить компетенции. Поэтому так или иначе нужно собирать список с ребятами.
И тоже не всегда это упражнение оправдано:
— Если в команде 3 человека — скорее всего, компетенции можно удержать в голове.
— Если не планируется нового найма — то и профиль кандидата составлять не нужно.
— Если бэклог устаканился и очевидно, что все компетенции в команде есть.
Хотя повторюсь, без выписывания на бумагу есть риск что-то упустить. Даже в команде из 3 человек с устаканившимся бэклогом.
Поэтому если есть возможность и желание что-то систематизировать — со стармапом будет лучше.
———
Забирайте шаблон (File -> Make copy), составляйте стармапы, пишите комменты к посту 🙂
P.S. Шаблон — на самом деле реальный стармап одной из команд, в котором я поменял имена. Список компетенций может вас заинтересовать, но предостерегаю от прямого копирования.
Талант vs системность и трудолюбие
Вася — молодец! За что ни возьмется — всё у него хорошо получается.
Быстро разбирается в новом проекте, проектирует идеальную архитектуру и пишет рабочий код с первого раза.
Если нанимает разработчика — тот обязательно окажется топ-перформером.
Запускает проекты в срок и качественно.
Процессы и метрики для Васи — это оверхед. Лишняя нагрузка, мешающая творить:
— Зачем измерять велосити? Срок назвали, попадаем, чего еще надо?
— Зачем составлять профиль кандидата? Не так много хороших людей на рынке, чтобы к ним какую-то линеечку прикладывать.
— Какой такой cycle time? Вам шашечки или ехать?
Если Вася преуспевает с таким подходом, то скорее всего ему помогает талант.
Проблема в том, что большинство людей — не Вася.
В этом сложно признаться. Я сам сейчас сижу и думаю: «Ну я-то точно талантливый» 😅.
Вернее, раньше мне так казалось. Но за последние годы что-то поменялось.
Может, появление ребенка заняло всё внимание. Может, бюрократия и обустройство жизни в эмиграции.
Но головы стало не хватать.
Если я буду делать всё, как Вася, — то у меня получится хреново.
Поэтому я включаю системность и трудолюбие. Перестаю плеваться от «оверхеда» и ищу в нём пользу:
— При найме составляю целевой портрет команды и профиль кандидата, чтобы самому лучше понять, кого ищу.
— Слежу за метриками, чтобы вовремя заметить: команда берёт в спринт в 2 раза больше работы, чем может сделать.
— Планирую агенду встреч и веду заметки, пишу follow-up чтобы потом не гадать, о чем договорились.
— Выписываю плюсы, минусы и риски перед сложными решениями. По рискам сразу пишу план митигации.
Это отнимает кучу времени. На реальные дела остаётся только 50%.
Но это помогает не обосраться.
Мораль простая:
Даже если ты талантлив и делаешь всё «по наитию, без лишней бюрократии», — настанет момент, когда места в голове на всё не хватит.
И если к тому моменту уже будет привычка систематизировать — будет легче жить.
Fintech Product Meetup от ЮMoney 🔥
17 декабря, вторник, 19:00 мск. Бесплатно.
5 лет назад я работал в QIWI и внимательно следил за конкурентами — в частности, за ЮMoney (тогда это были Яндекс.Деньги). Помню, как мы решали одни и те же проблемы. Например, как выживали держали нагрузку в эпические ноябрьские распродажи.
Сейчас я в Авито, но тема финтеха не отпускает.
Поэтому 17 декабря буду смотреть бесплатный митап от ЮMoney
Вот, что будет:
🟣Кросс-платформенная разработка: Эксперимент с React Native, сравнение с нативом и что в итоге выгоднее
🟣Mobile Web Banking: разоблачение олдскульных мифов
🟣Редизайн главной страницы ЮKassa и какие ошибки собрали по пути
🟣Как держать фокус на стратегических задачах, когда много операционки и задач «для денег»
📍 17 декабря, вторник, 19:00 мск — приходите на митап в Санкт-Петербурге или смотрите трансляцию.
Бесплатно, но нужно регистрироваться.
Все подробности — на сайте Fintech Product Meetup.
Микросервисы в Kubernetes — это ответ!
… а какой был ваш вопрос?
Спонсор поста — Selectel.
Давайте порассуждаем, зачем вообще вам микросервисы и Kubernetes.
Все компании, в которых я работал, проходили жизненный цикл от монолита к микросервисам.
Часто это сопровождается лозунгами про гибкость, адаптивность к меняющемуся рынку и возможность масштабироваться…
Но на мой взгляд основная причина очень простая — потребность пилить больше фич, а для этого расти в количестве разработчиков и не толкаться локтями.
Именно сложность параллельной разработки на монолите приводит всех к микросервисам.
Казалось бы, можно и в монолите выстроить хорошую архитектуру, которая четко разделит домены и проведет мостики между ними, чтобы обеспечить пресловутые low coupling & high cohesion.
Но на практике не получается. Сложно контролировать эту архитектуру, когда появляется несколько команд разработки. Да и обычно к тому моменту монолит уже состоит из переплетений кода, а на его рефакторинг уйдёт времени больше, чем выделить куски в микросервисы и начать независимо разрабатывать.
Микросервисы и API как мостики для взаимодействия между ними — системное решение для low coupling & high cohesion.
Архитектура буквально заставляет нас делать поменьше запросов между сервисами, потому что разработка API — сложнее, чем подключение зависимости внутри кода.
Но приходя к микросервисам мы сталкиваемся с накладными расходами:
— Сложнее управлять деплоем и масштабировать
— Сложнее доставлять конфиги и писать логи
— Сложнее делать трассировку запросов и собирать метрики.
А еще нужно обеспечить стабильность не только приложения из микросервисов, но и всей этой машинерии.
Можно всё собирать самому. Начать с Docker-compose на трёх виртуалках, самому поднимать nginx, самому настраивать маршрутизацию. В какой-то момент нагрузка потребует добавления виртуалок и каждый раз — это будет ручная работа и накладные расходы:
— Арендовать еще железа
— Поднять там виртуалки
— Настроить на них все компоненты
— Включить в балансировку
— ….🤯
Можно автоматизировать развертывание своих велосипедов на независимых компонентах, но скорее всего в итоге всё равно придём к Kubernetes.
А это еще больше накладных расходов на сетап и обслуживание компонентов K8s.
Да и в целом правильное управление k8s — это отдельная большая область знаний.
Зачастую в компаниях есть отдельные «DevOps’ы», которые занимаются чисто кубером.
Но Kubernetes — реально отчуждаемая часть, где гораздо проще отдать ответственность хостеру и потом требовать выполнения SLA.
И здесь я верю, что с помощью Managed Kubernetes можно сэкономить и упростить себе жизнь.
Особенно если вы и так хоститесь не в своих датацентрах, а арендуете инфру.
Сервис сам разворачивает кластер Kubernetes с Control Plane, настраивает сетевое окружение, глобальный роутер и поднимает группу нод на выделенных серверах. Со стороны инженеров не нужно париться об администрировании. Вам нужно только выбрать тип кластера и конфигурацию в панели управления. При этом есть доступ к kubectl и всему, что требуется для деплоя ваших микросервисов и маршрутизации трафика снаружи и между ними.
Из плюсов именно Selectel — воркер-ноды работают не на виртуалках, а на выделенном железе. А это убегерает от спецэффектов «шумных соседей» и оверхеда виртуализации. Как итог — обещают экономию на 40% по сравнению с арендой виртуалок.
Подробнее — на лендосе Managed Kubernetes от Selectel.
Реклама, АО «Селектел», ИНН: 7810962785, ERID: 2Vtzqx9pGZm
———
Поделитесь в комментах — поднимали ли вы хоть раз кубер?
Сколько времени это заняло в первый раз и сколько времени тратите на поддержку?
Цели на испытательный срок как OKR
для любой роли, не только для тимлидов.
Пример целей моего тимлида
———
Этот пост — завершающий в серии про онбординг -> Первый пост с шаблоном чеклиста онбординга.
Сегодня поговорим про цели на ИС.
Когда прохожу собеседования, всегда спрашиваю: как вы через 3 месяца поймете, что я молодец? Зачастую ответы достаточно размытые: процессы работают, таски пилятся, продакт и команда довольны — вот и все критерии.
И это, в целом, нормально. В IT невозможно описать полный список обязанностей в трудовом договоре и критерии прохождения ИС, и я точно не призываю так делать. Этот пост не про KPI и не про формальные критерии прохождения ИС и точно не про инструмент для увольнения после испыталки.
Но есть риск: если ожидания от вас не сформулированы, то вы их можете неправильно понять и не попасть в них. И в итоге оказаться «так себе сотрудником», хотя работали усердно и по вашему мнению всё делали идеально.
Поэтому даже если целей на испыталку вам не дали, всё равно есть смысл самому себе их составить и согласовать с руководителем. При чем не важно, на какую позицию вы вышли: тимлид, инженер, продакт или аналитик. Или вы только что перешли внутри компании на новую должность.
💡Как составлять цели.
1️⃣ — Описать образ не только хорошего результата, но и превышения ожиданий, а также недостаточного результата.
Так мы поймем, что для руководителя «нормально», а что «прям вау». Ну и где «так себе». Это даст лучшее понимание ожиданий от роли, куда нужно двигаться чтобы получить промо, а где нужно обращать внимание, чтобы не упустить из виду важное.
Пример — составить долгосрочную техническую стратегию команды.
Хорошим результатом будет проведение совместной работы с командой, но при этом тимлид должен быть сам погруженным в технику, чтобы валидировать корректность предложений ребят. Если тимлид сделает всё сам без привлечения команды — это будет ниже ожиданий. А если тимлид успеет за 3 месяца составить такую стратегию, чтобы запланировать на следующий год цели с учётом этой стратегии — это будет сверхрезультатом.
2️⃣ По возможности разделить на метричные и проектные.
Метричные дают больше свободы в достижении. В работе с тимлидом важно говорить «что» нужно достичь и оставить достаточно свободы, чтобы он решил сам, «как» это реализовать. Примеры метричных целей: SLI сервисов, % флакующих тестов, Scope Drop спринта, % выполнения квартальных OKR.
В проектные цели обычно вносят личные задачи:
— провести первое перформанс ревью с минимальной помощью руководителя
— составить стратегию развития тех. домена команды
— нанять людей
Не обязательно, чтобы по всем целям срок был ровно 3 месяца. Я считаю, что испытательный срок тимлида на самом деле длится 9 месяцев. Поэтому и в целях стоит указывать проекты, по которым достичь результата за 3 месяца заведомо невозможно. Но все-таки какой-то ожидаемый срок стоит указать.
Итог
Если цели есть от руководителя — хорошо. Вы можете их дополнить, почелленджить и согласиться.
Если целей нет — составьте сами и согласуйте с руководителем, чем раньше — тем лучше. Можно использовать пример.
Цели на ИС — это способ переложить ожидания из головы руководителя в голову новичка, чтобы сфокусировать его на самом важном. Дать понять, по каким признакам будет оцениваться его работа.
А чтобы инструмент работал, нужно возвращаться к этим целям хотя бы раз в месяц и смотреть прогресс по ним.
