Por Thomas Cohen, fundador de Maestro
Crear una aplicación interna para un equipo pequeño
Reparte las decisiones, evita reservas incompatibles y organiza un piloto: una guía práctica para construir una herramienta con las personas que la utilizarán.
Tu equipo quiere una aplicación interna. Cada persona conoce una parte del trabajo: planificación, seguimiento de peticiones o información que debe transmitir. Antes de construir, convierte esas expectativas en decisiones comunes: qué entra en la primera versión, quién puede hacer qué y cómo comprobar el resultado cuando varias personas trabajan juntas.
Sigamos a un colectivo ficticio que presta herramientas y organiza talleres de reparación. Maya prepara las jornadas, Étienne controla el material y Alice recibe a los participantes. Trabajan en horarios diferentes y quieren gestionar mejor las reservas. Los nombres, la asociación y las situaciones son inventados para explicar un método para equipos pequeños; no son un testimonio de cliente.
1. Parte de un relevo que causa problemas
Pide a cada persona que cuente una situación reciente de principio a fin. Evita empezar con «necesitamos un panel». Averigua quién espera qué información, cuándo la necesita y qué ocurre si no la recibe. La necesidad de un equipo suele aparecer entre dos tareas, cuando el trabajo de uno debe servirle al siguiente.
En el colectivo, Alice recibe por teléfono una petición de taladro y la apunta en una libreta. Étienne ve un taladro en la estantería y se lo presta a otra persona. El problema no es solo registrar más rápido: no comparten una reserva confirmada antes de prometer la misma herramienta a dos personas.
Reconstruye ese recorrido con ejemplos preparados para la conversación. ¿Dónde llega la petición? ¿Quién la confirma? ¿Cuándo deja de estar disponible el material? ¿Cómo se avisa de una devolución tardía? Anota las respuestas distintas. Señalan reglas que tienes que acordar con tu equipo, no una culpa que atribuir a un compañero.
Escribe una frase con el resultado esperado: «Antes de confirmar un préstamo, cualquiera debe poder ver si la herramienta está disponible para ese periodo». Esa frase da un criterio a la primera prueba. Evita construir una aplicación llena de funciones que deje intacto el desacuerdo inicial.
2. Nombra quién decide, quién aporta y quién comprueba
Un equipo pequeño puede decidir rápido si la responsabilidad está clara. Elige a alguien que reúna las peticiones y delimite el alcance. No se convierte en dueño de todas las ideas. Evita que se envíen instrucciones incompatibles en paralelo a la persona o los agentes que construyen.
Maya asume ese papel en el ejemplo. Étienne explica las reglas de préstamo y comprueba el seguimiento del material. Alice prueba la recepción y las reservas. Una persona con los conocimientos necesarios se encarga de las decisiones técnicas y del mantenimiento. Alguien puede asumir varios papeles, pero ninguno debe quedar implícito.
- Quien decide acepta una función, la pospone o pide aclaraciones.
- Los usuarios describen las situaciones y las excepciones que encuentran.
- Quienes verifican prueban los recorridos y anotan los resultados observados.
- La persona de mantenimiento prepara los accesos, las correcciones y la continuidad.
Prepara también la sustitución del responsable. Si Maya falta, ¿quién puede autorizar una corrección urgente y cuánto puede gastarse? Una breve regla escrita evita esperar un mensaje informal para cada decisión. La herramienta puede ayudar a conservar los acuerdos, pero no puede decidir legítimamente las prioridades por tu equipo.
3. Crea una primera versión que conecte los papeles
Es tentador pedir una pantalla para cada persona: calendario de Maya, inventario de Étienne y lista de Alice. Empieza por un recorrido que conecte sus acciones. Una primera versión útil permitiría solicitar una herramienta, confirmar su disponibilidad, registrar su salida y anotar su devolución.
Ese recorrido debe estar completo dentro de un alcance limitado. El colectivo selecciona algunas herramientas de prueba y deja fuera los pagos, las cuotas y los mensajes automáticos. Todavía no sustituye toda su organización. Escribe las exclusiones para que una pantalla añadida a mitad de camino no cambie el objetivo sin que nadie lo advierta.
Prepara situaciones que obliguen a decidir: préstamo normal, devolución tardía, herramienta no disponible y cancelación. Indica para cada una el punto de partida, la acción y el resultado esperado. Una maqueta enseña las pantallas; estas situaciones explican cómo espera el equipo que funcione la aplicación.
El documento de requisitos sin lenguaje técnico ayuda a reunir ese alcance. Pide que lo lea alguien que atienda una jornada sin participar en el proyecto. Si entiende qué podrá hacer y qué queda fuera, tienes una base mejor que una lista de funciones con nombres atractivos.
4. Define un vocabulario y una información comunes
Una aplicación compartida no reconcilia por sí sola hábitos diferentes. ¿«Reservado» significa solicitado, aceptado o ya entregado? ¿«Disponible» incluye una herramienta en reparación? Define las palabras antes de elegir colores. Una interfaz clara puede llevar a decisiones equivocadas si cada persona interpreta los estados de forma distinta.
El colectivo distingue «solicitud recibida», «reserva confirmada», «herramienta entregada» y «devolución registrada». Una herramienta en reparación sigue sin estar disponible aunque esté en la estantería. Étienne confirma qué cambios se permiten: una solicitud puede cancelarse; una herramienta entregada necesita una devolución o el aviso correspondiente.
Asigna una referencia estable a cada herramienta. Debe ser posible distinguir dos taladros idénticos si su disponibilidad es diferente. Decide también qué datos necesitas de quien recibe el préstamo. Una nota libre no debe convertirse en un lugar donde acumular detalles personales sin utilidad para gestionar ese préstamo.
Prepara un pequeño glosario con un ejemplo por estado. Añade quién puede corregir un error y cómo encontrar después esa corrección. Mantén el documento junto a la aplicación durante las pruebas. Si aparece un término nuevo, pregunta por qué hace falta antes de que surjan dos formas de describir la misma situación.
5. Define los permisos a partir de las acciones
Escribe qué acciones necesita cada papel: consultar disponibilidades, confirmar una reserva, corregir una devolución, exportar una lista o gestionar cuentas. «Miembro del equipo» resulta demasiado amplio. Alice y Étienne pueden necesitar información diferente aunque trabajen para la misma asociación.
La CNIL recomienda limitar los permisos a lo necesario para la función y revisarlos. Convierte esa regla en situaciones que los usuarios puedan comprobar.
En la prueba ficticia, Alice puede confirmar un préstamo, pero no cambiar el estado de reparación. Étienne puede declarar disponible la herramienta después de revisarla. Maya puede organizar una sustitución temporal. Prueba acciones permitidas y denegadas con cuentas distintas, incluido abrir un enlace recibido de otro usuario.
El final de una jornada o la salida de un voluntario también necesitan un tratamiento previsto. ¿Quién comunica el cambio y quién lo aplica? Conserva instrucciones adecuadas para el equipo. Una configuración correcta al empezar no garantiza que siga siéndolo si cambian las responsabilidades y nadie se ocupa de los accesos.
6. Prevé dos personas en el mismo expediente
Alice y Étienne abren la misma disponibilidad con segundos de diferencia. Ambos ven un taladro libre y confirman una reserva para el sábado. Si la aplicación acepta las dos peticiones sin comprobarlas, las pantallas pueden parecer correctas mientras el colectivo acaba de prometer dos veces una sola herramienta.
Describe la regla antes de pedir que se construya: solo una reserva confirmada puede ocupar esa herramienta durante un periodo concreto. La segunda persona necesita una explicación y la posibilidad de ajustar su petición. No debe creer que la operación ha terminado bien si fue rechazada o su resultado sigue siendo incierto.
La documentación de PostgreSQL sobre operaciones simultáneas describe conflictos y repeticiones necesarias. Su tratamiento depende de la aplicación y requiere comprobación técnica.
Prepara después una prueba con dos cuentas. Abre el mismo periodo, confirma casi a la vez y comprueba ambos resultados y la lista final. Repite con una cancelación y una devolución tardía. Tu papel es validar el comportamiento de trabajo; la persona técnica debe revisar el mecanismo que lo garantiza.
7. Organiza las peticiones sin cambiar de rumbo cada día
Mantén una sola lista de peticiones, accesible para las personas implicadas. Cada entrada describe la situación, la consecuencia y el resultado deseado. Una captura puede ayudar, pero necesita una explicación. «Cambiar este botón» no permite saber si se corrige un error, una dificultad de uso o una preferencia.
Alice pide un botón para ampliar un préstamo. Étienne se opone porque puede haber otra reserva a continuación. Maya reformula la necesidad: ampliar solo si la nueva fecha no bloquea una reserva confirmada. La conversación termina en una regla, en vez de alternar instrucciones que deshacen el trabajo anterior.
Ordena las peticiones según sus consecuencias: lo que bloquea o altera una operación, lo que dificulta el recorrido y las mejoras que pueden esperar. Añade la decisión y su motivo. Una idea pospuesta sigue visible sin prometerse para la semana siguiente ni volver a discutirse en cada conversación.
Antes de modificar algo, pide que se concreten los recorridos afectados y las pruebas que habrá que repetir. La guía para dirigir un proyecto de aplicación amplía esta organización. Decidir menos cosas a la vez ayuda a saber qué cambio produjo el resultado que estás examinando.
8. Separa participar en el proyecto de utilizar la aplicación
Construir juntos puede significar ver una demostración, comentar un documento o probar una versión. No exige que cada persona use la herramienta de creación o dé instrucciones directamente a los agentes. Elige una participación adecuada a sus responsabilidades, disponibilidad y funciones realmente disponibles.
Maya podría dirigir la construcción desde su ordenador y preparar una sesión de prueba para Alice y Étienne. Los comentarios se reúnen en el documento común antes de enviar otra petición. Puede funcionar en un equipo pequeño siempre que la ausencia de Maya no vuelva imposibles de encontrar los documentos y las decisiones.
La aplicación final debe prever los dispositivos y lugares de uso: recepción, almacén y quizá domicilio. Pide que se explique cómo accede cada persona y cómo se comparte la información. Construir en un ordenador local no convierte automáticamente el resultado en una aplicación para varias personas ni elimina la necesidad de un servicio central.
Prueba las condiciones materiales reales con datos ficticios: pantalla pequeña, conexión inestable y alguien que vuelve tras una semana de ausencia. Anota qué falta para retomar el trabajo sin explicación oral. Estas observaciones suelen ser más útiles que debatir en abstracto el número teórico de usuarios que admite una herramienta.
9. Haz un piloto con una referencia clara
Elige un periodo limitado y algunos usuarios representativos. Indica dónde están las reservas que cuentan como oficiales. Al principio, el colectivo puede trabajar con copias ficticias para validar los recorridos. En una prueba real debe decidir dónde registrar cada información y cómo evitar dos listas contradictorias.
Nombra a quien dirige la prueba, un canal para avisar de problemas y las condiciones de parada. Una doble reserva sin explicación bloquea el avance. Un texto confuso requiere corregirse. Una preferencia de color puede esperar. Así, la decisión final no depende solo del entusiasmo de quien construyó la aplicación.
- Alice reserva una herramienta disponible y encuentra la confirmación.
- Étienne intenta confirmar una reserva incompatible y recibe el rechazo esperado.
- Una herramienta devuelta tarde sigue identificada correctamente.
- Alguien retoma un expediente tras la ausencia de un compañero.
- Se corrige un error y las personas implicadas ven el resultado.
Conserva el resultado de cada prueba, su contexto y la versión examinada. Tras corregir, repite los recorridos afectados. Antes de ampliar el piloto, pregunta qué hacen aún los usuarios en otro lugar para terminar: una libreta paralela puede revelar información que falta o una regla que la aplicación todavía no refleja.
10. Prepara ausencias, incidentes y mantenimiento
Una aplicación interna puede volverse imprescindible rápidamente. Describe qué hace el equipo si no puede abrirla, si un dato parece incorrecto o si falta la persona habitual. Un procedimiento breve debe permitir continuar con cuidado, comunicar el problema y recuperar los registros realizados durante la interrupción.
En el ejemplo, Maya prepara una hoja de respaldo numerada para los préstamos autorizados durante una avería. El colectivo indica quién puede usarla y quién incorporará después esos movimientos. Este sistema ficticio necesita adaptación y pruebas: apuntar préstamos en papel no resuelve nada si nadie los concilia con las reservas existentes.
Nombra a la persona o al proveedor de mantenimiento, los horarios de disponibilidad esperados y cómo pedir una intervención. Guarda las instrucciones de recuperación y los accesos en un lugar adecuado. Otra persona autorizada debe saber encontrarlos sin depender de mensajes dispersos en varias conversaciones.
Reserva presupuesto para mantener y tiempo para probar después de corregir. La diferencia entre un prototipo y una aplicación utilizable se ve especialmente cuando varias personas dependen de la misma herramienta. Terminar la construcción no termina las decisiones que debéis tomar juntos.
11. Mide qué ha cambiado en el trabajo
Antes del piloto, elige observaciones sencillas: reservas que necesitan corrección, datos introducidos dos veces y peticiones que obligan a llamar a un compañero. Mantén la misma definición durante la prueba. Podrás comparar situaciones sin inventar una mejora de productividad solo porque la interfaz parezca más moderna.
Pide a Alice que enseñe cómo prepara una jornada y a Étienne cómo comprueba las devoluciones. ¿Dónde siguen buscando respuestas? ¿De qué información desconfían? Anota sus explicaciones. Una herramienta puede reducir una tarea visible y añadir una comprobación manual menos visible a otra persona.
El tiempo del equipo también cuenta: describir reglas, preparar datos, probar, formar y corregir. Si Maya evita una doble introducción de datos, pero pasa cada jornada explicando la aplicación, el problema aún no está resuelto. Esa observación señala una prioridad de mejora, no necesariamente un motivo para abandonar el proyecto.
12. Prepara el documento para los agentes o el profesional
Reúne la necesidad, los papeles, los estados, los permisos y las pruebas en un documento compartido. Añade las decisiones pospuestas y los límites aceptados. Pide a un compañero que encuentre solo la regla sobre reservas incompatibles. Si la respuesta aún está únicamente en una conversación, el documento necesita un pequeño repaso.
Puedes empezar con la plantilla gratuita de requisitos. Describe una petición cada vez y pide una explicación del comportamiento propuesto antes de construirlo. Los agentes pueden ayudar a preparar documentos y código; las personas del equipo siguen siendo responsables de las decisiones de trabajo y su validación.
Maestro permite dirigir un proyecto con agentes de IA en Mac. Esto no promete edición simultánea entre compañeros: debes definir y comprobar con tu equipo la organización del trabajo y las funciones compartidas de la aplicación final. Empieza con un piloto dirigido por alguien que reúna las aportaciones del equipo.
A 23 de septiembre de 2026, Maestro está en beta por invitación para macOS 13 y versiones posteriores. La aplicación es gratuita durante esta beta y el uso de IA se factura aparte; Windows está en desarrollo. El primer resultado sigue siendo sencillo: completar un relevo con la misma información y una regla que todos entiendan.