La primera versión de una aplicación debe resolver una necesidad reconocible, aunque deje otras ideas para después. Quien la use ha de poder empezar una tarea, completarla, conservar el resultado y continuar si aparece un error previsto.
“Habrá tres pantallas” no explica ese límite. “Podré registrar una decisión, encontrarla después y conservar el trabajo anterior si una importación falla” sí permite discutir qué hay que construir. Puedes aportar el resultado y tus prioridades; Ricardo puede ayudarte a concretar reglas, alcance y comprobaciones, tanto si partes de una idea como si traes requisitos preparados.
Elige una tarea que llegue hasta el resultado
Para conversar sobre esa tarea, estas cinco partes sirven de guía:
- Disparador: qué lleva a utilizar la aplicación.
- Entrada: qué información se aporta o selecciona.
- Acción y reglas: qué se hace y bajo qué condiciones.
- Resultado: qué cambia y dónde queda.
- Recuperación: qué ocurre si falta un dato o el proceso no termina.
No necesitas escribirlo todo ni conocer los detalles técnicos antes de pedir ayuda. Reconocer el resultado esperado ya permite empezar; las decisiones abiertas pueden resolverse durante la definición del proyecto.
Un ejemplo de principio a fin
Cuaderno de decisiones es un ejemplo ficticio. Su primera versión permite que una persona conserve decisiones de un proyecto y vuelva a encontrarlas.
| Parte | Decisión del ejercicio |
|---|---|
| Disparador | Registrar una decisión antes de perder su contexto |
| Entrada | Proyecto, título, motivo y estado |
| Acción | Crear, corregir y cambiar estado |
| Resultado | La decisión aparece en su proyecto y se localiza por texto o estado |
| Continuidad | Lo guardado se recupera al volver y se puede exportar |
| Error | Un archivo inválido se rechaza conservando el contenido anterior |
El mapa ayuda a decidir qué pertenece a la primera entrega. Un formulario para añadir una decisión aporta poco si después se pierde al cerrar. En cambio, adjuntar archivos puede esperar si el texto ya permite registrar el contexto necesario.
Inicial posterior y excluido con una razón
| Unidad | Versión | Razón y dependencia | Aceptación |
|---|---|---|---|
| Crear proyecto | Inicial | Organiza las decisiones; necesita nombre válido | Se crea y reaparece al abrir la aplicación |
| Añadir y editar decisión | Inicial | Resuelve la tarea; necesita campos y estados definidos | Guarda, permite corregir y conserva el cambio |
| Buscar y filtrar | Inicial en este ejemplo | Recupera decisiones cuando la lista crece | Encuentra por texto/estado y explica la ausencia de resultados |
| Exportar e importar | Inicial en este ejemplo | Permite conservar y trasladar el registro | Recupera contenido y estados; rechaza un archivo inválido sin pérdida |
| Varias personas | Posterior | Cambia la tarea a coordinación; necesita identidad, permisos y conflictos | Definir acciones permitidas antes de compartir datos |
| Avisos de revisión | Posterior | Depende de cuándo merece la pena avisar y por qué canal | Incorporar cuando exista una necesidad concreta |
| Adjuntos | Posterior | Añade almacenamiento, formatos y acceso | Definir archivos, límites y quién puede consultarlos |
| Cobros reales | Excluido de esta versión | No sostiene la tarea individual del ejercicio | Se especificaría en otro alcance |
Las decisiones son propias de este ejemplo. Otra aplicación puede necesitar colaboración desde el principio o no necesitar importación. El criterio es qué sostiene su tarea principal, no copiar esta lista como una receta.
El mapa de alcance de producto permite guardar cada unidad con razón, dependencia, error y criterio. Es una ampliación editable para revisar juntos el encargo, no un documento que debas entregar para iniciar la conversación.
Comprueba qué significa cada pantalla
“Nueva decisión” parece una función clara, pero todavía necesita respuestas:
- ¿Qué campos son obligatorios?
- ¿Qué significa cada estado?
- ¿Se permite registrar dos decisiones con el mismo título?
- ¿Quién puede corregir una decisión tomada y qué motivo conserva?
- ¿Cómo se reconoce que se ha guardado?
- ¿Qué ocurre si el guardado falla?
- ¿Dónde se encuentra esa decisión la próxima semana?
Una captura puede mostrar el formulario. Estas preguntas describen el comportamiento que debe existir detrás y que el profesional concretará contigo a partir del uso previsto.
En el Cuaderno, por ejemplo, se puede permitir un título repetido porque dos proyectos distintos comparten una pregunta. La identidad del registro y su proyecto permiten distinguirlos. Si el negocio necesitara otra regla, habría que expresarla antes de tratar una repetición como error.
Recorta sin romper el trabajo
Para cada idea, plantea tres preguntas:
- ¿Qué tarea quedaría incompleta si la quitamos?
- ¿Qué regla, dato o dependencia añade?
- ¿Cómo comprobaríamos que aporta el resultado esperado?
Eliminar adjuntos mantiene el recorrido individual del Cuaderno. Eliminar guardado y recuperación cambia su propósito: ya no conserva un registro. La diferencia está en la función, no en el tamaño aparente de cada botón.
También se puede simplificar una capacidad sin eliminarla. La búsqueda inicial puede cubrir título y estado sin incorporar un buscador avanzado. La exportación puede usar un formato documentado sin conectarse todavía con otras aplicaciones.
Incluye errores que permitan continuar
| Acción | Resultado correcto | Recuperación que debe estar definida |
|---|---|---|
| Guardar decisión | Aparece en el proyecto | Indicar un título vacío sin borrar el motivo escrito |
| Cambiar estado | El cambio reaparece al volver | Conservar y mostrar qué modificación no pudo guardarse |
| Importar archivo | Se recuperan datos válidos | Explicar incompatibilidad sin sustituir el registro anterior |
| Buscar | Aparecen coincidencias | Distinguir sin resultados de un fallo de carga |
| Usar almacenamiento | El guardado se confirma | Si falla, permitir conservar o exportar el trabajo de la sesión |
“Manejar errores” resulta demasiado general para revisar una entrega. La tabla permite describir qué espera la persona y qué evidencia se necesita.
Cuando la aplicación pasa a un equipo, aparecen errores y decisiones de acceso. La guía de usuarios, roles y datos muestra cómo concretarlos sin reducirlos a esconder controles de interfaz.
Reconoce cuándo estás añadiendo otra capacidad
“Ya que guardamos decisiones, añadamos comentarios, menciones y avisos”. La idea puede ser útil, pero introduce conversación, destinatarios y reglas de notificación.
“Ya que hay proyectos, demos acceso a todo el equipo”. Ahora hay que decidir identidad, permisos y cambios simultáneos.
“Ya que puede usarse como producto, añadamos planes y cobros”. Aparecen acceso, facturación, incidencias y continuidad del servicio.
No hace falta descartar esas ideas. Llévalas al mapa con su razón y dependencias. El artículo de convertir un servicio en SaaS desarrolla ese cambio de operación cuando tenga sentido.
Una revisión que puedes hacer antes de encargar
Al revisar una propuesta, comprueba si el recorrido se entiende y llega al resultado. Si para completar la tarea necesita una función dejada para después, habrá que revisar el límite.
Cada unidad inicial debería tener una entrada, un resultado y un caso de error que el equipo pueda comprobar. Deja visibles las decisiones que Ricardo te ayudará a resolver; no hace falta rellenarlas con suposiciones para que el documento parezca acabado.
El resultado es un alcance que puedes guardar, compartir y utilizar al revisar avances: qué se construye ahora, qué espera y qué debe funcionar para aceptar la primera entrega. Si aún no tienes ese mapa o ya cuentas con requisitos, puedes contarle a Ricardo qué aplicación necesitas.