Podcast: Play in new window | Download
Suscribirse: Apple Podcasts | RSS
¡Hola! Bienvenido a la serie “Cómo deleitar a tus usuarios”. En ésta hablaremos de Ingeniería de Requerimientos, un conjunto de actividades muy importantes, que nos permiten construir soluciones que deleitan a nuestros usuarios.
Esta es una serie de siete artículos. En éste primero te hablaré de qué son y en qué consisten las actividades de requerimientos, de su importancia y el propósito que tiene hacerlo.
En siguientes artículos, conocerás:
- Lost Tipos y niveles de requerimientos
- Cómo obtener y recolectar requerimientos
- Cómo analizar y comprender los requerimientos
- Cómo especificar requerimientos
- Cómo validar los requerimientos
- Cómo funciona el proceso de requerimientos en diferentes tipos de proyectos
¿Qué son los requerimientos?
Es una definición de lo que un sistema de software debe hacer, y una especificación de las restricciones en su operación e implementación.
Los requerimientos son la guía para comprender las necesidades de los usuarios con respecto al software y especifican las funciones que se deben de encontrar en el producto a desarrollar para satisfacerlas. Además, describen otros atributos que se encuentran en los sistemas, como el desempeño, la seguridad, la confiabilidad, la disponibilidad, entre otros.
En los requerimientos encontramos la información de quiénes son nuestros usuarios, sus intereses y sus prioridades. También, están descritas características del ambiente de operación, que nos ayudan a conocer la ubicación física de nuestros usuarios, y los otros sistemas de software y hardware que se estarán usando a la par que nuestro sistema, y con los que vamos a interactuar. En los requerimientos entendemos cómo son las actividades que vamos a apoyar con software, y cómo se deberían de hacer en un sistema de información. Además, encontraremos información acerca de restricciones tecnológicas que debemos considerar, como si los clientes tienen hardware que será usado obligatoriamente, o si existen limitaciones en presupuestos, que no permitan usar algunos dispositivos o tecnología. Por último, decisiones de tecnología que será usada en la construcción del software.
Actividades de requerimientos
- Elicitar: Tareas orientadas a recolectar información de los usuarios
- Analizar: Tareas orientadas al entendimiento de las necesidades de los usuarios y sus posibles soluciones
- Especificar: Tareas orientadas a establecer de forma clara, concisa, no ambigua y completa cuáles son las necesidades a resolver y las funciones que deben estar presentes en la solución
- Validar: Tareas cuyo propósito en aprobar o descartar las propuestas de solución.
Importancia de los requerimientos
Como ingenieros de software, nuestra labor es crear soluciones tecnológicas que entregan valor a los usuarios, y el valor siempre va ser conseguido cuando tenemos el Producto Correcto. La importancia de los requerimientos reside en que son la base para el éxito o fracaso del producto de software que se construye.
De acuerdo al Standish Group, una de las principales razones por las que fracasa un proyecto de software se debe a un proceso deficiente en los requerimientos. Principalmente por una especificación deficiente y un manejo inadecuado de los cambios (se evitan en lugar de añadirse, o se incluyen torpemente y generan problemas de calendario o calidad).
Es, pues, la capacidad de entender las necesidades de los diferentes stakeholders, alinear sus prioridades contrarias y encontrar las funciones que entregan el valor percibido y real para todos ellos. Sin esta capacidad, los equipos suelen encontrar dificultades para entregar soluciones adecuadas, y tardan mucho en darse cuenta de que propusieron y construyeron la solución incorrecta.
Propósito de las actividades de requerimientos
Nuestro trabajo de requerimientos debe incluir y empezar con La Empatía
Probablemente te resulta conocida la siguiente escena:
- Project Manager: Ya han pasado varias semanas y todavía no podemos iniciar la construcción del proyecto, y hace más de dos semanas que no vas a visitar al cliente
- Analista: Es que no tiene caso, porque siempre que voy acabo frustrado porque no me dice qué es lo que quiere. Es que el cliente no sabe ni lo que quiere
“El cliente no sabe qué quiere” y sus variantes son una creencia común entre muchos desarrolladores de software. A ellos les digo que si el usuario supiera qué quiere, no nos necesitaría ni nos contrataría, y lo haría por su cuenta. También les digo que es la falta de empatía la que nos hace creer eso, me declaro culpable de haberlo hecho antes.
El desarrollo de software no debe comenzar con un “¿Qué es lo que quieres que hagamos?”, sino con algo como “Cuéntame, cómo estás hoy”. Ponernos en los zapatos de los usuarios, de los dueños de los negocios, de las personas que día con día trabajan, tienen objetivos e ideales y encuentran dificultades para alcanzarlas. El de método Design Thinking comienza allí, en la empatía: un proceso para descubrir una necesidad con base en el entendimiento del usuario, en su entorno y situación actual, para llevarlo a una situación ideal.
Desarrollamos soluciones de tecnología para Personas. No lo olvidemos. Con eso en mente, podemos entender a quién estamos beneficiando con nuestro trabajo y cuál es el impacto que generamos en ellos con nuestras decisiones, buenas y malas.
Como gremio, los de software somos muy proclives a proponer e imponer soluciones a problemas que no hemos entendido. ¡Alto! Antes de proponer la gran solución tecnológica que nos viene a la mente, debemos tener claro cuál es el problema a solucionar y quién tiene ese problema. Estas personas, tus stakeholders, serán las fuentes para entender la situación, recolectar información, resolver tus dudas y validar las propuestas de solución.
Guía para la solución
Con base en el entendimiento de la situación del usuario y sus objetivos, se proponen las alternativas de solución y se definen las funciones del software, convirtiendo los requerimientos en una guía para el desarrollo. Esto es, guiar al equipo para que sepa cuál es el producto que se debe construir. Sin embargo, nuestra labor también consiste en proteger al cliente de sí mismo.
Verás. En ocasiones el cliente quiere adelantarse al ingeniero y pide cosas que no necesita. Esto se origina cuando un usuario recibe información que lo hace ver fuegos artificiales y despiertan su imaginación, o cuando se ha familiarizado al lenguaje técnico viendo su producto y comienza a solicitar cosas. “Es que mi amigo me habló de unas soluciones espectaculares en la nube, y ahora quiero una nube” o “Ya sé, hagamos una introducción animada de la interfaz gráfica cada vez que se abre la pantalla para que sea más divertida”. En el desarrollo de los requerimientos debemos de trabajar con el cliente para enfocarnos en el VALOR, y en hacerle ver el impacto de las restricciones que se tienen: Quizás la tecnología que quiere es muy cara y excede el presupuesto, o las funciones que pide consumen mucho tiempo, que posterga el desarrollo de otras con más valor.
También debe guiarnos como equipo de desarrollo, para establecernos límites. Recordemos que muchos somos como el chavo del ocho.
Podemos decir, con toda seguridad, que la ingeniería de requerimientos es el arte de quitar, en vez de poner.
Conclusión
Como puedes ver, las actividades de requerimientos tienen más que ver con la empatía que con la especificación técnica. Claro está, la segunda es importante y debe hacerse, pero nuestra primera labor es trabajar para descubrir y entender una necesidad real de nuestros clientes, a través de interacciones que nos permitirán encontrar qué es lo que les dará mayor beneficio y tendrá mayor impacto en ellos. Recuerda siempre la empatía en el trabajo de requerimientos, para estar en el lugar de tus usuarios, ver las cosas desde su perspectiva y entender qué solución les ayudará mejor; también recuerda que los requerimientos, mientras más breves y concisos, darán más valor. Calidad en lugar de cantidad.
