Una de las cosas que me encanta de participar y hacer “comunidad técnica” es tener la posibilidad de enriquecerte compartiendo experiencias y puntos de vista con multitud de personas, de diferentes sectores, tamaños de empresa, partners y clientes.
Sin embargo, me resulta llamativo y contemplo con cierto escepticismo y estupor (e incluso lástima), cómo hay empresas que carecen por completo de una estrategia tecnológica. Y lo peor de todo, es que en muchos casos se trata de “Consultoras tecnológicas” (WTF!!??).
Ciertamente es complicado estar siempre “en la cresta de la ola” tecnológica, hablar de un mercado dinámico es faltar a la realidad (y si te mueves en el “universo Microsoft” más), de hecho, mientras escribo estas breves líneas se estarán liberando “features” nuevas de Dynamics 365, Office 365, Azure, etc.
En ocasiones creo que justamente es esto lo que abruma a algunas empresas, que ven cómo siempre llegan tarde al tren y terminan buscando cobijo dentro de su estable zona de confort, mientras ven por la ventana que el ojo del huracán está cada minuto más cerca. Me gusta llamarlo “procrastinación tecnológica”.
Si has leído hasta aquí, asintiendo consciente o inconscientemente, ¡¡enhorabuena!! Creo que es una buena señal. Si no es así, te invito a que saltes directamente a la nota final.
Voy a pasar de la generalidad y a centrar mi ejemplificación dentro del mundo de Dynamics 365 Business Central (lo sé, lo estabas esperando 😊)
Ventajas que se tornaron pesadillas
Desde tiempos ancestrales Navision/Attain/NAV (NAV en adelante) ha sido para la inmensa mayoría una plataforma de desarrollo, al tiempo que se incorporaban funcionalidades que ayudaban a gestionar la empresa.
Es cierto que con relativamente poco esfuerzo se podían obtener resultados casi inmediatos, pero claro… como decía el tío de Spiderman: “todo gran poder, conlleva una gran responsabilidad”, y con el paso de los años, se daba el caso de que existían más objetos modificados que sin modificar en nuestra BBDD.
Claro, una de las grandes ventajas del producto se llegó a convertir en el peor de los lastres en los tiempos actuales, donde cuesta concebir cómo una actualización (o migración) de versión se convierte en una inversión similar a la inicial (o lo suficientemente elevada).
Pero desde mi punto de vista, la ventaja más grande es la que se ha convertido en la peor de las pesadillas imaginables: la rapidez y simplicidad.
La explicación es muy fácil, en nuestra naturaleza está el invertir el mínimo de energía posible para llegar a un fin, y al final esto es un “caldo de cultivo de malas prácticas”. Si a esto sumamos que la inmensa mayoría de empresas implantadoras son pequeñas, donde el volumen de proyectos es medio o alto, y los recursos limitados… llegamos a la siguiente ley de la identidad, donde “Consultor NAV = Juan Palomo” (el mismo de “yo me lo guiso y yo me lo como”).
Un ejemplo rápido: imagina que eres consultor/a (o algo muy común en este sector, eras developer y llegado el momento te reconvertiste a consultor/a). Estás llevando a cabo la implantación de un proyecto sencillo. Haces la toma de requerimientos (un clásico), sin demasiado detalle y el cliente lo valida. Llega la hora de empezar: ¿haces un documento de diseño técnico? – No, para qué, tengo claro lo que hay que hacer y no me lo voy a redactar a mí mismo.
¿haces pruebas unitarias? (suponiendo que sabes lo que es) – Pues no, vamos justos de tiempo, hay que facturar ya. Mejor aún, lo ponemos en producción, probamos en casa del cliente… y sobre la marcha ya ajustamos “en caliente”.
¿has guardado un registro de esto? – Claro, dentro del código del objeto he puesto mis iniciales y la fecha (bien, bien… vamos bien).
Objetivo cumplido: compila, ergo se puede facturar… si algo da la cara, ya ajustamos (total, me tocará hacerlo a mí, es mi proyecto).
Bien, ahora te pregunto, ¿qué crees que ocurre cuando una persona lleva trabajando así 5, 10, 15 o 20 años?
Se trata de un hábito, y somos animales de costumbres. Esto forma parte de la zona de confort a la que referenciaba al inicio del texto. Pero no te preocupes, siempre hay tiempo para cambiar.
Tu esto lo sabes ya, es decir, Microsoft lleva anunciando el cambio de modelo desde NAV 2016, cuando se lanzaron las extensiones v1. Bueno, mucho antes, cuando se comenzaban a promover buenas prácticas con “código limpio” y patrones de desarrollo menos invasivos.
Pero claro, es que no hay tiempo, hay que seguir facturando, los clientes deben atenderse, hay que hacer cambios (en producción probablemente) … resumiendo “procrastinación tecnológica”.
En paralelo, el mundo sigue, los cambios ocurren, el producto ya se ha transformado… y ya lo que hacías sencillamente no sirve.
El maravilloso mundo de los ISVs y/o Consultoras de referencia
¿Te parece alarmante lo que has leído? Si es así es porque lo has vivido, en tu piel o en la del vecino. Tranqui, esto no era nada con lo que ocurre con los ISVs y los partners de una cierta dimensión.
En el sector tecnológico siempre faltan profesionales, y particularmente cuando hablamos de especialistas en Soluciones empresariales, mucho más.
Volviendo al ejemplo anterior de nuestro Juan Palomo (en la actualidad «Senior Consultant & Project Manager»), ya con una cierta experiencia apetece un cambio de aires, y decides dar el salto a un proyecto mayor (ley de la oferta y la demanda).
¿Qué piensas que ocurre cuando pones a liderar equipos y a gestionar tus productos a personas de este perfil?
Básicamente lo esperado, hacemos lo que sabemos hacer, y nuestros juniors empiezan a adquirir muchos de estos malos hábitos.
En mis años de experiencia, una de las cosas que me ha tocado hacer es auditar implantaciones existentes, lógicamente todas con personalizaciones. Pero lo más sangrante siempre es cuando ves “personalizaciones sobre una solución vertical” (y de nuevo… WTF!!??)
¿Y que es esto? Muy sencillo: el ISV ha desarrollado una solución basada en NAV, más o menos integrada en el estándar. Idealmente lo que tiene es un producto (en diferentes versiones probablemente), pero estandarizado, de modo que se parametriza para la implantación de cada cliente.
Pero la triste realidad es otra, ocurre que cuando se lleva a cabo la implantación, a veces por desconocimiento de la propia solución (sí, esto pasa, aunque no lo creas), a veces porque no se han mapeado las expectativas del cliente con nuestro plan de proyecto… se hacen personalizaciones para cubrir algunas funcionalidades, que justamente para este cliente son imprescindibles. Bueno, ya sabemos que hay que facturar, que al final lo que cuenta es tener al cliente contento y todo esto.
¿Cuál es el resultado final de esto? Como ya intuías, si tienes “n” implantaciones de tu solución vertical, tienes “n” versiones diferentes que mantener. Insostenible.
Metodología y estrategia tecnológica
Hasta ahora, bien poco hemos hablado de estrategia tecnológica, más bien se trata de un problema de metodología. Pero ¿no crees que deberían ir de la mano?
En mi humilde opinión, la estrategia tecnológica no sólo se debe circunscribir a qué tecnología usamos o dónde pondremos foco de cara a nuestros proyectos de innovación o investigación. Los cambios de tecnología vienen acompasados de cambios en los paradigmas de trabajo, de desarrollo, de implantación, de brindar soporte… y por supuesto, de venta y preventa.
Hablamos por tanto de que la estrategia tecnológica es y debe ser transversal al plan estratégico de la compañía, independientemente del sector o del tamaño.
Así que: Querid@ amig@, si está en tu mano, piénsatelo 2 veces antes de nombrar a Juan Palomo CTO (o cargo similar) en tu empresa. Será cierto que nuestro amigo ya luce el pelo cano, tras años batallando y luchando por la compañía, se lo merece, pero primero debes verificar que tiene claro todo lo anterior. Es decir, debe ser capaz de levantar la vista y mirar adelante, poniendo algo de distancia con el día a día.
Claro, mucho más importante es que como CEO, tengas meridianamente claro que la estrategia tecnológica es fundamental.
Mis recomendaciones
Acabaré como he empezado, hablando del importante rol que juega la comunidad técnica. Debemos perder el miedo a compartir experiencias con el resto de empresas, por muy competidores que sean.
Resumiendo:
- Mantén una visión lo más global e independiente posible. El mundo de las soluciones monolíticas acabó.
- Participa en eventos de comunidad (encuentros de grupos de usuarios, Saturdays, partner days, Directions, Business Applications Summit, …
- No te escudes en la falta de tiempo, ni en la cantidad de esfuerzo que supondrá cambiar el rumbo. NO PROCRASTINES.
- Recuerda que nunca es tarde para cambiar o rectificar el rumbo, pero debe planificarse y trasladarse a una estrategia, que además sea respaldada por la dirección de la empresa.
Nota final
Asegúrate de que esta visión es compartida entre la dirección de la empresa y la dirección tecnológica. Si no es así, cambia de empresa.
Si eres el CEO y no lo compartes, siento decirte que tu empresa sobrevivirá lo que le permita la inercia y la renta pasada.