Un poco de historia
Hola mundo.
Como mucho de ustedes, hace algunos años (ya no son pocos) tenía el gran dilema de encontrar mi carrera profesional, la labor que haría todos los días de mi vida como profesional de TI.
Y es así como empecé a programar (recuerdo ASM, RM-Cobol 85, Fox Pro for Windows, e incluso hice algo de programación Java). De ahí mi carrera dio un giro inesperado, ya que no seguí programando, sino que ingresé a una compañía de venta al detalle (retail) en donde tenía la tarea de entregar equipos portátiles a usuarios finales (portables Toshiba eran de las mejores en esa época), para luego aprender a diagnosticar y reparar los equipos.
Después comencé a trabajar con servidores x86 y almacenamiento, haciendo las típicas labores asociadas a los servidores como creación/expansión de arreglos de discos, instalación de sistemas operativos, creación de redes (usando NetBEUI), y las configuraciones básicas de Directorio Activo, DNS, DHCP (desde Windows NT, Windows 2000 Server y así).
De ingeniero de soporte a ingeniero preventa
En ese momento yo hacía 2 cosas por fuerza de las circunstancias (no digo que lo hacía bien): tanto daba soporte como hacía la preventa. Acá haré una pausa, porque considero importante detallar cuál era mi definición de ingeniero preventa en ese momento. Se confundía fácilmente el rol de ingeniero preventa con el de jefe o gerente de producto.
Un jefe de producto debe saber los aspectos técnicos principales, comerciales, modelos de licenciamiento, esquemas de precios y descuentos, siempre alineado a SU producto. Un ingeniero preventa tiene un conocimiento similar al jefe de producto, quizás menos detalles comerciales, pero con mayor profundidad técnica y un enfoque más amplio, que permite conocer de diversas tecnologías, y encontrar la más beneficiosa integración con los productos o soluciones que el cliente ya posee.
Como ya lo mencioné, pasé de ser ingeniero de soporte (ingeniero implementador) a ingeniero preventa (coloquialmente suelo decir que me pasé al lado oscuro de la fuerza).
Usted que me lee, qué opina: ¿es más sencillo pasar de ingeniero de soporte a ingeniero preventa, o empezar como ingeniero preventa directamente?
Mi experiencia personal me dice que hay ciertas ventajas al tener experiencia de campo previa, puesto que te debería dar un bagaje importante al momento de buscar, armar y justificar soluciones... pero (y acá estoy siendo algo prejuicioso) es probable que no se tengan desarrolladas ciertas habilidades blandas (soft skills) críticas para este rol.
Para ilustrar este punto me permito introducir un aspecto que repito siempre que puedo, y considero muy importante en nuestro ámbito: habilidad para comunicar.
Una persona puede ser una lumbrera desde el punto de vista técnico, pero al mismo tiempo carecer de habilidades comunicativas. Este escenario es muy común en el mundo universitario: quién no ha tenido un profesor que sabe mucho de su materia, pero es pésimo explicando (seguro han escuchado la frase "El profesor sabe, pero no sabe explicar.").
Y aquí es donde empieza mi real transformación en ingeniero preventa. Yo carecía de habilidades comunicativas efectivas (y no lo sabía). A medida que trataba de explicar algún proyecto o solución, me topaba con clientes que tenían perfiles muy diversos como responsables de TI. Noté que en muchas ocasiones podíamos tener una solución muy robusta y costo/efectiva, pero no era capaz explicarla de manera efectiva.
Las habilidades de un ingeniero preventa
Algunas de las habilidades que considero debe tener (o cultivar) un ingeniero preventas son:- Saber comunicar
- Sabes escuchar
- Ser confiable
- Conocimiento general y específico
- Orientado al negocio
Saber comunicar
Habrán escuchado o leído una cita que se le atribuye autoría a Albert Einsten: "se deben explicar las cosas para que las entienda tu abuela"... pues puedo decir que es realmente necesario hacerlo así en el rol de preventa.
Basado en lo ya mencionado, es una de las primeras sugerencias que puedo hacer: desarrolla habilidades de comunicación efectivas. Tienes que hacerlo sencillo, fácil, digerible. Esto traerá un doble beneficio: por un lado, significa que vas a poder entregar el mensaje correcto de forma clara, y por otro vas a demostrar conocimiento.
Por ejemplo, si tienes una presentación de un proyecto, es tan importante conocer a la audiencia como el proyecto mismo; parte de saber comunicar es saber a quién le vas a hablar.
¿Cómo le explicas a tu hijo de 10 años cómo funciona la internet ? Volviendo al ejemplo de la abuela, ¿cómo se lo explicarías a una señora de 60 años? ¿Lo puedes hacer? ¿Harías la misma explicación?
En el mundo de TI es diferente el lenguaje que recepta un jefe de infraestructura, un responsable de redes/seguridad, un director de TI (CIO) o un Director Financiero (CFO). Y acá no hay nada mejor que la práctica, no en vano se dice que "la práctica hace al maestro". Cómo practicar? Veamos.
Uso de pizarra
Personalmente soy fanático del uso de la pizarra o tablero (blackboard) porque graficar esquemas o diagramas permite explicar de forma sencilla soluciones complejas o extensas. Además, hace que naturalmente la audiencia preste mayor atención ya que desde pequeños sabemos que normalmente quien está al frente parado en la pizarra sabe algo que me quiere enseñar.Muchos fabricantes en sus planes de capacitaciones incluyen sesiones técnicas para creación y manejo pizarra. Una técnica que aprendí y suelo usar es el manejo de los colores: marcador negro para los hechos ciertos, marcador azul para los hechos en los que haya dudas, marcador rojo para los problemas, y marcador verde para las soluciones.
Analogías/Parábolas
Es una herramienta absolutamente poderosa para hacer explicaciones complejas. El principio es simple: no le vas a enseñar o mostrar algo nuevo, sino que lo relacionas con algo que la persona ya conoce o sabe. Y la experiencia enseña que cuando las personas comprenden algo, lo hacen propio.Un ejemplo sencillo: intenta explicar lo del TV HD con hojas de cuadrículas (hojas cuadriculadas) vs hojas milimetradas (milimétricas). ¿Complejo?
Otro ejemplo más cercano al mundo de TI: ¿cómo explicas la impotancia del tamaño de bloques en una solución de almacenamiento? Prueba con autobuses de diferentes capacidades llevando un número N de persona de desde un sitio A hacía un sitio B.
Retroalimentación o Feedback
¡Listo! Has hecho una presentación impecable y usaste las analogías ideales. ¿Cómo sabes si el mensaje correcto llegó? ¿Cómo sabes si con el ejemplo de los autobuses se explicó el tema del tamaño de los bloques, o el cliente cree que vendes autos?Pues... haz la pregunta!
Y no necesariamente deben ser preguntas directas, sino más bien de preguntas cruzadas para validar o comprobar que el mensaje recibido es el correcto.
Y lo ideal es hacerlo durante la presentación y no al final, porque de esta forma si las respuesta no son correctas o al menos coherentes, podrás corregir o reforzar la idea erróneamente recibida. Hay que tener en cuenta que normalmente existen espacios de tiempo limitados, y se debe manejar los tiempos.
Dejaré hasta acá esta entrada del blog, por ahora. Espero continuar pronto con los demás temas.
Estaré muy agradecido escuchar y leer sus comentarios.
@RobertoUrgiles