Крупный ИТ-проект без хаоса: как пройти все этапы и уложиться в сроки и бюджет

Запуск ИТ-проекта — это всегда про сроки, деньги и риски. А когда проект крупный, добавляются интеграции, архитектурные ловушки и стресс. Партнёры Yandex Cloud рассказывают, как провести проект от идеи до стабильной работы и сохранить контроль над процессом.

Крупный ИТ-проект без хаоса: как пройти все этапы и уложиться в сроки и бюджет

Внедрение ERP, CRM или DWH, разработка программ лояльности, миграция в облако — любой крупный IT-проект требует чёткого планирования, исследований и грамотного управления. Самостоятельная реализация таких проектов требует значительных ресурсов и экспертизы. Без опыта работы с крупными IT-системами возрастает риск срывов сроков, перерасхода бюджета и архитектурных ошибок.

Минимизировать риски помогает экспертиза тех, кто уже решал похожие задачи. Попросили экспертов Softline, Axenix, Hilbert Team, ATSAero, VocaTech, Quick Resto и «Флант» рассказать о ключевых этапах IT-проекта с примерами решений, практическими советами и инструментами для снижения рисков. Их практика не универсальна, но поможет понять, как избежать типичных ошибок и довести проект до результата.

Статья основана на опыте партнёров Yandex Cloud и не является универсальным руководством для всех типов IT-проекта. Рекомендации могут не полностью соответствовать вашему кейсу, поэтому для оптимального решения рекомендуем проконсультироваться с профильными специалистами.

Подготовка к проекту

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

  • Бизнес-заказчики — определяют цель проекта и желаемый результат.
  • IT-специалисты — отвечают за интеграцию и инфраструктуру.
  • Операционные и производственные команды — им предстоит работать с новой системой или инструментом.
  • Финансовый отдел — оценивает экономическую эффективность.
  • Юристы — следят, чтобы проект соответствовал регуляторным требованиям.
Максим Егоров
Операционный директор Softline Digital (ГК Softline)

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

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

Чек-лист Softline Digital: вопросы для старта проекта

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

Оценка и аналитика проекта

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

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

Ольга Калинова
Руководитель блока анализа данных практики «Данные и прикладной искусственный интеллект» Axenix

«На этапе анализа важно тщательно проработать бизнес-требования и далее, при “приземлении” их на функциональный уровень, постоянно отслеживать их изменения. Однако одной документации часто недостаточно — для глубокого понимания данных аналитик предпочитает самостоятельно анализировать их, выявляя зависимости и скрытые инсайты. Обычно анализ ведётся посредством написания SQL-запросов и средствами Python. В последнее время мы внедряем в нашу работу AI-ассистенты, которые помогают не только правильно использовать данные, но и ускорить работу с кодом и упростить его оптимизацию.

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

Чек-лист Axenix: что должно быть в техническом задании

  • Краткие описания текущего состояния (as is) и целевого (to be). С их помощью аналитик понимает, почему возникла потребность в запуске новой функциональности — это задаёт фокус для более детальной проработки.
  • Список объектов к реализации в привязке к бизнес-требованиям.
  • Функциональные требования с указанием SLA и ограничений. Это позволит спроектировать систему, которая будет учитывать особенности бизнес-процессов и IT-ландшафта.

Проектирование

Этот этап, как правило, состоит из нескольких шагов:

  • Проектирование архитектуры.
  • Обсуждение бизнес-задач стейкхолдеров и проработка User Story Map (сценариев применения) системы.
  • Подбор технологического стека для реализации проекта: инструментов разработки, языков программирования, сервисов.

Важно разбить работу на шаги и проверять результат на каждом из них — это поможет заметить ошибки до того, как они станут проблемой.

Вячеслав Бессонов
CEO и основатель Hilbert Team

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

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

Чек-лист Hilbert Team: что важно учесть при проектировании

  • Отказоустойчивость — насколько критично для бизнеса поддерживать бесперебойную работу системы.
  • Катастрофоустойчивость — нужна ли географически распределённая архитектура, планы аварийного восстановления и резервное копирование.
  • Масштабируемость — насколько важно быстро увеличивать или уменьшать ресурсы (например, в случае роста клиентской базы).
  • Вопрос безопасности — обеспечить необходимый уровень защиты данных и соответствие стандартам (например, 152-ФЗ).
  • Скорость релизов — важно ли для бизнеса оперативно разрабатывать и выкатывать новые версии продукта.
  • Наличие контура разработки — нужен ли компании отдельный контур для разработчиков, где действуют специфические требования.
  • Интеграция с существующей инфраструктурой — если вы используете гибридную IT-среду, стоит предусмотреть, как облачная и on-premise-инфраструктуры будут взаимодействовать между собой.
  • Стоимость будущей инфраструктуры — важно заранее продумать баланс между необходимыми техническими характеристиками и затратами на их реализацию, чтобы обеспечить не только функциональность, но и экономическую целесообразность проекта для бизнеса.

Разработка

На этапе разработки создаётся работающий продукт, который соответствует всем требованиям бизнеса. В зависимости от задачи выбирают подходящую методологию: Scrum для гибкости, Kanban для постоянных улучшений или Waterfall для проектов с чёткой последовательностью этапов.

Егор Савушкин
Директор по производству компании АТС (ATSAero)

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

1. Бизнес- или технический аудит.

2. Реализация сервиса.

3. Сдача сервиса.

4. Техническая поддержка и сервисное сопровождение.

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

— гибридная система классификации на основе LLM-моделей;

— RAG-архитектура для поиска релевантных ответов на вопросы пользователей;

— модель для классификации голосовых ассистентов и автоответчиков.

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

Чек-лист ATSAero: на что обратить внимание при выборе методологии

  • Масштабируемость архитектуры. Важно убедиться, что проект легко выдержит рост нагрузки — больше пользователей, больше данных или дополнительные функции не должны ломать систему.
  • Многоуровневый контроль качества. Проверка должна быть на каждом этапе: от момента подготовки проектной документации до финальной версии продукта. Это помогает выявлять ошибки заранее и не тратить время на их исправление в последний момент.
  • Прозрачность процессов и регулярный мониторинг. Ежедневные короткие статус-чеки и автоматический мониторинг ключевых метрик (бизнес-показатели, технические параметры) позволяют видеть эффективность работы команды и функционирования сервисов.
  • Гибкость методологии. Подход должен исходить из задач: где-то эффективен Scrum, где-то — Kanban, а для части процессов может подойти Waterfall. Иногда лучше использовать комбинированные модели.

Приёмо-сдаточные испытания

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

Андрей Карасев
Product Owner VocaTech

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

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

Чек-лист VocaTech: как провести всеобъемлющее тестирование

  • Подготовительный этап. Собираются и уточняются данные об инфраструктуре заказчика, согласовывается архитектура решения, формируется пакет модулей системы согласно утверждённым требованиям. Готовится тест-план для альфа-тестирования.
  • Альфа-тестирование. Проверяется работа модулей системы в лабораторных условиях по заранее подготовленному плану. Фиксируются ошибки, проводится их оценка и приоритизация, выполняется повторное тестирование. По итогам разрабатывается тест-план для следующего этапа.
  • Бета-тестирование на инфраструктуре заказчика. Проводится проверка соответствия выделенных ресурсов утверждённой архитектуре, развёртывание и настройка модулей системы. Далее выполняется тестирование, анализируются возможные ошибки и разрабатывается программа приёмо-сдаточных испытаний (ПСИ).
  • ПСИ. Испытания проводятся по согласованной программе, фиксируются замечания заказчика и при необходимости устраняются. После успешного завершения испытаний осуществляется документальное закрытие приёмки.
  • Запуск системы. Система вводится в эксплуатацию.

Опытная эксплуатация

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

Александр Строкань
CEO сервиса автоматизации ресторанного бизнеса Quick Resto

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

Каждый модуль Quick Resto прямо или косвенно влияет на метрики ресторана. Мы стараемся сделать так, чтобы интерфейс наших продуктов позволял тратить минимум времени на рутинные операции, держать процессы под контролем и принимать правильные решения каждый день. А из небольших ежедневных улучшений складывается конечный финансовый результат».

Чек-лист Quick Resto: как понять, что автоматизация сработала

  • Оцените первые результаты. Посмотрите, как прошёл онбординг сотрудников (адаптировалась ли команда), оцените полноту оцифровки бизнес-процессов, выстроен ли регулярный менеджмент.
  • Проверьте эффективность бизнес-процессов. Автоматизация должна не просто работать, а улучшать процессы. Оцените, стало ли проще управлять заказами, сократились ли издержки и повысилась ли скорость обслуживания клиентов.
  • Оцените потенциал масштабирования. Если автоматизация помогла улучшить метрики и процессы, подумайте о масштабировании. Например, откройте новые точки, запустите франшизу или расширьте ассортимент.

Техническая поддержка

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

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

Андрей Корякин
Руководитель департамента внедрения и поддержки DevOps-практик компании «Флант»

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

Мы предлагаем три уровня SLA:

1. Быстрая реакция на критические сбои — в течение пяти минут.

2. Поддержка ключевых компонентов системы.

3. Специализированная поддержка для Deckhouse Kubernetes Platform.

Каждый SLA настраивается под потребности бизнеса и гарантирует чёткие сроки решения проблем.

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

Чек-лист команды «Флант»: что важно учесть после запуска

  • Запланируйте ресурсы на долгосрочную поддержку проекта, так как она играет ключевую роль в его успешности на длинной дистанции.
  • Заранее готовьтесь к изменениям, чтобы быстро адаптироваться в условиях изменений. Разработайте план дальнейшего развития и модернизации IT-систем.
  • Используйте актуальные технологии, которые позволят получить необходимый уровень отказоустойчивости, простоту масштабирования и устойчивость к колебаниям нагрузки.
  • Уделите внимание вопросу наблюдаемости (observability), так как это позволит превентивно реагировать на изменение состояния инфраструктуры и сервисов и предотвращать возможные сбои.
  • Запланируйте регулярное обновление программного обеспечения и компонентов системы.

  • Регулярно обучайте персонал новым технологиям и методам работы.

Выводы

Успешный запуск крупного IT-проекта требует тщательной подготовки, продуманного планирования и тесного взаимодействия с партнёрами. На каждом этапе важно согласовать цели, зафиксировать KPI и определить критерии успешности проекта.

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

Подписывайтесь на наш телеграм-канал и читайте ещё больше о компаниях, которые создают и развивают бизнес вместе с Yandex Cloud.

Другие кейсы наших клиентов и партнёров:

11
Начать дискуссию
[]