introducción
A lo largo de los años de mi trabajo en el campo de TI y especialmente en las ventas de TI, he visto muchos proyectos piloto, pero la mayoría de ellos terminaron en nada y tomaron una cantidad significativa de tiempo.
Al mismo tiempo, si hablamos de probar soluciones hardware, como sistemas de almacenamiento, para cada sistema demo suele haber una lista de espera con casi un año de antelación. Y cada prueba programada puede generar una venta o, por el contrario, arruinarla. No tiene sentido considerar una situación en la que las pruebas no afecten las ventas, ya que las pruebas tampoco tienen sentido: es una pérdida de tiempo y una pérdida de tiempo para el sistema de demostración.
Entonces, ¿cómo puedes hacer todo sabiamente y hacer que todo suceda?
Formación
Los objetivos del piloto.
¿Por dónde empieza un piloto? No con la conexión de equipos a un rack, en absoluto. Antes de comenzar cualquier trabajo en el equipo, se realiza el trámite. Y empezamos por definir los objetivos del piloto.
El objetivo del piloto es eliminar objeciones del cliente final. No hay objeciones, no se necesita piloto. Sí Sí exactamente.
Pero ¿cuáles son las principales clases de objeciones que podemos ver?
* Dudamos de la fiabilidad.
*Tenemos dudas sobre el rendimiento
* Dudamos de la escalabilidad
*Tenemos dudas sobre la compatibilidad y capacidad de trabajar con nuestros sistemas.
* No creemos en sus diapositivas y queremos asegurarnos en la práctica de que su sistema realmente pueda hacer todo esto.
* Todo esto será muy difícil, nuestros ingenieros ya están ocupados y les será difícil
En total, al final obtenemos tres tipos principales de pruebas piloto y, como caso especial de piloto, prueba de concepto (PoC - prueba de concepto):
* Pruebas de carga (+ escalabilidad)
* Pruebas funcionales
* Pruebas de tolerancia a fallos
En un caso concreto, dependiendo de las dudas de un cliente en particular, el piloto puede combinar diferentes objetivos o, por el contrario, puede estar presente solo uno de ellos.
El piloto comienza con un documento que describe en ruso sencillo por qué se están llevando a cabo estas pruebas. También incluye necesariamente un conjunto de criterios mensurables que permiten decir sin ambigüedades si el piloto aprobó con éxito o qué específicamente no aprobó. Los criterios medibles pueden ser numéricos (como latencia en ms, IOPS) o binarios (sí/no). Si su piloto tiene un valor inmensurable como criterio, no tiene sentido el piloto, es puramente una herramienta de manipulación.
Equipo
El piloto se puede realizar en equipos de demostración del proveedor/distribuidor/socio o en equipos del cliente. Estrictamente hablando, la diferencia es pequeña, el enfoque general es el mismo.
La pregunta principal con respecto al equipo ANTES de que comience el piloto es si está presente el conjunto completo de equipos (incluidos interruptores, cables de datos y cables de alimentación). ¿Está el equipo listo para realizar pruebas (versiones de firmware correctas, todo es compatible, todas las luces están en verde)?
La secuencia correcta de acciones después de determinar los objetivos de la prueba es preparar completamente el equipo para la prueba ANTES de entregarlo al cliente. Por supuesto, hay clientes fieles sin prisas, pero esta es más bien una excepción. Aquellos. el conjunto completo debe ser ensamblado en las instalaciones del socio, todo revisado y ensamblado. El sistema debe estar funcionando y debes asegurarte de que todo funciona, el software se distribuye sin errores, etc. No parece nada complicado, pero 3 de cada 4 pilotos empiezan buscando cables o transceptores SFP.
Por otra parte, cabe destacar que, como parte de la comprobación del sistema de demostración, es necesario asegurarse de que esté limpio. Todos los datos de pruebas anteriores deben eliminarse del sistema antes de la transferencia. Es posible que las pruebas se hayan realizado con datos reales y que pueda haber cualquier cosa allí, incluidos secretos comerciales y datos personales.
programa de pruebas
Antes de transferir el equipo al cliente, se debe preparar un programa de pruebas que cumpla con los objetivos de las pruebas. Cada prueba debe tener un resultado mensurable y criterios claros de éxito.
El programa de pruebas puede ser preparado por el proveedor, el socio, el cliente o conjuntamente, pero siempre ANTES del inicio de las pruebas. Y el cliente debe firmar que está satisfecho con este programa.
personas
Como parte de la preparación para el piloto, es necesario acordar las fechas del piloto y la presencia de todas las personas necesarias y su preparación para las pruebas, tanto por parte del proveedor/socio como por parte del cliente. ¡Oh, cuántos pilotos comenzaron con la persona principal del piloto del cliente yendo de vacaciones al día siguiente de la instalación del equipo!
Áreas de responsabilidad/acceso
El programa piloto debe comprender claramente e idealmente describir las responsabilidades de todos los individuos involucrados. Si es necesario, el acceso remoto o físico de los ingenieros del proveedor/socio a los sistemas y datos del cliente se ha coordinado con el servicio de seguridad del cliente.
Piloto
Si hemos completado todos los puntos anteriores, entonces la parte más aburrida es la del propio piloto. Pero debe funcionar como sobre raíles. Si no, entonces parte de la preparación se estropeó.
Finalización del piloto
Al finalizar el piloto, se elabora un documento sobre las pruebas realizadas. Lo ideal es que todas las pruebas del programa tengan una marca de verificación verde PASA. Es posible preparar una presentación para que la alta dirección tome una decisión positiva sobre la compra o inclusión en la lista de sistemas aprobados para su compra.
Si no tienes un documento en tus manos al final del piloto con una lista de las pruebas completadas y las calificaciones aprobadas, el piloto está reprobado y no debería haberse iniciado en absoluto.
Fuente: habr.com