archivo

Archivos diarios: enero 19, 2013

El principio de Pareto no suele fallar, el 80% del objetivo se consigue con el 20% del esfuerzo. Saber donde parar es importante, no solo por el ahorro económico sino también por la propia calidad del producto.

En cualquier caso, el producto final que satisface las expectativas del usuario estará por encima de ese 80% y ahí es donde el peso de los detalles crece exponencialmente.

Y si algo tiene el desarrollo de software son detalles, si algo marca la diferencia son los detalles. Un solo detalle, una sola instrucción mal codificada puede dar al traste con la implantación de un sistema en los plazos marcados y esto puede suponer mucho dinero y pérdida de confianza.

Charles Eames, en otro campo donde los detalles son importantes, como la arquitectura y el diseño, tuvo un gran acierto con la siguiente reflexión, perfectamente aplicable al desarrollo de software y a otros muchos ámbitos: “Los detalles son los detalles. Ellos hacen el producto”.

El antipatrón “techo de cristal” trataba sobre barreras invisibles, basadas en criterios subjetivos o con falta de transparencia, en las que se impedía la promoción profesional de un trabajador o de colectivos concretos de trabajadores.

En este caso, la “pared de cristal” trata de un aspecto diferente, aunque tiene en común la aparición de resistencias de gran intensidad basadas en criterios subjetivos u opacos, que dificultan el avance de un proyecto o de un objetivo más general, hasta tal punto de ponerlos en un grave riesgo.

Una “pared de cristal” podría ser el resultado de la labor de un “generador de resistencias“, pero hay una diferencia que hace que sean dos antipatrones diferentes: el “generador de resistencias” aplica su criterio a todos los proyectos (o a una gran mayoría de ellos) y quien crea “paredes de cristal” lo hace a proyectos u objetivos concretos, que tienen alguna característica que no les gusta, ya sean decisiones técnicas, funcionales, económicas o por el simple hecho de que no se llevan bien o no les gusta alguna de las personas que intervienen.

Un proyecto puede ir muy bien y una “pared de cristal” convertirlo en algo insufrible. En lugar de invertir el esfuerzo en el proyecto, se invierte en el lugar equivocado, en intentar sortear un obstáculo que artificialmente se ha añadido en nuestro camino. Lo peor de todo es que el obstáculo no es un objeto inanimado, tratará de evitar que lo superes y si lo haces, no te extrañe que vuelva a intentar ponerte las cosas más difíciles de lo que ya son.

Hay una reflexión del actor y cómico americano Steven Wright que me parece muy interesante: “La experiencia es algo que no se consigue hasta justo después de que lo necesitas”.

Y es que siempre llega tarde a la primera cita, aunque tal vez, lo más importante es que a partir de entonces siempre llegue a tiempo. Para eso es fundamental haber extraído conocimiento de la situación y eso solo se consigue con mentalidad abierta y capacidad para reconocer que las cosas se podrían haber hecho mejor, incluso en aquellos casos donde se hayan hecho bien.

La experiencia no es acumulación de años, sino como su propio nombre indica, de experiencias, de circunstancias. Por tanto no es lineal con el tiempo y sí con la intensidad y características de las situaciones que te has encontrado.

Y sobre todo es importante tener presente que por mucho que pienses que ya has pasado por todo, te seguirás encontrando con momentos en donde mires tu reloj y veas que la experiencia vuelve a llegar tarde.

Una última reflexión, si la experiencia se alcanza al enfrentarnos con el problema y analizar los resultados, y la trasladamos al desarrollo de software, ¿es el camino los enfoques predictivos o clásicos o resultan más adecuados los enfoques iterativos incrementales?.