El software propio puede acumular funciones con rapidez: una necesidad produce una pantalla, luego aparece una excepción y finalmente otra pantalla para administrar esa excepción. Meses después hay más piezas, pero el problema original no necesariamente está mejor resuelto. Software a medida no debería significar software sin límites.
Cada función tiene un costo después de publicarse
Agregar una función no termina cuando llega a producción: hay que probarla, mantenerla y actualizarla cuando cambia otra parte del sistema.
Explicársela a nuevos usuarios. Considerarla cada vez que modificamos la interfaz. Monitorearla. Corregirla cuando aparece un caso que nadie había previsto.
Por eso el costo de una función no es solamente cuánto tarda en desarrollarse. También es cuánto trabajo genera mientras exista.
El pedido no siempre es el problema
"Necesitamos un botón para exportar esto." "Queremos agregar otro estado al pedido." "Hace falta una pantalla nueva." Esas son soluciones propuestas.
Antes de desarrollarlas conviene entender qué está intentando hacer realmente la persona que las pide. Tal vez necesita enviar información a otro sistema. Tal vez intenta distinguir dos procesos que hoy están mezclados. Tal vez exporta un archivo porque no existe una integración. Antes de automatizarla, conviene entender qué sistema es responsable de cada dato.
Tal vez el nuevo estado solamente compensa una regla de negocio que debería estar en otro lugar. La pregunta útil no es “¿cómo hacemos esta función?”, sino “¿qué problema estamos intentando resolver con ella?”.
A veces ya existe una herramienta suficiente
Desarrollo a medida no significa que cada pieza tenga que escribirse desde cero. Si un servicio existente resuelve una parte secundaria del problema, puede ser la mejor decisión para autenticación, pagos, emails, almacenamiento, analítica o facturación. En esas áreas, desarrollar una solución propia puede agregar mantenimiento sin generar una ventaja real. El código propio tiene más sentido donde el problema también es propio.
Las excepciones se acumulan rápido
Muchos sistemas empiezan simples. Después aparece: "esto aplica a todos los clientes excepto a estos tres". Luego: "también excepto cuando el pedido viene de este canal". Después: "salvo que sea viernes y tenga esta categoría". Cada excepción puede ser legítima.
El problema aparece cuando las reglas se agregan una encima de otra sin revisar el modelo completo. En algún momento el sistema deja de tener reglas y empieza a tener historia. Antes de sumar una excepción nueva, conviene preguntarse si estamos viendo un caso especial o una señal de que el proceso necesita rediseñarse.
Un producto no mejora solamente porque puede hacer más cosas
Agregar funciones es visible. Eliminar pasos, simplificar una pantalla o evitar que una tarea exista directamente es menos espectacular. Pero muchas veces genera más valor. Si antes alguien necesitaba completar seis campos y ahora el sistema puede inferir cuatro, no agregamos una función llamativa.
El resultado es menos trabajo. Si una integración elimina una exportación manual, también desaparece una pantalla que quizá nunca debió existir. El buen software no siempre agrega; a veces quita.
Cuando el trabajo manual alrededor de una planilla empieza a ser el problema, conviene evaluar cuándo Excel deja de alcanzar y hace falta software a medida.
El alcance también necesita una razón
Una lista de requerimientos no debería ser una lista sagrada. Conviene poder explicar por qué cada parte está dentro de la primera versión, qué desbloquea y quién la necesita.
¿Qué ocurre si no existe? ¿Se puede resolver manualmente durante un tiempo? ¿Depende de algo que todavía no validamos? No todo lo que eventualmente podría ser útil tiene que estar en el primer lanzamiento.
La diferencia entre "podría servir" y "hace falta" puede ahorrar meses de desarrollo.
Lo manual no siempre es enemigo
Automatizar todo desde el principio también puede ser una trampa. Un proceso que ocurre dos veces por mes quizá pueda seguir siendo manual hasta entenderlo mejor. Automatizarlo demasiado temprano fija decisiones que todavía están cambiando. Primero podemos observar cómo funciona.
Después encontrar patrones. Y recién entonces decidir qué parte vale la pena convertir en software. No todo trabajo manual es deuda técnica. A veces es una forma barata de aprender.
También hay que poder borrar
Una función que nadie usa sigue ocupando espacio en el código, la interfaz y las pruebas.
En la cabeza de quien mantiene el producto. Sin embargo, eliminar funcionalidades suele ser mucho más difícil que agregarlas. Por eso conviene medir uso cuando sea posible. Si una característica lleva un año disponible y prácticamente nadie la toca, mantenerla por si algún día hace falta puede no ser gratis.
Los productos también necesitan perder piezas.
El software debería seguir al negocio, no coleccionarlo
Un sistema a medida tiene una ventaja enorme: puede adaptarse con mucha precisión a cómo funciona una empresa. Pero llevado demasiado lejos, puede terminar convirtiéndose en un archivo histórico de cada proceso, excepción y decisión que existió alguna vez. El objetivo debería ser otro.
Capturar las reglas que realmente importan y hacerlas más simples de ejecutar. No trasladar toda la complejidad existente a una pantalla nueva.
Menos también puede ser a medida
Desarrollar software propio permite hacer exactamente lo que necesitamos. Eso incluye la posibilidad de no hacer cosas. Elegir bien qué queda afuera suele ser tan importante como decidir qué desarrollar. Porque cada pieza que agregamos tiene que justificar el lugar que ocupa.
El resultado sigue siendo software a medida, pero con cada pieza ligada a una necesidad verificable y con espacio para eliminarla cuando deje de cumplirla.