La Visión del Túnel. Los Cisnes Negros del Software.

En estos días he estado leyendo un libro sumamente interesante llamado “El Cisne Negro” (The Black Swan) de Nassim Nicholas Taleb. Este libro plantea la tesis de que el mundo está lleno de eventos impredecibles, que de alguna manera cambian por completo la forma en que percibimos las cosas, y hasta después de que sucedieron nos podemos explicar como es que llevaron a cabo.

A estos eventos los llama “Cisnes Negros”, haciendo referencia a que antiguamente se pensaba que todos los cisnes eran blancos, pero al descubrir Australia se descubrió el primer Cisne Negro lo cuál impactó todo el conocimiento que se tenía sobre Cisnes hasta esa época. Eventos como el ataque a las Torres Gemelas, el surgimiento del Internet, y otros tantos que nos han cambiado la vida son considerados “Cisnes Negros”.

El libro es sumamente interesante, y aunque es un poco difícil de leer, se los recomiendo mucho. Uno de los puntos que me llamó la atención tiene que ver con la imposibilidad que tenemos los seres humanos de estimar un proyecto en forma precisa, debido a la complejidad de nuestro ambiente y a ciertas características de la naturaleza humana.

Según Taleb, una estimación tanto de software como de cualquier otro tipo de proyecto, falla debido a un concepto llamado visión de túnel. Básicamente, esto se refiere a que como seres humanos estamos condicionados sólo a ver lo riesgos que existen dentro de nuestro ámbito cotidiano y somos incapaces de tomar en cuenta riesgos que se encuentran fuera del mismo.

Hagamos memoria, el último proyecto que llevamos a cabo que haya fracasado ¿por qué fracasó? Normalmente la respuesta tiene que ver con algo que no se incluyó en la estimación original: el cliente decía tener claros los requerimientos pero no fue así, no se consideró el diseño de seguridad en una tecnología, el líder de proyecto nunca había manejado un proyecto tan grande, etc. La mayoría de estas razones no tienen nada que ver con el proyecto porque son elementos externos. Normalmente nuestro sentimiento es que esos eventos no son atribuibles a nosotros, y por lo tanto no cuentan.

Esto nos pone en un dilema interesante. Estamos diciendo que no importa el proceso que sigamos, la realidad es que no hay forma de hacer una estimación correcta. Adicionalmente, consideramos que las razones por las que las estimaciones fallan no son nuestra culpa o no tienen que ver con nosotros, así que ni siquiera estamos abiertos a ver como mejorar. A fin de cuentas así es siempre, y si algo sale mal no nos queda mas que negociar con el cliente. Algunos modelos como por ejemplo CMMI e ITIL tratan de resolver este problema a través de un control estadístico de tus estimados contra tus reales. Esto te lleva, dado el caso de que sigas el mismo proceso para hacer el estimado de todos tus proyectos, a que puedes utilizar esta información para detectar que tan exacto es tu modelo de estimación. El problema es que este método sólo contempla los procesos estadísticamente estables, así que no contempla los elementos que salen del estándar, que serían los Cisnes Negros en nuestra estimación.

Otro elemento importante que maneja la teoría del Cisne Negro es que la cantidad de cisnes crece exponencialmente cuando el problema que estamos atacando es un tema desconocido o lejano en el futuro. Por otro lado, esta probabilidad se reduce considerablemente entre menor sea la distancia de la predicción y más conozcamos sobre el tema que se está estimando.

Un modelo que trata de resolver esta problemática es el Proceso Personal de Software y Proceso de Equipos de Software (PSP/TSP por sus siglas en inglés). PSP/TSP ataca este problema desde un punto de vista algo diferente, ya que la estimación no es hecha por el líder del proyecto sino por todos los miembros del equipo a nivel individual, componente por componente, programa por programa, al inicio del proyecto. Toda esta información se une para formar el plan detallado global. Esto hace que el proceso de estimación sea mucho más predecible, ya que se está reduciendo la distancia y desconocimiento de la estimación.

Adicionalmente, PSP/TSP mide la cantidad de tiempo aplicado a actividades del plan las cuales llama horas de tarea, así como actividades que están fuera del plan. Por ejemplo, normalmente las juntas de equipo no se encuentran dentro del plan, esas se consideran horas fuera del pan. El manejar este parámetro adicional nos da más control sobre como mejorar la estimación. En un proyecto normal la cantidad de horas que se aplican en el día con día a actividades del plan de trabajo es alrededor de quince por semana. ¡Sí! no es un error quince por semana, esto quiere decir que si logramos mejorar este número a veinte por semana tenemos un aumento de productividad del 33%, que nos puede ser de ayuda para controlar grandes Cisnes Negros.

Esto definitivamente no quiere decir que estos procesos eliminan los Cisnes Negros, éstos seguirán existiendo. Lo único que podemos esperar lograr es controlar el medio ambiente lo suficiente para poder reducirlos al mínimo. La mejora continua no es la solución a todos los problemas, pero entre más sabemos que esperar de nuestros procesos más crecemos como individuos y como negocios.

Acerca del autor
Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.