«Предстарт, внимание, марш!»: как избежать хаоса в реализации ИТ‑проекта

Несущая стена проекта

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

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

Что необходимо для качественного исследования

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

1. Суть и назначение решения, какие проблемы оно должно решать.
2. В каком техническом окружении решение должно быть реализовано? Иногда заказчик не может определиться с технологическим стеком, и тогда уже на этапе предпроекта можно обсудить два‑три варианта реализации и технической инфраструктуры.
3. Какие данные потребуются для работы, где они хранятся — в реляционных базах, файловых хранилищах или гибридных системах, а также в каком объеме их предстоит обрабатывать. На данном этапе такой информации будет достаточно. Исчерпывающий анализ и профилирование данных будут выполнены уже в ходе проекта.
4. Наличие уже имеющихся компонент и интеграций и тех, которые требуется реализовать в ходе проекта. Понимание этого позволяет правильно заложить в оценку необходимые работы и сразу прояснить — на чьей стороне, интегратора или заказчика, будут выполняться дополнительные задачи.
5. Бизнес‑логика и потребители решения. Кто будет пользоваться системой? Какие предметные области деятельности бизнеса, подразделения и процессы она затронет? Какие отчеты и показатели для заказчика критичны? Чем детальнее удастся проработать эти вопросы на старте, тем более корректную оценку проекта удастся получить.

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

Тонкости, нюансы, возможные ошибки

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

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

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

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

Инструментарий

На этапе предпроекта мы фокусируемся на speed‑first‑подходе и используем легковесные инструменты для быстрой оценки. Для ускорения обследования и повышения точности оценки мы используем различные стандартизированные опросники и калькуляторы, которые уже содержат типовой набор работ в зависимости от заявленной задачи и технологического окружения. Для структурирования, наглядного описания процессов и создания эскизной архитектуры удобно использовать такие инструменты, как Visio, DrawIO или Mermaid, которые помогают быстро зафиксировать ключевые идеи и согласовать их с заказчиком. При наличии доступа к данным — что в предпроекте бывает нечасто — верхнеуровневый обзор данных можно провести с помощью специализированных инструментов для data‑driven проектов — SQL, Pandas. Такой подход позволяет за 3‑5 дней наметить контуры решения, не погружаясь в детали.

Не обходим стороной и инструменты ИИ. Это отличные помощники для тех случаев, когда требуется сделать сравнительный анализ платформ (что довольно трудоемко), или проанализировать бенчмарки. Их применение позволяет сделать наше предложение более убедительным и проработанным.

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

В целом же работа с ИИ в предпроектной и проектной аналитике в современных реалиях требует создания специализированных агентов, заточенных и обученных под выполнение конкретных задач или проектов. Речь идет не о модели, которая черпает свои знания из открытых источников, а о системе, «питающейся» корпоративными данными: внутренними базами знаний, структурированными репозиториями вроде Confluence или SharePoint, вики‑страницами с описанием процессов, техническими стандартами и т.п. Чем ближе ИИ к этим данным, тем выше релевантность его ответов, которые должны использовать в первую очередь контекст проекта. И в этом случае ИИ‑агент становится незаменимым помощником, способным существенно сэкономить наши усилия и время в ходе проекта.

Чек‑лист

Пять шагов предпроектного анализа для Data Platform:

1. Четко определите цель и границы проекта. Сформулируйте, какие бизнес‑проблемы решает платформа, определите ключевых стейк‑холдеров проекта.
2. Исследуйте окружение заказчика. Изучите организационную структуру, техническую инфраструктуру, существующие компоненты и интеграции. Это поможет выявить скрытые зависимости и определить ответственных.
3. Оцените данные на верхнем уровне. Определите, какие данные нужны, где они хранятся и в каком объеме. Глубокий анализ — задача проекта, но поверхностный обзор на предпроекте важен для оценки сложности.
4. Выявите риски и явно зафиксируйте ограничения. Проработайте риски и возможные варианты решения и действий. Все неопределенные аспекты и неизвестные оформляйте как письменные допущения.
5. Используйте легковесные инструменты для презентации решения и оценки. Опросники, калькуляторы, Draw.io для эскизов архитектуры помогут наметить контуры решения и дать оценку всего за несколько дней. Привлекайте ИИ для рутины, а не для стратегии.

Предпроектная аналитика — это как раз тот инструмент, который помогает не просто «отрезать», но и «семь раз отмерить» — чтобы после старта не пришлось тушить бесконечные кризисы.