ЭКПЕРТ PRO // испытания

ХОРОШИЙ РЕЗУЛЬТАТ ИСПЫТАНИЙ – ЭТО НЕ ВСЕГДА «ВСЕ РАБОТАЕТ»

Почему так – рассказывает Андрей Терлеев, руководитель практики координации технологических инициатив «Газпром нефти».

Раньше я довольно просто смотрел на испытания. Есть технология, есть требования, решение проверили – дальше, казалось бы, два варианта: прошло или не прошло. Почти как экзамен.

Сейчас я отвечаю за координацию испытаний и апробаций ИТ-решений в «Газпром нефти». Мы выстраиваем процесс проверки новых технологий для задач всей компании, за последние несколько лет мой взгляд на испытания довольно сильно изменился.

Например, мне все меньше нравится вопрос : «Ну что, решение прошло испытания? ». Не из-за того, что на него сложно ответить. Просто, на мой взгляд, сам вопрос слишком сильно упрощает то, ради чего испытания вообще проводятся.

Когда я был по другую сторону испытательного стенда

До «Газпром нефти» я занимался собственным технологическим стартапом. Мы хотели создать оператора сети интернета вещей – инфраструктуру, через которую различные умные устройства могли бы передавать данные. И, конечно, хотели работать с крупными промышленными компаниями, в том числе с такими, как «Газпром нефть».

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

А потом заказчик говорит: «Хорошо. Давайте тестировать».

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

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

«Работает ли решение?»

– не совсем правильный вопрос .

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

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

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

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

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

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

Сначала нужно понять, на какой вопрос мы хотим получить ответ:

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

То есть мы проверяем не абстрактное «хорошее это решение или плохое». Мы проверяем гипотезу его применения для конкретной задачи.

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

• Технопарк корпоративных ИТ занимается ИТ-решениями: серверами, системами хранения данных, сетевым оборудованием, виртуализацией, системным и прикладным ПО, персональной техникой.

• В блоке логистики, переработки и сбыта уже более 10 лет существует Технопарк промышленной автоматизации, благодаря которому различные контрольно-измерительные приборы и системы управления проходят испытания не только на специализированных стендах, но и на технологических позициях.

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

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

И возможных результатов становится явно больше двух.

Не только «да» и «нет»

Самый простой вариант – требования подтверждены, критичные сценарии отработаны, существенных ограничений не выявлено. Отлично, можно двигаться дальше.

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

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

Здесь даже статистика довольно показательная:

В 2024 году в Технопарке корпоративных ИТ из 249 апробированных решений 73 соответствовали функционально-техническим требованиям, 143 соответствовали с замечаниями и 33 не соответствовали.

То есть «работает, но...» – это не редкое исключение и не попытка красиво сформулировать отрицательный результат. В реальной практике это вообще самый распространенный вариант.

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

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

Плохую новость лучше узнать раньше

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

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

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

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

По отдельности все работает. А вместе?

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

Не всегда.

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

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

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

Так что же такое хороший результат?

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

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

Иногда это решение – «да». Иногда – «да, но при таких условиях». Бывает, что сначала нужно что -то доработать. Бывает и «нет, дальше не идем».

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

Поэтому, когда меня спрашивают: «Испытания прошли успешно?», мне хочется сначала уточнить: мы получили ответ на вопрос, ради которого их начинали?

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