Cumplir con los requerimientos de software correctos: 5 errores a evitar

No hay una fórmula única para cumplir los requerimientos de software correctamente. Los proyectos son diferentes y vienen con varios desafíos, oportunidades y metodologías para enfrentarlos.

Tener una idea de qué errores evitar puede mejorar la calidad y precisión de sus requerimientos. Esta publicación es una continuación del Plan de 5 pasos para obtener requerimientos precisos , y señala los pasos en falso que se deben evitar al obtener los requerimientos de software.

Evite los conflictos derivados de diferentes weltanschauung (visiones del mundo)

Haga un intento de comprender la weltanschauung de las partes interesadas, así como la suya. Weltanschuung se refiere a la cosmovisión sostenida por un individuo que se deriva de creencias profundamente arraigadas y supuestos fundamentales extraídos de la cultura, el medio ambiente y las experiencias personales.

Imagina que eres alguien que ha trabajado en un entorno burocrático durante años. Está acostumbrado a buscar aprobaciones y aprobaciones múltiples antes de comprometerse con una decisión importante. Un consultor ahora sugiere que los múltiples niveles de aprobación para el registro de clientes se reduzcan a uno y se implementen a través del sistema una vez que el sistema haya validado automáticamente los criterios predefinidos. Se opone a esto porque no cree que tales escenarios deban estar completamente automatizados; cree que es más efectivo que alguien verifique los datos manualmente (por ejemplo, verifique formularios de clientes, verifique información de fuentes de terceros, etc.) antes de otorgar la aprobación.

Si el analista estuviera al tanto de su bienvenida, podría presentar un argumento que aborde sus inquietudes, desafiar sus suposiciones y posiblemente convencerlo de que cambie de opinión. Tomarse el tiempo para comprender la participación de los interesados ​​puede ayudar a vender el cambio tan necesario.

Por otro lado, los analistas tienden a entrar en discusiones con su propio weltanschuung. Usando el mismo escenario anterior, el analista puede ser de la opinión de que las verificaciones y aprobaciones automáticas son más eficientes que las verificaciones manuales y las aprobaciones en papel. Tales suposiciones fundamentales pueden impedir que el analista vea el otro lado de la moneda. ¿Qué sucede si las aprobaciones manuales con un registro en papel hacen que los participantes del proceso sean más atentos y responsables de sus acciones? ¿Qué sucede si las tareas de verificación de datos manuales solo están reservadas para el personal del grupo y la compañía desea mantener a este personal ocupado porque es útil durante los períodos pico?

Identificar diferentes visiones del mundo no implica que el analista pueda cumplir con todos los requerimientos de los interesados, pero garantiza que las soluciones recomendadas sean aceptables para todos los interesados.

Evitar aseveraciones y recomendaciones ciegas.

Ver el sistema a través de los ojos del actor. Haga un esfuerzo adicional para comprender por qué los usuarios solicitan ciertas funciones. Pase un día en sus zapatos participando en la forma en que realizan su trabajo ( observación ) o mediante juegos de roles. Probablemente haya visto el programa de televisión, Undercover Boss, donde un empleador trabaja con empleados (desconocidos por los empleados) para tener una idea de los procesos, los problemas que enfrentan y las oportunidades de mejora. El juego de roles también se puede lograr a través de la técnica de observación activa.

También es una buena práctica participar en algún tipo de análisis de problemas antes de ofrecer recomendaciones. Esto evitará que el analista recomiende soluciones que no resuelvan el problema real o que causen nuevos problemas. Se debe hacer hincapié en el tratamiento del problema y no en los síntomas (consulte la técnica de 5 por qué ).

Evite los requerimientos de escritura sin conocimiento técnico

Una vez que se obtienen los requerimientos de software, se deben discutir con los desarrolladores y otros miembros del equipo técnico. Los analistas a menudo proponen requerimientos que funcionan en teoría pero no en la vida real.

Esta es la razón por la que las discusiones tempranas con los desarrolladores brindan una verificación de la realidad de los requerimientos propuestos y pueden ayudar a administrar las expectativas de los interesados. Al revisar los requerimientos con el equipo de desarrollo / implementación, la PYME se asegurará de que los requerimientos que se deben cumplir sean factibles antes de que las partes interesadas los firmen.

Evita usar una sola técnica

Cuando se obtienen requerimientos de software, es recomendable utilizar más de una técnica. Apegarse a una sola técnica puede limitar el compromiso de las partes interesadas y, en consecuencia, la cantidad de información recopilada. Por ejemplo, algunas partes interesadas no se sienten cómodas discutiendo sus suposiciones e inquietudes en el contexto de un taller. El uso de las entrevistas como una técnica complementaria en tal escenario, aseguraría que dichas partes interesadas tengan la oportunidad de abrirse al analista sin autocensura.

Además, la técnica de análisis de documentos puede proporcionar al analista información básica sobre el proyecto antes de que se realicen sesiones de obtención de eventos (talleres, grupos focales, entrevistas, etc.). El analista debe recopilar tantos hechos como sea posible antes de usar técnicas que involucren el contacto con las partes interesadas. El tiempo de las partes interesadas es un tiempo valioso para la empresa y es posible que no puedan proporcionar tanto tiempo como lo necesite el analista; tienen trabajos diurnos que deben continuar, a pesar de la necesidad de su participación en el proyecto.

Otra ventaja de usar técnicas complementarias es que los requerimientos conflictivos que no son obvios con una técnica pueden surgir cuando el analista repite la conversación usando una técnica diferente.

Evite reunirse con las partes interesadas desprevenidas

Estar preparado es un aspecto importante de la obtención de requerimientos. Es importante entender el lenguaje de negocios, especialmente los términos y definiciones utilizados por los usuarios de negocios.

Cuando el analista no tiene mucha experiencia con el dominio, hacer una investigación de antecedentes sobre el idioma del dominio puede simplificar las discusiones con las partes interesadas. El analista debe recopilar información de antecedentes sobre el proyecto y los términos comerciales para evitar comenzar en una página en blanco.