Peter Senge. A veces pequeños cambios pueden cambiar la dinámica

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.

Desarrollo de software. Desánimos

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.

Desarrollo de software. La necesidad de prestar atención en las entregas

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.

Dave Thomas. La arrogancia en el desarrollo de software

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».

La deuda técnica. Algo secundario para muchos clientes y proveedores.

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).

La separación entre el equipo de desarrollo y testing (o calidad del software)

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.

Desarrollo de software. El proceso de maduración

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).

Dave Thomas. ¿Cuándo parar? El usuario tiene la palabra

El desarrollador de software, por regla general, es creativo. Esa creatividad lleva en muchas ocasiones a incrementar la complejidad del producto bien sea añadiendo funcionalidades innecesarias o por querer hacer filigranas sobre funcionalidades que son importantes o sobre aspectos más internos del desarrollo como la arquitectura o la programación.

La complejidad adicional puede ser bienvenida si realmente aporta un valor proporcional al esfuerzo necesario para llevarla a cabo. El problema realmente se produce porque la complejidad añadida no suele tener aparejado ese beneficio y se convierte al final en un lastre con el que tenemos que cargar y que no siempre resulta sencillo quitárnoslo de encima.

Sobre aspectos técnicos (salvo en proyectos con usuarios con el perfil adecuado) el usuario no va a entrar a valorar tus decisiones por lo que en estos casos se requiere una cierta disciplina personal para ser práctico, diseñando un software de calidad pero sin entrar en excesos que pueden poner precisamente en peligro ese nivel de calidad o incluso la posibilidad de alcanzar las expectativas por incurrir en un coste excesivo en este tipo de tareas.

Sobre aspectos funcionales sí que debe ser el usuario el que tenga la última palabra (no entro a valorar las situaciones en las que hay que discutir aspectos presupuestarios que condicionarán hasta dónde se puede llegar con el presupuesto existente en base al esfuerzo invertido en las tareas realizadas hasta ahora).

Claro que podemos expresar nuestra opinión y debatir con el usuario (toda propuesta es mejorable), incluso mostrarnos con una cierta vehemencia en lo que creemos que es lo más correcto, pero al final la decisión debe ser siempre del usuario (aunque se equivoque y le hayas advertido) porque de lo contrario te estás echando a la espalda una responsabilidad que no te corresponde y que después te saldrá cara y por otro lado porque si desarrollas funcionalidades que no ha pedido el usuario pocas veces te lo agradecerán, lo más probable es que tengan menos utilidad de lo que crees y seguirás teniendo que hacer los desarrollos que estaban pactados.

La siguiente reflexión de Dave Thomas resume toda esta situación (traducción libre): «Si trabajas con el usuario con una mayor proximidad. Si trabajas interactivamente con el usuario ya sea diaria o semanalmente, el usuario tendrá la capacidad de indicarte cuando es tiempo de parar. No le permitas a los programadores añadir funcionalidades solo porque piensen que podrían ser una buena idea. Añadir funcionalidades debería ser una decisión del usuario y no una decisión del programador».

El coste de la calidad del software

La búsqueda de la perfección como objetivo en general y en el desarrollo de software en particular es una actividad que no tiene fin porque ¿dónde están los límites de la perfección?.

Llegado un punto cada paso que se de para intentar alcanzar esa perfección supondrá un incremento exponencial del esfuerzo necesario para conseguir ese progreso.

Teniendo en cuenta que no vamos a llegar a la perfección y que a partir de un momento el coste se dispara, la clave se encuentra en saber qué se considera como suficientemente bueno para el producto o sistema que se está desarrollando. No es lo mismo el nivel de calidad exigible a un software del que dependen la vida de personas o la integridad de una organización que el de una aplicación de gestión que trata sobre un determinado proceso no crítico.

Ese suficientemente bueno debe tener en cuenta el factor económico ya que la calidad cuesta dinero y si quieres llegar a un determinado nivel debes estar dispuesto a pagarlo. ¿Cuál es el problema? Pues que generalmente se exige unos niveles de calidad superiores a lo que se está dispuesto a pagar y eso al final termina afectando al producto y a las relaciones entre cliente y proveedor fruto del desgaste que se producirá en el proceso de desarrollo.

El desarrollador debe tratar de optimizar la calidad con los recursos disponibles pero en su mano no está hacer milagros.

Es importante que los desarrolladores (y sus gestores) tengan en mente esa optimización de los recursos pero también que no se marquen objetivos que estén por encima de esas posibilidades y de las exigencias del usuario porque se realizará un sobreesfuerzo que probablemente no alcance los niveles de calidad esperados y que además, probablemente, el cliente no valore.

Ron Jeffries. La retrospectiva

Avanzar no es no parar.

Ron Jeffries realizó la siguiente reflexión (traducción libre): «Cuanto de manera más frecuente nos tomemos un momento para reflexionar sobre cómo van las cosas, probablemente nos daremos cuenta más pronto en aquellas situaciones en las que nos estemos saliendo de la ruta más óptima».

Huir hacia adelante no es la solución, ejecutar trabajo no tiene por qué acercarnos a la meta.

¿Cómo estamos?, ¿qué ha pasado?, ¿qué hemos hecho mal?, ¿en qué hemos acertado?, ¿en qué podemos mejorar?, ¿cómo podemos hacerlo?, de las medidas que tomamos anteriormente ¿qué ha funcionado?, ¿cuál ha sido su impacto real en el proyecto?.

De nada vale todo eso si no tienes la voluntad de asumir errores. Realmente ahí es donde radica la dificultad de todo, en asumir errores.