Elige una tarea útil para un grupo definido de personas y asegúrate de que puedan terminarla. La primera versión debe incluir las correcciones, los permisos de acceso y la ayuda necesarios para que esa tarea siga funcionando. Las funciones adicionales pueden llegar después, cuando ese alcance esté claro.
Para la primera versión, elige una tarea que alguien pueda terminar. Incluye también lo necesario para completarla cuando un dato sea incorrecto, falte un compañero o el sistema necesite atención.
Imagina un lunes por la mañana: una persona abre el programa, hace un trabajo útil y deja un resultado en el que la siguiente persona puede confiar.
Imagina una empresa de mantenimiento ficticia que va a crear un sistema de órdenes de trabajo. Los primeros usuarios serán la persona que coordina los trabajos desde la oficina y un equipo de mantenimiento. La primera registra una tarea y la asigna; el equipo anota lo que ha hecho. Después, la persona coordinadora revisa el resultado y cierra la orden.
Eso podría ser una primera versión útil. «Una pantalla de órdenes de trabajo» dice mucho menos. ¿Puede el equipo ver la asignación? ¿Puede alguien corregirla? ¿Qué significa que una orden esté cerrada?
Define las personas y el resultado antes de decidir cuántas pantallas crear. Un flujo de trabajo completo puede necesitar varias pantallas y perfiles. El número de pantallas dice muy poco sobre si el programa servirá para trabajar.
La guía del Gobierno británico sobre la fase beta explica cómo crear y probar un servicio que responda a las necesidades de sus usuarios, incluido el recorrido completo y las personas que lo apoyan. El proceso de la administración británica tiene sus propios requisitos. Para esta empresa de mantenimiento, la pregunta útil es si el grupo elegido puede llevar una orden hasta el final.
En nuestro ejemplo ficticio, la persona coordinadora asigna una orden al equipo equivocado. El equipo lo descubre antes de salir del almacén. Alguien debe corregir la asignación, y ambos equipos deben poder ver cuál es la versión vigente. Dejar la corrección para más adelante abriría un hueco en el trabajo que te has comprometido a cubrir.
Revisa el trabajo propuesto con quienes lo hacen. Pregunta quién puede crear, modificar, asignar y cerrar una orden, y quién puede ver la información. Decide qué ocurre si el trabajo no puede terminarse: quizá no se puede entrar en el edificio o hay que pedir una pieza. La orden necesita un siguiente estado acordado y una persona responsable.
Crear, asignar, corregir y completar una orden de trabajo. Limitar el acceso según el perfil. Mantener visibles las órdenes pendientes y ofrecer ayuda al personal.
El autoservicio para clientes, la planificación de rutas y la facturación automática pueden esperar si este grupo puede completar el trabajo acordado sin ellos. Confírmalo antes de aplazarlos.
La segunda columna depende de la empresa. Si una orden no se considera terminada hasta que se emite una factura, decide cómo se hará en la primera versión. Puede bastar con un traspaso acordado al proceso de facturación existente. Si se omite ese paso sin decirlo, el personal descubrirá el vacío después.
El equipo necesitará datos reales de las órdenes. Decide qué registros existentes hay que trasladar, quién los comprobará y cómo se corregirán los errores. Una importación no deja de ser necesaria porque no tenga una pantalla vistosa.
Acuerda quién crea y elimina cuentas, responde a las preguntas del personal, investiga fallos y se ocupa del servicio. Incluye la ayuda o las instrucciones que necesita el primer grupo. Comprueba qué ocurrirá si el servicio no está disponible y cómo se podrá recuperar la información pertinente.
El relato de Google sobre el traspaso de la responsabilidad operativa trata las comprobaciones previas, la documentación y la formación. Describe el entorno de Google, no una estructura de equipo obligatoria para una pequeña empresa. Aquí la idea práctica es identificar quién gestionará y apoyará la versión inicial, y asegurarse de que tenga lo necesario.
Mantén pequeña la primera versión eligiendo menos trabajo que cubrir. Incluye en el plan los permisos, la privacidad, la seguridad y la recuperación necesarios para ese trabajo.
Un prototipo puede ayudarte a comprobar si la persona coordinadora entiende la pantalla de asignaciones o si el equipo puede registrar una visita desde el móvil. Deja claro qué demuestra. Una demostración convincente puede usar datos inventados y omitir permisos, almacenamiento o recuperación.
Antes de aprobar el uso en producción, acuerda qué pruebas necesita la versión real. En nuestro ejemplo, esto incluye probar una orden normal y otra asignada por error con los perfiles previstos en un entorno de pruebas separado. Comprueba que un equipo no pueda ver trabajos ajenos, que las correcciones lleguen a las personas adecuadas y que las órdenes pendientes sigan visibles.
Elige más comprobaciones según los riesgos del sistema: registros importados, cambios simultáneos, recuperación tras un fallo o volumen de trabajo que debe soportar. Completar una prueba de principio a fin una vez no resuelve todas esas cuestiones. Asigna un responsable a los riesgos pendientes y decide cuáles deben resolverse antes de que el personal dependa del servicio.
El alcance de la primera versión para la empresa de mantenimiento podría describirse así:
Revisa este alcance con el personal, la persona responsable del proceso empresarial y quienes crean y operan el programa. Todos deberían poder explicar qué cubre esta versión y adónde va el resto del trabajo.
Creamos software empresarial a medida. Si quieres hablar con nosotros sobre una primera versión, trae la tarea que las personas deben poder terminar, el grupo que la usará y las partes sobre las que tienes dudas. El alcance, la entrega y el soporte posterior se acuerdan para cada proyecto.
Puede atender a un grupo definido que realiza una tarea valiosa de principio a fin. Incluye los permisos, las correcciones y el apoyo operativo que esa tarea necesita. No existe una cifra universal de funciones o pantallas que resulte útil.
Los informes adicionales o las funciones de comodidad pueden esperar. Desde el principio debe existir una forma acordada de gestionar el acceso a las cuentas, las correcciones necesarias y las demás acciones que mantienen en marcha el trabajo elegido.
Un prototipo demuestra lo que realmente se ha probado, por ejemplo si las personas entienden una pantalla propuesta. El uso en producción exige pruebas propias del flujo acordado y sus riesgos, incluidos los controles de acceso, el tratamiento de datos, el apoyo y la recuperación necesarios.
Último boletín: ganar más con un sitio o app de suscripción que ya tienes.
El anterior: cómo distinguir las tonterías de la IA de los casos de éxito reales.
¿Te interesa?
Semanal O dinos y lo ajustamos para ti. ¿Suena bien?
