Introducción
A lo largo de mis años de experiencia en el campo de TI, y particularmente en ventas de TI, he visto muchos proyectos piloto, pero la mayoría de ellos terminaba en nada, a pesar del considerable gasto de tiempo.
Sin embargo, cuando hablamos de pruebas de soluciones de hardware, como por ejemplo sistemas de almacenamiento, cada sistema de demostración suele tener una lista de espera de casi un año. Y cada prueba programada puede generar una venta o, por el contrario, arruinar una venta. No tiene sentido considerar una situación en la que las pruebas no influyen en la venta, ya que las pruebas tampoco tienen sentido: es una pérdida de tiempo y un uso indebido de los sistemas de demostración.
Entonces, ¿cómo hacer las cosas de manera inteligente y asegurarnos de que todo suceda?
Preparación
Objetivos del piloto
¿Por dónde comienza un piloto? No es conectando el equipo en el rack, para nada. Antes de cualquier trabajo con el equipo, se realiza un trabajo documental. Y comenzamos con la definición de los objetivos del piloto.
El objetivo del piloto es eliminar las objeciones por parte del cliente final. Si no hay objeciones, no se necesita un piloto. Sí, así de simple.
Pero, ¿cuáles son las principales clases de objeciones que podemos observar?
* Dudamos de la fiabilidad
* Dudamos del rendimiento
* Dudamos de la escalabilidad
* Dudamos de la compatibilidad y la capacidad de trabajar con nuestros sistemas
* No creemos en sus diapositivas y queremos asegurarnos en la práctica de que su sistema realmente puede hacer todo eso
* Todo esto será muy complicado, nuestros ingenieros ya están ocupados y les será difícil
En resumen, al final, obtenemos tres tipos principales de pruebas piloto y, como un caso particular del piloto, la prueba de concepto (PoC – proof of concept):
* Pruebas de carga (+ escalabilidad)
* Pruebas funcionales
* Pruebas de tolerancia a fallos
En un caso concreto, dependiendo de las dudas del cliente específico, en el piloto pueden combinarse diferentes objetivos o, por el contrario, puede haber solo uno de ellos.
El piloto comienza con un documento que describe en español, de manera clara y precisa, el propósito de esta prueba. También se incluye un conjunto de criterios medibles que permiten determinar sin lugar a dudas si el piloto fue exitoso o qué aspectos específicos no se lograron. Los criterios medibles pueden ser numéricos (como por ejemplo, la latencia en ms, IOPS) o binarios (sí/no). Si en su piloto hay un criterio que no se puede medir, el piloto no tiene sentido, es únicamente una herramienta de manipulación.
Hardware
El piloto puede llevarse a cabo en el equipo de demostración del vendedor / distribuidor / socio o en el equipo del cliente. Estrictamente hablando, la diferencia es mínima, el enfoque general es el mismo.
La pregunta principal sobre el equipo ANTES de comenzar el piloto es si se cuenta con el conjunto completo de equipo (incluyendo switches, cables de transmisión de datos, cables de alimentación). ¿Está el equipo listo para la prueba (versiones de firmware correctas, todo en soporte, todas las luces en verde)?
La secuencia correcta de acciones una vez que se han definido los objetivos de la prueba es la preparación completa del equipo para la prueba ANTES de su entrega al cliente. Sin duda, hay clientes leales que no tienen prisa, pero esto es más la excepción. Es decir, el conjunto completo debe estar ensamblado en el sitio del socio, todo debe ser verificado y ensamblado. La sistema debe estar en funcionamiento y debe asegurarse de que todo funcione correctamente, que el software se despliegue sin errores, etc. Aparentemente, no hay nada complicado, pero 3 de cada 4 pilotos comienzan buscando cables o transceptores SFP.
Es importante resaltar que dentro de la verificación del sistema de demostración, debe asegurarse de su limpieza. Todos los datos de pruebas anteriores deben ser eliminados del sistema antes de la entrega. No se puede descartar que se haya realizado una prueba con datos reales, y allí puede haber de todo, incluidos secretos comerciales y datos personales.
Programa de pruebas
Antes de entregar el equipo al cliente, es imprescindible que se haya preparado un programa de pruebas que responda a los objetivos de la prueba. Cada prueba debe tener un resultado medible y criterios claros de éxito.
El programa de pruebas puede ser preparado por el proveedor, un socio, el cliente o conjuntamente, pero debe hacerse ANTES de que comiencen las pruebas. Y el cliente debe firmar obligatoriamente que está satisfecho con este programa.
Personas
En la preparación para el piloto, es necesario acordar las fechas de realización y la presencia de todas las personas necesarias, así como su disposición para realizar las pruebas, tanto por parte del proveedor/socio como del cliente. ¡Cuántos pilotos han comenzado con la ausencia de la persona clave del cliente en vacaciones al día siguiente de la instalación del equipo!
Áreas de responsabilidad/acceso
El programa del piloto debe dejar claramente entendidas y, idealmente, describir las áreas de responsabilidad de todas las partes involucradas. Si es necesario, se debe acordar el acceso remoto o físico de los ingenieros del proveedor/socio a los sistemas y datos del cliente con el departamento de seguridad del cliente.
Piloto
Si hemos cumplido con todos los puntos anteriores, la parte más aburrida es el propio piloto. Pero debe desarrollarse sin contratiempos. Si no es así, significa que hubo un error en la preparación.
Finalización del piloto
Al finalizar el piloto, se prepara un documento sobre la prueba realizada. Idealmente, con todas las pruebas en el programa marcadas como completadas con un check verde. Puede prepararse una presentación para la alta dirección para tomar una decisión positiva respecto a la compra o la inclusión en la lista de sistemas autorizados para adquisición.
Si al final del piloto no tienes un documento con la lista de pruebas realizadas y las marcas de completado, el piloto ha fracasado y no debió iniciarse en absoluto.
Fuente: habr.com
