¿Requisitos? ¿Y eso qué es?

Este es un tema tan manido en nuestra profesión, tan pesado, pero al mismo tiempo tan importante, que seguimos años y años hablando de lo mismo y sufriendo las mismas consecuencias una y otra vez.

¿Están bien especificados los proyectos? ¿Se parte de un grupo de requisitos suficientemente amplio? Es cierto que en software ágil ya se da por sentando que los requisitos pueden cambiar, porque de hecho cambian, es lo natural, pero lo hacen a partir de entregas, y esto es bueno y es precisamente lo que resuelven de manera magnífica todas las prácticas y principios de lo ágil.

Sin embargo, el peor vicio de nuestra profesión consiste en no saber o no querer esforzarse lo suficiente en establecer correctamente un documento con el catálogo de requisitos o especificaciones que indiquen qué es lo que hay que hacer. Es de sentido común dejar claro lo que el cliente quiere, ¿no?, sin embargo...

Muchas veces, el que tiene que tomar los requisitos, no sabe cómo hacer ese trabajo, me temo, pero en otras ocasiones, es la pura pereza de hablar con el cliente lo suficiente lo que impide que el equipo del proyecto sepa con más exactitud lo que hay que desarrollar.

Existe una ley universal que deberíamos tener siempre presente:

Cuanto más esfuerzo se dedica a especificar, menos tiempo se emplea en el desarrollo del proyecto.

Esto es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, reuniones, visitas, etc. se nos suele olvidar este principio.

Así de sencillo, así de simple. 

No me me deja de sorprender que compañías 100% de desarrollo e implantación de soluciones software, este trabajo previo e indispensable para crear una cotización aproximada y correcta, sencillamente no se tenga en cuenta con la seriedad que debería. Sí, me temo que puedo contar casos que harían palidecer a más de uno.

Hace un tiempo lanzé una encuesta con el siguiente lema: "El tiempo que se establece para los proyectos, ¿es correcto?"

El 81% de las respuestas seleccionaron la opción "No, se suelen hacer estimaciones cortas y muy ajustadas". Genial, como para recomendar a tus hijos esa profesión...

¿Cómo podemos estimar tiempos si no llegamos a especificar correctamente un porcentaje alto de lo que el cliente necesita?

Es cierto que nos podemos guiar un poco por la intuición después de llevar muchos años trabajando en el desarrollo de productos y proyectos, pero ningún negocio puede sobrevivir basado únicamente en este olfato, ni sería serio para ningún cliente determinar el precio de una manera no profesional: "pues a este, le vamos a cobrar X, más o menos", no, de ningún modo es serio, y sin embargo en muchas ocasiones se hace así, o ojo y con prisas, me temo.

La consecuencia natural de esta forma de hacer las cosas la he comentado mucho en este blog y en El Libro Negro del Programador: desarrolladores sin tiempo de hacer bien su trabajo y presionados, clientes enojados porque no se cumplen las fechas o porque se les entrega algo que no es exactamente lo que han pedido, compañías que pierden dinero, etc. También digo que con frecuencia es el mismo cliente el que te impide hacer el trabajo correctamente y te pone impedimentos.

La solución es bien sencilla, pero como todo lo fácil, requiere de disciplina y no dejarte llevar por la comocidad: no se pasa a la fase de ejecución de un proyecto hasta que no esté en su mayor parte especificado en un documento; pero, lo más importante, ese documento debe estar consensuado con el cliente. No es necesario que ese documento sea el que contenga los requisitos software, sino que la especificación puede estar en el mismo lenguaje con el que el cliente habla y entiende su negocio; de ahí, se extraerán después los requisitos software pero es suficiente para hacer una valoración de tiempos más acertada.

Pensándolo bien, en una compañía es vital gestionar los riesgos, ¿no es un riesgo ejecutar un proyecto por debajo del precio que se va a cobrar por él?

Esta falta de seriedad en la especificación la puedo comprobar continuamente y si de otras muchas cosas dudo, de hecho, suelo dudar de casi todo, en esto no hay nadie que me pueda rebatir. La buena ejecución de un proyecto depende enormemente de lo bien especificado que esté. Parece una perogrullada decir esto, pero como sabemos del día a día, a veces es difícil ponerlo en práctica. Otra cosa es que aplicando correctamente buenos principios de desarrollo, el proyecto sea mantenible y evolucionable cuando se planteen nuevos requisitos.

Otras veces es el mismo responsable comercial de la compañía el que quiere cerrar el tema (lanzándole la pelota o el marrón a otros), y a otro asunto.

Así son las cosas. Sin embargo, un buen responsable de equipo o de proyecto, no debe aceptar la puesta en marcha de un nuevo proyecto si no tiene claro en su mayor parte lo que hay que hacer. Es como si le pidiéramos a un constructor que nos levante una casa: ¿y cómo la hago?, pues mira, más o menos...