Análisis y desarrollo de software: qué es y qué decisiones separan a un senior

El análisis y desarrollo de software es el trabajo de entender un problema, decidir cómo resolverlo con un sistema y construir ese sistema para que siga funcionando cuando el contexto cambie. El análisis define qué se construye y con qué compromisos; el desarrollo lo convierte en código que corre en producción. Si solo cierras tickets que alguien más ya analizó, estás haciendo la mitad del trabajo.

Esa brecha no se nota en el día a día. Puedes pasar años dentro de un proceso de desarrollo de software, estimando tickets y cumpliendo sprints, sin entrenar lo que más pesa en el trabajo de un ingeniero senior: tomar decisiones técnicas con consecuencias reales.

El problema no es que falten procesos. De hecho, muchas veces sobran. El problema surge cuando esos procesos reemplazan el pensamiento en lugar de estructurarlo.

¿Qué es el análisis y desarrollo de software?

Son dos partes del mismo trabajo. El análisis responde qué problema hay que resolver, qué restricciones existen y qué decisiones de diseño tienen sentido. El desarrollo responde cómo se implementa eso en código, cómo se prueba y cómo se pone en producción.

En equipos sanos, las dos partes se mezclan todo el tiempo: escribes código y descubres que el análisis tenía un hueco, vuelves a decidir y sigues. Cuando se separan del todo, el análisis lo hace otra persona en otra reunión y a ti te llega un ticket cerrado.

¿Qué incluye el análisis de software?

En la práctica, analizar es tomar decisiones antes de que el código las tome por ti. Suele incluir:

• Entender el problema real, que no siempre coincide con el que describe el ticket.
• Identificar las restricciones: volumen de datos, latencia aceptable, presupuesto, gente disponible, sistemas legados.
• Modelar los datos y decidir dónde termina un componente y empieza otro.
• Elegir trade-offs y decirlos en voz alta: consistencia o disponibilidad, simplicidad o flexibilidad, entregar hoy o pagar deuda técnica después.
• Pensar qué pasa si el tráfico se multiplica, si un servicio externo se cae o si la feature no funciona como esperabas.
• Dejar por escrito por qué se eligió ese camino, para que dentro de seis meses alguien no tenga que adivinarlo.

¿En qué se diferencia el análisis del desarrollo?

El análisis decide y el desarrollo ejecuta esa decisión, aunque las dos cosas se retroalimentan. Así se reparte el foco de cada una:

• Pregunta central: el análisis pregunta qué hay que resolver y con qué compromisos; el desarrollo, cómo implementarlo bien.
• Resultado: el análisis deja decisiones de diseño, modelo de datos, límites y riesgos; el desarrollo deja código, tests, pipeline y deploy.
• Cuándo falla: el análisis falla cuando se salta o se hereda sin cuestionar; el desarrollo, cuando el código no refleja la decisión o queda frágil.
• Costo de equivocarse: en análisis es alto y aparece meses después; en desarrollo se ve antes y se corrige más rápido.
• Qué entrena: el análisis entrena criterio; el desarrollo, velocidad y precisión.

¿Qué hace un analista y qué hace un dev senior?

Muchas empresas tienen un rol de analista (funcional, de negocio o de sistemas) separado del equipo de desarrollo. Eso no significa que el dev senior deje de analizar: analizan cosas distintas.

• Foco: el analista mira qué necesitan el negocio y el usuario; el dev senior, cómo debe comportarse el sistema para cumplirlo.
• Trabaja con: el analista, con stakeholders, procesos y casos de uso; el dev senior, con arquitectura, modelo de datos y contratos entre servicios.
• Entrega: el analista, requerimientos, criterios de aceptación y flujos; el dev senior, decisiones técnicas, diseño, código y revisión.
• Pregunta típica: el analista pregunta qué tiene que pasar cuando el usuario hace X; el dev senior, qué se rompe cuando haya diez veces más usuarios haciendo X.

En equipos de producto chicos, el dev senior absorbe buena parte del análisis funcional. En equipos grandes, la diferencia entre un dev mid y uno senior suele estar en si cuestiona los requerimientos o solo los implementa.

¿Buscas la carrera de Análisis y Desarrollo de Software?

En varios países de LATAM existe una carrera técnica o tecnológica con ese nombre. Aquí no vamos a comparar programas. Esta nota trata sobre lo que pasa después, cuando ya trabajas en la industria y lo que te hace avanzar es tu criterio para decidir más que el título.

¿Cuál es la diferencia entre pensar en tareas y pensar en sistemas?

Mira tu semana y calcula cuánto tiempo pasaste tomando decisiones y cuánto ejecutando decisiones que ya tomó otra persona. En muchos roles de desarrollo de software a la medida, o donde el scope llega cerrado, el trabajo se ve así:

• Recibes una historia con criterios de aceptación cerrados
• Se espera que implementes exactamente eso
• Las decisiones importantes ya fueron tomadas en otra instancia
• El margen de cuestionamiento es limitado

En ese contexto, el desafío técnico puede existir, pero está encapsulado. No estás definiendo el sistema, estás operando dentro de él.

• El punto de partida: en modo tarea preguntas qué pide el ticket; en modo sistema, qué problema resuelve y si es el correcto.
• Dónde pones el esfuerzo: en modo tarea optimizas la implementación; en modo sistema cuestionas si hace falta implementarlo así.
• Cuándo termina la feature: en modo tarea, cuando pasa QA; en modo sistema, cuando se comporta bien en producción.
• Las restricciones: en modo tarea vienen dadas; en modo sistema se negocian y se documentan.
• Cómo te mides: en modo tarea, por tickets cerrados; en modo sistema, por decisiones que siguen en pie un año después.
• Qué es un error: en modo tarea, un bug; en modo sistema, también puede ser una decisión de diseño.

Cuando pasas a un entorno donde el análisis es real (y no una ceremonia), el trabajo cambia de naturaleza. El problema no está del todo definido, las restricciones se pueden discutir y tus decisiones técnicas tienen consecuencias visibles en cómo se comporta el sistema.

Es incómodo, y también es donde más se aprende.

¿Por qué seguir el proceso no garantiza un buen sistema?

Durante años, la industria promovió la idea de que seguir correctamente el ciclo de vida del software era suficiente para construir buenos sistemas. Si hacías bien el análisis, el diseño, la implementación, el testing y el despliegue, el resultado debería ser sólido.

En la práctica, cualquier ingeniero con experiencia sabe que esto no funciona así.

Puedes tener:

• Refinamientos bien documentados
• Historias de usuario claras
• Cobertura de tests aceptable
• Pipelines de CI/CD funcionando

Y aun así terminar con un sistema que:

• No escala como esperabas
• Es difícil de mantener
• Tiene decisiones inconsistentes entre módulos
• Se vuelve cada vez más frágil con cada iteración

Lo que falla no es el proceso en sí, sino la ilusión de que este reemplaza el criterio técnico. Ningún framework de trabajo toma decisiones por ti. Solo organiza cuándo y cómo deberías tomarlas.

¿Cómo se ve el análisis real en el día a día?

Dicho así suena abstracto, pero en la práctica son situaciones que seguro reconoces si ya llevas unos años en esto.

Por ejemplo, cuando estás diseñando un nuevo flujo en un sistema ya en producción, el análisis no consiste solo en entender qué pide el negocio, sino también en interpretar cómo ese cambio interactúa con lo que ya existe. Eso implica cuestionar supuestos, identificar inconsistencias y, muchas veces, proponer soluciones que inicialmente no estaban sobre la mesa.

Ese tipo de trabajo suele incluir cosas como:

• Evaluar si una nueva feature debería integrarse en un servicio existente o justificarse como un servicio nuevo.
• Decidir cuándo necesitas consistencia fuerte y cuándo te alcanza con consistencia eventual.
• Anticipar cuellos de botella antes de que aparezcan en producción.
• Identificar la deuda técnica que puede volverse crítica si no se aborda a tiempo.

Nada de esto está en el ticket (y nadie lo estima en story points). Y, sin embargo, es lo que define la calidad del sistema a largo plazo.

¿Qué preguntas de análisis conviene hacerte antes de escribir código?

Si quieres entrenar el músculo del análisis aunque tu entorno no lo pida, empieza por estas preguntas. No hace falta responderlas todas en cada ticket, pero sí saber cuáles importan en cada caso.

Sobre el problema

• ¿Este problema merece una solución técnica o hay una forma más simple de resolverlo?
• ¿Estamos optimizando para el caso correcto o para una excepción?
• ¿Qué pasa si no hacemos nada?

Sobre el diseño

• ¿Cómo modelas tus datos desde el principio?
• ¿Cómo defines los límites entre los servicios?
• ¿Qué tipo de contratos estableces entre los componentes?
• ¿Qué compromisos haces entre rendimiento, consistencia y complejidad?

Sobre el riesgo

• ¿Qué pasa si esta feature no funciona como esperamos?
• ¿Qué parte de esta decisión va a ser cara de revertir?
• ¿Quién va a mantener esto dentro de un año y qué necesita saber?

¿Qué pasa cuando siempre trabajas con problemas ya resueltos?

Uno de los efectos más limitantes de ciertos entornos es que los problemas llegan ya estructurados, de modo que no requieren un análisis real. Están “predigeridos”. Solo requieren ejecución.

Te vuelves muy eficiente en la implementación, pero pierdes exposición a la ambigüedad, que es justamente donde se construye el criterio.

Con el tiempo, esto se nota en detalles sutiles pero importantes:

• Dificultad para proponer alternativas fuera del alcance original.
• Tendencia a optimizar soluciones en lugar de cuestionarlas.
• Dependencia de definiciones externas para avanzar.
• Poca práctica defendiendo decisiones técnicas.

Y esto no es un problema de capacidad individual, sino de contexto. Si nunca te enfrentas a problemas abiertos, no desarrollas la musculatura necesaria para resolverlos.

¿Por qué la escalabilidad depende de decisiones y no del stack?

Muchas veces se habla de sistemas que “escalan” como si fuera una propiedad que aparece mágicamente cuando el sistema crece. En realidad, la escalabilidad es el resultado acumulado de cientos de decisiones pequeñas tomadas a lo largo del tiempo.

Las preguntas de diseño del checklist de arriba son exactamente esas decisiones. En un entorno donde el proceso de desarrollo de software está desacoplado del pensamiento técnico, tienden a ser implícitas o heredadas: nadie las cuestiona porque “así funciona”.

En cambio, en equipos donde el análisis es parte central del trabajo, esas decisiones se discuten, se revisan y, cuando es necesario, se corrigen. Y eso es lo que permite que el sistema evolucione sin colapsar bajo su propio peso.

¿Cómo cambia el análisis en un equipo de producto?

Cuando empiezas a trabajar en equipos donde el desarrollo está conectado con el producto, cambia la forma de las conversaciones. El código deja de ser el centro de todo y pasa a ser una herramienta dentro de un sistema de decisiones más amplio.

Las discusiones no empiezan por “cómo lo implementamos”, sino por “qué problema estamos resolviendo realmente”. Y eso abre la puerta a cuestionar aspectos que en otros entornos ni siquiera se consideran parte del rol técnico.

Ese nivel de involucramiento cambia por completo cómo trabajas. Ya no estás ejecutando dentro de un proceso: estás participando en la construcción del sistema.

¿Qué decisiones de análisis separan a un dev senior?

Es tentador medir el crecimiento profesional en tecnologías: qué lenguajes manejas, qué frameworks conoces, qué herramientas usaste. En el nivel senior, eso empieza a ser secundario.

Lo que realmente marca la diferencia es tu capacidad de:

• Entender problemas incompletos.
• Avanzar cuando el problema todavía es ambiguo.
• Tomar decisiones con información imperfecta.
• Asumir la responsabilidad por las consecuencias de esas decisiones.

Y eso no se aprende con una nueva librería. Se entrena trabajando en contextos en los que esas habilidades son necesarias para avanzar.

¿Qué puedes hacer si tu entorno no te deja analizar?

Puedes intentar forzar este tipo de crecimiento desde adentro: involucrarte más, proponer mejoras, cuestionar decisiones. A veces funciona, pero muchas veces la organización simplemente no está diseñada para eso.

En esos casos, el cambio real viene de moverte a equipos donde el análisis y el desarrollo están integrados de verdad, donde te toca definir cómo evoluciona el sistema además de implementarlo.

¿Qué separa a quien escribe buen código de quien construye sistemas?

Puedes seguir cada paso del proceso y aun así no estar haciendo análisis. Lo que cuenta es tomar decisiones técnicas que definen cómo se comporta un sistema, cómo escala y cómo cambia con los años.

Si hoy tu trabajo está centrado principalmente en ejecutar tareas bien definidas, es probable que estés desarrollando velocidad y precisión, pero no necesariamente criterio.

Y a largo plazo, eso es lo que separa a alguien que escribe buen código de alguien que puede construir sistemas que realmente funcionan cuando todo empieza a volverse más complejo.