15 метрик разработки: что измерять, чтобы проект не срывал сроки

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

19 августа 2026 Разработка 13 мин чтения

---

Зачем заказчику метрики разработки

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

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

Что даёт заказчику измеримый процесс:

• Ранний сигнал вместо поздней новости. Отставание видно на второй-третьей неделе по замедлению потока задач, а не в день, когда срок уже сорван.
• Предмет разговора вместо оценок. Обсуждение «мне кажется, идёт медленно» превращается в «время цикла задачи выросло с четырёх дней до девяти, разбираемся почему».
• Основание для решений по бюджету. Понятно, куда добавить людей, а где добавление людей ничего не ускорит.
• Сравнимость периодов. Один и тот же показатель за март и за сентябрь показывает, что изменилось в процессе после смены состава команды или технологий.

Отраслевой канон измерений задаёт исследовательская программа DORA (Google Cloud): изначально это были четыре ключевых показателя, сейчас в модели их пять — время прохождения изменения, частота выкладок, время восстановления после неудачной выкладки, доля неудачных выкладок и доля незапланированных повторных выкладок. Мы взяли эту рамку за основу и дополнили её тем, что в наших проектах регулярно спрашивает заказчик: качество, предсказуемость планирования и стабильность приложения у пользователей.

Четыре группы метрик разработки

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

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

Метрики скорости поставки (1–4)

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

Метрика 1. Время цикла задачи

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

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

Метрика 2. Время от постановки до релиза

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

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

Метрика 3. Частота выпуска обновлений

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

Редкие крупные релизы выглядят экономнее, но каждый из них несёт больше изменений сразу, поэтому и разбирать последствия сложнее. Частые небольшие обновления сокращают время до пользователя и упрощают поиск причины, если что-то сломалось. Ограничитель здесь внешний: у каждого стора свой срок проверки, и на релизный ритм он влияет напрямую — правила модерации App Store стоит учитывать при планировании.

Метрика 4. Пропускная способность команды

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

Практическая ценность в другом. Стабильная пропускная способность за три-четыре отрезка подряд даёт основание для прогноза: если в очереди осталось шестьдесят задач, а команда закрывает пятнадцать за две недели, до конца объёма примерно восемь недель. Это и есть переход от обещаний к арифметике.

Метрики качества (5–8)

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

Метрика 5. Плотность дефектов

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

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

Метрика 6. Доля ошибок, дошедших до пользователей

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

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

Метрика 7. Покрытие кода автотестами

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

Гнаться за абсолютным процентом не стоит: сто процентов покрытия не означают отсутствие ошибок, а стоят дорого. По нашему опыту в мобильном e-commerce разумнее считать покрытие критичных сценариев — авторизация, корзина, оплата, оформление заказа, синхронизация с учётной системой, — а по остальному коду смотреть на тренд, чтобы он не падал.

Метрика 8. Время жизни дефекта

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

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

Метрики предсказуемости (9–12)

Третья группа нужна тем, кто планирует бюджет и договаривается о сроках. Она показывает, насколько оценкам команды можно верить и что происходит с объёмом работ по ходу проекта.

Метрика 9. Точность оценки

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

Систематическое отклонение вверх на 30–40% — не повод обвинять команду, а повод изменить процесс оценки: разбивать задачи мельче, закладывать проверку и правки в оценку, требовать постановку с описанными состояниями экранов. При работе по фактическим часам этот показатель прямо влияет на бюджет, поэтому мы разбирали его в сравнении моделей оплаты — по фактическим часам или по фиксированной цене.

Метрика 10. Выполнение обязательств рабочего отрезка

Доля задач, взятых в план на две недели и закрытых в срок. Показатель отвечает на вопрос, можно ли строить планы на месяц вперёд по обещаниям команды.

Здоровое значение — стабильное, а не максимальное. Команда, которая закрывает 100% плана каждый раз, скорее всего берёт в план меньше, чем может. Команда с 50% либо перегружена, либо получает задачи с неясной постановкой. Обе ситуации чинятся на уровне планирования, а не давлением на сроки.

Метрика 11. Объём незавершённой работы

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

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

Метрика 12. Прирост объёма работ

Доля задач, добавленных в план уже после его согласования. Небольшой прирост — норма живого проекта; прирост в 40–50% означает, что объём работ на старте был описан слишком общо.

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

Метрики стабильности после релиза (13–15)

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

Метрика 13. Доля сессий без сбоев

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

Здесь есть внешний, а не выдуманный нами ориентир. Google Play публикует пороги нежелательного поведения: по данным документации Android vitals, приложение считается проблемным при доле сессий со сбоем выше 1,09% и доле зависаний интерфейса выше 0,47% в среднем по устройствам за 28 дней. Превышение порога может снизить видимость приложения в сторе и добавить предупреждение на его карточку. Это тот случай, когда техническая метрика напрямую конвертируется в трафик и продажи.

Метрика 14. Время восстановления после сбоя

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

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

Метрика 15. Доля неудачных выпусков

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

Рост показателя обычно означает недостаточную проверку под нагрузкой или на редких конфигурациях устройств. Проверить продукт под нагрузкой помогает нагрузочное тестирование, а спорные интерфейсные решения безопаснее выкатывать через A/B-тестирование — на части аудитории, а не сразу на всю.

Сводная таблица: 15 метрик и ориентиры

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

Показать все

Как выстроить измерения на проекте

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

1. Возьмите четыре метрики на старт. По одной из каждой группы: время от постановки до релиза, доля ошибок, дошедших до пользователей, точность оценки, доля сессий без сбоев. Этой четвёрки достаточно, чтобы увидеть перекос.
2. Договоритесь об определениях. «Задача готова» — это код написан, проверен или опубликован? Пока определение не зафиксировано письменно, цифры двух отчётов сравнивать нельзя.
3. Настройте сбор в тех системах, где работа уже идёт. Трекер задач даёт первые двенадцать показателей, система мониторинга сбоев — три последних. Отдельная таблица, которую кто-то заполняет руками, живёт ровно до первого аврала.
4. Снимите базовый уровень за два месяца. До этого цифры не с чем сравнивать. Первый отчёт задаёт точку отсчёта для всех следующих.
5. Договоритесь о ритме разбора. Раз в две недели — короткий обзор изменений, раз в квартал — разбор трендов и решения по процессу.
6. Добавляйте остальные показатели по мере вопросов. Метрика нужна тогда, когда без неё нельзя принять решение. Показатель, который никто не обсуждает, честнее убрать.

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

Типичные ошибки в работе с метриками

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

• Метрика как оценка людей. Как только пропускная способность становится основанием для премии, задачи начинают дробиться, а оценки — расти. Показатели описывают процесс, а выводы делаются о процессе.
• Одна метрика вместо набора. Скорость без качества даёт рост ошибок, качество без скорости — остановку поставки. Показатели читаются группами.
• Сравнение разных команд. Пропускная способность и точность оценки сопоставимы только внутри одной команды на одном продукте. Межкомандные сравнения ведут к подгонке цифр.
• Среднее вместо распределения. Среднее время цикла в пять дней может скрывать половину задач по два дня и половину по девяти. Медиана и «хвост» информативнее.
• Отчёт без решений. Если по итогам разбора не меняется ни один пункт в процессе, измерения превращаются в ритуал. Каждый разбор должен заканчиваться одним-двумя изменениями.
• Измерения вместо постановки задач. Никакая метрика не заменит внятного описания того, что нужно сделать. Часть проблем со сроками разбирается ещё до старта — мы собрали их в материале про ошибки заказчика при разработке приложения.

Что мы измеряем на проектах FITTIN

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

Модель платформы влияет и на сами показатели. Базовые модули — каталог, корзина, оплата, личный кабинет, программа лояльности — уже прошли проверку на реальных проектах, поэтому плотность дефектов в них ниже, а время цикла задач по ним короче: разрабатывается и проверяется только уникальная часть продукта. Мониторинг работоспособности и обновления модулей входят в ежемесячные лицензионные платежи — это же покрывает и метрики стабильности после релиза. Состав тарифов по трём направлениям опубликован на странице «Тарифы», а детали для интернет-магазинов — на странице мобильных приложений для e-commerce и комплексной разработки приложения и сайта.

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

Итог: с чего начать измерения

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

1. Возьмите четыре метрики — по одной из каждой группы: время до релиза, доля ошибок у пользователей, точность оценки, доля сессий без сбоев.
2. Зафиксируйте определения письменно — что считается готовой задачей и что считается критичной ошибкой.
3. Соберите базовый уровень за два месяца — первый отчёт задаёт точку отсчёта, по которой сравниваются все следующие.
4. Разбирайте цифры раз в две недели и заканчивайте каждый разбор одним-двумя изменениями в процессе.
5. Расширяйте набор по мере вопросов — показатель, по которому не принимается решений, честнее убрать.

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

Что делать дальше:

• Приложение уже работает — начните с аудита мобильного приложения от 7 дней или комплексной проверки продукта.
• Проект только планируется — посчитайте бюджет и срок в калькуляторе и закажите разработку технического задания.
• Не хватает людей на проверку качества или на разработку — подключите Flutter-разработчиков в команду или обсудите задачу через контакты.
• Хотите посмотреть, как это выглядит на реальных продуктах — откройте портфолио проектов.

Вопросы и ответы

Какие метрики использовать для оценки работы команды разработки?

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

Что такое метрики DORA и зачем они бизнесу?

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

Какое покрытие кода тестами считается достаточным?

Универсального процента нет, и стремиться к 100% невыгодно: полное покрытие дорого и не гарантирует отсутствие ошибок. По нашему опыту в мобильном e-commerce разумнее считать покрытие критичных сценариев — авторизация, корзина, оплата, оформление заказа, обмен данными с учётной системой, — а по остальному коду следить, чтобы показатель не снижался от релиза к релизу. Документация Flutter рекомендует держать много модульных проверок и проверок элементов интерфейса и дополнять их сквозными проверками ключевых сценариев.

Как измерить скорость разработки мобильного приложения?

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

Сколько сбоев в мобильном приложении считается нормой?

Ориентир задаёт сам стор. Google Play в документации Android vitals публикует пороги нежелательного поведения: доля сессий со сбоем выше 1,09% и доля зависаний интерфейса выше 0,47% в среднем по устройствам за 28 дней. При превышении стор может снизить видимость приложения и показать предупреждение на карточке. Практический вывод: держать долю сессий без сбоев заметно выше 99% и разбирать сбои, затрагивающие наибольшее число пользователей, в первую очередь.

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

Раньше всего это видно по трём показателям. Пропускная способность падает два отрезка подряд, время цикла задачи растёт, а доля задач, добавленных в план после его согласования, превышает 30–40%. Любой из этих сигналов появляется за несколько недель до срыва срока и позволяет обсудить объём работ, пока решение ещё есть. Разовое отклонение нормально — тревожен устойчивый тренд.

Кто должен считать метрики разработки — заказчик или подрядчик?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.