Solo Candidatos Mexicanos. Debe comprender y contar con experiencia demostrable en cada uno de los requisitos —los cuales deben verse reflejados en su currículum—, incluyendo experiencia en el sector asegurador, Inteligencia Artificial y flujos de trabajo para el análisis e implementación de soluciones. Para mayor información, consulte la sección "Diferencias con el rol tradicional" en esta publicación.

Si este es tu campo de experiencia, no dudes en postularse. Un rol integrado dentro de un equipo pequeño de entregables que desarrolla software de producción mediante un desarrollo asistido por IA de carácter agéntico.

Transforma la intención del negocio en especificaciones lo suficientemente precisas para construir a partir de ellas, y gestiona la cadencia de entrega que mantiene al equipo desbloqueado y tomando decisiones con rapidez. Dado que el desarrollo asistido por IA ha reducido drásticamente el costo de transformar un problema bien comprendido en software funcional, la ambigüedad —y no el esfuerzo de ingeniería— es la principal limitación en la entrega. Eliminarla es el núcleo de este rol.

Mandato del Rol. El mandato consta de dos partes y ambas son fundamentales. La parte de análisis garantiza que el equipo construya lo correcto. La parte de entrega garantiza que el equipo permanezca capacitado para construirlo: sin bloqueos, tomando decisiones semanalmente y replanificando con base en datos reales en lugar de defender una estimación original.

El rol está integrado en un solo equipo desde la fase de descubrimiento hasta la aceptación en producción. No existe un punto en el que el trabajo se transfiera y la responsabilidad termine.

Responsabilidades Principales

Descubrimiento y especificación.

· Ejecutar el descubrimiento directamente con los product owners del negocio y los equipos cuyo trabajo se verá transformado por el software.

· Aprender y utilizar el vocabulario propio del negocio, de modo que las especificaciones se lean tal como el negocio las expresaría.

· Convertir necesidades ambiguas en planteamientos de problemas precisos y ejecutables, y señalar claramente cuando un problema aún no se comprende lo suficiente como para construir.

· Confirmar que los criterios de aceptación consistan en condiciones probables sobre las que se ejecute la verificación automatizada, no en requerimientos narrativos que se interpreten posteriormente.

· Asumir la definición de lo que es "correcto" para cada funcionalidad, incluso cuando haya discrepancias, y conducirla hacia una respuesta única.

· Aprovechar la plataforma para modelar las reglas de negocio, los datos y los estados de los objetos a partir de los cuales construyen los ingenieros.

· Mantener las especificaciones como artefactos vivos a lo largo de la aceptación en producción, no como entregables de hitos que se firman y se archivan.





· Interacción con el Product Owner y partes interesadas (Stakeholders)

· Garantizar y proteger la disponibilidad semanal del product owner del negocio.Estructurar las decisiones para que puedan tomarse y llevarlas a su conclusión dentro del ciclo; escalar aquellas que se estanquen.

· Propiciar el contacto directo entre los dueños del negocio y los ingenieros, en lugar de actuar como intermediario entre ellos.

· Gestionar las expectativas del lado del negocio con respecto a la participación continua, los ciclos cortos y las decisiones semanales de aceptación.

· Cadencia de entrega y flujo.

· Ejecutar los ciclos cortos de resultados de principio a fin: planificación, revisión, retrospectiva y la cadencia diaria del equipo.

· Mantener el backlog a un nivel de granularidad lo suficientemente pequeño para verificar continuamente y lo suficientemente trazable para servir como evidencia.

· Rastrear los impedimentos y resolverlos; escalar aquello que el equipo no pueda resolver en lugar de absorberlo en silencio.

· Proteger la asignación dedicada del equipo y señalar cualquier menoscabo de la misma como un riesgo para la entrega.

· Gestionar las dependencias con programas adyacentes para que la entrega no se vea bloqueada por un compromiso previo no gestionado.

· Replanificar en función de datos reales e informar sobre el progreso en relación con los resultados de entrega a la dirección del programa.

Control, evidencia y preparación para auditorías.

· Apoyar el diseño de controles y la tipificación de riesgos de las aplicaciones de forma previa al desarrollo.

· Garantizar que la evidencia de control (autoría, aprobación, verificación y despliegue) se genere como un subproducto de la entrega, en lugar de adaptarse a posteriori para una auditoría.

· Mantener la segregación de funciones en la práctica diaria, asegurando que la autoría y la aprobación permanezcan a cargo de personas distintas formalmente identificadas, aun bajo la presión de los plazos.

· Mantener el modelo de entrega documentado y evaluable a medida que evoluciona.

· Adopción del modelo operativo.

· Documentar el modelo de entrega tal como se practica, para que sea repetible y transferible en lugar de residir únicamente en las personas.

· Apoyar a los ingenieros en la transición de producir código a dirigir, revisar y aceptar el trabajo.

· Registrar los datos reales de entrega (rendimiento, latencia en la toma de decisiones,



origen de defectos y retrabajo) con una fidelidad que respalde la planificación futura.

· Detectar tempranamente la resistencia a la adopción, la cual se manifiesta primero como una falta de participación silenciosa y no como una objeción explícita.

Diferencias con el Rol Tradicional DimensiónBA / Scrum Master Tradicional

Este Rol precisa de Requerimientos Documentados y entregados al equipo de desarrollo Especificados como criterios de aceptación ejecutables sobre los que corre la verificación automatizada La responsabilidad Termina efectivamente al momento de la entrega al equipo de desarrollo Se extiende a lo largo de todo el proceso hasta la aceptación en producción.

La participación del negocio que se recopila al inicio y revisada en hitos principal Continua, con decisiones que se toman semanalmente.

Aseguramiento de calidad

· Coordina una fase de pruebas posterior al desarrollo

· Define la corrección desde el principio; la verificación se ejecuta con cada cambio

· Gobernanza y evidencia Aprobaciones por fases (phase gates); evidencia recopilada para la auditoría a posteriori

· Aprobaciones por hitos (milestone gates); evidencia generada como subproducto de la entrega Insumo escaso gestionado

· Capacidad de ingeniería Claridad sobre el problema de negocio

Habilidades y Experiencia Requeridas

· Fluidez en el dominio de Seguros Comerciales y Especialmente de Daños y Propiedad (P&C;): conocimiento de cómo se reciben y clasifican las solicitudes, qué significa en la práctica, así como el apetito de suscripción y cómo se estructura, versiona y distribuye el producto. Lo suficiente para mantener una conversación solvente con un suscriptor sin necesidad de un traductor.

· Rigor en la especificación Capacidad para formular una regla de negocio como una condición objetivamente probable, junto con la disciplina para detectar cuándo una afirmación solo aparenta ser precisa.

· Fluidez en entregas asistidas por IA Comprensión de que la ambigüedad, y no el esfuerzo de desarrollo, es la principal limitante, y que un resultado generado que parezca plausible aún puede ser incorrecto para el negocio.

· Conocimiento de control y auditoría Capacidad para sostener una conversación sustancial sobre evidencia, segregación de funciones y autorización de cambios sin necesidad de escalar cada consulta.

· Facilitación bajo presión Capacidad para gestionar un ciclo semanal de toma de decisiones con partes interesadas de alto nivel donde el costo de diferir una decisión se mide en días, no en meses.

· Liderazgo y firmeza de criterio Capacidad para comunicar a una parte interesada de alto nivel que una especificación no está lista para construirse, o que una decisión está atrasada, y sostener dicha postura con firmeza.

📌 Analista de Negocio y Srum Master (Ciudad de México)
🏢 Propia
📍 Ciudad de México