Ese sabor agridulce de haber pensado bien pero en vano

Allá por el año 96 o 97 hacer testing en Argentina era algo raro. Aún más raro era ser una empresa de servicios de testing. Pocos hacían testing, pocos sabían de testing y poco había para leer. La teoría y la práctica además estaban distanciadas y había que resolver problemas prácticos sin demasiada ayuda [1]. Era una época en la que no tenías el nivel de información que hay ahora en la WEB. Digamos que te enterabas poco de cómo se trabajaban ciertos temas en otros lugares. De modo que, la mayoría de los problemas prácticos debías resolverlos solo.

En particular recuerdo el trabajo que fue establecer un método de estimación de esfuerzo y tiempo, para poder conversar con nuestros clientes de lo que implicaba llevar adelante una prueba. Luego, una vez acordado el plan, también fue un trabajo pensar cómo monitorear el avance de ese plan y de cómo lograr que el equipo mantuviera cierto ritmo de pruebas que garantizara su cumplimiento. 

Esta nostalgia viene a cuento de que en estos días donde hablamos en forma cotidiana de métodos ágiles, lean y otras tantas cosas, encuentro conceptos (como takt time sin ir más lejos) que me hacen recordar a aquellas cosas que tuvimos que deducir solos.

En el mundo del trabajador del conocimiento es bastante común esto de pensar en cómo resolver un problema, sintetizar una solución para luego, más tarde o más temprano, encontrar que alguien ya lo había hecho. Supongo que no hay manera de evitar ese sabor agridulce (dulce por haber pensado "bien" las cosas, amargo por invertir tiempo en algo que "ya estaba pensado").

Seguimos pensando..

[1] Con esto quiero decir que para saber cómo hacer testing en la práctica no alcanzaba con leer los libros. En ellos hablaban a un nivel de abstracción y nosotros debíamos trabajar a otro, principalmente por el nivel de madurez de nuestro cliente de ese entonces.