La falta de uso de las aplicaciones y la crisis del software

Las imágenes como la que se muestra a la izquierda son conocidas y familiares para muchos de nosotros, quienes estamos involucrados con el desarrollo de software. En México tenemos una frase que usamos para casos como éste: “No sé si reír o llorar”. Y es que, desafortunadamente, muchos de nosotros hemos sufrido en carne propia muchas de las desilusiones que los proyectos de desarrollo de software generan.

Uno de los fenómenos que se han presentado en los últimos años es el de la falta de uso de las funcionalidades de las aplicaciones desarrolladas con métodos que implican recopilar todos los requerimientos desde el inicio (Examining the "Big Requirements Up Front (BRUF) Approach, 2022).

No se trata solo de una percepción o sentimiento de algunos pocos desarrolladores. Según el Standish Group, más de la mitad de los proyectos de software exceden sus presupuestos y su duración, además de que no cumplen con el alcance pactado (The Standish Group, 2015). Podríamos decir que ese fenómeno es una de las principales causas de que se haya acuñado el concepto de “La crisis del software” (Crisis del software, 2022).

La importancia del involucramiento de los usuarios

Si ahondamos un poco más, encontraremos que uno de los principales factores que influyen en el hecho de que más de la mitad de los proyectos tengan dificultades o que inclusive sean cancelados, es la falta de involucramiento de los usuarios:

Y si, por otro lado, evaluamos cuál es el principal factor que influye en que los proyectos exitosos, encontraremos que es precisamente lo mismo, el involucramiento de los usuarios:

Entonces, ¿cómo involucrar a los usuarios?

Existen varias formas de hacerlo:

• Hablar directamente con ellos: sé que parece obvio, pero es increíble la cantidad de proyectos en los que he participado en los que las áreas de T.I. definen los requerimientos para las aplicaciones, en lugar de que lo hagan los usuarios finales.
• Seleccionar una técnica de recopilación de requerimientos, que los involucre, y usarla, aquí dejo algunas:

o   Entrevistas

o   Encuestas

o   Grupos de enfoque

o   Prototipado

o   Observación (Job Shadowing)

o   Otras

Ahora, la más importante propuesta que tengo por hacer para involucrarlos es:

Identificar cuál es el reto de negocio

Muchos usuarios o clientes se acercan a los desarrolladores de software con una propuesta de la aplicación que quieren desarrollar, pero ¿qué pasaría si ellos se acercaran para explicar primero cuál es el reto de negocio que enfrentan?

Cuando hablo de reto de negocio me refiero a:

• Objetivo de negocio que desean o requieren lograr.
• Problema de negocio que requieren resolver.
• Oportunidad de negocio que desean o requieren aprovechar.
• Regulación que deben cumplir.

Típicamente, una iniciativa que pretende desarrollar software está alineada a uno, o alguno, de los cuatro retos anteriores, pero no necesariamente a todos ellos.

Entonces, imaginen este escenario:

El escenario anterior presenta diferentes puntos en los que, potencialmente, puede haber contacto con los usuarios, pero nosotros nos enfocaremos en la etapa de identificación de los retos de negocio. Para ello, quiero proponerles el uso de los siguientes formatos:

Cómo definir un problema de negocio

Cómo definir un objetivo de negocio

El formato anterior está relacionado con la metodología de Google para definición de objetivos, conocida como OKRs (Objectives and Key Results), para mayor información, consulta esta guía.

Cómo definir una oportunidad de negocio

Conclusiones

Para ser concreto y resumir lo presentado aquí:

• Continuamente se desarrollan aplicaciones que ofrecen funcionalidades que no son empleadas por sus usuarios.
• La falta de uso de aplicaciones es uno de los problemas que enfrenta la industria del software como parte de la crisis por la que pasa.
• Una de las causas de esta crisis del software es la falta de involucramiento de los usuarios durante los proyectos de software.
• Los usuarios pueden ser involucrados de diferentes formas.
• Una de esas formas en las que pueden/deben ser involucrados es identificando sus retos de negocio para posteriormente determinar cuál es la mejor solución de negocio para dicho reto.

Referencias

• Crisis del software. (13 de 10 de 2022). Obtenido de Wikipedia: https://es.wikipedia.org/wiki/Crisis_del_software
• Examining the "Big Requirements Up Front (BRUF) Approach. (15 de 10 de 2022). Obtenido de Agile Modeling: http://agilemodeling.com/essays/examiningBRUF.htm
• McConnell, S. (2006). Software Estimation. Redmond, Washington: Microsoft Press.
• The Standish Group. (2015). Chaos Report. Boston, MA: The Standish Group.