Saltar al contenido
Todos los proyectos de ejemplo

App web

Nota de turnos

Anotar turnos y ver tu propia semana de un vistazo

Una app web que permite anotar un turno en menos de diez segundos y ver la semana siguiente de un vistazo.

Ejemplos didácticos construidos: estos tres proyectos se escribieron para el curso siguiendo las reglas documentadas de los siete días. No son proyectos reales de personas usuarias, no hay ninguna app en marcha, ni enlace en vivo ni ficha de tienda. La prueba aquí son las decisiones, no una captura de pantalla.

Para qué se construyó

Quien trabaja por turnos suele tener el plan como foto en el móvil o en un papel. La pregunta «¿trabajo el sábado?» cuesta entonces una búsqueda cada vez. La app responde rápido justo a esa pregunta; no sustituye al cuadrante de la empresa.

El bucle central en cuatro pasos

  1. 1Abrir — la semana actual está ahí al momento
  2. 2Anotar un turno — día, inicio, fin
  3. 3Ver la semana — qué viene, cuántas horas
  4. 4Planificar la semana siguiente — avanzar y anotar

Dejado fuera a propósito

Reducir el alcance es el trabajo real del día 1. Estos puntos habrían hecho el proyecto más grande sin mejorar el bucle central.

  • Sin cuadrante de equipo o departamento: en cuanto varias personas ven el mismo plan hacen falta cuentas, permisos y resolución de conflictos. Eso es otro producto.
  • Sin exportación a calendario o PDF: útil, pero no hace que «¿trabajo el sábado?» se responda más rápido.
  • Sin cálculo de sueldo o pluses: depende de convenio, país y contrato. Mal calculado es peor que no calculado.
  • Sin recordatorios ni notificaciones: exigen permisos y un servicio en marcha, y no corresponden a una primera versión.
  • Sin cuenta ni sincronización: los datos se quedan en el navegador. Eso descarta cambiar de dispositivo y fue el precio consciente de los siete días.

Objetivo de publicación

App web accesible públicamente en su propia dirección. Sin tienda, sin instalación, sin cuenta.

Los siete días de construcción

Para cada día se indica por separado qué quedó visible después y qué decisión había detrás. Donde algo no funcionó al principio, también consta.

  1. 1Día 1 — Tu alcance está definido

    Qué se construyó
    Una especificación de una página: persona destinataria, el problema central en una frase, el bucle central en cuatro pasos, cinco no-objetivos y el objetivo «app web accesible públicamente».
    Por qué así
    Como objetivo de publicación se eligió a propósito la app web y no la tienda. Así todo el camino hasta la publicación queda en las propias manos: sin verificación de cuenta, sin revisión, sin ventana de espera. Para un resultado de siete días esa es la diferencia entre «terminado» y «enviado y a esperar».
  2. 2Día 2 — Un build real funciona

    Qué se construyó
    Un proyecto en marcha con dos vistas — semana y anotación — y una navegación alcanzable con el pulgar. Los datos viven en local en el navegador.
    Por qué así
    En lugar de una base de datos se usó el almacenamiento local del navegador. Es la decisión con mayor ahorro de tiempo de todo el proyecto: sin servidor, sin cuenta, sin inicio de sesión, sin preguntas de protección de datos sobre datos personales almacenados. El precio consta como no-objetivo.
  3. 3Día 3 — Tu bucle central funciona

    Qué se construyó
    El flujo completo: anotar un turno, aparece en la semana, las horas semanales se actualizan, la semana siguiente es accesible.
    Por qué así
    La vista de semana llegó antes que el formulario de anotación. Quien construye primero el formulario prueba contra una superficie vacía y descubre tarde si la representación aguanta.
    Qué no funcionó al principio
    Los primeros datos de prueba fueron «turno 1» a «turno 5», todos de ocho horas. Así la semana se veía perfecta. Con datos reales — un turno partido, un turno de noche que cruza la medianoche — la representación se rompió al instante. El turno nocturno pasó entonces a ser un caso de prueba explícito.
  4. 4Día 4 — Tu app aguanta también los días malos

    Qué se construyó
    Cuatro estados: semana vacía con entrada, entrada inválida con motivo, un regreso tras semanas que aterriza en la semana actual y escalado de texto comprobado.
    Por qué así
    El estado vacío recibió el texto más largo de todo el proyecto. Es la primera pantalla que ve cada persona nueva: ahorrar ahí es ahorrar en el único sitio que ve todo el mundo.
    Qué no funcionó al principio
    El regreso aterrizaba al principio en la última semana consultada. Quien no abría la app durante cuatro semanas veía una semana antigua y la tomaba por la actual. El salto a la semana en curso fue la corrección.
  5. 5Día 5 — Operación, aspectos legales y costes

    Qué se construyó
    Política de privacidad, aviso legal y una dirección de soporte. Una línea en la app explica que los datos no salen del navegador.
    Por qué así
    No hay ninguna ruta de pago y por tanto tampoco límite de coste. Eso se anotó expresamente en vez de omitirse: «sin costes externos» es un resultado de la arquitectura, no una tarea olvidada. Quien no lo anota busca dentro de cuatro semanas el límite que falta.
  6. 6Día 6 — Un candidato de lanzamiento real

    Qué se construyó
    Un estado publicable, probado en dos navegadores y en un teléfono real, no solo en una ventana de escritorio estrechada.
    Por qué así
    La prueba en hardware real se hizo también para una app web. Una ventana de escritorio estrecha no tiene teclado en pantalla que tape media superficie, y justo ahí falló el formulario de anotación en el primer intento real.
  7. 7Día 7 — Tu decisión está documentada

    Qué se construyó
    Un registro con cada puerta de publicación y un sí o un no detrás, además de una lista V1.1 con cuatro puntos.
    Por qué así
    Se publicó. Lo decisivo no fue la exhaustividad, sino que el bucle central se recorriera entero en hardware real sin pérdida de datos. La exportación a calendario que falta encabeza la lista V1.1, con la frase que explica por qué no correspondía a la V1.

Llévatelo y remézclalo

La remezcla toma la idea, el bucle central, los no-objetivos y el objetivo de publicación como tu punto de partida, no la solución. Los siete días quedan idénticos: no te saltas ningún paso ni ningún criterio.

Encargo para tu herramienta de IA

Si prefieres empezar ya en lugar de pasar por la ruta: este encargo describe el proyecto con detalle suficiente para que una herramienta de IA pueda comenzar.

Estoy construyendo una pequeña app web: Nota de turnos — anotar turnos y ver mi propia semana de un vistazo.

Bucle central en cuatro pasos:
1. Abrir — la semana actual está ahí al momento
2. Anotar un turno — día, inicio, fin
3. Ver la semana — qué viene, cuántas horas
4. Planificar la semana siguiente

Expresamente NO en la versión 1: cuadrante de equipo/departamento, exportación a calendario o PDF, cálculo de sueldo y pluses, recordatorios, cuenta y sincronización.

Objetivo de publicación: app web accesible públicamente, los datos se quedan en local en el navegador.

Ayúdame a empezar:
1. Hazme las preguntas que necesites para el primer paso.
2. Propón la estructura de datos más pequeña que sostenga este bucle central.
3. Dime los tres casos de prueba con los que esta app fallará antes.

No cambies el alcance sin preguntarme.