¿Por qué tu cambio de software 'sencillo' tarda 8 horas en lugar de 30 minutos?

Pediste lo que parece un cambio sencillo. Quizás actualizar el momento de una notificación, cambiar un filtro de informe o añadir un nuevo campo a un formulario.

En tu cabeza, es algo de 30 minutos. Una hora si somos generosos. Luego yo vuelvo con una estimación de 6-8 horas, y tú piensas: ‘¿Qué demonios?’

¿Sinceramente? A veces, desearía que fuera tan sencillo como parece desde fuera.

Permíteme explicarte lo que está pasando. Es más complicado de lo que parece.

Por qué un cambio “pequeño” no es tan pequeño

Lo que ves en la superficie es el 10% de lo que ocurre por debajo.

Digamos que quieres cambiar cuándo se envía un correo electrónico de recordatorio de tarea. “Simplemente cámbialo de hoy a mañana”,.

Claro, eso es una línea de código. Pero

• ¿Qué sistema envía ese correo electrónico?  

• ¿Hay otros lugares que definan la “fecha de vencimiento” de manera diferente?

• ¿Qué pasa con las tareas recurrentes frente a las tareas únicas?

• ¿Necesitamos actualizar la interfaz de usuario para que coincida?

• ¿Esto romperá los correos electrónicos de escalada del gerente?

• ¿Qué pasa con las notificaciones de la aplicación móvil?

Ese cambio de una línea toca seis partes diferentes del sistema.

Si no revisamos todas, tu equipo de operaciones estará descontento cuando surjan problemas.

Qué sucede

Esto es lo que sucede cuando recibimos tu solicitud “sencilla”:

‍Hora 1: Averiguar dónde demonios reside esta lógica. Incluso en WeWeb y Retool, necesitamos encontrar dónde vive la lógica. ¿Está en el flujo de trabajo? ¿Un disparador? Podría estar oculta en una integración heredada de cuando empezamos a trabajar juntos. Eso son 30 minutos perdidos buscando, asumiendo que recordamos bien el sistema.

Horas 2-3: Mapear todos los lugares donde este cambio puede romper cosas. Queremos evitar romper algo más mientras arreglamos tu solicitud original.

Horas 4-5: Realizar el cambio y probarlo. Es decir, probarlo de verdad, no solo hacer clic durante 2 minutos. Necesitamos asegurarnos de no haber roto nada más. No podemos simplemente implementar un cambio y esperar lo mejor.

Necesitamos probarlo en un servidor de staging. ¿Se dispara la notificación correctamente? ¿Llega a las personas adecuadas? Si es una herramienta interna para tu equipo, una revisión rápida está bien (unos 20 minutos). Pero si es de cara al cliente? Un movimiento en falso y tus clientes reciben spam.

Horas 6-8: Limpiar cosas que encontramos accidentalmente. Si ya estamos ahí, podríamos arreglar las otras tres cosas que están unidas con cinta adhesiva. Luego, lo implementamos. Incluso con low-code, esto no es instantáneo. Llama a esto otros 15-30 minutos.

Por qué se siente peor de lo que debería

Gran parte de esta complejidad es innecesaria. Existe porque:

• Los sistemas se construyen rápidamente bajo presión

• Las “soluciones rápidas” se acumulan con el tiempo

• Nadie tiene tiempo para limpiar la base

• Siempre estamos apagando fuegos en lugar de prevenirlos

Renovar una casa mientras la gente vive en ella es un desafío. No puedes simplemente derribar paredes.

¿Y ahora qué?

Podríamos hacer ese cambio de una línea y darlo por terminado en 2 horas en lugar de 8. Pero entonces la siguiente solicitud similar también tomará 8 horas. Y la siguiente.

Cambiar incluso las cosas más sencillas se vuelve difícil cuando el sistema es demasiado complicado.

Necesitamos arreglar las cosas, no aplicar una solución temporal.

Sí, cuesta más por adelantado. Pero es la diferencia entre:

• Gastar 8 horas cada vez que necesitas un pequeño cambio

• Gastar 1-2 horas para el mismo cambio una vez que hayamos limpiado las cosas

No es un trabajo atractivo. No hay nuevas características que mostrar. Pero es la diferencia entre un sistema que funciona para ti y uno que funciona en tu contra.

En resumen

Ese cambio “sencillo” tomó 8 horas porque el sistema se ha desarrollado con el tiempo. Es complejo de maneras que no son obvias desde fuera.

No estoy inflando las estimaciones. Estoy siendo honesto sobre lo que se necesita para hacer el trabajo.

La pregunta principal no es “¿Por qué está tardando tanto?” sino “¿Cómo podemos acelerar esto la próxima vez?”