Si un proyecto entra en producción después de la recopilación de requisitos y nadie se ha tomado el tiempo de documentar minuciosamente cada decisión, excepción, especificación y suposición, ¿realmente se recopilaron los requisitos del proyecto?
La importancia de la recopilación de requisitos a menudo se subestima en varios niveles. Cuando los presupuestos son ajustados, los plazos son ajustados y el alcance se está expandiendo, la documentación de los requisitos tiende a ser el primer entregable que se descarta y el último que se considera.
Esto es sorprendente, especialmente cuando se considera que ignorar un proceso exhaustivo de recopilación de requisitos significa sacrificar un punto de referencia sólido para los controles y equilibrios durante la producción y el control de calidad, poniendo en peligro las expectativas entre el cliente, tu equipo y los usuarios finales, y dejando mucho espacio para errores y ambigüedad.
Todo esto puede afectar rápidamente tus márgenes (y tu cordura).
A primera vista, el proceso de recopilación de requisitos y la documentación de requisitos pueden parecer intimidantes, pero no tiene por qué serlo.
Voy a arrojar luz sobre la importancia de los requisitos, el proceso de gestión y recopilación de requisitos, algunas técnicas de recopilación de requisitos a considerar y enfoques para escribir la documentación de requisitos.
Si bien la documentación de requisitos puede volverse complicada, el proceso no tiene por qué serlo. Mi objetivo con este artículo es proporcionarte un enfoque simplificado y intuitivo para la recopilación y documentación de requisitos.
Plantilla de Documento de Requisitos
Los detalles de tu definición de requisitos dependerán de tu relación con el cliente, la experiencia de tu equipo y otros factores. Sin embargo, seguirás necesitando las partes básicas de un documento de requisitos del proyecto que defina la funcionalidad, ubicación, diseño, etc., de una característica.
Aquí tienes algunas plantillas de documentos de requisitos (en inglés), junto con un glosario digital para ayudarte:
¿Qué son los Requisitos?
Comenzando con una definición básica, los requisitos en el ámbito digital se pueden categorizar en dos tipos: requisitos funcionales y requisitos no funcionales.
Para los propósitos de esta discusión, nos centraremos en estos dos tipos de requisitos que generalmente encontramos en productos y servicios digitales. Por supuesto, existen otros tipos, como requisitos legales y técnicos, y dependiendo del contexto, la persona encargada de la documentación de requisitos puede necesitar capacitación adicional en redacción técnica, mapeo de información y más.
¿Qué son los Requisitos Funcionales?
En el contexto de una interacción digital, los requisitos funcionales se relacionan con la funcionalidad de un producto: sus capacidades, usabilidad, características y operaciones en relación con el propósito previsto del producto.
A menudo, los requisitos funcionales se mencionan claramente como tales en la Documentación de Requisitos Funcionales (FRD, por sus siglas en inglés). Mientras que una Declaración de Trabajo (SOW, por sus siglas en inglés) establece los objetivos y requisitos de alto nivel del producto deseado, un FRD proporciona una elaboración más detallada de estos requisitos, que se recopilan tan pronto como comienza un proyecto y hasta que comienza la producción del proyecto.
Nota adicional: los requisitos no se limitan al período anterior a la producción: la documentación de órdenes de cambio, la documentación de garantía, etc. son formas útiles de documentación continua de requisitos que ocurre a lo largo de un proyecto, ¡incluso más allá del proyecto! Mientras trabajes con un cliente, la documentación siempre crece y evoluciona.
Dependiendo del tamaño y alcance de un proyecto, podrías decidirte por un hito entre la SOW y el FRD (ya que este período puede extenderse durante meses). En este caso, algunos equipos crean la Documentación de Requisitos de Negocio (BRD) para proporcionar una aprobación formal a mitad de camino, un punto de control de expectativas, para todas las partes. Esto brinda la oportunidad al Director de Proyecto de confirmar que el equipo va en la dirección correcta antes de avanzar demasiado en la entrega de los resultados.
¿Qué son los Requisitos No Funcionales?
Los requisitos no funcionales abarcan todo lo que no está relacionado con la funcionalidad de un producto: su rendimiento, estabilidad, seguridad y especificaciones técnicas, por mencionar solo algunos tipos de requisitos no funcionales en la industria digital.
Ejemplos de Requisitos Funcionales vs. No Funcionales
Tanto la documentación de requisitos funcionales como la de requisitos no funcionales son igualmente instrumentales a su manera. Coexisten de la mano; uno se ve afectado directamente por el otro.
Aun así, no todos los requisitos no funcionales corresponden directamente a un requisito funcional. La configuración y puesta a punto del servidor, por ejemplo, es un requisito no funcional que tiene un impacto en la estabilidad de todo un sitio, sin una relación directa 1:1 con un requisito funcional singular.
Aquí tienes algunos ejemplos de requisitos funcionales y no funcionales, y cómo están relacionados:
- Requisito Funcional: funcionalidad de procesamiento de pagos
- Requisito No Funcional: certificado SSL
Si bien estamos en el 2023 y los sitios web deberían tener certificados SSL de todas maneras, es especialmente importante hacerlo si se implementa una funcionalidad de procesamiento de pagos en el sitio. Este es un ejemplo de un requisito no funcional (certificado SSL, un elemento de la implementación que afecta la seguridad) que afecta directamente a un requisito funcional (pago, un elemento de la implementación que afecta la usabilidad).
Aquí tienes otro ejemplo:
- Requisito Funcional: herramientas y recursos (PDF, infografías, material de curso, hojas de cálculo) disponibles para los usuarios, accesibles a través de la página de Recursos
- Requisito No Funcional: especificaciones de formato de archivo del panel de administración (por ejemplo, "Los siguientes formatos de archivo son válidos para cargar en el panel de usuario administrador, en relación con la página de Recursos: .zip, .jpeg, .csv, .pdf")
Según la funcionalidad de la página de Recursos, los usuarios pueden acceder a recursos como PDF, infografías, material de curso o hojas de cálculo. Esta funcionalidad es una característica y una operación de la página. Es un requisito funcional.
Las especificaciones de formato de archivo del panel de administración, por otro lado, son un requisito no funcional; son especificaciones técnicas relacionadas con la funcionalidad administrativa. No afectan la usabilidad de los usuarios finales. Sí, estas especificaciones afectan la usabilidad de los usuarios administrativos, pero no definen directamente cuál es la funcionalidad del producto para el usuario final. Esto es un requisito no funcional.
La Importancia de la Gestión de Requisitos
La gestión de requisitos es importante por dos razones principales:
- La documentación de requisitos sirve como punto de referencia para documentar la evolución de un proyecto, sus componentes móviles y su implementación.
- La documentación de requisitos sirve como un plano para que el cliente comprenda mejor qué esperar del proyecto (el qué, dónde, cuándo y por qué del proyecto).
Además de describir lo que pueden esperar, parte de la planificación de la gestión de requisitos debería detallar lo que no se debe esperar. Incluir una sección de "Suposiciones" y/o "Exclusiones" es un enfoque inteligente para eliminar el riesgo de la temida imaginación del cliente.
Veamos un ejemplo que muestra cómo la recopilación de requisitos es importante como punto de referencia y plano para gestionar las expectativas:
Ejemplo de Requisitos de un Proyecto
- Qué: Integración de PayPal
- Dónde: Página de pago
- Cuándo: En el paso 3 de 4 en la experiencia de pago (después del formulario web de dirección de envío, antes de la confirmación)
- Por qué: Una integración 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 del cliente.
- Suposiciones
- Tarifa plana para todos los gastos de envío y manipulación
- Todos los envíos se realizan dentro de los Estados Unidos (excepto Alaska o Hawái)
- No se aplican impuestos
- Exclusiones
- Cálculos personalizados de tarifas de envío y manipulación
- 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 con su producto digital, más contento estará tu cliente con el resultado final.
La calidad de tu gestión de requisitos se correlaciona directamente con tu capacidad como Gerente de Proyecto Digital para reducir las "zonas grises" en las expectativas del cliente.
En la gran mayoría de los casos, un cliente estará receptivo a limitar el alcance del proyecto si esto significa que se está preservando su presupuesto; si educas al cliente de manera suficiente sobre por qué se abordará una característica (o por qué no se abordará) y luego documentas la lógica detrás de ese enfoque dentro de los requisitos, es mucho más probable que tu cliente colabore (¡suelen disfrutar de sentirse involucrados, ¿verdad?!). Es más probable que otorguen su aprobación y, más adelante, cuando realicen las Pruebas de Aceptación del Usuario (UAT), tendrán una ventaja para comprender el "por qué" detrás de la solución de tu equipo.
Herramientas de Gestión de Requisitos
Puedes gestionar los requisitos en algo tan simple como Google Sheets, pero también existen plataformas especializadas diseñadas para ayudarte a definir y dar seguimiento a los requisitos a medida que evoluciona el proyecto. Aquí tienes algunos ejemplos, y puedes obtener más información sobre ellos en esta descripción general de las herramientas de gestión de requisitos:
Comprendiendo el Proceso de Recopilación de Requisitos
Si bien la recopilación de requisitos debe comenzar tan pronto como comienza una colaboración y durante todo el ciclo de vida de tu proyecto, la mayor parte de la documentación de requisitos para algo como la creación de un sitio web completo debe realizarse después de la fase de descubrimiento (estrategia de contenido, mapeo del sitio, wireframes, diseños) y antes del desarrollo. Nunca es demasiado temprano para comenzar a recopilar y documentar los requisitos del proyecto. De hecho, comienza ayer.
Nunca es demasiado temprano para comenzar a recopilar y documentar los requisitos del proyecto. De hecho, comienza ayer.
Aquí están los pasos sobre cómo recopilar requisitos, llevándote a través de un proceso completo de recopilación de requisitos. Estos pasos te ayudarán a finalizar la documentación de requisitos a través de la colaboración en equipo, controles y equilibrios, y la educación del cliente.
1. Tomar Notas
En todas las reuniones en las que participes, ya sean internas con tu equipo de proyecto o externas con tu cliente, siempre toma notas. Nunca supongas que alguien más lo está haciendo. Lo más probable es que no lo estén haciendo.
Los Gerentes de Proyectos Digitales no son secretarios, pero se espera que capturemos elementos de acción, necesidades de aclaración, oportunidades para investigaciones o discusiones adicionales, y cualquier otra información importante que se discuta en las reuniones. En el momento, puede ser fácil asumir que todo lo que se está discutiendo se recordará, pero 3 meses y 15 reuniones después, tu equipo y tu cliente te lo agradecerán por tener un registro de esas discusiones para consultar.
Consulta algunos de mis procedimientos recomendados para tomar notas de requisitos aquí:
- Antes de ingresar a tu reunión, prepara tu documento de notas para reflejar tu agenda, de manera que organizar los elementos de acción y los puntos sea más fácil. Por ejemplo, tu agenda puede tener los puntos "Integración de Paypal", "Página de destino de pago" y "Funcionalidad de código promocional". En tu documento de notas, agrega esos elementos como encabezados e incluye cualquier punto que tú o tu equipo deseen mencionar debajo del encabezado correspondiente. De esta manera, recordarás lo que se necesita mientras capturas información relacionada de manera organizada.
- Después de cualquier reunión, asigna de 15 a 30 minutos para revisar tus notas, asimilar lo que se discutió, priorizar elementos de acción, identificar desafíos/señales de alerta y necesidades de aclaración o reuniones adicionales.
- Envía tus notas a tu equipo de proyecto interno. Pídeles que revisen y verifiquen lo que has identificado como elementos de acción, señales de alerta, etc.
- Una vez que el equipo te haya dado su aprobación, envía tus notas a tu cliente.
- Finalmente, utiliza tus notas como referencia para crear tareas (por ejemplo, tareas en JIRA) a partir de cada elemento de acción. Agrega cualquier información nueva a tu documentación de requisitos y programa las reuniones necesarias para descubrimientos o discusiones adicionales.
- Guarda tus notas en un espacio compartido, quizás dentro de una carpeta de "Notas de Reuniones" en una instancia de Google Drive, para que los miembros de tu equipo de proyecto puedan acceder y consultarlas fácilmente en el futuro.
2. Revisa los Requisitos Creativos
No dejes las decisiones de diseño y estilo en el aire: proporciona requisitos creativos siempre que sea posible. Si tu calendario y presupuesto lo permiten, la orientación creativa es invaluable para los desarrolladores. Aunque puedes encontrar ese raro desarrollador unicornio que también es diseñador, más a menudo de lo que te gustaría, descubrirás que un desarrollador es mejor en desarrollo; no los encargues con el diseño.
Como mínimo, proporciona una guía de estilo, incluso si la guía de estilo es tan básica como la fuente y los colores de marca. Idealmente, tendrás tanto wireframes como diseños de interfaz de usuario completos para dispositivos móviles y de escritorio en todos los tipos de páginas.
Una vez que los hayas reunido, carga todos los activos creativos en un espacio compartido (como software de gestión de activos digitales) para que todo el equipo pueda acceder a ellos y verlos. Asegúrate de guardar las versiones finales de estos diseños en un solo lugar, separadas de las versiones más antiguas, para que tu equipo esté absolutamente seguro de que están haciendo referencia a los activos creativos finales.
Cuando la creatividad esté finalizada y aprobada formalmente por el cliente, es valioso programar una reunión interna de entrega para el equipo del proyecto; esto brinda la oportunidad para que los miembros de tu equipo creativo entreguen su trabajo de manera eficiente a los miembros del equipo de desarrollo. También permite la discusión para hacer preguntas, aclarar las necesidades de aclaración y reducir el riesgo de suposiciones de los desarrolladores, un juego peligroso en otros casos.
Tu "equipo creativo" puede no estar limitado a tus diseñadores de UX/UI; esto también puede incluir a un estratega digital para hablar sobre los recorridos de usuario o a un arquitecto de contenido para discutir el mapa del sitio. Incluye a todos los que contribuyeron a los entregables hasta ahora, que inevitablemente desempeñarán un papel en el desarrollo, la producción y la implementación que viene.
3. Realiza Anotaciones
Una vez que hayas entregado los entregables del equipo de creativos al equipo de desarrollo, es hora de hacer anotaciones en los elementos de la página en todos los tipos de página. Esto puede incluir imágenes de inicio estáticas frente a carruseles, menús desplegables frente a campos de texto en formularios web, menús desplegables frente a ventanas emergentes, modales emergentes frente a nuevas cargas de página y cualquier otra funcionalidad en cada tipo de página.
Solo realiza anotaciones en las páginas una vez que estén absolutamente finales. No hay nada peor que tener que volver a anotar una página con 35 elementos solo porque se eliminó la sombra de un botón de paginación (bueno, hay cosas peores, pero entiendes mi punto).
Cada elemento de la página requiere una anotación. Usa una herramienta como Invision o Skitch para anotar los diseños de la página.
Normalmente, comienzo anotando el diseño de la página móvil y luego anoto el diseño de escritorio correspondiente, solo cuando la funcionalidad de esa página difiere de la experiencia móvil a la experiencia de escritorio. ¿Por qué empezar con móvil? En la industria digital, es más beneficioso mantener en mente un enfoque "Mobile First" al producir una solución digital. Dicho esto, es posible que tengas un cliente en el espacio de Productos Industriales o Mecánicos cuyos usuarios acceden a su plataforma a través de computadoras de escritorio en almacenes y no pueden acceder mediante dispositivos móviles. En ese caso, debes adaptar y anotar los diseños de la página de escritorio primero.
Mi punto es este: ya sea móvil, tablet, escritorio, vertical, horizontal, lo que sea… anota primero el formato o tipo de diseño de página que tenga más sentido. Luego, ajusta los diseños restantes para cada página si es necesario.
Una vez que tus elementos creativos estén anotados, carga las imágenes en tu documentación. Hazlo en un orden que tenga más sentido. Si existe un recorrido de usuario, es más beneficioso aprovecharlo como guía para el orden en el que organizas los diseños anotados. Por ejemplo:
- Página de inicio
- Página de Categoría de Producto
- Página de Detalle del Producto
- Página de Personalización del Producto
- Página de Pago
- Página de Confirmación
Si no tienes un recorrido de usuario para aprovechar, entonces organiza tus diseños de página anotados de una manera que tenga sentido para tu cliente. La página de inicio siempre es una apuesta segura como primer diseño para mostrar en tu documentación de requisitos, ya que probablemente es el diseño de página con el que tu cliente está más familiarizado en este punto.
Recuerda: en este punto del compromiso, nada de lo que incluyas en la documentación de requisitos debe ser una sorpresa para tu cliente. Esto no es un vehículo para presentarles algo nuevo; esta documentación formaliza lo que ya se ha discutido, decidido y (al menos de manera informal) aprobado por tu cliente.
4. Escribe el Documento de Requisitos
La parte divertida.
Al sumergirte en la documentación, recuerda: tu primer intento de documentación de requisitos será el más difícil. ¿Por qué? Porque no tienes un documento previo del cual aprovechar (es decir, COPIAR-PEGAR). Afortunadamente para ti, querido amigo DPM, este artículo incluye una plantilla de documentación de requisitos que servirá como base para ti.
Como se muestra 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, tal como se relacionan con cada anotación.
- Requisito funcional: Incluye una definición (los requisitos, especificados) para cada elemento.
- Funcionalidad de administración/CMS: Define cualquier funcionalidad administrativa y/o de CMS relacionada con el elemento correspondiente.
5. Realiza una Revisión Interna
Una vez que hayas completado tu primer borrador de la documentación de requisitos, date un respiro. Tómate una cerveza. O una root beer (cerveza sin alcohol). Disfrútala. Pero solo una. Aún hay trabajo por hacer. Y te lo prometo: el trabajo inicial vale la pena.
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 todos juntos. Esta es una revisión interna final para garantizar tu comprensión de la implementación. Esto es imperativo. ¿Por qué? Porque, adivina qué, como DPM, tú gestionas las expectativas del cliente para la implementación. Tu comprensión es fundamental para el éxito del proyecto y la satisfacción de tu cliente.
Si es posible, haz que el equipo revise tu documentación de requisitos antes de la reunión para que puedan llegar preparados con sus preguntas y/o comentarios. Utiliza la reunión para discutir cualquier pregunta y dar retroalimentación sobre los requisitos. Identifica lagunas en la comprensión y verifica la coherencia de la documentación de requisitos.
Como parte de la fase de revisión interna, deberás realizar las revisiones necesarias en la documentación, basadas en la discusión interna. Finalmente, reenvía la documentación de requisitos revisada al equipo para su última aprobación.
Una vez que el equipo de proyecto interno haya dado su aprobación final a la documentación de requisitos, guarda el documento como un PDF para asegurarte de que permanezca en su estado finalizado para el siguiente paso: la creación de tareas.
6. Creación de Tareas
Proporciona la versión en PDF de la documentación de requisitos a tu equipo de desarrollo. Idealmente, tus desarrolladores o líder de desarrollo llevarán a cabo la creación de tareas para la construcción. Aunque algunas organizaciones pueden seguir un proceso en el que los DPM crean todas las tareas, prefiero que los desarrolladores creen sus propias tareas; las pocas horas que les lleva valen la pena. Esto permite que los desarrolladores creen las tareas de la manera que mejor se adapte a su enfoque de desarrollo.
Todavía puedes proporcionar pautas útiles a tu equipo mientras crean sus tareas de desarrollo. Aquí tienes algunas pautas de ejemplo para la construcción de un sitio web:
- Ninguna tarea debe superar las 8 horas.
- Sigue la terminología específica de JIRA, pero aplicable a otras herramientas.
- Cada elemento de tipo de página anotado en la documentación de requisitos debe tener su propia subtarea.
- Las versiones móviles y de escritorio deben tener historias separadas.
- 1 sprint = 1 semana.
- Utiliza estimaciones de tiempo (puntos de historia u horas).
Después de la creación de tareas, podrás obtener una estimación final de horas. Por ejemplo, si un desarrollador crea todas sus tareas con estimaciones de horas y el total de horas es de 150, entonces…
- Supón que tu desarrollador trabaja de manera enfocada solo en tu proyecto.
- Cada semana obtendrás 35 horas de su tiempo.
- 150 horas en total a 35 horas por semana = 4.3 semanas.
- Agrega la prueba de calidad (QA), que debería ser típicamente el 20% de tu tiempo de desarrollo.
- 150 horas de desarrollo = 30 horas de QA, o 1 semana.
- Ahora puedes confirmar que tu línea de tiempo de desarrollo es de 4 o 5 semanas seguidas de 1 semana de QA.
En este punto, compara esa proyección con la línea de tiempo que se ha comunicado previamente a tu cliente y gestiona según sea necesario. Para obtener más información sobre la estimación de proyectos, consulta esta guía completa de estimación de proyectos.
7. Realiza una Revisión Externa
En este punto, has:
- Escrito tu documentación de requisitos.
- Confirmado la documentación con tu equipo de proyecto interno.
- Creado tareas de desarrollo basadas en la documentación de requisitos.
- Confirmado la línea de tiempo proyectada a través de la prueba de calidad (QA) basada en la documentación de requisitos.
Es hora de presentar la documentación de requisitos a tu cliente. Proporciónala en formato PDF para asegurarte de que no se realicen ediciones. Incluye un mensaje solicitando de inmediato una reunión para revisar juntos esta documentación. Esto (1) ejemplifica la inversión de tu parte para garantizar la comprensión del cliente de la solución digital y (2) será un respaldo para ti, como DPM, para poder decir "ya te lo dije" (pero de manera mucho más elocuente) cuando inevitablemente surja el alcance fuera de lo acordado más adelante en el proceso.
Educa a tu cliente. Guíalos a través de esta valiosa documentación que con tanto esfuerzo has preparado para ellos. Puede que tengas clientes con una amplia experiencia en la implementación de soluciones digitales. Pero apuesto a que, más a menudo que no, no la tienen y no la han tenido.
Aunque tu cliente pueda menospreciar una revisión de la documentación, es posible que te sorprendas con su interés y aprecio por tener la capacidad de revisar la documentación contigo. Recuerda: ellos son expertos en su negocio. Tú eres el experto en la solución digital que les estás ofreciendo. Ellos te están pagando por esta solución. Educa y empodera a tu cliente. (Probablemente) se lo merecen. Inicia la conversación asegurándote de que entiendan que este es el momento para hacer cualquier pregunta que puedan tener, pedir aclaraciones y que ninguna pregunta es una pregunta tonta. Lo apreciarán. En el peor de los casos, pueden rechazar la solicitud de una revisión conjunta. Al menos puedes decir que ofreciste la opción. Y te diré esto: no he tenido un solo cliente que haya rechazado esta solicitud.
Una vez que el cliente haya confirmado su comprensión de la documentación de requisitos (ya sea que decidieron realizar una revisión contigo o no), finalmente es el momento de recibir una aprobación formal. Te recomiendo encarecidamente obtener una firma para esta documentación de requisitos antes de comenzar cualquier desarrollo. Parece algo obvio, pero esta dependencia se abusa con más frecuencia de lo que piensas. Haz todo lo posible por cumplirla.
Envía la documentación de requisitos firmada y aprobada a tu equipo y guárdala en un espacio compartido, de modo que haya una indicación formal de que el desarrollo puede comenzar.
Educa y empodera a tu cliente. (Probablemente) se lo merecen.
La Forma Incorrecta de Recopilar Requisitos
A continuación, se muestra un ejemplo de un requisito no tan bueno, un ejemplo en el que la gestión de requisitos es severamente deficiente. Este es un requisito real que se incluyó en la documentación que un cliente real aprobó para la creación de un sitio web de comercio electrónico personalizado.
Se implementarán y funcionarán todas las extensiones que existen en el sitio web actual de [VERSIÓN 1 DE LA PLATAFORMA DE COMERCIO ELECTRÓNICO NO DIVULGADA] en el nuevo sitio web de [VERSIÓN 2 DE LA PLATAFORMA DE COMERCIO ELECTRÓNICO NO DIVULGADA].
¡Dios mío! ¡La ambigüedad!
Aunque no voy a volver a escribir las múltiples páginas de documentación de requisitos técnicos y funcionales que la oración anterior realmente merece, sí voy a destacar algunas preguntas para desglosar el requisito y desafiar al autor a aclarar y documentar más detalladamente lo que significa exactamente.
¿Qué extensiones existen en la versión 1 actual de este sitio web?
Para cada extensión, quiero saber:
- ¿Cuál es su versión?
- ¿Quién es el creador/fuente/desarrollador?
- ¿Qué función o funcionalidad ofrece?
¿Son todas las extensiones capaces de ejecutarse en la versión 2 de esta plataforma?
Si es así, enumera cada extensión que es capaz de ejecutarse en la nueva plataforma.
Si no, enumera cada extensión que no es capaz de ejecutarse en la nueva plataforma, así como la solución de reemplazo, ya sea otra extensión que sea compatible con la nueva plataforma o una solución personalizada.
¿Hay un costo asociado con alguna de estas extensiones?
Para cada costo:
¿Es una licencia/costo de implementación único? ¿El costo se heredará de la licencia anterior o se necesita una nueva licencia?
¿Existen costos de suscripción?
¿El costo será el mismo si se ejecuta en una versión más nueva de la plataforma?
¿Se considerará que cualquier costo adicional es un cambio en el pedido?
Aunque tu equipo puede conocer muy bien las respuestas a todas las preguntas anteriores, saberlas no es suficiente. Esas respuestas deben documentarse a fondo. El DPM debe hacer esas preguntas y señalar esas lagunas para asegurarse de que se llenen esas lagunas.
Las preguntas anteriores fácilmente generan algunas páginas de requisitos, según la cantidad de extensiones aplicables a la construcción. Con este ejemplo en particular, se implementaron más de 100 extensiones en la versión actual 1 de la plataforma. Como puedes imaginar… el caos se desató. Dejaré el resto de esa historia a tu imaginación.
6 Técnicas de Recopilación de Requisitos de Vital Importancia
Es imperativo que tú, como DPM, te mantengas cerca de la documentación de requisitos. Después de todo, estos son documentos que puedes aprovechar para realizar verificaciones de salud del presupuesto, ofrecer recorridos a tu cliente antes de que proporcionen la aprobación, marcar elementos durante la fase de Control de Calidad (QA) del proyecto, utilizar como una guía para probar características y funcionalidades, y todo lo que conlleva.
Aquí tienes algunas técnicas para ayudarte a asegurarte de que estás realizando el importante trabajo de recopilación de requisitos de la mejor manera posible:
1. Comienza de Inmediato
La documentación de requisitos no debería esperar hasta que todas las discusiones de descubrimiento hayan ocurrido o hasta después de que se hayan creado los wireframes. La documentación de requisitos debe comenzar tan pronto como empiecen las conversaciones.
Funciona bien capturar toda la información y posteriormente reducirla. En lugar de eliminar información del documento, simplemente comienza a categorizarla en (A) lo que está incluido y (B) lo que no está incluido; de esta manera, evitas la típica suposición del cliente más adelante en el camino ("Juré que habíamos hablado de esto…"). Aquí es donde sacas tu documentación de requisitos en progreso (WIP, por sus siglas en inglés) y señalas dónde se capturó 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 capturó.
2. Utiliza Plantillas
Una vez que tengas algunos documentos de requisitos en tu haber, comienza a aprovecharlos y crear plantillas para su uso futuro en otros proyectos. Especialmente si te centras en el comercio electrónico, o en aplicaciones de catálogo, o en aplicaciones de aprendizaje… comenzarás a ver patrones de funcionalidad que surgen. Identifica dónde puedes reutilizar.
He incluido algunas plantillas de documentos de requisitos al final de este artículo.
3. El Trabajo en Equipo Hace que los Sueños Se Cumplan
Es altamente improbable que solo una persona elabore los requisitos del proyecto, aquí es donde entra la obtención de requisitos. Si hay diferentes tipos de recursos en un proyecto (por ejemplo, Diseñador de Experiencia de Usuario, Diseñador de Interfaz de Usuario, Ingeniero de Software, Desarrollador Frontend, Estratega Digital, Arquitecto de Contenidos, etc.), los requisitos para cada área de experiencia pueden ser redactados por los respectivos expertos.
¿Alguna vez has jugado al teléfono descompuesto? Por supuesto que sí. Cuando un DPM redacta documentación que se originó en la mente de un desarrollador (o de un estratega, o de un diseñador), corres el riesgo de que algo se pierda en la traducción. En muchos casos, la conversación sobre los requisitos es una serie de llamadas telefónicas, reuniones y conversaciones separadas, etc. Aquí es donde es crítico que tú, como DPM, asignes la documentación de requisitos a los miembros del equipo respectivos para obtener y compilar los requisitos.
Para ayudar a tu equipo con la obtención de requisitos, asegúrate de:
- proporcionar plantillas de documentación
- capturar y compartir tus notas
- organizar las conversaciones adecuadas
- facilitar reuniones y revisiones de planificación de documentación de requisitos
- dar los toques finales a la documentación
En el momento en que comiences a redactar los requisitos para tu documentación de requisitos, ya deberías haber tenido múltiples puntos de control relacionados con los requisitos, que incluyen:
- Reuniones con el cliente (donde se revisaron los diseños y al menos se aprobaron de manera informal)
- Notas compartidas (donde se capturaron decisiones, se revisaron tanto por el equipo interno como por el cliente, y se confirmaron como válidas)
- Revisión interna/entrega (donde se revisaron los diseños y se confirmaron los elementos de la página)
Dicho esto, asegúrate de aprovechar a los miembros de tu equipo según sea necesario para completar adecuadamente los requisitos.
4. No Solo Registres Requisitos, Aprende
Haz más que tomar notas. Espera más que recursos que te envíen un muro de texto que comprenda su parte de los requisitos. Tómate el tiempo para sentarte con tu equipo de desarrolladores y aprender las soluciones que el equipo tiene en mente para la implementación. Discute el por qué y el cómo. Haz preguntas.
Antes de decir, "Pero solo tenemos tanto tiempo en el día, ¿y qué pasa con el presupuesto?", comprende esto: si una solución en la que estás trabajando es aplicable a más de un proyecto, entonces este tiempo adicional para comprender no necesariamente debe ser facturable. Estás desarrollando tu experiencia en el tema que mejora directamente tu trabajo cotidiano.
5. Mantén a tu Cliente Informado
La documentación de requisitos no tiene que ser de Nivel 1 de Confidencialidad con un gran sello de Alto Secreto en la portada. Si no estás tratando con información sensible, puedes crear un documento de requisitos en curso compartido a través de un Documento de Google, con permisos habilitados para que el cliente pueda comentar.
Si estás tratando con información sensible, comparte una versión del documento de requisitos de manera semanal para proporcionar al cliente una instantánea de lo que se ha capturado. Después de todo, este es un documento que eventualmente tendrán que aprobar.
6. Supón que tu Cliente No Sabe Nada
En lugar de correr el riesgo de suponer que tu cliente sabe más de lo que sabe (luego de que eso te queme más adelante cuando realmente no sabía la diferencia entre "solución de complemento" y "solución personalizada"), asume que tu cliente no sabe nada. Define todo lo que puedas. ¿Cómo? Por cada anotación, pregúntate "¿Por qué?" cinco veces para asegurarte de la minuciosidad de cada requisito.
Aquí tienes un ejemplo de hacer la pregunta "¿Por qué?" cinco veces para definir tus requisitos:
Anotación para la Página de Registro:
La ubicación de la tienda del usuario debe ser una selección en el menú desplegable.
¿Por qué?
El campo de entrada de texto aumenta el riesgo de errores en la entrada del usuario. La selección del menú desplegable limita la cantidad de opciones que un usuario puede elegir.
¿Por qué?
Si hubiera un campo de entrada de texto, se podría ingresar "MINNEAPOLIS" como "MINNEAPOLIS" o "MPLS" o "Mini-manza" y los datos serían confusos. Esto no es bueno. Una selección del menú desplegable limita las opciones a las que el administrador ingresa en el panel de administración. Esta selección limitada es buena para la precisión.
¿Por qué?
El cliente quiere utilizar los datos del usuario para segmentar contenido en función de la ubicación del usuario.
¿Por qué?
Este cliente tiene contenido específico para la ubicación/región según los productos que ofrecen.
¿Por qué?
Porque NEGOCIOS.
Hacerte la pregunta "¿Por qué?" cinco veces para cada requisito también 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 aprendes (o te das cuenta de que necesitas aprender).
Algunos consejos de expertos: Cómo Escribir un Documento de Requisitos del Proyecto
1. Escribe los Requisitos para 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 es aplicable para elementos globales como los elementos del menú de navegación principal, cualquier cosa dentro de tu encabezado global y cualquier cosa dentro de tu pie de página. Una vez que hayas escrito los requisitos para estos elementos globales, no te preocupes por anotarlos en las otras páginas; solo anota elementos específicos de esas páginas.
2. Copia y Pega Funcionalidades Idénticas para Garantizar la Consistencia
Este es simplemente un consejo a tener en cuenta para tu cordura (y la de tu cliente). Verás esto más a menudo con elementos de página comunes como imágenes de héroe/banner, encabezados o iconos de "atrás"… entre una gran cantidad de funcionalidades repetidas en diferentes tipos de páginas (que no deben confundirse con elementos globales). Esto no es una estrategia de SEO de Google de la era moderna en la que tienes que preocuparte por repetir palabras o frases, y esto no es tu ensayo de inglés de noveno grado en el que tienes que hacer que la misma idea suene profunda reescribiéndola de seis maneras diferentes. Esto es documentación de requisitos.
3. Reconoce la Funcionalidad del Administrador y CMS (o la Falta de Ella)
Cuando estamos tan centrados en la funcionalidad de cada elemento de la página, es fácil pasar por alto la funcionalidad administrativa y/o de CMS. Si estás implementando una solución que ofrece funcionalidad administrativa y/o de CMS, asegúrate de incluirla como su propia columna en tus requisitos.
¿Qué piensas?
Cuanto más documentación de requisitos tengas, menos margen habrá para errores y suposiciones. El trabajo inicial te ahorrará dolores de cabeza más adelante. Los controles y equilibrios beneficiarán la comprensión mutua de tu equipo sobre el proyecto y las expectativas de tu cliente sobre el producto final.
Como en todas las áreas de experiencia: cuanto más lo hagas, más fácil será. La primera documentación de requisitos que escribí para la construcción completa de un sitio web me tomó aproximadamente 60 horas. Ahora me lleva alrededor de 15 horas hacer los requisitos para un sitio web de tamaño comparable. Y cada hora vale la pena. Tu cordura te lo agradecerá (eventualmente).