Construimos software para vivir, así que lo que sigue va en contra de nuestro propio interés inmediato. Lo escribimos igual, porque el proyecto que no debió existir es más caro para todos que el que no se vendió.
Una parte importante de las conversaciones que tenemos terminan en que la respuesta no es una herramienta. No porque el problema no sea real, sino porque el problema está en otro lado y el software lo va a amplificar en vez de resolverlo.
Estos son los cuatro patrones que más vemos, y cómo distinguirlos del caso en el que sí hace falta construir.
La herramienta que se compró y nadie usa
El patrón es reconocible. Hace un año se contrató un sistema, se pagó la implementación, hubo una capacitación. Hoy lo usa una persona a medias y el resto volvió al Excel.
La lectura fácil es que la herramienta era mala. Casi nunca lo es. Lo que suele haber pasado es una de dos cosas: la herramienta pedía que el equipo trabajara de una forma distinta y nadie acompañó ese cambio, o resolvía un problema que le dolía a la gerencia y no a quien tenía que usarla todos los días.
Cómo saber si es tu caso. Pregunta por qué se dejó de usar, pero no a quien la compró: a quien la usaba. Si la respuesta es "es más rápido a mano", el problema no era la herramienta.
Comprar una segunda herramienta aquí es repetir el experimento esperando otro resultado.
El proceso que falla por falta de dueño
Este es el más común y el que menos se parece a un problema de software.
Algo se atrasa siempre en el mismo punto. Las cotizaciones se demoran, los reclamos quedan sin respuesta, el cierre no sale a tiempo. Se pide un sistema para "darle seguimiento".
Pero si nadie es responsable de que eso avance, un sistema no lo va a hacer avanzar. Va a registrar con más detalle que no avanzó. Vas a tener un tablero preciso mostrando lo mismo que ya sabías, y ahora también hay que mantener el tablero.
Cómo saber si es tu caso. Pregunta quién responde si eso no ocurre esta semana. Si la respuesta es un área en vez de una persona, o si son tres personas, el problema es de responsabilidad y no de sistema.
Eso se arregla con una decisión, y la decisión es gratis.
Tres herramientas que hacen lo mismo
Un sistema de agenda, un grupo de chat donde también se agenda, y un cuaderno. Un formulario, una hoja compartida y un correo. Nadie decidió que fuera así: cada pieza entró por una buena razón, en un momento distinto, para resolver algo puntual.
El costo no es el de las suscripciones. Es que cada herramienta tiene una parte de la verdad y la operación real vive en la cabeza de quien las cruza.
Cómo saber si es tu caso. Cuenta en cuántos lugares distintos puede estar la respuesta a "¿en qué quedó esto?". Si son más de dos, ya lo es.
Y la salida no suele ser construir. Suele ser elegir cuál es el sistema de registro, decir qué papel cumple cada otra cosa, y apagar lo que sobra. Es una decisión incómoda porque alguien pierde su herramienta favorita, y es más barata que cualquier desarrollo.
Automatizar algo que está roto
El más caro de los cuatro, porque cuesta dinero real antes de que se note.
Un proceso con pasos innecesarios, aprobaciones que no aprueban nada y datos que se piden dos veces no mejora al automatizarse. Se vuelve más rápido, más difícil de cambiar y con más gente dependiendo de él. Lo que antes se corregía hablando con alguien, ahora requiere modificar un sistema.
Cómo saber si es tu caso. Dibuja el proceso actual en una hoja, paso por paso, y por cada uno pregunta para qué está. Si hay pasos cuya única respuesta es "siempre se ha hecho así", esos no se automatizan: se eliminan primero.
Automatizar debería venir después de simplificar, no en lugar de simplificar.
Lo que sí arregla estos cuatro
Ninguno de los cuatro necesita código. Necesitan cosas que suenan menos interesantes y funcionan mejor.
Un dueño por proceso, con nombre, no un área. Un lugar acordado donde vive cada tipo de información. Un ritual corto y regular donde se toman las decisiones pendientes, que es la mitad de lo que metodologías como Scrum o Kanban de verdad aportan cuando se aplican sin ceremonia. Y un proceso escrito en una hoja, que es donde se ven los pasos que sobran.
Eso es semanas de trabajo, no meses, y no tiene costo de mantenimiento. Cuando el problema es alguno de los cuatro de arriba, es también lo único que funciona.
Si no tienes claro si tu caso es de proceso o de sistema, esa distinción es exactamente lo que se puede resolver en una llamada de treinta minutos, y es de las conversaciones que más nos gusta tener.
Y el punto de quiebre
Ahora la otra mitad, porque este artículo sería deshonesto sin ella.
Hay un momento en que el proceso ya está sano y el sistema sí es la restricción real. Se reconoce así: el proceso está claro y escrito, hay un dueño, todos lo siguen, y aun así el equipo pasa horas haciendo a mano algo que es mecánico. Nadie discute cómo se hace; el problema es cuánto cuesta hacerlo.
Ahí construir se paga solo, y las señales concretas de que llegaste a ese punto están en seis señales de que lo manual ya te cuesta dinero.
La diferencia entre los dos casos es una pregunta: si mañana tuvieras el sistema perfecto, ¿tu problema desaparecería? Si la respuesta es sí, construye. Si la respuesta es "seguiría faltando que alguien decida", el sistema no era el problema.
Cómo trabajamos esto
Cuando el diagnóstico es de proceso, lo decimos y no vendemos un desarrollo. Lo que sí ofrecemos ahí es acompañamiento en la parte metodológica, y formación para equipos, que está en charlas y talleres. Todo lo que hacemos está en servicios, y cómo estructuramos un proyecto cuando sí toca construir está en del discovery a la entrega.
La llamada de descubrimiento dura treinta minutos, es gratuita y sin compromiso. Su trabajo es exactamente distinguir estos dos casos, y decirte que no hace falta construir es un resultado tan válido como el otro. Puedes agendarla aquí.
¿Esto aplica en tu empresa?
30 minutos, sin compromiso, para revisar tu caso y decidir si hay algo que construir.