En este post hablaremos sobre la importancia de tener un buen relevamiento previo antes de empezar a desarrollar nuestro producto. Veremos que ventajas y desventajas tendremos. ¡Manos a la obra!
Una pequeña introducción a la realidad
¿Cuántas veces nos ha ocurrido que al momento de estar en la Sprint Review el cliente nos comenta que el esperaba que nuestra aplicación tenga otro tipo de comportamiento? Esto no es algo nuevo, dentro del mundo del desarrollo de software la mayoría de las problemáticas se encuentran a la hora de relevar, documentar, validar y modificar requerimientos del producto. Ya sea porque tenemos requisitos poco especificados, funcionalidad asumida como válida por los desarrolladores, pero no validada por el usuario, falta de comunicación a la hora de obtener una definición y suposiciones que asumimos como verdadera cuando en realidad son falsas.
Todos estos problemas se pueden solucionar si dedicamos el tiempo necesario a “desarrollar” los requisitos dados.
Dilbert. Un proyecto en el cual no se desarrolla los requisitos esta condenado a fracasar
Trabajando correctamente en los requisitos tendremos un horizonte feliz donde los clientes estarán encantados con lo desarrollado y nosotros, los desarrolladores, estaremos felices y motivados. En caso contrario nos encontraremos en una situación en donde la calidad del producto que entreguemos no tenga valor para el cliente, provocando fricción y confusión en ambas partes.
Para esto existe una rama de la ingeniería dedicada a esto. La ingeniería de requisitos. Pero te estarás preguntando previamente ¿qué es un requisito?
De vuelta a la Teoría: ¿Qué es un requisito?
Un requisito es la condición que debe cumplir algo. Yendo más a la rama de desarrollo de software englobaría las características que debe tener nuestro producto, sean funcionalidades y/o restricciones.
Un problema común que vamos a encontrar buscando información en internet es que el termino requisito se lo suele confundir con la palabra requerimiento. Tanto es así que se suele llamar a la Ingeniería de Requisitos como Ingeniería de Requerimientos. Esto es erróneo ya que la palabra requerimiento está asociada a la acción de cumplir un requisito.
Este problema surge debido a que en ingles la palabra requeriment significa requisito y requerimiento a la misma vez lo que provoca el error al traducirla al español.
En el siguiente diagrama podemos observar la diferencia entre requerimiento y requisito:
En la imagen anterior podemos observar que existen diferentes tipos de requisitos, brevemente:
- Requisito Funcional: El cual describe el comportamiento exhibido del sistema en ciertas condiciones
- Requisito No funcional: el cual describe las características y propiedades que el sistema debe exhibir
- Regla de Negocio: Una política, reglas o regulaciones que define restricciones en nuestro negocio
La ingeniería de Requisitos
La ingeniería de requisitos es la rama que comprende el proceso de descubrir, analizar, verificar y validar las necesidades de las partes interesadas en el desarrollo del software.
La podemos dividir en 2 partes importantes: Desarrollo de los requisitos y el Manejo de los mismos.
En este post nos vamos a enfocar en el desarrollo de requisitos.
Desarrollo de Requisitos
Esta subrama de la ingeniería de requisitos engloba todas las actividades necesarias para la exploración, evaluación, documentación y validación de requerimientos de un producto. Podemos identificar 4 etapas importantes: Descubrimiento, Análisis, Especificación y Validación.
Descubrimiento
La etapa de descubrimiento (o elicitación) engloba todas las actividades que intervienen en el descubrimiento de requerimientos como entrevistas, talleres, prototipado, etc...
Es importante remarcar que en esta etapa debemos: Identificar quienes van a ser los usuarios de nuestro producto y quienes son los interesados, Entender la meta de los usuarios y el objetivo del negocio para alinearnos
Análisis
La etapa de análisis involucra todas las actividades necesarias para entender de forma más precisa los requisitos dados.
Es clave en esta etapa: Analizar la información de los usuarios para identificar requisitos funcionales, requisitos no funcionales, reglas de negocio, etc.; descomponer requisitos de alto nivel en bajo nivel.
Especificación
La etapa de especificación involucra las actividades necesarias para representar el conocimiento adquirido acerca de los requisitos en etapa previas de una manera organizada y persistente.
En esta etapa debemos trasladar las necesidades de los usuarios en forma documentada ya sea en historias de usuarios, casos de usos o diagramas para la compresión y revisión de la misma con los usuarios.
Validación
La etapa de validación involucra todas las actividades las cuales se enfocan en validar los requisitos para que el equipo de desarrollo empieza a desarrollar el producto.
Es clave en esta etapa validar los requisitos con el usuario para garantizar que el producto desarrollado cumpla con las necesidades del negocio mismo.
Todo definido antes de empezar a desarrollar
Tenemos estas 4 actividades. Ahora ¿Esto me garantiza que voy a lograr tener todos los requisitos definidos a la hora de empezar un proyecto? La respuesta es no. Esto es comprensible, entender todas las necesidades del negocio y/o usuarios lleva tiempo. Además, las necesidades de los usuarios cambian todo el tiempo y es necesario adaptarnos a esos cambios. Teniendo un proceso iterativo podemos refinar los requisitos de manera cíclica llevando de alto nivel a bajo nivel validando con los usuarios de por medio.
La idea del Desarrollo de Requisitos es lograr tener una base mínima de requisitos definidos para empezar a construir un producto en el cual entendemos la necesidad de los usuarios y el negocio.
El problema de los malos requisitos
Supongamos la siguiente situación. Estoy en medio de la sprint review y el usuario me dice “Lo que hiciste no me sirve la verdad, tenemos que cambiar todo”. Ufff, algo muy duro que te diga. No solo afecta tu moral como desarrollador preguntándote que salió mal, si no que vas a tener que modificar todo lo que hiciste hasta que cumpla con las expectativas del usuario. Hipotéticamente si lo que hiciste costo $1000, agregando todos estos cambios para rediseñar tu aplicación le agregaría un costo adicional, por ejemplo $2000. ¡Felicidades! ¡Triplicaste el costo del producto! ¡El cliente va a estar muy feliz de pagar esta diferencia!
Bromas aparte, acá vemos el fuerte de la Ingeniería de Requisitos. Si se hubiera tomado un mínimo de tiempo para descubrir, analizar, especificar y validar requerimientos es muy probable que toda esta situación no hubiera ocurrido.
Aplicando la ingeniería de requisitos evitamos esta situación y nos encontramos en un caso ideal en el cual entendemos la necesidad de los usuarios y nuestro producto creado tiene un valor en el negocio.
Problemas comunes a la hora de relevar
En esta sección vamos a incluir algunos consejos en situaciones comunes que vivimos en el día a día.
Falta de involucramiento con los usuarios
Busquemos la forma de involucrarnos con ellos. Es importante empatizar con ellos, entender sus necesidades y problemas. Entendamos cuál es su ambiente de trabajo, el negocio en el que están. Con solo saber esto sabremos en que escenario estamos parados y podemos tomar decisiones que realmente den valor a nuestro producto. Mas importante, sabremos el “Para que” y “Para quien” de nuestro desarrollo.
Estimaciones con requisitos poco definidos
Situación común: Organizamos una entrevista con el usuario, nos cuenta que es lo que quiere y al final nos pide una fecha de cuándo va a tener todo esto listo. Suena muy tentador querer quedar bien y tirar una fecha ahí mismo, pero esto es un error grave que nos va a perseguir en todo el desarrollo. Estamos condicionando nuestro tiempo desarrollo sin haber analizado que es lo que tenemos que hacer, que problemas podemos encontrar, restricciones de negocio y supuestos que asumimos como valido.
Una estimación hecha sin haber desarrollado previamente los requisitos es muy probable que no cumpla el tiempo pautado. Lo más común es que se modifique el tiempo provocado por cambios a la hora de analizar requerimientos (existentes o nuevos que hemos descubierto).
Lo ideal para hacer una estimación es analizar la información que se nos dio, suponer condiciones dadas que damos por hechas y validar nuevamente con el usuario para ver que entendimos lo mismo.
Sobrecarga de requisitos
El algo muy común esto, el usuario quiere tener la aplicación con todo los requisitos. Es importante nunca perder el foco del para que estamos haciendo las cosas. En este caso podemos simplemente analizar los requisitos que tenemos, ver cuáles son los que más le dan valor al usuario y planear futuros releases para los restantes.
El famoso Gold Plating
Vayamos ahora un problema que viene del desarrollo. Estamos desarrollando una funcionalidad dada y decidimos agregar algo adicional porque creemos que al usuario le ve a encantar. Esto es un problema: Estamos dedicando tiempo a hacer algo que no se pidió y no sabemos si esto tiene un valor para el mismo.
A la hora de desarrollar vayamos por lo que acordamos, vayamos por lo que le da valor real al producto. No digo que este mal pensar en mejoras, pero previamente tenemos que validarlas con el usuario para analizar su valor en el negocio (Por ejemplo: podemos hacer un prototipo en papel y explicarlo, pero no desarrollarlo)
Conclusiones
Ahora que sabemos que conocemos toda la teoría, que es un requisito, que es la ingeniería de requisitos y cuál es su objetivo podemos ver que lo que se plantea no es nada descabellado. Un proyecto tiene todas las papeletas para triunfar si sabemos el para qué y para quien lo estamos haciendo, conocemos el negocio, conocemos los interesados y sus usuarios.
En el momento que me encuentre desarrollando una historia y me pregunte por que se pidió esto y desconozca la respuesta es una señal para parar la pelota y empezar a indagar la validez de lo que estamos haciendo.
Como párrafo final, me gustaría que la próxima vez que nos llegue un requerimiento del usuario no salgamos a escribirlo en una historia de usuario de una y empecemos a desarrollar. Dediquemos el tiempo para descubrir quienes son los usuarios, que buscamos solucionar, analicemos las reglas de negocios, requisitos funcionales que tenemos, especifiquemos el requisito funcional que obtuvimos dentro una historia de usuario que tenga un para que potente y validemos con el usuario que lo que estamos haciendo tiene un valor
Esto fue todo hoy. ¡Espero que les haya gustado! ¡Saludos!