Un atril de músico de latón sostiene un documento impreso, con un portátil cerrado a sus pies

· 6 min de lectura · Actualizado el

También conviene conservar las reglas de tu aplicación

Un descuento, una cancelación, un acceso restringido: estas decisiones explican tu aplicación. Tenerlas por escrito facilita las correcciones y la continuidad del trabajo.

Tomemos un ejemplo ficticio: tu aplicación ofrece un descuento a los clientes habituales. Seis meses después cambias la regla: un 15 % a partir del tercer pedido. Si la decisión anterior solo existe en una conversación olvidada, quien haga el cambio tendrá que encontrarla primero, o adivinarla.

Qué significa una especificación

Una especificación describe lo que debe hacer la aplicación en una situación concreta. Aquí: qué pedidos cuentan, desde cuándo se aplica el descuento y sobre qué importe se calcula.

La palabra puede sonar técnica. El contenido lo es mucho menos: «Un pedido cancelado no cuenta entre los tres pedidos necesarios» es una regla que puedes escribir y comprobar sin programar.

Conserva las decisiones que cambian el resultado

No necesitas documentar cada reunión. Guarda las reglas importantes, las personas implicadas y las preguntas pendientes. Para una reserva, puede ser el plazo de cancelación; para un presupuesto, su periodo de validez.

Anota también por qué elegiste una regla cuando esa razón pueda servir más adelante. «Necesitamos un día para reorganizar el calendario» explica mejor un plazo que una cifra aislada.

Actualiza el documento cuando cambie la necesidad

Si el descuento pasa del 10 % al 15 %, modifica la regla escrita e indica desde cuándo se aplica. Aclara qué ocurre con los pedidos anteriores: ¿también les corresponde el nuevo porcentaje?

Pide después una comprobación con un pedido antiguo y otro nuevo. El documento, la aplicación y las pruebas deben contar lo mismo. Un texto conservado que ya no es correcto también puede provocar errores.

Facilita la continuidad del trabajo

El código sigue siendo necesario para ejecutar y modificar la aplicación. Los documentos ayudan a quien retoma el trabajo a entender lo que debe conservar. Una cosa no sustituye a la otra.

Guarda también los datos, los accesos y las instrucciones de funcionamiento útiles. Comprobar que puedes dejar una herramienta exige algo más que descargar una carpeta. Los documentos por sí solos tampoco acreditan los derechos que tienes sobre el programa.

Empieza con una sola página

Escribe tres reglas importantes para tu actividad y un ejemplo correcto de cada una. Añade una pregunta pendiente y el nombre de la persona que puede responderla.

La guía del documento de requisitos te ayuda a completar esa página. En Maestro, los documentos preparados con los agentes sirven para conversar: revisa las reglas de tu actividad y pide que se corrijan cuando se hayan entendido mal.

Dentro de Maestro · demo integrada Tablée · captura del 6 de septiembre de 2026
Ejemplo Tablée de Maestro: conversación a la izquierda y especificación del producto a la derecha, con objetivos y requisitos funcionales. La interfaz está en francés.
La necesidad se convierte en un documento que puedes revisarEn el ejemplo Tablée, la especificación reúne los objetivos y los requisitos funcionales. Esta captura muestra el documento en Maestro; ilustra la forma de trabajar, no la validación de todas sus reglas.Captura de la interfaz en francés.Ampliar la captura

Leer la guía completa: crear una aplicación sin programar

Volver al diario

Toma la batuta.

Deja tu correo para probar Maestro en las primeras tandas.

La beta está abierta por invitación en macOS 13 y versiones posteriores. Deja tu email para una próxima tanda de acceso. Windows está en preparación.

La beta está disponible actualmente en macOS 13 o posterior. Tu respuesta nos ayuda a preparar otras versiones.

Tu correo solo se usa para avisarte de la apertura. Nada más, prometido.