Especificaciones funcionales

It seems that specs are like flossing: everybody knows they should be writing them, but nobody does. — Joel Spolsky

Bee

¹

decidió pasar a comprar antes de juntarse con Jay aquel día, entró a una tienda que tenía todo tipo de regalos.

Esa tarde visitaría a su madre y quería llevarle algo lindo.  Le tomó bastante tiempo explicar lo que buscaba a la dependiente de la tienda, porque buscaba algo especial, pero no daba con las palabras para explicarlo. La vendedora la ayudó, con algunas preguntas, “¿qué edad tiene su madre?”, “¿trabaja?”, “¿qué lugares le gusta visitar?”, “¿cuáles son sus colores favoritos?”, y así. Después de varios minutos encontraron el regalo perfecto, ahora faltaba que su mamá lo apreciara.

Saliendo de la tienda pasó al café de siempre y ahí estaba J. con su notebook, concentrada en la pantalla. Como entró por la espalda pudo ver que estaba revisando unas fotografías de un tablero Kanban, eras unas tarjetas con lo que parecían historias de usuario. 

— ¡Hola, amiga! - la interrumpió.

— ¡Hola! Me pillaste trabajando

— ¿Así?, qué revisabas

— Historias de usuario

— Lo sospeché, y ¿qué tal?

— mmmm

Bee no pudo evitar sonreír.

— ¿Qué te causa gracia?

— Bueno, tengo una opinión impopular sobre las famosas historias de usuario.

— Cuéntame.

El problema con las historias de usuario

Bee entonces le explica a su amiga que en su equipo y en general en su empresa, no usan ese método.

— Para los requisitos somos bastante old school. Nuestros PM nos entregan un documento con la descripción del problema, el contexto, soluciones que se han intentado, o casos similares que podrían ocuparse. Luego especifican los requisito específicos. Idealmente con diagramas, o diseños en Figma si el producto requiere de alguna interfaz de usuario. Es un documento de especificación funcional hecho y derecho.

—Guau, eso debe tomar tiempo -- le acota Jay

— Claro que toma tiempo, pero lo vale. Además, permite abrir la conversación, que ayuda a construir un buen documento de diseño por parte del equipo de ingeniería. 

El problema con las historias de usuario, tal como comenta Bee, es que son demasiado sencillas, complacientes incluso, todo el mundo cree que van a solucionar el problema pero no ocurre. Son una solución demasiado simple para un problema tan crucial.

La queja frecuente que escuchamos desde las áreas de desarrollo de software es que los usuarios no se involucran en el proceso, a lo más entregan “el título de la canción”, y no mucho más. No hay profundidad en los requerimientos, y nunca ayudan a mejorar esa definición.

La historia de usuario es efectivamente el “título de la canción” pero estructurado con en la plantilla:

• COMO [rol/perfil]

• QUIERO [requerimiento]

• PARA [objetivo a lograr].

El problema que ocurre es que los usuarios nunca aprenden a escribirlas bien. Sintetizar en tan breve espacio algo es una ilusión, y lleva a tantas ambigüedades como el “título de la canción”. Otro problema es que a veces son demasiados generales. Se han escrito muchos blogs, libros, se han dictado talleres específicos para aprender el “arte de escribir historias de usuario”. Todo eso es un gran gasto de energía. Nada reemplaza a un buen documento de requisitos.

No tiene por qué ser un libro, sé de alguien que una vez escribió un documento de más de doscientas páginas como especificación de requisitos. No es necesario. Una o dos páginas pueden bastar. Lo importante es que lo escriba alguien que representa al negocio, llámenlos product owner, product manager, analista de negocios, lo que sea, tiene que ser alguien que haga la investigación necesaria, que conozca la operación, que ojalá viva con o experimente los problemas de primera mano. No es una labor para alguien del equipo de desarrollo, como el clásico analista de sistemas, o analista de requisitos. Este rol es un simple traductor, y como dice el adagio, “traduttore, traditore”.

Finalmente, Bee recuerda su experiencia comprando el regalo para su madre, le explica el proceso a su amiga. La interacción que ella como compradora tuvo con la amable dependienta de la tienda. 

-- Ella me guio haciendo las preguntas adecuadas, tuvimos un diálogo que me hizo pensar en mi mamá y de ese modo pude visualizar que es lo que creo que le va a gustar. El juicio final lo tendré más tarde, cuando le entregue el regalo, pero considero que fue una buena elección, porque siento que conozco bien a mi madre y sus gustos.

Efectivamente, Bee es como alguien del área de operaciones, que representa las necesidades del usuario final (la madre de Bee). La vendedora representa al equipo de desarrollo. Bee refina su requerimiento con cada pregunta que la vendedora le hace. Ese proceso es valioso y puede ser un buen modo de elaborar una especificación funcional.

-- Entiendo, lo que me dices es que el levantamiento de requisitos es un proceso que puede ser guiado del mismo modo que la vendedora te atendió

-- Sí, esa es una manera, pero en nuestro caso es que ese proceso de preguntas y respuestas quede registrado en un documento, que va a ser la guía para los desarrolladores. Pero fíjate que

-- Pero mencionaste que los ingenieros escriben otro documento, ¿por qué?

-- Por dos razones, primero porque es bueno documentar las decisiones que tomaste antes de construir algo. Segundo, porque al sentarte a reflexionar, sin escribir una línea de código, tu cerebro profundiza en la solución. Los diagramas y el documento de diseño no tiene la riqueza del código final, sin embargo, es el plano que guía la construcción. Claro, tampoco requiere ser un libro, por favor, no tenemos que invertir meses en este proceso. Si te dedicas puedes sacar estos documentos en un par de semanas, o menos.

-- ¿Tan poco tiempo? Te recuerdo que estamos hablando de sistemas tipo P o E -- replica Jay con ironía.

-- Ah, es que la clave es dividir para reinar. El mismo Lehman especuló con que los sistemas tipo P y E se podían abordar dividiéndolo en subsistemas tipo S. Su propuesta tiene algunos problemas, pero la intuición era clara y es algo que los agilistas tienen muy claro. Un problema grande debe ser dividido en problemas más pequeños y esto a su vez en unidades más pequeñas.

-- Entiendo, cosas que puedas abordar en un sprint.

-- Eeeeh, algo así. En otra ocasión podemos hablar de SCRUM y sus problemas, pero sí, lo importante es “rebanar” el problema, como dicen algunos agilistas. 

Jay se quedó pensando. Antes de empezar a usar SCRUM en su equipo tenían analistas sistemas, que se encargaban de recoger, o traducir como dice su amiga, los requisitos de los usuarios, escribiendo casos de uso que después se entregaban a los desarrolladores. 

Después que adoptaron SCRUM, ella tomó el rol de Scrum Master y un colega fue designado como Product Owner. Eso no ha funcionado muy bien hasta ahora, la redacción de historias de usuario es algo que comparte con su colega, y después se discuten en largas reuniones con otros stakeholders, con el fin acordar una redacción final, para posteriormente evaluarlos utilizando el método INVEST y establecer la definición de listo. Mirándolo bien parece un gran gasto de recursos y tiempo. ¿Puede ser que escribir un documento de requisitos sea más eficiente?

Jay se retiró pensativa del café esa tarde, ahora tendrá que ver si esta idea es bien recibida, después de todo, escribir documentos es muy latero, pero bueno, quizás…

Bee llegó a la fiesta de cumpleaños de su mamá, después del beso y abrazo de rigor su madre abrió el regalo y exclamó:

-- ¡Hija, qué hermoso! y es justo lo que necesitaba.

Bee sonrió satisfecha.

1. Bee y Jay son dos amigas que introdujimos en este artículo, este es el tercer artículo de esta serie.