Next WrldLa reunión empieza con una lista.
Un gerente trae diez pedidos. Administración suma otros ocho. El técnico más antiguo agrega cinco que “no pueden faltar”. En una hora ya hay cuarenta ideas para el nuevo sistema.
Todo parece razonable. Todo parece urgente.
Y ahí se traba la mayoría de los sistemas internos antes de existir, por exceso de alcance. Se quiere cubrir cada caso y conformar a cada persona desde el primer día. El proyecto se vuelve tan grande que tarda demasiado.
La pregunta útil es por dónde empezar para que sea útil cuanto antes, sin pasarse de alcance.
Una primera versión útil cubre el recorrido central completo aunque sea simple, y deja fuera casi todo lo demás. El alcance se recorta por uso, no por opiniones.
El recorrido central ordena todo
Todo sistema interno sostiene un recorrido. Una secuencia de pasos que hoy se hace por mensajes sueltos, planillas y memoria de las personas.
Si ese recorrido no está claro, cada pedido suena igual de importante. Un reporte parece tan urgente como registrar el trabajo. Sin recorrido central, no hay forma de ordenar.
Por eso el primer trabajo es acordar una frase que describa qué entra por un lado, qué pasos atraviesa y qué sale por el otro.
Con esa frase, recortar es más fácil. Lo que completa el recorrido entra. Lo demás espera.
Una primera versión tiene que llevar un caso real desde el inicio hasta el fin sin perderse en el camino.
Lo imprescindible se reconoce por el uso
¿Cómo distinguir lo imprescindible de lo deseable sin discutir por gustos? Por la frecuencia de uso.
Para cada pedido conviene preguntar: ¿se va a usar todos los días o solo en casos puntuales? ¿Lo necesita quien hace el trabajo o solo quien lo mira de vez en cuando? ¿Si falta, el trabajo se frena o solo se vuelve menos cómodo?
Lo imprescindible es lo que se usa todos los días y, si falta, frena la operación. Lo deseable es lo que se usa de vez en cuando y, si falta, se puede resolver por otro camino durante un tiempo.
Un reporte con muchos filtros puede ser atractivo en una reunión. Pero si el equipo aún no registra el trabajo de forma ordenada, ese reporte no tiene sobre qué apoyarse. Un permiso muy detallado puede parecer orden. Pero si hay dudas sobre quién hace qué, el problema es la falta de responsables claros, no el permiso.
Recortar por uso obliga a mirar qué necesita el trabajo diario para no trabarse.
Lo que sí tiene que tener una primera versión
Una primera versión bien planteada parece modesta y es exigente en lo esencial. Tiene que permitir cuatro cosas.
Registrar. Que lo importante quede en un solo lugar, con los datos mínimos para entender de qué se trata. Sin campos de más ni planillas paralelas.
Mostrar el estado. Que cualquiera responda en un minuto: ¿en qué está esto? ¿Pendiente, en curso, demorado, terminado? Esto evita preguntas repetidas y decisiones a ciegas.
Asignar responsables. Que quede claro quién hace qué y para cuándo. Si nadie tiene asignado el paso siguiente, el trabajo queda quieto.
Guardar una historia mínima. Lo suficiente para reconstruir qué pasó: quién lo pidió, quién lo tomó y cómo terminó.
Si logra esas cuatro cosas sobre el recorrido central, ya es útil. Si no las logra, ninguna función adicional la salva.
Lo que se deja fuera a propósito
Decir qué entra es la mitad del trabajo. La otra mitad es decir qué no entra, por escrito y con motivos. Cuatro grupos conviene dejar fuera.
Reportes avanzados. Tableros con cruces y comparaciones pueden esperar. Alcanza con ver la lista de trabajo y filtrar por estado. Cuando el registro sea confiable, los reportes tendrán sentido. Antes solo muestran desorden con buena presentación.
Permisos finos. Salvo información sensible, no hace falta definir quién puede ver cada campo en cada caso. Alcanzan reglas simples y parejas. El control detallado se justifica cuando el uso crece, no antes.
Automatizaciones prematuras. Avisos para cada situación o reglas que derivan casos solas ayudan cuando el proceso ya es estable. Si se automatiza algo que cambia cada semana, solo se genera retrabajo.
Casos borde. Esa excepción que pasa una vez cada tanto y que alguien quiere contemplar “por las dudas”. Diseñar para la excepción complica el camino habitual. Mejor resolver bien lo frecuente y tratar la excepción por fuera hasta ver si se repite.
Dejar fuera es decir “todavía no”, y buscar la menor complejidad necesaria para resolver correctamente el problema. Esa idea debería acompañar todo el proyecto.
Cómo se decide qué entra
El recorte se hace con tres o cuatro personas que conocen la operación, repasando la lista con tres preguntas.
¿Esto pasa todas las semanas? Si no, sale de la primera versión.
¿Si falta, el trabajo se detiene o se pierde información importante? Si se puede seguir con un acuerdo simple por un tiempo, espera.
¿Ayuda a completar el recorrido central o solo lo hace más atractivo? Si solo lo hace más atractivo, espera.
Este ejercicio suele bajar cuarenta ideas a ocho o diez decisiones. El equipo empieza a pensar en uso.
Conviene nombrar a alguien que cuide el alcance. Cuando aparece un pedido nuevo a mitad de camino, esa persona pregunta: ¿es parte del recorrido central? ¿Es de uso diario? ¿Qué pasa si lo dejamos para después? Sin esa función, el alcance crece de a un “ya que estamos” por vez.
Cómo saber si funciona
Una primera versión no se mide por cantidad de funciones. Se mide por orden y por alivio.
¿Se dejó de preguntar por mensaje dónde está cada cosa? ¿Se sabe quién tiene cada tarea sin llamar? ¿Se perdió menos información que antes?
Si mejoran en las primeras semanas, funciona aunque sea simple. Si el equipo sigue trabajando por fuera, algo falló en lo esencial.
Conviene definir dos o tres señales concretas. Por ejemplo: Todo pedido queda registrado el mismo día, todo trabajo tiene responsable visible, todo cierre queda documentado. Poco, observable, revisable en una reunión corta.
La primera versión termina cuando el recorrido central se usa todos los días sin rodeos, no cuando se entrega una lista de pantallas.
Ejemplo completo: empresa de mantenimiento
Una empresa de servicios técnicos recibe solicitudes, arma órdenes de trabajo, asigna técnicos, ejecuta visitas y luego cierra y factura.
Hoy trabaja con mensajes y una planilla que solo entiende una persona. Se pierden solicitudes, nadie sabe qué técnico está en cada sitio y la facturación se demora porque falta información de lo que se hizo.
El recorrido central se dice en una frase: Una solicitud entra, se convierte en orden, se asigna a un responsable, se ejecuta y se cierra con datos suficientes para facturar. Ese es todo el alcance de la primera versión.
Sería así. La solicitud se registra con datos mínimos: quién pide, dónde, qué problema reporta y contacto. Sin formularios largos. Cada solicitud aceptada genera una orden con número, descripción, dirección, fecha y responsable.
Cada orden tiene técnico visible y fecha. El listado muestra pendientes, en curso o demoradas. El técnico marca inicio y fin y anota lo realizado.
Al cerrar queda constancia de qué se hizo, qué materiales se usaron y si quedó algo pendiente. Administración ve qué está listo para facturar sin llamar para completar datos. Y cada orden guarda su historia: quién la creó, quién la tomó y cómo se cerró.
¿Qué queda fuera? Los reportes avanzados por técnico o por tipo de falla. Alcanza con ver abiertas y cerradas en la semana. Los permisos finos por cliente o por campo. Alcanzan accesos simples. Las automatizaciones prematuras, como asignación automática o avisos en cada cambio. Alcanza con avisar al asignar y al cerrar. Y los casos borde, como garantías especiales o trabajos con varias visitas. Se resuelven manual mientras se aprende.
Lo diario entró. Lo ocasional esperó. La operación ganó responsables claros y menos retrabajo. Y la facturación dejó de depender de la memoria de cada técnico.
Errores que agrandan la primera versión
Hay tres errores típicos. Pedir todo junto: Cada área suma lo suyo y nadie quiere quedarse afuera. Se evita volviendo al recorrido central y preguntando qué lo frena hoy. Lo que no lo frena, espera.
Diseñar para excepciones: Se dedica mucho tiempo al caso raro y poco al camino habitual. Conviene invertir la proporción y ser excelente en lo frecuente.
Confundir la primera versión con el producto terminado: Se la juzga como si ya tuviera que resolverlo todo. Pero un sistema interno evoluciona con el uso. Es un punto de partida firme, no un punto final.
Pedir de más no acelera, demora. Nunca conviene asumir que más funciones es mejor producto, ni que construir siempre es mejor que comprar.
El criterio para cerrar la discusión
Toda discusión de alcance termina con la misma pregunta: ¿esto tiene que estar en la primera versión?
La respuesta es sí solo si cumple tres condiciones. Forma parte del recorrido central. Se va a usar todas las semanas. Si falta, el trabajo se frena o se pierde información que no se recupera.
Si falla alguna, va a una lista visible de “después”. Se revisa cuando la primera versión esté en uso. Lo que demuestre uso frecuente, entra. Lo demás espera.
Empezar por lo importante es cuidar los recursos y respetar el tiempo del equipo. Un sistema útil sostiene con claridad el trabajo de todos los días.
Cuando el recorrido central funciona, el resto llega en orden y con sentido.