Existen dos frases, que he escuchado decir a muchos Líderes de equipo y Gerentes, quizás las has escuchado también:

- "Quiero un equipo con la camiseta bien puesta"

- "Todos los miembros del equipo deben ser más comprometidos"

Son una arenga, que busca motivar al equipo para que obtenga resultados extraordinarios o sea capaz de solucionar problemas activa y rápidamente. A veces, cuando existe la urgencia de liberar una función o un fix, la escucho en esta forma: "comprométete más con la empresa".

Sin embargo, solemos ver un efecto opuesto al que buscan estas frases: un equipo desmoralizado y resultados alejados de las expectativas de los líderes. Los miembros del equipo están comprometidos; dice Watts Humphrey: "todos los participantes quieren hacer un gran trabajo y dar lo mejor de sí, siempre", y es verdad; no conozco un solo desarrollador de software que se levante en las mañanas pensando "hoy haré el peor trabajo que pueda"; es solo que, en su estado actual, tiene poco margen para participar.

A lo largo de mi carrera profesional he escuchado lo siguiente en diferentes ámbitos:

“Es normal que el software tenga defectos” o su variante “El software siempre tendrá defectos”

No es normal.

Ustedes no andarían por un puente vehicular, del que saben que tiene defectos. No aceptarían un coche defectuoso o aceptarían una casa con múltiples defectos. Sin embargo, como decía mi profesor Carlos Montes de Oca “el software es tan necesario que le perdonamos que sea malo”.

Se vuelve el cuento de nunca acabar. En general, las organizaciones con este problema dedican entre 65% y 85% del tiempo solo a esta actividad en lugar de producir funciones nuevas, o dedican equipos completos solamente a esto. Algunas organizaciones, con algo de cinismo, la incluyen en los contratos como “fase de estabilización”, que solo es trasladarle el costo al cliente por la mala calidad del desarrollo.

A continuación te presento razones por las que se presenta este comportamiento en organizaciones de software.

No hay cultura de la calidad

Cuando pregunto “¿Quién es responsable de la calidad del software en la organizacion?” suelen responder:

El equipo de QA

La fase de Testing

Es decir, asumen que la calidad es “algo que sucede en un momento del tiempo” o es una actividad concreta, en lugar de ser un trabajo continuo.

Esto genera una forma de trabajo donde la responsabilidad se diluye. El equipo de desarrollo espera que QA sea quienes encuentren los defectos, y QA espera que desarrollo esté atento a los ciclos de pruebas para reparar cuanto antes. Además, genera conflicto y fricción, sobre todo si ambos grupos solo se involucran en su fase y no colaboran en el resto del ciclo.

Presiones para entregar a Testing rápido

Esto es consecuencia de la pobre cultura de la calidad. Project Managers, Gerentes y Líderes saben, por la experiencia anterior, que la fase con más costo será testing. Por lo tanto, concluyen que una forma de acortarla es iniciarla rápidamente. Presionan para entregar y empezar a probar, en lugar de promover que se aseguren de que lo que entregan aprobará las pruebas rápidamente. El resultado siempre es el opuesto al que esperan: mientras más defectos encuentran, más defectos hay por arreglar.

Watts Humphrey lo dice en su libro “A discipline for software engineering”: “Al llegar a testing, la calidad ya se encuentra dentro del producto”. William Lewis lo remata así: “No se puede agregar calidad a un producto ya terminado”

Imagen: pch.vector para Freepiki

La forma de trabajo es inadecuada

En el punto anterior menciono: mientras más defectos encuentran en testing, más defectos hay por arreglar. Si la forma de trabajo usada para arreglar los bugs es la misma que se usó para crear el código la primera vez, la consecuencia es que inserte más defectos. Puedes observar cosas como:

El equipo de desarrollo quiere regresar el código a QA lo más rápido posible (como la primera vez), y no verifica exhaustivamente que ya no hay defectos.

Los equipos no comparten información, que puede ayudar a prevenir defectos. Un caso común es que un equipo no comparte cuáles son las ideas de prueba que tiene, o qué cosas le gustaría probar.

Cualquier actividad de aseguramiento de calidad como peer review, inspecciones, walkthroughs, etc. es suprimida porque se ve como pérdida de tiempo y lo que urge es entregar a QA.

Deuda técnica

Productos y sistemas que están en desarrollo constante (mejoras y mantenimiento) suelen presentar el problema de la deuda técnica, la cual “se cobra” con el tiempo en forma de fallas y defectos. La deuda técnica es una implementación inadecuada, que se hizo apresuradamente para resolver algo en un momento, pero nunca se reemplazó por la solución correcta. Esto, a la larga, va manifestándose con problemas que son costosos para los equipos, en términos de tiempo.

Aunado a esto, los sistemas están pobre o nulamente documentados. Cuando un ingeniero quiere arreglar un problem...

En las cinco red flags de las organizaciones de software, que les detiene para lograr resultados de élite, tenemos el tiempo de desarrollo muy largo; esto es, la incapacidad del equipo para entregar software funcionando en intervalos cortos, regulares y frecuentes.

Algunas empresas se distinguen por su innovación, la cual notamos porque brindan funciones nuevas en sus productos constantemente. Hablamos de compañías como Amazon, Netflix o Facebook (ahora, Meta), quienes crearon una forma de trabajo capaz de hacer varios deploys al día, completamente funcionales. Amazon lo hace a una tasa de 30,000 al día; Netflix, 500 y Facebook 2 veces diariamente.

¿La tuya es capaz de hacer esto? Tal vez te encuentras en la circunstancia normal de muchas organizaciones: solo hacen una o dos entregas (deploys funcionales) AL AÑO. ¿Cuáles son las razones de esto? Te presento las más importantes.

Pasan muchos días entre el fin de un ciclo (sprint) y el inicio del siguiente

Los frameworks de la filosofía ágil, basados en ciclos, son muy populares. Estos recomiendan dividir el trabajo en ciclos cortos (sprints), en los que se produce un MVP listo para ser utilizado. La idea es que, después de cerrar uno, inmediatamente comenzar el siguiente, incorporando las nuevas User Stories y la retroalimentación del anterior.

Muchos equipos dejan pasar días, o semanas, entre el fin de un ciclo y el inicio del siguiente. Las causas suelen ser:

Realmente no entregaron un MVP sino un producto a testing; el equipo de QA ha regresado la entrega con muchos reportes de defectos para reparar.

No hay autonomía en el equipo para tomar decisiones. Si el responsable de autorizar o dar visto bueno a la planificación está ausente, el trabajo se detiene.

Proceso burocrático. Se requieren muchos pasos para lograr el visto bueno de inicio; por ejemplo, que los requerimientos sean definidos, priorizados y aprobados por varias personas.

Tiempos muertos entre silos funcionales

Si tu equipo está organizado en grupos especialistas (analistas, desarrolladores, testers, etc.), verás que las personas tienen picos de ocupación y desocupación. Esto es porque el trabajo está avanzando linealmente, pero necesita de que todo esté terminado para poder pasar al siguiente grupo; éste tiene que esperar, hacer su parte y enviarla al siguiente, que también está a la expectativa.

Mientras están desocupados, quizás están haciendo otras labores (capacitarse, arreglar defectos, entre otros), pero el progreso del sprint no está avanzando más rápidamente.

Burnout

Imagen: Macrovector para Freepik

Un equipo cansado es improductivo. Algunos señalan que una noche sin dormir (o poco sueño) reduce la efectividad de un Ingeniero en 20%; dos consecutivas la reducen 80%.

La creencia de que trabajar más horas hará que el resultado sea más rápido es contraproducente. Muchos Project Managers y Gerentes insistirán en prolongar las jornadas de trabajo para acelerar el desarrollo, pero con esto solamente lograrán que el equipo se queme. En esta circunstancia, por más horas que acumulen, no podrán producir un buen resultado y la cantidad de defectos y problemas crecerá exponencialmente. 

Pobres técnicas de ingeniería para validar la solución

A lo largo de mi carrera, he observado que una limitante para las entregas continuas es la carencia de técnicas ingenieriles:

Los desarrolladores no saben cómo probar un módulo si otro, u otros, no están terminados. Por esto, deciden usar un enfoque en Cascada para completar todas las partes y poder probar.

El equipo no sabe cómo automatizar las pruebas. Los procesos son manuales y replicar una prueba toma mucho tiempo, sobre todo si falla.

El proceso de instalación de cualquier cambio, actualización o ambiente es completamente manual. Literalmente, copian y pegan archivos de una computadora a otra en lugar de tener scripts o software que haga el deploy por ellos.

Una organización de software es una persona o grupo, que tiene como fin crear y entregar soluciones basadas en software, las cuales deleitan a sus usuarios y dan valor financiero a los patrocinadores de su desarrollo. Estas organizaciones pueden ser vendedoras del servicio de software a clientes finales o estar dentro de otra empresa, creando el software que se usa en las operaciones diarias.

Mientras más rápido consigan la entrega, más rápido se obtienen también los beneficios e inician más oportunidades de desarrollo. Es lo que, hoy en día, se llama Agilidad y es un resultado que todas las organizaciones deben procurar.

Sin embargo, muchas de ellas descuidan factores importantes, que les impiden obtener los mejores resultados. Estas carencias se observan en sus prácticas de Ingeniería de Software. A continuación te presento cinco red flags en los grupos de desarrollo de software y las razones por las que detienen al equipo para lograr los resultados de elite:

El tiempo de desarrollo es muy largo

La mayor parte del tiempo se dedica a apagar fuegos y arreglar defectos

Moral de equipo baja

Pérdida de oportunidades para aprovechar tendencias tecnológicas y crear nuevos productos, servicios y negocios

No pueden crecer

El tiempo de desarrollo es muy largo

Un requerimiento solamente aporta valor a los usuarios si éste se encuentra en sus manos, implementado sin defectos, y listo para ser utilizado. Guardado en el backlog o en la lista de requerimientos no les es útil, por lo tanto, debe pasar poco tiempo entre la espera y la entrega. Ese poco tiempo es un día o unos pocos días.

Los equipos que tienen esta red flag tardan meses entre una entrega y la siguiente, porque el proceso de desarrollo establece esta forma de trabajo o bien porque hay un período largo de inactividad entre el fin de un ciclo de desarrollo y el inicio del siguiente.

Los gerentes y directores suelen presionar en este aspecto; aunque la presión aumenta, la práctica y el resultado siguen iguales: el tiempo de entrega es de meses. Peor aún, cuando las jornadas de trabajo se extienden, tratando de acortar el calendario de entregas, y frecuentemente se pierden fines de semana o se trabaja desde la mañana hasta la madrugada.

La mayor parte del tiempo se dedica a apagar fuegos y arreglar defectos

El valor que entrega el software solamente puede aumentar si agregamos funciones nuevas o mejoramos mucho las existentes. No hay valor si una función falla o los defectos hacen imposible el uso del software. Las organizaciones deberían pasar la mayor parte del tiempo implementado nuevas funciones y mejoras.

Los equipos que tienen esta red flag dedican entre el 65% y el 85% de su tiempo arreglando defectos y apagando fuegos (problemas causados por la operación del software). Terminan con una crisis y al poco tiempo están atendiendo otra, o varias a la vez. Los problemas parecen inacabables porque los equipos utilizan las mismas prácticas para arreglar los defectos, que fueron las que los pusieron en el software en primer lugar. El ciclo es interminable por esta razón.

Moral del equipo baja

Los grandes resultados son obtenidos por equipos cohesivos y altamente motivados. Las organizaciones que tienen esta red flag cuentan con individuos desmotivados y la moral baja; esto puede observarse porque los miembros de equipo solo se limitan a cumplir con las funciones que les encomendaron en su puesto y no se involucran en otras actividades, opinan poco o nada y no comparten información relevante, sobre todo cuando puede prevenir problemas.  Los directores y gerentes llaman a esto "falta de compromiso", ¿te suena?

Cuando los problemas ocurren, inevitablemente, todos intentarán culpar a otros y no asumir la responsabilidad por el resultado completo, pues ellos habrán cumplido con lo que les correspondía, pero no asumirán nada más.

Imagen: jcomp para freepik

Pérdida de oportunidades para aprovechar tendencias tecnológicas y crear nuevos producto...

Muchas veces ocurre que no comprendimos bien los requerimientos de un sistema y ponemos el producto incorrecto en las manos del cliente. Esto, si ya ha pasado mucho tiempo y se ha consumido mucho del presupuesto, puede causar daños irreparables para el cliente, hasta la quiebra de la compañía.

Entender mal los requerimientos es algo completamente normal y a todos nos va a pasar. Lo importante es que nos demos cuenta lo más pronto posible, cuando es fácil y barato corregir.

La validación de requerimientos es el medio que nos permite asegurar el entendimiento de lo que se va a hacer. Depende de lo que quieres validar es la técnica que puedes usar.

Soy Edgar Fernández, hablemos de la validación de requerimientos.

¿Qué es la validación de los requerimientos?

Validar los requerimientos es un paso crucial. Va más allá de leer los documentos, aprobar y recolectar firmas. Aunque esto es necesario a veces, no es lo más importante. 

Validar correctamente los requerimientos es lo que permitirá que el equipo se enfoque en producir y entregar valor frecuentemente. Es el paso en el que encontramos lo valioso y nos deshacemos de lo innecesario.

Hay varias formas de validar un requerimiento. Antes de conocerlas, primero veamos cuáles son las características de un requerimiento excelente.

Características de un requerimiento excelente 

Correcto: el requerimiento provee una función o capacidad que es acorde con una necesidad de los stakeholders. La función está descrita con claridad.

Factible: es posible implementar el requerimiento dentro de las capacidades y limitaciones del sistema y el proyecto. Por ejemplo, tenemos y conocemos el framework de desarrollo para hacerlo y contamos con el tiempo y el presupuesto necesarios.

Necesario: el requerimiento ofrece a los stakeholders el valor de negocio esperado, diferencia el producto de software de otros en el mercado, o es necesario para adecuarse a una regulación externa. En nuestra metodología DINO, estos son los requerimientos Obligatorios.

No ambiguo: primeramente, la definición del requerimiento debe ser comprensible; quien lo lee debe ser capaz de comprender lo que fue definido. Después, el requerimiento debe ser interpretado de la misma manera por dos o más personas.

Verificable: el requerimiento es verificable si podemos definir formas de probarlo. 

Consistente: los requerimientos deben ser atómicos y no entrar en conflicto con otros o contradecirse. Un ejemplo de contradicción es que el sistema de permisos autorice a usuarios a hacer cosas que no están en su tabla de acceso.

Completo: la especificación tiene el detalle suficiente para permitirle al equipo entender lo que se debe desarrollar. 

Ahora que conocemos las características de los requerimientos excelentes, veamos cómo se validan los requerimientos en sus diferentes niveles. 

Validación de requerimientos de negocio

Para validar los requerimientos de negocio, debemos asegurar que estamos alineados con los objetivos del negocio y que la solución propuesta nos conduce a ello.

Podemos validar estos requerimientos en dos momentos:

Al inicio del proyecto, con una prueba de concepto. Esta puede realizarse con un prototipo no funcional, que simula la aplicación final y la mostramos a los usuarios. Los prototipos no funcionales son hechos con tecnología y componentes que no serán parte del producto final, como un prototipo en papel, una presentación interactiva de diapositivas o un andamio rápido como los que hace Ruby on Rails.

Al comenzar el desarrollo, con un MVP. Esperamos que el equipo construya una primera versión del producto completo, con la que se validará la idea de negocio.

En la validación de requerimientos de negocio, aseguramos dos cosas más:

Los criterios de éxito están definidos en términos del negocio y sus objetivos, lo cual nos permitirá medir los parámetros que usaremos para nuestros prototipos.

Los perfiles de los stakeholders están completos. Así,

Hablemos de la Especificación de Requerimientos

Es imposible que el equipo de desarrollo memorice toda la información del producto. A lo largo del proyecto, los miembros del equipo tendrán preguntas, habrá suposiciones y ocurrirán otras situaciones que causarán que haya un entendimiento diferente de lo que debe y no debe hacer el software. No resolver rápidamente las dudas o que haya esa comprensión dispar de los requerimientos nos conducirá a retrabajo, retrasos y descontento entre los stakeholders.

Además, para sistemas ya construidos, es importante que exista información que permita entender cómo y por qué se tomaron las decisiones y qué implica hacerle cambios.

Por eso debemos especificar los requerimientos. Esto significa documentar los acuerdos sobre lo que debe hacer el software y las restricciones existentes.

Ahora, una de las mayores dificultades que enfrentan los equipos de software es saber lo que sí se debe especificar. La información importante que siempre debes registrar en tus especificaciones es la que te permita responder las siguientes preguntas:

¿Qué se va a resolver y por qué es importante hacerlo?

¿En quiénes estamos teniendo impacto?

¿Qué es lo que quieren hacer los usuarios con el software?

¿Qué funciones tendrá el software?

¿Cuál es el ambiente en que estará operando el software?

¿Cómo se usarán las interfaces con otro software y hardware?

¿Hay alguna restricción con la tecnología?

¿Cómo evaluaremos el cumplimiento de los requerimientos no funcionales?

¿A cuáles estándares nos debemos apegar?

¿Qué se va a resolver y por qué es importante hacerlo?

Los requerimientos de negocio, que están en lo más alto de los niveles, marcan la dirección del proyecto, los objetivos que persigue el usuario u organización y una visión de cómo el producto ayudará a alcanzarlos.

Para que los involucrados siempre tengan presente por qué es importante hacer este proyecto, haz un resumen ejecutivo con lo siguiente:

El estado actual y la problemática que se enfrenta.

El estado deseado, expresado en objetivos SMART y criterios de éxito

El enunciado que describe la visión del software

Las funciones principales que ejecutará

Los riesgos del proyecto

Recuerda que esta especificación hablará en el lenguaje del negocio, por lo que debes evitar incluir muchos conceptos técnicos y ser muy concreto en la descripción de la visión.

Por ejemplo, tu especificación de la visión y sus funciones principales puede ser: "Un sistema distribuido en web y dispositivos móviles que permitirá registrar clientes, crear rutas de reparto, notificar los cambios de estado de los pedidos y administrar el almacén". La descripción detallada de cómo se hará cada función se hará, pero es parte de otras especificaciones.

¿En quiénes estamos teniendo impacto?

Todas las decisiones que se toman para el producto tienen un impacto en y reciben influencia de la comunidad de Stakeholders. Debemos establecer un acuerdo de quiénes son y cuál es su rol en la comunidad. En esta especificación, deberás definir:

Quiénes son los usuarios directos

Quiénes son los patrocinadores del proyecto

Quiénes son usuarios indirectos

Quiénes definen reglamentos, estándares y leyes

Los patrocinadores suelen tener el poder de aceptar o rechazar el proyecto, así que establecen los objetivos del mismo. Los usuarios directos utilizarán las funciones del software. Los usuarios indirectos reciben un beneficio aunque no usen el producto (por ejemplo, para una aplicación de GPS, los restaurantes se benefician de que los conductores puedan llegar a sus locales mediante el mapa y el gps). Los definidores de reglas establecen lineamientos a los que el software debe apegarse (como el Gobierno).

El Stakeholder especificado será el nombre del rol, no debes poner el nombre de cada persona. Como "Director", "Gerente", "Empleado", etc. Puedes agregar información adicional, como los intereses principales,

La información que obtienes durante el levantamiento de requerimientos es un conjunto de datos muy grande, que en su estado natural es poco útil. Debemos analizarla para entender cuatro cosas respecto a nuestro sistema:

— El contexto en el que se desempeña

— La información que pertenece al dominio del sistema

— Cómo y dónde se procesa la información

— El comportamiento que debe tener el sistema ante diferentes estímulos

¡Acompáñame para conocer en qué consiste el Análisis de los requerimientos!

Contexto

Las aplicaciones de software no realizan su trabajo de forma aislada. Estos interactúan con diferentes actores que se encuentran dentro de un sistema complejo, tales como otras aplicaciones, hardware y dispositivos, redes y ubicaciones remotas. A esto le llamamos El Contexto del sistema, y en él encontraremos información importante para definir nuestros requerimientos no funcionales.

Cosas que debes buscar para definir el contexto:

Otras aplicaciones y software que se está usando. Los usuarios pueden mencionar estos otros programas o descubrirlos en los manuales o documentos que te faciliten. Debes registrar cuantas instancias hay y si se encuentran en varias versiones.

Ubicaciones remotas. ¿Dónde se encuentran geográficamente los usuarios o los otros sistemas que interactúan? En esto, debes prestar atención para entender cómo se comunican, si existe una infraestructura de red de telecomunicación actualmente o será necesario desarrollar una. Debes comprender cómo es el acceso a cada lugar, geográficamente, para entender cómo será la comunicación con estos puntos remotos y no suponer ni asumir que la infraestructura de internet funcionará igual en todas partes.

Hardware y dispositivos. ¿Qué hardware especializado se usa e interactuará con nuestro software? ¿Qué dispositivos emplearán tus usuarios para acceder al sistema? ¿En qué versiones se encuentran? ¿Cuál es la variedad de dispositivos, sistemas operativos y capacidades que tienen? ¿Cuántos son y quiénes los usan? ¿Cuál es la posibilidad de cambiarlos por otros? Esta información te permitirá entender, más adelante, cuáles son las decisiones de tecnología que deberás tomar. Ten en cuenta que tu sistema deberá ser adecuado para el contexto y no obligar a los usuarios a que se adapten al sistema. 

Entender el contexto es muy importante y no se debe dar por hecho. Dale un tiempo a tus actividades de análisis para definirlo.

Dominio de la información

Los conceptos de información son entendidos de diferente forma en los distintos dominios. Piensa por ejemplo en un "Cliente"; en el contexto de los negocios, es alguien que consume productos y servicios, del cual nos interesa conocer su nombre, datos demográficos y otros atributos; pero en el dominio la informática, un "Cliente" es un dispositivo o programa que se comunica con un servidor para consultar información o ejecutar funciones de hardware; de este cliente, nos interesa conocer su origen, dirección, capacidad, permisos, entre otros atributos.

Así pues, debemos definir las entidades de información que se usarán en nuestro software y las relaciones entre ellas; debemos hacer esto de acuerdo al dominio en el que están nuestros usuarios.

El análisis del dominio es un diccionario de datos, que nos permite entender qué significa cada concepto o sustantivo que se usa en el dominio. No es un diccionario para una base de datos todavía, sino una descripción de alto nivel que nos permite entender qué significa, para un usuario, un concepto que él utiliza con frecuencia y cómo se relaciona con otros conceptos. Esto te permitirá encontrar los procesos en los que se origina y transforma cada parte de la información.

Por ejemplo, piensa nuevamente en el Cliente y en una Factura. Ambos estarán definidos por un conjunto de datos que les pertenecen y que esperaremos encontrar en el software. Ahora, ¿cómo se relacionan ambos conceptos? Una factura es creada cuando un cliente completa una compra,

Los ingenieros de software solemos cometer el error de esperar que los usuarios nos den sus requerimientos; ellos nunca lo podrán hacer, porque no están entrenados en desarrollo de software, pero insistimos en hacer preguntas como "¿Qué es lo que quieres?", "¿Usamos tal herramienta o tal otra?", "¿Será en plataforma móvil, web o de escritorio?", "¿Lo quieres responsivo?". 

Ya que estamos en eso, también debemos dejar de enojarnos cuando nos dicen cosas como "quiero que sea bonito y rápido".

La brecha que existe entre el vocabulario y entendimiento entre usuarios y desarrolladores debe achicarse, en vez de agrandarse. Los usuarios nos hablarán con su vocabulario habitual, en el contexto que conocen; nuestra labor es entender eso para transformarlo en los requerimientos que guiarán la construcción de un gran software. El primer paso es recolectar la información.

Identificar el problema

Descubrir las necesidades de los involucrados en el software es un reto. Es un proceso analítico y colaborativo con actividades para encontrar y definir las necesidades.

Los usuarios no pueden definir con precisión técnica cuál es el software que necesitan, por lo tanto, es labor de los ingenieros conseguir lo siguiente:

Tener un ambiente adecuado para facilitar la exploración y comunicación

Entender las actividades de los usuarios. 

¿Qué actividades quiere completar el usuario y cómo podemos ayudar?

¿Cuáles son las aspiraciones del usuario y cómo podemos ayudar a que las alcance?

¿Qué relación esperan que establezcamos con ellos?

¿Cuál es el valor que realmente esperan recibir?

Entender cómo toman decisiones

Entender lo que consideran innecesario, obsoleto o ineficiente.

Para esto, debemos trabajar primero en recolectar la información y resistir la tentación de diseñar el software hasta que has entendido el problema. En este proceso, seleccionamos de entre un conjunto de técnicas las que mejor se adapten a nuestro proyecto y a nuestros usuarios.

Técnicas para recolectar información

Antes de comenzar con cualquier intento de proponer una solución de software, debemos reunir la información suficiente para conocer, cuando menos, el contexto y las características principales de nuestros usuarios y su entorno. Este proceso puede durar unas pocas semanas, y en ellas recolectamos información.

Existen múltiples técnicas para descubrir las necesidades de usuarios de software

Colaborativas: Interacción con los usuarios

Independientes: Descubres información por tu cuenta

Algunas de las técnicas son:

Entrevistas

Talleres

Focus groups

Observación estructurada del entorno

Encuestas

Análisis de documentos

Evaluación heurística 

No uses solamente una, diferentes usuarios preferirán alternativas distintas

Detallemos cada una

Entrevistas

Las entrevistas son actividades colaborativas. El propósito es reunirte directamente con los usuarios, ya sea individualmente o en grupos pequeños, para preguntarles directamente y conocer su información.

Las entrevistas tienen un objetivo y propósito definidos, que se plasma en un cuestionario o una guía, y una duración, establecida en una agenda.

En el proceso de la entrevista debes presentarte, revisar la agenda con los asistentes, presentar los objetivos y resolver las preguntas iniciales. Tu objetivo es escuchar, así que hazlo activamente. Haz la pregunta y deja que los asistentes sean quienes hablen; solamente debes intervenir para aclarar algo o mantener el enfoque de la entrevista.

Esta técnica es útil cuando has identificado a los usuarios más representativos de un grupo y estos tienen poco tiempo para reunirse. Así que aprovecha todo el tiempo con ellos y prepara una buena lista de preguntas.

Talleres

Son reuniones formales y estructuradas, en las que un grupo de personas y expertos trabajan juntos. En esta colaboración, se usan diferentes herramientas para crear un modelo de la situación actual e identificar las nece...

Hay tres cosas que debes entender para tener buenas prácticas en tus requerimientos:

Qué son los Stakeholders

Los niveles de requerimientos

Los tipos de requerimientos

Comprender bien esto, te permitirá responder fácilmente a la pregunta: ¿Cuáles son las siguientes user stories a desarrollar? 

Identifica a tus Stakeholders

Un sistema de software impacta a diferentes personas y grupos. Entre esos individuos están tus usuarios, pero no son los únicos a los que debes considerar.

A toda la comunidad de interesados o impactados por el sistema le llamamos Stakeholders y representan la voz de las diferentes necesidades que se deben satisfacer con el software.

Entre tus stakeholders puedes encontrar:

Patrocinadores del proyecto: quienes aportan los recursos para realizar el proyecto, o apoyan con entusiasmo su realización; contribuyen en la gestión de recursos

Usuarios directos: individuos que utilizarán las funciones del software con frecuencia, para completar sus tareas habituales. En esta categoría encontramos también otros dispositivos o sistemas, que están empleando nuestro producto con frecuencia.

Usuarios indirectos: individuos, organizaciones y otros sistemas que reciben un beneficio con el uso de nuestro producto. Por ejemplo, para una aplicación de mapas y GPS, un usuario indirecto es un negocio, que recibe el beneficio de que la aplicación lleve a personas a su local. En esta categoría también encontramos a quienes se benefician con al información producida por nuestro producto, ya sea que la puedan consultar periódicamente o que acceden a ella de alguna forma.

Definidores de reglas de negocio: Individuos y entidades que establecen reglas, a los cuales el sistema se debe ajustar. Estos stakeholders podrían no utilizar el sistema, pero influyen en su comportamiento. Incluso, pueden ser externos, como instituciones de gobierno, reguladores u otras organizaciones.

Photo by Kaboompics .com from Pexels

Todos los usuarios y stakeholders consideran que sus necesidades y requerimientos son prioritarios e importantes, que todos deben ser incluidos en la solución final. Sin embargo, no es así: hay formas de encontrar los requerimientos que son importantes y prioritarios.

Para ello, te enseñaré el método DI NO

Tipos de requerimientos

DINO son las siglas de los tipos de requerimientos. Cada vez que encontramos uno debemos clasificarlo según lo siguiente:

Deseables: Requerimientos estéticos, agregan alguna conveniencia en la usabilidad o en el ahorro de pasos. También los conocemos como “nice to have” y son los que se anotan para hacerse si tenemos el tiempo para hacerlos

Importantes: Son requerimientos de gran valor, pero pueden esperar. Los requerimientos importantes se convierten en obligatorios con el tiempo, pero en el momento de registrarlos por primera vez son los que se negocian por otros prioritarios.

No implementables: Requerimientos deseables por algunos usuarios, pero agregan poco valor con un alto costo de desarrollo. Estos requerimientos suelen ser para muy pocos usuarios, o uno o dos son los que perciben el valor, pero la mayoría no. Suelen estar fuera de la línea de los objetivos del producto.

Obligatorios: Los requerimientos que le dan sentido al producto. Sin ellos, el producto no tiene razón de ser o se vuelve inútil. Estos requerimientos aportan el máximo valor, aún cuando su implementación tenga un alcance inicialmente pequeño.

Photo by cottonbro from Pexels

Como un ejemplo:

Un requerimiento obligatorio es que puedas guardar y editar la información de los clientes. Importante que puedas guardar y editar varios registros a la vez, en lugar de hacerlo uno por uno. Deseable, el poder editar en línea los registros (sin presionar el botón editar) y No implementable el que haya una animación con sonido cada vez que guardas un registro.

Pero, te estarás preguntado, ¿cómo sé cuáles serán los obligatorios y cuáles los demás?

¡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 requerimientosCómo obtener y recolectar requerimientosCómo analizar y comprender los requerimientosCómo especificar requerimientosCómo validar los requerimientosCó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 usuariosAnalizar: Tareas orientadas al entendimiento de las necesidades de los usuarios y sus posibles solucionesEspecificar: 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ónValidar: 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 tod...