Vivir del cuento 19 - Radio edit

Hablamos de definir objetivos y os cuento mis no-avances con el #BuildInPublic.

Nota: Archivo

Este texto forma parte de la primera temporada de la newsletter "Vivir del cuento y no morir en el intento". En diciembre de 2022 Revue, el servicio que alojaba la newsletter, cerró. Lo conservo aquí como archivo histórico.
Cuando tienes hijos te das cuenta de que su educación se hace eminentemente asumiendo que ellos van a tener una vida larga y productiva.
De hecho hacer lo contrario se considera ser mal padre.
Vamos, que no puedo decirle al niño de tres años "no te líes, suda del brócoli, aliméntate a base de papas y birra y a la mierda lo de ir al colegio, total cualquier día te cae una maceta a la cabeza y te quedas yerto. ¡La vida son dos días!".
No. Lo que haces es martirizarlo para que coma bien y vaya a la escuela para aprender y ser un miembro productivo de la sociedad.
Porque asumimos que va a vivir mucho tiempo. Que su vida será fructífera y feliz. Que los sacrificios de ahora reportarán bienestar futuro.
Y es lo razonable a todas luces, pues sabemos que si al final tienen esas vidas largas y productivas, les habrá resultado muy ventajoso. Y si por lo contrario viene la guerra atómica y se nos lleva a todos, pues, sinceramente, da bastante igual lo que hayas hecho.

Con los proyectos en los que trabajamos hacemos muchas veces lo mismo. Incluso proyectamos sentimientos sobre ellos, com si fueran nuestra verdadera prole.

Nos enamoramos de conceptos abstractos inanimados tan absurdos como una release de un juego o un SaaS de gestión de almacenes.

O, peor todavía, un subsistema que hemos montado para definir ciertos movidotes con un DSL basado en Brainfuck o cualquier otra tecnofumada esotérica digna del Hall of Fame de la sobreingeniería.

Queremos que sean perfectos. Que huelan a clean code. Que superen el listón irrealizable de los gurús del TDD y el SCRUM. Que chequeen todas las casillas. Que sean ejemplo y referencia de código perfecto, capaces de sobrevivir inmaculados de aquí al advenimiento de la singularidad.

Y la realidad es que un proyecto tecnológico tiene algo que no tiene (normalmente) un niño.

Tiene objetivo.

Y el esfuerzo a volcar sobre él está sujeto a y definido por este objetivo.

Ni más, ni menos. Si cumple el objetivo, el proyecto ha sido un éxito.

A nadie le importará nada más.

Si tu proyecto genera >2K€ al día con un archivo PHP dejado caer en un VPS, sin frameworks, sin tests, sin ni siquiera una triste clase, a nadie le importará.

Embedded tweet

Cómo definir un objetivo

O mejor.

Cómo no definir un objetivo.

Te voy a poner algunos ejemplos. De objetivos. Objetivos que están mal. Que no deberías usar a la hora de iniciar un nuevo proyecto. Objetivos que te llevarán inevitablemente a tratar tu proyecto como un hijo y no como lo que es, algo que tienes que hacer:

El objetivo de este proyecto es que me solucione la vida.
El objetivo de este proyecto es comerse un 10% del mercado potencial de trescientos billones de euros. Y forrarme.
El objetivo de este proyecto es lograr un monthly recurring revenue de dos mil pavetes y vivir del cuento.
El objetivo de este proyecto es comerme el desarrollo inicial pero luego vendérselo a veinte y retirarme al caribe.

¿Por qué están mal? ¿Por qué te llevarán por el mal camino?

El primer motivo es que no son útiles.

Son objetivos puramente aspiracionales. Carecen de contenido, de forma, de medios, de concreción sobre cuál será el resultado particular.

El segundo motivo es que son excesivos. No son realistas. Pixen alt.

Pa los que no son del terreno

La diferencia entre lograrlos o no es demasiado significativa. De hacerlo, tienes la vida solucionada. De lo contrario habrás quemado cientos de horas en un proyecto sin futuro, probablemente renunciando a otras oportunidades por el camino y castigando tu vida personal y salud.

Hay demasiado en juego. Si en la habitación de al lado tuvieses a tres señores del departamento de gestión de riesgo sentados, los tendrías con taquicardia. Alguno ya muerto en el suelo de la impresión.

El tercer motivo es que ni se huele cómo va a ser su ejecución. Dejan el camino en el aire como el proverbial ejercicio al lector.

Y finalmente, el cuarto motivo, es que no se vislumbra ningún horizonte temporal. No hay plazos ni se contemplan criterios concretos para decidir cuando es oportuno abandonar.

Entonces, ¿cómo deben ser tus objetivos?

Te lo resumo en cuatro puntos, que son la concreción de los cuatro problemas anteriores. Los objetivos útiles son:

Cercanos y acotados en el tiempo — Un objetivo a largo plazo será pasto de las incertidumbres que están por llegar y tenderán a extenderse indefinidamente.
Asumibles — La ejecución del objetivo debe ser factible dentro del tiempo disponible y la capacidad de aquellos que lo implementarán.
Realistas — Los resultados esperados deben estar alineados con resultados observados anteriormente y ser razonables. No podemos inventarnos un resultado. Debe ser consistente con lo que sabemos.
Procedimentados — Al objetivo debe acompañarlo siempre la planificación de su ejecución. El procedimiento general para llevarlo a término.

Vamos a poner algunos ejemplos que cumplen los requisitos anteriores:

El objetivo es validar una idea de SaaS creando un pequeño MVP en un stack que domino bien para sacar al mercado el mes que viene y para hacerlo voy a basarme en la implementación de un proyecto similar que hice el año pasado.
El objetivo es hacer una campaña de mailing a nuestros clientes para determinar si hay interés en una nueva funcionalidad de nuestro producto. En tres semanas determinaremos conclusiones.
El objetivo es implementar una nueva funcionalidad en un producto existente que sabemos es del interés de uno de nuestros clientes, que nos ha descrito en detalle sus requerimientos. Nuestro deadline es en dos meses.
El objetivo es experimentar con una nueva tecnología reimplementando una herramienta que conocemos en profundidad y apoyándonos en el manual. Dedicaremos 30 horas al proyecto.

En resumen, plantea tus objetivos siempre de forma incremental. Con horizontes temporales concretos y cercanos. Con resultados realistas, razonables. Empleando métodos conocidos o suficientemente abarcables. Y siempre de forma que el fracaso no sea catastrófico.

Rinse and repeat.

No pixes alt.

#BuildInPublic

Os comenté la semana pasada que me metía de lleno con un nuevo proyecto para montar en público. Basado en Twitter.

¿Cómo ha avanzado?

Pues poco.

Pero bueno, al menos no es cero. He validado que es viable implementar log-in con Twitter y la extracción de los Tweets de tu timeline en el stack que he escogido.

Iré actualizando, aquí y en Twitter, conforme vaya implementando nueva funcionalidad.

Sanseacabó

Hasta aquí la newsletter de hoy, que es algo más corta que las anteriores, en particular en la sección de #BuildInPublic.

Tomárosla como un radio edit de lo que, si consigo sacar algo de tiempo, está por llegar.

Me refiero a aquello de de vivir del cuento, que es de lo que va el asunto.

Porque de eso va la newsletter, en teoría.

Y yo mientras aquí haciendo de libro de auto ayuda para middle-management venido a más.

Sigh

Nos leemos pronto.