Resumen ejecutivo

• Una ruta de cinco etapas para llegar al rol de Analista Funcional, pensada para quien viene de administración, soporte o atención al cliente.

• Cada etapa tiene un entregable concreto: relevamiento, modelado de procesos con BPMN, historias de usuario con criterios de aceptación, consultas SQL de validación y trabajo con QA y desarrollo.

• Herramientas gratuitas para practicar cada etapa.

• Un proyecto final de portafolio que integra todo y que podés mostrar en entrevistas.

El Analista Funcional es quien traduce lo que necesita el negocio en algo que un equipo de desarrollo pueda construir. Es uno de los roles tech con más gente que llega desde otras áreas, porque lo más valioso no es programar sino entender procesos, hacer buenas preguntas y escribir con claridad. Si trabajás en administración, soporte o atención al cliente, probablemente ya hacés parte de este trabajo sin saberlo: detectás qué falla en un sistema y explicás qué necesitarían los usuarios. Esta ruta ordena lo que te falta aprender en cinco etapas, cada una con un entregable. Si te interesa ver cómo se compara con roles vecinos, mirá qué hace un Business Analyst y en qué se diferencia de un Data Analyst.

Antes de empezar: qué hace un Analista Funcional

• Releva necesidades con usuarios y áreas de negocio.

• Documenta procesos actuales y propuestos.

• Escribe requisitos, historias de usuario y criterios de aceptación.

• Valida con el equipo técnico que la solución es viable.

• Acompaña las pruebas y la puesta en marcha.

El marco de referencia internacional de la disciplina es la BABOK Guide del IIBA, que describe las áreas de conocimiento del análisis de negocio. No hace falta leerla entera para empezar, pero conviene conocerla.

Etapa 1: Entender el negocio y relevar

Qué aprender: técnicas de relevamiento (entrevistas, observación, talleres), cómo identificar stakeholders y cómo separar el problema de la solución que te piden.

Práctica: elegí un proceso que conozcas de tu trabajo actual (por ejemplo, la gestión de reclamos) y entrevistá a dos o tres personas que participen. Preguntá qué hacen, en qué orden, qué sistemas usan y dónde se traban.

Entregable: una minuta de relevamiento con objetivo, stakeholders, situación actual, problemas detectados y preguntas abiertas.

Etapa 2: Modelar procesos con BPMN

Qué aprender: la notación BPMN 2.0, el estándar más usado para diagramar procesos. Enfocate en lo básico: eventos de inicio y fin, tareas, compuertas de decisión, carriles por rol y flujos de mensaje.

Herramientas gratuitas: Bizagi Modeler o diagrams.net.

Entregable: dos diagramas del proceso que relevaste: el actual (AS-IS) y el propuesto (TO-BE), con las mejoras marcadas.

Etapa 3: Escribir historias de usuario y criterios de aceptación

Qué aprender: el formato "Como [usuario], quiero [acción], para [beneficio]", los criterios INVEST para evaluar si una historia está bien escrita y cómo redactar criterios de aceptación con el formato Dado/Cuando/Entonces. La guía de historias de usuario de Atlassian es una buena referencia práctica.

Ejemplo: "Como operador de atención, quiero ver el historial de reclamos del cliente en la misma pantalla, para no tener que pedirle los datos de nuevo". Criterio: "Dado un cliente con reclamos anteriores, cuando abro un reclamo nuevo, entonces veo los últimos cinco con fecha y estado".

Entregable: un backlog de ocho a diez historias derivadas del proceso TO-BE, priorizadas. Para profundizar, tenés la guía para escribir historias de usuario y criterios de aceptación.

Etapa 4: SQL básico para validar datos

Qué aprender: SELECT, WHERE, JOIN, GROUP BY y COUNT. No vas a desarrollar, pero saber consultar una base te permite validar supuestos ("¿cuántos reclamos quedan abiertos más de diez días?") y revisar si lo que se construyó funciona.

Práctica: armá una tabla de ejemplo con datos de reclamos y escribí cinco consultas que respondan preguntas del relevamiento.

Entregable: un documento con las consultas, los resultados y qué decisión ayudan a tomar.

Etapa 5: Trabajar con QA y desarrollo en un equipo ágil

Qué aprender: cómo funcionan las ceremonias de Scrum (refinamiento, planning, review), cómo participás en cada una y cómo se convierten tus criterios de aceptación en casos de prueba. La Guía de Scrum oficial es corta y vale la pena leerla completa.

Práctica: para tres de tus historias, escribí los casos de prueba que debería ejecutar QA. Si querés entender mejor ese lado, mirá qué hace un QA Tester y qué herramientas usa.

Entregable: matriz de trazabilidad que conecte cada requisito con su historia y sus casos de prueba.

Proyecto final de portafolio

Integrá los cinco entregables en un caso de estudio con esta estructura:

1. Contexto del proceso y problema.

2. Relevamiento: a quién entrevistaste y qué encontraste.

3. Diagramas AS-IS y TO-BE.

4. Backlog priorizado con criterios de aceptación.

5. Validaciones con SQL.

6. Casos de prueba y trazabilidad.

7. Qué aprendiste y qué harías distinto.

Publicalo en Notion o en un PDF prolijo y llevalo a cada entrevista. Es la mejor forma de demostrar que podés hacer el trabajo aunque no hayas tenido el título del puesto.

Cómo aprovechar tu experiencia previa

• Desde administración: conocés procesos, controles y documentación. Destacá cómo mejoraste algún circuito.

• Desde soporte: conocés los errores reales del sistema y cómo piensan los usuarios. Destacá los problemas que escalaste y cómo los documentaste.

• Desde atención al cliente: sabés escuchar y traducir quejas en necesidades. Es exactamente la habilidad del relevamiento.

Cursos recomendados de Coderhouse

Para la etapa ágil, el Curso de Scrum y Metodologías Ágiles te prepara para trabajar con equipos de desarrollo. Si querés sumar visión de producto y priorización, el Curso de Product Manager amplía tu perfil. Y para la etapa de datos, el Curso de SQL te da las consultas que vas a usar para validar requisitos.

Preguntas frecuentes

¿Necesito saber programar para ser Analista Funcional? No. Ayuda entender cómo funciona un sistema y saber SQL básico, pero el foco está en relevar, documentar y comunicar.

¿Cuánto tiempo lleva esta ruta? Depende de tu dedicación. Con algunas horas por semana, recorrer las cinco etapas y armar el proyecto final puede llevar unos meses.

¿Qué diferencia hay entre Analista Funcional y Business Analyst? Se superponen mucho. En general, el Analista Funcional está más cerca del sistema y los requisitos de software, y el Business Analyst puede trabajar a un nivel más estratégico del negocio. Depende de cada empresa.

¿Conviene certificarse? Una certificación puede sumar, pero al principio pesa más un portafolio con un caso completo. Podés evaluar certificaciones del IIBA o de Scrum más adelante.