Muchos desarrolladores de software padecemos el “God Complex”: creemos que todas nuestras decisiones son acertadas y sabemos más que todos. También, que podemos resolver los problemas con poca o nada de ayuda.

El ejemplo más común es que saltamos a escribir el código sin haber entendido los requerimientos. Asumimos que nosotros siempre sabremos qué necesita el cliente, sin preguntarle. ¿Involucrar al usuario en la definición de la solución? ¡Para qué! A fin de cuentas, el cliente no sabe lo que quiere. Es algo que solemos decir.

Algunos de ustedes podrán decirme: “Edgar, es que así es el desarrollo ágil. Se descubre y refina la solución iterativamente, principalmente con código”.

Tienen razón en parte, pero ágil parte de un hecho: empezamos a implementar la solución sobre un problema que ya comprendimos en su mayoría y lo que se descubre es el cómo resolverlo mejor.

Por eso, aquí te dejo tres recomendaciones de lo que debes entender bien antes de comenzar el desarrollo de un producto de software.

¿Para quién es el beneficio/resultado de la solución?

Lo primero que debes hacer es entender quiénes son tus Stakeholders.

Todo el que reciba un impacto directo o indirecto con la existencia del producto es un Stakeholder. En esta lista, encuentras personas y grupos como el patrocinador, los usuarios, definidores de reglas de negocio y otros que se benefician con la existencia del producto de software.

Primero debes conocer sus objetivos, intereses y actitudes hacia el producto de software. Es una descripción del beneficio que obtienen y cómo contribuyen a obtener el resultado final.

Hacer esto nos coloca en la posición de comprender a quiénes estamos ayudando y nunca perder de vista esto.

¿Qué se quiere resolver y por qué hoy no se ha solucionado?

El contexto importa, como dice Scott Ambler. Las soluciones de software existen para hacer realidad un estado deseado; sin embargo, debemos partir de comprender la situación actual.

En el momento de iniciar el desarrollo, o al comienzo de un ciclo, se debe entender cómo los stakeholders hacen las cosas en ese momento y las circunstancias alrededor. De este modo, podremos saber por qué no se han podido alcanzar hoy los resultados esperados, donde han intervenido cosas como:

• Soluciones que no han funcionado
• El contexto actual de la organización (en cuanto a recursos, competencia, capacidad y tecnología)
• Oportunidades que no se habían definido o aprovechado

El producto de software debe estar enfocado en cerrar la brecha entre el estado actual y el deseado: resolver esos huecos e impedimentos entre ambos.

¿Por qué es importante resolverlo?

El software no existe solamente porque sí. Los stakeholders tienen objetivos trascendentales, más allá de “solo tener el software”. Esos objetivos se establecen en términos financieros, de negocio, de bienestar personal, de mejora en ciertos rubros.

Al comienzo del desarrollo, debemos establecer los objetivos del producto, con respecto a los stakeholders.

OJO, esto no es en términos de las funciones, sino de lo que los stakeholders persiguen como individuos u organizaciones.

Los objetivos establecen la dirección y los requerimientos que se alinearán.

¡Hasta la siguiente entrega!