Gestión de re­qui­si­tos: clave del éxito de los proyectos in­fo­r­má­ti­cos

Ya se ha cerrado el pre­su­pue­s­to, se ha definido el objetivo y los plazos están claros: llegados a este punto, las empresas suelen apre­su­rar­se a poner en marcha el proyecto en lugar de recabar in­fo­r­ma­ción acerca de los re­qui­si­tos concretos de todas las partes in­te­re­sa­das en el producto final. Como resultado, muchos proyectos de software fracasan. Se trata de una pérdida de tiempo y de pre­su­pue­s­to que puede evitarse con una gestión es­tru­c­tu­ra­da de los re­qui­si­tos.

La gestión de re­qui­si­tos o re­qui­re­me­nts ma­na­ge­me­nt es un co­m­po­ne­n­te integral de la gestión de proyectos te­c­no­ló­gi­cos cuyo objetivo consiste en ga­ra­n­ti­zar que el producto final se ajusta a lo que desean tanto los clientes, como los sta­keho­l­de­rs, sean estos internos o externos.

Este proceso incluye la de­fi­ni­ción (análisis, do­cu­me­n­ta­ción y va­li­da­ción de re­qui­si­tos) y la ad­mi­ni­s­tra­ción de los re­qui­si­tos (ad­mi­ni­s­tra­ción de riesgos, de cambios y de im­ple­me­n­ta­ción). No se trata, por lo tanto, de una tarea sencilla que se realice una única vez al comienzo del proyecto, sino de un ciclo de procesos re­cu­rre­n­tes a lo largo de todo el de­sa­rro­llo. Un ingeniero de re­que­ri­mie­n­tos es la persona re­s­po­n­sa­ble de su­pe­r­vi­sar la im­ple­me­n­ta­ción y la in­te­gra­ción de estos re­qui­si­tos, así como de los posibles cambios que puedan surgir a lo largo del proyecto.

En el sector de la te­c­no­lo­gía y las TIC, la gestión de re­qui­si­tos está más co­n­so­li­da­da que en otros sectores. En los proyectos in­fo­r­má­ti­cos debe es­pe­ci­fi­car­se desde el principio qué debe poder hacer el software en cuestión y qué procesos debe llevar a cabo, de lo contrario, es cuestión de tiempo que surjan co­m­pli­ca­cio­nes. Sin dichas es­pe­ci­fi­ca­cio­nes, el tiempo y los recursos no pueden pla­ni­fi­car­se de manera realista y es muy probable que los clientes empiecen a solicitar cambios que requieran un ala­r­ga­mie­n­to de los plazos y que quizás el pre­su­pue­s­to no cubra. Si dichos cambios, a su vez, no se gestionan como deberían, los costes seguirán au­me­n­ta­n­do, y así su­ce­si­va­me­n­te.

La gestión de re­qui­si­tos, sin embargo, es un elemento clave en cualquier sector. Es­pe­cia­l­me­n­te en proyectos extensos y productos complejos, la in­ge­nie­ría de re­qui­si­tos se encarga de asegurar una gran efi­cie­n­cia a lo largo de todo el proyecto y de evitar fallos o in­co­n­grue­n­cias entre las partes im­pli­ca­das. Un ingeniero o ingeniera de re­qui­si­tos puede reconocer pre­co­z­me­n­te cambios en los deseos del cliente y definir medidas para atenuar sus posibles efectos negativos.

Si bien la de­s­cri­p­ción de los re­qui­si­tos puede suponer un esfuerzo para el cliente al inicio del proyecto, los frutos de im­ple­me­n­tar una gestión de re­qui­si­tos es­tru­c­tu­ra­da se reflejan luego en su sa­ti­s­fa­c­ción.

• Mayor efi­cie­n­cia
• Menos so­li­ci­tu­des de cambios durante el de­sa­rro­llo del proyecto
• Menos errores e in­co­n­grue­n­cias
• Detección temprana de problemas y de la necesidad de hacer cambios
• Costes más bajos al evitar los fallos
• Fi­na­li­za­ción del proyecto a tiempo y de acuerdo con el pre­su­pue­s­to inicial
• Clientes más sa­ti­s­fe­chos

Algunas de las tareas más im­po­r­ta­n­tes que abarca la gestión de re­qui­si­tos son la re­co­pi­la­ción, la do­cu­me­n­ta­ción y el análisis de los re­que­ri­mie­n­tos, así como la gestión de cambios a lo largo del proyecto.

El primer paso es recopilar las es­pe­ci­fi­ca­cio­nes de todas las partes in­te­re­sa­das. El ingeniero o ingeniera de re­qui­si­tos dispone de di­fe­re­n­tes métodos para ide­n­ti­fi­car los deseos y ne­ce­si­da­des de los sta­keho­l­de­rs y clientes y crear a partir de ellos la do­cu­me­n­ta­ción de los re­qui­si­tos.

• En­tre­vi­s­tas: puede llevar a cabo en­tre­vi­s­tas con los sta­keho­l­de­rs, ya sea en persona o por teléfono.
• Cue­s­tio­na­rios: también se puede hacer una encuesta por escrito para recabar los re­qui­si­tos de forma más es­tru­c­tu­ra­da. Este método permite recopilar las re­s­pue­s­tas de un mayor número de personas.
• Workshops o talleres: las partes in­te­re­sa­das pueden ser invitadas, por ejemplo, a pa­r­ti­ci­par en talleres creativos en los que se favorezca la detección de ciertos aspectos del proyecto que quizá no surgirían con una mera lluvia de ideas.
• Ob­se­r­va­cio­nes del contexto de apli­ca­ción: puede observar cómo trabaja el sta­keho­l­der o el cliente y do­cu­me­n­tar­lo por escrito o mediante una grabación.
• Ace­r­ca­mie­n­to al contexto de apli­ca­ción: aprende acerca de la actividad del sta­keho­l­der para ide­n­ti­fi­car las ne­ce­si­da­des que debe sa­ti­s­fa­cer el producto.
• Ar­queo­lo­gía de sistemas: en el caso de sistemas in­fo­r­má­ti­cos de los cuales se tiene poca do­cu­me­n­ta­ción, el ingeniero o ingeniera puede iniciar una in­ve­s­ti­ga­ción acerca del sistema y do­cu­me­n­tar­la. Este análisis puede ser luego co­m­ple­me­n­ta­do con encuestas a usuarios del sistema.
• Re­uti­li­za­ción: si se trata de renovar un sistema, pro­ba­ble­me­n­te haya que dejar intactos ciertos flujos de trabajo con los que ya se hayan fa­mi­lia­ri­za­do los usuarios. Así, en lugar de definir de cero todos los re­qui­si­tos, se puede recurrir a la do­cu­me­n­ta­ción ya existente.

El documento de re­qui­si­tos de proyecto (DRP) es la base del acuerdo co­n­tra­c­tual entre ambas partes para iniciar el proyecto y es, por lo tanto, el primer documento que debe re­da­c­tar­se en el marco de la gestión de re­qui­si­tos. En él se describen todas las exi­ge­n­cias del cliente de cara a la empresa encargada del proyecto: es decir, se establece qué se espera del producto final. En algunos casos, el DRP va aco­m­pa­ña­do de un pliego de co­n­di­cio­nes que define por separado cómo debe de­sa­rro­llar­se la im­ple­me­n­ta­ción.

Además, en muchos casos, conviene do­cu­me­n­tar los re­qui­si­tos no solo por escrito, sino también de manera gráfica, es­pe­cia­l­me­n­te cuando se trata de re­pre­se­n­tar sistemas, procesos y ejemplos de uso. Para hacerlo, suelen usarse los llamados diagramas UML.

Una vez re­co­pi­la­dos y do­cu­me­n­ta­dos los re­qui­si­tos, el siguiente paso dentro del re­qui­re­me­nts ma­na­ge­me­nt es ana­li­zar­los. Puede que haya, por ejemplo, in­di­ca­cio­nes co­n­tra­di­c­to­rias que deban ser aclaradas con las partes in­te­re­sa­das. El ingeniero o ingeniera debe, además, ide­n­ti­fi­car y evaluar riegos (haciendo es­ti­ma­cio­nes sobre la pro­ba­bi­li­dad de que ocurran y del posible alcance de los daños). También se deben ordenar los re­qui­si­tos según su prioridad.

A co­n­ti­nua­ción, la do­cu­me­n­ta­ción de los re­qui­si­tos debe pre­se­n­tar­se a las partes in­te­re­sa­das para que co­m­prue­ben si concuerda con su idea del proyecto. El proyecto no debería iniciarse hasta que no se haya llegado a un acuerdo respecto al contenido de estos do­cu­me­n­tos.

En prá­c­ti­ca­me­n­te todos los proyectos acaba surgiendo la necesidad de hacer algún cambio una vez iniciado el trabajo. Para evitar grandes di­s­cu­sio­nes acerca del trabajo adicional que eso supone y para poder deshacer los cambios si el cliente no queda sa­ti­s­fe­cho, vale la pena hacer distintas versiones. Este método se originó en el ámbito del de­sa­rro­llo de software, pero se usa también en la gestión de proyectos: se do­cu­me­n­tan los distintos estados del proyecto y se definen los estados actuales como nuevas baselines o puntos de re­fe­re­n­cia. Así, es más fácil comparar el alcance de los cambios pasados y de los actuales.

Muchas empresas suponen que la gestión de re­qui­si­tos no es necesaria en proyectos ágiles, puesto que la dirección del proyecto va cambiando según se va de­sa­rro­lla­n­do, pero se equivocan.

En proyectos ágiles, de gran parte de las tareas que abarca la gestión de re­qui­si­tos se ocupa el product owner, es decir, la persona que controla y dirige el de­sa­rro­llo del proyecto y, por lo tanto, la im­ple­me­n­ta­ción de los re­qui­si­tos. Esta persona se encarga, además, de priorizar ciertos re­qui­si­tos y coordinar las mo­di­fi­ca­cio­nes, dos tareas típicas del re­s­po­n­sa­ble de la gestión de re­qui­si­tos.

Si el product owner no puede en­ca­r­gar­se de todas las tareas de in­ge­nie­ría de re­qui­si­tos, también puede designar a otros miembros del equipo para que controlen la apli­ca­ción de nuevas in­di­ca­cio­nes y mantengan al día la do­cu­me­n­ta­ción (acerca de las mo­di­fi­ca­cio­nes, por ejemplo).

La gestión de re­qui­si­tos en proyectos ágiles no es tan compleja, pero sigue siendo tan im­po­r­ta­n­te como en proyectos clásicos de de­sa­rro­llo en cascada.