По оценкам отраслевых аналитиков до 60–70% срывов сроков и бюджета ИТ-проектов связаны с тем, что требования на старте описаны неполно или остаются на уровне общих формулировок.
Есть идея продукта и верхнеуровневое описание, но нет зафиксированной модели того, как система должна работать в реальных сценариях. В результате уже в процессе разработки начинаются уточнения, пересборка решений и возвраты к ранее сделанным частям системы.
В этой статье расскажем, почему так происходит и как аналитика на старте влияет на управляемость ИТ-проекта, сроки и бюджет.
Есть идея продукта и верхнеуровневое описание, но нет зафиксированной модели того, как система должна работать в реальных сценариях. В результате уже в процессе разработки начинаются уточнения, пересборка решений и возвраты к ранее сделанным частям системы.
В этой статье расскажем, почему так происходит и как аналитика на старте влияет на управляемость ИТ-проекта, сроки и бюджет.
Почему проекты выходят за сроки и бюджет
Большинство проблем со сроками и бюджетом закладывается ещё на старте проекта.
Типичные признаки:
Пока проект находится на этапе аналитики, такие пробелы обычно стоят недорого — их можно устранить через уточнение требований и согласование решений. Но по мере развития проекта цена изменений быстро растёт. Во время разработки они уже затрагивают код, архитектуру и интеграции, а после запуска — работающие процессы и пользователей.
Типичные признаки:
- требования описаны как идея, а не как сценарии работы;
- не прописаны исключения и альтернативные варианты;
- у заказчика и команды разное представление о результате;
- границы системы определены размыто.
Пока проект находится на этапе аналитики, такие пробелы обычно стоят недорого — их можно устранить через уточнение требований и согласование решений. Но по мере развития проекта цена изменений быстро растёт. Во время разработки они уже затрагивают код, архитектуру и интеграции, а после запуска — работающие процессы и пользователей.
По данным отраслевых исследований, исправление требований на этапе разработки обходится в среднем в 5–10 раз дороже, чем на старте проекта, а после ввода системы в эксплуатацию разница может достигать десятков раз.
В крупных информационных системах стоимость изменений растёт не линейно, а каскадно. Одно изменение требования может затронуть несколько модулей, интеграции со смежными системами и работу разных команд. В итоге дорабатывать приходится не отдельную функцию, а целую цепочку связанных процессов. Поэтому даже небольшие уточнения, появившиеся слишком поздно, способны существенно увеличить объём работ, сроки и стоимость проекта.
Что входит в аналитику на старте ИТ-проекта
В ИТ-проектах аналитику часто воспринимают как один этап перед разработкой. На практике она состоит из нескольких уровней.
Первый — концептуальный. На этом этапе формируется общее понимание продукта: зачем он нужен, какую задачу бизнеса решает и какой результат считается успешным. Дальше начинается детальная аналитика — более прикладной этап, где общая идея продукта превращается в конкретную логику работы системы.
Первый — концептуальный. На этом этапе формируется общее понимание продукта: зачем он нужен, какую задачу бизнеса решает и какой результат считается успешным. Дальше начинается детальная аналитика — более прикладной этап, где общая идея продукта превращается в конкретную логику работы системы.
Формирование концепции продукта
Сначала фиксируются базовые вещи:
На этом этапе важны не детали, а чтобы все участники проекта одинаково понимали, что именно нужно сделать и какой результат получить.
Обычно в этом этапе участвуют:
Если кто-то из этой цепочки выпадает, картина становится неполной: требования могут быть логичными с точки зрения бизнеса, но не учитывать ограничения системы, либо быть реализуемыми технически, но неудобными для пользователя, либо просто не укладываться в реальные сроки и ресурсы.
- цели и ожидаемый результат;
- границы системы;
- функциональные требования;
- ограничения (технические и внешние);
- верхнеуровневая архитектура;
- интерфейс (если есть такой запрос).
На этом этапе важны не детали, а чтобы все участники проекта одинаково понимали, что именно нужно сделать и какой результат получить.
Обычно в этом этапе участвуют:
- бизнес-аналитик — собирает и структурирует логику;
- продуктовый аналитик — смотрит на метрики и поведение пользователей;
- архитектор — оценивает ограничения системы;
- UX/UI-дизайнер — прорабатывает сценарии использования;
- владелец продукта — принимает решения;
- руководитель проекта — связывает всё с ресурсами и сроками.
Если кто-то из этой цепочки выпадает, картина становится неполной: требования могут быть логичными с точки зрения бизнеса, но не учитывать ограничения системы, либо быть реализуемыми технически, но неудобными для пользователя, либо просто не укладываться в реальные сроки и ресурсы.
Зачем нужна детальная аналитика
После утверждения первоначальных требований проводится детальная аналитика, где описываются конкретные сценарии работы системы, исключения, правила обработки данных и взаимодействие компонентов.
Речь идёт не об общем описании процессов, а о том, как система работает в реальных сценариях:
После этого система перестаёт быть набором допущений и становится формализованной моделью, на которую можно опираться в разработке. На этом уровне уже становится возможной более точная оценка сроков, бюджета и сложности реализации.
Речь идёт не об общем описании процессов, а о том, как система работает в реальных сценариях:
- как проходит каждый ключевой процесс от начала до конца;
- что делает пользователь на каждом шаге;
- как система ведёт себя при отклонениях от основного сценария;
- какие есть ограничения, зависимости и правила обработки данных;
- как и какие отрабатывают альтернативные сценарии.
После этого система перестаёт быть набором допущений и становится формализованной моделью, на которую можно опираться в разработке. На этом уровне уже становится возможной более точная оценка сроков, бюджета и сложности реализации.
Комментарий эксперта:
Аналитика не заканчивается на старте проекта. В сложных ИТ-системах требования и сценарии живут вместе с продуктом — появляются новые интеграции, уточняется логика процессов, меняется поведение пользователей. Если это не фиксировать на уровне аналитики, система начинает постепенно распадаться: каждая команда решает свою часть задачи правильно, но общая логика теряется.
Вот пример. В одном из проектов клиент передал реализацию части системы подрядчику. Там меняли процесс согласования заявок на доступ к корпоративным системам — нужно было добавить дополнительный этап проверки для части сотрудников.
На старте сценарий описали в общих чертах без детализации пограничных ситуаций. Например, что делать с повторной заявкой после отказа, как система должна вести себя при смене роли пользователя в процессе согласования, и как обрабатывать заявки, которые приходят из разных каналов — через портал, интеграции или вручную через админку.
В результате доработка корректно отрабатывала только в основном сценарии — когда заявка проходила стандартный маршрут без отклонений. Но при добавлении новых условий система начала вести себя по-разному.
Мы подключили свою команду из 4-х человек: аналитик, два разработчика и тестировщик. В процессе пришлось заново пройтись по всем сценариям, дописать поведение системы в исключениях и внести изменения в несколько связанных модулей — маршрутизацию заявок, статусы и правила согласования.
На исправление логики ушло несколько недель. По трудозатратам это составило порядка 600–900 часов работы команды — по сути, объёме, сопоставимом с отдельным небольшим проектом.
Поэтому аналитика — это неотъемлемая часть управления проектом и нужна на всём его протяжении, чтобы сохранять целостность системы.
Олег, руководитель направления аналитики Nord Clan
Почему нельзя делать одинаковую аналитику для всех проектов
Разная цена ошибки в проектах определяет не только сложность разработки, но и то, насколько глубоко нужно прорабатывать аналитику на старте. В одних случаях система должна быть максимально формализована до кода, в других — достаточно зафиксировать минимальную модель поведения, чтобы быстро проверить идею.
Поэтому универсального подхода к аналитике не существует: она всегда подстраивается под цель системы и допустимый уровень неопределённости.
Поэтому универсального подхода к аналитике не существует: она всегда подстраивается под цель системы и допустимый уровень неопределённости.
1. Системы с высокой критичностью (финтех, медицина, госсервисы)
Цель: обеспечить корректность решений системы и исключить ошибки, которые могут повлиять на деньги, данные или регуляторные обязательства.
Что ожидают от системы: предсказуемое поведение в каждом сценарии. Одинаковые входные данные должны всегда приводить к одинаковому результату независимо от условий выполнения.
Подход к аналитике: максимальная формализация до начала разработки. На этом этапе фиксируются все сценарии работы системы: основные, альтернативные и исключения. Важно не просто описать процесс, а полностью снять неоднозначность поведения системы, чтобы исключить разную интерпретацию требований разными участниками команды.
Что ожидают от системы: предсказуемое поведение в каждом сценарии. Одинаковые входные данные должны всегда приводить к одинаковому результату независимо от условий выполнения.
Подход к аналитике: максимальная формализация до начала разработки. На этом этапе фиксируются все сценарии работы системы: основные, альтернативные и исключения. Важно не просто описать процесс, а полностью снять неоднозначность поведения системы, чтобы исключить разную интерпретацию требований разными участниками команды.
2. MVP и проверка гипотез
Цель: быстро понять, работает ли продуктовая идея и есть ли у неё ценность для пользователя или бизнеса.
Что ожидают от системы: минимально жизнеспособная реализация, которая позволяет проверить ключевую гипотезу и получить измеримый сигнал — пользуются продуктом или нет.
Подход к аналитике: сознательное упрощение. Фиксируются только ключевые сценарии и критерии успеха. Всё, что не влияет на проверку гипотезы, временно выносится за скобки. Важнее скорость запуска и стоимость ошибки при неверной гипотезе, чем полнота модели системы.
Что ожидают от системы: минимально жизнеспособная реализация, которая позволяет проверить ключевую гипотезу и получить измеримый сигнал — пользуются продуктом или нет.
Подход к аналитике: сознательное упрощение. Фиксируются только ключевые сценарии и критерии успеха. Всё, что не влияет на проверку гипотезы, временно выносится за скобки. Важнее скорость запуска и стоимость ошибки при неверной гипотезе, чем полнота модели системы.
3. Развитие существующих систем
Цель: аккуратно изменить или расширить уже работающую систему без нарушения текущих процессов.
Что ожидают от системы: стабильность. Новые изменения не должны ломать уже работающую логику и должны предсказуемо встраиваться в существующие сценарии.
Подход к аналитике: точечная работа с изменениями. Аналитика фокусируется не на всей системе, а на том, как конкретное изменение влияет на существующую модель поведения. Важно заранее понимать зависимости и потенциальные последствия, чтобы не нарушить целостность работающего продукта.
Что ожидают от системы: стабильность. Новые изменения не должны ломать уже работающую логику и должны предсказуемо встраиваться в существующие сценарии.
Подход к аналитике: точечная работа с изменениями. Аналитика фокусируется не на всей системе, а на том, как конкретное изменение влияет на существующую модель поведения. Важно заранее понимать зависимости и потенциальные последствия, чтобы не нарушить целостность работающего продукта.
Как понять, что аналитика сделана нормально
Часто в ходе проектов после этапа аналитики всё равно возникают вопросы — это нормальная часть процесса, потому что часть процессов уточняется уже в разработке. Важно то, что уточнения не должны менять зафиксированную логику системы.
Хорошая аналитика опирается на несколько обязательных условий:
Если этого нет, команда вынуждена уточнять требования уже в процессе разработки. Вместо опоры на аналитику возникает поток изменений по ходу реализации, и это приводит к росту сроков и бюджета.
Хорошая аналитика опирается на несколько обязательных условий:
- зафиксирован бизнес-результат в измеримых терминах. Например: «сократить цикл согласования заявки с 3 дней до 1 дня за счёт исключения ручного этапа согласования у руководителей»;
- описаны сквозные сценарии работы системы с привязкой к ролям и данным: кто инициирует действие, какие сущности изменяются, где фиксируется результат, какие системы получают обновление (а не только пользовательский путь в интерфейсе);
- отдельно прописаны исключения, которые реально ломают логику процесса: повторная подача заявки, изменение роли пользователя в процессе обработки, конфликт статусов между системами, частичная недоступность интеграций;
- критерии приёмки сформулированы как проверяемые условия поведения системы: какие статусы должны появиться в системе учёта, какие события должны быть зафиксированы в логах/интеграциях, какие данные должны совпадать между системами после завершения процесса;
- оценка сроков и бюджета прозрачна и привязана к количеству сценариев, интеграций и точек изменения в системе (например: сколько сервисов затрагивается, сколько бизнес-правил меняется, сколько систем синхронизируется).
Если этого нет, команда вынуждена уточнять требования уже в процессе разработки. Вместо опоры на аналитику возникает поток изменений по ходу реализации, и это приводит к росту сроков и бюджета.
Аналитика на старте определяет успех ИТ-проекта, потому что именно здесь определяется, как будет работать система. От этого зависят сроки, бюджет и то, насколько управляемой будет разработка.
Дальше это естественно переходит в заказную разработку ИТ-проектов, где зафиксированные требования становятся основой для реализации системы.
Дальше это естественно переходит в заказную разработку ИТ-проектов, где зафиксированные требования становятся основой для реализации системы.
