Requisitos de usar y tirar

Garrotazos Que nadie piense que voy a hablar de una aproximación hacia la captura de requisitos que tenga similitud alguna con los prototipos de usar y tirar. Ni siquiera es post va de cómo manejamos los requisitos en las metodologías ágiles y Scrum. De lo que voy a hablar hoy es de una situación que me estoy encontrando a menudo, sobre todo en equipos con cierto nivel de madurez, que escriben elaborados documentos de requisitos. No se porque algunos tienen la extraña idea de que madurez y documentos de requisitos infumables deben ir de la mano.

Cada vez más y más equipos que ‘oficialmente’ se encuentra en organizaciones CMMI, se interesan por la agilidad. En estos equipo, y según mi experiencia, que no es una muestra muy amplia de momento, todo hay que decirlo, encuentro un problema habitual en la gestión de los requisitos.

Las manifestación más claras de este problema es tener diferentes documentos, elaborados por diferentes grupos del equipo de proyecto, que dicen ser la fuente última de verdad sobre los requisitos.

La situación suele ser parecida a la siguiente:

Un grupo, bien ubicado en el departamento de Marketing o en el de Product Management escribe una especificación de requisitos. Esta especificación de requisitos es un documento con un buen puñado de páginas. Generalmente estos requisitos están expresados siguiendo una plantilla de documento, con una serie de campos. Luego este documento se pasa a los desarrolladores, para que lo asuman como fuente de verdad y validen su contenido desde diferentes puntos de vista.

Aquí están los desarrolladores, enfrentándose a un documento formado por cientos de páginas que deben leerse, que básicamente consisten en un motón de aburridísimos formularios. ¿Alguien cree a estas alturas que los desarrolladores se van a leer ese tocho? Ni por asomo. Yo he tenido que leerme ese tipo de documentos y sinceramente, tengo que reconocer que nunca lo hice con el más mínimo interés. Es que leer formularios es muy aburrido.

¿Qué hacemos los desarrolladores en lugar de leernos decenas de aburridos formularios? Defendernos para no tenerlo que hacer. La defensa suele ocurrir de dos maneras: o nos escudamos en las carencias que todo documento tiene para evitar tenerlo que leer y proponemos continuas mejoras o proponemos crear un nuevo documento. Tenemos un nuevo documento, que expresa los mismos requisitos desde el punto de vista de los desarrolladores.

Aquí están los Product Managers o analistas funcionales o lo que quiera que ponga en su tarjeta, enfrentándose a un documento formado por cientos de páginas de incomprensible jerga técnica alejada totalmente de las necesidades del negocio. Y que hacen… protegerse como lo hicieron los desarrolladores.

En cualquier de los casos, nos vemos en la situación que yo llamo requisitos de usar y tirar… de tirar contra otros implicados en el proyecto. Requisitos que se acaban convirtiendo en un arma arrojadiza entre dos grupos de implicados en el proyecto. He puesto aquí el ejemplo de desarrolladores y Product Managers, pero esta situación también se da entre organizaciones, entre proveedores y clientes.

Lo peor, es el tiempo de proyecto que se pierde en este baile de requisitos arrojadizos… y que se podría estar empleando en un motón de cosas útiles.

¿Cuál es el antídoto para esta situación? Usar un lenguaje común, el lenguaje natural para expresar los requisitos, lenguaje simple y llano que todos los implicados entiendan. Y hacer los requisitos divertidos… vale, vale, ya se que los requisitos nunca pueden ser divertidos… pero no tienen por que ser una colección de aburridísimos formularios que se rellenan solo por sistema. Otra aproximación fallida, es la visión de los requisitos como algo jerarquico. ¿Alguien es capaz de leerse una jerarquía de lo que sea? ¿Es posible conocer la historia de una familia viendo su árbol genealógico?.

Evidentemente, lo anteriormente dicho excluye a UML y los casos de uso como herramientas ágiles a la hora de especificar un sistema. Las metodologías ágiles proponen usar historias de usuario o escenarios como alternativa. No es que sea lo más divertido del mundo leer requisitos escritos como historias o escenarios, sigo prefiriendo una buena novela, pero sin duda es infinitamente más divertido que leer casos de uso o jerarquías de requisitos.

Solo si logramos que leer nuestros requisitos no sea una tarea titánica lograremos que los clientes, los desarrolladores y los Product Managers dejen de usarlos como un arma arrojadiza y lo empiecen a utilizar como un artefacto útil que facilite la construcción del sistema que se necesita.

¿Vamos a poner esfuerzo en hacer de los requisitos algo manejable o vamos a seguir a garrotazos?

7 comentarios sobre “Requisitos de usar y tirar”

  1. Muy buen post Rodrigo.

    Viví una experiencia como la que cuentas en una empresa de cuyo nombre no puedo acordarme 🙂
    Documentos de requisitos excesivamente formales, que no es que fuesen aburridos, eran un tostón enorme, que iban y venían. Cuando te habías (medio) leído la quinceava versión del documento de «Requisitos del formulario de acceso», te dabas cuenta de que podrías haber implementado 25 «formularios de acceso» por lo mínimo.
    El resultado: dos áños y medio después del inicio del proyecto este se cancela. Dos años y medio de tiempo tirados por la borda. Y SOLO el equipo técnico del proyecto era de 10 personas (de media).

    No fue el único problema que hubo ciertamente, pero tu post me lo ha recordado mucho. 🙂

    Un saludo!

  2. @andrechi: Claro que los clientes no saben lo que quieren. Tu cuando vas a comprar un sofá tampoco lo sabes. Y un sofá es algo más simple que un sistema informático ;). Peor aun, los clientes que parecen saber lo que quieren, realmente tampoco lo saben.

    La labor del desarrollador no es hacer lo que el cliente quiere, sino desarrollar software de valor para nuestros clientes.

    No nos pagan por hacer el software que el cliente quiere, sino por descubrir maneras en las que el software puede mejorar los procesos de nuestro cliente e implementar las soluciones que habiliten estas mejoras.

    Otro error habitual es ver los requisitos como contratos. Los requisitos no son contratos, son un mecanismo de colaboración entre el cliente y desarrollador.

    Comparto lo que comentas de la falta de madurez, solo una industria muy inmadura puede seguir cayendo en el error de pensar que los requisitos se pueden fijar temprano en proceso de desarrollo.

  3. Interesantísimo el artículo. Y totalmente de acuerdo… aunque en teoría. Por lo pronto mi equipo no ha visto jamás un papel más o menos serio diciéndonos qué hay que hacer antes del desarrollo.

    La poca documentación la elaboramos nosotros, así que estamos muy contentos con ella.

    Todo esto me lleva a comparar extremos. Ninguno es bueno, pero me atrevo a opinar que el de la no-documentación es mejor. Al menos se es consciente de lo que no se tiene, y no se ha perdido un tiempo elaborando documentos inútiles (aunque se perderá otro luego, cuando nadie recuerde qué había que hacer… a no dudarlo)

  4. @Andrés: Yo no creo que la gestión de requisitos basada en documentos infumables, pero tampoco creo que la ausencia total de gestión de los requisitos sea el camino. La gestión explicita y ágil de los requisitos es vital para tener alguna prosibilidad de éxito a la hora de gestionar proyectos.

    @mmmim: El libro es excelente. Ya lo he terminado. Pronto publicaré un comentario sobre el libro en el blog.

    ¡Un saludo!

  5. Interesante el artículo,
    Despues de muchos años de profesión de lo que me he dado cuenta es que una imagen vale más que mil palabras. Por esta razón CUANDO he tenido que realizar una toma de requisitos, estos los he plasmado en imagenes; diagramas sencillos con un par de líneas de texto que describe brevemente el requerimiento. Muy alejando de la pesadilla de los casos de uso & company del UML.

    Y por la experiencia y comentarios tanto de los clientes como de los programadores creo que seguire por esa línea.

    un saludo

  6. @PepeLolo: Comparto plenamente lo que comentas de que una imagen vale más que cien palabras. Sin duda es así. Las historias de usuario promocionan el uso de información visual sobre información textual siempre que se posible.

    El problema es que la gente tiende a pensar, que la foto de un dibujo en una pizarra es un mal artefacto, que no tiene la formalidad necesaria, pero no se trata de ser formales sino de ser pragmático. El dibujo ya esta hecho, todos tenemos una camara en el movil y se agradece más ver un dibujete de una pantalla que un tocho de texto explicandola.

    ¡Un saludo y gracias por el comentario!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *