Lo perfecto es enemigo de lo bueno
Un buen plan ejecutado violentamente hoy es mejor que un plan perfecto ejecutado dentro de una semana.
La semana pasada, en el post Deadline Driven Development, hablábamos sobre las ventajas de trabajar con deadlines a la hora de desarrollar producto.
Esta semana, mientras hablaba con un colega de profesión, me vino a la mente de nuevo otra de las ventajas de las fechas límites: te evitan caer en la trampa del perfeccionismo.
Un ejemplo lo tenemos en esta misma newsletter. El simple hecho de tener que enviar un post cada domingo me fuerza a ser efectivo y no invertir muchísimo tiempo tratando de hacer el mejor post posible.
Mi objetivo es tan sólo escribir uno lo suficientemente bueno.
Lo perfecto es enemigo de lo bueno
La frase se le atribuye al filósofo francés Voltaire. La idea subyacente es que es preferible hacer algo en un tiempo razonable a dedicar una cantidad exagerada de tiempo buscando la perfección.
En la doctrina militar, donde literalmente se juegan la vida en el campo de batalla, encontramos una frase equivalente de uno de los generales clave en la derrota de Hitler en la Segunda Guerra Mundial:
A good plan violently executed now is better than a perfect plan executed next week. — George S. Patton
Esta lección la aprendí como se aprenden las cosas de verdad, palmando mi propio dinero hace 15 años. En esa época fundamos una empresa y, buscando la perfección, retrasé 6 meses el lanzamiento de nuestro producto. Cuando por fin lanzamos, rompió todas nuestras expectativas al alza, generando decenas de miles de euros de facturación desde el primer mes.
Y esos 6 meses que invertimos de más en alcanzar la perfección no estaban detrás de nuestro éxito. Podríamos haber lanzado perfectamente y empezar a facturar meses antes. Calculo que esa decisión nos costó al menos medio millón de euros.
Lo perfecto no sólo es enemigo de lo bueno. También puede ser terriblemente caro.
Pareto aplica aquí perfectamente. Llegar a la perfección, arañar ese último 20%, conlleva en muchas ocasiones el 80% del esfuerzo total. En un mundo dónde todo cambia a la velocidad de la luz, escoger donde invertir tu tiempo para maximizar tus oportunidades de aprendizaje puede suponer la diferencia entre triunfar y desaparecer.
En “La velocidad de iteración es una ventaja competitiva”, contábamos la historia de Paul MacCready y su aeronave Gossamer Condor.
Décadas después, en 1959, un magnate industrial británico de nombre Henry Kremer lanzó un reto a ingenieros de todo el mundo. Daría 50.000£ como premio, equivalentes a dos millones de libras hoy en día, al primero que fuera capaz de construir un aeroplano capaz de volar sólo con la fuerza generada por un ser humano.
Para obtener el premio, el artefacto debía completar un circuito en forma de ocho entre dos postes separados por media milla de distancia. Dobló la cantidad a 100.000£ al primero que fuera capaz de cruzar el Canal de la Mancha entre Inglaterra y Francia.
Durante cerca de dos décadas, decenas de equipos compitieron sin éxito por llevarse el triunfo, hasta que Paul MacCready, un ingeniero aeronáutico estadounidense decidió involucrarse.
MacCready observó que los otros equipos participantes seguían un largo proceso de desarrollo. Pasaban mucho tiempo diseñando y construyendo su aeronave, hasta un año de media. La ponían en la pista, se estrellaba, y volvían a comenzar el ciclo.
Nuestro héroe tuvo la intuición de que para resolver el problema y ganar el concurso, necesitaba poder iterar más rápido que el resto de equipos. Lo hizo construyendo un prototipo diseñado para fallar.
Mientras los otros equipos trabajaban por minimizar el riesgo, MacCready, sabiendo que el verdadero aprendizaje se produce en la pista, construyó su aeroplano con materiales ligeros como el poliéster, aluminio y alambre. Esto le permitía repararlo en muy poco tiempo tras cada intento, lo que reducía los ciclos de aprendizaje de meses a días.
Año y medio después, MacCready se llevó el primer premio con un prototipo llamado Gossamer Condor. Un año después, se llevó también las 100.000£ por cruzar el Canal de la Mancha.
Los rivales de MacCready buscaban la perfección. Este, sin embargo, maximizó sus posibilidades de aprendizaje a partir de sacar prototipos, probar, fallar e iterar. Esta es una de las claves de los mejores equipos y empresas de producto ahí fuera: optimizan para aprender.
El falso dilema del retrabajo
Una palabra que me pone en alerta en mis equipos cada vez que la oigo es “retrabajo”, refiriéndose a evitar hacer el mismo trabajo dos veces porque la primera no lo has hecho perfecto.
Soy ingeniero. Por naturaleza, tiendo a optimizar todo lo que hago. Hacer dos veces lo mismo por no haberlo hecho bien a la primera parece un crimen. Va contra todo lo que nos enseñan.
Pero si volvéis a la historia de MacCready, aquellos que perdieron la competición son aquellos que quisieron evitar el retrabajo haciéndolo perfecto al primer intento.
Retrabajar es la base de la experimentación. ¿Cuántas veces intentó Edison crear una bombilla funcional hasta que lo consiguió?
“I have not failed. I’ve just found 10,000 ways that won’t work.” – Thomas A. Edison
El verdadero problema del retrabajo no es el retrabajo en sí, si no la velocidad con la que sois capaces de iterar. El coste de tirar a la basura un esfuerzo de un día o una semana no tiene nada que ver con el de una funcionalidad que te ha llevado tres meses lanzar. Si tus ciclos de desarrollo son largos, tu problema no es el retrabajo, tu problema es la madurez de la compañía.
Evitar el retrabajo, la optimización prematura, lleva a situaciones cómicas. He visto iniciativas retrasarse años por tratar de evitar hacer el mismo trabajo dos veces. Años en los que le podrías ofrecer una solución a tus usuarios y que no lo has hecho para evitar incurrir en un supuesto doble coste futuro.
Donald Knuth, uno de los padres de la ingeniería informática, lo deja claro:
“Premature optimization is the root of all evil.” — Donald Knuth
Pero claro. Hay que tener mucha experiencia para decir a un equipo de ingeniería o a tu capa directiva, que el retrabajo puede ser bueno. Y también que tomar atajos para poder iterar a veces es necesario, porque esa velocidad que ganas aprendiendo es lo que te mantiene en el juego y con opciones de ganar.
Os animo a pasar este post a vuestros equipos y empresas e iniciar esa discusión. ¿Estamos optimizando nuestro tiempo para maximizar nuestros aprendizajes? ¿O estamos optimizando para supuestamente ahorrar retrabajo invirtiendo tiempo de más en hacerlo perfecto a la primera?
La respuesta a esa pregunta te puede dar pistas de la madurez de la compañía y hasta de su propio futuro. Y también del tuyo. Aquellas que no estén optimizadas para aprender tienen los días contados.