Cinco errores comunes en el análisis de requisitos (y cómo evitarlos)

En el modelo tradicional de desarrollo de software, la fase inicial de análisis de requisitos es también la más importante. Esta es la fase que involucra la recopilación de información sobre las necesidades del cliente y la definición, en los términos más claros posibles, del problema que se espera que el producto resuelva.

Esta análisis incluye comprender el contexto y las limitaciones del negocio del cliente, las funciones que el producto debe realizar, los niveles de rendimiento a los que debe adherirse y los sistemas externos con los que debe ser compatible. Las técnicas utilizadas para obtener esta comprensión incluyen entrevistas con el cliente, casos de uso y listas de características del software. Los resultados del análisis se capturan típicamente en una especificación formal de requisitos, que sirve como entrada para el siguiente paso.

Bueno, al menos eso es cómo se supone que funciona en teoría. En realidad, hay varios problemas con este modelo teórico, y estos pueden causar retrasos y errores en el resto del proceso. Este artículo analiza algunos de los problemas más comunes que los gerentes de proyecto experimentan durante esta fase y sugiere posibles soluciones.

Problema 1: Los clientes no saben realmente lo que quieren

Posiblemente el problema más común en la fase de análisis de requisitos es que los clientes solo tienen una idea vaga de lo que necesitan, y depende de ti hacer las preguntas correctas y realizar el análisis necesario para convertir esta visión amorfa en una especificación formal de requisitos de software documentada que a su vez se pueda utilizar como base tanto para un plan de proyecto como para una arquitectura de ingeniería.

Para resolver este problema, debes:

• Asegurarte de pasar suficiente tiempo al comienzo del proyecto para comprender los objetivos, los entregables y el alcance del proyecto.
• Hacer visibles todas las suposiciones que el cliente esté utilizando y evaluar críticamente tanto los beneficios probables para el usuario final como los riesgos del proyecto.
• Intentar escribir una declaración de visión concreta para el proyecto, que abarque tanto las funciones específicas o los beneficios para el usuario que proporciona como el problema empresarial general que se espera que resuelva.
• Hacer que tu cliente lea, piense y apruebe la especificación completa de requisitos de software, para alinear las expectativas y asegurarse de que ambas partes tengan una comprensión clara del entregable.

Problema 2: Los requisitos cambian durante el curso del proyecto

El segundo problema más común en los proyectos de software es que los requisitos definidos en la primera fase cambian a medida que avanza el proyecto. Esto puede ocurrir porque a medida que avanza el desarrollo y se desarrollan prototipos, los clientes pueden ver con mayor claridad los problemas con el plan original y hacer las correcciones necesarias; también puede ocurrir porque los cambios en el entorno externo requieren remodelar el problema empresarial original y, por lo tanto, necesitan una solución diferente a la propuesta originalmente. Los buenos gerentes de proyecto son conscientes de estas posibilidades y generalmente ya tienen planes de respaldo para manejar estos cambios.

La huella digital de los empleados de IT: una medida extrema o simplemente una práctica de seguridad más

Para resolver este problema, debes:

• Tener un proceso claramente definido para recibir, analizar e incorporar solicitudes de cambio y hacer que tu cliente conozca su punto de entrada en este proceso.
• Establecer hitos para cada fase de desarrollo más allá de los cuales ciertos cambios no son permitidos, por ejemplo, no permitir cambios importantes una vez que un módulo alcanza el 75 por ciento de finalización.
• Asegurarte de que las solicitudes de cambio (y las aprobaciones) sean claramente comunicadas a todas las partes interesadas, junto con su justificación, y que el plan de proyecto maestro se actualice en consecuencia.

Problema 3: Los clientes tienen plazos poco realistas

Es bastante común escuchar a un cliente decir algo como "es un trabajo de emergencia y necesitamos que este proyecto se complete en X semanas". Un error común es aceptar plazos poco realistas antes de realizar un análisis detallado y comprender tanto el alcance del proyecto como los recursos necesarios para ejecutarlo. Al aceptar un plazo poco realista sin discusión, de hecho, le estás haciendo un mal servicio a tu cliente: es muy probable que el proyecto se retrase (porque no fue posible ejecutarlo a tiempo) o sufra defectos de calidad (porque se apresuró sin una inspección adecuada).

Para resolver este problema, debes:

• Convertir la especificación de requisitos de software en un plan de proyecto, detallando las tareas y los recursos necesarios en cada etapa y modelando escenarios de mejor caso, caso intermedio y peor caso.
• Asegurarte de que el plan de proyecto tenga en cuenta las limitaciones de recursos disponibles y reserve suficiente tiempo para las pruebas y la inspección de calidad.
• Iniciar una conversación sobre los plazos con tu cliente, utilizando las cifras de tu plan preliminar como evidencia de respaldo para tus declaraciones. Suponiendo que tu plan sea razonable, es bastante probable que la negociación resultante sea productiva y conduzca a un resultado favorable para ambas partes.

Problema 4: Existen brechas de comunicación entre los clientes, los ingenieros y los gerentes de proyecto

A menudo, los clientes y los ingenieros no se comunican claramente entre sí porque provienen de diferentes mundos y no entienden los términos técnicos de la misma manera. Esto puede llevar a confusión y una grave falta de comunicación, y una tarea importante de un gerente de proyecto, especialmente durante la fase de análisis de requisitos, es asegurarse de que ambas partes tengan una comprensión precisa del entregable y de las tareas necesarias para lograrlo.

Para resolver este problema, debes:

• Tomar notas en cada reunión y difundirlas en todo el equipo del proyecto.
• Ser consistente en el uso de palabras. Hazte un glosario de los términos que vas a usar justo al comienzo, asegúrate de que todas las partes interesadas tengan una copia y adhiérete a ellos de manera consistente.

Problema 5: El equipo de desarrollo no comprende la política de la organización del cliente

Los estudiosos Bolman y Deal sugieren que un gerente efectivo es aquel que ve la organización como una "arena en disputa" y comprende la importancia del poder, el conflicto, la negociación y las coaliciones. Tal gerente no solo tiene habilidades en tareas operativas y funcionales, sino que también comprende la importancia de enmarcar agendas con fines comunes, construir coaliciones unidas en su perspectiva y persuadir a los gerentes resistentes de la validez de una posición particular.

4 pasos para mejorar la colaboración en proyectos de IT

Estas habilidades son críticas al tratar proyectos grandes en organizaciones grandes, ya que la información a menudo está fragmentada y el análisis de requisitos se ve obstaculizado por problemas de confianza, conflictos de interés internos e ineficiencias de información.

Para resolver este problema, debes:

• Revisar tu red existente e identificar tanto la información que necesitas como quién probablemente la tenga.
• Cultivar aliados, construir relaciones y pensar de manera sistemática en tu capital social en la organización.
• Persuadir a los oponentes dentro de la organización de tu cliente al plantear problemas de manera relevante a su propia experiencia.
• Utilizar puntos iniciales de acceso/control para hacer avanzar tu agenda.

Con suerte, esta discusión debería haberte hecho consciente tanto de los posibles obstáculos en la fase de análisis de requisitos como de proporcionar orientación sobre cómo evitarlos. ¡Buena suerte!

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre CXO, allí encontraras muchos artículos similares a Cinco errores comunes en el análisis de requisitos (y cómo evitarlos) , tenemos lo ultimo en tecnología 2023.