Пилот запущен, а дальше что: почему перспективные ИТ-проекты не доходят до промышленной эксплуатации
Пилот показывали руководству в пятницу. В понедельник выяснилось, что сервис работает под учетной записью разработчика, данные загружаются вручную, мониторинга нет, резервное копирование никто не согласовал, а интеграция с основной системой существует только в виде CSV-файла.
На демонстрации все выглядело убедительно. В промышленной эксплуатации такая конструкция не проживет и недели.
Проблема большинства пилотов не в том, что технология оказывается нерабочей. Чаще компания проверяет саму идею, но не проверяет собственную готовность ее эксплуатировать. В результате успешный эксперимент принимают за почти готовый продукт, хотя между ними лежит не пара спринтов, а полноценный инженерный и организационный переход.
У пилота почти всегда привилегированные условия. Пользователей мало, нагрузка контролируемая, сценарии заранее известны, данные подготовлены, а проектная команда находится рядом и вручную устраняет любые сбои. Разработчик поправил запись в базе, аналитик объяснил спорный сценарий, DevOps перезапустил контейнер, и демонстрация продолжилась.
В промышленном контуре такой режим быстро разваливается. Пользователь создает заявку ночью, интеграция возвращает ошибку, данные расходятся, а человек, который знает, как все починить, уже занят другим проектом. Именно здесь становится видно, что многие проблемы пилота не были решены. Их временно компенсировали вниманием команды.
После демо начинается ответственность
Пока решение остается экспериментом, оно может жить на временной инфраструктуре, финансироваться из бюджета на исследования и не иметь формального владельца. После запуска появляются обязательства: доступность сервиса, резервирование, восстановление после сбоя, контроль прав, аудит действий, регламент обновлений, поддержка пользователей.
И тут нередко обнаруживается, что отвечать за систему некому.
Бизнес считает, что продукт уже передан в ИТ. ИТ напоминает, что проект вел бизнес. Служба эксплуатации не принимала архитектуру, информационная безопасность подключилась в последний момент, а команда разработки рассчитывала завершить работу после пилота.
Система оказывается между подразделениями. Формально она существует, но ни у кого не входит в зону ответственности.
Прототип приходится проектировать заново
Второй барьер возникает на уровне архитектуры. Чтобы быстрее проверить гипотезу, пилот часто собирают в изолированном контуре. Авторизация упрощена, роли заданы вручную, интеграции заменены выгрузками, отказоустойчивость не рассматривается, а объем данных ограничен тестовой выборкой.
Для эксперимента это разумный компромисс. Ошибка начинается тогда, когда временные решения становятся фундаментом промышленной системы.
Например, на пилоте сервис раз в сутки получает файл из учетной системы. После запуска бизнес ожидает обновление данных в реальном времени. Значит, требуется API, обработка повторных запросов, контроль последовательности событий, очередь сообщений и механизм сверки. Это уже не «небольшая доработка», а другой интеграционный контур.
То же самое происходит с инфраструктурой. Одна виртуальная машина превращается в кластер, локальные логи должны попасть в корпоративный мониторинг, ручное восстановление базы уступает место проверяемому сценарию disaster recovery. Иногда после такой ревизии дешевле пересобрать решение, чем продолжать наращивать прототип.
Система есть, процесса нет
Даже технически зрелый продукт может не дойти до нормальной эксплуатации, если вокруг него не построен процесс.
Кто создает пользователей и меняет права? Кто отвечает за справочники? Кто разбирает инциденты? Кто принимает решение об обновлении? Кто определяет приоритет доработок? Кто сообщает пользователям об изменениях?
На пилоте все это делает проектная команда. После релиза ее участники возвращаются к своим основным задачам, и выясняется, что постоянная поддержка продукта нигде не предусмотрена.
Особенно быстро такие системы деградируют при высокой зависимости от ручных операций. Один сотрудник умеет исправлять данные, второй знает порядок перезапуска, третий хранит актуальную инструкцию у себя на диске. Пока все на месте, решение выглядит работоспособным. После первого отпуска или увольнения начинается археология.
«Работает» — слишком слабый результат пилота
Еще одна причина провала связана с критериями успеха. В отчете часто фиксируют, что технология работает, интеграция выполнена, пользователи дали положительную обратную связь. Но этого недостаточно, чтобы обосновать промышленный запуск.
Работать может почти любой аккуратно подготовленный прототип. Вопрос в другом: изменил ли он сам процесс.
Сократилось ли время операции? Уменьшилось ли число ошибок? Какова стоимость сопровождения? Возвращаются ли пользователи в систему без напоминаний? Сколько ручного труда скрыто за красивым интерфейсом? Что произойдет при десятикратном росте нагрузки?
Без таких метрик пилот превращается в дорогую демонстрацию. Технология выглядит перспективной, но руководство не понимает, что именно получит компания после дополнительных инвестиций.
Промышленный сценарий нужно обсуждать до пилота
Это не означает, что эксперимент следует сразу строить по всем требованиям продакшена. Такой подход сделает проверку гипотезы слишком дорогой и медленной. Но еще до начала работ нужно понимать, что произойдет в случае успеха.
Где будет размещена система? Какие интеграции обязательны? Кто примет ее на поддержку? Какие требования предъявят безопасность и эксплуатация? Из какого бюджета будет финансироваться развитие? Какие части прототипа можно сохранить, а какие заведомо придется заменить?
Пилот должен отвечать не только на вопрос «можно ли это сделать». Он должен показать, имеет ли смысл превращать идею в промышленный продукт и готова ли компания взять на себя последствия этого решения.
Перспективные ИТ-проекты редко погибают на демонстрации. Обычно они заканчиваются позже, когда аплодисменты уже стихли и выяснилось, что за красивым прототипом нет архитектуры, процесса и человека, который отвечает за результат.