archivo

Archivos diarios: noviembre 18, 2010

Antoni Gaudí utilizaba los planos, sus modelos en yeso y otro tipo de abstracciones de lo que posteriormente serían sus obras como un instrumento de trabajo, posteriormente estaba a pie de obra y se encargaba personalmente de solicitar modificaciones sobre el proyecto base.

No hace mucho escuché una entrevista a Achero Mañas donde comentaba la necesidad de adaptar los guiones en el propio proceso de rodaje de la película porque lo que parecía funcionar en papel, no conseguía transmitir lo que él quería cuando se llevaba a cámara.

En el desarrollo de software lo especificado en el análisis podría perfectamente adaptarse a lo que he comentado en los dos párrafos anteriores, es decir, por mucha capacidad de abstracción que se tenga, posteriormente (puede que en el diseño, en la construcción o en el mantenimiento) será necesario realizar modificaciones sobre la propuesta base, ya que la falta de flexibilidad en estos casos, puede ir a favor de la agilidad y la rentabilidad en el proceso de desarrollo pero en contra del éxito en la implantación del sistema de información.

¿Hasta dónde se puede ser flexible? Salvo que el proyecto cuente con un presupuesto muy por encima del necesario para desarrollar el producto y además se cuente con unos plazos de entrega holgados es necesario establecer ciertos límites, no obstante, pienso que muchos problemas se podrían solucionar mediante la aplicación de una metodología adecuada, es decir, seguirá siendo necesaria la flexibilidad pero el objetivo será reducir el número de casos en proceso de desarrollo.

Cada vez soy más partidario de realizar el análisis utilizando como base prototipos, ya que los usuarios nos tienen que especificar lo que quieren y a través de los prototipos les resulta mucho más sencillo. También soy cada vez más proclive a que el proceso de desarrollo (más concretamente el diseño y construcción) sea iterativo, es decir, vamos liberando y pasando a explotación módulos de la aplicación (aunque partiendo de un análisis global realizado a partir del trabajo con el prototipo), tal vez las primeras versiones todavía no tengan funcionalidad suficiente para que el sistema entre efectivamente en producción, pero hará más sencillo la localización de errores, simplificará los posteriores pasos a explotación del resto de módulos y también permitirá que el usuario pueda empezar a familiarizarse con el sistema y a poder solicitar cambios (ahí es donde entra en funcionamiento la flexibilidad) que modificarán el análisis y en consecuencia futuras iteraciones.

Cada proyecto es distinto, no importa que coincida la tecnología, los usuarios o el equipo que participa en el mismo, por eso a veces las cosas salen bien y otras salen mal.

Cada uno puede tener unos conocimientos, una experiencia o un método para afrontar los trabajos y cada vez, si se pone suficiente empeño, funcionarán mejor, sin embargo nada garantiza que los ingredientes que fueron bien en un proyecto sean los idóneos para otro. Es bueno tenerlos en la despensa porque lo más normal es que también puedan ser útiles, sin embargo resulta todavía más importante tener la capacidad de improvisar recetas en el caso de que el plato que se esté cocinando no termine de arrojar unos resultados esperados.

No veo mal que si se tiene una buena estrategia se intenta hacer repetible, sin embargo, siempre es necesario tener en cuenta el contexto en el que se va a aplicar y adaptarlo a él. Hay que buscar la efectividad y la practicidad y eso pasa por entender las circunstancias antes de aplicar un método.

Los proyectos de desarrollo de software en términos de la efectividad de la aplicación de buenas prácticas podríamos decir que tienen una parte constante y otra variable, cuanto mayor sea la primera, más posibilidades hay de que el proyecto tenga éxito, sin embargo si las condiciones del proyecto son muy cambiantes, dependerá mucho de lo capaces que seamos de adaptarnos a lo que hay, existiendo una mayor incertidumbre.

La aplicación de una gestión organizada (en cliente y proveedor), metodologías, procedimientos, buenas prácticas y gestión de equipos de trabajo, utilización de frameworks (más o menos completos), generación de código a partir de modelos, etc… tienen como objetivo reducir en lo posible el grado de incertidumbre ya que intenta acotar todos los desarrollos y mantenimientos dentro de un mismo marco, reduciendo los posibles riesgos. Aún así, habrá aspectos que no se pueden controlar (como por ejemplo la calidad de la participación en el proyecto de terceros departamentos o usuarios que resultan esenciales), además de existir siempre el factor humano.

Los departamentos de informática no medimos en demasiadas ocasiones el impacto que tiene optar por determinadas soluciones software centrándonos en situaciones de máximos o en escenarios teóricos sin tener en cuenta la realidad de nuestro propio departamento, de la organización o de nuestro entorno.

Será mucho mejor una solución que se pueda llevar a cabo con los recursos existentes que otra que siendo superior o muy superior no sea viable porque al final será como tener un coche caro las veinticuatro horas en el garaje (pagando, por supuesto, su seguro y los impuestos).