Puesto

Analista de negocio

¿Qué no sabéis de un requisito hasta que veis la primera versión funcionando? Normalmente que falta un caso, uno en el que nadie pensó porque todo el mundo lo daba por sabido.

Conversación inicial

Cuatro preguntas por las que empezaríamos

¿Qué no sabéis de un requisito hasta que existe la primera versión?

Si la respuesta es «bastante», la pregunta no va de lo que sabe el negocio, va de cómo se hacen las preguntas.

¿En qué mesa acaba resolver las expectativas contradictorias de dos departamentos?

Si es en la del analista, el analista está tomando una decisión de negocio sin tener potestad para ello, y eso suele volver.

¿Cuánto dura acordar un requisito, desde la primera conversación hasta la aprobación?

Esa cifra suele explicar por qué el proyecto va tarde antes incluso de empezar.

¿Qué hacéis cuando dos departamentos describen el mismo proceso de distinta manera?

Si la discrepancia queda registrada y se resuelve, o gana quien habló con vosotros el último.

Escritorio, impresión de una maqueta de pantalla: maqueta en papel de un formulario sobre la mesa, una persona rodea un campo y traza desde él una línea de referencia hasta el margen.

Nos quedamos con anotar y ordenar, vosotros con descubrir

Tomar notas de las conversaciones, ordenar los requisitos, perseguir las aprobaciones y mantener la documentación se pueden quitar del escritorio. Qué preguntas merece la pena hacer, y advertir lo que nadie dijo, se quedan con el analista.

  • La conversación queda registrada en un solo sitio. - La nota, el acuerdo y el cambio del requisito están enlazados, en lugar de dispersos por hilos.
  • Una contradicción entre requisitos queda señalada. - Dos descripciones del mismo proceso que se excluyen aparecen como algo que resolver, no como dos líneas de una lista.
  • La documentación va detrás del cambio. - Un cambio en un requisito señala qué descripciones y modelos hay que corregir, en lugar de dejarlo a la memoria del analista.

Alcance

Qué se puede quitar del análisis de negocio

Diecinueve tareas de ejemplo. Cada una tiene un punto de aprobación humana. Abajo una selección, y el alcance lo ajustamos a vuestra forma de trabajar.

Recogida de requisitos

  • Una nota de reunión con los acuerdos extraídos (verificación: el analista)
  • Una lista de preguntas abiertas surgidas de la conversación
  • Enlazar un requisito con quien lo planteó y con el proceso
  • Señalar los requisitos formulados como solución y no como necesidad (valoración: el analista)

Descripción y modelado

  • Un borrador de descripción del requisito en el formato acordado (contenido: el analista)
  • Señalar los elementos que faltan en la descripción
  • Un borrador de modelo de proceso a partir de la descripción
  • Nomenclatura coherente entre requisitos

Acuerdos con el negocio

  • Un registro de acuerdos con la fecha y la persona
  • Un recordatorio sobre un requisito pendiente de aprobación
  • Señalar los requisitos que se contradicen entre sí (resuelve: el responsable del proceso)
  • Los requisitos pendientes de aprobación en una sola vista

Cambios por el camino

  • Un registro de cambios de un requisito con su motivo
  • Señalar las partes de la documentación afectadas por un cambio
  • Un aviso cuando un requisito se cambia repetidamente
  • El efecto de un cambio sobre los requisitos relacionados

Documentación de la solución

  • Una comparación de los requisitos entregados frente a los descritos
  • Señalar las descripciones que divergen de la solución entregada
  • Documentación en un solo sitio, enlazada con los requisitos

Un día de trabajo

Hoy

  • Escribís las notas de reunión después, de memoria y de vuestros apuntes
  • Los acuerdos están en notas, en el correo y en el chat
  • Una contradicción entre requisitos sale a la luz durante la implementación
  • Perseguís las aprobaciones por correo, sin saber qué lleva más tiempo esperando
  • Cuando algo cambia averiguáis vosotros qué más hay que corregir
  • La documentación se aleja de la solución después de la primera entrega

Con asistencia de IA

  • La nota de reunión tiene los acuerdos y las preguntas abiertas extraídos
  • Los acuerdos están en un solo sitio, enlazados con el requisito
  • Una contradicción entre requisitos queda señalada antes de la implementación
  • Veis qué está pendiente de aprobación y desde cuándo
  • Un cambio señala las descripciones y los modelos a los que afecta
  • La documentación que se aleja de la solución queda marcada
  • Requisitos completos

    menos carencias descubiertas durante la implementación

    las preguntas abiertas quedan escritas tras cada conversación

  • Cambios por el camino

    menos correcciones causadas por contradicciones

    los requisitos contradictorios se señalan antes

  • Tiempo dedicado a acordar

    las aprobaciones no se quedan semanas sin que nadie lo note

    veis qué está esperando y desde cuándo

  • Documentación en la que se puede confiar

    la descripción coincide con lo que realmente funciona

    un cambio señala los documentos que corregir

Empezamos por registrar los acuerdos, porque es ahí donde se pierde más contexto.

  1. Paso 1

    Acuerdos y preguntas abiertas en un solo sitio

    Notas de reunión con los acuerdos extraídos, enlazadas con los requisitos.

  2. Paso 2

    Un registro de acuerdos y aprobaciones

    Qué está esperando, con quién y desde cuándo.

  3. Paso 3

    Detección de contradicciones

    Requisitos que se excluyen, señalados antes de la implementación.

  4. Paso 4

    Documentación frente a los cambios

    Señalar los documentos a los que afecta un cambio. Al final, porque requiere que los enlaces estén ordenados.

Preguntas frecuentes

Preguntas que surgen en la primera reunión

¿Quién resuelve las expectativas contradictorias entre departamentos?

El responsable del proceso, no el analista. La herramienta señala la contradicción y muestra quién dijo qué; la decisión pertenece a quien tiene potestad para ello. Suele ser el cambio más perceptible para el propio analista.

¿No se vuelve prescindible el analista de negocio?

Los mejores requisitos nacen de una pregunta que nadie esperaba, y en eso consiste todo el valor de este puesto. Quitamos del escritorio anotar, ordenar y perseguir aprobaciones, es decir, lo que ocurre después de la conversación. El tiempo que hoy se va en eso vuelve en forma de más conversaciones, y su número suele decidir la calidad del proyecto.

¿Esto entra en el ámbito del Reglamento de IA?

El análisis de negocio no es un uso de alto riesgo. Si las notas de reunión nacen de grabaciones, se aplican las reglas sobre grabación y consentimiento de los participantes: eso es cuestión de protección de datos y de acuerdo dentro del equipo, no de la normativa sobre sistemas de IA.

¿Os queda alguna pregunta que no esté aquí? Reservad una llamada

Siguiente paso

¿Cuántos requisitos de vuestro último proyecto cambiaron después de empezar la implementación?

Os enseñaremos cómo es el análisis cuando los acuerdos están en un solo sitio y los requisitos contradictorios salen a la luz antes de la implementación.