El botón era perfecto.
Verde, grande, bien alineado y con una pequeña animación al pasar el ratón por encima. El equipo llevaba varias semanas trabajando en aquella funcionalidad y, por fin, había llegado el momento de enseñársela a los usuarios.
El desarrollador pulsó el botón.
En la pantalla apareció el mensaje:
«Operación realizada correctamente».
Durante un par de segundos nadie dijo nada…
Entonces Carmen, una de las personas que utilizaría la aplicación, se inclinó hacia la pantalla.
—Pero… ¿ha cerrado todos los expedientes?
—Sí —respondió el desarrollador—. Todos los que estaban seleccionados.
—No, no. Eso no puede hacerlo así. Tiene que cerrar únicamente los que cumplen las condiciones. Los demás deben quedarse pendientes y tenemos que saber por qué no se han tramitado.
El desarrollador miró al analista.
El analista abrió el documento de requisitos.
Allí estaba escrito:
«El sistema permitirá cerrar conjuntamente los expedientes seleccionados».
La aplicación hacía exactamente lo que decía el documento. El problema era que el documento no decía exactamente lo que necesitaba el usuario.
La escena, cómo no, es ficticia, pero cualquiera que haya trabajado en un proyecto de software ha vivido alguna versión de ella. Cambian los nombres, las pantallas y los botones, pero la frase suele ser la misma:
—Esto no es lo que habíamos pedido.
Y, casi siempre, la respuesta también:
—Es exactamente lo que estaba escrito.
Una frase puede esconder un sistema entero
Durante mucho tiempo hemos aceptado estas situaciones como algo inevitable.
El negocio explica lo que necesita, el analista intenta recogerlo, el equipo técnico lo interpreta, los desarrolladores programan, los probadores comprueban lo que creen que debe suceder y, finalmente, el usuario descubre qué entendió realmente cada uno. El desarrollo de software ha funcionado muchas veces como el juego del ‘teléfono roto’.
Una persona dice:
—Necesitamos que el sistema permita tramitar varios expedientes a la vez.
Y al final de la cadena alguien implementa:
—Hay que poner un botón que procese todos los registros seleccionados.
Entre ambas frases se han perdido las condiciones, las excepciones, los permisos, los estados, las consecuencias y, en ocasiones, hasta el verdadero objetivo de la funcionalidad.
Antes, esta pérdida de información avanzaba lentamente. Un desarrollador podía detectar una duda, levantar la mano y preguntar:
—¿Qué ocurre si uno de los expedientes no cumple las condiciones?
Entonces comenzaba una conversación. Quizás había una reunión. Tal vez alguien revisaba la normativa. En el peor de los casos, la decisión se tomaba sobre la marcha.
Ahora hemos incorporado un nuevo participante a la conversación: la inteligencia artificial.
Y la inteligencia artificial programa muy deprisa, pero también se equivoca muy deprisa.
La IA no entiende nuestros silencios
Imaginemos otra escena.
Son las cinco de la tarde. Un desarrollador quiere adelantar trabajo antes de marcharse y escribe en su asistente de IA:
«Crea una funcionalidad que permita modificar los datos de un solicitante y guardar los cambios en la base de datos».
La petición parece suficientemente clara.
En pocos minutos, la IA genera el formulario, las validaciones, el servicio, la consulta SQL y hasta algunas pruebas unitarias. El resultado compila, los datos se guardan.
Hasta que alguien pregunta:
—¿Qué sucede con los datos anteriores?
La aplicación los ha sobrescrito.
Nadie había explicado que, por razones de auditoría, debía conservarse el histórico. Tampoco se había indicado quién podía modificar los datos, qué campos eran inalterables o qué debía ocurrir cuando dos personas editasen el mismo registro al mismo tiempo.
La IA no había cometido un error de programación; había rellenado los huecos de una historia incompleta.
Eso es lo que hacemos los seres humanos cuando nos falta información: interpretamos. La diferencia es que una máquina puede convertir su interpretación en cientos de líneas de código antes de que hayamos terminado el café.
La inteligencia artificial no elimina la ambigüedad: la industrializa.Puede transformar una idea confusa en una solución completa, elegante y perfectamente equivocada.
Un nombre algo extraño para una idea muy humana
Spec-driven suena a una de esas expresiones inventadas en una conferencia tecnológica por alguien que llevaba una acreditación colgada del cuello.
Pero detrás del término hay una idea bastante sencilla:
Antes de pedir a una persona o a una máquina que construya algo, debemos contar la historia con suficiente claridad para que no tenga que inventarse el final.
Una especificación no debería ser solamente una colección de requisitos. Debería contar la historia completa del sistema.
- Quién interviene.
- Qué necesita.
- Qué puede hacer.
- Qué no puede hacer.
- Qué sucede cuando todo va bien.
- Y, sobre todo, qué sucede cuando algo sale mal.
Los problemas aparecen en las esquinas: cuando falta un dato, cuando dos reglas se contradicen, cuando alguien pulsa dos veces el mismo botón o cuando un expediente llega a un estado que, en teoría, nunca debería producirse. La realidad tiene la incómoda costumbre de encontrar todos los casos que consideramos imposibles.
La historia del usuario «activo»
En otro proyecto, durante una reunión, alguien dijo:
—Esta operación solo podrán realizarla los usuarios activos.
Nadie pareció encontrar nada extraño en aquella frase.
Todo el mundo sabía lo que era un usuario activo.
O eso creían.
Para el responsable del negocio, un usuario activo era alguien que no había sido dado de baja.
Para el equipo de seguridad, era alguien con credenciales vigentes.
Para el desarrollador, era cualquier registro cuyo campo ESTADO tuviera el valor A.
Para la persona que administraba los permisos, un usuario podía estar activo y, sin embargo, no estar autorizado para realizar aquella operación.
Cuatro personas habían utilizado la misma palabra para referirse a cuatro realidades diferentes.
El problema no era técnico. La base de datos funcionaba. El servicio de autenticación funcionaba. Los permisos funcionaban.
Lo que no funcionaba era el significado de la palabra «activo».
Ese es el territorio del análisis funcional.
El analista no es simplemente la persona que toma notas en una reunión y después redacta un documento. Es quien escucha una palabra aparentemente inocente y pregunta:
—Cuando decimos «activo», ¿qué queremos decir exactamente?
A veces esa pregunta provoca un silencio incómodo.
Ese silencio puede ahorrar semanas de trabajo.
El analista que hace una pregunta más
Los buenos analistas funcionales suelen tener una costumbre ligeramente irritante: hacen una pregunta más.
Cuando parece que todo está claro, preguntan:
—¿Y qué ocurre si…?
- ¿Qué ocurre si el pago ya se ha realizado?
- ¿Qué ocurre si el solicitante ha fallecido?
- ¿Qué ocurre si dos gestores modifican el mismo expediente?
- ¿Qué ocurre si el proceso se interrumpe a mitad?
- ¿Qué ocurre si el servicio externo no responde?
- ¿Qué ocurre si el usuario vuelve a pulsar el botón?
No hacen estas preguntas para complicar el proyecto. Las hacen porque saben que, tarde o temprano, alguna de esas situaciones ocurrirá.
Quizás suceda dentro de seis meses, a las ocho de la mañana, el último día de un plazo importante. Y entonces alguien pronunciará una de las frases más temidas en informática:
—El sistema no me deja continuar.
La principal herramienta de un analista funcional no es Word, Jira, UML ni ninguna aplicación concreta: es la capacidad de imaginar situaciones que todavía no han sucedido. El analista recorre mentalmente el proceso, se pone en el lugar del usuario, observa dónde podría tropezar y trata de encender la luz antes de que alguien llegue allí.
Las especificaciones también pueden contar historias
Cuando hablamos de especificaciones pensamos inmediatamente en documentos extensos, tablas interminables y códigos como RF-023.4-B.
Pero una buena especificación puede comenzar con una historia:
Una gestora necesita tramitar conjuntamente cien expedientes. Noventa y siete cumplen las condiciones, pero tres se encuentran en un estado incompatible. La gestora no quiere perder todo el trabajo realizado ni descubrir el problema al final del proceso. Necesita saber, antes de confirmar la operación, qué expedientes pueden continuar y cuáles deben revisarse.
En ese pequeño relato ya aparecen una persona, un objetivo, un obstáculo y una necesidad. Después podremos convertirlo en reglas, escenarios, diagramas o pruebas. Pero primero debemos entender la historia.
Porque los usuarios no viven dentro de una tabla de requisitos. Viven situaciones. Tienen plazos, responsabilidades, interrupciones, dudas y consecuencias. Una pantalla mal diseñada puede hacerles perder cinco minutos. Una regla mal interpretada puede hacerles tomar una decisión incorrecta. Un mensaje ambiguo puede llevarles a repetir una operación que ya se había ejecutado.
El análisis funcional spec-driven no debería alejarnos de las personas. Debería obligarnos a acercarnos más a ellas. La especificación debe ser rigurosa, pero también debe conservar la historia humana que le da sentido.
No se trata de escribir más
Trabajar de forma spec-driven no consiste en fabricar documentos cada vez más grandes. Un documento de cien páginas puede seguir ocultando las preguntas importantes.
Tampoco significa que todo deba expresarse mediante una sintaxis rígida ni que cada conversación tenga que terminar convertida en un diagrama. Es algo mucho más sencillo: las decisiones relevantes no pueden quedarse flotando en el aire.
Si en una reunión se decide que una operación puede continuar parcialmente, esa decisión debe incorporarse a la historia del sistema.
Si descubrimos una excepción, la historia debe cambiar.
Si el negocio modifica una regla, no basta con cambiar el código. Debemos actualizar primero la explicación de lo que el sistema debe hacer.
La especificación se convierte así en una memoria compartida.
Evita que la respuesta a una duda dependa de encontrar a la única persona que recuerda una conversación mantenida hace dos años junto a una máquina de café.
La IA necesita límites, no solo instrucciones
Solemos hablar de la calidad de los prompts como si todo dependiera de encontrar una frase especialmente ingeniosa.
Pero un buen sistema no nace de un prompt brillante, nace de una comprensión profunda del problema.
Podemos pedir a una IA:
«Desarrolla una aplicación para gestionar expedientes».
Y obtendremos algo. Seguramente tendrá formularios, botones, estados y una base de datos.
Pero ese «algo» será, en gran medida, una colección de decisiones que la máquina habrá tomado por nosotros.
La alternativa es contarle una historia mucho más completa: quién utiliza el sistema, qué pretende conseguir, qué reglas debe respetar, qué situaciones pueden producirse y cómo sabremos que el resultado es correcto. Entonces la IA deja de improvisar y comienza a trabajar dentro de un mundo definido por nosotros.
Ese mundo es la especificación.
La IA puede ayudarnos a encontrar contradicciones, imaginar escenarios, proponer pruebas o detectar preguntas que todavía no hemos formulado. Puede convertirse en una magnífica compañera de análisis.
Pero no debería decidir en silencio aquello que nosotros no nos hemos molestado en explicar.
Volvamos al botón verde
Regresemos a la primera historia.
El botón continúa siendo verde, grande y perfectamente alineado.
Pero ahora, antes de pulsarlo, el sistema comprueba qué expedientes pueden tramitarse. Separa los que necesitan revisión. Explica la causa. Pide confirmación. Registra lo ocurrido y evita que una operación accidental se ejecute dos veces.
El usuario pulsa el botón.
Aparece un mensaje:
Se tramitarán 97 expedientes.Otros 3 necesitan revisión.
Carmen observa la pantalla y asiente.
—Ahora sí.
Tal vez la inteligencia artificial haya generado parte del código. Quizás también haya creado las pruebas y propuesto el diseño de la pantalla.
Pero la IA no decidió qué significaba «tramitar correctamente».
Eso lo hicieron las personas.
Alguien escuchó la necesidad. Alguien hizo una pregunta más. Alguien convirtió una frase ambigua en una historia completa.
Ese es el verdadero valor del análisis funcional.
Cuando el código se vuelve abundante, la claridad se vuelve escasa.
Cuando las máquinas aprenden a programar, los seres humanos necesitamos aprender a explicar mejor qué queremos construir y por qué.
El análisis funcional spec-driven consiste precisamente en eso:
contar la historia con tanta claridad que el sistema ya no necesite inventarse el final.