¿Deberíamos construirlo? La pregunta que hacemos antes de escribir código

Cuando una organización se acerca a una empresa de desarrollo de software, lo habitual es esperar que la conversación termine en una propuesta para construir algo: una nueva aplicación, un reemplazo para un sistema que envejece, una plataforma que una procesos desconectados. Es una suposición comprensible, pero se salta una pregunta que debería responderse antes de que nadie hable de tecnología, presupuestos o fechas de entrega.

¿Deberíamos realmente construirlo?

En Libertas Software Research (LSR) creemos que saber si se debe desarrollar software importa tanto como saber cómo. A veces una aplicación a medida es exactamente lo adecuado. A veces una plataforma SaaS consolidada cubre la necesidad perfectamente, o conectar los sistemas que ya tiene logra el resultado sin el coste y la disrupción de reemplazarlos. El objetivo es mejorar el funcionamiento de una organización, no añadir otra aplicación a un entorno ya complicado.

Empiece por el problema, no por la solución

Las organizaciones tienden a describir la solución que creen necesitar en lugar del problema que tienen. «Un panel de informes» o «una app para reemplazar nuestras hojas de cálculo» suena bien definido, pero dice poco sobre qué motivó la petición.

Piense en un informe de gestión mensual elaborado a mano a partir de varias hojas de cálculo y sistemas. Lleva días y, cuando llega, los datos ya están desactualizados. La conclusión obvia es que necesita software de informes. Si se mira de cerca, el verdadero problema suele ser datos desconectados y procesos inconsistentes: un proyecto de integración modesto, no una aplicación nueva. Y si la investigación demuestra que necesita flujos de trabajo o controles especializados que ningún producto admite, ese es el momento en que el desarrollo a medida se gana su lugar.

Cuándo tiene más sentido comprar

El mercado comercial es maduro. CRM, contabilidad, planificación, gestión documental e inteligencia empresarial tienen productos con años de refinamiento. Si uno satisface sus necesidades sin restricciones irrazonables, un reemplazo a medida aporta poco valor.

Pero compare el coste total de propiedad, no el precio de la suscripción. Un producto de 500 £ al mes son 30.000 £ en cinco años, antes de añadir configuración, integraciones, licencias adicionales o cambios en sus propios procesos. Compruebe cómo escala el precio, si puede exportar sus datos y qué ocurre si el proveedor cambia su modelo. Y desconfíe de obligar al negocio a abandonar actividades que realmente lo distinguen solo porque un producto asume otra cosa.

A veces la respuesta es conectar lo que ya tiene

La mayoría de las organizaciones acumulan sistemas con el tiempo: las finanzas en uno, las operaciones en otro, el servicio al cliente en un tercero. Cada uno funciona bien; simplemente no se comunican entre sí, y el resultado son retrasos, duplicación de esfuerzo e información inconsistente.

Reemplazarlo todo por una sola aplicación es tentador, pero arriesgado. Las plataformas existentes guardan años de conocimiento operativo e integraciones ocultas. Una capa de integración cuidadosamente diseñada (conectar API, automatizar transferencias, consolidar informes desde fuentes autorizadas) puede prolongar la vida de esas inversiones. Requiere un buen planteamiento de autenticación, propiedad de los datos, gestión de errores y auditabilidad, pero recomendar integración en lugar de sustitución no es ingeniería de segunda. A menudo es la decisión arquitectónica más meditada.

Cuándo lo a medida es la inversión adecuada

Algunos requisitos realmente no encajan con los productos convencionales: operaciones especializadas, necesidades inusuales de seguridad o de datos, o software que es en sí mismo una ventaja competitiva. Aquí el software a medida permite que la arquitectura siga cómo trabaja realmente el negocio.

Esa flexibilidad conlleva una responsabilidad a largo plazo de mantenimiento, seguridad, pruebas y soporte. Un sistema puede cumplir su especificación original y aun así ser una mala inversión si es difícil de mantener o no puede adaptarse. El desarrollo a medida está justificado cuando los beneficios de una solución hecha a propósito superan tanto el coste inicial como el compromiso continuo de poseerla.

No todo problema necesita más software

A veces el problema es el proceso. Las aprobaciones, los informes y los pasos administrativos se acumulan con los años, mucho después de que desaparezcan las circunstancias que los crearon. Automatizarlos tal como están solo preserva la complejidad.

Si un documento necesita cinco aprobaciones, no pregunte cómo automatizar cinco aprobaciones, pregunte por qué existe cada una y qué riesgo cubre. El software es excelente aplicando reglas coherentes, pero no puede decirle si el proceso tiene sentido. Simplificar un flujo de trabajo o aclarar responsabilidades puede dar mejoras reales sin otro sistema que aprender y mantener.

Mire más allá del coste inicial

Los proyectos a medida tienen un gran coste inicial, mientras que el SaaS reparte el suyo en suscripciones, lo que hace que la comparación parezca desequilibrada. Una comparación justa abarca toda la vida útil: implantación, licencias, alojamiento, soporte, mantenimiento, integración, formación y cambios futuros.

Incluya también el coste de no hacer nada. Un proceso ineficiente que consume 20 horas de personal a la semana son unas 1.040 horas al año. A una tarifa ilustrativa de 35 £ la hora, son unas 36.400 £ anuales, suponiendo que ese tiempo pueda recuperarse y reorientarse de verdad. Añada la mala calidad de los datos y las decisiones lentas, más difíciles de valorar pero igual de reales. La mejor opción no es la más barata, sino la que ofrece la mejor combinación de valor, riesgo aceptable y sostenibilidad a largo plazo.

¿Por qué una empresa de software recomendaría no construir software?

Es una pregunta justa. Si recomendamos un producto o una pequeña integración, sobre el papel hay menos trabajo de desarrollo.

Pero hay una diferencia entre proporcionar capacidad de desarrollo y actuar como socio de investigación y arquitectura de software. Nuestro trabajo empieza antes de que exista la especificación: entender el problema, sopesar las opciones y ayudarle a decidir dónde invertir. Eso tiene valor sea cual sea el resultado, y normalmente sigue habiendo trabajo de análisis, arquitectura, planificación e integración incluso cuando el desarrollo a medida no es la respuesta.

Recomendar un desarrollo que no necesita es contraproducente. Un proyecto entregado a tiempo y conforme a la especificación sigue fracasando si no era la solución adecuada. Ayudar a un cliente a evitar un gasto innecesario genera la clase de confianza que perdura.

Poder construir no es una razón para construir

La IA y las herramientas modernas hacen que producir código sea más rápido y barato. Eso es útil, pero hace que pensar de antemano sea más importante, no menos, porque el esfuerzo que antes obligaba a preguntarse «¿de verdad necesitamos esto?» está desapareciendo. Es perfectamente posible construir algo técnicamente excelente, entregarlo con eficiencia y descubrir que era la respuesta equivocada.

Antes de que empiece el desarrollo, queremos respuestas claras sobre el problema de negocio, el coste de dejarlo sin resolver, qué requisitos no pueden cubrir los productos existentes, cómo se medirá el éxito (tiempo de procesamiento, precisión, visibilidad, cumplimiento, no número de funciones) y quién operará y dará soporte a la solución después.

Habrá proyectos donde el software a medida es claramente lo correcto, otros donde la integración ofrece mejor valor y otros donde una plataforma estándar hace el trabajo. Lo importante es que la recomendación surja de entender su organización, no de una suposición sobre lo que quiere vender una empresa de software.

Antes de preguntar cómo deberíamos construir algo, conviene establecer si deberíamos construirlo.

Libertas Software Research trabaja con organizaciones para investigar, evaluar, diseñar y desarrollar soluciones de software, con foco en la mantenibilidad a largo plazo, el valor operativo y la inversión tecnológica informada.