Por qué decepcionan los proyectos con agencias de software: guía basada en evidencia

En el trabajo de software externalizado pueden darse expectativas incumplidas, versiones defectuosas, entregas tardías y facturas discutidas. Eso no demuestra que las agencias, como categoría, sean malas. Una evaluación útil separa la evidencia sobre un proveedor y un proyecto concretos de las suposiciones sobre el modelo de entrega.

Los resultados dependen del problema, la capacidad del proveedor, las decisiones del cliente, el contrato, las dependencias, la evidencia y el entorno operativo. Tanto el comprador como el proveedor pueden crear o reducir riesgos. Esta guía convierte esos factores en preguntas que pueden responderse antes de la selección y durante la entrega.

Usa las restricciones para planificar, no como una ley

Tiempo, coste, alcance y calidad son dimensiones útiles para planificar, pero el conocido triángulo o cuadrángulo es una heurística, no una fórmula que prediga un proyecto. Un cambio puede afectar a varias dimensiones, pero la dirección y la magnitud dependen de la arquitectura, la secuencia, las capacidades, la automatización, las dependencias y el riesgo.

Usa el modelo para registrar decisiones. ¿Qué fecha es fija? ¿Qué resultados son esenciales? ¿Qué atributos de calidad son críticos por riesgo? ¿Qué rango de presupuesto e incertidumbre está autorizado? ¿Qué supuestos cambiarían el plan? No prometas que gastar más mejora automáticamente la calidad ni que añadir personas recupera automáticamente el calendario.

Define resultados y evidencia de aceptación antes de comparar proveedores

Describe el resultado para usuarios o negocio, el punto de partida, las personas afectadas, las restricciones y el responsable. Después define cómo se aceptará cada incremento. La evidencia puede incluir recorridos funcionales, pruebas automatizadas, hallazgos de seguridad, revisiones de accesibilidad, resultados de rendimiento, datos conciliados, manuales operativos y aprobación de las partes interesadas.

El Sourcing Playbook vigente del Gobierno británico recomienda especificaciones basadas en resultados, interacción temprana con el mercado, modelado de costes esperados, pruebas, pilotos, asignación de riesgos y medición del rendimiento para la contratación de servicios públicos. No es una plantilla contractual universal, pero sus preguntas son útiles para compradores comerciales de software.

Haz que el progreso pueda revisarse en incrementos pequeños

Un informe de estado no equivale a evidencia de software utilizable. Acuerda una cadencia de revisión que muestre incrementos funcionales, decisiones, dependencias bloqueadas, cambios de previsión, defectos y resultados de aceptación. La frecuencia debe responder al riesgo y al tipo de entrega, no a un ritual semanal arbitrario.

La Oficina de Rendición de Cuentas de Estados Unidos describe Agile como desarrollo incremental con evaluación continua de funcionalidad, calidad y satisfacción del cliente. Su Agile Assessment Guide está escrito para evaluar organismos públicos, pero respalda el principio general de revisiones frecuentes y feedback del cliente. La entrega incremental reduce algunos riesgos, pero no garantiza plazo, presupuesto ni éxito del producto.

Trata la calidad como una decisión de riesgo

Hacer más pruebas no produce una curva universal de costes exponenciales, y no se puede inferir un menor número de defectos solo a partir de las horas. La eficacia de la verificación depende de los requisitos, el diseño, la selección de pruebas, el entorno, la automatización, la calidad de las revisiones, la exposición a amenazas y el feedback operativo.

Define los atributos de calidad relevantes: corrección, seguridad, privacidad, accesibilidad, rendimiento, resiliencia, mantenibilidad y recuperación. La evidencia necesaria difiere entre una herramienta interna de bajo impacto y software relacionado con seguridad, finanzas, identidad o derechos. No trates la aviación, Web3 ni ningún otro sector como una clase de riesgo uniforme.

El Secure Software Development Framework del NIST se basa en resultados y está pensado expresamente para adaptarse a las necesidades del negocio, la tolerancia al riesgo y los recursos. Recomienda considerar riesgo, coste, viabilidad y aplicabilidad en vez de aplicar una lista sin cambios. La verificación de seguridad es una parte de la calidad, no una prueba de la idoneidad total del producto.

Estima la incertidumbre en vez de ocultarla

Una estimación debe indicar alcance, supuestos, exclusiones, dependencias, método, confianza y condiciones de actualización. Separa el trabajo estimado de la exposición a riesgos identificados y de las decisiones de gestión sobre fondos adicionales. No supongas que cada proyecto debe usar exactamente tres partidas presupuestarias ni que añadir una reserva reduce el riesgo técnico subyacente.

El Cost Estimating Handbook de la NASA está diseñado para programas de la NASA, no para proyectos habituales con agencias. Aun así, es una referencia autorizada sobre cómo documentar la base de una estimación, el riesgo, la incertidumbre, los rangos y las actualizaciones. Adapta el método a la escala del proyecto en vez de copiar toda la gobernanza aeroespacial.

Asigna cada riesgo a quien pueda gestionarlo

Crea una matriz de asignación de riesgos antes de fijar precios. Para cada riesgo material, registra causa, consecuencia, señal temprana, responsable, mitigación, exposición residual, derechos de decisión y tratamiento comercial. Algunos riesgos corresponden al proveedor, otros al comprador y otros exigen control conjunto. Transferir un riesgo mediante el contrato no concede control práctico sobre él.

La guía vigente Risk Allocation and Pricing Approaches del Gobierno británico indica que los riesgos deben recaer en la parte mejor capacitada para gestionarlos y que los precios deben distinguir entre inputs, outputs y resultados. También indica que las medidas de rendimiento deben ser objetivas y limitarse a resultados en los que el proveedor pueda influir. Aplica la legislación local de contratación y contratos al encargo concreto.

Elige precios adecuados a la incertidumbre y al control

Los modelos por tiempo, precio fijo, hitos, límites o resultados distribuyen la incertidumbre de forma distinta. Ninguno es intrínsecamente honesto, eficiente o alineado. El precio fijo puede funcionar cuando los entregables y la aceptación son suficientemente estables. El trabajo por tiempo puede encajar en discovery o alcance cambiante si gasto, prioridades y reglas de parada siguen visibles. Los precios por resultados exigen resultados medibles y un tratamiento justo de las dependencias fuera del control del proveedor.

Compara propuestas sobre el mismo alcance y evidencia. Pregunta qué está incluido, excluido, supuesto, sujeto a control de cambios, garantizado, soportado, licenciado y entregado. Modela el trabajo interno del comprador, costes de terceros, nube, revisión de seguridad, migración de datos, operaciones y salida, no solo la factura del proveedor.

Haz que el control de cambios sea útil, no punitivo

El discovery de software cambia lo que el equipo sabe. Un buen registro de cambio indica el desencadenante, el requisito afectado, las opciones, el impacto sobre la evidencia, el rango de coste y plazo, el responsable de la decisión y la aprobación. Conserva la línea base y permite un cambio deliberado.

No clasifiques cada aclaración como ampliación facturable ni cada petición nueva como incluida. Acuerda cómo distinguir defectos, aceptación ausente, cambios normativos, fallos de dependencias y nuevo alcance de producto. Revisa los cambios acumulados contra el caso de negocio, en lugar de aprobarlos uno a uno sin visión global.

Exige responsabilidad operativa y una vía de salida

La entrega está incompleta si nadie puede operar, proteger, mantener y cambiar el sistema. Define repositorios, accesos, entornos, despliegue, observabilidad, respuesta a incidentes, copias de seguridad, recuperación, exportación de datos, documentación, licencias, credenciales, dependencias de proveedores y transferencia de conocimiento.

Define la autoridad de forma explícita. ¿Quién acepta el trabajo, cambia prioridades, aprueba el acceso a producción, acepta el riesgo residual y puede detener una versión? Un asesor sénior, Product Owner, Engineering Lead o ejecutivo fraccional puede ayudar, pero ningún título alinea incentivos automáticamente. La clasificación contractual y la situación laboral dependen de la relación real y de la jurisdicción, no de la etiqueta comercial.

¿Qué debe revisar un comprador?

Las señales de alerta necesitan contexto

• Una propuesta da un coste o una fecha precisos sin supuestos, discovery ni confianza.
• La aceptación depende de satisfacción subjetiva sin criterios observables.
• El proveedor no puede mostrar incrementos funcionales, fallos o cambios de previsión.
• Los riesgos importantes se transfieren por contrato a una parte que no puede controlarlos.
• Faltan seguridad, privacidad, accesibilidad, migración de datos, operaciones o salida pese a ser relevantes.
• El comprador no tiene un responsable autorizado para prioridades, aceptación, dependencias y decisiones.

Son preguntas de diligencia debida, no una prueba de que un proveedor sea inadecuado. Solicita la evidencia ausente y evalúa la respuesta según el riesgo del proyecto.

¿Cómo debe evaluarse el modelo de Wavect?

Evalúa Wavect con el mismo marco. Nuestros servicios de desarrollo de software a medida y Fractional CTO describen distintos tipos de apoyo, pero sus nombres no demuestran idoneidad, resultados, independencia ni clasificación legal. Solicita una propuesta que detalle alcance, supuestos, equipo, autoridad, precios, evidencia, riesgos, dependencias, traspaso y salida.

Los casos de estudio y testimonios seleccionados son evidencia de trabajos concretos, no un conjunto completo de tasas de éxito ni una garantía. Comprueba referencias actuales, experiencia relevante, conflictos, disponibilidad, prácticas de seguridad y quién realizará realmente el trabajo.