¿Eres capaz de adivinar cuántas pelotas saltarinas hay en el recipiente?

Seguramente no podrás adivinarlo fácilmente, no conoces el tamaño de las pelotas, el volumen del recipiente ni lo lleno que está.

El proceso de cálculo será similar a dar palos de ciego en la oscuridad o saber cuántos granos de arena hay en el desierto del Sáhara.

Precisamente éste tipo de problemas nos encontramos todos los días los que trabajamos en la industria del software.

Frecuentemente, al inicio de un proyecto de desarrollo, se nos pide que hagamos un cálculo ridículo y a la ligera, que es lo mismo que un SWAG (”Silly Wild-Ass Guess”).

Un SWAG es un cálculo intuitivo del esfuerzo necesario para desarrollar un proyecto de software. Los jefes de proyecto nos suelen pedir un SWAG para predecir las fechas de lanzamiento de los productos cuando nosotros aún no contamos con datos relevantes sobre los requisitos del proyecto y, a esas alturas, todavía sabemos menos del diseño. La probabilidad de adivinar el número de pelotas saltarinas equivale a la probabilidad de calcular con exactitud la cantidad de esfuerzo necesario para completar un proyecto con muchas variables.

A medida que restamos incertidumbre al proyecto mediante la identificación de características, el establecimiento de requisitos y la creación de un diseño, la imagen se va aclarando. Puede que no tengamos toda la información necesaria para realizar un cálculo preciso pero, llegados a este punto, sabemos lo que no conocemos y podemos hacer planes.

Si conociéramos el diámetro de las pelotas, el volumen total del recipiente, la cantidad de espacio vacío,… el cálculo del número de pelotas podría ser mucho más aproximado.

Con los proyectos de software, al final conseguimos desechar variabilidad suficiente y reducir bastante el riesgo como para ofrecer un cálculo razonablemente preciso. Al principio de un proyecto, sin embargo, hay muchos factores desconocidos.

Para minimizar éste problema, algunas metodologías ágiles como Extreme Programming o Scrum utilizan un método ágil de estimación denominado “Planificación de Póker”.

La Planificación de Póker consiste en un método para agilizar y conducir la estimación de las tareas en la reunión inicial. Para ello se realiza una reunión en la que participa todo el equipo a partir de la información del proyecto proporcionada por el cliente con el objetivo de encontrar el verdadero alcance del proyecto.

Un artículo muy recomendable sobre éste método lo podéis encontrar aquí perteneciente al blog Navegapolis, de Juan Palacio.

En nuestras vidas y carreras profesionales existen determinados momentos donde debemos tomar decisiones en situaciones de gran intensidad emocional, donde las decisiones adoptadas determinarán coger un camino u otro, cada uno de los cuales conduce a destinos totalmente diferentes.

Uno de los problemas más frecuentes es cuando entramos en una situación de desacuerdo. Seguramente, en algún momento de su vida ha presenciado un acalorado debate entre compañeros de trabajo o familiares donde finalmente la conversación ha acabado entrando en una fase de parálisis o estancamiento.

Si hace memoria, o mejor dicho, si es un poco observador en futuros debates podrá darse cuenta que la mayoría de las veces se produce un hecho intrigante. A pesar de que las diversas partes discuten violentamente, en realidad se encuentran en un violento acuerdo. Es más, de hecho están de acuerdo en todos los puntos importantes de la conversación, sin embargo siguen discutiendo. Han encontrado una manera de convertir las diferencias sutiles en una reñida discusión.

En mi caso, el noventa por ciento de éste tipo de situaciones se producen cuando la otra parte tiene un perfil técnico, y más concretamente es un programador. Precisamente, la mayoría de discusiones se producen por riñas en torno a ese cinco o diez por ciento de puntos en los que discrepamos. No importa que sea un punto sin importancia, si existe alguna discrepancia no dudamos en perseguirla como si fuera un criminal que se da a la fuga.

Analizando la situación, me di cuenta que el problema venia motivado por algunos de los talentos predominantes en los buenos programadores, la necesidad de buscar las diferencias.

En realidad, desde nuestra tierna infancia estamos entrenados para detectar los errores o pequeñas diferencias que se cruzan en nuestro camino. Por ejemplo, en la guardería aprendemos que si damos la respuesta correcta nos ganamos la aprobación y felicitación de nuestra maestra, y en caso de equivocarnos señalamos los errores para no volverlos a cometer en el futuro.

Al acabar la etapa escolar, ya nos hemos convertido en unos expertos en el arte de detectar las pequeñas diferencias y convertirlas en un asunto de enorme importancia. De modo que cuando una persona nos hace una sugerencia nosotros buscamos un resquicio para manifestar nuestro desacuerdo.

Imaginad entonces los estragos que puede llevar a cabo ser una persona con un talento extraordinario en la detección de pequeñas diferencias cuando se encuentra con situaciones que no siguen un patrón determinado.

Fíjense en lo que dedica la mayor parte de su tiempo un programador.

- Identificar y crear patrones coherentes dentro de un conjunto de datos incoherentes (talento analítico).

- Buscar errores o tratar de evitarlos.

El programador siempre piensa en lo que puede fallar, en lo que no encaja y como poder encajarlo. Por lo tanto, esta actividad rutinaria va forjando una personalidad que buscará siempre ante cualquier situación los posibles errores o no concordancias de la misma. Es decir, ante cualquier situación se centrará en los peros. Sin embargo, no debemos confundirnos, no es una personalidad que busca problemas, más bien busca resolverlos, pero enfocará su energía principalmente en los problemas y a veces no en las soluciones.

¿Cómo podemos solucionarlo?

A la larga se deben superar esas diferencias, y para ello la mejor solución es empezar por crear un terreno de común acuerdo. Si esta completamente de acuerdo con el camino de la otra persona, dígalo, déjalo claro, y reanuda el dialogo. Muestra tu acuerdo cuando así suceda, y no lo conviertas en una discusión.

La clave está en conectar los puntos de acuerdo.