Recopilación de Requisitos: Guía Completa y Plantilla
La recopilación de requisitos es un proceso que te permite establecer y gestionar expectativas con los interesados, prevenir la expansión del alcance y reducir la ambigüedad sobre lo que realmente entregará tu proyecto.
Cuanta más documentación de requisitos tengas, menos margen de error y suposición habrá. Los controles y equilibrios beneficiarán tanto la comprensión mutua de tu equipo sobre el proyecto como las expectativas del cliente sobre el producto final.
¿Qué es la recopilación de requisitos en la gestión de proyectos?
La recopilación de requisitos es el proceso de determinar qué necesitan los patrocinadores del proyecto y los principales interesados del mismo. Los gestores de proyectos trabajan para identificar qué se solicita y los detalles relacionados con esa solicitud.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Estas solicitudes se convierten en la lista de requisitos del proyecto. Cumplir con estos requisitos determinará si el esfuerzo se considera un proyecto exitoso o no.
Los gestores de proyectos usan documentos de requisitos y herramientas de gestión de requisitos para realizar un seguimiento de estos tipos de requisitos a lo largo del proyecto:
- Requisitos funcionales
- Requisitos técnicos
- Requisitos no funcionales
- Requisitos del sistema
¿Por qué es importante la recopilación de requisitos?
La recopilación de requisitos es importante por los siguientes motivos (así como también lo es la documentación de dichos requisitos):
- Sirve como punto de referencia para documentar la evolución de un proyecto, sus partes móviles y su implementación.
- Sirve como un plano para que los interesados comprendan mejor qué esperar del proyecto (el qué, dónde, cuándo y por qué del proyecto).
- Reduce el margen de error y ambigüedad, ya que los requisitos están claramente documentados y acordados antes de que comience el trabajo.
- Proporciona controles y equilibrios durante la producción y el aseguramiento de calidad del proyecto, permitiendo que los gestores y miembros del equipo se remitan a él siempre que surjan dudas sobre cómo proceder.
Además de describir lo que se puede esperar, una gestión eficaz de los requisitos debería detallar lo que no se puede esperar. Incluir una sección de “Suposiciones” y/o “Exclusiones” es una estrategia inteligente para eliminar el riesgo de la temida imaginación del cliente.
Un ejemplo de especificación de requisitos de software
Aquí tienes un ejemplo de especificación de requisitos para un proyecto de comercio electrónico:
- Qué: Integración con PayPal
- Dónde: En la sección de pago
- Cuándo: En el paso 3 de 4 de la experiencia de checkout (después del formulario de dirección de envío, antes de la confirmación)
- Por qué: Una integración ya establecida (por ejemplo, PayPal) es una mejor solución que una integración personalizada robusta para un servicio de pago en este caso porque cumple fácilmente con los requisitos de negocio.
- Suposiciones
- Tarifa plana para todo el envío y manejo
- Todos los envíos se realizan dentro de EE. UU. (no incluye Alaska ni Hawái)
- No se aplican impuestos
- Exclusiones
- Cálculos personalizados de tarifas de envío y manejo
- Envíos internacionales, a Alaska o a Hawái
- Reglas fiscales
Recuerda: cuanto menor sea la diferencia entre las expectativas del cliente y la realidad de su producto digital, más satisfecho estará tu cliente con el resultado final. La calidad de tu gestión de requisitos está directamente relacionada con tu capacidad como gestor de proyectos para reducir cualquier área gris en lo que respecta a las expectativas del cliente.
La gran mayoría de las veces, un cliente estará receptivo a que limites el crecimiento del alcance si eso significa que estás preservando su presupuesto; si educas lo suficiente al cliente sobre por qué se abordará (o no) una funcionalidad y luego documentas la lógica detrás de ese enfoque dentro de los requisitos, es mucho más probable que tu cliente colabore contigo.
Es más probable que brinden su aprobación, y más adelante, cuando estén realizando las Pruebas de Aceptación del Usuario (UAT), tendrán una ventaja para entender el "por qué" detrás de la solución propuesta por tu equipo.
Proceso de recopilación de requisitos en 6 pasos
Si bien la recopilación de requisitos debe comenzar tan pronto como se inicie un proyecto y continuar durante todo tu ciclo de vida del proyecto, nunca es demasiado pronto para empezar a recopilar y documentar requisitos. De hecho, deberías haber empezado ayer.
Aquí tienes los pasos para recopilar requisitos.
1. Toma notas
En cada reunión en la que estés—ya sea interna con tu equipo de proyecto o externa con tu cliente—siempre toma notas. Nunca supongas que alguien más las está tomando.
En el momento, puede parecer fácil pensar que se recordará todo lo que se discute, pero tres meses y quince reuniones después, tu equipo y tu cliente te agradecerán tener un registro de esas conversaciones al que puedan recurrir.
Consulta algunos de mis procedimientos recomendados para tomar notas de requisitos aquí:
- Antes de entrar a la reunión, prepara tu documento de notas de acuerdo a la agenda para que organizar los puntos y acciones sea más fácil. Así recordarás lo que hace falta, mientras registras la información relacionada de manera ordenada.
- Después de cualquier reunión, reserva de 15 a 30 minutos para revisar tus notas, digerir lo que se discutió, priorizar las acciones y detectar desafíos/alertas o la necesidad de aclaraciones o reuniones adicionales.
- Envía tus notas a tu equipo interno de proyecto. Haz que revisen y validen lo que has identificado como acciones, alertas, etc.
- Una vez que el equipo haya dado su visto bueno, envía tus notas a tu cliente.
- Finalmente, utiliza tus notas como referencia para crear tareas a partir de cada acción. Agrega cualquier información nueva a la documentación de requisitos y agenda las reuniones necesarias para más descubrimiento o debate.
2. Revisa los requisitos creativos
No dejes las decisiones de diseño y estilo en manos de miembros individuales del equipo: formaliza los requisitos creativos siempre que sea posible. Las directrices creativas son invaluables para los desarrolladores. Como mínimo, asegúrate de tener una guía de estilos a mano, aunque solo incluya tipografías y colores de marca.
Recopila todos los recursos creativos, como logotipos o tipografías de marca, y súbelos a un espacio compartido (como un software de gestión de activos digitales) para que todo el equipo tenga acceso y visibilidad.
3. Redacta el documento de requisitos
Al abordar la documentación, recuerda que tu primera vez será la más difícil. ¿Por qué? Porque no tienes un documento previo para aprovechar (es decir, COPIAR-PEGAR). Por suerte, este artículo incluye una plantilla de documentación de requisitos que te servirá como base.
Como muestro en esta plantilla, organizo mi documentación de requisitos en cuatro partes:
- Anotación: Incluye los números de tu diseño anotado. Si tu diseño de página tiene 8 elementos, tendrás 8 anotaciones y tu columna de anotaciones tendrá 8 filas
- Elemento: Incluye los títulos de los elementos, según corresponden a cada anotación
- Requisito funcional: Incluye una definición (los requisitos, detallados) para cada elemento
- Funcionalidad de administración/CMS: Define cualquier funcionalidad administrativa y/o de CMS relacionada con el elemento correspondiente
4. Realiza una revisión interna
En esta parte del proceso de recopilación de requisitos, programa otra reunión interna con tu equipo de proyecto para revisar la documentación de requisitos. Esta es una última verificación interna para asegurar que comprendes la implementación.
Si es posible, haz que el equipo revise tu documentación de requisitos antes de la reunión para que puedan venir preparados con sus preguntas y/o comentarios. Utiliza la reunión para discutir cualquier pregunta o comentario sobre los requisitos.
Realiza las revisiones necesarias en la documentación según lo hablado en la discusión interna. Finalmente, reenvía la documentación de requisitos revisada al equipo para que sea aprobada definitivamente. Una vez que el equipo interno de proyecto dé su aprobación final de la documentación de requisitos, guarda el documento como PDF para asegurar que permanezca en su estado final para el siguiente paso: el desarrollo de tareas.
5. Detalla las tareas
Proporciona la versión PDF de la documentación de requisitos a tu equipo de desarrollo. Idealmente, tus desarrolladores o el líder del equipo serán quienes definan las tareas para la construcción.
Si bien algunas organizaciones pueden operar bajo un proceso en el que los project managers detallan todas las tareas, prefiero que los propios desarrolladores definan sus tareas; las pocas horas que les implica valen la pena.
De todas formas, puedes ofrecer pautas útiles a tu equipo mientras desarrollan sus tareas y entregables de desarrollo. Tras el desglose de las tareas, podrás obtener una estimación final de horas.
Compara esa proyección con el cronograma del proyecto que has comunicado previamente a tu cliente y gestiona en consecuencia si lo consideras necesario. Para más información sobre la estimación de proyectos, consulta esta guía completa de estimación de proyectos.
6. Realiza una revisión externa
Ha llegado el momento de presentar la documentación de requisitos a tu cliente. Proporciónala como un PDF para evitar que se realicen modificaciones. Esto (1) demuestra tu compromiso para asegurar la comprensión por parte del cliente de la solución digital y (2) te servirá como respaldo para poder decir "ya te lo advertí" (pero de una forma mucho más diplomática) cuando surja el famoso aumento de alcance.
Educa a tu cliente. Guíalo por esta valiosa documentación que has preparado cuidadosamente para él. Recuerda: ellos son los expertos en su negocio. Tú eres el experto en la solución digital que les ofreces. Ellos te pagan por esa solución. Educa y empodera a tu cliente.
Una vez que el cliente haya confirmado su comprensión de la documentación de requisitos, es momento de recibir la aprobación formal. Envía la documentación de requisitos firmada y aprobada a tu equipo y guárdala en un espacio compartido, para que quede constancia formal de que el desarrollo puede comenzar.
Técnicas para la recopilación de requisitos
A continuación, algunas técnicas que te ayudarán a asegurarte de que realizas el importante trabajo de recopilación de requisitos de la mejor manera posible:
1. Empieza de inmediato
La documentación de requisitos debe comenzar tan pronto como se inicien las conversaciones, antes de que hayas concretado el plan o los objetivos exactos del proyecto. Captura todo lo que puedas y después recorta. Aquí tienes algunas estrategias que puedes probar con tu cliente:
- Envíales un cuestionario sobre lo que les gustaría ver en el proyecto
- Realiza una sesión de lluvia de ideas
- Organiza un grupo focal
En lugar de eliminar información del documento, clasifícala en lo que está incluido y lo que no lo está—esto evita suposiciones del cliente más adelante.
Podrás extraer tu documentación WIP (en progreso) de requisitos y señalar dónde se recopiló esa información, por qué puede que no esté incluida, la lógica detrás de la decisión y la fecha en que se recogió, dejando toda la trazabilidad.
2. Utiliza plantillas
Una vez que hayas elaborado algunos documentos de requisitos, comienza a aprovecharlos y plantillízalos para su uso futuro en otros proyectos. Especialmente si tienes un enfoque específico en proyectos de comercio electrónico o aplicaciones de aprendizaje, empezarás a ver que surgen patrones de funcionalidad. Identifica dónde puedes reutilizar.
3. El trabajo en equipo hace que el sueño funcione
Si hay diferentes tipos de miembros en el equipo de un proyecto, los requisitos de cada área de especialización pueden ser redactados por los expertos correspondientes.
En muchos casos, la conversación sobre requisitos es un camino sinuoso de llamadas telefónicas, varias reuniones separadas y conversaciones, etc. Por eso es fundamental asignar la redacción de los documentos de requisitos a los respectivos miembros del equipo mientras llevas a cabo la obtención y compilación de los requisitos.
4. No solo registres los requisitos—aprende
Haz más que tomar notas. Espera más que recursos enviándote un muro de texto con su parte de los requisitos. Dedica tiempo a sentarte con tu equipo de desarrolladores y aprende las soluciones que el equipo tiene en mente para la implementación. Habla sobre el porqué y el cómo. Haz preguntas.
Antes de que digas: "Pero solo tenemos cierta cantidad de tiempo al día, ¿y el presupuesto?", comprende esto: si la solución en la que trabajas es aplicable a más de un proyecto, entonces este tiempo adicional para comprender no necesariamente tiene que ser facturable. Estás aumentando tu conocimiento experto en la materia, lo que mejora directamente tu trabajo diario.
5. Mantén a tu cliente informado
Ten un documento interno de requisitos, así como un documento de requisitos en progreso orientado al cliente. En el documento interno, puedes preocuparte menos por incluir notas más transparentes.
Si no estás tratando con información sensible, puedes crear este espacio compartido mediante un Google Doc, habilitando permisos para que el cliente pueda comentar. Si se trata de información sensible, comparte una versión del documento de requisitos semanalmente para dar al cliente una instantánea de lo que se ha recogido.
6. Da por hecho que tu cliente siempre quiere saber más
En vez de arriesgarte a suponer que tu cliente sabe más de lo que realmente sabe (y luego tener problemas por ello), da por hecho que tu cliente siempre quiere saber más. Por cada anotación, pregúntate “¿Por qué?” cinco veces para asegurar la exhaustividad de cada requisito.
Cuestionarte a ti mismo “¿Por qué?” cinco veces por cada requisito te desafía a considerar realmente la lógica detrás de cada elemento y funcionalidad de cada tipo de página. Puede que te sorprendas con cuánto tú aprendes (o te des cuenta de lo que necesitas aprender).
3 consejos de expertos para redactar un documento de requisitos de proyecto
1. Redacta los requisitos para los elementos globales por separado
Para eliminar la redundancia, cubre todos los elementos globales en una sección de “Elementos globales” en tu documentación de requisitos. Esto aplica para elementos globales como los elementos principales del menú de navegación, cualquier cosa dentro de tu encabezado global y cualquier cosa dentro del pie de página.
Una vez que hayas redactado los requisitos para estos elementos globales, no te molestes en anotarlos en el resto de las páginas; solo anota los elementos específicos de esas páginas.
2. Copia-pega la funcionalidad idéntica para asegurar la coherencia
Esto es solo un consejo a tener en cuenta para tu cordura (y la de tu cliente). Verás esto sobre todo en elementos comunes de página como imágenes hero/banner, encabezados, o iconos de “volver”, entre una gran cantidad de funcionalidades repetidas en distintos tipos de páginas (sin confundirse con los elementos globales).
3. Reconoce la administración y el CMS (o su ausencia)
Cuando estamos tan enfocados en la funcionalidad de cada elemento de la página, es fácil pasar por alto la funcionalidad administrativa y/o del CMS. Si vas a implementar una solución que ofrece funcionalidad administrativa y/o de CMS, asegúrate de incluirla como una columna por separado en tus requisitos. Ejemplo a continuación:
Plantilla de documento de requisitos [Descargar]
Los detalles específicos de la definición de los requisitos dependerán de tu relación con el cliente, la experiencia de tu equipo y otros factores.
Sin embargo, aún necesitarás las partes básicas de un documento de requisitos del proyecto que defina la funcionalidad de una característica, su ubicación, diseño, etc. Aquí tienes nuestra plantilla para el documento de requisitos (debes ser miembro para acceder):
Acelera tu trabajo con más de 100 plantillas premium
Hazte miembro de DPM para acceder a infinitas plantillas creadas por expertos que te ayudarán a trabajar más rápido y de manera más eficiente.
