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

Две вечные боли у новичков и у джунов/мидлов: «мы всё записали, но всё равно переделываем» и «почему согласование одной кнопки занимает две недели». Ответ обычно простой и неприятный: вы не измеряете требования. А значит — не можете ни улучшить сбор требований, ни нормально сделать анализ требований, ни доказать бизнесу, что сроки уплывают не из-за “разработчики медленные”.

Я видел это в российских компаниях десятки раз: в Яндекс.Трекере (или Jira), в Confluence/Notion, в 1С:ИТС-хаосе, в чатах Telegram. Везде одна и та же схема: требования приходят «как попало», живут «где придётся», меняются «по ощущению». И потом удивление, почему бюджет сгорел, а релиз превратился в сериал без финала.

Что именно измеряем: два показателя, которые режут туман

1) Время прохождения требования (Lead Time требования)

Тезис: если вы не знаете, сколько живёт требование от появления до “готово”, вы не управляете сроками — вы гадаете.

Как считать: зафиксируйте дату/время:

• создания (когда требование впервые сформулировано);
• принятия в работу (когда команда согласилась, что «да, делаем»);
• готовности (попало в релиз/в прод/в завершённые).

Практический вывод: уже через 2–4 недели у вас появится медиана и “хвост” — требования, которые зависают на согласованиях, аналитике, правках или тестировании.

Подводный камень: мерить “среднее” вместо медианы. Среднее красиво врёт, когда у вас 3 требования прошли за 2 дня, а одно висело 45 дней.

2) Процент изменений требований (Change Rate)

Тезис: изменения — нормальны. Ненормально, когда вы не знаете их долю и причины.

Как считать: для каждого требования отмечайте, было ли:

• изменение объёма (scope): добавили/убрали функционал;
• изменение правил (business rules): поменялась логика;
• изменение интерфейса/текста;
• изменение интеграций/данных;
• изменение приёмки (acceptance criteria).

Метрика: Change Rate = (кол-во требований, изменённых после согласования) / (общее кол-во требований) × 100%.

Практический вывод: если у вас 30–60% изменений — проблема обычно не в команде, а в входном качестве: слабый сбор требований и поверхностный анализ требований.

Подводный камень: считать изменением любое уточнение. Уточнение формулировки без изменения смысла — это не “изменение требований”, иначе вы сами себе нарисуете катастрофу.

Минимальная система учёта: без «внедрения цифровой трансформации»

Какие статусы реально нужны

Тезис: чем проще workflow, тем больше шансов, что по нему будут жить.

Это легко делается в Яндекс.Трекере, Kaiten, YouTrack, Jira — неважно. Важно: одинаковые статусы и дисциплина фиксации дат.

Как сделать так, чтобы изменения были “легальными”

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

1. Заводите поле: «Изменено после согласования: да/нет».
2. Если «да» — обязательное поле: «Причина изменения» (выбор из списка).
3. Если изменение крупное — создавайте “версию” требования или отдельную задачу change request.

Подводный камень: “мелкие правки” копятся, превращаются в переработку на 40%. А по документам — “ничего не меняли”. Ну да, конечно.

Причины изменений: что обычно ломает требования в российских реалиях

Топ-6 причин (и что с ними делать)

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

Кейсы из практики: как метрики вскрывают реальность

Кейс №1 (условно успешный): “Согласование длиннее разработки”

Команда делала внутренний сервис заявок. По ощущениям менеджмента «всё тормозит на разработке». Мы померили Lead Time: медиана 18 дней, но из них 11 — статус “На уточнении/Согласовании”. Разработка занимала 4–5 дней, остальное — беготня за ответами, потому что владельца данных (в 1С) никто не назначил.

Что сделали: добавили в шаблон требования блок “источник данных + ответственный”, и правило: без него в “Согласовано” не переводим. Через месяц медиана Lead Time упала до 11 дней. Не магия. Просто перестали делать вид, что данные “как-нибудь сами”.

Ошибка, которую чуть не совершили: нанять ещё одного разработчика “для ускорения”. Он бы ускорил 4 дня из 18. Бизнесу понравилось бы… минут на десять.

Кейс №2 (неудачный): “Процент изменений 70%, но виноват… аналитик”

В продуктовой команде изменения летели постоянно: “поменяйте текст”, “добавьте поле”, “а давайте ещё фильтр”. Мы посчитали Change Rate — 70% требований менялись после согласования. Отчёт показали руководству, и первое решение было: “аналитик плохо собирает требования”.

А потом разложили причины: 40% изменений — потому что финальный стейкхолдер вообще не участвовал в согласовании; 20% — потому что отсутствовали критерии приёмки; остальное — потому что приоритеты менялись каждую неделю без фиксации. То есть проблема была в управлении требованиями как процессом, а не в человеке.

Скрытая цена изменений: почему метрика — это про деньги

В российском найме бизнес-аналитик/системный аналитик ценится не за «умение писать ТЗ на 40 страниц», а за снижение переделок. По рынку (если грубо по вакансиям больших городов) джуны часто стартуют в районе 80–140 тыс. ₽, мидлы — 160–250 тыс. ₽, выше — как договоритесь и как вы умеете считать эффект.

Простой расчёт для трезвости: если команда из 5 человек (разраб, тест, аналитик, дизайнер, проджект) тратит суммарно 20 часов в неделю на переделки из‑за изменений требований, это около 80 часов в месяц. Даже по условным 1500–2500 ₽/час внутренней стоимости получается 120–200 тыс. ₽ в месяц “в печку”. И это без учета упущенной выгоды от задержек.

Подводный камень: пытаться «запретить изменения». Запретите — и они просто переедут в “срочные правки после релиза”, то есть станут дороже.

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

Если вы хотите нормальный сбор требований и честный анализ требований, начните не с шаблонов и не с “культуры общения”, а с двух цифр: Lead Time и Change Rate. Они быстро показывают, где узкое горлышко: согласование, данные, приёмка или приоритеты. А дальше вы чините конкретное место, а не “весь процесс целиком”.

• Если вы меняете профессию в IT: учитесь записывать требования так, чтобы по ним можно было проверить результат (критерии приёмки + примеры данных). И ведите учёт изменений — это ваш аргумент на собеседовании сильнее любого сертификата.
• Если вы джун 1–3 года: соберите статистику по своей команде за 1–2 месяца и принесите на ретро/встречу с руководителем. Цифры снимают личные обвинения и переводят разговор в “что улучшить”.

Если хочется больше таких разборов без маркетингового дыма — они живут на https://itokno.ru (здесь же можно найти соседние статьи про требования, роли и карьерный рост).

Частые вопросы