Блог

Почему аналитика на старте определяет успех ИТ-проекта

По оценкам отраслевых аналитиков до 60–70% срывов сроков и бюджета ИТ-проектов связаны с тем, что требования на старте описаны неполно или остаются на уровне общих формулировок.

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

В этой статье расскажем, почему так происходит и как аналитика на старте влияет на управляемость ИТ-проекта, сроки и бюджет.

Почему проекты выходят за сроки и бюджет

Большинство проблем со сроками и бюджетом закладывается ещё на старте проекта.

Типичные признаки:

  • требования описаны как идея, а не как сценарии работы;
  • не прописаны исключения и альтернативные варианты;
  • у заказчика и команды разное представление о результате;
  • границы системы определены размыто.

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

Что входит в аналитику на старте ИТ-проекта

В ИТ-проектах аналитику часто воспринимают как один этап перед разработкой. На практике она состоит из нескольких уровней.

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

Формирование концепции продукта

Сначала фиксируются базовые вещи:

  • цели и ожидаемый результат;
  • границы системы;
  • функциональные требования;
  • ограничения (технические и внешние);
  • верхнеуровневая архитектура;
  • интерфейс (если есть такой запрос).

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

Обычно в этом этапе участвуют:

  • бизнес-аналитик — собирает и структурирует логику;
  • продуктовый аналитик — смотрит на метрики и поведение пользователей;
  • архитектор — оценивает ограничения системы;
  • UX/UI-дизайнер — прорабатывает сценарии использования;
  • владелец продукта — принимает решения;
  • руководитель проекта — связывает всё с ресурсами и сроками.

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

Зачем нужна детальная аналитика

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

Речь идёт не об общем описании процессов, а о том, как система работает в реальных сценариях:

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

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

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

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

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

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

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

На исправление логики ушло несколько недель. По трудозатратам это составило порядка 600–900 часов работы команды — по сути, объёме, сопоставимом с отдельным небольшим проектом.

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

Олег, руководитель направления аналитики Nord Clan

Почему нельзя делать одинаковую аналитику для всех проектов

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

Поэтому универсального подхода к аналитике не существует: она всегда подстраивается под цель системы и допустимый уровень неопределённости.

1. Системы с высокой критичностью (финтех, медицина, госсервисы)

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

Что ожидают от системы: предсказуемое поведение в каждом сценарии. Одинаковые входные данные должны всегда приводить к одинаковому результату независимо от условий выполнения.

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

2. MVP и проверка гипотез

Цель: быстро понять, работает ли продуктовая идея и есть ли у неё ценность для пользователя или бизнеса.

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

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

3. Развитие существующих систем

Цель: аккуратно изменить или расширить уже работающую систему без нарушения текущих процессов.

Что ожидают от системы: стабильность. Новые изменения не должны ломать уже работающую логику и должны предсказуемо встраиваться в существующие сценарии.

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

Как понять, что аналитика сделана нормально

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

Хорошая аналитика опирается на несколько обязательных условий:

  • зафиксирован бизнес-результат в измеримых терминах. Например: «сократить цикл согласования заявки с 3 дней до 1 дня за счёт исключения ручного этапа согласования у руководителей»;
  • описаны сквозные сценарии работы системы с привязкой к ролям и данным: кто инициирует действие, какие сущности изменяются, где фиксируется результат, какие системы получают обновление (а не только пользовательский путь в интерфейсе);
  • отдельно прописаны исключения, которые реально ломают логику процесса: повторная подача заявки, изменение роли пользователя в процессе обработки, конфликт статусов между системами, частичная недоступность интеграций;
  • критерии приёмки сформулированы как проверяемые условия поведения системы: какие статусы должны появиться в системе учёта, какие события должны быть зафиксированы в логах/интеграциях, какие данные должны совпадать между системами после завершения процесса;
  • оценка сроков и бюджета прозрачна и привязана к количеству сценариев, интеграций и точек изменения в системе (например: сколько сервисов затрагивается, сколько бизнес-правил меняется, сколько систем синхронизируется).

Если этого нет, команда вынуждена уточнять требования уже в процессе разработки. Вместо опоры на аналитику возникает поток изменений по ходу реализации, и это приводит к росту сроков и бюджета.
Аналитика на старте определяет успех ИТ-проекта, потому что именно здесь определяется, как будет работать система. От этого зависят сроки, бюджет и то, насколько управляемой будет разработка.

Дальше это естественно переходит в заказную разработку ИТ-проектов, где зафиксированные требования становятся основой для реализации системы.
2026-06-17 14:49 Разработка ПО