El punto de partida: tres freelancers y una planilla que nadie miraba
Antes de tener tableros, el equipo trabajaba con una planilla compartida que se desactualizaba cada dos días. El problema no era la falta de tareas, sino no saber cuántas cabían realmente en una semana. La primera versión del pronóstico de carga se armó justamente para responder esa pregunta: cuánto trabajo entra sin que se caiga una entrega.
El tablero kanban como base, no como decoración
Cuando se sumaron los primeros estudios de diseño como usuarios, quedó claro que las columnas tenían que reflejar el flujo real: boceto, revisión interna, ajustes del cliente, entrega. Ese orden se mantuvo desde entonces, con el historial de cambios guardando cada movimiento para que nadie tenga que reconstruir lo que pasó en una reunión.
Reportes en CSV para clientes que no entran a la herramienta
Varios clientes en Asunción y en otras ciudades solo querían un archivo claro los viernes. La exportación en CSV se diseñó con ese uso en mente: tareas cerradas, tareas en riesgo y estimado contra real por proyecto. Menos columnas, menos preguntas, menos reuniones de seguimiento que no aportaban nada.
Equipos distribuidos y husos horarios distintos
Con consultoras que trabajan con clientes en Buenos Aires, Madrid y Ciudad de México, la vista de calendario dejó de ser un extra y pasó a ser central. Ver la carga semanal por persona evita comprometer fechas cuando alguien ya está al límite, algo que en un equipo chico se nota rápido si los datos están a la vista.
Lo que sigue: medir sin inflar el proceso
La decisión que se mantiene desde el inicio es no agregar funciones que obliguen a llenar formularios largos. Cada nueva métrica de equipo tiene que poder leerse en menos de un minuto y servir para reordenar prioridades, no para justificar el trabajo ya hecho. Si una función no ayuda a decidir algo concreto, no entra.