Empieza por el trabajo que alguien necesita completar
Describe una situación concreta antes de enumerar funcionalidades. Identifica quién llega a la aplicación, qué información trae y qué resultado necesita para continuar el trabajo. Ese recorrido da un propósito a pantallas y acciones. Sin él, una lista extensa puede seguir dejando sin resolver la necesidad principal.
Imagina un taller que recibe solicitudes de reparación por varios canales y quiere organizarlas. La idea inicial puede ser tener una aplicación con clientes, equipos y estados. Todavía falta saber quién registra la solicitud, qué información recibe y cómo determina si hay material suficiente para derivar el trabajo a un técnico.
Una descripción más útil sigue una solicitud desde la entrada: recepción identifica el equipo, registra el síntoma y asocia una forma de contacto. El responsable técnico analiza la solicitud y decide el siguiente paso. El equipo necesita reconocer el estado actual sin reconstruir la historia en varias conversaciones.
Ese recorrido ayuda a encontrar el primer resultado que merece construirse. Quizá baste con registrar y consultar solicitudes de forma consistente antes de añadir notificaciones o informes. Esa elección puede cambiar después, pero permite discutir una necesidad completa en lugar de empezar por una colección de botones.
Es la misma lógica de utilizar IA en el negocio más allá del chatbot: partir del trabajo que necesita ocurrir. La herramienta pasa a tener un lugar definido en el proceso y la especificación puede explicar cómo contribuye la aplicación al resultado sin atribuirle todas las responsabilidades del equipo.
Para preparar el siguiente paso, consulta Crear productos digitales con IA.
Utiliza las preguntas para cerrar elecciones importantes
Las preguntas deben reducir la incertidumbre que afecta al comportamiento, empezando por las decisiones con más consecuencias. Quién puede realizar cada acción, qué información es obligatoria y cuándo cambia de estado una solicitud son buenos puntos de partida. Las cuestiones de apariencia pueden esperar mientras el funcionamiento central siga sin definirse.
Al desarrollar una plataforma de soporte con solicitudes de ayuda, tuve que responder a muchas preguntas para aclarar qué quería que ocurriera. La idea de tener un sistema de tickets parecía sencilla. El detalle apareció cuando hubo que explicar el comportamiento de la plataforma, los accesos y la relación entre sus partes.
En el taller hipotético, pregunta primero quién puede marcar una solicitud como completada. Si cualquiera puede hacerlo, el proceso será distinto del de un sistema en el que esa decisión pertenece al técnico responsable. La respuesta cambia las acciones disponibles, la información mostrada y los casos que necesitan comprobarse.
Pide a la IA que explique por qué necesita cada decisión importante y presente opciones comprensibles. Si una pregunta mezcla varias elecciones, divídela. Es más fácil evaluar las consecuencias de permitir reabrir una solicitud completada que responder a un párrafo que mezcla estados, notificaciones, permisos y diseño del panel.
No hace falta responder a todas las preguntas antes de la primera construcción. Algunas pueden aplazarse si no afectan al recorrido elegido. Registra ese aplazamiento y su alcance, para que la ausencia de decisión no se interprete después como autorización para inventar una regla o construir una funcionalidad.
Distingue datos, reglas y decisiones abiertas
La especificación debe separar la información existente de las reglas que aplicará la aplicación sobre ella. También debe señalar lo que todavía no se ha decidido. Esa distinción evita que los ejemplos se conviertan en requisitos obligatorios o que una hipótesis sugerida por la IA pase a tratarse como una elección aceptada.
Una solicitud de reparación puede tener identificación del equipo, descripción del síntoma y contacto del cliente. Esos son datos. Impedir su derivación cuando falta información esencial es una regla, que debe indicar exactamente qué es esencial. La forma de avisar a recepción puede seguir siendo una decisión abierta.
También importa saber de dónde viene cada información y quién puede corregirla. Si el cliente describe el síntoma y el técnico registra el diagnóstico, ambos campos tienen funciones distintas. Sustituir uno por otro puede borrar contexto que ayuda a comprender la solicitud y explicar la respuesta posterior.
Al dar contexto a la IA con criterio, incluye ejemplos representativos y explica el papel de cada documento. Una hoja antigua puede mostrar cómo se organizaban las solicitudes sin determinar que todas sus columnas deban existir en la nueva aplicación. La relevancia del material depende de la decisión que ayuda a tomar.
Escribe resultados que puedas observar
Una especificación útil describe el resultado esperado en situaciones concretas, incluidas al menos las excepciones que modifican la decisión principal. Sustituye palabras vagas por comportamientos observables. En lugar de pedir una aplicación intuitiva, explica qué debe poder encontrar, hacer y confirmar la persona al recorrer la tarea definida.
En el taller, un caso puede empezar con una solicitud completa que todavía no tiene técnico asignado. Cuando el responsable lo asigna, el nombre debe quedar asociado a la solicitud y visible para quienes siguen el trabajo. Ese resultado permite verificar una función sin depender de una opinión genérica sobre la calidad del panel.
Otro caso puede tener información insuficiente sobre el equipo. La aplicación debe mostrar qué falta y mantener la solicitud en el estado previsto, en lugar de presentarla como lista para analizar. La excepción obliga a aclarar la relación entre los datos disponibles y la acción permitida en ese momento.
Pide que la IA contraste los ejemplos con las reglas y busque contradicciones antes de implementar. Si un caso aceptado exige una acción que otra regla prohíbe, queda una elección por resolver. Encontrar esa incoherencia en el documento permite discutirla antes de que existan pantallas y datos dependientes de interpretaciones distintas.
Entrega una primera versión delimitada de la especificación
La primera especificación debe contener el recorrido elegido, las reglas aceptadas, los ejemplos de validación y los límites de lo que se construirá. Incluye las cuestiones aplazadas y las acciones que exigen una decisión tuya. Pide una lectura de confirmación para saber si la IA entendió el mismo resultado antes de avanzar.
Esa confirmación puede ser una explicación breve del recorrido, acompañada de las decisiones de mayor impacto. Si la IA solo repite la lista de funcionalidades, aún no sabes si comprendió la relación entre ellas. En el ejemplo del taller, interesa que pueda explicar cuándo una solicitud está lista para derivarse.
El siguiente paso es planificar la construcción de la aplicación a partir de esa base. La especificación describe el comportamiento deseado; el plan organiza el trabajo para obtenerlo y verificarlo. Mantener esa distinción ayuda a revisar la implementación sin dejar que una elección técnica cambie silenciosamente una regla del negocio.
Durante la construcción surgirán preguntas nuevas y algunas respuestas pueden mejorar la idea inicial. Actualiza la especificación cuando aceptes un cambio relevante, indicando qué sustituyó a la decisión anterior. Así, el documento sigue orientando el trabajo en curso y permite comprender por qué la aplicación tiene el comportamiento elegido.