Clase 1.

¿Sabías que casi la mitad de los proyectos que fracasan han tenido una gestión de requisitos
deficiente? Impresionante, ¿no? De acuerdo con el estudio «Pulse of the Profession: Más allá de la
Agilidad», llega a 47 % los proyectos que, desafortunadamente, no llegan al éxito. La gestión de los
requisitos es la piedra angular del proyecto. Tener los requisitos claros, analizados, aprobados y
bien documentados, ciertamente, te ayudará a aumentar la probabilidad de éxito de tus proyectos.
(Música ambiental) Soy Teresa Rojas, consultora, mentora y directora de proyectos internacionales
y he ayudado a clientes de diferentes industrias a desarrollar una base sólida para gestionar los
requisitos de sus proyectos. Acompáñame en este curso de LinkedIn Learning y aprende por qué es
de alta relevancia contar con un proceso adecuado de identificación y gestión de requisitos.
¿Comenzamos?

Parte 2.

Gestionar los desafíos de los requisitos del proyecto parece una tarea muy sencilla, pero,
en general, no lo es. Aun cuando conoces el alcance inicial del proyecto, no siempre es el correcto
y, por lo general, tampoco está completo. En la mayoría de los casos, son necesidades de muy alto
nivel que se tienen que analizar para llegar al fondo del problema que hay que resolver. Voy a
compartir contigo algunos de los principales desafíos que he detectado durante mi experiencia
gestionando distintos projectos.

El alcance del proyecto es poco o no definido.

Cuando el objetivo no está claramente identificado, el equipo de trabajo se ve impactado y

la organización también; esto alimenta la incertidumbre y genera retrasos.

Problemas con los recursos asignados.

Lo más seguro es que la organización tenga varios proyectos en marcha y los recursos
tengan una disponibilidad limitada, y no contar con los recursos necesarios causa problemas, como
la falta de detalle en los requerimientos o los conflictos entre áreas que no se ponen de acuerdo en
un objetivo común.

No involucrar a los grupos de interés o expertos en tiempo y forma.

El no incluir a los grupos de interés en la definición de los requisitos es un error gravísimo,

ya que estos grupos tienen poder de decisión para continuar, parar o cancelar el proyecto.

La falta de atención a posibles cambios de mercado, de la industria o de regulaciones

internas y externas.

Hay ocasiones en que alguna norma o regulación de industria o gobierno es actualizada y,

si no te enteras, no tendrás la menor idea de cómo estos cambios pueden impactar tu proyecto.

La falta de entendimiento entre los equipos de trabajo.

La gestora o gestor del proyecto tiene que asegurarse que todos los involucrados estén
alineados y entiendan a detalle cuál es el objetivo del proyecto y el rol de cada uno. En ocasiones,
los equipos tienen diferentes puntos de vista e intereses o simplemente existe resistencia. Se
requiere de mucha negociación y empatía, además de asegurarte de contar con el apoyo de la alta
gerencia de todas las áreas involucradas.

Los cambios de presupuesto.

Los cambios en el entorno empresarial o en las prioridades de la organización o incluso una

recesión en el mercado pueden hacer que el presupuesto original se vea disminuido o transferido a
otros proyectos, lo que incurre en un impacto directo al proyecto. En realidad, aún no me ha
tocado presenciar que el presupuesto incremente.

La incapacidad de gestionar los cambios.

Alguien puede solicitar alguna funcionalidad o mejora que requiera de un esfuerzo

adicional o algún recurso especializado que no estaba considerado originalmente. Es común la
aparición de requisitos adicionales que pueden incluso llegar a comprometer el costo y el tiempo
del proyecto. Ahora ya conociste algunos de los desafíos de la gestión de los requisitos del
proyecto. ¿Añadirías algún otro desafío a la lista? Tenerlos bien presentes te ayudará a ajustar la
definición de los requisitos y a evitar tener grandes sorpresas en el desarrollo de tu proyecto.

Elaborar planes sólidos pero flexibles a la vez

Un plan de gestión de requisitos es un documento clave que describe cómo vas a analizar,
documentar y gestionar los requisitos dentro del proyecto. Este plan debe contener los siguientes
componentes:

 la descripción general del proyecto;

 el proceso de recopilación de requisitos;
 la definición de roles y responsabilidades;
 la selección de herramientas;
 la trazabilidad de requisitos;
 el control de cambios,
 así como la priorización de los requisitos.

Es crucial que el plan sea sólido para guiar a todos los involucrados hacia el objetivo
esperado, pero debe ser flexible a la vez. ¿Y por qué? Porque en la gestión de proyectos, al igual
que en todo lo demás en la vida, todo está en constante cambio. Así, dominar la planificación
flexible es muy importante para adaptarse a los cambios y garantizar el éxito del proyecto. Un buen
gerente de proyecto que no maneje los componentes del plan de requisitos que mencionamos
tendrá muchos problemas para administrar, monitorear y controlar los requisitos y será
complicado comunicar las necesidades y desviaciones a los grupos de interés tanto internos como
externos y le será muy difícil adaptarse a situaciones adversas. Cuanto más flexible es tu plan y tu
mentalidad en la gestión de los requisitos, mejor será tu resultado. Dominar la fase de planificación
mejora la eficiencia y los resultados del proyecto. También te permite tomar decisiones más
rápidas y efectivas, no solo en la fase de planeación de requisitos, sino durante toda la vida del
proyecto. Acuérdate, gestionar proyectos es como navegar; debes ajustar tu vela a cada momento
y nueva circunstancia o es probable que el proyecto se hunda.
 Cap II.

Proceso de recopilación de informaciones.

Identifica los estándares de la industria que utilizarás

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el

vídeo

¿Qué es lo que sucede cuando trabajamos en proyectos que son únicos, complejos y llenos
de incertidumbre?

Necesitamos recopilar una gran cantidad de información y debemos asegurarnos de que

nada se nos escape. Por lo tanto, ayuda mucho si el equipo de trabajo usa el mismo enfoque para
administrar los proyectos.

Los marcos de trabajo apoyan la ejecución y éxito de un proyecto y nos permiten reducir la
probabilidad de que se pierda información relevante o de que algo inesperado suceda en los
proyectos. Los diferentes estándares cambian de acuerdo al objetivo y cada uno puede utilizar
herramientas y procesos particulares dependiendo de lo requerido. He descubierto, tras mi
experiencia, que tener una forma estructurada para trabajar puede ayudar a reducir la confusión y
los errores; también evita un análisis equivocado, ahorra tiempo y mejora la colaboración del
equipo de trabajo. También llega a suceder que tu cliente te solicite el uso de un estándar
específico, por lo tanto, es importante conocer, qué estándares se utilizan en tu organización y en
el entorno de tu industria para definir cuál adoptar para administrar los requisitos del proyecto de
manera efectiva.

Estándares internacionales para la gestión de proyectos

Te presento una lista de algunos de los estándares internacionales más conocidos en el

mundo de la dirección y manejo de proyectos.

PMBoK.

PMBoK son las siglas en inglés del «Project Management Body of Knowledge». Es una guía
de buenas prácticas con reconocimiento internacional en cuanto a la gestión, administración y
dirección de proyectos.

Te puedes estar preguntando «¿Esta guía me va a garantizar la ejecución de un proyecto

perfecto?». La respuesta es no. Va a depender mucho del contexto en que se da el proyecto. Sin
embargo, gracias a esta guía es posible conocer todas las áreas a considerar y seleccionar aquellas
que tú creas que pueden ayudarte a planear el enfoque del proyecto, ya sea predictivo, ágil o
híbrido. Se puede adquirir una copia en el portal del Project Management Institute.

ISO 21500.

ISO son las siglas en inglés del International Standard Organization. Presenta las bases que
permiten medir la eficacia del sistema de dirección y gestión de proyectos de cualquier tipo de
empresa. El uso más común de este estándar se da en organizaciones que se rigen por acuerdos
internacionales, donde la dirección y manejo de proyectos es de alto nivel. Permite a las
organizaciones considerar aspectos críticos de su operación, como aumentar la calidad del
producto, sistema, proceso o servicio; promover el uso de un lenguaje común; ganar productividad
y eficacia; reforzar la evaluación y auditoría de proyectos, entre otros beneficios. Se puede conocer
más en el portal de ISO.

IEEE 29148-2018.

Es un estándar compartido entre las tres organizaciones Institute of Electrical and

Electronics Engineers, International Standards Organization y International Electrotechnical
Commission. Va dirigido a desarrolladores de software y a los que trabajan en la industria
electrónica. La guía expone los procesos del ciclo de vida, actividades y elementos necesarios para
la definición de requisitos. Si manejas proyectos ágiles, este estándar te puede interesar. Se puede
adquirir una copia en el portal de IEEE.

IPMA,

siglas del inglés International Project Management Association o Asociación Internacional

de Gerencia de Proyectos. Es considerada la primera confederación mundial de dirección de
proyectos desde 1965, con una participación de 72 naciones. En la perspectiva de IPMA, no basta
solo con conocer los procesos que componen un proyecto, sino tener las habilidades blandas o
«soft skills» para manejar la complejidad, la incertidumbre, la volatilidad, la empatía y la estrategia,
por mencionar solo algunas. Se puede conocer más en su portal.

¿Has considerado contemplar algunas de estas guías o estándares en tus proyectos?

El uso de metodologías con estándares internacionales brindan una serie de herramientas

y técnicas afines al fortalecimiento de la gestión de proyectos. Elegir un estándar internacional te
permitirá, indiscutiblemente, aumentar la eficacia y eficiencia en los proyectos que desarrolles.
Estos marcos de trabajo los puedes aplicar a cualquier tipo de proyecto o industria, lo que las hace
bastante adaptables a los requerimientos de los usuarios y te pueden apoyar a una mejor toma de
decisiones. Ten siempre en cuenta lo que dijo Woody Williams: «No importa qué tan bueno sea el
equipo de trabajo o qué tan eficaz sea el estándar usado. Si no estamos resolviendo el problema
correcto, el proyecto fracasará».
 Prepara el plan de la captura de requisitos

¿Alguna vez te ha tocado gestionar un proyecto con un volumen muy grande de detalles
técnicos?

Yo he podido sobrevivir a varios proyectos con estas características, utilizando un plan de

captura de requisitos. Primero te invito a conocer la definición de requisito.

Según el PMBoK, un requisito es una condición o capacidad que debe estar presente en un
producto, servicio o resultado para satisfacer una necesidad de negocio. La preparación del plan
para captura de requisitos forma parte de la documentación del alcance del proyecto. El objetivo
principal es asegurar la planificación de todas las actividades referentes a capturar los requisitos de
los grupos de interés y del negocio, para que posteriormente puedas saber cómo identificarlos,
analizarlos y priorizarlos correctamente. Uno de los enfoques que puedes utilizar se divide en
cuatro áreas; te las voy a comentar una a una.

Identificación: se refiere a qué método y herramientas vas a usar para la captura de los
requisitos.

Existen varias técnicas para capturar requisitos, como por ejemplo,

 tormentas de ideas,
 análisis de datos,
 documentación,
 prototipos,
 encuestas,
 observación estructurada del entorno;
 la más utilizada son las entrevistas.

Análisis: se trata de definir qué tipos de requisitos funcionales y no funcionales existen.

Conocer los tipos de requisitos te facilita determinar qué áreas del negocio debes integrar al
proyecto. También, qué criterios de medición y aceptación vas a utilizar. Debes considerar todas las
condiciones y capacidades que debe tener un producto, servicio, sistema o proceso como
requisitos.

Documentación: corresponde a documentar los requisitos que hayan sido identificados y

analizados. La documentación formal tiene por objetivo evitar malos entendidos sobre las
necesidades de los grupos de interés. Se extiende desde los requisitos de negocio, pasando por los
requisitos de usuario, requisitos de producto o sistema, para llegar a los requisitos funcionales y no
funcionales.

Gestión continua: conforme el proyecto avanza, se pueden presentar cambios o

actualizaciones, para lo cual el equipo de trabajo debe seguir el proceso de gestión del cambio que
conoceremos más adelante. Asimismo, este plan te servirá como evidencia para cuando inicies la
solicitud de cierre del proyecto. Al elaborar el plan de captura de los requisitos, debes redactarlo
de forma clara, medible y comunicable para que el equipo de trabajo esté alineado con las tareas a
realizar para cumplir con los objetivos de negocio planteados.
 Te presento dos técnicas que podrías considerar en tu plan de captura de requisitos,
dependiendo del tipo de proyecto que gestiones.

En proyectos más predictibles, con poca incertidumbre y requisitos más estables, como por
ejemplo, construir un edificio, un avión o un puente, se utiliza comúnmente el marco de trabajo en
Cascada o «Waterfall». Empiezas documentando los requisitos a un alto nivel, y vas detallando a
medida que conoces más sobre las necesidades de los grupos de interés. Es una metodología de
gestión secuencial con varias fases en separado, en que una sola empieza después de que se
concluye la anterior. Las tareas y actividades, por lo tanto, caen en cascada, una tras la otra.

En el caso de que trabajes en un proyecto donde la incertidumbre sea alta, a veces no

sabemos qué se quiere resolver y los cambios son frecuentes, por ejemplo, campañas de
mercadotecnia, desarrollo de software o portales digitales, lo mejor sería que utilices un marco de
trabajo adaptativo y ágil, que te permita documentar los requisitos de forma iterativa y continua,
incluyendo sesiones de feedback de cliente y usuarios. En la sección de ejercicios de este curso te
dejo dos plantillas para apoyar la captura de los requisitos, tanto en proyectos en cascada como
ágiles.

Contar con un plan de captura te servirá para gestionar los requisitos del proyecto con un
horizonte claro y definido. Si tienes bien documentado el plan, te será más sencillo seguir con los
próximos pasos para descubrir y entender cuáles son las necesidades de los grupos de interés.
 Identifica cuál es el deseo o la necesidad del cliente

Si seleccionas líneas de la transcripción en esta sección, irás a la marca de tiempo en el

vídeo

Si no conoces los deseos y necesidades de tu cliente, te tengo malas noticias. Estás en

serios problemas.

La satisfacción del cliente, en términos de valor, es la mejor medida del éxito.

Las necesidades de los clientes son los detonadores que los impulsan a la búsqueda de
soluciones a sus problemas. Por ejemplo, si necesitan cumplir con una recién aprobada regulación
de gobierno o alguna actualización de un estándar de industria o también si deben atender una
oportunidad o demanda de mercado.

Identificar los deseos o necesidades para satisfacer a un cliente es un proceso laborioso

que requiere de tu habilidad para escuchar y observar a detalle la reacción que tiene en cada
interacción con su entorno. Descubrir qué fue lo que motivó al cliente a iniciar un proyecto es
pieza clave para validar que cuentas con toda la información necesaria para satisfacer las
necesidades y resolver el problema con el proyecto que estás gestionando. Los clientes necesitan
la capacidad de ajustar las prioridades en función de muchos factores que pueden no estar
previstos al comienzo de un proyecto. Constantemente tienes que estar monitoreando y
evaluando si algo cambió. Existen varias técnicas que puedes utilizar para identificar las
necesidades de tu cliente, realizando, por ejemplo,

 entrevistas,
 grupos de foco,
 encuestas,
 observación in situ, entre otras.

Ahora, piensa en alguno de los proyectos que estás gestionando actualmente o que estás a
punto de empezar. ¿Tienes claras las necesidades o deseos más críticos de tus clientes? Te invito a
identificar aquellos grupos específicos cuya satisfacción es clave para el éxito de tu proyecto, a
acercarte a tus clientes y a comenzar a trabajar en entender sus necesidades en detalle. Si te
resulta difícil, puede ser necesario invertir un poco más de tiempo en aplicar una de las técnicas de
recopilación de requisitos mencionadas con anterioridad. Estoy segura que será de gran ayuda
para alinear sus necesidades lo más temprano posible con el desarrollo de las actividades de tu
proyecto.
 ¿Quiénes son los «stakeholders»?

En el mundo empresarial los stakeholders o grupos de interés son aquellas personas o

entidades que tienen algún interés e impacto en un proyecto. Así que identificar y reconocer los
stakeholders de nuestros proyectos, nos permite comprender quiénes se verán afectados de forma
positiva o negativa por el resultado del mismo. Y hacerlo bien, puede ayudar a asegurar que los
proyectos sean más exitosos.

Los stakeholders llamados internos son aquellos que se ven directamente afectados por los
resultados del proyecto. En general, son parte de la organización, como por ejemplo, los
empleados, los líderes de diferentes unidades de negocio, los directivos y accionistas de la
organización. En mi experiencia algunos de los proyectos más difíciles que he gestionado, han
tenido un gran impacto en los empleados por ser proyectos de cambio en implementación de
sistemas, automatización de procesos, reestructuraciones internas, cambio de marca o
cumplimiento de auditorías.

Los stakeholders externos son las personas o entidades que no son parte de la
organización, pero están de alguna forma involucrados o tienen un interés en el proyecto. A
menudo, esas personas no participan en las actividades del día a día del proyecto, pero sus
acciones pueden, eventualmente, influir en el resultado, como por ejemplo, los proveedores, las
instituciones gubernamentales y financieras, los consumidores, las comunidades y entidades
regulatorias.

A los stakeholders clave se les debe preguntar acerca de las expectativas de los resultados
del proyecto, al final su satisfacción es el máximo criterio del éxito, y si el proyecto entrega los
beneficios esperados a los stakeholders clave, se considerará exitoso.

El mapa de stakeholders es una herramienta que se puede utilizar para manejar la relación
con los diferentes grupos y entender mejor qué interés tiene cada uno de ellos en el proyecto. En
este mapa, se puede colocar la lista de los grupos de interés, si son defensores u oponentes del
proyecto, así como determinar en una escala del 1 al 10 qué influencia e impacto pueden llegar a
tener en el proyecto.

Te dejo en los archivos de ejercicio del curso un ejemplo de cómo puedes mapear tus
stakeholders para que puedas empezar a hacerlo de forma estructurada para tus proyectos.
Siempre será aconsejable practicar la empatía cuando nos relacionamos con los stakeholders de
los proyectos. Debemos ponernos en sus zapatos para entender el contexto en el cual trabajan, ya
que tienen el poder para favorecer la oportunidad de alcanzar el éxito o la capacidad de parar un
proyecto o rechazarlo definitivamente. Recuerda que todas las personas afectadas por tu proyecto
son considerados stakeholders. Seguramente, no podrás hacer todo lo que ellos quieran por lo que
puede ser de gran ayuda si te indican qué es lo más importante para ellos y qué cosas son
opcionales. Como te darás cuenta, una identificación correcta y a tiempo de los stakeholders te va
a ayudar a no solo evitar conflictos futuros, también a desarrollar un plan de comunicación que los
mantenga bien informados y comprometidos conforme avanza el proyecto.
 Requisitos funcionales y no funcionales del proyecto

Recopilar los requisitos del proyecto es todo un reto. Es un proceso analítico y colaborativo
con actividades para descubrir y definir las necesidades, deseos y aspiraciones de los grupos de
interés.

Los requisitos pueden ser de varios tipos, por ejemplo,

 requisitos del negocio,

 de los grupos de interés,
 del producto,
 del sistema,
 servicio o proceso de transformación.

Y todos ellos se pueden agrupar en dos principales categorías: funcionales y no

funcionales.

Los requisitos funcionales definen lo que el producto o el sistema debe hacer. En el caso
del portal de una empresa e-commerce, por ejemplo, los requisitos funcionales serían todas las
acciones requeridas del sistema, tal como permitir a los usuarios iniciar sesión en su cuenta
introduciendo su correo electrónico y contraseña, enviar un correo electrónico de confirmación
cada vez que se realiza un pedido, permitir al usuario enviar comentarios a través de un formulario
de contacto en el portal. A su vez, los requisitos no funcionales definen cómo el producto o
sistema debería ser. Continuando con el caso de la empresa de e-commerce, un requisito no
funcional impone una restricción sobre cómo debe hacer una acción el sistema en cuanto a
seguridad, facilidad de uso, desempeño, rendimiento, escalabilidad, portabilidad, entre otros.

Por ejemplo, cuando el usuario presente sus credenciales, pero su información está
equivocada, debe aparecer el mensaje de introducir una dirección de correo o una contraseña
válidos.

Cuando se confirme el pedido, la pantalla con información del número de pedido debe
cargarse en 5 segundos. Cuando se presiona el botón de envío, la pantalla de confirmación debe
cargarse en 2 segundos. Debemos reunir una gran cantidad de información para conocer el
contexto y el entorno de las personas de interés; este proceso puede durar un par de semanas y en
ese tiempo recopilamos mucha información.
 Técnicas para identificar y recopilar los requisitos

Existen múltiples técnicas para descubrir las necesidades de los grupos de interés. Pueden
ser activas, con interacción entre los grupos de interés, o pasivas, donde descubres la información
por cuenta propia.

Es muy probable que llegues a utilizar más de una técnica para profundizar en lo que
necesitan los grupos de interés. Te darás cuenta que algunas técnicas facilitarán la dinámica de
recopilar la información que buscas para el proyecto.

Hablemos de algunas de las técnicas que te pueden ayudar a descubrir las necesidades de
tus grupos de interés y, como consecuencia, definir los requisitos de tu proyecto.

Entrevistas o grupos de foco. Son actividades colaborativas con el propósito de reunirse

con el usuario, ya sea individualmente o en grupos pequeños, para preguntarles directamente y
conocer sus inquietudes y necesidades y compilar información relevante. Tu objetivo aquí es
escuchar, así que hazlo activamente. Son útiles cuando se han identificado a los usuarios más
representativos de un grupo de interés y que, además, tienes disponibilidad de tiempo limitada.

Reuniones de tormenta de ideas. Es una técnica que permite reunir a un determinado

número de personas para generar nuevas ideas en un ambiente libre de críticas y juicios, donde
se conocen puntos de vistas diferentes y pueden encontrar soluciones originales e innovadoras.

Análisis de datos y documentación. Se revisa la documentación existente, como, por

ejemplo, manuales, el acta de constitución de un proyecto o contrato, reportes anuales,
estadísticas, entre otros. Todo lo que te apoye en entender el contexto del proyecto.

Prototipos. Esta técnica se usa mucho en los proyectos ágiles. Un prototipo es un modelo
básico o una simulación de un producto final que se elabora muy fácilmente, ya que puedes utilizar
desde un lápiz y papel hasta plastilina o piezas de Legos para así crear un modelo sencillo que te
permite evaluar la viabilidad de un proyecto. Se utiliza para obtener una retroalimentación
temprana por parte de los grupos de interés.

Encuestas y cuestionarios. Con esta técnica, se puede recopilar información de manera

rápida e informal de muchas personas, utilizando preguntas cerradas y abiertas.

Observación estructurada del entorno. Es una de mis predilectas, ya que permite a la

persona que observa darse cuenta de lo que sucede, por ejemplo, en el lugar de trabajo de las
personas, conocer cómo trabajan, cómo interactúan con sus pares, qué herramientas usan o cuáles
son los retos que enfrentan. La información que se obtiene es valiosa para documentar la situación
actual. Si decides utilizar esta técnica, es importantísimo que pactes con anticipación el día y la
hora de visita para reservar la disponibilidad de las personas que requieres. Te recomiendo
elaborar una agenda y lista de las áreas y los nombres de las personas, así como indicar la duración
de esta actividad. Los usuarios siempre te van a hablar desde su perspectiva; es tu labor como
gerente de proyectos recolectar toda la información relevante, analizarla y definir los requisitos del
proyecto. ¿Has utilizado alguna de estas técnicas? Te invito a contarme en la sección de preguntas
de este curso cuáles de ellas ya te han ayudado a definir de manera exitosa los requisitos de tus
proyectos.
 Analizar los requisitos

¿Te gustan los rompecabezas? A mí me encantan.

Desde mi punto de vista, existe una semejanza entre cómo funciona el armado de un
rompecabezas y la elaboración del plan de requisitos para el proyecto. Constantemente estoy en
busca de todas las piezas que me ayuden a cumplir con las necesidades de los grupos de interés y
terminar con éxito el proyecto.

¿Me ayudas a armar el rompecabezas? En la recopilación de requisitos del proyecto, ya

has identificado las piezas del rompecabezas, entonces, ahora es tiempo de armarlo.

El proceso de analizar los requisitos está enfocado en ampliar el entendimiento actual de

la información, integrar y mejorarla. La información descubierta con la recopilación de requisitos
del negocio y las necesidades de los grupos de interés son los insumos que alimentan el análisis.

En el proceso de análisis de los requisitos es importante asociar información adicional

sobre ellos; es lo que llamamos los atributos de los requisitos. Te presento los diez atributos más
recomendados en la Guía del conjunto de conocimientos de análisis del negocio, BaBok por sus
siglas en inglés.

Son los siguientes:

referencia absoluta. Es la identificación numérica y alfanumérica única para no perder de

vista el requisito.

Autor o autora del requisito. Es la persona que registró el requisito, que, en caso de dudas,
puede ser consultada.

Complejidad. Indica la estimación de qué tan difícil será implementar este requisito.

Propiedad. Se refiere a la persona o grupos de personas que son los dueños o dueñas del
requisito.

Prioridad. Indica el orden en que serán atendidos los requisitos.

Riesgos. Indica el nivel de riesgo potencial en que se puede incurrir por atender o no el
requisito.

Fuente de requerimiento. Se refiere al detalle de dónde surgió el requerimiento.

Estabilidad. Se usa para indicar si el requisito está completo y listo para implementarse o
aún hay que conseguir más detalles.

Estado. Indica en qué parte del proceso de análisis se encuentra el requisito. Por ejemplo,
nuevo, en proceso, borrador, aprobado, desarrollado, verificado, diferido, eliminado o rechazado.

Urgencia. Se refiere a la rapidez con que se requiere el requisito.

En la sección de ejercicios del curso te dejo una plantilla de apoyo. Mientras estés en el
proceso de análisis de los requisitos de tu proyecto, puedes darte cuenta de que no es necesario
identificar todos los diez atributos que te presenté, eso dependerá del tamaño y complejidad del
proyecto. Para armar un rompecabezas, comienzas por identificar las piezas y agruparlas según su
forma y color; así te darás cuenta si están todas las piezas disponibles o si algo te hace falta. De
igual forma, los atributos que selecciones te pueden ayudar a organizar y gestionar los
requerimientos de tu proyecto. Lo más importante es asegurarte que estás cumpliendo con las
necesidades de los grupos de interés. Recuerda que solo puedes completar el rompecabezas una
pieza a la vez. Hay que estar atentos durante este proceso porque, en ocasiones, es posible que
nos puedan faltar algunas piezas del rompecabezas y es responsabilidad del gestor o la gestora de
proyectos identificar todas las piezas. Se necesita tiempo para armar un rompecabezas. Lo mismo
sucede con el análisis de requisitos. No debes apresurarte, date el tiempo para determinar si en tu
proyecto cuentas con todas las piezas que necesitas.

Priorizar los requisitos del proyecto

¿Por qué es importante que se prioricen los requisitos del proyecto?

La priorización de los requisitos está enfocada a maximizar el valor entregado por el

proyecto y establece un orden en modo jerárquico, haciendo que los requisitos más importantes
sean tratados primero. Es una actividad que está bajo la responsabilidad de quien gestiona el
proyecto, donde, a veces, también participa el analista de requisitos para facilitar el proceso
cuando se trata de proyectos muy grandes.

El cliente o los grupos de interés definen qué es lo más importante. El gerente del
proyecto, junto con ellos, tiene autoridad para hacerlo y te equivocas si piensas que la priorización
de requisitos se hace solo una vez al inicio del proyecto; tanto los requisitos como las prioridades
pueden cambiar a lo largo del proyecto. Este es un proceso continuo que va de la mano de la
gestión del cambio de requisitos. Vas a descubrir que existen varios desafíos para priorizar los
requisitos y, en realidad, estos desafíos no están relacionados con la definición de la técnica a
utilizar, sino en la toma de decisiones, ya que al tomar una decisión, se está dejando algo atrás.

Otro de los desafíos es que los clientes o grupos de interés pedirán todo si no hay algo que
los convenza de lo contrario. Buscarán la forma de definir todos los requisitos con alta prioridad.

Esta situación sucede cuando existen diferentes perspectivas, por ejemplo, algunos se
centrarán por definir facilidad de uso y velocidad, otros en la seguridad, otros en la experiencia de
usuario y, en realidad, no toman en cuenta la necesidad de priorizar un requisito sobre otro.

Para priorizar, es importante que te hagas las siguientes preguntas:

¿cómo lograr acuerdos entre los diferentes grupos de interés? Conocer la importancia de
cada uno y sus necesidades es clave.

¿Cómo garantizar que los requisitos tengan un reparto equitativo de las prioridades? Como
regla general, un tercio de los requisitos debe ser alta, un tercio, media y un tercio, baja prioridad.
 Veamos algunas técnicas de priorización de requisitos.

Timeboxing. En la técnica timeboxing, definimos la prioridad en base a la cantidad de

esfuerzo que un equipo de trabajo puede realizar en un periodo de tiempo determinado y
restringido.

Budgeting. La técnica de budgeting o presupuesto la podemos utilizar cuando ha sido

asignada una cantidad limitada de dinero para realizar el requisito. Estas técnicas se utilizan mucho
en los proyectos ágiles.

Votación. Como el nombre lo indica, las prioridades son definidas por medio de votos de
las personas involucradas. Es una de las técnicas más simples de calificación numérica y la
podemos utilizar cuando hay demasiados requisitos que deben priorizarse.

Los distintos grupos de interés cuentan con 10 puntos, siendo la escala baja prioridad, 1, a
alta prioridad, 10.

MoSCOW. Esta técnica consiste en calificar los requisitos como Must, Should, Could o
Would. De ahí viene la abreviatura. Must - Mandatorio. Should - Alta prioridad. Could - Podría
hacerse, pero no es necesario. Would - Puede ser diferido para otra fase del proyecto.

En mi experiencia, la técnica que me ha dado los mejores resultados es la MoSCOW, ya que

es una técnica más completa que permite agrupar los requisitos según la importancia y las reglas
proporcionan la base sobre la cual puedes tomar decisiones con respecto a todo el proyecto;
además, ayuda al gestor o gestora del proyecto a evitar conflictos innecesarios, ya que sería
evidente para los grupos de interés la razón por la cual el equipo de trabajo está desarrollando
unos requisitos primero y los demás después. Y tú, ¿qué técnica de priorización de requisitos has
utilizado para darle mejor panorama a tus proyectos?
 Elaborar casos de uso

Los requisitos del proyecto describen lo que los grupos interesados quieren que haga una
solución, pero, generalmente, no brindan el contexto que necesitas para desarrollar buenas
soluciones. Puedes resolver este problema utilizando los requisitos recopilados para crear casos de
uso.

Un caso de uso cuenta la historia de cómo deben funcionar las soluciones una vez que se
terminen. Proporciona una explicación paso a paso de un proceso y lo que todos los involucrados
deben hacer en el camino. Un solo caso de uso podría proporcionar el contexto para admitir
muchos requisitos diferentes. Antes de crear casos de uso para tu proyecto, hay un par de
términos clave que debes conocer.

Las personas y los sistemas que se incluyen en un caso de uso se denominan actores y los
pasos se denominan acciones o Eventos. Evita crear casos de uso muy pequeños o muy grandes; la
razón es que ninguno representará el flujo completo de las acciones.

Ahora, armemos un caso de uso para la compra de un café en una cafetería llamada Star
Coffee. Este caso de uso tiene varios actores, como el cliente, el cajero y el barista, y dado que los
pedidos deben ingresarse en un sistema, el sistema también es un actor. Ahora, ¿cuáles son los
pasos que ocurren en el proceso? El cajero toma el pedido del cliente y lo ingresa en el sistema, a
continuación, el cliente paga al cajero. Cada uno de esos pasos es una acción o evento. Luego, el
sistema transmite la orden al barista, el barista prepara el café y lo entrega al cliente.

Este es un caso de uso sencillo. Muchas veces, la forma más fácil de comunicar un caso de
uso es escribirlo. También puedes documentarlo mediante diagramas. La forma de escribir y
comunicar el caso de uso se adecúa al tipo y complejidad del proyecto. La utilización de los casos
de uso facilita la comprensión entre todos los involucrados en llevar el proyecto. En el ejemplo que
hablamos, el caso de uso ayuda a que los desarrolladores, cliente y usuario final entiendan mejor
sobre lo que el sistema de la cafetería debe hacer. Los casos de uso te ayudarán a ti y a los grupos
de interés de tu proyecto a entender mejor los requisitos. Te recomiendo incluirlos en tus
proyectos, en especial para los proyectos de desarrollo de software. Te aseguro que te facilitará el
trabajo con el equipo del proyecto y traerá más claridad para llegar a la solución que se espera.
 Priorizar los casos de uso

Ten por seguro una cosa, siempre habrá innumerables actividades que hacer en todos los
proyectos, pero nunca alcanzará ni el tiempo ni el dinero para hacerlo todo.

Y por mucho que los grupos de interés odien elegir entre cosas que parezcan igual de
críticas para el proyecto, si todo es prioritario, nada lo es. La priorización de los casos de uso
sucede una vez que ya contamos con la captura, análisis y priorización de requisitos, además de la
elaboración de los casos de uso.

Te preguntarás qué es lo que hay que considerar para que unos casos de uso se desarrollen
primero y otros tengan que esperar; te lo voy a explicar. Primero, debes definir junto con el equipo
de trabajo los criterios que utilizarás para calificar cada uno de los casos de uso y la escala que
van a usar, por ejemplo, del 1 al 5. Algunos ejemplos de estos criterios pueden ser: la
disponibilidad de fuentes de información, como accesibilidad a los datos.

El valor comercial y estratégico, como mejorar el servicio al cliente y la participación en el

mercado.

El impacto económico, como los impactos a los ingresos y egresos de la organización.

La viabilidad técnica, como la infraestructura tecnológica.

El riesgo de implementación, como cuándo es positivo en términos de oportunidades. Por

ejemplo, ayuda a incorporar nuevos métodos y herramientas que permitan a la organización ser
más eficiente. O como cuándo es negativo, en términos de amenazas, por ejemplo, impacto en la
reputación de la empresa. Si uno o varios casos de uso no cumplen con la mayoría de los criterios
previamente acordados, este quedará fuera de la lista y será colocado en la lista de diferidos hasta
que cumpla con los criterios definidos.

Si has tenido problemas al tratar de seleccionar qué casos de uso cumplen con los criterios
para ser priorizados y no quieres que vuelva a pasar en tu próximo proyecto, puedes
buscar criterios diferentes que te ayuden a avanzar de forma más eficiente. Un ejemplo
más sería sustentabilidad. Se refiere al impacto mínimo o nulo en las condiciones
ambientales, sociales y económicas. Es importante que te asegures de utilizar una lista de
criterios como la planteada aquí, enfocada en asegurar que se cumplan con los objetivos
estratégicos del proyecto en cuanto a valor y beneficios esperados. Lo que sí es muy claro
es que priorizar es una tarea difícil y que genera desacuerdos. Por lo mismo, asegúrate de
involucrar a las personas de interés desde un inicio para definir en conjunto y de forma
clara los criterios que consideren más relevantes para priorizar los casos de uso. Te
ahorrará tiempo, dinero y algunos dolores de cabeza.
Documentar los requisitos del proyecto

Para gestionar y organizar la documentación de los requisitos, los gestores y gestoras de

proyecto utilizan el documento de requisitos de proyecto.

Este documento plantea toda la información referente a los problemas que el proyecto
pretende resolver y describe los resultados esperados en cuanto a la entrega de valor y
beneficios para la organización. No todos los documentos de requisitos de proyecto son
iguales, todo depende del tamaño de la empresa, industria y el alcance del proyecto.

Algunos pueden ser documentos muy largos y formales y, en otras ocasiones, solo un par
de páginas que incluya la información más relevante del proyecto.

La documentación de requisitos es como una historia detallada que explica qué va a hacer
nuestro proyecto y por qué es importante. Y cuenta con muchos de los aspectos que ya
hemos comentado en el curso: resumen ejecutivo; objetivos, antecedentes y alcance del
proyecto; grupos de interés; limitantes, como tiempo, presupuesto, fechas; requisitos
funcionales; requisitos no funcionales; casos de uso y riesgos.

El documento de requisitos del proyecto lo puedes almacenar en el repositorio de

información del proyecto, donde el equipo pueda revisarlos, validarlos y darles prioridad
en base a los objetivos de negocio definidos.

Documentar los requisitos del proyecto es un paso clave que garantiza que todos los
grupos de interés y el equipo de trabajo comprendan y compartan la importancia de
cumplir con ellos.

Como gestor o gestora de proyecto, es fundamental que documentes adecuadamente

todos los requisitos necesarios del proyecto. Se entiende que existen momentos de gran
tensión por cambios o conflictos, en donde hay veces que dejamos de documentar y
decidimos que no es relevante para el avance del proyecto. Te puedo compartir que, si no
se hace en ese momento, difícilmente se presentará otra oportunidad para hacerlo.
Puedes bajar desde los archivos de ejercicios del curso un documento de referencia para
apoyarte en la documentación de los requisitos. Te invito a hacer un esfuerzo para
mantener la documentación del proyecto siempre actualizada, completa y disponible. Te
aseguro que valdrá la pena.
Proceso de aprobación de requisitos

¿Qué debemos tener en cuenta para formalizar la aprobación de los requisitos?

Una vez que cuentas con la documentación de los requisitos del proyecto, es momento de
pasar al proceso de aprobación.

Como gestor o gestora del proyecto, necesitas la autorización de los grupos de interés, que
analizarán y evaluarán los requisitos documentados para asegurarse que satisfacen las
necesidades de los usuarios finales.

La buena comunicación e involucramiento temprano de todos los participantes en las

fases de recopilación, análisis y gestión te facilitará obtener la aprobación de los requisitos.

Existen distintas formas de solicitar la aprobación. Si es un proyecto interno, seguramente,

solo necesitarás un correo electrónico de los grupos de interés. En el caso de ser un
proyecto con clientes, la aprobación tendrá que ser más formal, por medio de una reunión,
para firmar los documentos por duplicado.

También, en ocasiones, las aprobaciones se pueden dar por módulos o fases del proyecto.
El proceso es muy sencillo.

Primero se elabora el documento de requisitos; luego se revisa el documento; si se

necesitan cambios, se vuelve al paso 1 para redefinir requisitos y prioridades, y, por último,
se aprueba o rechaza o mismo se aprueba con cambios mínimos.

Antes de que solicites la aprobación de los requisitos del proyecto, es importante que
tengas una conversación previa con los grupos de interés. Puedes reservar tiempo en la
agenda de algunas de las sesiones de priorización para que definas junto con ellos los
criterios de aceptación y te posiciones un paso adelante en este proceso tan importante en
tu proyecto; de esa forma, será más fácil que obtengas el consentimiento y no te
encuentres con grandes sorpresas en este momento. Los grupos de interés y los expertos
en la materia son personas muy demandadas y extremadamente ocupadas, por lo que un
buen gerente de proyecto siempre puede adelantar y reservar tiempo en las agendas si
actúa con proactividad.

El proceso de aprobación de requisitos significa mucho más que solo llegar a un convenio o
crear un pacto. Si este proceso lo haces de manera correcta, significa que los grupos de
interés y expertos están alineados con la documentación de los requisitos y el equipo de
trabajo tiene el banderazo para iniciar con las actividades del proyecto. ¿A qué desafíos te
has enfrentado en el proceso de aprobación de los requisitos? Cuéntame en la sección de
preguntas del curso, me va a gustar leerlo e intercambiar soluciones.
Gestión del cambio de requisitos

¿Alguna vez has gestionado un proyecto donde nada cambió?

Yo tampoco, así que ¿por qué sorprenderse cuando hay cambios en los requisitos? El
cambio no solo es esperado; como es una constante en la gestión de proyectos, son tan
inevitables como el clima y los impuestos.

Algunas de estas cosas que pueden detonar el cambio son: el entorno empresarial, ajuste
de prioridades, ajuste de presupuestos o falta de recursos, entre otros.

Sería ideal que la mayoría de los cambios sucedieran al inicio del proyecto, no durante la
ejecución o mantenimiento, pero hay un detalle a considerar: al inicio es cuando menos
información se tiene sobre lo que se pretende hacer, entonces, es de esperarse que
surgirán cambios conforme se vayan aclarando los supuestos y mitigando los riesgos.

También es importante considerar que los cambios al inicio serán mucho menos costosos y
de bajo riesgo, a diferencia de cuando ya se están ejecutando las tareas y hay que cambiar
de dirección. El costo, en este momento, será mucho mayor y de un riesgo más alto. Te
había planteado que, para definir el alcance del proyecto, debes comenzar con un buen
volumen de requisitos, pero incluso después de que hayan sido aprobados, estos requisitos
pueden cambiar.

Podría ser que no consideraste algunas necesidades durante el proceso de recopilación o

podrías haber descubierto algo una vez que empezaste a ejecutar el proyecto o, mismo, el
negocio o el entorno empresarial podría haber cambiado y debes evaluar detenidamente
para decidir si se acepta el cambio o no.

Es muy importante realizar los cambios utilizando una solicitud formal. En esa solicitud
debe venir muy bien explicado los siguientes puntos:

 el número de identificación del cambio,

 la fecha de solicitud,
 la persona que lo solicita,
 el propósito del cambio,
 el impacto,
 lo que se requiere para realizarlo,
 el valor o beneficio de ese cambio,
 la persona o equipo que revisa,
 la persona que aprueba y la fecha de aprobación.

Todos los gerentes de proyectos estamos expuestos a que durante el ciclo de vida del
proyecto el alcance comience a tener una magnitud distinta a la esperada. En mi
experiencia, un proyecto comienza con una necesidad específica de algún usuario en
particular, pero a medida que se tiene las sesiones de trabajo con los grupos de interés, los
requisitos ya no están solamente relacionados con el alcance inicial; comienzas a descubrir
que hay tintes más allá de lo que originalmente se aprobó. Entonces es cuando un
proyecto se podría considerar fuera de los objetivos iniciales. A esto se le conoce como
corrupción de alcance. Hay que estar siempre alerta para evitar esta situación, ya que
podría impactar al proyecto en tiempo y costo, inclusive llegar a fracasar si no se detecta a
tiempo. Si el cliente cambia de enfoque, tú también tienes que cambiar. El cambio no es
tan malo siempre y cuando sea gestionado de forma correcta y bien documentada.

Hay que tomarlo con una actitud positiva, una mente abierta e innovadora que, al fin de
cuentas, puede llegar a ser una forma distinta de entregar mayor valor o beneficios al
cliente. Cada vez que se presenta un cambio en lo profesional o personal, siempre tengo
presente la frase de Rob Dial que dice: «Nunca tengas miedo al cambio; puedes perder
algo bueno, pero puedes ganar algo mejor».