Por qué su proyecto de software está retrasado (y qué hacer al respecto)

El Informe CHAOS 2024 del Grupo Standish encontró queEl 66% de los proyectos de software exceden su cronograma o presupuesto. Uno de cada cinco se cancela de plano. Estas cifras se han mantenido obstinadamente constantes durante más de una década.

Las causas no son misteriosas. Se repiten en todas las industrias, tamaños de empresas y pilas de tecnología. Después de enviar docenas de proyectos de clientes en Savi, seis patrones representan la gran mayoría de los retrasos que vemos. Todos ellos son prevenibles. A continuación se explica cómo detectar cada uno y qué hacer en su lugar.

1. La ampliación del alcance acaba con más proyectos que el código incorrecto

La variación del alcance es la razón más común por la que los proyectos de software se retrasan. Empieza poco a poco. Una parte interesada dice "ya que estamos en eso, ¿podemos agregar también..." en un stand-up. El primer ministro asiente. El ingeniero añade una tarea. Multiplique esto por tres solicitudes por semana durante ocho semanas y su proyecto original de 6 semanas ahora será un proyecto de 14 semanas sin un final a la vista.

Aquí están las matemáticas que hacen que el alcance sea tan destructivo:un cambio de requisitos en la semana 1 cuesta aproximadamente 1 hora de tiempo de ingeniería. El mismo cambio en la semana 8 cuesta 10 veces más. Para la semana 8, el código base tiene dependencias construidas sobre el diseño original. Cambiar de dirección significa refactorizar el código de trabajo, actualizar las pruebas, volver a verificar las integraciones y volver a probar las funciones que ya aprobó.

El IBM Systems Sciences Institute publicó datos que muestran que los defectos encontrados durante la fase de mantenimiento cuestan 100 veces más reparar que los defectos encontrados durante la fase de diseño. Los cambios de requisitos siguen la misma curva de costos.

Qué hacer en su lugar:Escriba un documento de requisitos del producto (PRD) antes de escribir cualquier código. Enumere cada característica, cada flujo de usuarios y cada punto final de API. Obtenga la aprobación de todas las partes interesadas. Entonces traten al PRD como un contrato. Las nuevas ideas van a una "acumulación de pedidos v2", no al sprint actual. En Savi, dedicamos entre 1 y 2 semanas a definir los requisitos antes de que comience el desarrollo. Esa inversión de $1,500 en planificación ahorra más de $10,000 en retrabajos a mitad del proyecto.

2. Las capas de comunicación añaden semanas, no claridad

Imagine la configuración típica de una agencia: explica su solicitud de función a un administrador de cuentas. El gerente de cuentas escribe un ticket y lo asigna a un gerente de proyecto. El director del proyecto lo traduce en una especificación técnica y la envía al líder técnico. El líder tecnológico lo asigna a un desarrollador. El desarrollador tiene una pregunta, por lo que toda la cadena se invierte.

Cada traspaso en esta cadena introduce dos problemas. Primero, pérdida de información. Su solicitud original tenía matices; cuando llega al desarrollador, ha sido parafraseado tres veces. En segundo lugar, la latencia. Cada traspaso agrega de 4 a 24 horas de tiempo de espera. Una pregunta que podría resolverse en una llamada de 5 minutos tarda 3 días en recorrer la cadena de comunicación.

Un estudio del Project Management Institute encontró queEl 56% del presupuesto del proyecto en riesgo se debe a una mala comunicación. En un proyecto de 50.000 dólares, eso significa 28.000 dólares expuestos al desperdicio por falta de comunicación.

Qué hacer en su lugar:Habla directamente con la persona que escribe tu código. En Savi, cada cliente tiene un canal Slack directo con su ingeniero senior asignado. No hay administradores de cuentas que transmitan mensajes. No hay requisitos de interpretación de PM. Describes lo que necesitas; el ingeniero hace preguntas aclaratorias en tiempo real; la característica se construye correctamente la primera vez. Este único cambio elimina entre el 30% y el 40% de los idas y venidas que inflan los plazos.

3. La composición incorrecta del equipo quema el presupuesto en los traspasos

Muchas agencias trabajan en proyectos con entre 4 y 6 desarrolladores: dos frontend, dos backend, un ingeniero de control de calidad y una persona de DevOps. Esto suena productivo. En la práctica, crea un impuesto de coordinación que consume entre el 30% y el 40% del presupuesto total.

El equipo de frontend crea un componente de formulario y necesita un punto final API. Presentan un ticket para el equipo de backend. El equipo de backend está a mitad de carrera en una característica diferente. Pasan tres días. El desarrollador frontend pasa a otra tarea. Cuando el punto final está listo, el desarrollador frontend debe volver a cambiar de contexto. El punto final devuelve datos en una forma diferente a la esperada. Comienza otro viaje de ida y vuelta.

Dotar de personal a demasiados desarrolladores junior crea el mismo problema de una manera diferente. Los jóvenes escriben código que funciona en su máquina local pero falla en la preparación. Un ingeniero senior dedica 3 horas a depurar el problema de implementación de un junior en lugar de crear funciones. La velocidad efectiva del equipo cae al 40-50% de su capacidad teórica.

Qué hacer en su lugar:El personal de proyectos cuenta con 1 o 2 ingenieros senior full-stack que poseen todo el código base. Un ingeniero que crea la API, escribe la interfaz, configura la base de datos e implementa la aplicación no tiene gastos generales de transferencia. En Savi, este es nuestro valor predeterminado. Un solo ingeniero senior que envía un proyecto de $20 000 en 5 semanas supera a un equipo de cuatro jóvenes que envían el mismo proyecto en 12 semanas con más errores y un costo total más alto.

4. No hay criterios definidos de "hecho" para las funciones

"Crear el panel de usuario" no es una especificación de función. Es un tema de conversación. Sin criterios de aceptación explícitos, los ingenieros hacen suposiciones. A veces esas suposiciones coinciden con lo que quería el cliente. A menudo no es así.

El resultado: el ingeniero crea un panel con tres gráficos y una tabla de datos. El cliente esperaba cinco gráficos, un filtro de rango de fechas, un botón de exportación CSV y una vista comparativa. El ingeniero lo reconstruye. El cliente da su opinión sobre la reconstrucción. Una función que debería haber tardado 3 días tarda 10.

Este patrón es tan común que tiene un nombre en la gestión de proyectos:La trampa del "90% hecho". Una función permanece "casi terminada" durante semanas porque nadie definió cómo se ve "terminada". Los ingenieros siguen puliendo. Los clientes siguen solicitando cambios. El proyecto sangra tiempo.

Qué hacer en su lugar:Escriba criterios de aceptación para cada característica antes de que comience el desarrollo. Utilice este formato: "Esta función se realiza cuando [condición específica y comprobable]". Por ejemplo: "El panel finaliza cuando muestra los ingresos, los pedidos y la tasa de conversión para el rango de fechas seleccionado, con un botón de exportación CSV que descarga todos los datos visibles". El ingeniero sabe exactamente qué construir. El cliente sabe exactamente qué esperar. Nadie discute si está "hecho".

5. Subestimar la complejidad de la integración

"Necesitamos integrarnos con Stripe" parece una tarea de un día. En realidad, una integración de Stripe a nivel de producción incluye: creación de intención de pago, manejo de webhooks para eventos asincrónicos (pago exitoso, pago fallido, suscripción cancelada, disputa abierta), claves de idempotencia para evitar cargos duplicados, lógica de reintento para webhooks fallidos, un portal de cliente para administrar suscripciones y estados de error adecuados en la interfaz de usuario para cada modo de falla.

Esa "tarea de un día" requiere de 3 a 5 días para un ingeniero senior y de 7 a 10 días para un junior. Multiplique esta subestimación por 3 o 4 integraciones (pasarela de pago, proveedor de correo electrónico, análisis, KYC) y habrá agregado de 2 a 4 semanas a un proyecto para el que nadie presupuestado.

La calidad de la API de terceros varía enormemente. Stripe tiene excelente documentación y entornos sandbox. Muchas API específicas de la industria (banca, logística, gobierno) tienen documentos incompletos, entornos sandbox poco confiables y equipos de soporte que responden en 48 a 72 horas. Cada API mal documentada agrega entre 2 y 3 veces el tiempo de integración estimado.

Qué hacer en su lugar:Audite cada integración durante la fase de requisitos. Para cada servicio de terceros, responda tres preguntas: ¿Tiene un entorno de pruebas? ¿Qué tan completa está la documentación? ¿Cuál es el tiempo de respuesta de soporte? Luego, calcule el tiempo de integración 3 veces lo que parece razonable. Cree una prueba de concepto para la integración más riesgosa antes de comprometerse con el cronograma completo del proyecto. En Savi, creamos prototipos de integraciones de alto riesgo durante la primera semana y ajustamos el cronograma en función de lo que encontramos, no de lo que promete la página de marketing de la API.

6. Los lanzamientos big bang crean fracasos big bang

El enfoque de "construir todo, lanzar una vez" es la estrategia de entrega más riesgosa en el desarrollo de software. Los equipos pasan de 3 a 6 meses construyendo de forma aislada. Nadie fuera del equipo de desarrollo ve el producto. El día del lanzamiento, docenas de funciones entraron en producción simultáneamente. Compuesto de insectos. Los usuarios encuentran flujos interrumpidos. El equipo pasa las siguientes dos semanas en modo de extinción de incendios en lugar de iterar.

Los lanzamientos big bang también ocultan retrasos en el cronograma. Cuando todo el proyecto es un entregable monolítico, es imposible medir el progreso con precisión. Un equipo puede informar "80 % completo" durante 6 semanas consecutivas porque el último 20 % contiene los problemas más difíciles: pruebas de integración, casos extremos, configuración de implementación y migración de datos.

Qué hacer en su lugar:Envíe de forma incremental. Divida el proyecto en hitos de 1 a 2 semanas, cada uno de los cuales producirá una característica funcional e implementable. En Savi, realizamos demostraciones semanales en las que el cliente ve el software en funcionamiento, hace clic en flujos reales y brinda comentarios sobre un entorno de puesta en escena en vivo. Si algo anda mal, lo detectamos en la semana 2, no en la semana 12.

La entrega incremental también le brinda una trampilla de escape. Si el presupuesto o las prioridades cambian en la semana 4, tendrá un producto funcional con cuatro semanas de funciones implementadas y utilizables. Con la entrega big bang, no tienes nada utilizable hasta que se envíe todo el proyecto.

Una lista de verificación antes de comenzar su próximo proyecto

Estos seis problemas no son inevitables. Son fallas de proceso, y las fallas de proceso tienen soluciones de proceso. Antes de que comience su próximo proyecto, verifique estas seis condiciones:

• Los requisitos están escritos y firmados.Cada característica tiene criterios de aceptación. Las partes interesadas acordaron el alcance por escrito, no a través de una llamada que nadie documentó.
• Puede hablar con el ingeniero que construye su producto.Sin intermediarios traduciendo sus requerimientos. Acceso directo a través de Slack, correo electrónico o videollamada.
• El equipo es pequeño y senior.1 o 2 ingenieros full-stack propietarios de todo el código base. No es un equipo de 6 personas con transferencias entre frontend, backend, control de calidad y DevOps.
• Cada característica tiene una definición "terminada".Condiciones comprobables y específicas. No "crear el panel", sino "mostrar ingresos, pedidos y tasa de conversión con una exportación CSV".
• Las integraciones se crean prototipos tempranamente.La conexión de terceros más riesgosa se prueba en la semana 1, no en la semana 8.
• Ves software funcionando todas las semanas.Demostraciones semanales sobre un entorno de puesta en escena. Clics reales, datos reales, bucles de retroalimentación reales.

Los proyectos que cumplen los seis requisitos se envían a tiempo. Los proyectos que se saltan incluso uno de ellos se retrasan. La correlación es así de consistente.

Preguntas frecuentes