Introduzione
Negli anni della mia esperienza nel settore IT, e in particolare nelle vendite IT, ho visto molti progetti pilota, ma la maggior parte di essi si è conclusa senza risultati concreti, a fronte di significativi investimenti di tempo.
Inoltre, se parliamo di testing di soluzioni hardware, come ad esempio i sistemi di archiviazione, per ogni sistema demo solitamente c'è una lista d'attesa che può arrivare a un anno. Ogni sessione di test nel programma può portare a una vendita o, al contrario, comprometterla. Discutere di una situazione in cui il test non influenzi la vendita non ha senso, perché anche il test perde di significato: è solo una perdita di tempo e occupa il sistema demo.
Quindi, come possiamo procedere in modo intelligente affinché tutto accada?
Preparazione
Obiettivi del pilota
Da dove inizia un pilota? Non dall'installazione dell'hardware nel rack, affatto. Prima di qualsiasi attività con l'hardware, si lavora con la documentazione. Cominciamo con la definizione degli obiettivi del pilota.
L'obiettivo del pilota è rimuovere le obiezioni da parte del cliente finale. Se non ci sono obiezioni, non è necessario un pilota. Esatto, proprio così.
Ma quali sono le principali categorie di obiezioni che possiamo riscontrare?
* Dubitiamo dell'affidabilità
* Dubitiamo delle prestazioni
* Abbiamo dei dubbi sulla scalabilità
* Abbiamo dei dubbi sulla compatibilità e sulla capacità di funzionare con i nostri sistemi
* Non crediamo nelle vostre presentazioni e vogliamo assicurarci nella pratica che il vostro sistema sia davvero capace di tutto questo
* Sarà molto difficile, i nostri ingegneri sono già occupati e avranno difficoltà
In definitiva, otteniamo tre principali tipi di testing pilota e, come caso particolare del pilota, la prova di concetto (PoC – proof of concept):
* Test di carico (+ scalabilità)
* Test funzionale
* Test di resilienza
Nel caso specifico, a seconda dei dubbi del cliente, nel pilota possono essere combinate diverse finalità o, al contrario, essere presenti solo una di esse.
Il pilota inizia con un documento che descrive chiaramente in lingua russa il motivo per cui viene condotto questo test. Questo include obbligatoriamente un insieme di criteri misurabili che consentono di stabilire senza dubbio se il pilota ha avuto successo o quali aspetti non sono stati superati. I criteri misurabili possono essere numerici (come ad esempio il ritardo in ms, IOPS) o binari (sì/no). Se nel tuo pilota è presente una misura non misurabile come criterio, il pilota non ha senso, è solo uno strumento di manipolazione.
Attrezzature
Il pilota può essere condotto su attrezzature demo del fornitore / distributore / partner oppure sull'attrezzatura del cliente. A rigor di logica, la differenza è piccola, l'approccio generale è lo stesso.
La principale domanda sull'attrezzatura PRIMA dell'inizio del pilota è: è presente un completo set di attrezzature (inclusi switch, cavi di trasmissione dati, cavi di alimentazione)? È l'attrezzatura pronta per il test (versioni firmware corrette, tutto in supporto, tutte le luci verdi)?
La sequenza corretta di azioni dopo aver definito gli obiettivi di test è la preparazione completa dell'attrezzatura per i test PRIMA della sua consegna al cliente. Certamente, ci sono clienti fedeli che non hanno fretta, ma questo è più un'eccezione. Ovvero, l'intero pacchetto deve essere assemblato presso il sito del partner, tutto deve essere controllato e montato. È obbligatorio che il sistema sia avviato e dovete assicurarvi che tutto funzioni, il software venga distribuito senza errori, ecc. Potrebbe sembrare niente di complicato, ma 3 piloti su 4 iniziano con la ricerca di cavi o trasmettitori SFP.
È importante sottolineare che, nell'ambito del controllo del sistema dimostrativo, dovete assicurarvi della sua pulizia. Tutti i dati di test precedenti devono essere eliminati dal sistema senza eccezioni prima della consegna. Non è escluso che siano stati testati dati reali, e lì potrebbe esserci di tutto, inclusi segreti commerciali e dati personali.
Programma di test
Prima della consegna dell'attrezzatura al cliente, deve essere preparato un programma di test che soddisfi gli obiettivi di collaudo. Ogni test deve avere un risultato misurabile e criteri di successo chiaramente definiti.
Il programma di test può essere preparato dal fornitore, dal partner, dal cliente o congiuntamente, ma deve essere completato PRIMA dell'inizio dei test. Inoltre, il cliente deve firmare per attestare che il programma lo soddisfa.
Persone
Nell'ambito della preparazione al pilota, è necessario concordare le date di esecuzione del pilota e la presenza di tutte le persone necessarie e la loro disponibilità al testing, sia da parte del fornitore/partner sia da parte del cliente. Ah, quanti piloti sono iniziati con l'uscita della persona chiave in ferie il giorno dopo l'installazione dell'attrezzatura!
Aree di responsabilità/accesso
Nel programma del pilota devono essere chiaramente definite e idealmente descritte le aree di responsabilità di tutte le persone coinvolte. Se necessario, deve essere concordato l'accesso remoto o fisico per gli ingegneri del fornitore/partner ai sistemi e ai dati del cliente con il servizio di sicurezza del cliente.
Pilota
Se abbiamo seguito tutti i punti precedenti, la parte più noiosa è il pilota stesso. Ma deve procedere come su binari. Se non è così, significa che una parte della preparazione è stata compromessa.
Conclusione del pilota
Alla conclusione del pilota, viene preparato un documento riguardante il test effettuato. Idealmente, con tutti i test nel programma contrassegnati con un segno di spunta VERIFICATO. È possibile preparare una presentazione per la direzione superiore al fine di prendere una decisione positiva riguardo all'acquisto o per includere nel elenco dei sistemi autorizzati per l'acquisto.
Se al termine del pilota non avete un documento con l'elenco dei test completati e i segni di verificato – il pilota è fallito e non doveva essere avviato affatto.
Fonte: habr.com
