archivo

Archivos diarios: enero 1, 2012

Lo fácil es asociar un incremento de la jornada laboral a un intento por incrementar la productividad en lugar de aplicar otras estrategias que probablemente tendrían mejores resultados.

La productividad es la capacidad de generar más resultados efectivos (que sirvan) por unidad de tiempo. Con esta definición se podrá pensar: “Bien, si es capaz de hacer X en t, si le incremento un 10% t, x también se incrementará en un 10%”.

Error.

Tal vez en máquinas eso funcione, pero en personas no. Nadie es capaz de mantener un ritmo de manera sostenida (sí de tener una media o una regularidad), un incremento de horas tal vez permita generar a corto plazo más trabajo efectivo, pero ¿y a la larga? lo más normal es que la productividad se diluya entre el número de horas de la jornada laboral.

¿Quieres hacer a la gente más productiva?, ¿quieres que superen la media de la organización? Para empezar no los desmotives (es importante este detalle, comento que lo primero que hay que hacer antes de motivarles es no desmotivarles porque desgraciadamente se tiene la tendencia a que las decisiones que se toman, más allá de motivar producen el efecto contrario) y a continuación premia de manera objetiva el cumplimiento de resultados.

Y conseguir los resultados no es lo mismo que ejecutar trabajos. Para ejecutar trabajos ya te pagan, la bonificación debe llegar cuando se superan unos objetivos que van más allá de lo normal, así como las penalizaciones deberán llegar cuando el rendimiento sea inferior a lo esperado.

Más tiempo, ¿más productividad? No, más tiempo, mayor temperatura en la silla.

Los planteamientos ágiles en el desarrollo de software, siendo extensible a prácticamente cualquier ámbito de nuestra vida, no son contrarios ni incompatibles con la definición de objetivos a medio o largo plazo porque una cosa es saber a dónde queremos llegar y otra superar las diferentes metas parciales con sus correspondientes obstáculos que nos encontraremos hasta llegar allí.

Y es en ese camino de incertidumbre donde los planteamientos ágiles permiten sortear los inconvenientes que nos vayamos encontrando, realizando adaptaciones rápidas y aproximada a cada nuevo entorno.

Definir un objetivo, determinar con detalle los pasos a dar para conseguirlo y no querer salir del guión pase lo que pase es como tener un mapa que sabemos que está equivocado y empeñarnos en seguir utilizándolo.

Los proyectos de desarrollo de software se caracterizan por su incertidumbre. Tenemos una idea de a dónde queremos llegar pero no podemos saber qué es lo que va a pasar por el camino. Una buena gestión de riesgos permite adelantarnos a esas contingencias o tener previstas una respuesta pero es su combinación con un planteamiento ágil la que permitirá sortear con menos dificultad los obstáculos.

La agilidad es una actitud que se instrumenta en metodologías pero no es la solución a todos los problemas ya que es una forma de afrontar y reaccionar ante ellos, una forma de evolucionar hacia la consecución de un objetivo.

Son muchos más los factores y variables que nos pueden llevar al éxito o al fracaso. Por eso el desarrollo de software es algo tan complejo y no basta con seguir una metodología o unos principios, si bien, cuanto mejores sean nuestras herramientas, hábitos, experiencia y conocimientos más posibilidades habrá de superar las adversidades, teniendo presente que, nadie, absolutamente nadie, es infalible.

Nos encontramos con otro antipatrón muy típico y consiste en dar por supuesto que determinadas instrucciones, objetivos o explicaciones que se han dado al equipo de proyecto, a equipos concretos del mismo o a componentes de los stakeholders, han sido entendidos pese a ser consciente de no haber invertido el suficiente tiempo en ello y/o pese a que la temática que se ha tratado no resulta simple de asimilar.

Todo aquel hueco que dejemos en nuestras explicaciones será cubierto por el destinatario de las mismas, en ocasiones acertará, en otras (la mayoría) no. Esto generará malos entendidos, resultados que no se corresponden con lo esperado, realización de trabajo innecesario y/o incorrecto, etc…

Pensamos que dedicar tiempo a explicar las cosas es una pérdida de tiempo, pues bien, por mucho tiempo que se pierda, siempre será muchísimo menos, que el tiempo y esfuerzo que se tirarán posteriormente por trabajo no válido debido precisamente a dar por hecho que todo se ha entendido.

En más ocasiones de las que resultaría recomendable nos encontramos con proyectos que no llevan un ritmo constante, de pronto se va deprisa que poco después se produce un parón.

Esta falta de ritmo ocasionará retrasos, probablemente importantes, en la consecución de sus diferentes hitos.

Sin embargo, en la mayoría de ellos, llegará un momento donde alguien, relacionado directamente con el proyecto o desde fuera, pero con poder suficiente, que querrá los resultados para ya y, cuando eso sucede, empiezan las prisas.

Con esas prisas, se intentará en muchas ocasiones forzar la máquina mucho más de lo que es soportable: presión, plazos imposibles, overtime, etc… y esa aceleración no mejorará los resultados, tal vez se consiga sacar más trabajo, pero la calidad del los mismos probablemente será más que discutible y es que no resulta razonable que se intente sacar en X tiempo lo que en 4X no se ha podido.

Por mucho que trates de explicar esto, salvo que tus jefes o el responsable del cliente ocupe un nivel directivo en la organización, aquellas personas que ahora piden resultados no lo entenderán (o no lo querrán entender) y por supuesto cargarán toda la responsabilidad en el equipo de desarrollo por mucho que los parones no hayan sido provocados por ellos.

Acelerar no recupera el tiempo perdido porque hay límites que no se pueden superar (las tareas llevan su tiempo, el tiempo es optimizable, pero siempre existirán límites). La sensación de generar trabajo es solo eso, una sensación que puede tener ciertas notas de realidad cuando se liberan nuevas versiones del software, sin embargo, no se trata exclusivamente de sacar trabajo ya que es importante que los resultados sirvan y que no comprometan la capacidad de mantenimiento del producto, la disponibilidad del sistema y la experiencia de usuario.

Cuando un proyecto nos sale bien o cuando conseguimos mantener una regularidad en los resultados durante un tiempo, tendemos a pensar que nuestros conocimientos, que nuestras prácticas, que nuestra forma de gestionar es, sin duda, la mejor, que hemos descubierto la piedra filosofal del desarrollo de software y que estamos por encima de cualquier proyecto que nos toque gestionar.

Cuando se está en esa nube se olvidan o minimizan los fracasos previos y, generalmente, empezaremos a obviar nuestra responsabilidad en los mismos.

Esta actitud nos llevará de nuevo a fracasar en los proyectos porque en este negocio no hay superhombres y porque conforme te vayas alejando de la realidad más complicado será afrontar las diferentes contingencias que vayan apareciendo.

Los desarrolladores sufrimos de exceso de ego y es cuando empezamos a tener un control sobre él, cuando cada proyecto se afronta desde la humildad, cuando realmente podremos mantener una regularidad a más largo plazo en los resultados.

O infierno de los artefactos (en general). Se produce cuando en una organización o en un departamento de desarrollo o TIC no se gestionan de manera adecuada los artefactos de los que hacen uso las aplicaciones (gestionados, generalmente, a través de un repositorio de artefactos), lo que implica que se pueda sustituir un artefacto por otro que se llame de la misma manera y tenga un comportamiento distinto, que hagamos uso de uno que no es el oficial de una solución concreta, etc…

Al final, problemas y más problemas.

Esto, además de provocar problemas de disponibilidad cuando se tiene que generar una nueva versión de una aplicación, dificulta la reutilización de artefactos entre diferentes sistemas.

Pocas cosas son absolutas. Tampoco lo son las buenas prácticas y los antipatrones.

Cuando leáis algunos de ellos estaréis completamente de acuerdo y en otros estaréis, como mucho, de acuerdo a medias (dependiendo del tipo de proyecto, del equipo de trabajo, de la organización o del momento en que se aplique), cuando no en desacuerdo absoluto.

Y eso es lo normal porque una de las variables que hay que entender en el desarrollo de software es que no hay dos proyectos iguales y por tanto, los factores que hicieron que algo funcionara en uno, no tiene por qué funcionar en otro.

Lo anterior es extensible a la propia gestión de un equipo de trabajo o de una organización, donde los objetivos y las prioridades cambian, las personas también (e incluso permaneciendo el mismo equipo, las circunstancias personales de cada uno y las relaciones dentro del grupo, van evolucionando).

Las buenas prácticas y antipatrones son el resultado de la experiencia, por ese motivo, es importante darle el valor que se merecen y eso se consigue teniéndolas en cuenta total o parcialmente en cada situación, tras analizar si resultan adecuadas para el propósito que se persigue.

La experiencia no se aprovecha aplicándola a ciegas, sino utilizándola de manera conveniente.