Тема эффективности в IT не теряет актуальности, и обсуждения последнее время становятся только горячее. Несмотря на зрелость индустрии в целом, кажется, до сих пор нет единого и стандартизированного понимания о том, что считать по-настоящему эффективной работой. Для многих компаний разработка по-прежнему остается «черным ящиком», в который вливаются большие деньги при не всегда прозрачном и предсказуемом результате.
Мы с вами находимся в таймлайне, который вообще не дает расслабиться. Во-первых, у нас тут сильное экономическое давление: бизнес последние годы смотрит на расходы всё пристальнее. Во-вторых, не сбавляет оборотов ИИ-трансформация, которая захлестывает индустрию. Поэтому мы с техдиректорами из разных сфер ИТ-бизнеса решили погрузиться в вопрос и понять, какие подходы помогают приблизиться к адекватной оценке эффективности разработки так, чтобы при этом не навредить команде и разработчикам.
Мысли, описанные в статье, мы обсудили на круглом столе, посвященном эффективности разработки. Посмотреть запись можно в VK или на YouTube.
Участники обсуждения:
-
Юрий Аксенов, CTO Eatr & Yogi, ex-CTO Emex
-
Андрей Смирнов, CTO поддержки бизнеса в MAGNIT TECH,
-
Алексей Рахманов, Руководитель департамента разработки и тестирования FUN&SUN (СТО)
-
Антон Воротынцев, Руководитель .NET-направления разработки «Астрал-Софт»
Какую команду мы вообще можем назвать эффективной?
Эффективная команда — это команда какая? Быстрая? Или опытная? Или та, которая любит овертаймить? Если отвечать на этот вопрос однозначно, тогда первое, что приходит на ум — это все же измерять эффективность скоростью. Но в рабочих условиях, увы, скорость без предсказуемости не имеет смысла. Эффективность команды разработки не должна быть разовым прыжком воли: команды должны быть способны стабильно доставлять бизнес-результат от идеи до реализации в понятные (и не всегда, кстати, короткие) сроки.
«Эффективность — это предсказуемость доставки бизнес-результата от идеи. Чтобы мы учитывали стоимость, качество, скорость и, самое главное, устойчивость. Чтобы не было героизма, а было плавное, постепенное доставление»
— Юрий Аксенов, технический директор Eatr & Yogi
Реальная эффективность не должна выражаться в выгорании и раз за разом повторяющихся в конце спринта переработках. Вместо этого стоит тренировать системность и повторяемость: команда должна работать одинаково качественно и предсказуемо как сегодня, так и через год. Работа должна строиться так, чтобы каждый следующий шаг был максимально понятен в заданных условиях; удавалось находить компромиссы между скоростью, качеством и стоимостью; было понимание, что даже самый качественный код бесполезен, если он не решает задачу рынка.
Кажется, такое распределение сил звучит довольно логично. Но, конечно, есть нюанс.
«Мы живем в конкурентной среде. Если ты разрабатываешь продукт, ты конкурируешь с другими, которые могут выкатить фичу раньше тебя — они начнут захватывать рынок, а ты останешься не у дел. Поэтому качество, несомненно, важно, но скорость тут тоже решает».
— Антон Воротынцев, руководитель .NET направления в «Астрал-Софт»
Разрабатывая цифровые продукты для бизнеса, нельзя игнорировать приоритеты. Если для одних важна стабильность, то для других в условиях жесткой конкуренции ключевой будет скорость захвата рынка.
Подводя итог здесь, можно сказать, что эффективность команды — не статичный показатель, а скорее динамическое равновесие. Можно преуспеть в том, чтобы уйти в «качественно и стабильно», но если это не дает ту ценность, которую ждет бизнес в конкретные сроки, называть такую команду эффективной нельзя.
И кстати, в этом проблема большинства традиционных метрик — они меряют процесс, а не результат. Количество закрытых задач, объем выработки, соблюдение формальных сроков — всё это может выглядеть отлично в дашборде и при этом не иметь никакого отношения к реальной ценности для бизнеса.
Важность контекста
Получается, что эффективность — понятие с плавающим центром тяжести. И его смещение зависит от приоритетов бизнеса. А еще нам очень важен контекст. То, что считается успехом, скажем, в крупном ритейле, может оказаться критическим промедлением для технологического стартапа. В продуктовой разработке качество зачастую не может быть высшим само по себе: оно должно быть достаточным, чтобы пользователь не тонул в багах, а компания могла захватывать свою нишу на рынке.
«В стартапе важно уметь быстро «переобуться», поменять полностью курс развития, если вы поняли, что идете немного не туда. Фокус сдвигается в сторону гибкости в отношении всего: рынка, ожиданий и того, как вы сами собраны».
— Андрей Смирнов, CTO функции поддержки бизнеса в MAGNIT TECH
Для зрелого энтерпрайза эффективность перемещается в плоскость SLA, системности и предсказуемости. Тут не нужны разовые прорывы, потому что гораздо ценнее повторяемость результата из квартала в квартал. В корпорациях эффективность измеряется через сложные иерархии метрик, где каждый винтик системы должен работать в заданных параметрах стабильности.
Конечно, стартап против большого энтерпрайза в контексте обсуждения эффективности — все же упрощение. Бывает, что и в крупном продукте-долгожителе нужно включить режим стартапа, если речь идет об определенной функциональности, которую нужно выкатить очень быстро, чтобы протестировать гипотезу, и уже потом встроить ее в устойчивую систему. И тогда эффективность разработки продукта в целом нельзя будет измерять единообразно. Тем не менее, стоит четко эту разницу видеть и осознавать, чтобы подходить к оценке эффективности разных команд и не строить ошибочных ожиданий.
Синхронизация с бизнесом и метрики
Бывает, что разработчики попадают в ловушку, считая себя эффективными на основе технических показателей, пока бизнес видит лишь огромные затраты без прямой связи с прибылью. Потому что у каждого юнита свой инструментарий оценки.
Порой IT-команда воспринимается как сервисная функция, а не как полноценный партнер в принятии решений. Поэтому рассинхрон только растет. Чтобы преодолеть историческое недоверие между отделами, стремимся к прозрачности через понятный бизнесу язык: финансовые показатели, отчеты о сэкономленных средствах или анализ предотвращенных рисков.
«У нас была продуктовая команда, но внутренние цели были разные. Например, у тестировщиков — условное «меньше багов», у бизнеса — метрики конверсии. И они расходились. Это не работало, пока мы не объединили их едиными KPI и не сделали полноценные команды, которые живут одними целями и совместно принимают решения»
— Андрей Смирнов, CTO функции поддержки бизнеса в MAGNIT TECH
Чтобы ускорить наступление синергии, разработчикам полезно выходить за рамки простого выполнения задач и мыслить продуктовыми категориями. Для этого имеет смысл не просто совместно обсуждать планы раз в квартал, а буквально погружать инженеров в реальность конечного пользователя.
По сути это Гэмба 現場. Например, можно сесть рядом с водителем-дальнобойщиком, для которого придуман сервис, чтобы своими глазами увидеть, как он взаимодействует с интерфейсом приложения в реальных условиях. Пример, конечно, нетривиальный — наверняка в вашей практике можно сделать что-то попроще, но не менее эффективное.
Только когда вся команда понимает, ради какой бизнес-ценности работает, а бизнес видит прозрачный путь реализации своих идей, можно говорить о достижении реальной эффективности. Отцы менеджмента типа Питера Друкера говорят нам, что менеджмент должен быть регулярным. Значит, и набор метрик должен быть более-менее постоянным. Но не ограничиваемся здесь только технической скоростью.
Бывают в разрезе личной эффективности кейсы вида «сделал 400 саппорт тикетов и ни одной фичи». И тогда в сравнение с другим разработчиком, который условной ценности доставил больше, этот сотрудник вроде как менее эффективен. Но может сложиться и так, что без закрытия саппорт тикетов, полезная функциональность, выданная другим сотрудником, вовсе не дошла бы до пользователей. Верно и обратное. Поэтому смотреть надо чуть более комплексно.
Например, в MAGNIT TECH есть стандарт метрик DORA вместе с замерами Lead Time и Cycle Time. К этому добавляют оценку зрелости команды, которую проводят раз в квартал по пяти-шести параметрам, включая инженерные практики, состав команды и гигиену работы с таск-трекером.
«Я в целом отношусь к метрикам так, что с ними нужно не переборщить. Но при этом брать те, которые именно вам подходят, и тоже регулярно пересматривать не только значение этих метрик, а то, показывает ли нам что-то конкретная метрика или она просто есть и всегда примерно одинаковая».
— Андрей Смирнов, CTO функции поддержки бизнеса в MAGNIT TECH
Чтобы сделать разработку прозрачнее для бизнеса и наоборот, стоит идти в направлении иерархии метрик. Пример такого подхода использовали в EMEX. Ключевые показатели бизнеса разложили в иерархию и сделали так, чтобы каждое подразделение отвечало за какие-то из составляющих. Разработка не стала исключением: на всех уровнях вплоть до тимлида руководители разработки отвечали за три группы метрик: time to market, надежность систем и финансовые показатели команды. В дальнейшем систему расширили до метрик индивидуальных сотрудников, чтобы даже тестировщик понимал, как он влияет на прибыль через свои задачи. Стали выпускать еженедельные новости: что сделали и на какую сумму. Даже работу инфраструктуры, которую бизнес обычно не видит, начали показывать в сэкономленных деньгах или нереализованных рисках.
«В итоге за 5 месяцев бизнес начал доверять разработке настолько, что разрешил закупать больше серверов и вкладываться в инфраструктуру».
— Юрий Аксенов, технический директор Eatr & Yogi, ex EMEX
Полезной практикой может стать и регулярный замер настроения каждого сотрудника. Если человек в унынии, это сигнал для руководителя: нужно идти в 1-на-1 за решением ментальной проблемы, пока она не парализовала продукт. Так делают в «Астрал-Софте», в дополнение к процессу SAFE, где планирование идет сразу на три месяца, а норма выполнения плана — 80%, потому что в живой разработке невозможно предсказать всё до минуты.
«Термометр — это больше история про общее состояние, настроение каждого человека в команде… Если мы видим красные флажки — кто-то прямо там совсем в депрессии — есть смысл с этим человеком индивидуально поработать, пока эти эффекты не сказались на продукте».
— Антон Воротынцев, руководитель .NET направления в «Астрал-Софт»
При всей любви к цифрам избыточное регулирование ведет и к управленческим катастрофам. Однажды в Fun&Sun случился массовый сбой: на сайте отвалились туры в Турцию и Таиланд, и люди не могли их купить. Команда могла быстро выкатить исправление для одного направления, но возникла патовая ситуация. Из-за требования «ноль багов на проде» и регламента, по которому задача считается закрытой только при полном решении, фикс не выпускали — ждали, пока поправят всё. В итоге процесс победил здравый смысл, а компания потеряла огромные суммы. И в этом смысле любая зрелость и метрики вторичны по сравнению с предсказуемостью и способностью команды принимать решения в критический момент.
«У меня нет четкого ответа на вопрос, как измерить эффективность за исключением оценки поставки ценности, которая была просчитана, продумана и оценена техническими специалистами. А дальше, если поставки не случилось, мы смотрим, где процесс просел, где были узкие места. То есть ретроспективу провели, поняли что не так, как улучшить, пошли дальше. Это цикличный процесс»
— Алексей Рахманов, руководитель департамента разработки и тестирования FUN&SUN
Индикаторы проблем в разработке и бесполезные измерения
Эффективность не падает мгновенно, но ее падение просматривается через косвенные признаки. Первый и самый очевидный сигнал — это резкие и необъяснимые скачки в lead time. Если вчера команда поставляла фичу в среднем за 20 дней, а сегодня этот показатель подскочил до 40, начинаем расследование. Такие флуктуации почти всегда означают, что что-то сломалось: например, возникли скрытые зависимости между продуктами или начались системные сбои в самой разработке.
Другой критический маркер — полная потеря связи между тем, как команда оценивает задачи, и тем, когда она их реально сдает. Если маленькая по оценкам задача делается неделями, а сложная пролетает за день, система планирования вероятно мертва. Без корреляции между прогнозами и реальностью вы просто не можете управлять загрузкой команды и обещать что-то бизнесу.
Интересно, что метрики бывает запаздывают по сравнению с человеческим восприятием. Владельцы продукта обычно первыми чувствуют, когда в команде неполадки. Если продакт приходит с ощущением, что «что-то идет не так», скорее всего, он прав, даже если графики пока еще выглядят пристойно. И этот фидбэк — один из самых ценных «нецифровых» индикаторов эффективности.
Нельзя ставить метрики, которые легко превратить в самоцель и саботировать ради них работу. Один из самых популярных капканов здесь — погоня за 100% выполнением спринта. Казалось бы, если команда закрывает всё, что напланировала, — это супер. Но нет.
«У нас во всех командах [норма выполнения] — это 80%. Был период в самом начале, когда мы сотку сказали… Но там завышали сроки, перестраховывались. Это не работает»
— Алексей Рахманов, руководитель департамента разработки и тестирования FUN&SUN
Другая сомнительная история — метрики счастья пользователей или NPS, спущенные на ИТ-отдел сверху. Проблема в том, что ни разработка, ни зачастую даже продакт не могут на них влиять напрямую. NPS в принципе специфичен: довольный клиент пройдет мимо опросника, а вот тот, у кого плохое настроение или кому не понравился цвет полотенец в отеле, обязательно поставит единицу.
Даже проверенные инструменты вроде Lead Time легко поддаются манипуляциям. Команды начинают хакать метрику, дробя задачи на микроскопические части. Формально Lead Time — один день, а по факту в такой задаче нет никакой бизнес-ценности. Чтобы этого избежать, вводим требование: любое дробление должно сохранять ценность для конечного пользователя.
«Отдельная боль — сторипоинты. Они всегда были сложной конструкцией, а с приходом ИИ и вовсе начали обесцениваться. Когда Claude пишет код за секунды, классическая оценка сложности по сторипоинтам превращается в нечто требующее пересмотра подхода к оценке трудозатрат»
— Юрий Аксенов, технический директор Eatr & Yogi
И еще спорный момент: внедрение личных целей для каждого сотрудника. В Eatr & Yogi был эксперимент, когда даже тестировщикам ставили KPI по количеству написанных автотестов. В итоге люди перестали думать о целях команды и сфокусировались на своих KPI. Пришлось проводить А/Б тесты, сравнивая команды с личными целями и без них, чтобы найти баланс.
Также личные KPI немного убивают взаимопомощь. Потому что когда всё, что ты делаешь, измеримо и направлено на максимизацию каких-то цифр, тогда то, что, соответственно, неизмеримо — и делать не надо. Разработчики перестают рисковать и креативить, стараясь сделать задачу максимально предсказуемо, чтобы попасть в сроки. Ну и выбирать они будут простые и понятные задачи из бэклога вместо действительно важных, но сложных, где степень неопределенности выше.
«Всё зависит от того, как вы транслируете эти показатели команде. Либо это инструмент наблюдения и анализа для поиска бутылочных горлышек, либо кнут, от которого зависит зарплата. Во втором случае готовьтесь к тому, что команда будет играть в цифры»
— Антон Воротынцев, руководитель .NET направления в «Астрал-Софт»
ИИ-трансформация: не навредить
Искусственный интеллект — это фактор, одновременно развивающий и дестабилизирующий ИТ-команды. С одной стороны ИИ в разработке — это экономия времени и помощь инженерам, с другой — причина искажения и устаревания прежних способов оценки эффективности работы. Но рука к возможностям все равно тянется: 59% российских компаний видят в ИИ-агентах главный технологический фокус года, согласно исследованиям Высшей школы бизнеса НИУ ВШЭ.
ИИ теперь и лакмусовая бумажка для оценки кандидатов. Это может работать так: если человек принципиально отказывается от нейросетей, он не проходит отбор. В стартапах, например, разница в производительности между теми, кто умеет в промпты, и остальными видна невооруженным глазом. Но совсем уж укатываться в ИИ-эйфорию без разумной базы не стоит.
«В незрелой команде будет еще больше хаоса с искусственным интеллектом… Важнее как раз все подготовить к тому, чтобы ИИ мог действительно усилить эффективность: нормальные тестовые контуры, задокументированные требования, понятные правила работы».
— Андрей Смирнов, CTO функции поддержки бизнеса в MAGNIT TECH
Однако вайбкодинг, на который многие делают ставку сейчас, все же неприменим в корпоративной разработке, потому что агенты в корпорации обязаны учитывать регуляторные требования, внутренние правила безопасности и архитектурные ограничения. Это подводит нас к мысли, что эффективность в 2026 году — это также и дисциплина использования ИИ-инструментов.
Например, в «Астрал-Софт» на некоторых задачах lead time сократился на 20–40%, но на других внезапно вырос. Все как раз потому, что далеко не все умеют пользоваться инструментом эффективно. Пока одни «забивают микроскопом гвозди», другие перекладывают на ИИ практически весь цикл: от анализа до проектирования, и делают это вполне эффективно.
Ну и тут сложно отрицать, что с ИИ-бустом ценность простого написания кода стремительно падает. Эффективность инженера измеряется тем, насколько глубоко он понимает бизнес-проблему и какую архитектурную ответственность готов на себя взять. Мы переходим в эру продуктовых инженеров, где освободившееся от рутины время тратится на то, чтобы сделать решение по-настоящему полезным для клиента. Процесс адаптации разработчиков к новой реальности часто происходит сам собой.
«Как только код начинает писаться быстрее, высвобождается время. Его человек начинает тратить на изучение предметной области. Фронтендеру становится не всё равно, будет ли удобен его интерфейс менеджеру, который бегает в перчатках по складу со старым планшетом в руках. Люди начинают делать шаг навстречу бизнесу просто потому, что у них появилась на это возможность».
— Андрей Смирнов, CTO функции поддержки бизнеса в MAGNIT TECH
Разработчики всё больше фокусируются на архитектурном мышлении. Чтобы эффективно давать промпты ИИ, нужно видеть систему целиком: как связаны сервисы и как ходят данные. Это все шире написания конкретной функции. Параллельно с этим растет навык качественного код-ревью: инженер теперь не столько пишет сам, сколько выступает в роли цензора для сгенерированного кода.
Формируется и встречный тренд: не только разработчики уходят в продукт, но и менеджеры становятся технически подкованнее. Из-за этого где-то ТЗ становятся более полными, где-то коммуникация между технологиями и бизнесом становится в целом более богатой, кто-то делает себе мини-инструменты для операционных задач. Понемногу это все отражается на общей эффективности в продукте.
«Серебряные пули» для вашей команды
Предлагаем зафиксировать несколько простых, но полезных практик. Они смогут бустануть эффективность в разработке почти любого уровня вне зависимости от предметной области, в которой существует разрабатываемый продукт.
«Через весь проект должна проходить «красная нить» от глобальной стратегии компании до каждого действия разработчика»
— Алексей Рахманов, руководитель департамента разработки и тестирования FUN&SUN
Потому что самый большой демотиватор для инженера — это непонимание смысла своей работы. А если человек понимает, зачем он перекрашивает кнопку из зеленого в красный и как это поможет бизнесу заработать, он работает совершенно иначе. Даже если и вправду перекрашивает кнопку.
«Чтобы у команды было меньше шансов застрять на пути доставки бизнес-ценности, путь должен быть предсказуем и описан»
— Андрей Смирнов, CTO функции поддержки бизнеса в MAGNIT TECH
Нужен прозрачный чеклист, где каждый шаг процесса виден как на ладони. Вы всегда понимаете, какой следующий шаг, где находится узкое место и кто подхватит задачу после вас. Это убирает лишнюю когнитивную нагрузку: разработчику не нужно гадать, какие блокеры он откроет своим релизом.
«Разработчики по своей природе торопыги: они склонны передать задачу в тестирование и тут же хвататься за новую. В итоге, когда приходят баги по старой задаче, контекст уже потерян, и переключение между делами съедает время. Поэтому не берем следующую задачу до тех пор, пока не дотолкали текущую до прода.»
— Антон Воротынцев, руководитель .NET направления в «Астрал-Софт»
Жесткий фокус на завершении задач — полезная практика. Условно, если оперативно приходит фидбэк от тестировщика, баги сразу сообщаются разработчику, разработчик уже пошел их фиксить. Пока тестировщик находит 2-й, 3-й, 4-й баг, предыдущий уже закрывается. С таким подходом процесс можно ощутимо ускорить.
«Чтобы инженеры концентрировались на качественной реализации задуманного, жестко разделяем процессы Discovery (исследование идеи) и Delivery (производство продукта)»
— Юрий Аксенов, технический директор Eatr & Yogi
Это избавляет инженеров от необходимости додумывать за кого-то другого те вещи, которые зависят от интерпретации, но очень важны для разрабатываемого решения.
Ну и последнее, возможно банальное заключение: эффективность — это люди. Поэтому нельзя переоценить способность вовремя подсветить проблемы в коммуникациях или качественно влиться в бизнес, для которого разрабатывается очередной сервис. Это все софт-скиллы и мудрость управления ресурсами, если хотите. Поэтому, кажется, опрометчиво полагать, что хорошего результата получится получится достигнуть просто через железную дисциплину.
ссылка на оригинал статьи https://habr.com/ru/articles/1049536/