AUTOR: Alberto Maurel Mendizábal
¿No has hecho nunca recopilación de requisitos? Parece fácil. La idea es coger papel y bolígrafo, apuntar lo que te piden y ponerlo luego en limpio. Pero, ¿seguro que lo has entendido todo bien?, ¿No te has olvidado de ninguna petición? ¿Las has transcrito bien? A veces una palabra lo cambia todo...¿Qué harás la próxima vez?
La recopilación de requisitos es la base para definir el alcance del proyecto, es decir, la descripción clara y concreta de los los productos y otros entregables. Consiste en identificar las necesidades de los interesados (como el representante del cliente) y ponerlas por escrito de forma organizada. Este escrito servirá para hacer seguimiento y control de su cumplimiento.
Un análisis de varios cursos de la asignatura proyectos de informática mostró que los equipos olvidaban poner por escrito entre un 10 y un 20% de las peticiones. Al juntar esto con las deficiencias en su seguimiento, el resultado es que bastantes productos entregados incumplían muchos requisitos.
Según nuestra experiencia realizando dos proyectos de siete semanas cada uno, las razones que explican estos resultados pueden ser las siguientes:
- La documentación proporcionada inicialmente no se entiende completamente. Se trata del documento de presentación del proyecto donde se presentan de forma escueta las peticiones iniciales.
- Interpretaciones erróneas. Los contenidos de la presentación y de los mensajes del cliente se pueden entender mal si se leen rápido. Hay que poner atención a los detalles.
- Suposiciones que contradicen peticiones olvidadas. Las peticiones se van volcando en una sección del plan. Las que se olvidan de recoger allí, dejan de existir para el equipo. Las suposiciones posteriores pueden contradecir lo solicitado inicialmente y no recogido.
- Delegar en una persona. Por más competente que sea esa persona es fácil que cometa errores, sobre todo si no dispone del tiempo y la paciencia necesaria para hacer bien esta labor. En el último proyecto de siete semanas que hicimos en la asignatura, el cliente se reunió con los representantes de los equipos, y además nos escribíamos con él por email. En este contexto, las posibilidades de despistarse en algún momento aumentan. Además, en ese proyecto el equipo es más numeroso y hay que comunicarse y revisar lo que hacen más personas, aumentando las probabilidades de cometer errores.
- No revisar lo realizado. Es importante que una segunda persona revise el trabajo hecho por el encargado de gestionar los requisitos. Tiene que ser una persona diferente.
- La dificultad propia de la comunicación. Hay mucha comunicación y muchos interlocutores. Está el director y todos los miembros del equipo. También el representante del cliente y el promotor. Las probabilidades de olvidar o malinterpretar algún mensaje aumentan.
- El tiempo que lleva comunicarse. Exige un esfuerzo, hay que pensar lo que se escribe y hacerlo claro y breve para que nos entiendan. La escasez de tiempo influye negativamente en la calidad de nuestras comunicaciones.
- Empezar la tarea tarde. Cuando el tiempo escasea se empiezan las tareas muy tarde y no queda tiempo para preguntar al representante del cliente o al promotor. Los equipos tomamos atajos preguntando a otros equipos o haciendo suposiciones de última hora. La consecuencia es una documentación incompleta o con errores.
¿Es aceptable esta tasa de errores a nivel profesional? Obviamente no. Los errores en la recopilación de requisitos pueden tener consecuencias dolorosas, como tener que rehacer parte de una aplicación y la insatisfacción del cliente. A nivel profesional es esencial realizar productos ajustados a las peticiones y de suficiente calidad.
Existen bastantes recursos que nos enseñan a afrontar este problema. Uno de ellos es el libro "Técnico en Gestión de Proyectos: Claves para aprobar el examen CAPM". En su capítulo 5 (páginas 94 y 95), se presentan algunas formas de superar estos errores:
- Preguntar al promotor y al cliente, además de leer con calma y analizar los documentos.
- Reuniones de varios miembros del equipo para discutir sobre los requisitos encontrados.
- Usar técnicas de creatividad como la tormenta de ideas y los mapas conceptuales.
- En caso de discrepancias entre miembros del equipo, utilizar técnicas grupales para la toma de decisiones, ya sea por consenso, votación, o siguiendo las indicaciones del director del equipo. Personalmente, considero que la última opción no es adecuada.
- Realizar primero un prototipo de los requisitos para visualizar los más claros y luego llevar a cabo un estudio más profundo. Cuidado porque NO se trata de delegar la revisión de los requisitos en el cliente entregándole cualquier cosa.
Por tanto, a la vista de las cinco ideas anteriores, podemos concluir que, para lograr una gestión de requisitos de mayor calidad, es aconsejable la colaboración de varias personas del equipo.
Algunas lecciones que también hablan sobre el problema de los requisitos son "La maraña de los requisitos y los extras" de Joaquín Ortiz de Murua y "El Iceberg de requisitos y nuestro 'Titanic'" de Carlos Carbonell.
No comments:
Post a Comment