Definiendo el éxito en los proyectos

La primer definición de “proyecto exitoso” surge de los inicios de la industria informática, cuando su objetivo era informatizar procesos establecidos. Cuestiones como trayectorias balísticas o cálculos de impuestos debían seguir procedimientos precisos: cualquier desvío podía costar dinero, multas o vidas.

En otras palabras, el foco estaba en lo que sucedía en la máquina. Lo que sucedía delante de ella, no era una preocupación. De hecho, los términos usabilidad y experiencia de usuario recién aparecerían algunas cuantas décadas más tarde.

Es así que la primer definición de Calidad, que podemos considerar fundacional, es lo que se conoce como la triple restricción:

  • Costo: todos los recursos empleados, particularmente los recursos humanos (“horas”).
  • Tiempo: el tiempo calendario que durará el proyecto.
  • Alcance: lo que el equipo se compromete a construir.

En la forma de trabajo de ese entonces, que desde 1970 se conoce como “waterfall” o “cascada” y que muchos aún utilizan, estas variables se definían antes de empezar a construir el software, en una fase preliminar de análisis y estimación.

Cualquier diferencia entre esta estimación y la ejecución real, se entendía como desvío. La triple restricción tiene forma de triángulo, por dos razones:

1. Interdependencia: como en un triángulo, modificar cualquiera de las variables, requiere ajustar al menos una de las otras dos. Por ejemplo, si se revela que es necesario construir más que lo estimado, será necesario no sólo extender el alcance, sino también acomodar el costo y/o tiempo en consecuencia.

2. Simplicidad: Supongo que el triángulo debe ser la forma geométrica más compleja que pueden entender quienes pretendan seguir aplicando el modelo “en cascada”, ignorando que su primer descripción formal (Royce, 1970) era en realidad una crítica que exponía sus severas limitaciones.

En su paper de 1970, Winston W. Royce presentaba en la página 2 el modelo “en cascada” y luego lo defenestraba, proponiendo un enfoque más rico e iterativo que documentaba en detalle nueve páginas más tarde.

Evolución del concepto de “éxito” en proyectos de software

Desde 1994, el Standish Group se ha dedicado a analizar el éxito y el fracaso de los proyectos de software, revelando en su informe CHAOS Report tendencias y factores determinantes en la gestión de proyectos tecnológicos.

Las conclusiones de la primera edición fueron contundentes: el 84% de los proyectos de software, resultaban deficientes o abandonados.

Si el 84% de los edificios colapsaran antes de ser terminados, preferiríamos vivir a la intemperie. Si el 84% de las cirugías fracasaran, aprenderíamos a andar por la vida cargando nuestros órganos en una bolsa. Pero en tecnología, esto no genera pánico ni titulares: simplemente se acepta como parte del paisaje.

Esta evidencia quizás haya ayudado a cuidar las variables, y con los años se haya observado una mejora de vez en cuando. Pero los mayores impactos los tuvieron dos grandes cambios de criterio:

  • En 2001, el Manifiesto Ágil propuso una transformación en la gestión de proyectos, sugiriendo pasar del enfoque rígido y formalista a uno pragmático, que priorizara individuos e interacciones, software funcional, colaboración con el cliente y capacidad de respuesta ante el cambio.
  • En 2015, el Standish Group ajustó su criterio de éxito, considerando como “exitosos” aquellos proyectos que, dentro del tiempo y presupuesto establecidos, lograban “resultados satisfactorios”, sin la necesidad de cumplir estrictamente con todo el alcance planificado.

Es así que en 2020, los proyectos ágiles mostraron más del triple de proyectos exitosos, y menos de la mitad de proyectos fallidos que sus contrapartes en cascada:

Entonces, ¿ya tenemos la solución para lograr el éxito?

Empecemos por observar que para 2020, la definición de éxito que se venía aplicando, resultaba un poquito anacrónica.

Como recordarán, esa definición había nacido para evaluar la informatización de procesos bien definidos. Pero la realidad es que para mediados de la década del ’80, de esos procesos quedaban pocos aún sin resolver. Buena parte de la industria se estaba volcando a producir software como producto, para usuarios de computadoras personales. Lo cual dio un vuelco final cuando terminando el siglo XX explotó la Internet.

Hoy en día, la mayoría de los proyectos de desarrollo de software se centran en la creación de sistemas destinados a ser utilizados por usuarios finales, ya sean herramientas internas para empleados o productos y servicios destinados a su lanzamiento y monetización en el mercado.

Esto implica que la definición de “éxito” debe considerar la aceptación por parte de los usuarios, una variable que el Standish Group no contempla al aplicar una estricta perspectiva de ingeniería.

Construyendo nuestra definición de “éxito” para la industria de las experiencias

Para construir nuestra nueva definición sobre la anterior, partimos de considerar exitosos sólo los proyectos que antes satisfacían esa medida.

Y luego, observamos que podemos tomar la cantidad de descargas de las Apps como medida de su aceptación en el mercado:

Basado en Zhao, Sha & Pan, Gang & Zhao, Yifan & Tao, Jianrong & Chen, Jinlai & Li, Shijian & Wu, Z.. (2016). Mining User Attributes Using Large-Scale App Lists of Smartphones.

La distribución de descargas de aplicaciones sigue una ley de potencias, similar a la ley de Zipf: unas pocas aplicaciones acumulan la mayoría de las descargas, mientras que la mayoría recibe muy pocas.

Como vemos, el 80% de las aplicaciones no supera las 10.000 descargas. En un mercado de millones de usuarios, esto es prácticamente homeopático. Pero para peor, considerando que la mayoría de las apps se monetizan a un precio cercano a 1 dólar (o euro) por usuario, los ingresos obtenidos no alcanzarán para cubrir los costos de desarrollo, marketing y otros gastos asociados (de al menos, entre 18.000 y 100.000 €).

Del otro 20%, es la mitad es la que realmente se lleva la torta: tan sólo el 10% acapara el 90% de las descargas.

Pero para ser generosos y optimistas, digamos que el 20% es “exitoso” en lo que hace a aceptación. Y para calcular qué porcentaje de proyectos representa, tomamos el mejor valor del criterio del Standish Group (el 42% de proyectos técnicamente exitosos ). El producto nos daría los proyectos que podemos considerar exitosos tanto desde lo técnico, como en el mercado: tan sólo el 8.4% de los proyectos.

O en otras palabras:

En la industria de las experiencias, la probabilidad de fracaso es de más del 90%.

Si fuéramos muy generosos y tomáramos el 8.4% de no sólo al 42% de proyectos técnicamente exitosos, sino también del 47% de “desafiados” (de alguna manera, puestos en producción), la probabilidad de fracaso sería de un 82.2%. Lo cual sigue siendo terrible.

Ante eso, los capitanes de los proyectos, las personas en la punta de la pirámide de decisiones gerenciales de la que depende que los proyectos existan, suelen tener su foco en otra parte.

El muy probable fracaso del proyecto no es algo que los capitanes de los proyectos tengan activamente en el radar para evitarlo.

En parte, porque se han formado en otras aguas: gerentes con alto seniority que llegan a la aún naciente industria de las experiencias desde industrias más maduras como bienes y servicios, están confiados en saber reconocer a tiempo las tormentas. Esa confianza suele jugarles malas pasadas cuando los riesgos son tan abstractos como la materia con la que se trabaja: software y comportamiento. Y en donde las aguas, en lugar de hacer olas, tienden a espesarse hasta que se termina remando en dulce de leche.

Y en parte, porque como dice mi colega Kaleem Khan: “Nadie quiere creer que lo que ofrece es de mala calidad o deficiente, porque nadie se propone lograr un mal diseño como objetivo. Siempre es un riesgo. Los malos diseños y las malas experiencias… ocurren”.

Entonces, ¿qué es “éxito” para Experience Decision Making?

Frente a este escenario, en Kambrica y en XDM definimos el éxito en los proyectos sobre tres dimensiones:

1. Software funcionando vs. defectos y sobreproducción.

Siguiendo el manifiesto ágil, nuestra definición considera software funcionando (que puede portar valor real: producto que llegue a los usuarios), por sobre documentación extensiva.

La documentación no puede portar valor en sí misma, porque nunca llega a los usuarios finales. En el mejor de los casos, podemos considerarla equivalente a los andamios que se erigen al menor precio posible para poder construir un edificio. Pero de la misma manera en que un andamio bañado en oro no hace ninguna diferencia más que el mayor costo, hay un punto a partir del cual mayor esfuerzo y nivel de detalle en la documentación no se traduce en mejor software: nos encontramos ante un tipo de desperdicio.

Tomando la distinción entre valor y desperdicio de la filosofía Lean –y en particular, de Lean Software Development– nuestra definición de calidad del producto final evita:

2. Aceptado y adoptado por usuarios reales vs. impuesto, resistido, rechazado.

La aceptación de los usuarios finales es crítica para un producto o servicio tecnológico que se pretende monetizar. Como vimos, sólo el 20% de las aplicaciones lanzadas logran superar las 10,000 descargas: en otras palabras, el 80% de los proyectos resultan económicamente inviables.

Pero la aceptación de los usuarios finales también es determinante para el caso de herramientas internas. Un software cometido sin ninguna consideración por la facilidad de uso y curva de aprendizaje, requerirá de horas o días de “capacitación”, y de un buen tiempo hasta que al usuario se lo pueda considerar productivo. He llegado a ver el caso de un Call Center donde se considera que cada nuevo empleado requiere de tres meses hasta tener suficiente dominio del sistema poder resolver todos los casos que requiere su función. Tres meses durante los que se le pagará un sueldo, y que el día que renuncie, habrá que volver a dedicar con su reemplazo.

Pero la historia no termina ahí. Una vez superado esa barrera inicial, el mal software seguirá cobrando su tasa. Cada minuto adicional que los empleados pierdan debido a software difícil de usar, que no se adecúa a su real proceso de trabajo, o simplemente ineficiente, será más productividad y dinero perdidos. El modelo KLM-GOMS permite estimar el tiempo adicional que los empleados tardan en completar sus tareas debido a problemas de diseño y usabilidad: multiplicado por el salario promedio, se puede obtener una estimación del costo asociado a la ineficiencia del software, que para una planta de miles de empleados resulta millonaria.

El software sólo puede lograr valor si es aceptado y adoptado. En el mercado, el software no aceptado no genera ingresos. En herramientas internas, la resistencia de los empleados al software que se les pretende imponer siempre refleja ineficiencias operativas, donde la mala usabilidad causa confusión, errores y pérdida de productividad.

3. Cumpliendo objetivos de Negocio vs. deseos, caprichos y fracasos.

Para que un proyecto sea exitoso, debe centrarse en objetivos de negocio claros y medibles. Lo cual empieza por el desarrollo de una habilidad ejecutiva crítica: distinguir Deseos de Objetivos.

Cuando por no conocer las aguas de la industria de las experiencias se priorizan deseos o caprichos de los stakeholders, el proyecto pierde enfoque y genera desperdicio de recursos, ya que se invierte tiempo en tareas que por definición no aportan valor al Negocio.

Sólo al definir bien los objetivos y alinearlos con las mejores prácticas de la industria es posible generar resultados de calidad, verdaderamente orientados a las necesidades del cliente.

Definir qué es éxito y Calidad, es el primer paso de todo proyecto.

La Calidad no se puede agregar a un producto ya terminado. Es el resultado de las decisiones de todos los involucrados en su construcción.

Para lograr mejores experiencias y mejores productos, necesitamos claridad y tomar mejores decisiones.

De eso se trata el sistema Experience Decision Making que desarrollamos en Kambrica.