¿Pero para qué te complicas tanto? ¡Lo que queremos construir es un MVP sencillo!
Todos los que nos hemos embarcados en emprendimientos tecnológicos y nos hacemos cargo del desarrollo de Software para ese emprendimiento, hemos escuchado esa frase de muchas formas y en muchas oportunidades, pero
¿Por qué ocurre esta desconexión de expectativas entre los emprendedores? ????
Yo pienso que hay 3 razones que tienen mucho que ver con la forma de pensar y de abordar los desafíos que los tecnológicos tenemos:
1. Hablamos otro idioma. Nos cuesta transmitir el lado técnico del argumento a personas que no son técnicas. Como explicarle a un no tecnológico que hacer una arquitectura orientada a eventos es la mejor idea, pero requiere una fase de discovery y design mucho más larga comparado con un monolito en Java.
Cuando nuestro “socio no técnico” tiene una gran ansiedad por lanzar pronto y cuando los inversionistas están “respirando en nuestro cuello” para que salgamos al mercado esta conversación se hace aún más difícil.
2. Nos “engolosinamos” fácilmente. Hoy existe tanta tecnología realmente increíble y es de tan fácil acceso que nos convertimos en niños en una dulcería y queremos tenerlo todo.
Cuando esto sucede, realmente nos sumergimos en el maravilloso mundo de la tecnología y nos descontamos un poco de las urgencias, del time-to-market y otras cosas que también son importantes.
3. Nos rehusamos al trabajo desechable. Que mágico es el momento cuando escuchamos esa tan ansiada frase ..“El MVP fue todo un éxito, encontramos el product Market Fit!!” Es realmente una muy buena noticia, el problema es que viene acompañada de otra que para nosotros es muy mañana …”Ahora botemos a la basura el MVP y construyamos la plataforma de verdad”.
A los tecnológicos no nos gusta desechar nuestro trabajo y además somos muy optimistas, entonces cuando estamos construyendo un MVP siempre asumimos que tendremos éxito, por lo tanto, tomamos decisiones técnicas pensando en que ese MVP escale para soportar la operación real que esperamos tener.
¿Qué hacer entonces? ¿Cómo abordar esta incomodidad?
Aquí es cuando tenemos que recordar que además de programadores también somos ingenieros y también somos emprendedores. Como emprendedores pensamos en cosas como:
- ¿qué vamos a lograr para nuestros clientes?
- ¿cuándo vamos a estar en el mercado?
- y luego como developers pensamos en el “¿cómo vamos a construirlo?”.
Para abordar esto, hay 3 reflexiones muy simples.
Primero… “show me the data” ????
Tenemos que esforzarnos por tener claridad y data explícita al momento de explicar los tradeoffs de una decisión técnica. Cuando nos paramos frente a un inversionista y le explicamos que una arquitectura orientada a eventos es mejor idea que una arquitectura SOA es muy difícil para el inversionista aceptar nuestra decisión. Por lo general no comprende con profundidad lo que le estamos diciendo y cuando un inversionista ve poca claridad traduce eso en riesgo y el riesgo es algo que buscamos disminuir al momento de invertir.
Lo técnico debe estar siempre presente en un proyecto tecnológico, pero si nos paramos en los zapatos del resto por un momento, rápidamente veremos que es importante responder preguntas como por ejemplo:
- ¿Cuánto nos va a tomar lanzar el MVP con una arquitectura u otra?
- ¿Si seguimos la opción A, hasta cuantas transacciones soportamos vs la opción B?
- ¿Cuanto nos tomaría cambiar de A a B ya operando versus partir con B?
Segundo.. La tecnología es un acelerador y no un lastre ????
Cuando empezamos a tomar decisiones respecto a qué nube usar, que arquitectura, que entorno de ejecución, que estrategia de deployment, que lenguaje, etc, etc, etc.. a menudo nos encontramos con que alguna de esas decisiones nos va a producir un retraso y cuando esto sucede probablemente esa decisión no es la correcta.
Hoy los stacks tecnológicos que nos ofrecen las nubes modernas son tan poderosos, tan innovadores y están tan centrados en el developer experience que no hay espacio a que alguna de esas decisiones nos retrase. Cuando nos enfrentemos a retrasos producto de decisiones técnicas detengámonos a pensar si es o no la decisión correcta.
Tercero… No es necesario desechar nada cuando pensamos nuestros pasos bien ????️
Algo que me encanta de Amazon Web Services es que el esfuerzo de crear un proyecto en un monolito Java deployado en un servidor Linux versus crear el mismo proyecto dentro de un Container serverless y auto administrado con ECS+Fargate es prácticamente el mismo.
Pero la segunda opción tiene una maravillosa ventaja, la elasticidad.. tu entorno de ejecuciòn puede soportar 10 TPS y costar menos de USD $1 por hora o bien autoescalar hasta soportar 1 millón de TPS y costar USD $20 por hora, todo sin tener que reescribir ni una línea de código.
El código fuente es lógica, no es arquitectura y las nubes modernas permiten poner con poco esfuerzo nuestro código en diferentes arquitecturas que se auto administran y autoesclan sin esfuerzo.
No escribas el código fuente para un MVP pensando en desecharlo, sino que escribelo haciéndolo agnóstico del entorno de ejecuciòn, así podrás reusarlo cuando tu startup escale.
Alguien dijo una vez “programar es como ser un superhéroe con superpoderes”
Yo estoy muy de acuerdo, pero también pienso que en general a los super héroes solitarios les ha ido mal… como superhéroes nos va a ir bien en la medida que podamos conectar de manera fluida con nuestros socios e inversionistas, tomemos las decisiones correctas y no dejemos nunca de pensar como emprendedores.
