Олег Ильин - тимлид в BigTech

Тишина в чате — это тоже сообщение. И обычно оно звучит как «всё плохо». Знаете эту ситуацию: приходит задача от продукта, а там буквально три строчки. Ни зачем это надо, ни как должно работать, ни по каким критериям поймём, что всё получилось. И тут начинается магия додумывания. Каждый разработчик берёт эти три строчки и докручивает в голове свою версию. Кто-то решит, что надо сделать максимально надёжно и накидает кучу проверок. Кто-то сделает попроще, потому что «и так сойдёт». А в итоге получается… ну, не то. И потом все дружно исправляют: ночами, в спешке, когда сроки уже горят. Любая неточность бьёт не только по нашей работе, но и по людям, которые пользуются сервисом. Хочется ведь делать хорошо и с первого раза. Что помогает мне как тимлиду не попадать в эту ловушку: 🟢Проговаривать с командой простое правило: если в задаче непонятно «зачем» и «как узнаем, что хорошо», мы её не берём. Лучше пять минут потратить на уточнение, чем пять часов на переделку. 🟢Договариваться с продуктом: цель, ограничения, пример ожидаемого результата. Даже если это черновик — уже спасает от разночтений. 🟢Если чего-то не знаем — честно говорим: «Пока данных нет, решение будет позже. Работаем по старому плану». Это снимает тревогу и убирает почву для слухов. 🟢Все изменения кидаем в одно место и помечаем: «обновили требования». Чтобы никто не думал, что «всё осталось как было». Иногда самое ценное, что тимлид может дать команде, — это не новую фичу и не крутой инструмент, а просто понятный контекст. А у вас бывало: сделали по задаче, а потом оказалось, что все думали про разное?

😂 VK Музыка: «Мы так старались подобрать для тебя идеальное разнообразие!» А на деле — 5 плейлистов с абсолютно одинаковым содержимым. Ну, алгоритм, ну даёшь! 😄 Мало того, что я вообще не знаю этих исполнителей… Так ещё и «разнообразие» рекомендаций просто поражает — в самом ироничном смысле. 😅 В общем, стримингом, который я буду слушать регулярно, VK‑музыка точно не станет. 🤷‍♂️ Между прочим в других сервисах такой проблемы у меня не было. Часто у вас алгоритмы тоже выдают «уникальные» подборки из одного и того же?

В посте про эффект Рингельмана в комментариях мне подкинули ещё один «командный антипаттерн» из социальной психологии. Сегодня разберём, как диффузия ответственности незаметно съедает сроки и качество в разработке. Диффузия (или распыление) ответственности — это когда в группе каждый чувствует себя чуть менее ответственным, чем если бы был один. Чем больше людей вокруг, тем сильнее надежда: «Ну кто‑нибудь да сделает». Знакомо? Если в голове сразу всплыл случай, когда задача висела неделями, а все думали, что её взял коллега, — ставьте 🔥. Интересно увидеть, насколько это распространённая история в командах. Как это выглядит в жизни - Эффект свидетеля. Человеку на улице плохо, а толпа стоит и ждёт, что поможет кто‑то другой. Классика. - Рабочие процессы. Задача «на всю команду» без владельца — и дедлайн предсказуемо улетает. Каждый думает, что отчёт/баг/ревью уже в работе у кого‑то из коллег. Почему это вообще происходит - Ожидание помощи от других. Мозг охотно перекладывает ответственность на невидимого «кого‑то». - Социальное доказательство. Все спокойны — значит, всё ок. Если никто не паникует, значит, и мне не надо. - Боязнь осуждения. Страх ошибиться на глазах у всех иногда парализует сильнее, чем отсутствие времени. В разработке это бьёт особенно больно В IT диффузия ответственности часто маскируется под «командную работу»: - Неясные роли. Нет владельца задачи — есть коллективная безответственность. В итоге задача висит, а в трекере тишина. - Молчаливое согласие. В обсуждении спорного решения никто не возражает: каждый думает, что остальные лучше разбираются. А потом на проде всплывает «тот самый кейс». - Пропущенные риски. Баг или уязвимость заметили несколько человек, но каждый уверен, что его уже кто‑то завёл в трекер. На практике — никто не завёл. Что можно сделать уже сегодня - Назначайте владельца. Не «команда сделает», а «Алексей берёт задачу и даст апдейт до пятницы». - Фиксируйте явно. Если увидели риск — заводите тикет и тегните ответственного. Не полагайтесь на «кто‑то точно уже сделал». - Нормализуйте вопросы. Если ситуация кажется подозрительной — лучше спросить вслух, чем молчать из страха показаться неопытным. Поделитесь в комментариях: какая самая заметная ситуация с диффузией ответственности была в вашей команде? Что случилось и чем всё закончилось. 👇

Чем чаще нужно уточнять задачу, тем хуже она поставлена Для меня, как лида в продуктовой бэкенд-команде, это видно особенно ярко, потому что бэкенд редко работает с одной сущностью — он работает с их пересечением: данные, бизнес-правила, интеграции, edge-кейсы, которые никто не проговорил вслух. Если разработчик за день пишет тимлиду или продакту три разных вопроса по одной задаче — это не значит, что разработчик невнимательный. Это значит, что задача сформулирована на уровне идеи, а не на уровне решения. Типичные вопросы, которые вскрывают плохую постановку: 🟠«А что делать, если пользователь уже существует?» 🟠«А это должно работать синхронно или через очередь?» 🟠«А кто у нас источник правды — это поле берём из CRM или из биллинга?» Каждый такой вопрос — не разработчик тормозит процесс, а продакт или тимлид не додумал задачу до того, как отдать её в работу. Разница дорогая: вопрос на старте стоит 5 минут в чате, тот же вопрос, обнаруженный на код-ревью или, хуже, в проде — стоит переписывания и репутации фичи. Что делать тимлиду, если он видит, что по задачам команды идёт поток уточнений: 🟢вводить короткий чек-лист готовности задачи: есть источники данных, есть поведение при ошибках, есть договорённость про синхронность/асинхронность 🟢требовать явно прописывать edge-кейсы в тикете, а не оставлять «разберёмся по ходу» — по ходу разбираются все по-разному 🟢проводить груминг перед стартом спринта, где вопросы задаются один раз всей командой, а не по одному в личке весь спринт Хорошо поставленная задача — это не задача без вопросов вообще. Это задача, где вопросы заканчиваются на этапе постановки, а не размазываются по всему циклу разработки. Сколько уточнений в среднем требует одна задача в вашем беклоге — и на каком этапе они обычно всплывают?

💪 Если вы настоящий IT-шник и вас не устраивают обычные приложения, то для вас есть репка с огромной базой упражнений. Внутри 1324 упражнения с GIF-анимациями, картинками, отмеченными группами мышц, оборудованием и пошаговыми профессиональными инструкциями. 👨‍💻 можете свое навайбкодить )

Баланс: почему важно инвестировать в жизнь вне работы Как тимлид бэкенд‑команды, я часто вижу, как увлечённость кодом приводит к дисбалансу. Как я это вижу: Этап 1: позитивный цикл 🟢задачи решаются; 🟢вы получаете признание и рост; 🟢мотивация растёт — вы вкладываете ещё больше сил. Этап 2: уязвимость 🟠возникает сложная проблема (баг, дедлайн, конфликт); 🟠если работа — главный источник радости, мозг воспринимает её как «провал всей жизни»; 🟠стресс, выгорание, потеря эффективности. Решение: стратегия диверсификации Распределите эмоциональную энергию между сферами: 🟢Сон — основа когнитивных функций. 🟢Спорт — управление стрессом и энергия. 🟢Хобби — развитие креативности вне IT. 🟢Общение — социальная поддержка. Результат: устойчивость. Проблемы на работе перестают быть катастрофой, потому что у вас есть другие источники удовлетворения. Баланс — не роскошь, а критически важная часть продуктивности.

Делай как я 🤫 «Делай, как я говорю» — это уровень новичка. «Делай, как я» — уровень мастера. И вот почему. Представьте ситуацию: 🟠Тимлид орёт про «качественную подготовку к встречам», а сам приходит с мыслью «разберёмся на ходу». 🟠Требует идеальных декомпозиций, но когда просят показать пример — сливается с фразой «у меня дедлайн, разбирайтесь сами». 🟠Вещает про ответственность, но как только что‑то идёт не так — сразу ищет, на кого перекинуть. Знакомо? Команда всё видит. И копирует. Это не магия, а базовый принцип работы любой системы: выходные данные зависят от входных. В нашем случае входные данные — это поведение лидера. Что происходит, когда тимлид показывает пример: 🟢Берёт сложную задачу и разбирает её вслух: «Вот тут я выбрал этот подход, потому что… А вот тут мог ошибиться, но вот как это проверить». → Команда начинает так же проговаривать логику. 🟢Готовится к встрече как к собеседованию в FAANG: чёткие цели, agenda, материалы заранее. → Встречи перестают быть пустой тратой времени. 🟢Признаёт ошибку и говорит: «Да, тут я накосячил, вот план исправления». → В команде появляется атмосфера доверия, а не охоты на ведьм. 🟢Показывает декомпозицию на живом примере: рисует схему, объясняет приоритеты. → Задачи перестают превращаться в «чёрные ящики». Как это провернуть на практике (лайфхаки для тимлидов): 🟢Вместо «сделайте нормально» — сделай сам и покажи. Разбери одну задачу на доске/в Miro: где тут фича, где баги, какие риски. 🟢Будь первым в зоне дискомфорта. Взял сложную задачу? Расскажи, как подходил к решению. Какие варианты рассматривал? Почему отбросил? 🟢Проговаривай мысли вслух. Не просто пиши код, а комментируй: «Я выбираю этот алгоритм, потому что он быстрее на больших данных, хотя и жрёт больше памяти». 🟢Готовься к встречам так, будто на них придёт не команда, а инвестор. Потом удивись, как подтянется уровень у всех остальных. 🟢Ошибки — это фичи для обучения. Не скрывай промахи, а разбирай их публично (но без драмы). Как правило слова мотивируют на пару дней. Пример — меняет привычки навсегда. Да, это дольше и сложнее, чем просто раздавать указания. Да, иногда хочется просто сказать: «Сделайте, как надо, я устал объяснять». Но помните: команда смотрит на вас. И делает… как вы. 😏 А у вас были случаи, когда пример тимлида реально поменял подход команды к работе?

Почему 8 разработчиков не делают работу в 2 раза быстрее, чем 4 В конце XIX века французский инженер Максимилиан Рингельман попросил людей тянуть канат — сначала по одному, потом группами. Логика подсказывала: 8 человек потянут в 8 раз сильнее, чем один. На деле — примерно в 4 раза. Каждый человек в группе прикладывал меньше личных усилий, чем в одиночку. Не потому, что люди ленивые. А потому, что в группе размывается ответственность: если канат не потянулся, непонятно, кто именно недотянул. В разработке это выглядит до боли знакомо. Команда из 3 человек делает фичу за 2 недели. Добавляем ещё 3 — и вместо ускорения в 2 раза получаем ускорение в 1.3, а иногда фича вообще буксует дольше, чем раньше. Причины те же, что и с канатом: 🟠ответственность размыта, «это же не только моя зона» 🟠координация между людьми съедает больше времени, чем экономит параллельная работа 🟠в толпе легче остаться незамеченным, если стараешься меньше Тимлид, который решает проблему производительности словами «давайте добавим людей», часто получает не ускорение, а версию эффекта Рингельмана в чистом виде. Что реально работает против этого: 🟢чёткое владение задачей одним человеком, а не «командой» в целом — у каждого куска работы есть конкретное имя 🟢видимость вклада каждого: не для контроля, а чтобы вклад вообще был виден, включая самому человеку 🟢маленькие автономные группы вместо одной большой — 3-4 человека держат личную ответственность лучше, чем 8 Прежде чем закидывать проект людьми, стоит спросить: у нас правда не хватает рук, или просто непонятно, кто за что отвечает? Сталкивались с ситуацией, когда добавление людей в команду замедляло проект, а не ускоряло?

Давно мы так не хихикали, слушая полезный контент 👀 Всему виной Андрей Аксёнов из Авито! Если вы ещё не знаете, кто это, вот несколько фактов: — Больше 25 лет в IT. — Написал поисковый движок Sphinx — один из самых известных опенсорс-проектов в российском IT. — Застал офис Авито, когда он ещё состоял из двух комнат. Максимально рекомендуем к просмотру новый выпуск AviTalk: мало того, что сохраните для себя кучу интересных и забавных цитат, ещё и узнаете чуть больше про зарю IT в России и цену технической свободы. 📱 Смотреть на YouTube 📱 Смотреть в ВК

Сильные команды спорят, слабые — соглашаются. Звучит круто, по‑лидерски. Но давайте разберёмся, где тут правда, а где — перегиб. Что значит «сильные команды спорят»? Нет, это не когда коллеги орут друг на друга и кидаются клавиатурами. Сильный спор — это когда: 🟢Все готовы высказать мнение, даже если оно идёт вразрез с мнением тимлида. 🟢Аргументы — не «мне так кажется», а «вот метрики, вот опыт, вот кейсы». 🟢Спор идёт про код, архитектуру, бизнес‑цели — но не про то, кто вчера опоздал на митинг. 🟢В конце все понимают: мы не «побеждали» друг друга, а искали лучшее решение. А что значит «слабые команды соглашаются»? Тут тоже не про уровень скиллов. Слабость — это когда: 🟠Все кивают, потому что боятся сказать слово против тимлида‑тирана. 🟠Младший разработчик хочет возразить, но вспоминает прошлый опыт: «А, ну да, тогда меня за это отчитали…» 🟠В команде царит атмосфера «да, босс» — лишь бы не нарываться. 🟠Или ещё вариант: всем просто всё равно. Выгорание, апатия, «лишь бы досидеть до 18:00» Спор ради спора — это тоже плохо Представьте: команда 3 часа спорит, какой цвет кнопки лучше — синий или зелёный. В итоге все устали, никто не решил, а фича так и не сделана. Это не сила — это цирк. 🎪 Спор должен быть: 🟢Конструктивным. 🟢С фокусом на результат. 🟢Ограниченным по времени (да‑да, ставьте таймер!). 🟢Без перехода на личности. Так что делать тимлиду? Вот несколько лайфхаков, чтобы споры работали на вас, а не против: 🟢Создай психологическую безопасность. Скажи прямо: «Я могу ошибаться. Если у вас есть идея — давайте обсудим». 🟢Задавай правила игры. Например: «Каждый говорит 2 плюса и 2 минуса подхода. Через 15 минут голосуем». 🟢Гаси токсичность на корню. Если спор превращается в перепалку — жёстко, но спокойно вмешивайся: «Стоп. Мы обсуждаем код, а не друг друга». 🟢Разделяй принципиальные и непринципиальные вопросы. Спорить о выборе базы данных — надо. Спорить о названии переменной — нет. 🟢Подводи итог. После дискуссии скажи: «Мы выслушали аргументы. Идём по варианту А, потому что…». Даже если кто‑то не согласен.

Тимлид: какие метрики реально смотрит бизнес? Одна из главных ловушек для начинающего тимлида — верить, что его главная цель — это «чтобы код летал», а спринты были идеальными. Часто тимлиды отчитываются сторипоинтами и покрытием тестов. Бизнесу это… не очень интересно. Ему важно другое. 1. Time‑to‑Market (TTM) или Lead Time for Changes Скорость от идеи до продакшена. Бизнес существует в конкурентной среде. Если ваш конкурент выкатывает функцию за две недели, а вы за два месяца, бизнес теряет долю рынка. Для владельца продукта скорость доставки — это вопрос выживания. Задача тимлида: Не гнаться за скоростью написания кода, а сокращать «мертвые зоны»: ожидание ревью, долгие согласования, сложный CI/CD, ручное тестирование. 2. Cycle Time и Predictability (Предсказуемость) Бизнес готов простить меньшую скорость, но не хаос. «Сделаем ровно через 3 недели» ценнее, чем «может завтра, может через месяц». Стабильность поставок снижает риски. Задача тимлида: Стабилизировать процесс. Убрать «слона» (огромные задачи, которые невозможно оценить). Сделать так, чтобы менеджер продукта мог с уверенностью 95% называть даты релизов. 3. Ценность, а не активность Закрыли 50 задач — здорово. А что это дало бизнесу? Рост продаж, удержание, снижение затрат? Любая техническая задача должна быть привязана к бизнес‑цели (OKR). Если не привязана — возможно, она не нужна прямо сейчас. Задача тимлида: Научить команду задавать вопрос «Зачем?». Любая техническая задача должна быть привязана к бизнес-цели. Если задача не влияет на OKR, возможно, она не нужна прямо сейчас. 4. Employee Net Promoter Score (eNPS) или текучесть кадров Команда — главный инструмент. Потеря ключевых разработчиков бьёт по деньгам и срокам. Высокая текучесть — это красный флаг для бизнеса. Счастливая команда = стабильный продукт. Задача тимлида: Следить за микроклиматом жестче, чем за процентом покрытия кода. Текучесть ниже 10–15% (для IT) — это зона здоровья. Если она выше — это «красная лампочка» для бизнеса, которую тимлид обязан зажечь первым. Что в итоге? 😎 Техническое совершенство ради совершенства бизнесу не нужно. Ему нужны деньги, время и предсказуемость. Хороший тимлид переводит технические активности на язык бизнес‑результатов — и становится стратегическим партнёром, а не просто «руководителем программистов».

Поздравляю вас с наступлением нового года — и пусть он будет для всех нас таким же стабильным, как хорошо оттестированный код, и таким же динамичным, как идеальный алгоритм! Как настоящий тимлид, желаю вам: 🟢чтобы задачи приходили чётко сформулированными — без «надо что‑то сделать, сами разберётесь»; 🟢чтобы дедлайны были реалистичными — а не «вчера»; 🟢чтобы ревью кода приносило радость, а не желание всё переписать с нуля; 🟢чтобы баги находили себя сами — и исчезали без следа. А ещё — чтобы: 🟢ваш стек технологий всегда был актуальным, но не заставлял вас каждую неделю учить новый язык; 🟢митинги были короткими и по делу — без «давайте просто пообщаемся»; 🟢коммиты проходили без конфликтов, а мерджи — без сюрпризов; 🟢кофе в кружке никогда не заканчивался, а интернет не падал в самый ответственный момент. Пусть в этом году: 🟢ваши идеи превращаются в крутые фичи; 🟢ошибки становятся ценным опытом; 🟢проекты приносят удовлетворение и рост; 🟢а жизнь остаётся сбалансированной — с достаточным количеством отдыха и радости. И помните: если что‑то не работает — попробуйте перезагрузить не только компьютер, но и себя. А если и это не помогло — зовите тимлида!

Зарядились пятничным роцком🤘🎸

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

Рабочая суббота — это как hotfix для недели: вроде бы не планировалось, но надо срочно всё починить

Готов ли ты стать тимлидом? Составил список вопросов, которые помогут тебе понять, готов ли ты стать тимлидом и что для этого нужно. 1. Про лидерство и управление командой 🟢Почему я хочу стать тимлидом? 🟢Какой у меня стиль управления? (Авторитарный, демократический, либеральный?) 🟢Готов ли я брать ответственность не только за свой код, но и за работу команды? 🟢Как я буду мотивировать команду? 🟢Как я буду справляться с конфликтами в команде? 2. Про технические навыки 🟢Хорошо ли я разбираюсь в технологиях, с которыми работает команда? 🟢Готов ли я тратить меньше времени на программирование и больше на архитектуру, ревью кода, менеджмент? 🟢Как я буду развивать технические навыки команды? 3. Про менеджмент и процессы 🟢Какие методологии управления проектами я знаю (Agile, Scrum, Kanban)? 🟢Как я буду планировать работу команды? 🟢Как я буду расставлять приоритеты между задачами? 🟢Как я буду оценивать сроки выполнения задач? 🟢Как я буду проводить ретроспективы и улучшать процессы? 4. Про коммуникацию 🟢Умею ли я ясно и понятно объяснять задачи? 🟢Как я буду общаться с заказчиками, менеджерами продукта, другими командами? 🟢Как я буду давать и принимать обратную связь? 🟢Готов ли я быть "щитом" между командой и внешними давлениями? 5. Про развитие команды 🟢Как я буду помогать команде расти профессионально? 🟢Как я буду распределять задачи в зависимости от навыков сотрудников? 🟢Как я буду оценивать работу членов команды? 🟢Как я буду нанимать новых людей в команду? 6. Про стресс и баланс 🟢Как я буду справляться со стрессом? 🟢Как я буду сохранять баланс между технической и управленческой работой? 🟢Готов ли я к тому, что теперь моя работа — это не только код? 7. Про карьерные ожидания 🟢Вижу ли я себя в менеджменте в долгосрочной перспективе? 🟢Хочу ли я дальше расти до CTO, VP of Engineering или останусь на уровне тимлида? 🚀 Если ты ответил себе на большинство вопросов и уверен в своих силах — значит, ты на правильном пути! 💡 Если есть сомнения — подумай, какие навыки нужно прокачать.

Зависимости в программном обеспечении (Coupling) Ни одна программа в мире не существует в вакууме. Все её компоненты зависят друг от друга. Задача архитектора — не избавиться от зависимостей полностью (это невозможно), а управлять ими. Сегодня разберем, какие бывают типы связности (coupling) и почему это важно для создания гибких и надежных систем. Связность — это степень зависимости между компонентами. Любой компонент А зависит от компонента Б, если ему нужен Б для компиляции, работы, установки или тестирования. Связность бывает на разных уровнях: не только в коде, но и в инфраструктуре. Типы связности — это инструмент для принятия правильных решений. Знание конкретных типов помогает архитекторам предвидеть последствия изменений и выбирать оптимальные способы взаимодействия между модулями. Давайте разбираем типы связности 🟢Связность через использование/delegation Класс А напрямую использует публичные переменные или методы класса Б. Поможет инкапсуляция. Делайте переменные приватными и обращайтесь к ним через геттеры. 🟢Связность через композицию Жесткая связь, когда класс Б является неотъемлемой частью класса А и не может существовать без него (как двигатель в автомобиле). 🟢Связность через создание Класс зависит от фабрики или другого класса, который его создает (паттерны Factory, Abstract Factory). 🟢Связность через наследование Самая жесткая связь в ООП. Дочерний класс тесно связан с родительским, наследуя всё его поведение. Изменения в родителе немедленно влияют на всех потомков. 🟢Связность через сообщения или события Компоненты обмениваются асинхронными сообщениями или событиями через промежуточное ПО (message queue, event store). Отправителю не нужно знать, кто и когда получит сообщение. Это максимально ослабляет связь и повышает отказоустойчивость системы. 🟢Временная связность Компонент А не может выполнить свою работу, пока компонент Б не завершит свою и не отдаст результат (например, нельзя оплатить заказ, пока не добавлены товары в корзину). 🟢Связность через типы данных Многие классы зависят от одного центрального типа данных (например, UserEntity). Любое изменение в этом типе заставляет меняться всех, кто его использует. 🟢Связность через данные Компоненты взаимодействуют через общие ресурсы: базу данных, файлы конфигурации, переменные окружения. Изменение формата данных одним компонентом ломает другой. 🟢Связность через оборудование Низкоуровневая связь, когда компоненты взаимодействуют через общую память или аппаратные ресурсы. 💡Связность неизбежна, но ею можно управлять. Стремитесь к слабой связности. Такие подходы, как обмен событиями и сообщениями, делают систему более гибкой и легкой для поддержки. Сильная связность (наследование, композиция) — не всегда зло, но требует осторожности, так как делает изменения дорогими и рискованными.