Cuando me cuentan que un tipo les ofreció hacer una app para armar su negocio, una de mis primeras preguntas es:

— “¿Y qué te ofreció?”
— “Un 2% de la empresa”
— “Shiu… la estai cagando compadre…”

Seguir leyendo

El computín que tiene el 2%

El computín que tiene el 2% was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

La verdad es que cuando postulé no me tenía mucha fe. Soy ingeniero comercial, y a pesar de que tomé varios cursos de programación en la u y siempre me ha gustado harto el mundillo de las startups, nica pensé que podía llegar a quedar en una empresa full de desarrollo de software tan bacán como Platanus. Postulé igual, total no perdía mucho… y para mi sorpresa, quedé.

Primer Día

Ese día llegué 15 min antes, estaba bien nervioso, no tenía idea de qué iba a hacer o si me la iba a poder, era mi primera experiencia de desarrollo real en una empresa.

Entré a la oficina y me recibió el equipo entero. Siempre había tenido una imagen muy distinta de cómo sería mi primer trabajo. Me imaginaba todos muy formales, con camisa y corbata trabajando en cubículos apretados.

En Platanus no es así (en mi casa todavía no pueden entender que vaya con shorts y chalitas a la pega). Todos son muy buena onda, y da lo mismo si eres founder, developer o practicante todos trabajamos en el mismo lugar. De hecho no hay ningún puesto con nombre, todos se pueden sentar donde quieran y eso hace muy fácil integrarse rápido en el equipo.

Después de las presentaciones y el infaltable tour por el lugar, me dieron una mini clase de cómo funcionaban algunas de las cosas entretes que hay en la oficina, como Ham y Refreshments. Se me pasó rapidísima la mañana en todo este proceso de setup.

Ya con todo listo y antes de seguir con la próxima etapa, fui a prepararme un cafecito. Mientras esperaba la taza, entra la Jesús (que hasta ese minuto no la había conocido), se acerca a saludarme y me pregunta cómo estoy, yo medio nervioso respondo con un:

“Muy bien, ¿Y usted?…”

Primer día y ya la había cagado. No pasó piola. Slack estaba en 🔥

Hasta el día de hoy me molestan por haber tratado de usted a la Jesús.

El proyecto

A las 12 tuve mi primera reunión para hablar sobre el proyecto en el que trabajaría el resto del semestre.

Sorteo Amigo Secreto es una página bien conocida que tiene Platanus. Todos los años llegan millones de usuarios de todo el mundo y este año querían probar algo nuevo: Una plataforma para que los usuarios del sorteo pudieran encontrar regalo fácilmente.

Desde el día uno ya estaba motivado. Me identifiqué al tiro con el problema que queríamos resolver. Siempre he tenido dolores de cabeza cuando tengo que pensar en regalos para mis amigos, especialmente cuando se trata de un regalo para mi polola. Pero por lejos lo que más me motivó, fue la forma en que me hicieron parte del proyecto.

Algo que me encanta de Platanus, es que uno no viene solo a programar sino a resolver un problema. Me llamó mucho la atención que incluso como practicante, mi opinión y mis ideas eran importantes para la construcción del producto final. Mas encima lo que estaba haciendo iba a ser usado por miles de personas!

Resultados

Terminamos el semestre con algo en producción: el Bazar del amigo secreto (incluso me dejaron ponerle nombre). Tuvimos más de 220.000 usuarios!

En todo este proceso aprendí montón. Desde cómo trabajar con diseñadores hasta metodologías de desarrollo. Pero lo más importante fue aprender sobre cómo llegar a puerto con una idea a través de iteraciones pequeñas y mejoras continuas.

Lo más difícil de estudiar y trabajar part-time durante este proceso fue balancear bien los tiempos. Era tan entretenido el proyecto que se hacía fácil dedicarle más tiempo a éste y dejar un poco de lado el estudio. Pero eso mismo es lo que lo hace tan especial.

Esta experiencia me sirvió un montón para darme cuenta lo mucho que me gusta desarrollar software y crear productos bacanes. Así fue como terminé trabajando en Platanus, donde ya voy a cumplir un año. Jamás lo hubiese imaginado un tiempo atrás mientras estudiaba para mis ramos de finanzas en comercial.

Si te gusta la computación y te hace falta un empujón para saber si es lo que quieres hacer, te recomiendo 100% que postules al programa. Siempre estamos buscando postulantes y personas bacanes para que se unan al equipo!

Qué hace un Trainee en Platanus was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

No me malinterpreten. Cuando escribo esto no intento caer en el cliché de “Amiga eris seca hazlo público”. O quizás sí. La verdad es que quiero exponer algo que me ha estado dando vueltas en el último tiempo: para las mujeres en STEM, principalmente en el área techi, existe una tendencia a echarnos para abajo → vale decir, no aceptar y renegar nuestras propias capacidades.

El síndrome del impostor es algo que se da en mujeres, y es principalmente un problema de género, pues se explica en gran parte por cómo la sociedad inculca ciertos comportamientos o expectativas. Y muchas veces la sociedad se esmera en hacernos sentir que nuestra opinión no vale mucho o estamos equivocadas. Porque “no sabemos lo suficiente”. Pero ¿es realmente así?.

Es ampliamente sabido que el porcentaje de mujeres en roles técnicos es bajo. Un estudio realizado por Fundación Por una Carrera y Clio Dinámica Consultores determinó que las mujeres egresadas de carreras técnicas en Chile entre los años 2013–2017 era aproximadamente un 12% (frente al 88% de egresados hombres). No quiero ahondar en por qué hay tan pocas mujeres en STEM, si no que quiero ahondar en cómo hacer un mejor lugar para el pequeño 12% que decidió seguir una carrera en el área.

¿Si ya sabes programar no es eso un logro? ¿que hayas pasado muchos cursos en el área no es un logro?¿que tengas un título o que estés por sacarlo no es un logro?. Y no, no creo que sean situaciones atribuidas a la suerte. Pensamientos del tipo “ah, es que ese ramo lo pasé porque en la segunda prueba justo entró lo que había estudiado la hora antes, tuve mucha suerte”. STOP. Ese ramo lo pasaste por todo el contexto y trabajo que hay detrás también.

Volviendo a ese mismo tema, hay personas y personas: aquellos que les gusta dedicarse de lleno a lo que hacen y hacerlo perfecto (perfeccionistas) y otras más dispersas que prefieren dedicarse dependiendo de sus gustos o inquietudes en hartas cosas a la vez. Una alumna matea, que se preocupa de pasar bien sus ramos y que tiende a ser perfeccionista, ¿en qué minuto va a tener tiempo para aprender el último framework de moda de javascript?.

Muy probablemente esa alumna terminó el getting started de la documentación y no le dio el tiempo para seguir aprendiendo por los miles de quehaceres de la vida académica. Por eso si le preguntan “cachas X framework” te van a decir que no. Sin embargo, esa alumna pasó cursos teóricos mucho más difíciles. Continuar más allá del getting started es solo cosa de tiempo, porque la capacidad y background de conocimientos ya están ahí. Ya tienes los logros y tienes que partir validándote a ti misma para dar el siguiente paso.

Les recomiendo el libro The Secret Thoughts of Successful Women: Why Capable People Suffer from the Impostor Syndrome and How to Thrive in Spite of It — de Valerie Young. Para cualquier mujer en cualquier etapa de su carrera. Me gusta porque no es el típico libro bullshit de “¿cómo ser exitosa?” si no que es lo contrario: Ya eres exitosa, ahora date cuenta.

Hablemos un poco de emprendimiento

En 2014 solo existía un 3% de mujeres en cargos de CTO en EEUU, según un estudio de Forbes . Han pasado 6 años desde entonces y la situación no ha cambiado tanto, y bueno, no estamos en EEUU. En el paper del 2017 “Funding challenges of Latin American women start-up founders in the technology industry” se hizo un estudio con datos de StartUp Chile, donde se analiza que en general las mujeres emprendedoras prefieren no levantar capital en base a este tipo de inversión, y que esto podría ser una causa de la baja cantidad de postulaciones que existen (además de otros factores que se analizan también en ese artículo).

Un dato más reciente es que en Platanus Ventures, del total de postulaciones solo un 15% de founders o socias son mujeres. La diferencia aquí con este dato y los anteriores, es que ya no estamos enfocados solo al puesto de CTO, si no que podría ser cualquiera de los roles típicos de un socio en un startup. El número de mujeres postulando a Platanus Ventures con el rol de CTO es contado con las manos (un porcentaje cercano al 2%). A pesar de ser cifras bajas, tengo fe de que estos números aumenten.

Lo cierto es que mientras más mujeres emprendedoras y en cargos gerenciales hayan, más posible es lograr una igualdad real, pues nos acercamos más a la equidad (según algunos estudios algo antiguos sobre el área). Sin embargo, no es algo fácil, porque el área del emprendimiento al menos en Chile sigue siendo marcadamente masculina. En el mundo de emprendedores chilenos aún está muy marcado el “business man” de traje y corbata. Hay estudios que sostienen que una cultura de emprendimiento más andrógeno permite más inclusión de la mujer (esto lo tratan más en detalle en este artículo “Entrepreneur‐mentality, gender and the study of women entrepreneurs”, se basa mucho en las comparaciones de lo “femenino” y “masculino”).

Ya hablamos del éxito, ahora hablemos del fracaso

Si sólo con leer la palabra fracaso te duele el estomago, no eres la única. Hasta hace no mucho, era una palabra que me llenaba de un terror terrible. Sin embargo ahora hago un simple proceso mental: ¿cuáles son mis expectativas sobre mí misma?. OK, y si no las cumplo ¿qué pasará?. Muy probablemente nada. No se quemará mi casa, no se abrirá un agujero en la tierra, no moriré de combustión espontánea. De hecho, del fracaso puedes aprender y crecer aún más.

El miedo a fracasar siempre es una piedra de tope que impide avanzar. Sin embargo, creo que el verdadero fracaso es quedarte con esa incertidumbre del “¿qué pudo pasar?”. Partiendo desde el nivel más básico: “quiero decir algo pero sé que no me escucharán”, pasando por el “quiero postular pero sé que no quedaré” o “quiero emprender pero sé que fracasaré”. Es cierto que hay que ser realistas. Por ejemplo, ¿si sabes que algo fracasará, es porque la idea es mala o es porque tu crees que no das la talla?. Si es solo lo segundo, entonces dale con todo. Es mejor descubrir tus límites y aprender de ellos para seguir creciendo. Así puedes descubrir qué es lo que te falta para dar la talla. Y en el mejor de los casos, y el más probable, es que das la talla y sea un éxito.

Para terminar este popurrí de ideas

Finalmente para terminar quería contar una anécdota. El año pasado me contactó una reclutadora de Google. Fue una gran sorpresa que llegaran a mí, siendo que yo no postulé a nada. Me sentí muy alabada por ello. Luego del primer correo acepté hablar y busqué un poco cuál era el proceso de selección. Encontré varios tests estándar, nada del otro mundo (similares a las pruebas de ramos de Estructuras de datos o de Bases de datos). Era muy abordable, como una prueba cualquiera de la universidad.

Entonces me pregunté: ¿es el logro de mi vida ir a trabajar a Google?. En mi retrospectiva también venía el pensamiento “No, no, me estoy diciendo esto porque me da miedo fracasar en la prueba. OBVIO que todo el mundo quiere entrar a Google. OBVIO que es el camino”. Mientras más leía el material de estudio, más segura estaba de que daba la talla. Y así mismo más segura estaba de que Google no es lo que yo quería. Y no estoy loca por no quererlo.

El día de hoy sueño con lograr algo mejor para mi comunidad local. Como una persona introvertida (se me nota mucho ¿no?), hablar en público, voluntariados y reuniones sociales son actividades muy agotadoras. Sin embargo, de a poco trato de ser parte de la comunidad de forma más pro-activa, con el fin de ser un aporte.

Creo que es importante la sororidad entre mujeres. Creo que es importante ir derribando estereotipos de género. Creo que el sexo de una persona no es algo que condiciona tu capacidad como ser humano. Y creo firmemente que al seguir en el área techi con estos ideales (que muchos me han dicho, muy “idealizados”) quizás algún día llegue a hacer un cambio.

No me siento ni remotamente cerca de ser una role-model para las siguientes generaciones. Pero sí me siento capaz de hablar y dar consejo cuando alguna compañera lo necesite. Y si eres tan introvertida como yo (como para hablar o pedir consejo), mi consejo final es que estés segura de ti misma. Por muy cliché que suene, ¡empodérate!. Descubre qué es lo que te falta y sigue aprendiendo. Nunca pares, que no será en vano.

• Kuschel, K., Lepeley, M., Espinosa, F. and Gutiérrez, S. (2017), “Funding challenges of Latin American women start-up founders in the technology industry”, Cross Cultural & Strategic Management, Vol. 24 №2, pp. 310–331. https://doi.org/10.1108/CCSM-03-2016-0072
• C. Brush et. al. Women entrepreneurs: Bridging the gender gap in venture capital. The Diana Project, 2014.
• Miri Lerner, Candida Brush, Robert Hisrich, “Israeli women entrepreneurs: An examination of factors affecting performance”, Journal of Business Venturing, Volume 12, Issue 4, 1997, Pages 315–339, ISSN0883–9026, https://doi.org/10.1016/S0883-9026(96)00061-4
• Bruni, A., Gherardi, S. and Poggio, B. (2004), “Entrepreneur‐mentality, gender and the study of women entrepreneurs”, Journal of Organizational Change Management, Vol. 17 №3, pp. 256–268.

Cabras ¿Por qué nos tiramos para abajo? was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

Habían seleccionado a su startup en una aceleradora chilena. Al poco andar, tuvo una reunión con los encargados. Le informaron que tenía que cambiar lo que hacía su startup o no podía seguir en el programa.

— Pero cómo, ¿y qué voy a hacer?
 — Hay hartos temas interesantes… ¿por qué no haces algo con Inteligencia Artificial?

No podía creer lo que me estaba contando. Una aceleradora conocida aconsejando tan mal.

La tecnología

Este experto estaba aconsejando iniciar una startup a partir de una tecnología.

No tengo nada en contra de la IA. Tampoco contra ninguna otra nueva tecnología. Si hubiesen dicho que usen “páginas web” para empezar un negocio, estaría igualmente en desacuerdo. Blockchain, IOT o tenedores. Da lo mismo.

No puedes iniciar un producto con la tecnología como motivación. No si quieres que alguien lo use.

En los ’90 la tecnología de moda era Internet. Salieron miles de empresas que usaban la tecnología como excusa para lanzar un producto.

Ya sabemos qué pasó con eso. La burbuja puntocom. La gran mayoría murió. Muy pocas sobrevivieron.

Es como sacarse la lotería. En una de esas tienes suerte y le achuntas a lo que resulta. Pero yo no apostaría años de mi vida en eso. Demasiado improbable.

Por más sexy que se vea una tecnología, no es razón suficiente para empezar un producto.

La solución

Otro error muy común es enamorarse de la solución. Los famosos “productos en búsqueda de problemas”.

Un caso bien increíble es Juicero.

Juicero es una máquina que exprime jugo. Pero no solo eso. Es una máquina inteligente. Se conecta al WiFi, tiene una app para smartphone, te avisa cuando el jugo va a vencer, y un montón de otras cosas tecnológicas entretenidas.

Al principio costaba $700 dólares. Después bajó a $400.

Parece que hacer esta máquina fue un desafío ingenieril gigante. No por nada se demoraron 3 años desde que tuvieron la idea hasta que lanzaron el producto. Necesitaron más de $120 millones de dólares.

También vendían las bolsas que traían el jugo a ser exprimido por la máquina.

Y bueno, todo se derrumbó cuando Bloomberg sacó un video que mostraba que podías exprimir la bolsa con las manos.

Parece que alguien se había enamorado de la solución.

Por más bacán que haya sido la máquina, había una solución mucho más barata: exprimir con la mano.

Terminó siendo un problema por el que muy poca gente estaba dispuesta a pagar.

Y los que pagaron seguro se arrepintieron después de ver el video.

El problema

La mayor razón por la que una startup muere es porque no existe suficiente gente que quiera su producto.

Si empezamos un negocio desde la tecnología o desde la solución, lo más probable es que muera por esa razón.

Para empezar un producto lo más importante es partir resolviendo un problema. Sin ese elemento, va a fracasar tarde o temprano.

Ojalá sea un problema que tenga harta gente. Así el negocio puede ser grande.

Ojalá sea un problema que te guste resolver. Así duras harto tiempo intentando resolverlo.

Y ojalá sea un problema que tú mismo tengas. Así estás 100% seguro de que existe.

En Platanus Ventures nunca te vamos a pedir que uses Inteligencia Artificial ni Blockchain. Te vamos a empujar a que soluciones un problema. Algo que al menos un grupo pequeño de usuarios necesite con urgencia.

El resto es puro adorno.

No necesitas Inteligencia Artificial ni Blockchain was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

Un SAFE es medio difícil de entender, así que lo intentaré de explicar con un caso concreto.

SAFE significa: Simple Agreement for Future Equity.

Es un instrumento de inversión muy útil para startups que están en una etapa temprana.

Se trata de:

• El inversionista da X monto de plata ahora
• La startup promete que en el futuro (cuando levante plata) le dará una cierta cantidad de acciones de la empresa (no se sabe exactamente cuántas al momento de firmar)

La startup debe negociar dos cosas con el inversionista: cuánta plata va a poner ahora y el “Cap de valorización” (hay otros SAFE en los que hay que negociar más cosas. Por ejemplo, una “tasa de descuento”. En este post explicaré el SAFE solo con Cap).

La plata invertida y el Cap determinan cuántas acciones tendrá el inversionista antes de que se levante capital. Cuánto tendrá, viene dado por la siguiente relación:

Donde P es el porcentaje de la empresa al que apunta el inversionista.

En la práctica

Veamos un ejemplo.

Un inversionista A ofrece 65,000 USD con un Cap de 650,000 USD. El inversionista apunta a tener el 10% de las acciones antes del levantamiento de capital.

Por ahora, la startup recibe 65,000 USD para usarlos como quiera y el inversionista se queda con el SAFE (un documento).

¿Cuántas acciones podría tener el inversionista A (x)? Tenemos que ver la siguiente relación:

En humano: se debe cumplir que el número de acciones del inversionista sean el 10% del total antes de que un inversionista meta plata en una ronda de inversión. Ojo que las acciones x serán acciones nuevas. Los founders no le venden acciones al inversionista.

Es super importante que el inversionista aún no tiene las acciones. Se queda con un SAFE que equivale a una promesa. Legalmente, los founders siguen teniendo el 100% de la empresa.

Ronda de inversión

Hagamos un fast-forward.

Supongamos que al emprendimiento le ha ido bien, y un año después decide levantar plata. Quieren hacer una expansión agresiva, así que apuntan a levantar 20 millones de dólares a un pre-money valuation de 65 millones.

El lenguaje sería: “Quiero levantar 20 millones a una valorización pre-money de 65 millones / post-money de 85 millones.”

Se juntan con un inversionista B, y este decide invertir los 20 millones en la empresa.

Como resultado de esa operación surgen varias preguntas.

• ¿Qué porcentaje de la empresa tiene el inversionista A?
• ¿Qué porcentaje de la empresa tienen ahora los founders?
• ¿Qué porcentaje de la empresa tiene el inversionista B?

Para determinar el resultado final hay que recurrir a dos pasos. El primero es para ver cuánto tendrá el inversionista A, y el segundo para ver cómo quedará todo con la entrada del inversionista B.

Vamos a las matemáticas.

Paso 1

Supongamos que los founders son los únicos que tienen acciones y que son 1,000,000. Recordemos que el inversionista A puso 65,000 USD con un Cap de 650,000 USD.

Si honramos a la ecuación de más arriba, tenemos:

Si despejamos x , entonces llegamos a x = 111,111.

El inversionista A tiene ahora 111,111 acciones. Los founders se quedan con sus 1,000,000 de acciones iniciales. El total de acciones es 1,111,111.

¿Cómo influyó el Cap en esto? En el fondo, hizo que el dueño del SAFE pudiera comprar acciones de la empresa a un precio mucho más barato que el inversionista B.

Este escenario nunca es el resultado final, y nunca se “dejará hasta acá” en la vida real. Es solo un paso teórico para entender cómo queda todo después de la inversión.

Paso 2

El inversionista B decide invertir 20 millones de dólares. Ahora tenemos que hacer unos cálculos.

Tenemos:

Pre-money valuation = 65,000,000 USD (la valoración acordada)
Total raise = 20,000,000 USD (lo que invirtió el inversionista)

Ahora, tenemos que calcular el precio por acción antes de que el inversionista nuevo meta su plata.

Acciones totales = 1,111,111
Precio por acción = pre-money valuation / acciones totales = 58.5 USD

Como dijimos que el emprendimiento valía 65 millones de dólares, entonces el precio por acción es de 58.5 dólares.

El inversionista B decide invertir 20 millones de dólares, entonces:

Acciones inversionista B = 20,000,000 USD / 58.5 USD ~= 341,880 acciones

Perfecto, sabemos cuántas acciones le corresponden al inversionista B.

El resultado final sería como el de esta tabla:

Como puedes ver, los founders ahora tienen un 68.82%, y el inversionista A 7.65%. Tienen el mismo número de acciones, pero distintos porcentajes. Ambos diluyeron su participación con la entrada del nuevo inversionista.

Pero fue el tremendo negocio para el Inversionista A. Puso 65,000 USD, y hoy día tiene un 7.65% de una empresa de 85 millones de dólares. O sea, su parte vale 6.5 millones de dólares.

Not bad.

¿Por qué el SAFE es buena idea?

• El documento es super estándar, muy fácil y rápido de redactar. Y Combinator tiene un template en el que hay que cambiar el nombre de la empresa, el monto a invertir, el Cap, firmar y depositar la plata. Y ya está. Es muy rápido para un inversionista meter plata en emprendimientos así. Te evitas un cacho legal bien grande, porque en realidad no se hace ningún movimiento de acciones aún.
• El inversionista tiene algún grado de protección si la empresa vale menos que el Cap. Mira la siguiente sección. Igual, este no es el caso al que apunta un inversionista. Es como un premio de consuelo.
• Para los founders es muy fácil saber cuánto están cediendo de la empresa antes de la serie A.

Pero no se detiene ahí…

Si no has entendido el caso del ejemplo, te sugiero que lo entiendas bien primero antes de pasar para acá. Se vuelve más enredado aún.

¿Qué pasa si el pre-money valuation es menor que el Cap del SAFE?

En este caso, la fórmula de las acciones no corre. Ups.

Si el Cap es mayor, en el paso 1 el inversionista A se queda con el número de acciones que equivalen a monto_invertido / pre-money valuation. O sea, si tiene un SAFE de 1 dólar con un Cap de 10 dólares, y el pre-money valuation es 2 dólares, el Cap no corre. Como puso 1 de 2 dólares, en el paso 1 se queda con aproximadamente el 50% de las acciones.

Las acciones de los empleados

Cuando una startup está partiendo, usualmente se les ofrece equity a los primeros empleados. Un porcentaje de la empresa. Como hay pocas lucas, seguramente tienen menos sueldo, por lo que se les compensa con un cierto número de acciones.

¿Cómo queda el mono del SAFE cuando se meten esos sujetos?

No es muy distinto. Sus acciones se consideran common shares, como las de los founders.

Si te fijas, ahora habían más common shares (1,100,000). Por lo tanto, para lograr el 10%, al inversionista A le corresponden más acciones (122,222).

Recuerda que el esquema de acciones nunca va a quedar así, porque para que se termine el SAFE tiene que entrar un inversionista a meter plata por equity.

Más de un SAFE con distintos Cap

Imagínate el emprendimiento firma dos SAFE en distintos momentos.

El primero: 5,000 USD con un Cap de 25,000 USD (founders ceden el 20% de la empresa)

El segundo: 10,000 USD con Cap de 100,000 USD (founders ceden el 10% de la empresa)

En total, los founders han cedido el 30% de la empresa para levantar 15,000 USD.

¿Cómo queda el mono?

¿Post-money SAFE o pre-money SAFE?

Uf, me costó un entender esta.

Mi resumen es:

• En el pre-money SAFE, para calcular cuántas acciones le corresponden al dueño del documento, no se consideran las nuevas acciones creadas por los otros SAFE (o por otros documentos convertibles).
• En el post-money SAFE, sí se considera la cantidad de nuevas acciones creadas por los otros SAFE.

¿Qué implica?

Que con pre-money, los SAFE sí se diluyen entre sí al momento de convertir.

En el post-money no se diluyen entre sí. Solo se diluyen con el ingreso del new money.

¿Por qué es importante para los fundadores de startups?

Con el pre-money nunca se sabe bien cuánto porcentaje de tu empresa has cedido hasta ahora. Como los SAFE se diluyen entre sí, cuánto has dado depende de los SAFE que has firmado y de los que firmarás en el futuro.

Con el post-money, sabes perfecto cuánto porcentaje has dado, porque los distintos SAFE no se diluyen entre ellos. Es más transparente para todos. Lo malo es que los fundadores asumen toda la dilución y no se comparte con los dueños de los SAFE.

¿Quieres saber más?

Hay mucho que aprender acá. Si te interesa, lee esto:

• Post Money Safe User Guide de YC
• Documentos YC
• Understanding SAFEs and Priced Equity Rounds by Kirsty Nathoo
• SAFE Genie

SAFE: qué es y cómo funciona was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

Por la precisión del tiempo en el título se darán cuenta de que no estoy hablando de una estimación. Casi 2 minutos es realmente el tiempo que me tomó crear la típica API de blog posts con sus comentarios.

Los modelos:

class Blog < ApplicationRecord
 has_many :comments
end

class Comment < ApplicationRecord
 belongs_to :blog
end

Los endpoints:

GET     /api/v1/blogs
POST    /api/v1/blogs
GET     /api/v1/blogs/:id
PUT     /api/v1/blogs/:id
DELETE  /api/v1/blogs/:id

GET     /api/v1/comments/:id
PUT     /api/v1/comments/:id
DELETE  /api/v1/comments/:id
GET     /api/v1/blogs/:blog_id/comments
POST    /api/v1/blogs/:blog_id/comments

Suponiendo que me creen el “casi 2 minutos”, imagino que estarán pensado que en ese tiempo no se puede hacer nada o quizás, con mucha fe y velocidad, se podría algo como esto:

class BlogsController < ApplicationController
  before_action :set_blog, only: [:show, :update, :destroy]

  def index
    @blogs = Blog.all

    render json: @blogs
  end

  def show
    render json: @blog
  end

  def create
    @blog = Blog.new(blog_params)

    if @blog.save
      render json: @blog, status: :created
    else
      render json: @blog.errors, status: :unprocessable_entity
    end
  end

  def update
    if @blog.update(blog_params)
      render json: @blog
    else
      render json: @blog.errors, status: :unprocessable_entity
    end
  end

  def destroy
    @blog.destroy
  end

  private

  def set_blog
    @blog = Plop.find(params[:id])
  end

  def blog_params
    params.require(:blog).permit(:title, :body)
  end
end

A simple vista parece suficiente pero veamos algunos problemas:

• En cada endpoint se está especificando el status que debe retornar. Un poco verboso siendo que en un CRUD común y corriente un POST a la colección siempre devuelve un HTTP status code 201 y un GET a un recurso un 200, ¿verdad?
• En el update o create se están manejando los errores de validación ¿Eso quiere decir que en todos los endpoints donde tenga validaciones voy a tener la misma lógica? ojalá que no.
• Para devolver la respuesta se usa render json: .... Esto es un poco peligroso (a nivel de buenas prácticas) porque anima al desarrollador a no respetar una estructura. Es decir, invita a tener formatos de respuesta diferentes en los distintos endpoints de la API. Poco estándar, ¿no?
• El BlogsController hereda directamente de ApplicationController. Esto es malo porque, salvo que nuestra app sea solo una API, de ahí también heredan los controllers de nuestra aplicación web. El problema con esto es que si tenemos solo un controlador base (el ApplicationController), muchos métodos globales de la app no tendrán sentido en el contexto de la API y viceversa.
• No hay manejo de versiones. Quizás hoy no es un problema pero si mañana tenemos que sacar la versión 2 de está increíble y original idea, vamos a extrañar no haber manejado este problema de entrada.
• No hay documentación. Una API no documentada es una que no se usa. Nada más que decir.
• Y los endpoints de los comentarios?

• Finalmente, el mayor problema es que la API no funciona! ¿¡cómo!?, ¿¡dónde!? En el método set_blog escribí por error Plop en lugar de Blog . Sí, ni lo digan… Esto con tests no pasaba.

Imagino que a esta altura ya estarán pensando: bueno ya, ¿cómo hiciste para crear una API que no tenga los problemas mencionados anteriormente en ese tiempo? La respuesta es: ¡no lo hice! La gema Power API que desarrollamos en Platanus lo hizo por mí.

La prueba:

El resultado:

Explicación en pasos:

1 ~ Ejecuté el instalador de la gema:

rails g power_api:install

Es necesario correr este comando para tener el setup inicial sobre el que se apoyará nuestra API. Puedes ver el detalle de lo que se genera/instala/configura aquí.

2 ~ Generé el controller de blogs

rails g power_api:controller blog --allow-filters --use-paginator --version-number=1 --attributes=title body

Esto agrega el controlador:

class Api::V1::BlogsController < Api::V1::BaseController
  def index
    respond_with paginate(filtered_collection(Blog.all))
  end

  def show
    respond_with blog
  end

  def create
    respond_with Blog.create!(blog_params)
  end

  def update
    respond_with blog.update!(blog_params)
  end

  def destroy
    respond_with blog.destroy!
  end

  private

  def blog
    @blog ||= Blog.find_by!(id: params[:id])
  end

  def blog_params
    params.require(:blog).permit(
      :title,
      :body
    )
  end
end

El serializer:

class Api::V1::BlogSerializer < ActiveModel::Serializer
  type :blog

  attributes(
    :title,
    :body
  )
end

Los tests:

require ‘swagger_helper’

describe ‘API V1 Blogs’, swagger_doc: ‘v1/swagger.json’ do
  path ‘/blogs’ do
    get ‘Retrieves Blogs’ do
      description ‘Retrieves all the blogs’
      produces ‘application/json’

      let(:collection_count) { 5 }
      let(:expected_collection_count) { collection_count }

      before { create_list(:blog, collection_count) }

      response ‘200’, ‘Blogs retrieved’ do
        schema(‘$ref’ => ‘#/definitions/blogs_collection’)

        run_test! do |response|
          expect(JSON.parse(response.body)[‘data’].count).to eq(expected_collection_count)
        end
      end
    end

    post ‘Creates Blog’ do
      description ‘Creates Blog’
      consumes ‘application/json’
      produces ‘application/json’
      parameter(name: :blog, in: :body)

      response ‘201’, ‘blog created’ do
        let(:blog) do
          {
            title: ‘Some title’,
            body: ‘Some body’
          }
        end

        run_test!
      end
    end
  end

  path ‘/blogs/{id}’ do
    parameter name: :id, in: :path, type: :integer

    let(:existent_blog) { create(:blog) }
    let(:id) { existent_blog.id }

    get ‘Retrieves Blog’ do
      produces ‘application/json’

      response ‘200’, ‘blog retrieved’ do
        schema(‘$ref’ => ‘#/definitions/blog_resource’)

        run_test!
      end

      response ‘404’, ‘invalid blog id’ do
        let(:id) { ‘invalid’ }
        run_test!
      end
    end

    put ‘Updates Blog’ do
      description ‘Updates Blog’
      consumes ‘application/json’
      produces ‘application/json’
      parameter(name: :blog, in: :body)

      response ‘200’, ‘blog updated’ do
        let(:blog) do
          {
            title: ‘Some title’,
            body: ‘Some body’
          }
        end

        run_test!
      end
    end

    delete ‘Deletes Blog’ do
      produces ‘application/json’
      description ‘Deletes specific blog’

      response ‘204’, ‘blog deleted’ do
        run_test!
      end

      response ‘404’, ‘blog not found’ do
        let(:id) { ‘invalid’ }

        run_test!
      end
    end
  end
end

El resultado:

3 ~ Generé el controller de comments

rails g power_api:controller comment --attributes=body --parent-resource=blog

Este paso es similar al anterior pero, por haber especificado la opción --parent-resource=blog, el recurso se creará “nesteado” en blogs

class Api::V1::CommentsController < Api::V1::BaseController
  def index
    respond_with comments
  end

  def show
    respond_with comment
  end

  def create
    respond_with comments.create!(comment_params)
  end

  def update
    respond_with comment.update!(comment_params)
  end

  def destroy
    respond_with comment.destroy!
  end

  private

  def comment
    @comment ||= Comment.find_by!(id: params[:id])
  end

  def comments
    @comments ||= blog.comments
  end

  def blog
    @blog ||= Blog.find_by!(id: params[:blog_id])
  end

  def comment_params
    params.require(:comment).permit(
      :body
    )
  end
end

4 ~ Generé la documentación

rails rswag:specs:swaggerize

Gracias a la gema rswag que incluye Power API podemos generar, a partir de los tests, la documentación. Esto se hace con el comando anterior.

5 ~ Corrí los tests

bundle exec rspec spec/integration

Para probar que todo se creó correctamente.

6 ~ Levanté el server.

rails s

Para probar manualmente que todo funcionó bien :)

Ahora que parece que todo funcionó correctamente, repasemos una vez más los problemas que encontré en la versión inicial para confirmar que la gema los resuelve:

En cada endpoint se está especificando el status …

Ya no es necesario porque la gema incluye un api_responder que maneja el HTTP status code desde los HTTP verbs.

En el update o create se están manejando los errores de validación…

No se hace más en el controller ya que se usa un concern que viene incluido para manejar excepciones.

Para devolver la respuesta se usa render json: .... Esto es un poco peligroso (a nivel de buenas prácticas) porque anima al desarrollador a no respetar una estructura…

Ahora se utilizan serializers de la gema Active Model Serializers configurada para devolver respuestas con el formato de json api.

El BlogsController hereda directamente de ApplicationController …

Power API genera una estructura que permite que cada versión de la API tenga su propio BaseController que además hereda de uno pensado para el manejo exclusivo de APIs.

No hay manejo de versiones…

El manejo de versiones lo hacemos con la gema versionist.

No hay documentación…

La creamos con rswag.

Finalmente, el mayor problema es que la API no funciona!

Power API genera los specs ;)

Cómo crear una API REST en Rails testeada, documentada y con buenas prácticas en 1 minuto y 54… was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

El 3 de marzo se anunció el primer caso de COVID-19 en Chile. El día siguiente en la mañana en el Slack de la oficina se anunciaban un par de medidas que debíamos seguir por precaución, como por ejemplo no saludarnos ni de mano ni de beso en la mejilla. Fue raro, uno está acostumbrado a esas interacciones todos los días, pero será, es necesario.

El resto de la semana, sin ponernos de acuerdo, estuvimos casi todos trabajando desde la casa. Había ansiedad, nos lo estábamos tomando en serio. Ese viernes en nuestra reunión semanal lo conversamos y decidimos oficializarlo: estaríamos todos trabajando remoto hasta nuevo aviso.

Siempre hemos sido amigos del trabajo remoto, casi todos lo hacíamos al menos una vez a la semana y algunos compañeros van a la oficina solo un par de veces al año. Pero varios estamos acostumbrados a ir a la oficina bien seguido. Nos gusta vernos las caras, pelear con la cafetera, comer la comida de la Vicky (nuestra chef que nos cocina exquisito). El cambio no nos entusiasmaba mucho que digamos. Pero igual, concordamos en que era lo mejor, así que filo, démosle.

La pega

En la oficina tenemos una sala especial para reuniones o presentaciones. Ahí hay una tele con un aparatito de Google con una cámara para que sea llegar y presentar a los de la sala y a quién se conecte al meet. Para los que están ahí mismo es bien cómodo, aunque para los remotos de repente podía ser molesto cuando hablaba mucha gente junta con un solo micrófono en la sala. Ya no podíamos usar el aparatito, obviamente, así que cada uno de su compu desde la casa no más. No fue tanta diferencia igual, y apuesto que los que desde siempre han sido remotos están más que felices por el cambio.

Muchas reuniones de sprint con clientes ya se hacían por videollamada, pero a algunos tuvimos que convencerlos. La experiencia es un poco distinta, pero a menos que necesites “pizarrear”, todo bien.

El office y after-office

Aunque por el lado operativo no hemos tenido mucho problema, se nota un cambio anímico de repente. No poder salir mucho y el constante flujo de información sobre la situación a nivel mundial te tiran pa abajo igual.

Dado lo anterior y que no podemos ir a la oficina, tuvimos un par de actividades bien choras para hacer más amena la semana remota:

• Salió la idea de tener una Remoto Party™️. ¿Qué es eso? No sé. Una llamada pa conversar cada uno con su chela, jugar algún juego de mesa de alguna manera (?), que sé yo, la idea era hacer algo. Al final decidimos bajarnos todos un juego online.
  Teníamos un canal de slack, #pl-games, medio botado la verdad. Lo revivimos y nos organizamos ahí para ver que juego íbamos a jugar: Worms. Nos conectamos por Discord y como éramos hartos al principio alguien que estuviera jugando streameaba, así todos veíamos y comentábamos la partida. Incluso armamos dos partidas simultáneas, fue bien entrete.

• Jaime, en su afán de que todos seamos tan fan de Zalo Reyes como él, preguntó si había alguna manera de tener una especie de radio en que cualquiera de nosotros pudiera ir encolando canciones y que todos estuviéramos escuchando lo mismo. La respuesta fue Discord + bots.
  Así fue como salieron dos radios, una con música más de bus de paseo de curso/fogata y otra con música en inglés. Debo decir que mi playlist personal creció harto con este experimento.

Gran parte de las empresas techi tenemos la suerte de estar pintadas para el trabajo remoto. En estos tiempos difíciles es sumamente importante que aprovechemos esa oportunidad y aportemos de esta manera a disminuir las probabilidades de contagio. Siempre se puede hacer algo para hacer este cambio más llevadero 😄.

Si alguna empresa quiere implementar más trabajo remoto pero tiene dudas o necesita ayuda, felices de aportar por ese lado.

El trabajo en los tiempos de pandemia was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

Resultó ser que sí, por lo que me animé a escribir este post para compartirles la enseñanza.

Veamos este ejemplo en Rails

Tenemos 3 modelos AdminUser , BankMovement y BankMovementCheck. El último es un modelo intermedio para que un usuario pueda marcar los movimientos bancarios. Las relaciones son las siguientes:

Ahora, supongamos que queremos saber si un movimiento fue marcado por un user en específico: ¿En qué se diferencian estos dos métodos?

Como lo anticipa la introducción, la única diferencia es que a la izquierda de la igualdad se cambio un punto por un guión bajo.

Ok, ¿y cómo afecta esto a Boca?

Aunque la diferencia en código sea literalmente de 1 caracter, el significado detrás de cada método es muy diferente. Hint: El primero es mucho más ineficiente que el segundo.

Lo que realmente los diferencia es que en el primer método estamos cargando el admin_user en memoria para consultar por su id. En cambio en el segundo, solo se está accediendo al atributo admin_user_id de la instancia bank_movement_check (que se carga en ambos métodos). Es decir, nuestro método eficiente se ahorra la carga de un objeto completo.

Muy bonito, quiero ver los números.

Para ejemplificar lo significativa que es esta diferencia, veamos un análisis (no científico) en cuanto a consultas, uso de memoria y tiempo de ejecución.

Consultas

Nuestro método eficiente _marked_by_user? (con _ al inicio de su nombre) hace una consulta menos a la base de datos

Memoria

Utilizando gema benchmark/memory probamos el uso de memoria de ambos métodos, tanto al ser ejecutados por primera vez como para N ejecuciones consecutivas:

Podemos ver que el uso de memoria baja de 2.325M a 1.230M para la primera llamada al método, lo que significa un ahorro de casi un 50% 🤯. Por su parte, en llamadas consecutivas la baja es de 30.776k a 15.019K.

La abismal diferencia entre el primer intento y los siguientes se debe a que el objeto (o parte de él) permanece cargado en memoria/caché y no es necesario cargarlo completo como en el primer intento.

Tiempo

Ahora utilizando la librería Benchmark de Ruby, medimos los tiempos de ejecución:

Nuevamente el ahorro es significativo. El método ineficiente toma 0.022013s mientras que el eficiente 0.010956s , es decir, casi el doble de tiempo. Para los siguientes intentos, la diferencia es aun mayor, el método eficiente hace la tarea en aproximadamente un tercio del tiempo.

Nuevamente el caché y la memoria hacen que haya una diferencia importante entre la primera llamada al método y las siguientes.

Conclusión

Un ínfimo cambio en el código nos trajo un tremendo boost en performance. Imagina el impacto de esto en una app con cientos o millones de operaciones como esta. Lo importante a rescatar es que vale la pena estar atento a estos detalle y a qué está haciendo realmente nuestro código. Si bien este ejemplo es en Ruby, en todos los lenguajes y frameworks existen estas sutilezas como esta.

¿Cómo encontrar problemas de este estilo al desarrollar o probar?

• Siempre analiza la consola en búsqueda de consultas innecesarias
• Instala plugins de memory-profiling y performance en general, pueden ayudar a detectar métodos o endpoints ineficientes. En Platanus usamos Scout
• Intenta entender qué hace tu código a más bajo nivel
• Realiza Code Review, siempre pueden aparecer sugerencias como esta!

Por qué un _ puede ahorrarte un 50% de memoria was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pero los estándares no bastan, para asegurar la calidad tenemos un proceso de revisión de código. Como utilizamos GitHub, este proceso lo realizamos por medio de pull requests y es muy típico que, a pesar de usar linters, hayan detalles que se nos pasen al escribir código.

En esta dinámica de revisión, los comentarios y solicitudes de cambios abundan, muchas veces se trata de un refactor, sacar un typo, o mejoras menores, pero a la hora de programar esos cambios, una duda muy natural surge:

¿cómo deberían verse estos cambios en los commits del pull request?

El problema radica en que muchas veces los commits para arreglar esos cambios se ven como:

Pero no es deseable incluir ese tipo de commits en la historia de un repositorio, porque no tienen que ver realmente con lo que se cambió en la lógica del proyecto. Lo único que se logra es contaminar la historia y hacer menos útil ese historial.

No solo ensucian la historia, también dificultan la revisión, ya que cuando se revisa un pull request commit a commit, quien revisa puede encontrar un typo en un commit anterior, y después se da cuenta que subieron otro commit que lo soluciona. Todo un enredo que hace que la revisión sea menos fructífera.

Aquí es donde git nos hace la vida más fácil con rebase. Esta herramienta tiene múltiples usos, pero uno que encuentro particularmente útil es el de editar la historia de commits en una branch, y explicaré una forma de usarlo.

Existe el comando git rebase --interactive ‘<commit_hash>^’ que nos permite reescribir la historia en la rama actual desde el commit al que corresponde ese hash, hasta el último. Al ejecutarlo se abre en la consola un documento con la planificación para este rebase, que corresponde a una lista de los commits correspondientes.

A la izquierda de cada commit aparece una palabra que es la acción a realizar. Por defecto aparece pick que corresponde a seleccionar el commit sin cambiarlo. Si uno quiere cambiar la historia puede cambiar esa palabra por una serie de opciones: edit para modificarlo, reword para cambiar el mensaje, drop para descartar ese commit, squash para juntar ese commit con otro, entre otras.

Me voy a detener en edit que es el que más uso. Una vez que uno cambió en el documento la palabra pick por edit en los commits que quiere modificar, puede guardar y cerrar.

Comúnmente el editor de texto que aparece es vim, a menos que la variable de entorno EDITOR del terminal señale otro, por lo que para editar el texto se presiona la tecla i seguido de lo que se quiere escribir, y para terminar se puede apretar la tecla esc para luego escribir :wq o :x.

Cuando se cierra la planificación se ejecuta realmente el comando, y empieza la magia. Una forma fácil de imaginarse lo que hace el comando es que está viajando al pasado. Git se encarga de ejecutar la acción especificada en cada commit, partiendo desde el más viejo. Cuando la acción es pick no hace nada, porque el commit se mantiene, pero cuando la acción es edit, se detiene en ese commit, como si los commits posteriores aún no ocurrieran.

En ese momento es cuando uno puede editar lo que está pasando. El commit ya está hecho, pero git nos permite modificarlo in situ. Una forma es la siguiente:

1. Editar y guardar los archivos que queremos cambiar
2. Hacer git add de los cambios que queremos agregar
3. Añadir esos cambios al commit que estamos editando, por medio de git commit —-amend —-no-edit

Hay que considerar que realmente el commit ya se hizo, lo que se está haciendo es pararse justo después de que se realizó, y hacer un amend a este commit, es decir, añadirle más cambios, pero sin cambiar nada más, ni el mensaje.

Una vez que ya se está satisfecho con los cambios realizados, hay que indicar que puede continuar, y eso se hace por medio de git rebase —-continue. Así el comando sigue realizando las acciones que correspondan sobre los commits restantes, hasta llegar al último.

Otra de las acciones que mencioné antes es reword, que en vez de modificar el contenido de cada commit, permite modificar el mensaje. La acción squash en términos simples se puede usar para mezclar uno o varios commits que no se quieren mantener, en el anterior. Es una forma alternativa de mantener la historia limpia.

Ahora solo queda hacer push de la rama con los cambios, pero al intentar hacerlo es probable que sea rechazado:

No hay que preocuparse, se puede forzar con git push —-force o el más seguro git push —-force-with-lease origin <branch_name>, que evita pisar el trabajo ajeno y nos asegura subir cambios en la rama correcta. Disclaimer: no suelo recomendar utilizar comandos con flags como esos, pero como estamos en una rama distinta a la principal y los cambios son solicitados en el pull request, no debería haber problema. Igual tengo que recomendar usar el comando con cuidado y en la rama que corresponde, nunca en master.

En lo personal me gustan los repositorios ordenados y poder navegar por los commits. La gran gracia de usar rebase de la forma que vimos es que la historia del repositorio queda mucho más limpia que agregando un commit por cada mini cambio que nos pidan en la revisión. Para los obsesivos como yo, no solo es útil, es necesario.

Manteniendo la historia limpia usando git rebase was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.

Como la oficina empezó a crecer, tener que decidir cada día quiénes almorzaban se hizo un problema. Agustín lo solucionó haciendo la primera versión de Ham.

Ham (el mono) es un bot de Slack que elige a los que almorzarán la comida de la Vicky.

¿Cómo funciona?

El mono nos pregunta por Slack todos los días a las 3 pm si queremos almorzar el día siguiente en la oficina. Tipo 8 pm sortea quienes serán los que almorzarán.

Si quedas en el almuerzo, se te descuenta “karma”. El karma es como un sistema de “puntos” o una “moneda” de los almuerzos. No puedes decirle al mono que quieres almorzar si no tienes karma!

A medida que usábamos la primera versión de Ham, surgieron algunas oportunidades y problemas. Y como somos muchos computines en la oficina, empezamos a atacarlos 💻.

No sé cuándo terminamos de solucionar problemas y cuándo empezamos a hacer experimentos económico-sociales, pero la cosa se nos escapó de las manos (para bien).

Ham terminó siendo un laboratorio para probar dinámicas sociales con activos digitales. Les quiero contar sobre algunos de los experimentos, lecciones y situaciones que hemos vivido con el mono.

1. Confianza

Hubo un momento en que la confianza en Ham se estaba yendo a la cresta. La gente apostaba karma en cualquier cosa. Algunas personas aparecían mágicamente con mucho karma.

Había una sensación de guata de que había algo raro. ¿Por qué yo valoro muchísimo más mi karma que otras personas? ¿Por qué algunos están en modo casino todo el rato? ¿Por qué la gente en modo casino igual almuerza harto?

Con Griffero decidimos descubrir qué pasaba.

Implementamos que en el canal de Slack #karma-audit (yo le quería poner #karma-blockchain) se avisara cada vez que alguien traspasaba un karma o un almuerzo.

Dos horas después entendimos nuestra sensación de güata.

Se confirmaban los rumores. Cuando alguien se iba de la oficina, le transfería mucho karma a algunas personas.

Fome igual.

No estaba prohibido por las reglas. Nada ni nadie decía que no se podía hacer. Pero claramente alteraba el sistema. Algunos quedaban con mucho karma y tenían rienda suelta para gastar.

Pero bueno, desde que implementamos #karma-audit el juicio público hizo lo suyo y estas transferencias fueron mucho menos comunes.

Igual pusimos un límite de transferencia de 5 karmas al día por si acaso 👹.

Lección 1: la sensación de que todos jugamos con las mismas reglas es necesaria para que la gente confíe y le haga caso a un sistema.

Lección 2: en un sistema que maneja cosas con valor, las “zonas grises” se van a usar. No se puede esperar que todos actúen como uno quiere. Hay que ir cubriendo los casos especiales a medida que aparecen.

2. Orden y mercados eficientes

Si alguien quedaba para el almuerzo, podía pasar que al final no iba a la oficina o que le salía un almuerzo en otro lado. Obviamente, a esa persona le interesaba recuperar el karma que usó para asegurar su puesto. Entonces intentaba vender su almuerzo.

Así se empezó a armar un mercado de compra-venta de almuerzos.

Pero el proceso era super desordenado y tenía muchos pasos.

1. Tenías que avisar por algún canal que querías vender el almuerzo.
2. Otra persona tenía que ver ese mensaje.
3. Se tenían que poner de acuerdo de manera explícita entre ellos.
4. Había que escribir dos comandos para hacer la transacción: uno para transferir el cupo y otro para transferir el karma.

Siempre habían malos entendidos. No se respetaba el orden de los que decían que compraban, las transacciones no eran atómicas (alguien podía transferir el puesto y el otro no transferir el karma) y se perdía mucho tiempo.

Justo llegó Felipe a hacer su práctica. Decidimos atacar el problema. Armamos un equipo con Boris, Memo y Felipe, y desarrollamos un mercado de almuerzos automatizado.

Fue un éxito.

Hoy día es una de las funcionalidades que más se usa.

“Formalizar” el mercado con software nos trajo hartos beneficios:

• Se hizo todo más ordenado
• Perdemos menos tiempo coordinando
• Se respeta el orden de llegada
• Nadie puede hacerse el tonto y no transferir el karma

3. Escasez

Hace un tiempo, cuando uno empezaba a trabajar en la oficina, se te asignaban 1000 puntos de karma. El almuerzo costaba 1 karma. O sea, tenías para 1000 almuerzos.

Pero 1000 es como mucho. La gente apostaba en juegos de cachipún, resultados de partidos de fútbol, compraba almuerzos por 10 karma, etc. No había una sensación real de escasez.

Decidimos experimentar un poco acá.

De manera absolutamente totalitaria, con Griffero le bajamos el karma a todo el mundo. Si tenías 1000, después de la expropiación quedabas como con 30. Las proporciones entre todos se mantenían eso sí.

Arriesgado igual. Me sorprendió que nadie terminara muy enojado.

Pero resultó. El karma ya no se gasta en cualquier cosa. Es algo que la gente valora más.

Lección: la escasez de un activo es necesaria para que este tenga valor. Si no es escaso, lo más probable es que valga muy poco (hola Venezuela).

4. Experimento socialista

Pero ahora teníamos un nuevo problema. ¿Qué pasa si a alguien se le acaba el karma? Antes tenías 1000, no había que preocuparse mucho del futuro. Pero ahora todos tenían entre 20 y 40. Eso significaba que en 3 o 4 meses podíamos quedarnos todos sin karma y nadie podría almorzar. Ups.

Entonces, ¿cómo lo hacemos para que no lleguemos a cero karma? Evaluamos hartas opciones, pero nos la jugamos con que Ham juntara todo el karma que se gastaba en almuerzos y que lo repartiera entre todos a fin de mes.

Había un pequeño problema eso sí. Si proyectamos el sistema al infinito, pasaría que los que almuerzan poco van a ser muy adinerados, y los que almuerzan mucho van a tener 0 karma durante gran parte del mes.

Para solucionarlo decidimos estimular un poco el gasto. Pusimos un límite a la riqueza. Lo máximo que puedes tener es 40 de karma. Con esto creamos un incentivo para que los ricachones almuercen en la oficina y compartan con la gente. También se consigue que los pobres reciban más karma en la repartija mensual. Bien socialista igual.

A mí parecer funciona bien. El sistema parece estar en equilibrio.

5. Darle el poder a la gente

Durante un tiempo, hubo una sensación de que los que venían menos a la oficina no eran seleccionados por Ham para los almuerzos. Era fome. Había harta decepción en los que estaban trabajando harto remoto y venían a la oficina de vez en cuando.

Antes de lanzarnos a solucionar el problema, nos hicimos algunas preguntas. ¿Qué queremos arreglar? ¿Qué queremos mejorar? Nos dimos cuenta de que no podíamos definir una solución sin tener eso muy claro. Teníamos que definir nuestra “función objetivo” a optimizar. Nos fuimos en una volada media filosófica y llegamos a la conclusión de que el mantra tenía que ser:

Los que almuerzan poco en la oficina deben tener la oportunidad de almorzar cuando así lo decidan.

El almuerzo es un espacio para compartir con el resto de la oficina. Sería bueno que haya un poco de rotación de los comensales.

¿Cómo le damos más poder de decisión al usuario para aumentar su probabilidad de quedar en el almuerzo? Como somos un poco ludópatas, decidimos implementar apuestas.

Ahora, además de preguntarte si quieres almorzar el día siguiente, Ham te da la opción de apostar. Eso significa que puedes apostar 10 karmas si quieres para el almuerzo del día siguiente. Si apuestas más que el resto, quedas sí o sí!

Así se consigue un buen trade-off. ¿Quieres asegurarte el almuerzo? Entonces tienes que gastar más karma. Pero tienes que ser responsable, o te puedes quedar sin almuerzo hasta el mes siguiente! Ya ha pasado que alguien se queda sin karma por gastar mucho. Como diría el Tío Ben de Spiderman, “un gran poder conlleva una gran responsabilidad”.

Esta movida fue más capitalista. Le quitamos responsabilidad de decisión al Estado primate y se lo dimos a las personas.

¿Qué vamos a hacer ahora?

Hay algunas ideas dando vuelta. Por ejemplo, que uno pueda ganar karma por hacer buenas acciones en la oficina.

Pero ni idea cómo va a seguir esto. Hace 2 años era imposible pensar que Ham iba a ser lo que es ahora. Tampoco es fácil imaginar lo que va a ser en 2 años más.

Pero siendo bien honestos, el 99% del problema ya está solucionado. Estamos metiéndole mucha ingeniería a esto porque lo pasamos bien y porque nos gusta hacer experimentos con activos digitales. Hemos aprendido harto así.

Y quién sabe! Quizás con algún nuevo experimento esto se transforma en algo que se pueda vender.

Si te interesa saber cómo está funcionando Ham y los almuerzos ahora, puedes entrar a La Guía de Platanus a mirar.

¿De dónde sacamos tiempo para hacer estas cosas? En Platanus los viernes los dedicamos a hacer cosas que nos hagan una mejor empresa. Ham cae en esa categoría.

Qué hemos aprendido de un mono que pone las reglas en la oficina was originally published in Código Banana: El blog de Platanus on Medium, where people are continuing the conversation by highlighting and responding to this story.