No puedo asegurarlo pero tampoco tengo muchas dudas que la gente que trabaja en mi equipo piensa que soy gilipollas por “apretar” todo el rato con las fechas de entrega. Cada nueva cosa que arrancamos siempre digo lo mismo: “si podemos tener algo visible mañana mejor que pasado, pero lo ideal serían un par de horas”, “si dudas, mejor avanza” y otra serie de cosas que intento transmitir, habitualmente con poco éxito, aunque no será pos ser el brasas.
Cualquiera que trabaje en el mundo del software sabe por mucho que aprietes, da igual, tarde o temprano terminas inviertiendo el tiempo que se necesitaba. Como todo lo bueno, y no es diferente en esta industria, necesita mucho tiempo. Entonces, por qué soy el gilipollas que aprieta con el plazo, que negocia cada paso del proyecto, que pide buscar compromisos en la “calidad” todo el rato ? es muy fácil: en un producto como en nuestro la mayor parte del tiempo no sabes bien lo que estás resolviendo, la falacia de que sabes dónde tienes que ir es la peste de la industria del software, especialmente en el mundo startup.
Nosotros no somos una empresa que haga “commodity”, estamos haciendo algo que no es lo que hace la industria pero un poco diferente, tratamos de simplificar algo que lleva 40 años haciéndose de la misma forma. Las bases de datos han llegado a un punto donde ya no hay mucha mejora relativa a la mejora del hardware y nuestro plan es hacer que las cosas sean más fáciles. Así que si crees que sabes lo que realmente estás haciendo en un entorno así es que o confías mucho en ti o eres demasiado “junior” (odio este concepto pero lo pongo por hiriente)
“Apretar“ no es más que una forma de poner lo que estás haciendo delante del usuario (bueno, y delante tuyo también, que a veces es importante ver la mierda que has hecho) lo antes posible. Esto no es nuevo, es lo que llaman feedback rápido; en este caso trato de que sea fugaz, visceral, como cuando un músico saca la guitarra y toca, sin importar los fallos, un poco desafinado, lo que luego será una obra bien tocada, arreglada y perfectamente producida. La esencia es la misma, la canción la vas a reconocer, y si te gusta en crudo, te va a gustar “a lo grande”. El mejor ejemplo actual de esto es Tesla, el Cybertruck a nivel de standard de calidad de fabricación es absurdo, pero seguramente se dieron cuenta pronto que esa parte no es la importante (recomiendo este video donde explican el drama en detalle)
Cuesta, no es trivial plantear la mínima expresión de producto, desarrollar sabiendo que dejas cadáveres por el camino, mucha gente ni sabe ni quiere hacerlo pero es fundamental: si tardas 3 meses en poner en algo producción, has consumido el 15-20% de lo que dura una ronda de financiación de una startup, solo tienes 6 balas y te aseguro que 6 intentos son demasiado pocos. Y el desarrollo es lo de menos, es toda la cadena de marketing, ventas, etc que viene detrás tuyo. Del mismo modo, este tipo de “features” no se pueden desarrollar usando un proceso habitual, necesita que haya poca gente tomando decisiones, que al resto del equipo le “moleste” un poco, necesita que la política y las opiniones no estén en el camino (y ahora entiendes el porqué de la innovación en las grandes empresas)
La literatura no sirve aquí, el proceso tampoco, lo único que sirve es llegar cuanto antes para ver lo que hay y volver rápido a contar lo que has encontrado. Bueno, en realidad la literatura del software nos lleva diciendo años que tenemos que iterar rápido, pero nos empeñamos en montar castillos en el aire para intentar solucionar un problema demasiado complejo para arreglarlo proceso.
Por último, no entiendo a la gente que no disfruta del subidón de tener prisa por poner algo en producción :)
Muy interesante, Javi. Creo que es importante mantener ese nivel de compromiso por que el trabajo salga a la luz lo antes posible. Es una forma también de retratar nuestro propio desarrollo, como bien dices. Viendo lo que hacéis, doy por sentado que el nivel de calidad que se pedirá al final del proceso será muy alto. Siempre me ha gustado la búsqueda del performance en el software, así que Tinybird me parece muy interesante. Ese aspecto del desarrollo, el celo por el rendimiento, es algo que se ha perdido muchísimo estos últimos años y las nuevas generaciones ya casi ignoran por completo. Es muy fácil echar más CPU y más RAM.
También entiendo por qué desarrolláis así. Poca gente involucrada, poco ruido, pocas opiniones, poco manual. Procesos adaptados a la realidad de la empresa. Acuerdos en la generalidad y avanzar, iterar, corregir. Me recuerda a Basecamp.
Un saludo, y mucho ánimo!