archivo

Archivos diarios: septiembre 30, 2012

En muchas ocasiones cambiar la dinámica de un proyecto o de una organización requiere realizar grandes cambios estructurales sin embargo hay casos donde se pueden producir mejoras sustanciales con la inclusión de cambios no tan significativos.

Tal vez la maquinaria tiene piezas muy buenas pero faltan y/o sobran algunas, lo que impide que el conjunto funcione de manera adecuada.

Comenta Peter Senge que: “Solo cambiando la forma en que interactuamos podemos compartir visiones, compartir conocimientos y se establecen nuevas capacidades para actuar de manera coordinada”.

La reflexión de Senge se centra en la comunicación y en los procesos que son piezas que pueden atrancar o engrasar la maquinaria si bien es extensible a otros aspectos de carácter organizativo, incluidas las personas.

Si las cosas no salen como queremos pese a que se pone todo el interés posible para conseguir los objetivos es normal que aparezca la frustración y el desánimo.

Ahora bien, tenemos que ser fuertes para hacerlos desaparecer lo antes posible porque de lo contrario se convertirán en una resistencia más que nos pondrá todo todavía más difícil y dará lugar a nuevas frustraciones y nuevos desánimos, de manera que entramos en un círculo vicioso de difícil salida.

Bajar los brazos supone el primer paso para el fracaso en el proyecto. Si no pones intención y arrojas la toalla no puedes esperar que otro lo haga por ti. Precisamente son en los momentos difíciles donde tenemos que sacar lo mejor de nosotros mismos y si la situación y el proyecto nos termina superando que no sea porque nos hemos dado por vencidos.

Muchas veces estamos más cerca del objetivo de lo que pensamos y sin embargo tenemos la sensación de que cada vez está más lejos. Eso es provocado porque los golpes del presente te hacen perder objetividad ya que te centras en el daño que tienes ahora, lo que te hace mirar hacia ti en lugar de mirar hacia adelante.

En la mayoría de los casos la instalación de una versión del sistema en el entorno de producción es realizada por un personal distinto al que desarrolla y que se encargar de administrarlo.

También antes de proceder a la instalación en producción se realizan pruebas específicas ya sean por parte del usuario, por parte de personal de equipo de proyecto y/o por parte de un equipo de personas que realizan este tipo de tareas.

Básicamente (dependiendo de la organización con la que se trabaje estos requisitos podrán ser mayores) una entrega consistirá en la entrega del código fuente, en un sistema de control de versiones, la incorporación de las librerías dependientes en un repositorio de artefactos y la documentación necesaria para la instalación del producto y la realización de pruebas.

No es mucho, ¿verdad?, pues incluso en este tipo de circunstancias los desarrolladores realizan con demasiada frecuencia entregas deficientes que provocan retrasos en el proceso de paso a producción (vueltas a atrás por entregas defectuosas ya sea del producto y/o de la documentación) e incidencias sobre funcionalidades ya existentes en el sistema y que funcionaban bien (efecto colateral) o funcionalidades nuevas que fallan.

Esto tiene un coste importante para el proveedor y también para el cliente. En algunas ocasiones este coste puede ser incluso mayor cualitativamente y/o cuantitativamente que el esfuerzo que ha sido necesario para desarrollar esta iteración.

¿Por qué estas malas entregas? Principalmente por la falta de atención. A los desarrolladores no les motiva esos preparativos y hacer esa documentación, les aburre y mientras están trabajando en la misma en lugar de enfocar su atención a esa tarea se ponen a pensar en otra cosa o simultanearla con otros asuntos.

Con respecto a esto yo solo digo que un muy buen trabajo en el desarrollo puede quedar arruinado por una mala gestión de la entrega lo que realmente es una pena porque es como fallar un gol desde el área pequeña y sin portero.