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 el desarrollo ágil de software ya se da por sentado que los requisitos pueden cambiar, porque de hecho cambian; es lo natural. Pero lo hacen a partir de las entregas, y esto es bueno: 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 para establecer correctamente un documento con el catálogo de requisitos o especificaciones que indique qué es lo que hay que hacer. Es de sentido común dejar claro lo que quiere el cliente, ¿no? Sin embargo…
Muchas veces, me temo, quien tiene que recoger los requisitos no sabe cómo hacer ese trabajo. Pero en otras ocasiones es la pura pereza de hablar lo suficiente con el cliente 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.
Es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, las reuniones, las visitas, etc., se nos suele olvidar este principio.
Así de sencillo, así de simple.
No me deja de sorprender que, en compañías dedicadas al 100% al desarrollo y la implantación de soluciones de 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 podría contar casos que harían palidecer a más de uno.
Hace un tiempo lancé 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 recomendarles esa profesión a tus hijos…
¿Cómo podemos estimar tiempos si no llegamos a especificar correctamente un porcentaje alto de lo que necesita el cliente?
Es cierto que podemos guiarnos 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 basándose únicamente en ese olfato, ni sería serio para ningún cliente determinar el precio de una manera poco profesional: “pues a éste le vamos a cobrar X, más o menos”. No, de ningún modo es serio. Y, sin embargo, me temo que muchas veces se hace así, a ojo y con prisas.
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 para hacer bien su trabajo y bajo presión, 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 propio cliente quien te impide hacer el trabajo correctamente y te pone trabas.
La solución es bien sencilla, pero, como todo lo fácil, requiere disciplina y no dejarse llevar por la comodidad: no se pasa a la fase de ejecución de un proyecto hasta que no esté especificado en su mayor parte en un documento. Pero lo más importante es que ese documento debe estar consensuado con el cliente. No es necesario que contenga los requisitos de software; 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 de software, pero eso ya 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 muchas otras 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 decirlo, pero, como sabemos por el 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 evolucione cuando se planteen nuevos requisitos.
Otras veces es el propio responsable comercial de la compañía quien quiere cerrar el tema (lanzándoles la pelota o el marrón a otros) y pasar a otra cosa.
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 levantara una casa: “¿Y cómo la hago?” “Pues mira, más o menos…”