Где брать цифры для резюме?

Работодатели любят метрики.

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

— Сколько человек в команде владеют критичными частями системы?
— Какой % задач команда закрывает без твоего участия?

Вопросы логичные. Но возникает другая проблема — где брать эти цифры?

Несколько лет я вела метрики команды в Excel. В какой-то момент стало интересно сравнить себя с другими тимлидами. Но чужих данных нигде нет.

На длинных выходных я собрала небольшого бота с помощью Claude Code.

15 вопросов, около 5 минут — и в итоге получаешь:
— персонажа по каждому блоку
— примерную позицию среди тимлидов с командой такого же размера.

Персонажи шуточные, инсайты — иногда не очень 😄

У меня, например, в блоке «Здоровье команды» получился Реаниматолог. Совпало примерно на 70%.

Теперь интересно посмотреть статистику.

Какой вы тимлид?

Пройдите тест и делитесь в комментариях, что получилось.
Можно скрином или просто названием персонажа 🙌

НФТ. Их не видно, пока система не падает.

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

Один из моих ранних кейсов был как раз про это. Мы не заложили нагрузочное тестирование до старта MVP. Архитектор поднимал вопрос, но в бэклоге были фичи и жёсткий дедлайн. Перед релизом система не прошла нагрузочный тест. В итоге — два спринта рефакторинга и перенос релиза.

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

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

Интересно, как это устроено у вас. Кто в команде держит список нефункциональных требований — архитектор, тимлид или это появляется по мере необходимости?

Продолжаем тему нефункциональных требований

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

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

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

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

Почему НФТ не выживают в отдельном эпике в бэклоге и чему меня научили 2 спринта рефакторинга перед релизом.

После фейла с нагрузочным тестом перед релизом и двух спринтов на рефакторинг я перестала выносить НФТ отдельным эпиком.

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

На такие задачи я закладываю 10–25% времени плюсом к базовой оценке в зависимости от сложности и требований.

Единственное условие: команда понимает что и зачем заложено. Иначе это просто раздутые оценки.

Как закладываете НФТ вы — явно или негласно?

Аналитики и дизайнеры в спринте: в общем потоке или отдельно?

Мы делали и так, и так. Дизайн и аналитика шли в один спринт с разработкой — задачи начинали реализовывать синхронно.

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

Позже аналитики и дизайнеры ушли на 1–2 спринта вперёд, но формально всё велось в одном бэклоге. На демо показывали реализованные фичи и макеты проработанных на будущее фич. Но это вызывало много вопросов и негатива на демо - бизнес хочет видеть что уже работает, а не концепцию.

Это частая история и пока демо проводят "для своих", все понимают правила без слов, но при росте продукта и количестве стейкхолдеров, присутствующих на демо, процесс рассыпается.

А как устроено у вас?

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

И это выделенный спринт на опережение. Пока команда закрывает техдолг — аналитики и дизайнеры уходят вперёд на 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 — это про качество кода.

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

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

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