Ser consultor

Imagen sacada de un proyecto de TI real

Ser un buen consultor es difícil, yo lo veo como un arquitecto, que recibe los requisitos del cliente, le da ideas para mejorar sus procesos, dice al cliente lo que no se puede hacer, hace un proyecto con el resultado que se va a implementar, sigue y audita que se está implementando según especificaciones y finalmente presenta al cliente el resultado explicándole y guiándole con la funcionalidad de su obra. Y le da un período de garantía, claro. Esto en un proyecto de implantación.

Cómo no ponga un pilar ahí esto se cae. ¿Y si en vez de hormigón uso corchopán?

En un mantenimiento lo veo más como un controlador aéreo. Priorizando tareas, evolutivos e incidencias, sabiendo donde están en cada momento y donde deben terminar.

Viene una incidencia urgente, pista 1 despejada. Manolo calienta que sales.

Aunque hay mucho «consultor» que realmente es más bien un obrero que un consultor, solamente ejecuta lo que el cliente exige, sin aportar nada ni rebatir ideas locas.

¡Menudo chorrazo de código estoy echando!

Según la RAE, consultor se define como:

Que atiende consultas y asesora sobre una materia específica, sobre todo de forma profesional.

Real Academia Española

Por lo tanto, un consultor de TI debería ser un asesor, una guía para la transformación digital de procesos y operaciones empresariales. No un simple «ejecutor» de órdenes.

Yo, a mi lado, quiero gente que tenga opinión, que sepa discutir acerca de la mejor solución o que sepa que alguna idea es una locura (pero de eso no hay, ¿no? 😜)

El problema, muchas veces, parte del cliente. Que no valora nada más que el precio y/o tiempo de un proyecto (¿os suena lo de retroplanificar un proyecto?). Cuando lo que debería primar sería el ratio entre tiempo/coste/calidad/funcionalidad. Y en cuanto a calidad un proyecto debe contar con estimación de tiempo y esfuerzo en cada una de las fases, y gastar el tiempo necesario en ellas. A saber:

  • Análisis de los requerimientos y aceptación por las partes
  • Diseño de la solución y aceptación
  • Hito de Kick off de la implementación
  • Desarrollo de la solución
  • ¿Habrá entregas parciales? Se marcarán los hitos repitiendo en cada hito los siguientes pasos.
  • ¿Hay integraciones con otros sistemas? Si es así es necesario un plan de pruebas integradas
  • Formación a key users
  • Pruebas de usuario
  • Go Live (subida a producción y acceso de los usuarios) Aquí no termina el proyecto
  • Monitorizacion de sistema y usuarios
  • Soporte continuo a usuarios y procesos
  • Periodo de garantía

Por supuesto esto es una lista básica con lo imprescindible para un proyecto TI clásico. Ya si hablamos de Agile, Sprints, Gestión del cambio, Análisis de riesgos y Planes de contingencia, etc. la cosa se complica.

La norma ISO666 de los proyectos

Pero lo que quería ejemplarizar con el gif inicial es que un proyecto sin la formación y soporte a los usuarios, dará como resultado resistencias, mal uso y frustración. Y que algún usuario diga la frase:

¡Yo tenía un Excel que hacía más cosas!

Por ultimo no podía dejar pasar la ocasión para meter el video de Pantomima Full acerca del consultor. Yo nunca he sido así, y mi entorno no es así, pero he visto este tipo de fauna pululando por las oficinas y los clientes. Obviamente esto es una exageración (¿o no?😜).