Un modelo de proyecto mejor que la «cascada»

Esto ocurre todos los días: se entrega una «solución» a un equipo para que la construya. El equipo determina el alcance del trabajo, desarrolla un plan de proyecto y promete un conjunto de funciones para una fecha específica. Se supone que estas funciones resolverán algún problema empresarial o cumplirán con una directiva ejecutiva, ya que alguien con una remuneración superior a la del equipo de ejecución ha bendecido el trabajo. Y con este conjunto de características y plan de proyecto el ciclo de las cascadas empieza de nuevo.

El equipo comienza a definir el trabajo minuciosamente y describe todos los escenarios posibles, casos de uso, punto de integración del back-end y regla empresarial. El equipo de diseño parte de ahí y articula visualmente la ubicación de cada píxel y la lógica detrás de cada campo de entrada, casilla de verificación y botón de envío. Pronto los ingenieros de software tendrán su turno de bateo, seguidos de cerca por sus compatriotas en materia de control de calidad y, finalmente, cuando se hayan impreso las camisetas y se hayan reducido las fiestas de lanzamiento, los clientes de la empresa tendrán su primera oportunidad de utilizar el nuevo producto.

A pesar de la confianza que inspiran toda esta planificación y diseño iniciales, lo único garantizado que saldrá al final de este proceso en cascada es una solución equivocada. No es que el patrocinador del proyecto haya elegido un conjunto de funciones inadecuado o que la experiencia de usuario del sistema haya sido mala. El equipo presentó una solución equivocada porque el proyecto se basaba en suposiciones no validadas. Estas suposiciones se presentaron como requisitos y, como tales, no se posicionaron como algo que pudiera refutarse o incluso cuestionarse.

**Ejemplo de requisito:
**Crearemos tres nuevas rutas de conversión con tres nuevas verticales de contenido para atraer nuevos clientes.

El problema con los requisitos es que a menudo son incorrectos. Si un equipo no tiene la oportunidad de averiguar si las funciones prescritas resuelven una necesidad que realmente existe para los clientes reales, el esfuerzo está condenado al fracaso el día de su publicación. A mi socio de negocios Josh Seiden le gusta decir: «En el desarrollo de software, los murciélagos de la realidad son los últimos». Lo que quiere decir es que no importa lo optimista que sea un equipo con respecto al producto que está creando, lo único que demostrará que el proyecto tiene éxito o no es la realidad de que los clientes reales lo utilizan para resolver problemas reales. Trabajar al estilo de una cascada retrasa el turno de la realidad hasta el final del proyecto, cuando se han gastado todos los recursos. Esto es extremadamente arriesgado, ya que cualquier fallo fundamental en la solución (ya sea una función que los clientes no necesitaran realmente o la dificultad de los clientes para utilizarla) es extremadamente caro de corregir en un momento tan posterior.

En lugar de presentar a sus equipos listas de funciones para crear en secuencia, las organizaciones deberían presentarles a sus equipos los problemas empresariales que resolver. Indique las restricciones para la solución y cualquier suposición que exista actualmente sobre ese problema empresarial y su público objetivo. Lo más importante es que a cada equipo se le deben cumplir criterios de éxito específicos. Estos criterios deben ser cuantificables y apuntar a resultados específicos que demuestren que se han satisfecho las necesidades del cliente y se ha resuelto el problema empresarial.

**Ejemplo de declaración de problema:
**Las tasas de conversión han bajado hasta el 1,12% entre los compradores frecuentes por Internet de entre 18 y 34 años. Esta disminución se debe en gran medida a una disminución similar de la tasa de visitantes que regresan a este grupo (actualmente es del 9%). Esto indica una disminución del valor de nuestra oferta para estos clientes. El negocio del comercio electrónico necesita generar al menos 61,2 millones de dólares este año, y el 20% proviene de este grupo demográfico. Tenemos que alcanzar una tasa de visitantes que regresan del 40%, lo que nos permitirá alcanzar la tasa de conversión del 5,4% necesaria para alcanzar nuestros objetivos de ingresos.

Al cambiar la conversación de la producción de funciones a resultados que se puedan medir de forma explícita, el equipo puede empezar a encontrar la mejor solución a este problema. Entonces, en lugar de redactar un conjunto de requisitos rígidos, el equipo empieza a escribir una serie de hipótesis. Estas hipótesis exponen las suposiciones del equipo de una manera comprobable.

**Ejemplo de hipótesis:
**Creemos que la creación de tres nuevas verticales de contenido aumentará el número de clientes nuevos y habituales. Sabremos que tenemos éxito cuando el número de nuevos visitantes aumente un 5% y el número de visitantes que regresan se duplique con respecto a su estado actual.

Trabajando en ciclos cortos e iterativos, el equipo ahora puede empezar a probar formas de probar esta hipótesis. En lugar de centrarse en grandes conjuntos de funciones, el equipo concibe, diseña y crea «primeros borradores» de ideas que se despliegan rápidamente. Estos «primeros borradores» se miden con las métricas objetivo y, si son prometedoras (es decir, las cifras avanzan en la dirección correcta), se refinan en la siguiente iteración. Si no funcionan, se rediseñan o desechan en favor de la siguiente idea.

Estos estrechos ciclos de aprendizaje permiten al equipo reducir partes de riesgo significativamente más pequeñas y, al mismo tiempo, dan a la realidad la oportunidad de tomar muchos turnos en el plato. El equipo aprenderá muy rápido que crear tres nuevas verticales de contenido es exagerado y solo se necesita una. Como alternativa, puede que aprenda que tres nuevas verticales no marcarán ninguna diferencia en sus métricas de éxito. En ese momento tendrán que concebir una nueva hipótesis.

Cuando acabe el plazo del proyecto, puede que el equipo no haya lanzado tantas funciones como las que tendría en la antigua cascada, pero las que sí enviaron son las funciones correctas. Trabajar con hipótesis en lugar de con requisitos permite al equipo determinar qué soluciones tienen más promesas de éxito y, al mismo tiempo, minimizar el tiempo dedicado a desarrollar ideas incorrectas.