En este guía, Jesús Arboleya, Responsable de Producto de Velneo, nos relata en primera persona su experiencia como analista-programador. Hemos añadido algunas actualizaciones a su testimonio para adaptar el contenido a las nuevas metodologías Low-Code.
La profesión de analista-programador se ha consolidado como una opción atractiva en el mundo laboral actual. Los profesionales en este campo disfrutan de una alta demanda del mercado, oportunidades de crecimiento y salarios competitivos. Además, la flexibilidad laboral, la capacidad de trabajar en diversas industrias y el potencial de impacto en la sociedad convierten a esta carrera en una opción prometedora.
Sin embargo, también es esencial considerar los desafíos y exigencias que puede presentar el rol. En este artículo, exploraremos las ventajas y desafíos de ser un analista-programador en el panorama actual, abordando temas como la demanda del mercado, el equilibrio entre la vida laboral y personal, y las perspectivas de crecimiento profesional.
Introducción: la figura del analista programador en 2023
La carrera de analista-programador ofrece múltiples ventajas, como alta demanda laboral, salarios atractivos y un gran impacto social. A pesar de los desafíos inherentes, como el estrés y la necesidad de actualización constante, esta profesión brinda oportunidades gratificantes y un sólido futuro.
Exploraremos en detalle estos aspectos clave y cómo impactan en la experiencia de los analistas-programadores en el mundo actual.
La profesión del analista-programador es una buena profesión actualmente y ofrece varias ventajas:
Demanda del mercado
La demanda de profesionales de TI, incluidos los analistas-programadores, sigue siendo alta en todo el mundo. Las empresas continúan invirtiendo en tecnología y digitalización, lo que aumenta la necesidad de expertos en desarrollo de software.
Oportunidades de crecimiento
La industria de la tecnología está en constante evolución y ofrece oportunidades de crecimiento profesional y aprendizaje continuo. Un analista-programador puede especializarse en diferentes áreas, como desarrollo web, móvil, inteligencia artificial, big data, etc.
Remuneración competitiva
Los analistas-programadores suelen recibir salarios competitivos en comparación con otras profesiones. La remuneración puede variar según la experiencia, la ubicación y el sector, pero en general, los profesionales de TI suelen estar bien remunerados.
Flexibilidad laboral
Muchos analistas-programadores tienen la oportunidad de trabajar de forma remota o adoptar horarios flexibles, lo que puede mejorar el equilibrio entre la vida laboral y personal.
Creatividad y resolución de problemas
Ser un analista-programador implica resolver problemas y encontrar soluciones creativas para desafíos tecnológicos. Esto puede ser gratificante y mantener el interés en el trabajo a lo largo del tiempo.
Diversidad de industrias
Los analistas-programadores pueden trabajar en una amplia gama de industrias, desde tecnología de la información, servicios financieros, salud, educación hasta el sector público. Esto permite a los profesionales explorar diferentes campos y encontrar oportunidades que se ajusten a sus intereses y habilidades.
Impacto en la sociedad
El trabajo de un analista-programador puede tener un impacto significativo en la sociedad, ya que las soluciones de software que desarrollan pueden mejorar la vida de las personas, aumentar la eficiencia en las empresas y contribuir a la innovación en diversos campos.
Sin embargo, también es importante tener en cuenta que ser un analista-programador puede ser un trabajo exigente y en ocasiones estresante. Los plazos ajustados, la necesidad de mantenerse al día con las tecnologías en constante evolución y las largas horas de trabajo pueden ser desafiantes.
En general, ser un analista-programador es una buena profesión en el panorama actual, ya que ofrece una demanda estable, oportunidades de crecimiento, remuneración competitiva y la posibilidad de causar un impacto positivo. No obstante, es esencial evaluar si las características y desafíos de esta profesión.
No es algo nuevo, ya estaba aquí cuando yo llegué
Después de casi 40 años de profesión todavía no he encontrado a ningún compañero que me haya dicho que comenzó en la informática con el rol de analista. Sin embargo, el 100% entre los que me incluyo comenzamos disfrutando de largas sesiones de programación en uno u otro lenguaje y sistema operativo.
Llevo mucho tiempo comentando con otros programadores de mi edad que cada vez que hablo con programadores jóvenes tengo la sensación de que solo quieren trabajar en desarrollo de la interfaz, el front-end, y es rarísimo que a alguno le guste el diseño de la base de datos.
Para ser justos tengo que decir que si miro hacia atrás esto siempre ha sido así. Cuando yo empecé a dar mis primeros pasos en 1980 ya existía el rol de analista y de analista-programador, sin embargo ¡a mí lo que me gustaba era “programar”, picar código!
Daba igual si era una calculadora programable Texas Instruments TI-59 o el Spectrum 48K. Es curioso que no resulte difícil recordar aquella sensación, ¡cuánto disfruté, he disfrutado y sigo disfrutando!, creo que lo mejor de todo es que después de casi 4 décadas sigo manteniendo esa misma pasión cada vez que abro un editor y me pongo a programar.
Hoy y en el futuro los dispositivos y los lenguajes con los que un programador comenzará su andadura en el mundo del desarrollo de software serán distintos; sin embargo la sensación de estar disfrutando seguirá existiendo de igual manera.
Profesionalmente cuando comienzas a desarrollar aplicaciones, en general, y sobre todo si estás focalizado en el desarrollo de aplicaciones de gestión, tú mismo te darás cuenta de que conocer como se diseña una base de datos es fundamental para tu trabajo. La influencia de un buen diseño de base de datos en la programación del back-end, las reglas de negocio y la interfaz es absoluta.
Si tienes una base de datos bien diseñada, aunque no hagas un gran trabajo en la interfaz, tu aplicación funcionará bien, sin embargo lo contrario no es posible, si el diseño de la base de datos es malo, da igual el trabajo que hagas a nivel de interfaz porque el funcionamiento de la aplicación no será bueno.
Profesionalmente tuve la suerte de que en mi primer trabajo participé en un equipo de desarrollo de una aplicación para gestionar la facturación de un importante grupo empresarial, que en aquél entonces ya contaba con más de 40 empresas. El proyecto se desarrolló sobre un sistema AS/400 de IBM con lenguaje RPG II. En el equipo teníamos un analista encargado de hacer de puente entre el cliente y los programadores, allí descubrí la importancia de ese rol, una persona que no programaba pero que decidía como estructurar la base de datos, definía las interfaces y gestionaba los avances del desarrollo de la aplicación.
Por un lado me gustaba lo que hacía aquella persona, y por otro lado veía las dificultades que tenía para cohesionar sus ideas con los programadores al no tener conocimientos de programación. Entendí la importancia del análisis, y a la vez la necesidad de plasmar ese análisis en un diseño de base de datos coherente, normalizado, y con capacidad para adaptarse a futuras necesidades. Acababa de descubrir el rol que más me ha gustado desde entonces el de analista-programador.
Un analista-programador es un semidiós de la informática. Es capaz de tratar con el cliente, con el product owner, con otros analistas, con programadores, con probadores, etc. Controla y gestiona los proyectos, aunque no tiene por qué ser el rol de jefe de proyecto, sus competencias están cercanas y podría en un momento dado asumirlo.
Si eres un desarrollador autónomo sabes perfectamente de qué te estoy hablando. Tú te lo guisas y tú te lo comes, estás solo y además de todo lo comentado tienes que hacer de administrador, comercial, consultor, soporte, etc. Pero ser un hombre orquesta es tema para otro post :)Si trabajas en una empresa y dentro de un equipo de desarrollo interdisciplinar, la figura del analista-programador no puede faltar, al menos debe existir uno por equipo, y si hay más de uno aún mejor. Ojalá todos los programadores pudiesen tener el rol de analista-programador, ya que si analizas bien programas mejor.
Definición del rol de analista-programador
En internet vas a encontrar muchas definiciones sobre el rol de analista-programador como algunas de las siguientes que te detallo:https://micarreralaboralenit.wordpress.com/2007/12/05/analistas-programadores-que-hacen-y-que-se-necesita-para-serlo/
El Analista Programador es la persona que realiza las funciones de un analista técnico y de un programador; es decir, parte de una información previa recibida del analista funcional, en función de la cual desarrolla las aplicaciones y organiza los datos. Es el perfil más buscado en la actualidad.
En base a sus conocimientos en el o los lenguajes de programación necesarios en cada caso, sintetiza, organiza y lo lleva a la práctica mediante la codificación de la solución. Requiere características de personalidad similares a las de un programador, con mayor visión global y capacidad de análisis y síntesis.
https://antonioalcala.com/funciones-del-analista-programador/https://datosconciencia.com/que-hace-un-analista-programador/Está claro que los autores han bebido de las mismas fuentes :)Así que si me lo permites te voy a definir qué es para mi un analista-programador con mis propias palabras.
Un analista-programador es la combinación de dos roles que se complementan, por una lado es un profesional con capacidad para analizar las necesidades que demandan los clientes y los requisitos de una aplicación, es capaz de abstraer y sintetizar una solución óptima, definir la estructura de base de datos que de soporte a la solución, y finalmente programar con uno o varios lenguajes de programación la solución. Para ser un buen analista-programador debes dominar la empatía para tratar con los stakeholders de un proyecto, y también dominar la lógica y la abstracción; debes ser previsor, sin olvidarte de sintetizar hasta encontrar soluciones lo más simples de programar, prácticas y bien documentadas pensando en el futuro mantenimiento; y sin olvidar que debes ser perseverante para llevar los proyectos al éxito final.
Como ves un analista-programador es un perfil muy completo, con bastantes competencias, y aunque sea un único rol existen muchas especialidades, ya que no es lo mismo desarrollar soluciones web, que soluciones para dispositivos móviles o de escritorio.
Mi experiencia está centrada en las soluciones de gestión para escritorio, que es a lo que he dedicado una mayor parte de mi carrera profesional.
En las definiciones se indica que el analista-programador hace funciones de analista técnico, y que usa la información que le proporciona un analista funcional ¿Qué diferencias hay entre uno y otro?
Analista funcional
Según podemos leer en esta página https://noticias.universia.com.ar/educacion/noticia/2017/03/20/1150657/ocupaciones-tecnologicas-hace-analista-funcional.html
El Analista Funcional es un profesional que se ocupa de analizar los procesos involucrados en negocios con el fin de intentar buscar y descubrir posibles necesidades de información que pueda tener el cliente. Es el nexo entre las necesidades del usuario o cliente y el equipo informático encargado de elaborar una aplicación. A partir de su análisis, definirá las funcionalidades y requerimientos que deberá tener el software para lograr responder satisfactoriamente a las necesidades del cliente. Además, se encarga de la supervisión de la programación y de la actualización y mantenimiento de los sistemas informáticos para asegurarse del correcto funcionamiento de las aplicaciones. Esto implica muchas veces realizar tareas de asesoramiento y capacitación.
Al leer esta definición en la que el analista funcional es el nexo de unión entre el cliente y el equipo informático, y que se encarga de definir las funcionalidades y requerimiento, no puedo evitar que me venga a la mente la palabra agilidad y el rol de product owner.
Analista técnico
En principio, y tal como se define, el analista-programador utiliza los requerimientos definidos por analista funcional, o las historias de usuario que define el producto owner para diseñar la base de datos y posteriormente realizar la programación necesaria.
En mi opinión si el proyecto lo permite y la persona que hace el análisis funcional es la misma que hace el análisis técnico, estaremos ahorrando tiempo y sobre todo errores de interpretación. Lo que ocurre es que en los proyectos donde el analista funcional o el producto owner no tiene competencias para definir la base de datos no queda más remedio que mantener los roles separados.
Tenemos un proyecto, se busca un analista-programador
Para entender lo que hace un buen analista-programador vamos a adentrarnos en una historia ficticia pero que bien podría ser tan real como el próximo proyecto en el que tengas que trabajar.Tenemos un nuevo cliente que nos ha contratado el desarrollo de un software a medida para su empresa. Lo ideal para estos casos sería el desarrollo basado en “agilidad”, sin plazos y presupuesto cerrado, pero esto es algo que se escapa del artículo. Así que vamos a repasar las diferentes fases de desarrollo en las que estaría o podría estar involucrado el analista-programador.
Fase 1. Reuniones con el cliente
Si es posible, aunque en el equipo exista un analista funcional, sería conveniente que el analista-programador pudiese asistir a esas reuniones para escuchar lo que dice el cliente, e incluso preguntar para aclarar dudas, ya que para resolver una funcionalidad siempre pueden existir múltiples soluciones. En estas reuniones se trata de resolver el qué, sin embargo el analista-programador también puede aprender muchos matices que le ayudarán a definir el cómo, ya que por sus conocimientos puede detectar en estos momentos tempranos algún problema, lo que supone una gran ventaja poder atajarlos antes de comenzar con el desarrollo.
En esta fase el analista-programador tiene que practicar a fondo una de sus competencias, la escucha activa y la empatía con el cliente. Siempre es mejor escuchar directamente al cliente, que escuchar a un analista funcional que no deja de ser un intermediario, por lo que la información nos llegará irremediablemente adulterada en mayor o menor medida.
No es necesario que como analista-programador expliquemos técnicamente nada al cliente, ya que lo más probable es que no nos entienda. Al contrario debemos tratar de dar el menor número de explicaciones y solo hacer preguntas, dejar que el cliente lo cuente con sus propias palabras, aclarar términos. A medida que avanza la reunión o reuniones si el tamaño del proyecto lo exige debemos esforzarnos por tratar de usar su mismo lenguaje.
En esta fase es importante tener una visión, al menos global, de todo el proyecto. No podemos pensar en tener una reunión y comenzar a trabajar sobre lo hablado en dicha reunión quedando por revisar con el cliente otros requisitos. La experiencia nos dice que eso nos llevará a hacer cambios por falta de información relevante.Por lo tanto, hasta que no tengamos bien analizado con el cliente el proyecto en su totalidad no deberíamos comenzar con el desarrollo. No estoy hablando de retrasarlo mucho tiempo, al contrario, sería bueno que estas reuniones se realizasen en el menor tiempo posible lo que facilita trabajar con ideas frescas y quitar esta fase del análisis en poco tiempo.
Algo que valoran mucho los clientes en esta fase es nuestra experiencia en el desarrollo de aplicaciones similares o del mismo sector. El cliente rápidamente se da cuenta de nuestro conocimiento por el qué y cómo preguntamos o aclaramos las dudas, con ideas prácticas que proceden de haber resuelto esas mismas necesidades en ocasiones anteriores.
Un error habitual que debemos evitar a toda costa es intentar alimentar nuestro ego tratando de demostrarle al cliente que sabemos mejor que él lo que quiere o necesita. Eso acaba llevándonos a invertir tiempo y esfuerzo en desarrollar cosas que no nos han pedido, que no valoran y que hasta nos echarán en cara. Focalicemos nuestros esfuerzos en lo que el cliente nos dice, exclusivamente, y en todo caso si vemos que falta información, preguntemos y que sea el cliente el que confirme si lo quiere o no lo quiere en su aplicación.
No caigas en el error de pensar que el cliente no sabe lo que quiere hasta que tu se lo enseñes. El cliente puede no saber cómo solucionarlo, para eso te ha contratado, pero sí sabe lo que quiere resolver o mejorar, y aunque no sepa expresearlo bien tu misión será preguntar hasta comprenderlo.
Fase 2. Dando cuerpo al análisis
Algo que he aprendido a base de palos es que no es lo mismo lo que tiene el cliente en su cabeza, lo que nos cuenta, lo que nosotros entendemos, y lo que realmente necesitan los usuarios que no estaban en las reuniones iniciales. No hay una única realidad, por ese motivo debemos tratar de consensuar al máximo lo que hemos entendido con el cliente.
Tras las reuniones iniciales en las que hemos escuchado y preguntado al cliente, ahora nos toca a nosotros, documentar lo recogido de forma sencilla y comprensible, es decir podemos usar gráficos, esquemas y otros recursos que nos ahorren literatura, pero sobre todo debemos tratar de usar su mismo lenguaje, sus mismos ejemplos, y hasta sus mismos datos si es posible. El «utópico» objetivo final es que todos entendamos lo mismo, o al menos minimizar las diferencias de interpretación.
En esta fase es muy importante aplicar nuestra competencia de ser previsor. Programar es prever, y qué mejor momento que éste para intentar estudiar lo que nos ha dicho el cliente intentando comprenderlo e incluso descubrir lo que falta, lo que no nos ha contado, o también pensar en aquello que puede necesitar el cliente derivado de todo lo que ya sabemos.
Hay que evitar a toda costa el exceso de documentación. Los documentos largos son muy caros para el proyecto, primero para el que los genera y después para el que los tiene que leer, y además no aportan valor al producto final. Pónselo fácil al cliente, hazlo con la menor cantidad de documentación posible y con elementos fáciles de leer e interpretar.
Con toda esa información debemos reunirnos nuevamente con el cliente, y esta vez debemos hablar nosotros comentando lo que hemos entendido que debemos desarrollar, no se trata de contar cómo lo vamos a hacer, solo centrados en la funcionalidad y cómo se usará la aplicación en la práctica una vez desarrollada. En estas reuniones es grato descubrir como aparecen apuntes, precisiones y correcciones del cliente que una vez más nos ahorrarán muchas horas de desarrollo.
No es necesario, o sí, que el cliente te firme con sangre que está de acuerdo con la información que le has presentado. Quiero destacar en este punto que ser “ágiles” siempre nos va a permitir obtener mejores resultados para nuestro cliente, un mejor producto y con mayor calidad. Sin embargo, no siempre están abiertos a trabajar con estos frameworks. Una de las labores del equipo comercial primero, y del product owner y los analistas después es formar al cliente para que entienda los grandes beneficios de no trabajar con requisitos y plazos cerrados.
No nos engañemos, aunque ahora tengamos todo claro nosotros y el cliente, durante el desarrollo aparecerán mil y un detalles a perfilar, corregir y adaptar. Tenemos que tenerlo asumido, por este motivo las fases 1 y 2 debemos realizarlas con la mayor rapidez posible, ya que todavía no hemos comenzado a crear valor, aunque sí nos ayudarán en las siguientes fases a desarrollar el software con mayor calidad y menor coste.
Fase 3. Plasmando el análisis en la base de datos
Por fin, ha llegado el gran momento. Ya tenemos una visión global del proyecto, sabemos lo que el cliente espera de nosotros, lo que para él es más prioritario. Así que nos ponemos manos a la obra para diseñar nuestra base de datos. Usaremos otras competencias, la lógica y la abstracción con las que podremos desmenuzar los requisitos funcionales convirtiéndolos en tablas, campos, índices y relaciones que nos permitan almacenar toda la información que usará la aplicación.
Este es un punto crítico en nuestra aplicación. Los errores de diseño de la base de datos se pagan muy caros. Cualquier cambio de estructura puede requerir un proceso de migración de datos, eliminar código existente, reescribir código, rehacer objetos visuales de la interfaz, etc. Cualquier objeto por el que haya que pasar más de una vez supone un cargo adicional al proyecto, por ese motivo cuanto mejor hagamos esta fase menos cambios a posteriori se producirán.
La experiencia en estos casos es un grado a la hora de tomar decisiones sobre como plantear las relaciones de las tablas, y cómo se implementan las reglas de negocio en los triggers o eventos de tablas, actualizaciones, procedimientos almacenados, etc. Es lógico que si ya hemos desarrollado antes una solución similar nuestra base de datos requiera menos ajustes en el futuro.
Como comentaba al principio, a muchos programadores sobre todo en la etapa inicial, no les gusta trabajar con los gestores de base datos, definir las tablas y relaciones. Sin embargo, esto esa forma de pensar es algo que debes cambiar desde ya si quieres ser un buen analista-programador. Me atrevo a decirte que tu nivel profesional como analista-programador va estar ligado a la calidad de tu trabajo a la hora de definir la estructura de la base de datos. Aquí es donde debes marcar la diferencia.
Es importante definir todas las tablas de la aplicación y sus relaciones antes de comenzar con el desarrollo de la interfaz. Lo ideal, es que también tengas definidos todos los campos e índices, pero es lógico que esa información varíe a lo largo del desarrollo. Lo que sí debemos tratar de evitar es tener que cambiar tablas o relaciones, por este motivo antes de comenzar con el desarrollo hay que tener totalmente definidas todas las tablas y sus relaciones.
Fase 4. La importación de datos
Hace muchos, muchos años cuando informatizaba una empresa que no tenía software había que grabar los datos manualmente, ¡qué tiempos aquellos! 🙂 Hoy en día pasa justo lo contrario. Uno de los grandes temas a resolver es la migración de la información del sistema actual: aplicación, hojas de cálculo… a la base de datos de la nueva aplicación.
Mi recomendación en este punto es que como analista-programador priorices la importación de los datos antes de comenzar a crear la interfaz. Hay dos motivos para hacerlo en este momento. En primer lugar porque cuando desarrolles la interfaz podrás verla con los datos reales, eso ayuda a detectar errores, además cuando se muestran los avances al cliente, éste podrá entender mejor su funcionamiento y también puede detectar errores de forma sencilla, algo que no podría hacer con datos que no le resulten familiares.
En segundo lugar es importante tener una importación de los datos muy depurada y automatizada ya que cuando lleguen los momentos críticos de la puesta en producción de la aplicación será necesario hacer nuevamente la migración de los datos, y si eso ya lo tenemos resuelto podremos abordarlo con más tranquilidad.
Fase 5. Desarrollando ando
Cuando desarrollo con Velneo, llegado a este punto sé que ya tengo programado el 40% de la aplicación. Disponer de la base de datos y las reglas de negocio ya probadas y funcionando me otorga toda la tranquilidad necesaria para focalizar los esfuerzos en la capa de interfaz, que requiere bastante tiempo si queremos una aplicación con una buena usabilidad.
Cuando se desarrolla en equipo es fundamental pensar en el equipo. Todos tenemos nuestras costumbres, nuestros hábitos, y por supuesto nuestras manías. Pero ante todo debemos ser profesionales y pensar en el futuro, y que es muy probable que tarde o temprano el código que estamos desarrollando pase a manos de otro programador. Y aquí es donde debemos aplicar el refrán de haz a los demás lo que te gustaría que te hicieran a ti.
El equipo debe trabajar de forma homogénea, y aplicar una guía de estilo que facilite que todos programemos igual, o lo más parecido posible. Esto supone un gran beneficio a corto, medio y largo plazo. La típica queja de que esto no deja espacio para la creatividad es una falsedad, nada más lejos de la realidad. Que todos usemos un mismo sistema de nomenclaturas para objetos y variables, un mismo sistema de organización de los objetos, la misma plantilla para ubicación de controles en la interfaz no limita que un buen programador sea capaz de hacer un código elegante y bien documentado.
En esta fase las prisas no aportan nada. Hacer algo corriendo para cumplir un plazo es sinónimo de mayores costes pues estaremos generando deuda técnica sin parar, deuda que tarde o temprano vamos a pagar. Así que siempre es preferible hacer una programación de calidad, con la menor deuda técnica y con el menor número de errores. No en vano, el coste de resolver un error va creciendo de forma exponencial a medida de que la corrección se aleja del momento de su desarrollo inicial.
Un buen analista-programador y en este punto también un buen programador, deben tener dos características que los hacen mejores. La primera es ser práctico, es decir, no buscar la perfección, es importante mimar el código para conseguir el mejor rendimiento posible con un código fácil de entender y mantener. Por poner un ejemplo, es lógico esforzarse para que un formulario en lugar de tardar 3 segundos en abrirse lo haga en 6 décimas de segundo. Tratar de bajar ese tiempo de 6 a 5 décimas complicando la programación no tiene demasiado sentido salvo en casos excepcionales.
La segunda característica es ser simplista, es decir aplicar el criterio de menos es más. Resolver una función o un procedimiento con el menor código posible es un buen síntoma, pero no debe ser nuestro objetivo si por ahorrar líneas de código lo convertimos en difícil de entender y mantener. Lo más complicado es conseguir desarrollar aplicaciones sencillas, con las opciones adecuadas y la usabilidad correcta. Tan malo es lo que sobra como lo que falta. El usuario es un juez implacable y sabio, habla con los usuarios y simplifica.
En esta fase el buen programador prueba bien lo que programa. Y cuando digo bien me refiero a no dejar pasar ni una, porque ese bug volverá con más fuerza y costes. Probar, corregir, probar y probar hasta que todas las pruebas que nos han documentado en la historia de usuario se cumplan correctamente.
Si trabajamos en un marco ágil con “sprints” de 2 semanas, es importante que las tareas que pasan a producción o pre-producción estén bien probadas, ya que a partir de ese momento serán los usuarios finales los que deban probar la aplicación y dar su visto bueno. Y cada vez que un usuario abre una incidencia estamos incurriendo en un aumento de costes, y la pérdida de velocidad de desarrollo en el equipo para próximos sprints.
Fase 6. Despliegue en producción
Aunque el despliegue en sí no es una tarea propia del analista-programador, hay que entender que son momentos críticos para todo el equipo. Es normal que a esta fase se llegue con cansancio acumulado y con ganas de superar este momento lo antes posible.
Durante los días o semanas que dura la puesta en producción, dependiendo del tamaño del proyecto, el equipo normalmente estará centrado en resolver todas las incidencias que van surgiendo. Es importante mantener el marco de trabajo ágil para no caer en la anarquía.
En esta fase también existen tareas adicionales como puede ser la formación de los usuarios finales. Esta labor pueden llegar a realizarla roles específicos si así lo permite el tamaño de los equipos y de la empresa de desarrollo. En empresas más pequeñas también puede recaer en los propios desarrolladores que se deben armar de paciencia a la hora de formar lo mejor posible a los usuarios.
Cuanto más sepan los usuarios menos soporte harán, o lo harán con mejores criterios y calidad. Además, cuando los usuarios se están formando es fácil que encuentren bugs, funcionalidades no cubiertas o que no funcionan exactamente como lo usan hasta ahora.
Otro problema habitual para los usuarios es el rechazo al cambio ya que es algo implícito en la naturaleza humana. Piensa que pueden llevar años haciendo su trabajo de una determinada manera, y cualquier cambio aunque sea para mejor será traumático. Así que ármate de paciencia y tómatelo con calma. Piensa que los usuarios deben ser tus aliados no tus enemigos.
En esta fase el analista-programador debe ser más documentalista que nunca. Hay que documentar bien el código, las incidencias, ya que es posible que las resuelva otro compañero, y está bien dejar las cosas como te gustaría encontrarlas a ti.
Fase 7. Mantenimiento
Tras la puesta en producción se inicia una fase que desde el punto de vista económico puede ser la más importante para las empresas de desarrollo. Se trata del mantenimiento de la aplicación desarrollada. Los mantenimiento suelen generar ingresos recurrentes que a lo largo de los años supera con creces los ingresos del desarrollo inicial.
Existen dos tipos de mantenimientos, el correctivo que suele estar incluido en un contrato de mantenimiento.
Si quieres evitar problemas con los clientes respecto al servicio de mantenimiento correctivo debes dejarlo claro desde el primer día. Informar cuanto antes que la aplicación se desarrollará y una vez revisada y probada se desplegará en producción, y que a partir de ese día ya se cobrará mantenimiento. Si no se aclara bien hay clientes que no entienden que se les cobre por corregir errores de programación que según su criterio deberían de correr a cargo de la empresa que hizo el desarrollo. Si no se gestiona bien desde el momento de la venta esto se convertirá en un quebradero de cabeza para nuestra empresa.
El mantenimiento evolutivo, que puede estar incluido en un ingreso recurrente o no y cobrarse de forma independiente, cubre aquellas mejoras que son necesarias por cambios legislativos, y en la mayoría de los casos se deben a mejoras que el cliente solicita para seguir mejorando la aplicación.
Como desarrolladores sabemos que las aplicaciones se comportan como un ser vivo: nacen, crecen, se desarrollan y mueren. Lo importante aquí es que la fase de crecimiento suele durar años. Una aplicación totalmente nueva suele tener un período de maduración rápida y estabilización que suele durar dos años. Estos dos primeros años son bastante críticos, y una vez superados la evolución suele ser más pequeña o gradual y se controla mejor.
En esta fase como analista-programador debes hacer uso de otra característica que te hace especial, tu perseverancia, ser capaz de mantener tu calidad y dedicación a una aplicación durante años y años. Al fin y al cabo es como un hijo para ti.
¿Dónde se crece más como analista-programador?
Es muy fácil que durante la vida profesional como analista-programador te surjan oportunidades y te encuentres con períodos donde trabajes de profesional autónomo, o trabajes para una empresa de desarrollo o incluso para el departamento de informática de una empresa. En cada uno de estos casos aprendemos cosas nuevas y diferentes, aunque las características que hemos comentado en este artículo son igual de válidas para todos los casos.
Desde el punto de vista del aprendizaje, está claro que trabajar para una empresa de desarrollo que haga proyectos diferentes para empresas diferentes te ayuda a crecer en el conocimiento de múltiples sectores, problemáticas y perfiles de personas con las que colaboras. Esto es muy enriquecedor profesionalmente.
Trabajar para un departamento de informática de una empresa, suele ser mucho más tranquilo en la mayoría de los casos ya que los plazos y los alcances suelen ser más controlables, aunque no siempre es así. El mayor handicap es que salvo excepciones trabajar para una empresa supone cerrar la visión a otros negocios que limitan tu mejora continua como analista-programador.
Como autónomo, eres un hombre orquesta por lo que además de lo que se vive trabajando para una empresa de desarrollo te encuentras que también debes aprender a gestionar el negocio, su administración, pero sobre todo el ámbito comercial, ya que no solo tienes que analizar, programar, implantar, mantener y formar, además tienes que vender.
Después de repasar todas las competencias de un analista-programador es lógico qué sea un perfil tan altamente demandado.
¿Cuánto gana un analista programador?
Llegamos a uno de los aspectos menos importantes, ¡sin duda! :)Ser un buen analista programador puede cubrir las expectativas profesionales, sin embargo el sueldo es uno de los aspectos que todo trabajador debe tener en cuenta.
Lo que es seguro es que de media ganan más que los desarrolladores, ¡solo faltaba!, jeje.
En este caso los autónomos quedan fuera de la ecuación pues su remuneración depende de los beneficios obtenidos, salvo que se ponga un sueldo o salario fijo y los beneficios los reinvierta en su negocio. En cualquier caso nadie le fija su sueldo salvo las circunstancias y sus propias decisiones.
Muy distinto es el caso de los empleados por cuenta ajena que trabajan en departamentos de informática o empresas de desarrollo. Seguro que existen muchos informes, sin embargo, he decido buscar la información como si estuviese buscando empleo.
He realizado la búsqueda en Google indicando el país y la profesión analista programador. Lógicamente la muestra no es muy fiable, pero tampoco lo suelen ser muchos de los informes sobre sueldos que puedes encontrar en internet. Hay que tener en cuenta que el sueldo depende en gran medida de los años de experiencia, del tipo de tecnologías que dominas y demandan, y del tipo de empresa que ha puesto la oferta.
Si tras leer los sueldos que he encontrado ves que he metido la pata, no dudes en poner un comentario indicando la información de la que tú dispones, ya que puedes ayudar a otros compañeros de profesión que están buscando empleo.
Hay que tener en cuenta que esta búsqueda la he realizado en agosto de 2019. Buscando empleo como analista programador en diferentes países. Muchas de las ofertas no especifican un sueldo. Y las que lo especifican en su mayoría ofrecen un rango mínimo y máximo. Lo que he hecho es quedarme con la segunda mínima más baja y la segunda máxima más alta.
Claves para ser un buen analista programador utilizando metodologías low-code
Aquí dejamos una comparación más detallada de cada uno de los puntos en relación con la figura del analista-programador tradicional:
1. Entender los fundamentos del low-code:
- Tradicional: Un analista-programador tradicional escribe código utilizando lenguajes de programación y sigue patrones de diseño y arquitectura de software.
- Low-code: Un analista-programador low-code utiliza herramientas visuales y componentes preconstruidos para diseñar y construir aplicaciones, reduciendo la necesidad de escribir código desde cero. La habilidad para adaptarse a este enfoque más visual y modular es fundamental.
2. Conoce las plataformas y herramientas low-code:
- Tradicional: Un analista-programador tradicional trabaja con lenguajes de programación como Java, C#, Python, entre otros, y utiliza frameworks y bibliotecas específicas para cada lenguaje.
- Low-code: Un analista-programador low-code debe familiarizarse con las distintas plataformas y herramientas low-code disponibles, ya que estas proporcionan los componentes y funcionalidades necesarios para crear aplicaciones rápidamente. El dominio de estas herramientas es crucial para un desarrollo eficiente y efectivo.
3. Desarrolla habilidades en diseño y arquitectura:
- Tradicional: Un analista-programador tradicional necesita comprender y aplicar patrones de diseño y arquitectura de software, como MVC, capas, microservicios, etc., para diseñar soluciones escalables y mantenibles.
- Low-code: Un analista-programador low-code también debe aplicar conceptos de diseño y arquitectura, pero adaptados al entorno de las herramientas low-code. Deben aprender a organizar y estructurar aplicaciones utilizando componentes y módulos disponibles en las plataformas low-code, y a integrarlos con sistemas externos y APIs.
4. Dominar la lógica de negocio:
- Tradicional: Un analista-programador tradicional necesita entender la lógica de negocio y codificarla en aplicaciones y sistemas utilizando lenguajes de programación. Deben ser capaces de analizar y traducir los requisitos del negocio en soluciones de software funcionales.
- Low-code: Aunque la programación low-code simplifica el proceso de desarrollo, un analista-programador low-code aún debe comprender la lógica de negocio y cómo aplicarla dentro de las herramientas low-code. Pueden necesitar crear flujos de trabajo, reglas de negocio y expresiones para reflejar la lógica de negocio dentro de la aplicación.
La diferencia principal radica en que un analista-programador low-code implementará esta lógica utilizando los componentes y funcionalidades proporcionados por la plataforma low-code, en lugar de escribir código desde cero.
En resumen, aunque un analista-programador low-code comparte similitudes con un analista-programador tradicional, existen diferencias clave en términos de las herramientas, enfoques y habilidades necesarias. Un analista-programador low-code debe adaptarse a un enfoque más visual y modular, familiarizarse con diversas plataformas y herramientas low-code, y aplicar conceptos de diseño y arquitectura dentro del contexto de estas herramientas. Además, deben ser capaces de entender e implementar la lógica de negocio utilizando las funcionalidades proporcionadas por las plataformas low-code.