Por qué el Diseño Centrado en el Usuario es más eficiente que el desarrollo en cascada (Parte 1)

Uno de los principales desafíos que enfrentamos los profesionales de User Experience es cómo lograr que nuestros clientes acepten trabajar bajo un proceso de Diseño Centrado en el Usuario en lugar de uno en cascada. En este artículo propongo un ejercicio comparativo simple para analizar la eficiencia económica de un proceso y el otro. 

Descripción de los supuestos

Supongamos que recibimos un requerimiento para desarrollar una aplicación móvil en cinco semanas. De acuerdo al análisis preliminar que hemos hecho se requerirán dos semanas de diseño que alimentarán otras cuatro semanas de desarrollo. La segunda semana de diseño se solapará con la primera de desarrollo por lo que el proyecto tendrá una duración de cinco semanas de acuerdo a lo solicitado por nuestro imaginario cliente.

El costo de los recursos de diseño y programación es de U$S 50.- (cincuenta dólares) por hora cada uno de ellos, por lo que el costo total del proyecto podría estimarse de la siguiente forma:

• Tareas de diseño:  80 (horas) x 50 (dólares) = U$S 4000.- (cuatro mil dólares) 
• Tareas de programación:  160 (horas) x 50 (dólares) = U$S 8000.- (ocho mil dólares) 
• TOTAL PROYECTO:  U$S12.000 (doce mil dólares)  

Estimación del riesgo del proyecto.

El riesgo puede estimarse de muchas maneras. A los fines de este ejercicio se calculará a partir de dos variables:

• Riesgo = especificidad de los requerimientos x tiempo de desarrollo

Considerando que cuanto menos precisa es la especificación de los requerimientos y mayor es el tiempo de desarrollo el riesgo será también mayor.

Proceso de desarrollo en cascada

Un proceso de desarrollo en cascada consiste en la realización de una serie de etapas consecutivas de trabajo (en este caso diseño y desarrollo) hasta la finalización del proyecto que culmina con la entrega completa de la aplicación según los requerimientos definidos antes de comenzar. Si tuviéramos que graficarlo de manera simple el proceso se compondría de tres grandes etapas:

Esta metodología no contempla la posibilidad de medir los resultados hasta el final del proyecto, en parte porque recién en ese momento se dispondrá de un entregable capaz de ser medido y, en parte, porque no considera necesario realizar ninguna medición antes del lanzamiento de un producto. En todo caso, los resultados podrán ser estimados luego, midiendo el comportamiento del producto en el mercado real.

Teniendo en cuenta esto podemos decir que la utilización de un proceso en cascada demandaría para este proyecto una inversión de U$S12.000 dólares y cinco semanas de desarrollo para obtener algún resultado.

El riesgo en un proyecto con una metodología de desarrollo en cascada

Cuando agregamos el componente de riesgo, las estimaciones iniciales en cuanto a tiempos y costos cambian sustancialmente. Veamos qué sucede con las dos variables que, en nuestro análisis, componen el riesgo:

• Especificación de requerimientos: las definiciones de requerimientos hechas antes de iniciar un proyecto y no revisadas posteriormente a medida que el desarrollo va avanzando contienen una serie de supuestos que las vuelven imprecisas y, a veces, directamente equivocadas. Al respecto, Jason Fried y David Heinemeier Hansson en su libro Rework, plantean muy acertadamente que el momento en el cual menos se conoce de un determinado problema es antes de comenzar a resolverlo. Sin embargo, en un proceso en cascada, es ese el momento en el que se definen los requerimientos que guiarán todo el proceso de desarrollo, aumentando desde el inicio los riesgos de desvío producto de la defectuosa definición de requerimientos.
• Tiempo de desarrollo: el tiempo transcurrido hasta la primera instancia de medición de resultados y, por lo tanto, de identificación de posibles problemas y su corrección, se podría hacer recién en la quinta semana del proyecto, es decir al final, teniendo ya consumidas la totalidad de las horas de diseño y desarrollo estipuladas.  

Considerando estos dos factores, el riesgo de desvío en un proceso de desarrollo en cascada es alto. De hecho, según un reciente estudio de IAG Consulting (en Inglés) las compañías definidas como inmaduras en la definición de requerimientos fallan la mitad de las veces en alcanzar los objetivos planteados para una aplicación y requieren un 35% más de tiempo y presupuesto para lograrlo.

Volviendo a nuestro ejemplo, si los resultados no fuesen los esperados (lo cual como vimos tiene en promedio un 50% de chances de suceder bajo esta metodología) habrá que sumar un 35% más de tiempo de desarrollo y presupuesto para realizar los ajustes necesarios y así alcanzar los objetivos planteados. Esto llevaría la inversión total del proyecto a U$S16.200 dólares y casi siete semanas, en lugar de las cinco originalmente estimadas.

Todo este proceso podría graficarse como se ve a continuación:

Aquí se observa la diferencia entre la estimación inicial y lo que realmente sucedería, producto del incremento del riesgo a medida que avanza el desarrollo y las decisiones se van tomando en base a requerimientos defectuosamente definidos.

En la segunda parte de este artículo vamos a describir de qué manera el Diseño Centrado en el Usuario evita estos desvíos, disminuye el riesgo, el tiempo y los costos de desarrollo.


Gráficos: Tamara López Breit