Cuando se te ocurra una buena idea, querrás comunicársela a los clientes lo antes posible. Durante años, los equipos de marketing, servicio al cliente y productos han estado presionando para obtener entregas cada vez más rápidas.
Y los departamentos de TI también quieren aumentar la velocidad, pero a menudo se ven obstaculizados por la forma de trabajar.
Recientemente estuve hablando con el Jefe de Entrega de una organización que dijo que quiere pasar a versiones ágiles. Ha estado presionando a sus equipos para que dividan los grandes proyectos en lanzamientos más pequeños para que el valor se pueda entregar rápidamente, pero el costo de la entrega comenzó a aumentar y, según él, «se volvió prohibitivo».
El problema es que el costo solo se mide de una manera: el costo de entrega de un solo proyecto. Pero nada sucede de forma aislada, por lo que para medir el costo real, debe tener en cuenta los costos en toda la cartera. Lo que me lleva a los 6 costos ocultos de los grandes proyectos.
1. Construyendo lo incorrecto
Comenzaremos con el mayor costo. Sí, podría costar un poco más lanzarlo con más frecuencia, pero ¿cuánto podría ahorrar si se enterara de que está en el camino equivocado y cambia su enfoque antes de construir lo incorrecto?
Hasta 66% de funciones no logran entregar el valor esperado por lo que, incluso sin ninguno de los costos ocultos adicionales, esto por sí solo es suficiente para garantizar la inversión adicional.
2. Costo de mantenimiento
El costo de mantenimiento se refiere a los ingresos / valor que la empresa está perdiendo al no lanzar funciones del producto o correcciones que están listas para publicarse.
Cuando se aprueba un proyecto, generalmente tiene un rendimiento que es un múltiplo de la inversión: el valor comercial supera con creces el costo de implementación. Por lo tanto, incluso si tiene que aumentar ligeramente el costo de entrega, es probable que el lanzamiento anticipado signifique que la empresa está mejor.
3. Fusionar costos
Los proyectos no ocurren de forma aislada. En la empresa en la que estoy actualmente, por ejemplo, hay más de 60 proyectos en ejecución al mismo tiempo. Esto significa que existe una necesidad constante de fusionar los cambios de código de los proyectos que se están entregando ahora en proyectos de larga ejecución.
Cada fusión conlleva un riesgo, pero las fusiones más grandes tienen un riesgo exponencialmente mayor que da como resultado que los costos de fusión aumenten exponencialmente con el tamaño y la duración del proyecto.
4. Costos de demora
Otro problema que puede ocurrir es la aplicación prematura de la dependencia. Digamos que desea comenzar un nuevo proyecto y cree que tardará 6 meses en entregarse.
Ya hay otro proyecto en curso que se pondrá en marcha en 5 meses, por lo que tiene sentido construir sus cambios en una rama del código de proyectos anteriores. Esto reduce el costo combinado anterior, pero si el proyecto anterior se retrasa, usted también se retrasa.
5. Costos de bloqueo
Con arquitecturas monolíticas, que siguen siendo la norma, solo hay una configuración de código e infraestructura en producción, por lo que solo un proyecto puede estar en el camino hacia la producción en un momento dado.
Esto significa que otros proyectos deben hacer cola detrás de él. Los proyectos más grandes tienen caminos más largos para la duración de la producción, lo que bloquea el lanzamiento de otros proyectos.
6. Costos de planificación
Cuando las organizaciones ejecutan muchos proyectos, a menudo se programan muy cerca unos de otros para aprovechar las ventanas de lanzamiento limitadas en toda la cartera.
Esto hace que cualquier retraso del proyecto tenga un efecto en cascada en los proyectos posteriores. Me refiero al caos resultante como planificación circular; alinee todas las variables para generar un plan que funcione, comience de nuevo cuando una dependencia se deslice y repita continuamente hasta que finalmente la suelte.
Una vez que tiene en cuenta el número de proyectos en la cartera y la planificación, la gestión de recursos y los gastos generales de comunicación, el costo de un solo retraso del proyecto se multiplica rápidamente.
7- (más o menos). Solicitudes de cambio
Las solicitudes de cambio son un costo obvio, pero controvertido. Cuanto más grande sea el proyecto, más solicitudes de cambio se requerirán en el camino. Esto está tan aceptado que muchas empresas incluyen la contingencia de solicitudes de cambio en la planificación de sus proyectos.
El problema con este costo es que no es solo la solicitud de cambio, es el tiempo de análisis, el tiempo de aprobación y el tiempo de reelaboración. Si bien esto es significativamente más costoso en los proyectos de Waterfall, lo he omitido porque los proyectos ágiles también se encuentran con cambios.
¿Cómo podemos reducir estos costos?
La mayoría de los costos están relacionados con el tamaño del proyecto. Los proyectos más pequeños reducen estos costos porque las características se lanzan tan pronto como se desarrollan, las fusiones se vuelven más pequeñas, el riesgo de demoras se reduce y la tubería permanece abierta.
El contraargumento es que el costo de las pruebas de regresión aumenta porque debe asegurarse de probar todo en cada versión pequeña.
Dados los numerosos beneficios de las versiones pequeñas, el enfoque debe cambiar a realizar menos proyectos (y, por lo tanto, menos pruebas de regresión) para reducir el costo de las pruebas de regresión.
El desafío es que los procesos que están arraigados en muchas organizaciones tienen un sesgo hacia los grandes proyectos, como es el caso de la empresa que mencioné al principio. Si queremos hacer cumplir proyectos más pequeños, necesitamos introducir «funciones de forzamiento» que rompan los viejos hábitos. Hay dos tipos de funciones forzadas que podemos usar:
1. Regulación
Imagínese si solo pudiera pasar una semana en su camino hacia la producción. ¿Qué impacto tendría eso en sus proyectos? Para completar sus pruebas de regresión, debe invertir en automatización o realizar pruebas basadas en riesgos. Una vez que se entreguen estas mejoras y todos se adhieran al límite de una semana, puede reducir el límite de tiempo a 2 días, lo que desencadenará una mayor innovación.
2. Impuestos
Básicamente, tenemos que hacer visibles los costos de la forma en que estamos trabajando o se seguirán ignorando. Los impuestos son una excelente manera de lograr este objetivo. Un impuesto que aumenta exponencialmente en línea con la duración de un proyecto hace que el costo de entrega esté más en línea con sus costos reales. El resultado será que la gente empezará a pedir proyectos más pequeños, o en los casos en los que tengas que hacer un gran proyecto, el “impuesto” financiará la tecnología necesaria y las mejoras en las formas de trabajar para que los proyectos futuros no sean tan caro. Cualquiera de los resultados permite proyectos más pequeños.
La maldición de conseguir lo que pides
Hacer proyectos más pequeños y más fáciles de lanzar permite el cambio de toda la industria hacia equipos de productos, que esencialmente eliminan el concepto de proyectos por completo.
Los equipos lanzan continuamente pequeñas iteraciones y realizan mejoras constantes en los sistemas que cuidan. Esta es una estructura mucho mejor para los resultados comerciales porque puede probar ideas rápidamente y girar cuando sea necesario.
La desventaja es que esto es mucho más complicado para los especialistas en marketing u otros representantes comerciales. No puedes simplemente entregar ideas atractivas a otra persona para que las implemente.
Necesita compartir sus objetivos con los equipos de producto y trabajar con ellos, continuamente, mientras prueba nuevos experimentos para ver qué funciona y qué no. Si bien hay mucha más inversión en su nombre, es realmente estimulante ver cómo las ideas se hacen realidad rápidamente.
Si está interesado en obtener más información, consulte UXDX que se centra en ayudar a las empresas a pasar de proyectos tradicionales en cascada a equipos de productos multifuncionales.