archivo

Archivos diarios: julio 31, 2013

Los principios de Peter o Dilbert nos dan una respuesta a cómo es posible que determinadas personas hayan llegado (y mantenido) a según qué puestos en sus organizaciones.

Otra respuesta la tenemos también en las condiciones que ha tenido el mercado hasta hace pocos años, en los que entraba suficientemente dinero como para que apenas importase lo que se hacía mal, en los que prácticamente sin esfuerzo, se conseguían unos resultados más que aceptables.

Esta situación dio lugar a una burbuja de gestores: muchos y con unos méritos más que dudosos.

Ya lo decía Deming: “Cualquier gestor puede hacerlo bien en un mercado en expansión”.

Ahora con el doble o el triple de esfuerzo, equivocándonos mucho menos, se puede optar, en la mayoría de los casos, a la mitad que antes.

La competencia es mucho más fuerte, quienes sobreviven son los que mejor se han conseguido adaptar, y todo eso en un contexto en el que aparece nueva competencia cuyas bases se encuentran ya adaptadas a la situación actual.

Se llega a este antipatrón por la creencia de que si se retrasa la entrega, se llegará a producción con un mayor número de funcionalidades y de más calidad.

Es posible que quien haga esta planteamiento lleve razón pero un retraso en la entrega debe sustentarse en bases más sólidas, ¿más solidas que esa? Sí, porque, ¿quién te dice que cuando termine ese mes no se va a hacer de nuevo el mismo planteamiento? y así sucesivamente, no se terminará de entregar el producto.

La búsqueda de la perfección en el desarrollo de software no suele dar buenos resultados porque llegado a un punto el esfuerzo necesario para producir una mejora crece exponencialmente respecto a la mejora conseguida, a eso súmale que se sigue trabajando sobre un producto que no está en producción y aunque tengamos versiones sobre las que se pueden hacer pruebas y obtener feedback, seguiremos trabajando con fogueo y no con fuego real por lo que lo mismo se está invirtiendo esfuerzo en evolucionar un producto que cuando se utilice realmente se deba orientar de otra manera.

No se trata de negarnos a retrasar una entrega, negarnos a eso de base sin analizar la situación es un error, sino de evitar que ese retraso sea consecuencia del miedo (lógico) que existe a dar el paso final de tener el producto (o una nueva versión del mismo) en producción.