Gestión de requisitos de producto: ¿lenta o rápida?

En el ámbito del Product Management, se usan a menudo los conceptos de "proceso rápido" o "proceso lento" para describir el grado de formalidad con la que se gestionan los requisitos de producto.

Un "proceso lento" se caracteriza por un elevado nivel de formalidad. Dentro de esa formalidad, es habitual encontrar estándares y directrices que dictan cómo se articula el proceso. Además, las decisiones suelen ser colegiadas y se registran de manera explícita. Para evitar la ambigüedad, el proceso suele llevarse a cabo con un nivel de detalle considerable.

Por el contrario, un entorno caracterizado por la gestión rápida de requisitos suele prescindir de casi toda esa formalidad. En ausencia de estándares y directrices formales, el juicio experto y la experiencia del equipo son la guía principal del proceso. Las decisiones personales del responsable de producto son mayoritarias. Como cabe esperar, el nivel de detalle con el que se documentan las decisiones es bajo.

Pero... ¿qué método es mejor?

Ninguno es mejor que el otro. Veamos por qué.

En realidad, ni siquiera se trata de dos métodos concretos. "Lento" y "rápido" están en los extremos de un rango continuo. Entre ellos, cabe encontrar un sinfín de grados y combinaciones. Es poco habitual mantenerse en uno de los extremos.

Cada organización debe encontrar el punto en el que se encuentra más cómoda. El punto ideal es el que mejor se ajusta a:

• su entorno (p. ej. - productos que se desarrollan en un sector regulado, como el farmacéutico, exigen procesos "lentos"),

• su cultura organizativa y, concretamente, su tolerancia al riesgo,

• las características del equipo de trabajo: nivel de experiencia, cohesión, ubicación, entornos multiproveedor...

• y las circunstancias alrededor del producto (p. ej. - ¿hay que salir al mercado con urgencia?)

¿Dónde hay menor riesgo?

La literatura sobre gestión de productos coincide en afirmar que los procesos "lentos" implican menos riesgo. Yo no creo que sea exactamente así. 

Un riesgo es un acontecimiento o condición de carácter incierto que, si llegase a ocurrir, tendría un impacto positivo o negativo sobre el proyecto de desarrollo de producto o sobre la gestión de su ciclo de vida.

Puede parecer que un proceso de gestión de requisitos muy formal, guiado por estándares y con decisiones colegiadas es la fórmula ideal para reducir los riesgos pero, como digo, no creo que sea completamente así.

Gestión de riesgos en procesos "lentos"

Un proceso "lento" de gestión de requisitos reduce sensiblemente el riesgo del proyecto si (y sólo si) tiene asociado su propio proceso de gestión de riesgos.

Gestionar requisitos sin gestionar explícita y formalmente los riesgos asociados quizá permita identificar y registrar más riesgos, pero no hace nada por reducir su probabilidad de ocurrir ni por amortiguar su impacto.

Además, en la práctica, no me cuesta demasiado recordar ejemplos de procesos muy formales de gestión de requisitos que sufrieron de forma despiadada el impacto de riesgos críticos. En muchos casos, por motivos tan simples como que las premisas de negocio sobre las que se apoyaban no tenían ni pies ni cabeza.

O, también, puedo recordar casos en los que alguna persona concreta fue capaz de "secuestrar" las decisiones colegiadas para amoldarlas a su punto de vista, a base de influencia política y de persuasión. Sobre el papel, todo era formalmente correcto pero, en realidad, eran decisiones personales, rápidas e impulsivas, disfrazadas de decisiones formales y basadas en procedimientos.

Gestión de requisitos "rápida" y sus riesgos

Por otro lado, un proceso "rápido" de gestión de requisitos suele carecer de cualquier gestión formal de riesgos. Como resultado, los riesgos suelen ocurrir de forma efectiva con mayor frecuencia.

Sin embargo, la mayor capacidad de respuesta (podríamos decir "agilidad", aunque con cautela para no mezclar conceptos a la ligera) de un proceso "rápido" otorga también un mayor nivel de resistencia frente a los riesgos cuando estos ocurren:

• su impacto tiende a ser menor, porque el trabajo invertido que se ve afectado también es menor

• el diseño de la solución que mitigará el impacto también resulta más llevadero

Si adoptamos una gestión rápida de requisitos, debemos asumir un mayor nivel de incertidumbre. Hay que sentirse cómodos, a todos los niveles, con ese mayor nivel de riesgo.

Y, por supuesto, la gestión "rápida" de requisitos debe estar en sintonía con la forma de trabajo del equipo de desarrollo/gestión de producto. De lo contrario, no disfrutaríamos de las ventajas de arriba sobre la mayor capacidad de respuesta.

Dicho de otro modo:

Gestión rápida de requisitos + gestión adaptativa del trabajo = mayor resistencia ante el impacto de los riesgos

Gestión rápida de requisitos + gestión pesada del trabajo = chapuza suicida

En mi opinión, la gestión "rápida", pero no extrema, de requisitos de producto es la ideal en actividades como el diseño de productos mínimos viables (MVP).

En resumen

• No existe un estilo de gestión de requisitos de producto que sea mejor que los demás.

• Debemos elegir el grado de formalidad más adecuado en función de nuestro entorno, nuestra organización y las circunstancias.

• La gestión "lenta" de requisitos no reduce los riesgos por sí sola. Ha de contar con procesos formales de gestión de riesgos.

• La gestión "rápida" de requisitos reduce el impacto de los riesgos si está acompañada por una forma de trabajo que admite bien el cambio frecuente.