Аналитика в спринте: схема, которая работает

И это выделенный спринт на опережение. Пока команда закрывает техдолг — аналитики и дизайнеры уходят вперёд на 1–2 спринта.

Техдолг перестаёт быть простоем и становится окном. Раз в квартал такая синхронизация просто необходима каждой команде.

Плюс мне удобно вести задачи аналитиков и дизов на отдельной доске, изолированной от основного спринта. Никакой путаницы на демо и это "на новый од ещё не готово, это аналитика".

Формально можно держать всё в одном бэклоге, но отдельная доска для аналитики и дизайна — это не про инструмент, это про прозрачность процесса — и бизнесу и команде сразу очевидно, что реально в работе, а что в процессе подготовки.

Как у вас — аналитика живёт на общей доске или отдельно?

Каждый второй спринт — срыв scope

Это были мои первые полгода в управлении командой.

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

Мне казалось: вот задачи, вот люди, вот дедлайн. Что тут может пойти не так?

Оказалось, всё.

Бизнес уточнит или расширил требования, а команда переоценила свои силы и вот scope и сроки плыли. Но и то, и другое — это навык, который нарабатывается со временем.

Сейчас процент сорванных спринтов меньше 20%. Не ноль, и никогда не будет ноль. Но разница между 50% и 20% — это уже управляемый процесс, а не тушение пожаров.

Что изменилось:

Первое: декомпозиция до старта. Мы перестали брать в спринт задачи формата «сделать фичу Х». Каждая задача дробится до уровня, где можно оценить и проверить по отдельности. Это больно и долго на планировании, зато спринт перестаёт быть чёрным ящиком.

Второе: буфер. 15–20% ёмкости спринта — на незапланированное. Не на конкретные задачи, а просто на то, что обязательно прилетит. Потому что оно ВСЕГДА прилетает.

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

Четвёртое: команда стала точнее декомпозировать и оценивать задачи т.к. мы стали разбирать ретроспективы честно. Ошибся в оценке на два дня? Давай поймём почему, без обвинений. Через 3–4 спринта точность выросла как будто сама.

А 20%, которые остаются? Бизнес меняет приоритеты потому что рынок не ждёт и постоянно прилетают уточнения, которых не было на этапе аналитики. Или другие команды задерживают API, от которого зависит твоя задача. Идеальных условий не бывает.

Предсказуемость спринта — одна из метрик, по которой можно понять, как на самом деле работает поставка. Не velocity, которую легко подкрутить размером задач, а именно процент спринтов без срыва scope. Ни Jira, ни Яндекс Трекер эту метрику автоматически не считают — burndown покажет scope change внутри спринта, но накопленную статистику по спринтам придётся вести руками.

А у вас какой процент срывов? И что помогло его снизить?

Штатная команда: когда все свои

Первый пост (и очень длинный) из серии про типы команд. Начну с классики — все в одной компании/группе компаний, один работодатель.

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

Но у любой модели есть цена. Хотя если команда распределённая — часовые пояса и доступы догонят и тут.

Сначала плюсы)

Всё внутри. Кодовая база, документация, архитектурные решения, экспертиза по продукту принадлежат компании. Единые стандарты качества, CI/CD и инфраструктура под контролем. Решения принимаются быстрее — не нужно согласовывать изменения с внешним подрядчиком. И команда живёт с последствиями своих решений поэтому техдолг не копится бесконтрольно.

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

Единая среда. Корпоративные мероприятия, общие стандарты разработки, одинаковые праздники и выходные. Снижает трение в ежедневной работе т.к. одни правила для всех.

Долгий и глубокий контекст. Нет резкого переключения между проектами — человек живёт в продукте месяцами. Но дело не только в коде. Корпоративная среда даёт понимание, для кого ты строишь. Я однажды ездила на площадку добычи нефти помогать проводить конкурс профмастерства. После того как познакомилась с мастерами, которые каждый день работают с планшетами — фраза «проектируем интерфейс под крупные руки операторов» перестала быть абстракцией. Всегда есть контекст, который сложно передать в ТЗ. (фото с той самой поездки. 2018г.)

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

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

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

Но у инхауса есть своя цена.

Зависимость. Если ключевой человек уходит — уходит и контекст. Чем глубже погружение, тем больнее потеря.

Стоимость. Штатная команда — это не только зарплаты, это налоги, ДМС, оборудование, обучение. Для бизнеса это долгая инвестиция, и не каждый проект её оправдывает.

Скорость масштабирования. Нужно ещё два разработчика на следующий месяц? Это найм, онбординг и 2–4 месяца до продуктивности. В других моделях может быть быстрее (при определенных обстоятельствах).

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

Штат — это фундамент. Но фундамент работает, когда на нём строят осознанно, а не "как пойдет".

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

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

Аутстафф: одна команда, два работодателя

Второй пост из серии про типы команд.

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

Это самая распространённая модель в крупных компаниях. И самая коварная потому что выглядит как единая команда, а управляется как две.

Зачем вообще миксуют. Бизнесу нужна скорость — штатный найм не успевает. Или бюджет выделен на проект, а не на расширение штата. Или нужна экспертиза, которой внутри нет. Причины разные, результат один — в твоём спринте сидят люди с разными работодателями.

Что работает

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

Гибкость. Нужно усилить команду на три месяца под релиз — подрядчики. Без расширения штата и долгосрочных обязательств.

Свежий взгляд. Люди из других проектов приносят практики, о которых инхаус-команда могла не знать.

Где обычно болит.

Два контекста. Штатные знают продукт глубоко, подрядчики — поверхностно. Со временем разрыв растёт, если с ним не работать.

Разная мотивация. Штатный думает о продукте на горизонте года. Подрядчик — о текущем контракте. Это влияет на решения в коде. Техдолг оставляет тот, кто не будет с ним жить.

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

Операционка множится. Таблица отпусков, отгулов, контактов на случай экстренной связи, рискует переехать во внешний контур, потому что вести две неудобно, хотя команда как будто одна. Важно с самого начала организовать единый инфраструктурный слой — хранилище кода, CI/CD, трекер, вики. Это можно разместить как на мощностях заказчика, так и на стороне подрядчика. Обычно выбирают где проще и дешевле.

Code review. Стандарты кода у штатных и подрядчиков часто разные. Без жёстких гайдлайнов и линтеров — ревью превращается в бесконечный пинг-понг.

Как с этим жить

Тех-лиды в штат при наличии бюджета. Это люди, которые держат архитектуру и стандарты. Эти же люди потом садятся на третью линию поддержки. Так формируется сильное ядро внутри — что всегда в плюс. Но это не значит, что подрядчики пилят только простые задачи! Распределение должно быть по компетенциям, а не по типу договора.

Единые стандарты кода — не рекомендация, а требование.

Онбординг для подрядчиков — такой же, как для штатных.

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

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

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

Следующий пост про аутсорс — когда проект передают в разработку целиком.

А у вас как — штатные и подрядчики сработались или живут параллельно?

Тимлид, Engineering manager, Delivery Manager — три роли, ноль подходящих вакансий

Месяц поиска работы. Ни одна вакансия не совпадает с тем, что я делала последние годы.

В Газпромнефть-ЦР у меня было всё сразу: код, развитие людей, планирование релизов, коммуникации с заказчиками. Внутри компании это работало — все знали, кто я и что делаю. Снаружи — ступор. Опыт есть, а вакансии под него как будто нет.

Потребовался месяц разбора вакансий и десятки отказов, прежде чем я поняла: моя основная роль — Delivery Manager. Не чистый тимлид, не чистый EM. Человек, который держит процесс, сроки и мост между командой и бизнесом.

Три роли — если коротко:

Тимлид — технический лидер. Код, архитектура, ревью, рост инженеров.
EM — про людей. Менторство, культура, конфликты, развитие.
DM — про систему. Планирование, риски, коммуникации, delivery.

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

Самое полезное, что я сделала — перестала искать вакансию, которая совпадает на 100%. Вместо этого разобралась, какая роль в моём опыте основная, а какие — дополняющие. Сразу стало понятно, куда откликаться и как описывать себя.

Если вы тимлид и чувствуете, что переросли чистую техническую роль — возможно, вы уже делаете работу DM или EM. Просто ещё не назвали это правильным словом.

Кто проходил через такой же ступор при поиске — как разобрались?

#лебедева_ит #лебедева_команды

Аутсорс: скорость на входе, сюрприз на выходе

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

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

Что работает.

Скорость старта. Команда уже собрана. Если дедлайн горит, а нанимать некогда — аргумент реальный.

Доступ к экспертизе, которую нет смысла растить внутри. Разовая задача на незнакомом стеке — логичнее отдать, чем учиться.

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

Где обычно болит.

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

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

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

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

Нет продуктового контекста. Внешняя команда проектирует по ТЗ, а не под реального пользователя. Разница видна сразу — в интерфейсных решениях и в приоритетах при конфликте требований.

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

Без прозрачного процесса аутсорс — это чёрный ящик с дедлайном. Что внутри узнаешь только когда откроешь.

Был опыт приёмки аутсорс-проекта? Что обнаружилось первым?

#лебедева_ит #лебедева_процессы

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

Иногда хочется просто «жжжжж» и цветочки, а не вот это все на работе 😅

9 Мая для меня — не просто дата из учебника.

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

С Днём Победы. И вечная память тем, кто не вернулся домой. ❤️🙏

Мы онбордим за пару-тройку недель.

Слышу это регулярно и каждый раз 🤦‍♀️🤦‍♀️🤦‍♀️ Да вы в лучшем случае успели выдать ноутбук и доступы, и то не всегда даже это успели. А до состояния "человек самостоятельно берёт задачу и не блокирует команду" — там совсем другие цифры.

Бенчмарки APQC по всем профессиям: медиана выхода на базовую продуктивность — 35 дней. У худших компаний — 50+. И это про базовую, а не про полную.

Для разработчиков сроки длиннее. Так GitLab в открытом гайде по онбордингу даёт три фазы: обучение и адаптация — 3-6 месяцев, создание ценности — 6-12 месяцев, полная экспертиза в роли — до 18 месяцев. И это нормальная картина для крупных engineering-команд.

У Lally с коллегами *(European Journal of Social Psychology, 2010)* есть классическое исследование привычек. Медиана достижения автоматизма любого нового действия — 66 дней. Разброс от 18 до 254 дней в зависимости от человека и сложности действия. И это не лень или отсутствие мотивации, а устройство нашего мозга.

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

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

И вот этот настоящий онбординг идёт месяцами. У меня в практике senior'ы выходили на полную мощность к четвёртому-пятому месяцу, потому что в систему нужно врасти.


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

Признать долгий онбординг — это уважение к реальности.

---

Это первый пост в серии *"Мои любимые мифы про разработку"*. Дальше разберу ещё четыре:

— Документация необязательна, нормальная команда и так разберётся.
— Больше людей в проекте — быстрее результат.
— Senior-разработчик готов стать team lead.
— Code review — это про качество кода.

Каждый из этих мифов дорого обходится команде.

Сколько по факту занимает онбординг до состояния "самостоятельно тянет задачу средней сложности" в ваших командах? Совпадает с цифрами из исследований или нет?

#лебедева_ит #лебедева_команды #лебедева_найм

Документация не нужна, пока не уволится Катя

В каждой команде есть своя Катя. И пока она на месте — кажется, что документация это блажь.

При этом Катя единственная знает, почему пару лет назад платёжный модуль написали именно так, почему интеграция с этим контрагентом идёт через костыль, а какие функции в legacy нельзя трогать вообще никогда. Команда привыкла: что-то непонятно — спрашиваем у неё, отвечает за пять минут. Удобно.

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

А когда приходит заявление на увольнение, начинается настоящая паника. Срочные встречи, попытки записать всё что человек знает, договорённости о платных консультациях после ухода.

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

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

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

У DORA в исследовании 2023 года есть цифра: команды с качественной документацией показывают на 25% выше team performance, чем команды с плохой документацией.

---

Главный аргумент против документации — "нет времени писать".

Немного цифр:
— команда из 10 человек по медиане рынка на май 2026 стоит компании 2,2 млн ₽ в месяц на руки
— без качественной документации она выдаёт на 25% меньше результата, чем могла бы
— в деньгах это около 440 тыс. ₽ недополученной ценности каждый месяц.

Двое из десяти человек в команде фактически работают вхолостую и оплачивают отсутствие документации.

---

А у вас как: пишете доку системно или живёте на тех, кто всё помнит?

#лебедева_ит #лебедева_процессы #лебедева_команды

🧩 ИИ vs джун. Почему я больше не верю в «ИИ заменит джунов»

Читаю последние месяцы одно и то же — «зачем нанимать джунов, если есть ИИ», «джуны больше не нужны», «ИИ закрывает 80% задач начального уровня».

Дала ИИ обычную джуновскую задачу — на внимательность, без архитектурных решений. Живой джун у меня такое делает часа за два. Я с ИИ — за час (за счёт контекста и опыта). Можно сказать «вот и преимущество».

А теперь — в деньги. В расходы компании, не просто в зарплату на руки.

📊 Цифры (источник — Хабр Карьера, 1 пол. 2026):
— Джун: 98 000 ₽ на руки → расход компании ~147 000 ₽ в месяц → час работы ~920 ₽
— Лид: 440 000 ₽ на руки → расход компании ~660 000 ₽ в месяц → час работы ~4 100 ₽
— Токены (Qwen Code): реалистичная сессия ~200 ₽

Считаем задачу:
— Джун закрывает баг за 2 часа → 1 800 ₽ расходов компании
— Лид закрывает с ИИ за 1 час → 4 100 ₽ (время лида) + 200 ₽ (токены) = 4 300 ₽

В два с лишним раза дороже прямо сейчас.

— — —

❗ А теперь главное: простые баги — это учебный материал, на котором растёт джун.

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

ИИ съест эти задачи и не вырастет. Закроет ровно ту, на которую был промпт, и не запомнит контекст. Завтра дадите такую же — он точно так же будет тыкаться вслепую.

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

«ИИ вместо джуна» — это посадить логиста на электросамокат и отправить развозить заказы. Быстро. Дорого. И никто не растёт.

Я сама использую ИИ каждый день — и для кода, и для текстов, и для рутины. Вопрос не «использовать или нет». Вопрос — где использовать. И простые баги для джуна — это тот контекст, где ИИ забирает у команды будущее, а не помогает в настоящем.

— — —

❓ А у вас как? Считали реальную стоимость задачи, закрытой через ИИ? Или ощущение «вроде дешевле» без цифр?

🔗 Зарплаты IT в 1 пол. 2026 — Хабр Карьера: https://career.habr.com/salaries

#лебедева_ит #лебедева_ии #лебедева_команды

📉 15 проваленных спринтов за 1,5 года. Во столько я обошлась работодателю, пока росла из джуна

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

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

По исследованию Хабр Карьеры, джуны в России обычно сидят в этой роли 2–3 года. Я выросла за полтора. И всё равно стоила компании этих пятнадцати спринтов.

И это только то, что видно в трекере. За кадром:

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

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

— — —

Так растут все. Просто вслух мы любим рассказывать «я быстро въехал(а)» и «сразу начал(а) закрывать задачи».

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

💰 Медиана мидла по Хабру — 250 000 ₽ на руки. С налогами и страховыми компания тратит около 375 000 ₽, час работы — 2 350 ₽. В два с половиной раза дороже часа джуна.

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

— — —

❓ Во сколько ваше обучение обошлось работодателю?

🔗 Зарплаты разработчиков в России — анализ по грейдам и стажу, Хабр: https://habr.com/ru/articles/981704/

#лебедева_ит #лебедева_ии #лебедева_команды

🧩 3 строчки вместо 30. Чему меня реально научил ИИ

Два поста я считала, во что ИИ обходится компании. Сегодня — за что я ему благодарна. И это не код.

Когда я ставлю задачу живому джуну — он додумает. Переспросит. Поймёт из контекста. Увидит моё лицо и считает, что «ну ты понял» означает «сделай как в прошлый раз».

ИИ работает ровно с тем, что я написала. Размыто написала — размыто получила. Накидала воды — получила воду обратно, только красиво оформленную.

Полезная школа:

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

Это переползло куда угодно: в тикеты, в ТЗ подрядчикам, в письма коллегам. Там, где раньше писала полотно из тридцати строк — теперь укладываюсь в три. Понятнее стало раза в три.

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

— — —

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

Но мне больше всего интересен сам канал коммуникации: с человеком мы передаём контекст голосом, мимикой, паузами. С ИИ — только текстом. Об этом напишу отдельно.

— — —

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

#лебедева_ит #лебедева_ии #лебедева_команды

Как тимлиду пережить лето и не загнать команду (и себя)

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

Делюсь своим чеклистом для подготовки к этому прекрасному сезону:

Планирую спринт под тех, кто реально на месте.

❌ Набитый под завязку спринт летом — это гарантированный недовоз и потом неловкие объяснения.
✅ Режу скоуп под фактический размер команды - это и цифры честнее цифры и команда спокойнее.

Лето — хорошее время для среднего техдолга.

❌ Большие фичи начинать рискованно: контекст сильно теряется между людьми в отпусках.
✅ Реализовывать задачи, которые закрываются одним человеком за спринт, в самый раз.

Перед отпусками смотрю, где бас-фактор равен единице.

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

Новый проект летом — предупреждаю бизнес о просадке заранее.

‼️Любой новый продукт — это онбординг: первые недели команда входит в незнакомый контекст. Летом, на фоне отпусков, заметнее вдвойне. Сказать об этом стейкхолдерам до старта, а не оправдываться постфактум — часть работы тимлида.

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

А вы режете план на лето заранее или работаете как обычно и смотрите по факту?

Прошла модерацию на Хабре с первого раза 🎉

Готовилась сидеть в песочнице, а статью взяли сразу в общую ленту.

В статье разбираю сколько человек реально нужно для веб-продукта в 2026 и что из этого правда закрывает AI.

Приглашаю к прочтению, комментарии приветствуются 🙂

https://habr.com/ru/articles/1041100/