archivo

Archivos Mensuales: septiembre 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.

Los desarrolladores tenemos la tendencia a creernos mejores de lo que realmente somos. Afortunadamente el día a día nos pone de nuevo los pies en el suelo cuando los resultados que obtenemos distan de las posibilidades que teníamos.

Alejarnos del día a día ya sea porque vamos escalando en la organización o porque se realizan tareas que no están relacionadas con proyectos supone alejarnos de lo que nos pone los pies en el suelo y esa arrogancia crece y no parece tener freno.

La arrogancia también llega cuando no asumimos los errores (siempre es culpa de otro o simplemente los ignoro) o cuando se tiene una buena racha de resultados (probablemente hayas tenido que ver en ello pero no serás el único responsable).

La arrogancia crea distancia con los demás tanto si pertenecen a tu equipo como si se trata de la otra parte en una relación cliente/proveedor. Si eres bueno no hace falta ser arrogante para que te respeten.

La arrogancia te hace bajar las defensas, es lo que tiene creerte invulnerable. Cuando bajas la tensión y cuando disminuyes la atención es cuando mas posibilidades hay de cometer errores. Es una demostración más de que la arrogancia no te engrandece sino que te empequeñece.

Un ejemplo de esto último lo tenemos en la siguiente cita de Dave Thomas: “Si asumes que puedes producir un software libre de errores, tu actitud cambia cuando lo escribes. Tiendes a ser arrogante o por lo menos complaciente con el código que escribes”.

Si no se le ha prestado mucha o ninguna atención a la deuda técnica de los sistemas que se han desarrollado para tu organización ya sea porque no se ha medido o porque midiéndola ni tan siquiera se ha analizado nos encontraremos con que la mayoría, por no decir todos, los sistemas que tienes en producción tendrán una deuda técnica superior a la que debería haber tenido incluso existiendo un contexto o contextos de desarrollo desfavorables.

Esta deuda técnica tiene un impacto directo en el mantenimiento y evolución de los sistemas: cuesta más hacerle los cambios y existe una mayor probabilidad de que los mismos provoquen efectos colaterales y nuevos errores.

Es como la gasolina, céntimo a céntimo y parece que no te duele, pero duele.

Los clientes ignoran la deuda técnica pese a que cada vez notan como los costes de mantenimiento son mayores y los pasos a producción son cada vez menos limpios. Se centran en aspectos funcionales y no entran a valorar las posibles causas que provocan ese problema.

Pero hay algo que considero casi más grave que lo anterior y es que los proveedores, en la mayoría de los casos, también la ignoran y asumen mantenimientos sin valorar y evaluar qué se van a encontrar detrás. Como en el presupuesto no se habrá tenido en cuenta la deuda técnica al final será insuficiente para el alcance previsto y provocará, además del consiguiente desgaste con el cliente, una pérdida en la calidad del producto (y a la vez un nuevo incremento no proporcional a los desarrollos realizados).

Que haya especialistas en testing o que haya personas que hagan verificaciones sobre la calidad del software no me parece mal, al contrario. Sé también que hay muchas personas que no están de acuerdo con la necesidad de estos equipos de trabajo.

Lo que suele provocar rechazo es el hecho de que alguien ajeno al proyecto, a su contexto y sensibilidades, que no ha sufrido lo que has sufrido tu para sacar el trabajo adelante, se ponga a hacer revisiones que obstaculicen el paso a producción de una versión de un producto o el propio proceso de desarrollo.

Precisamente el problema está (y en eso estoy totalmente de acuerdo con los críticos) en la palabra ajeno y en lo que eso representa realmente: no conocen la realidad del proyecto y las revisiones que realizan están basadas en procesos y reglas predefinidos que no tienen en cuenta esa realidad, persiguen objetivos distintos y se termina cayendo, además, en el antipatrón “arrojar al otro lado del muro“.

Yo estoy de acuerdo en que esos equipos o especialistas colaboren con el proyecto pero sintiéndose parte de él, de su contexto y de sus objetivos y trabajando a favor del proyecto por encima (que no ignorando gratuitamente) de los procesos, normas y reglas. Todos agradecemos la ayuda de personas y el valor que nos puedan aportar, por lo que el problema no es que participe más gente sino la manera en que se efectúa esa colaboración.

No debe haber barra libre pero tampoco reglas inflexibles. ¿Cómo se llega a eso? Para empezar con unas normas de mínimos basándose en aspectos de los que la organización no puede renunciar (salvo excepciones debidamente justificadas), como por ejemplo, el entorno tecnológico, una arquitectura de desarrollo a alto nivel, el control sobre el código fuente y sobre las librerías dependientes, control de la deuda técnica, elementos documentales, etc… y que no de partida no deben ser impuestos sino consensuados y negociados con las personas que están en el día a día de los proyectos y algunos de ellos interpretados en función del contexto del proyecto como por ejemplo el control de la deuda técnica o incluso algunos tipos de documentos.

También es importante que todo el mundo sea consciente que estos equipos pueden aportar valor (si se dan las circunstancias que he comentado) y que ese valor puede influir en la calidad del producto final, ahora bien, estas colaboraciones por el simple hecho de existir no van a garantizar la calidad del sistema de información, es decir, no es una inversión que va a garantizar eso porque entre otras cosas en el proyecto hay tantas variables que influyen en su resultado final que escapan a su alcance, por eso, soy de la opinión que llamar a estos equipos y a sus tareas utilizando la palabra certificación hace un flaco favor tanto a esos equipos como a sus funciones.

Hace poco tiempo en el trancurso de una reunión sobre un determinado proyecto en la que estaba sobre la mesa la más que probable desviación con respecto a los plazos fijados inicialmente para tener un conjunto de funcionalidades de un producto disponibles en producción un compañero dijo una frase que me pareció interesantísima: “Vamos dando pasos, cada vez estamos más cerca, es cierto que tenemos que terminar de cerrar determinadas especificaciones pero es que un sistema de información de las características del que estamos desarrollando requiere un proceso de maduración y la verdad es que cada vez está más maduro”.

Sí señor, eso es el desarrollo de software, llámalo evolución, llámalo madurez, llámalo aproximaciones o llámalo iterativo incremental.

Tener la capacidad de tenerlo todo claro desde el principio requiere tener la capacidad de poder abstraer a lo concreto eso que tienes en la cabeza y eso no es nada sencillo tanto para nosotros y sobre todo, para el usuario. Y más si cabe cuando son varios usuarios los que opinan por más que haya un Product Owner que sea el que tome las decisiones definitivas.

Esto implica que la aproximación a las expectativas del usuario es un proceso que requiere paciencia, que requiere maduración, de manera que cada vez nos encontraremos más cerca de ese objetivo aunque a veces se den pasos para atrás (mejor eso que entregar productos con funcionalidades deficientes o que no alcanzan los mínimos exigidos por el usuario).