Cómo preparar el encargo de una aplicación sin redactar una especificación técnica.

La descripción de un proyecto no necesita empezar por un diagrama de base de datos. Necesita explicar qué trabajo debe poder completar una persona y qué resultado espera el negocio.

El objetivo inicial es poder hablar del proyecto con claridad. Puedes dejar abiertas las decisiones técnicas y, al mismo tiempo, concretar el proceso que debe cubrir la aplicación.

Empieza por un usuario y una tarea

“Crear un portal” indica un tipo de software. “Permitir que un cliente aprobado envíe una solicitud y consulte su estado” describe un primer proceso útil.

Identifica al usuario, la acción y el resultado. Después explica quién atiende la otra parte del proceso. En este ejemplo, alguien del equipo debe revisar la solicitud y actualizarla. Ya aparecen dos roles distintos y un registro compartido.

Evita empezar por “una aplicación para todo el mundo”. Cada usuario puede necesitar permisos, pantallas e información diferentes. Decide qué rol es prioritario en la primera versión.

Explica qué ocurre ahora

Describe los pasos actuales con lenguaje habitual. Quizá el cliente envía un correo, una persona copia la información a una hoja de cálculo y otra comunica el progreso. Indica dónde se repite trabajo o surgen dudas, sin asumir que el software resolverá todos los problemas del proceso.

Un ejemplo del formulario o registro actual puede resultar más útil que una presentación elaborada. Elimina datos personales y detalles confidenciales antes de compartirlo.

Describe un recorrido completo

Sigue un registro representativo desde el inicio hasta el final. ¿Qué lo crea? ¿Qué información necesita? ¿Quién toma la siguiente decisión? ¿Cuándo se considera terminado?

Incluye una o dos excepciones importantes. Puede faltar información, una solicitud puede rechazarse o el usuario puede necesitar corregir un error. Esos casos distinguen una aplicación útil de una demostración que solo funciona en la situación ideal.

No hace falta enumerar todos los eventos poco frecuentes. Céntrate en las excepciones que impedirían utilizar el proceso principal.

Identifica los datos y las dependencias

Enumera los registros importantes: usuarios, solicitudes, productos, reservas, archivos u otra información. Explica de dónde proceden y quién los mantiene.

Si hay una integración, indica el servicio externo y aporta su documentación cuando exista. “Conectar con nuestro CRM” deja muchas preguntas abiertas. Lo útil es explicar qué registro se transmite, en qué dirección y a partir de qué evento.

Aclara si ya dispones de diseños, contenidos, accesos o reglas de negocio. Lo que falta no siempre impide empezar, pero necesita un responsable y un lugar en el plan.

Define la primera versión útil

Separa la entrega principal de las ideas futuras. Un primer portal puede permitir crear una solicitud, revisarla y consultar su estado. La mensajería, los informes avanzados o una app móvil pueden quedar para después, en lugar de convertirse en requisitos implícitos.

No se trata de entregar algo incompleto. El proceso elegido debe funcionar de principio a fin. El límite debe estar entre procesos completos, no entre una pantalla atractiva y la lógica que todavía le falta.

Escribe un ejemplo de aceptación

Prueba con una frase que alguien pueda comprobar:

Un cliente aprobado puede enviar una solicitud, consultar su estado al acceder a su cuenta y ver únicamente sus propias solicitudes. Una persona autorizada del equipo puede actualizar el estado y el cliente ve ese cambio.

Es un requisito ilustrativo, no la descripción de un cliente existente. Explica mejor el comportamiento esperado que “un portal moderno y seguro”. El alcance posterior puede concretar permisos y casos especiales.

Añade las condiciones prácticas

Indica las fechas deseadas, si son orientativas o responden a un compromiso externo, y el rango de presupuesto cuando lo conozcas. Nombra a la persona que aprueba las decisiones y explica cómo se aportarán diseños y comentarios.

Incluye las expectativas de publicación y entrega. ¿Quién será titular del alojamiento y las cuentas? ¿Otro desarrollador debe recibir el código? Estas cuestiones influyen aunque no aparezcan en una pantalla.

Una estructura que puedes utilizar

Queremos desarrollar: la aplicación o el proceso. Los usuarios principales son: personas y roles. Necesitan hacer: la tarea y su resultado. Ahora se hace mediante: el proceso actual. La primera versión debe incluir: el recorrido completo imprescindible. Debe conectarse con: sistemas y documentación conocidos. Ya tenemos: diseños, contenidos, cuentas o ejemplos de datos. Queda por decidir: las preguntas abiertas. Fechas, presupuesto y responsable: las condiciones prácticas.

Bastan unas frases claras en cada apartado. La descripción es un punto de partida para definir el proyecto, no un examen que debas superar antes de hablar con un desarrollador.

Consulta el desarrollo de aplicaciones web o envíanos tu proyecto.