Краткое руководство по проведению пилотов и PoC

Введение

За годы своей работы в области ИТ и в особенности в продажах ИТ видел много пилотных проектов, но большинство из них оканчивалось ничем при значительных расходах времени.

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

Итак, как же сделать все по уму и чтобы все случилось?

Подготовка

Цели пилота

С чего начинается пилот? Не с подключения оборудования в стойку, совсем нет. До начала любых работ с оборудованием идет работа с документами. И мы начинаем с определения целей пилота.
Цель пилота — устранение возражения со стороны конечного заказчика. Нет возражений — не нужен пилот. Да-да, именно так.
Но какие же основные классы возражений мы можем увидеть?
* Мы сомневаемся в надежности
* Мы сомневаемся в производительности
* Мы сомневаемся в масштабируемости
* Мы сомневаемся в совместимости и способности работать с нашими системами
* Мы не верим в ваши слайды и хотим убедиться на практике, что ваша система все это действительно умеет
* Это все будет очень сложно, наши инженеры и так загружены и им будет тяжело

Итого, в конечном итоге мы получаем три основных вида пилотного тестирования и как частный случай пилота, доказательство концепта (PoC – proof of concept):
* Нагрузочное тестирование (+ масштабируемость)
* Функциональное тестирование
* Тестирование отказоустойчивости

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

Пилот начинается с документа, описывающего русским языком по белому – зачем проводится данное тестирование. Туда же включается в обязательном порядке набор измеримых критериев, позволяющих однозначно сказать – прошел пилот успешно или что конкретно было не пройдено. Измеримые критерии бывают числовыми (как например задержи в мс, IOPS) или бинарными (да/нет). Если в вашем пилоте присутствует неизмеряемая величина в качестве критерия – в пилоте нет смысла, это исключительно инструмент манипуляций.

Оборудование

Пилот может проводиться на демо-оборудовании вендора / дистрибьютора / партнера или на оборудовании заказчика. Строго говоря, разница небольшая, общий подход один и тот же.

Главный вопрос по оборудованию ДО начала пилота – полный ли комплект оборудования присутствует (включая коммутаторы, кабели передачи данных, кабели питания)? Готово ли оборудование к тестированию (правильные версии прошивок, все на поддержке, все лампочки зеленые)?

Правильная последовательность действий после определения целей тестирования – полная подготовка оборудования к тестированию ДО его передачи заказчику. Безусловно, есть лояльные заказчики без спешки, но это скорее исключение. Т.е. полный комплект должен быть собран на площадке партнера, все проверено и собрано. В обязательном порядке система должна быть запущена и вы должны убедиться, что все работает, софт разливается без ошибок, и тд. Казалось бы, ничего сложного, но 3 из 4 пилотов начинаются с поиска кабелей или трансиверов SFP.
Отдельно нужно подчеркнуть, что в рамках проверки демо-системы вы должны убедиться в ее чистоте. Все данные предыдущего тестирования должны быть удалены с системы в обязательном порядке перед передачей. Не исключено, что проходило тестирование на реальных данных, а там может быть все что угодно, и коммерческая тайна и персональные данные.

Программа тестирования

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

Люди

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

Сферы ответственности / доступа

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

Пилот

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

Завершение пилота

При завершении пилота готовится документ по проведенному тестированию. В идеале со всеми тестами в программе с зеленой галочкой ПРОЙДЕНО. Возможна подготовка презентации для высшего руководства для принятия положительного решения о покупке или внесению в список разрешенных к закупке систем.
Если у вас на руках в конце пилота нет документа со списком выполненных тестов и отметками пройдено – пилот провален и его не надо было начинать вообще.

Источник: habr.com