Cuando se trabaja en equipo notas bastante pronto qué compañeros son los que resuelven de forma más eficiente, los que te sacan de apuros ante cualquier asunto, los que tienen Acabativa como los llama Yoriento. No son los más inteligentes, ni los más experimentados ni los que tienen un título universitario de renombre. Son los más decididos, los que se deciden a empezar a cortar y tomar resoluciones. Los que se ponen el cuchillo en la boca y empiezan a avanzar, encuentren lo que encuentren.

En una gran número de ocasiones no queremos empezar a atacar un problema hasta no tener todos los datos, hasta no saber seguro qué hacer. El problema es que nunca podrás estar seguro. Solo estás buscando excusas en tu mente para empezar a trabajar fuerte en ello (mañana, cuando esté el tech lead será mejor día, seguro), para no decidirte por una de las opciones, y por tanto no correr el riesgo de equivocarte.

Mucho me temo que te vas a equivocar, tanto si lo pospones a mañana, a principios de mes, o al Q1, como si retrasarlo tu fuese a garantizar una ejecución perfecta. Pero no, casi nunca sabrás de antemano cuál es la mejor opción. Escoge la opción más «económica», la de menor coste o haz una prueba piloto/PoC, y mira los resultados. Seguro que aprenderás mucho más de ello que buscando excusas mentales para justificar por qué justo hoy no es buen día para empezar a teclear/diseñar/probar/construir.

Tampoco lo conviertas en un Spike eterno. Estos spikes o pruebas/investigación sobre un asunto han sido uno de los grandes males de Agile y los equipos de desarrollo. Suelen ser la excusa perfecta para darte tranquilidad mental y pensar que lo estás mirando, que estás en ello pero que todavía necesitas comprobar esto o aquello. Estas tareas de investigación deberían estar prohibidas si no entregan al finalizar un trabajo tangible, unas líneas de código o unos diagramas. Lo que sea que quiera que hagas, pero asegúrate de que te ayudan a atajar el problema, o incluso mejor, a descartar opciones.