A lo largo de los últimos meses he aceptado muchos proyectos. Todos los proyectos estimados según la forma de hacer de cada empresa y según sus necesidades. No importa. Pero, ¿qué sucede cuando una empresa solicita una tecnología nueva, en la que no tiene experiencia y necesitan aprender?
Es curioso que siendo el sector en el que más rápidamente cambian las cosas, la inercia de los negocios nos siga llevando a intentar conservar lo que funciona y mantenerlo. No se adapta. No se cambia.
Voy a analizar algunos factores que llevan a que la empresa se comporte normalmente de esta forma.
Bootstrapping
Cada empresa que nace lo hace sin nada. Por así decirlo. Tiene la aportación de capital inicial de los socios, gente para trabajar, pero no hay nada hecho. Normalmente suele ser el caso más normal. Aún teniendo capital, solo tendrías más gente para comenzar a construir algo, pero no tendrías nada de momento.
El inicio se construye con las modas. Los responsables de las empresas tendrán una idea en mente, revisarán la competencia, los comentarios de profesionales del sector y lo más usado. Finalmente irán a emplear o algo mainstream que les permita encontrar gente y ayuda de forma muy fácil, o algo disruptivo que les permita salirse del un poco del grupo y crearse una identidad.
La facilidad de tener una tecnología que todos conocen, economiza y facilita encontrar gente experta en esa tecnología. Encontrar foros de ayuda y comunidades de cientos o miles de usuarios y en varios idiomas.
Emplear una tecnología disruptiva de poca adopción o propia dificulta el inicio, encontrar gente o incluso ayuda para el desarrollo de la misma.
Eligiendo una opción u otra debemos de construir desde cero nuestro sistema. Quizás tomando algo de software libre para ayudar a generar un entorno de trabajo, las liberías de base, servidores, bases de datos, sistemas de control de versiones y así un largo etcétera.
Construir el entorno de trabajo, de pruebas y poner nuestro sistema en producción conlleva un esfuerzo considerable. Una vez construido la empresa suele tomarlo como la construcción de un edificio. Lo mantiene, pero se intenta no cambiar ni modificar nada de la estructura.
Malos Cimientos
Una vez industrializado el sistema IT, realizar cambios de base es complejo o casi imposible. Los programadores comienzan a escribir código para llegar a donde el sistema base no llega y para escribir lo necesario y obtener el producto a explotar.
El problema de una empresa que ha optado por personal barato y tecnologías ampliamente difundidas es que seguramente no haya ningún senior en el equipo. En unos años el sistema comienza a tener fallos y cada subida a producción resulta una cadena de problemas y errores que ven cada vez más los clientes.
Algunos puntos para detectar si se ha comenzado con mal pie:
-
No se emplea un sistema de control de versiones. O se emplea como copia de seguridad en lugar de como versiones de desarrollo, pruebas y producción.
-
Los programadores tienen acceso a los servidores de producción y emplean editores como Vi, emacs, nano, ... Muchos de estos cambios se sobreescriben al subir código nuevo y vuelta a empezar.
-
No hay versiones de código. El código se programa y cuando ya se ha hecho un cambio simple va a producción directamente.
-
No hay pruebas automáticas. Los programadores consideran que probar a mano (más de 1000 posibles casos de uso que pueden existir en el software creado) es más rápido que programar cada test en el momento que se solicita una funcionalidad y reutilizar este test en cada cambio que vaya a ir a producción.
-
No hay compilación o generación del paquete automatizada. No emplean herramientas de construcción, gestión de dependencias o comprobación básica del código.
-
No existen paquetes. El código que va a ponerse en producción no se empaqueta en un servidor de construcción para después ser subido y puesto en producción de forma rápida sino que se compila y se hace todo el proceso de construcción dentro del servidor de producción.
-
No existe documentación. No hay documentación sobre lo que se ha desarrollado, ni lista de cambios entre subidas a producción, ni generación automática de documentación del código que se emplea, ni diagramas, ... está solo el código.
Normalmente, cuando una empresa decide optar por un enfoque disruptivo, se encarga de buscar a profesionales que le permitan tener un mínimo de calidad.
¿Qué sería lo lógico?
No hay mayor constante que el cambio. Al crear el entorno IT de una empresa debemos de mantener el flujo de aprendizaje que nos ha llevado a construir ese entorno y dedicar esfuerzos en mantener un constante aprendizaje y adaptación a nuevas versiones, nuevas técnicas, nuevas tecnologías. El estudio y realizar pruebas es lo que conduce hoy en día a empresas como Facebook o Google a ser quienes son y estar donde están.
Hay empresas que contratan asesores tecnológicos para ayudarles en ciertos aspectos. Normalmente esto se hace cuando ya es demasiado tarde y hay que entregar algo basado en una tecnología, versión o framework en el que no se tienen muchos conocimientos. Esto debería de ser al revés. El asesor debería de ser contratado como mentor para enseñar a nuestro equipo de personas.
Es muy sano contactar e incluso contratar empresas que han trabajando con tecnologías en las que estás interesado/a o profesionales que saben adaptarse al aprendizaje continuo para servir de mentores en procesos de cambio acelerados.
Sea como fuere, la gestión del cambio debe de tenerse en cuenta. Cada cierto tiempo debería de estar en el orden de trabajo adaptar los sistemas a una nueva versión del framework que se usa para trabajar. Probar un nuevo control de versiones si puede suponer una mejora. Montar una maqueta del sistema de producción y cambiar algún servidor.
Incluso participar en el desarrollo de esas tecnologías que se emplean para mantenerse actualizado. Aportar todo el código posible al software libre y emplear en lo máximo posible todo lo que se pueda de software libre facilita una rápida evolución, mejora al descubrir antes los errores e incluso obtener ayuda para resolverlos.
Conclusiones
Bootstrapping es un término empleado de muchas formas pero yo he querido resaltar el hecho de comenzar algo desde cero. Las empresas comienzan de forma fuerte, se estancan y en ese período de estancamiento, para salir del punto deben invertir más de lo que hubiese sido necesario en caso de llevar una política de gestión de cambios en IT.
Considero que las mejores empresas son las que mantienen ese período de innovación y creación inicial. Siguen creando y siguen adaptándose. Para conseguir esto se rodean de los mejores profesionales.
¿Has pensado en mejorar y evolucionar el software que desarrollas en tu empresa desde hace años? ¿Ya lo haces? ¿Necesitas ayuda para conseguir estos cambios? ¿Crees que sería imposible?
