¡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.

Foto de bongkarn thanyakij en Pexels

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.

Foto de bongkarn thanyakij en Pexels

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”“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.

Foto de Ali Pazani en Pexels

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.

En esta ocasión te presento las razones por qué hablo de lo que hablo en este canal.

Visita mi web:
https://www.edgarfernandez.com
https://www.aprend-is.net

Aprende a estimar proyectos de software:
http://bit.ly/estimacionpromo

Videos mencionados:
Mi experiencia con Rambo: https://www.youtube.com/watch?v=qllc56_uR6c
¿Qué hace un Ing. de Software?: https://www.youtube.com/watch?v=uRiXseiYOUQ
¿Cómo quebré mi empresa? https://www.youtube.com/watch?v=LjZYZbVKJMQ

Música
De fondo: “Hard Boiled”, por Kevin MacLeod (https://incompetech.com)
Intro: Virus, por Dzynek

Watts S. Humphrey es el padre de la calidad del software. Él tenía un compromiso inquebrantable con la disciplina y la calidad. Emprendió una misión, con la que inspiró a muchos; entre ellos, a mí. Quiero hablarles de las razones por las que es mi role model profesional.

Mi curso en Udemy: http://bit.ly/estimacion

Contacto
Web: https://www.edgarfernandez.com
Facebook: https://www.facebook.com/SoftwareEngineeringCoach/
Twitter: https://twitter.com/edfrz1
LinkedIn: https://www.linkedin.com/in/edgarfernandezr/

Todo trabajo que se haga en un período de tiempo y que tenga un objetivo debe ser monitoreado regularmente, para asegurar que se camina en rumbo a ese objetivo y tomar decisiones para corregir desviaciones.
Entender el estatus de tu proyecto requiere que reunas información que te permita contestar estas seis preguntas.

Mi curso en Udemy: https://www.udemy.com/estimacion-de-proyectos-de-software-d…

Envíame un mensaje, y si eres de los primeros, gánate un cupón de descuento.

Varias personas me han pedido que les diga cómo crear una startup o empresa exitosa. He sido emprendedor, y mi empresa más grande quebró.

Quiero compartirte esa experiencia y los errores que nos condujeron al fracaso, esperando que puedas aprender de ellos, y lo que te recomendaría hicieras en lugar de lo que nosotros hicimos esa vez.

Recuerda suscribirte al canal para recibir las notificaciones cuando publicamos nuevos videos y compartirlo con quien creas necesite ver este video.

Visita mis redes:
Web: www.edgarfernandez.com
FB: https://www.facebook.com/SoftwareEngineeringCoach/
Twitter: https://twitter.com/edfrz1
LinkedIn: https://www.linkedin.com/in/edgarfernandezr/

Créditos de imágenes y recursos:
Photo by Tyler Nix on Unsplash (Cochera)
Photo by Hack Capital on Unsplash
Photo by Stefan Steinbauer on Unsplash
Photo by rawpixel on Unsplash
Photo by Tim Gouw on Unsplash
Photo by Ambreen Hasan on Unsplash
“Designed by kues1 / Freepik”

Quienes hemos tenido la oportunidad de liderar equipos de trabajo nos hemos encontrado, en ocasiones, a un personaje conflictivo. Hay varios tipos de ellos: el Rockstar, la Diva, el Inconforme, pero en este video trato de uno muy peculiar. Yo le llamo “Rambo”.

Sugerencias de Libros:
Willet, Alan. Leading the Unleadable: How to Manage Mavericks, Cynics, Divas, and Other Difficult People. Amacom, 2016
Patterson, Kerry. Crucial Conversations Tools for Talking When Stakes Are High. McGraw-Hill Education; Edición: 2nd ed. (9 de septiembre de 2011)

Visita mi sitio web para conocer mi experiencia: https://www.edgarfernandez.com
Sígueme en Facebook: https://facebook.com/SoftwareEngineeringCoach

Modelar el sistema pemite una mejor visualización de la situación que se quiere resolver y encontrar la solución más adecuada. Además de que nos evita problemas comunes en el desarrollo de software.

En este video te digo qué es System Testing, los tipos de pruebas de sistema y qué buscar en cada una.

Libros de consulta:

  • Lewis, William E. “Software Testing and Continuous Quality Improvement”. Third Edition. Taylor & Francis Groupi, 2009

  • The art of software testing / Glenford J. Myers, Corey Sandler, Tom Badgett. — 3rd ed.

Herramientas