Запровадження
За роки своєї роботи в галузі ІТ і особливо у продажах ІТ бачив багато пілотних проектів, але більшість із них закінчувалася нічим за значних витрат часу.
При цьому, якщо ми говоримо про тестування залізних рішень, як, наприклад, СГД, на кожну демо-систему зазвичай стоїть ще й черга на рік наперед. А кожне тестування у розкладі може принести продаж чи, навпаки, продаж запороть. Ситуацію, в якій тестування не впливає на продаж, розглядати не має сенсу, оскільки і тестування не має сенсу — це марна витрата часу та зайняття демо-системи.
Отже, як же зробити все за розумом і щоб усе трапилося?
Підготовка
Цілі пілота
З чого починається пілот? Не з підключення обладнання до стійки, зовсім немає. До початку будь-яких робіт із обладнанням триває робота з документами. І ми починаємо з визначення цілей пілота.
Мета пілота – усунення заперечення з боку кінцевого замовника. Немає заперечень – не потрібен пілот. Так Так саме так.
Але які основні класи заперечень ми можемо побачити?
* Ми сумніваємося в надійності
* Ми сумніваємося у продуктивності
* Ми сумніваємося в масштабованості
* Ми сумніваємося у сумісності та здатності працювати з нашими системами
* Ми не віримо у ваші слайди і хочемо переконатися на практиці, що ваша система все це справді вміє
* Це все буде дуже складно, наші інженери і так завантажені і їм буде важко
У підсумку ми отримуємо три основні види пілотного тестування і як окремий випадок пілота, доказ концепту (PoC – proof of concept):
* Навантажувальне тестування (+ масштабованість)
* Функціональне тестування
* Тестування відмовостійкості
У конкретному випадку, залежно від сумнівів конкретного замовника, в пілоті можуть поєднуватись різні цілі, або навпаки, бути тільки одна з них.
Пілот починається з документа, що описує російською мовою по білому – навіщо проводиться це тестування. Туди ж включається в обов'язковому порядку набір вимірних критеріїв, що дозволяють однозначно сказати - пілот успішно пройшов або що конкретно було не пройдено. Виміряні критерії бувають числовими (наприклад затримай в мс, IOPS) або бінарними (так/ні). Якщо у вашому пілоті є невимірювана величина як критерій – у пілоті немає сенсу, це виключно інструмент маніпуляцій.
Обладнання
Пілот може проводитись на демо-обладнанні вендора/дистриб'ютора/партнера або на обладнанні замовника. Строго кажучи, різниця невелика, загальний підхід той самий.
Головне питання щодо обладнання ДО початку пілота – чи повний комплект обладнання присутній (включаючи комутатори, кабелі передачі даних, кабелі живлення)? Чи готове обладнання до тестування (правильні версії прошивок, все на підтримці, всі зелені лампочки)?
Правильна послідовність дій після визначення цілей тестування – повна підготовка обладнання до тестування ДО передачі замовнику. Безумовно, є лояльні замовники без поспіху, але це скоріше виняток. Тобто. повний комплект має бути зібраний на майданчику партнера, все перевірено та зібрано. В обов'язковому порядку система повинна бути запущена і ви повинні переконатися, що все працює, програма розливається без помилок, і тд. Здавалося б, нічого складного, але три з чотирьох пілотів починаються з пошуку кабелів або трансіверів SFP.
Окремо слід наголосити, що в рамках перевірки демо-системи ви повинні переконатися в її чистоті. Усі дані попереднього тестування мають бути видалені із системи обов'язково перед передачею. Не виключено, що проходило тестування на реальних даних, а там може бути все, що завгодно, і комерційна таємниця та персональні дані.
Програма тестування
До передачі обладнання замовнику обов'язково повинна бути підготовлена програма тестування, що відповідає цілям тестування. Кожен тест повинен мати вимірний результат та чіткі критерії успіху.
Програма тестування може бути підготовлена вендором, партнером, замовником або спільно – але обов'язково до початку тестів. І обов'язково замовник повинен підписатися, що його задовольняє дана програма.
Люди
У рамках підготовки до пілоту необхідно погодити дати проведення пілота та присутність всіх необхідних осіб та їх готовність до тестування як з боку вендора/партнера, так і з боку замовника. О скільки пілотів починалося з відходу головної людини в пілоті у замовника у відпустку наступного дня після монтажу обладнання!
Сфери відповідальності/доступу
У програмі пілота мають бути чітко зрозумілі та в ідеалі описані сфери відповідальності всіх осіб, що беруть участь. При необхідності узгоджено віддалений або фізичний доступ інженерів вендора/партнера до систем та даних замовника зі службою безпеки замовника.
Пілот
Якщо ми виконали всі попередні пункти, то найнудніша частина – це пілот. Але він має йти як рейками. Якщо ні, то значить була запорота частина підготовки.
Завершення пілота
При завершенні пілота готується документ із проведеного тестування. В ідеалі з усіма тестами у програмі із зеленою галочкою ПРОЙДЕНО. Можлива підготовка презентації для вищого керівництва для прийняття позитивного рішення щодо купівлі або внесення до списку дозволених на закупівлю систем.
Якщо у вас на руках наприкінці пілота немає документа зі списком виконаних тестів та відмітками пройдено – пілот провалений і його не треба було починати взагалі.
Джерело: habr.com