Question woman

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. 

Esta es una de las cosas más difíciles de resolver cuando afrontamos la creación de un nuevo proyecto: distinguir claramente entre qué debe hacer de cómo se debe hacer.

El "qué" está relacionado con requisitos, especificaciones, historias de usuario, todo aquello que nos haga entender lo que el cliente quiere, su problema a resolver.

El "cómo" tiene que ver con las tecnologías que van a resolver ese problema que el cliente nos plantea, en otras palabras, el cómo abarca desde las tecnologías a usar, metodología, evidencias a entregar hasta dónde se desplegaría el proyecto final.

Hay una confusión tremenda entre esa separación de conceptos, hasta el punto de tener que forzar o usar mal tecnologías mal elegidas para el propósito indicado en una sencilla especificación (cuando no se le dice a un cliente que "eso no se puede hacer").

Si ya es difícil extraer al comienzo todos los requisitos y conseguir que estos estén descritos con buena calidad y que sean entendibles, más complicado aún el elegir ese cómo a partir de todo lo anterior.

De cómo se gestione esto y las decisiones que se tomen en ese momento dependerá en gran medida la calidad del proyecto que se entregue, su coste final y su facilidad de mantenimiento y evolución. Errores en esta fase hacen que el proyecto termine en un completo fracaso o haya que tirarlo al cabo de algunos años.

Lo peor de todo es que en muchas ocasiones confundimos requisitos objetivos, indicados o no por un cliente o intermediario, con aquellas tecnologías que nos gustaría usar porque sí o bien porque son las únicas que conocemos bien y no queremos salir de nuestra zona natural de confort. 

Traducido al desarrollo de proyectos software, esto viene a ser algo así como empezar la casa por el tejado: si antes de afrontar un nuevo proyecto, sea del tipo de que sea, ya estamos diciendo que lo vamos a hacer con una base de datos en SQL Server, ya estamos levantando paredes en el laberinto que se formará durante su desarrollo, o dicho en otras palabras, en lugar de solucionar, estamos poniéndonos a nosotros mismos obstáculos.

Este no es que sea un error más, el confundir qué se tiene que hacer con cómo se debe hacer, sino que es un error paradigmático de una profesión tanto si a ella llegan gente titulada con uno u otro título académico o intrusos sin formación formal relacionada (sin ánimo de menospreciar a nadie, al fin de al cabo sólo valen el talento de cada cual y el trabajo bien hecho).

Sin clientes, ¿a quién le venderíamos nuestros productos o proyectos software?

Esto es evidentemente una obviedad, es una desfachatez siquiera comentarlo; sin embargo, no siempre tenemos a esos mismos clientes en cuenta para escucharles y que en cierta medida nos ayuden a mejorar todo aquello que hacemos y cómo lo hacemos.

Por lo general, no programamos o trabajamos en un proyecto cuyo cliente o usuario vamos a ser nosotros mismos, sino que siempre, de algún modo, vamos a realizar algo para que lo utilicen otros. No entiendo, por tanto, por qué no se trabaja intensamente con una actitud de escucha y recopilación activa de sugerencias y críticas para mejorar aquello que hacemos.

Es cierto esa frase ya clásica en software que dice que "el cliente no sabe lo que quiere" hasta que se le comienza a enseñar algo de esa nube abstracta de funcionalidad y requerimientos que pide. Pocos, muy pocos proyectos, comienzan con una definición clara y exhaustiva de requisitos. Por tanto, lo más normal (y natural) es que el cliente o nuestros usuarios comiencen a matizar y a solicitar nueva funcionalidad cuando ya por fin tiene algo entre manos que tocar y usar.

Esto no es malo, no hemos hecho nada erróneamente: sencillamente es lo habitual. Hay que vivir con ello y sabiéndolo, anticiparemos posibles problemas por desviaciones en tiempos y esfuerzos.

En realidad, esa falta de definición inicial es una gran ventaja si la sabemos usar correctamente.

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...