Antes de empezar

Sé que este artículo es un poco superficial; simplemente pretendo compartir mi punto de vista basado en la experiencia de varios años en este mundillo. Incluso habrá quien lo considere anticuado por entenderlo como programación en cascada o simplemente quien no comparta algunas afirmaciones. Me encantaría poder recibir vuestros comentarios al respecto y aprender de vosotros.
 

¿Empezamos a trabajar ya?

Al iniciar un proyecto, a veces se deja de dedicar esfuerzo en detectar los puntos clave, documentar por escrito e intentar aportar más valor de lo que solicita el cliente y tener visión para anticipar futuros problemas y/o requerimientos. Este ejercicio, aunque puede demorar un poco el inicio de la programación tiene beneficios a corto y medio plazo.
 

¿Qué me estás pidiendo?

Es conocido que el cliente no suele pedir lo que necesita, pide lo que «cree» que necesita, habitualmente condicionado a las soluciones ya implementadas, centrándose únicamente en los defectos y limitaciones de estas, sin hacer el ejercicio de poner la mente en blanco, desaprender lo aprendido, pensar únicamente en su negocio y lo que realmente necesita.

Al psiquiatra vas

Es por ello que la realización del análisis por parte de un externo (el analista), permite aportes frescos, nuevas ideas, algo así como ir al psiquiatra, que es un perfecto desconocido pero te ayuda a ver las cosas desde otra perspectiva y aporta valor a las ideas preconcebidas.

También es cierto que a veces el cliente es reticente a nuevas ideas, aquello que se llama «miedo al cambio». Aquí se debe jugar la carta opuesta a «si funciona no lo toques» porque el cliente es consciente de que «no funciona» y por eso es necesario darle la vuelta a la tortilla.
 

Visión, visión, visión

Entender las necesidades (requerimientos) y encontrar respuestas siempre lo asocio al juego del ajedrez. Como analistas debemos ser capaces de anticipar a:

  • Corto plazo: lo que nos piden, la jugada inmediata, me como el caballo y punto

  • Medio plazo: lo que el cliente sabe que pedirá, anticipar un par de jugadas para comerle la reina

  • Largo plazo: lo que ni el cliente sabe pero que algún día llegará, jaque mate.
     

Nota: el adversario no es el cliente, es llegar a la mejor solución para todos.

Con todo ello, debemos ser capaces de diseñar los sistemas, componentes, procesos, bases de datos y todo aquello que cubra el corto plazo, pero preparado para el medio y el largo que hemos identificado. El esfuerzo no debería ser mayor, solo es anticiparse y dejarlo todo preparado a futuro.
 

«Especificación» no es sinónimo de «rigidez»

Analizar, definir, documentar no tiene porque ser una foto estática, es más, puede convertirse en la herramienta para posteriores cambios pues ayuda a conocer las consecuencias, esfuerzos, riesgos de los cambios.
 

Las ventajas de documentar formalmente

A veces comparo la elaboración de software con la construcción de un edificio, nadie entendería empezar a construir sin planos, los cimientos preparados para soportar cuantos pisos… ¿Debe haber parquing? ¿De cuántas plazas? ¿Aire acondicionado? Si no se tiene claro desde el primer dia, a medio trabajo estaremos rehaciendo todo, una montaña de chapuzas, material desperdiciado, horas desperdiciadas, desprestigio, desmoralización y no hablemos del cliente.

En la elaboración de software podemos aplicar la misma premisa, realizar un diseño previo, completo y detallado de los componentes y sus iteraciones aporta:

  • Facilita la valoración de tiempo y costes

  • Evita riesgos (¡¡¡sustos!!!) al anticipar soluciones antes que aparezcan

  • Mejora la comunicación entre el equipo y con el cliente

  • Evita malentendidos «tú me dijiste», «yo entendí» (¿os suena?)

  • Ayuda a distribuir las tareas

  • Facilita la creación de iteraciones

  • Evita errores y duplicidades

  • Facilita la gestión de cambios.
     

La lista es muy larga, os dejo que la completéis.
 

Conclusión… personal

Dependiendo del tipo de proyecto y el equipo involucrado, cada hora dedicada al análisis y especificación puede tener un ahorro de decenas de horas de trabajo y desmoralización.
 

Foto de cabecera: Markus Spiske / Unsplash
Open,Programación,projectes,proyectos,