Fork me on GitHub

El dilema del prisionero: Por que las empresas de desarrollo se auto-imponen fechas de entrega complicadas

Por luxspes

La carrera armamentista entre las empresas de desarrollo de software “por terminar el proyecto en el menor tiempo y al menor costo” continua por los incentivos. Es un ejemplo clásico del Dilema del Prisionero. Consideremos por ejemplo 2 empresas: AguacateSoft y BerenjenaSoft que están decidiendo individualmente si comprimir o no el tiempo para la entrega de un proyecto.

Desafortunadamente, el personal en BerenjenaSoft piensa exactamente lo mismo. Como resultado, ambos comprimen los tiempo de entrega, fácilmente superando el limite de factibilidad para el proyecto. Si pudieran confiar en el otro, podrían evitar comprimir sus tiempos trabajar en condiciones en las que estimaciones realistas del esfuerzo tendrían valor, y reducir de manera radical los riesgos para si mismos y para sus clientes

Pero las empresas en competencia no pueden confiar la una en la otra, y entonces, todas sienten que tienen que comprimir sus tiempos para tener una oportunidad en el mercado, y continuamente buscan nuevas maneras de convencer a los clientes que “ellos lo pueden hacer en menor costo y menor tiempo” solo para poder competir… Y la carrera armamentista sigue…

Se me ocurrió escribir este articulo al leer este. Me hizo pensar que era una buena analogía para explicar como las empresas de desarrollo de software caen en el [arquetipo sistémico de escalación][2] que refuerza cada vez mas la necesidad  de sobreprometer  para simplemente competir en el mercado, del mismo modo que los atletas sienten que tienen que drogarse para poder competir.

Esta es una de las principales razones por las que la calidad de software de ve disminuida, y los programadores son obligados a trabajar hasta quedar exhaustos. Curiosamente el problema no se origina a su nivel, si no al nivel de la administración de la empresa, que esta respondiendo a la competencia de las otras para poder sobrevivir. La agresión crece y crece y puede llevar a comportamiento autodestructivo. El circulo vicios solo puede ser roto si al menos uno del los participantes deja de reaccionar defensivamente y convierte al juego en uno cooperativo…

¿Comó podríamos hacer que “el juego de proponer tiempo y desarrollos de software se vuelva cooperativo” y detener este circulo vicioso?

[2]: http://en.wikipedia.org/wiki/System_archetype#Escalation


comments powered by Disqus