Hiring En Un Startup

Hace unos meses escribía sobre cómo era la experiencia de hacer crecer un equipo en una startup y hablaba un poco sobre el tema del hiring. Si estás leyendo esto seguramente habrás escuchado en más de una ocasión “es imposible encontrar buenos técnicos”, “los buenos están todos pillados”, “hay una burbuja y todo el mundo quiere cobrar demasiado” o “tardo meses en contratar a alguien”.

Ok, es verdad, el mercado está mal, por varias razones:

• La obvia, hay poca gente y mucha demanda.
• Hay mucha gente muy sobrevalorada y eso hace que los salarios suban como la espuma (y por si acaso lo estás pensando, yo me incluyo en ese grupo)

Dicho esto, contratar no es imposible, símplemente es difícil, como vender tu producto, pero mientras la mayoría de startups tienen un proceso de venta o desarrollo definido (bueno, ejem) no lo tienen para el hiring. Es curioso, el asset más importante de una empresa es la gente, y por tópico que suene, es una realidad como la catedral de Burgos.

Dejadme que lo repita de nuevo, la gente en una empresa es lo más importante, así que si tienes 200 mil millones de buenas prácticas en el código, 5 herramientas de lead generation antes que alguien de recursos humanos cuidando a tu gente (y cuidar a la gente no es solo que les llegue la nómina) es que lo estás haciendo lo siguiente a mal.

Ahora déjame decirte algunas cosas que he visto durante estos últimos 6 años en CARTO relacionados con el hiring.

El qué

Primero, no estás apuntando a gente dentro de la zona central de la campana de Gauss, estás buscando en los laterales. Y para contratar a esa gente no valen cuestionarios típicos, preguntas manidas o procesos normales. No eres el empresote que contrata a miles de desarrolladores y que te permite jugar con la estadística y en donde una persona significa una mejora en un equipo pero realmente tiene poco impacto global. Quieres contratar a gente muy buena, con chispa, que impacte en tu empresa.

Como cuando vendes un producto quieres que todo sea inbound (esto es, que vengan a comprarte) o por referal (que te recomienden). Y esto se consigue muy fácil, teniendo un buen producto. Dicho de otra forma, tienes que tener una empresa que guste y funcione bien. Esto atrae a gente buena y la gente buena quiere trabajar con gente mejor aún. En CARTO la mayoría de hiring inicial se hizo tirando de contactos, de gente con la que queríamos trabajar.

El cómo

No sólo se vende teniendo un buen producto, tienes que saber ponerte donde toca para que te vean y además diferenciarte. Necesitas tener una estrategia para posicionar el hiring.

Tener una estrategia no es poner 200 tweets o 15 mensajes en linkedin con “BUSCAMOS NODEJS DEVELOPER”. No. Es algo que se construye con los años, es buscar los sitios donde están las personas con las que tienes feeling, es tener un mensaje consistente durante los años, construir una red de gente alrededor de tu empresa, etc. Y ojo, lo del feeling parece algo secundario en el mundo técnico, pero en mi experiencia los equipos que funcionan mejor son en los que hay “feeling”. Te dirás, este gilipollas me dice “feeling” y se queda tan ancho, qué tal si lo describes. No puedo, seguramente me falte experiencia para materializar eso, pero google se hizo la misma pregunta y sacaron algunos resultados

En CARTO la estrategia siempre ha sido un bastante agresiva, nada de gilipolleces de frameworks del momento, nada de recetitas. Nosotros hacemos tecnología y queremos a gente que quiera hacer tecnología y no perder el tiempo siendo el mago de la tecnología del momento o que sepas responder a las preguntas de entrevista de google como el mejor del mundo.

Cuando tu gente vaya a dar charlas tiene que tener claro como orientar el mensaje, cuando se pongan ofertas tienen que seguir la misma linea, las entrevistas, a qué eventos vas, qué patrocinas, qué tuiteas, todo. Y esto no se hace con una documento interno llamado “hiring guidelines” (que no estaría de más)

Pero llega un momento que no vale con tener inbound, tienes que salir a buscar a la gente, bien porque necesites mucha gente o porque tus contactos se te han acabado. Y aquí tienes que tener un recruiter. Sabemos que el mercado de los recruiters está mal, pero está mal porque hay gente que no son profesionales, así que contrata gente profesional, que sepa establecer la conversación con un desarrollador (no un puto correo automático que va a hacer lo contrario a lo que esperas). En CARTO hubo un salto de un orden de magnitud en la calidad del proceso gracias a la llegada de Justyna, y no solo hablo de la calidad de la gente, hablo de la rapidez del proceso, salarios, seguimiento, etc… que da para otros cuantos posts y que en parte están resumidos en este blog post de Félix López sobre el proceso de hiring

El outbound es cosa de todos, de nuevo, si la gente no está preocupada con quién va a trabajar es que tienes un problema. Personalmente entrevisto a todas las personas que llegan a CARTO, pero la decisión no es mía, es del equipo que va a trabajar con él y son ellos los que tienen que sentir ese feeling.

Además de todo esto, tienes que ser un poco diferente, algunas de las cosas que yo considero importantes (que tampoco son novedosas, pero funcionan)

• Que se te conozca por algo y que no sea porque usas “el framework del momento”. Amigo, alguien que viene por un framework se va a ir por otro.
• Sé un poco creativo con las pruebas. Nosotros antes de llegar a la entrevista ponemos una prueba sencilla, algo así que motive y no lleve mucho tiempo y divierta (mi solución aquí). De esta prueba recibimos soluciones de gente que no estaba buscando trabajo.
• Si no hay un meetup de algo que te interesa, organizalo, vendrá gente que esté interesada.
• Conferencias: en general no me gustan las conferencias, en la mayoría el objetivo es difuso, muchas charlas aceptadas por el título o el ponente. Mucho mejor ir a una conferencia con poca gente, con temas muy claros que una multitudinaria.
• Intenta tener un blog técnico o usa los blog personales de la gente del equipo. No hay cosa mejor que dar voz a alguien de tu equipo en el blog/twitter/lista de correo oficial de la empresa. Esto se puede ampliar a “da visibilidad a tu gente” CARTO tenemos un blog técnico, es un poco durillo (porque así queremos que sea), pero funciona.
• Open source. Recuerda que poner algo en github NO es open source. En general si tienes algo open source y haces y deshaces basado exclusivamente en lo que tu empresa quiere/necesita, NO es open source, es que no estás haciendo open source.

Y sobre todo, contrata buena gente por encima de gente técnicamente buena.

Escalar El Equipo Tecnico En Una Startup

Hacer crecer un equipo técnico parece fácil a priori, hay unos 200 millones de blogpost sobre el tema y en general los desarrolladores tenemos tendencia a ser optimistas, en esto también. Estoy seguro que comparado con hacer crecer un equipo de ventas o de marketing es coser y cantar.

Sin embargo, a pesar de haber leído esos blogposts, libros y demás, hay algunas cosas que hemos aprendido en CARTO que puede que te sean útiles si piensas hacer crecer un equipo de 4 adolescentes a un equipo que funciona como un tiro.

Un equipo es algo así como una persona, pasa por la fase de crío, pasa a ser un adolescente, después a tener pareja e hijos, posiblemente pase por una etapa de madurez, jubilación y muera. En CARTO se podría decir que acabamos de tener hijos.

Aquí os dejo cada una de las fases por las que hemos ido pasando, con algunos consejos en forma de retales.

Cuando sois 4 fulanos dándole a la tecla sin control (recien nacido)

Aprender inglés cuando eres un niño es coser y cantar, cuando tienes 40 es un infierno, ya no estás para gilipolleces y tienes un montón de cosas que la sociedad te dice que tienes que hacer. Así que más vale que lo fundamental quede claro cuando sois 4, con 40 personas en un equipo no va a ser tan fácil. Estas son las cosas que yo haría si empezase desde cero:

• Establece los patrones básicos, aunque te parezca matar moscas a cañonazos: control de versiones, testing, integración continua, deploy automático, trabajo en ramas. El test de Joel es un buen punto de partida (aunque es un poco killer). En serio, montar esto y acostumbrarse es 1 semana.

• La elección de la tecnología base puede parecer importante, en mi opinión no lo es. Podría parecer que escoger el último framework o la última tecnología va a ayudarte en el hiring, pero:
  • Si alguien va a un proyecto por la tecnología y no por el proyecto tienes que pararte a pensar si de verdad quieres gente tan junior. Amigo, estás poniendo el cimiento del chiringuito, más te vale poner unas buena base.
  • En el futuro la tecnología importa básicamente nada, esto es, lo que marca la diferencia es lo que haces con ella. Repito, la tecnología que uses ahora no significa absolutamente nada. En la due diligence técnica que hizo el CTO de accel antes de la ronda B de CARTO no preguntó ni una sola vez por el lenguaje de programación ni frameworks (lo que preguntó lo dejo para otro post)
  • No confundamos tecnología base con la tecnología que es clave para el negocio. Salvo excepciones el lenguaje de programación o el framework no lo es. Eso no quiere decir que no tengas que controlar bien el lenguaje y los frameworks/herramientas que uses.
  • Vas a tener oportunidades de cambiar todo unas cuantas veces, así que no te preocupes.

• Aprende a trabajar con proyectos de otros. Haz que sea una práctica habitual el usarlos, valorarlos y entenderlos. Comerciales u open source.

• En equipos de este tipo el KPI suele ser la velocidad. La velocidad en los equipos de desarrollo es la peor métrica posible. Chaval, un equipo de 4, apenas empezando a desarrollar el producto, es rápido como el mismísimo diablo aunque pienses que eres lento (y cuando crezcas lo entenderás). La mala hierba crece muy rápido en la tierra bien abonada. Así que preocúpate de hacer que las cosas que haces son las correctas y haz que todo el mundo sea MUY consciente de ello. Tu gente debe ser crítica al extremo, nada de chiquilladas de “esto mola, lo metemos en un fin de semana”. De otra forma estarás cavando tu tumba a ritmo de agile.

• Es tan fácil añadir una gilipollez inútil a un producto que si no entrenas a tu gente para tener alergia vas a pasarlas muy putas. Esto parece que es cosa de Product managers (sí, esto te suena a consultora y tú no los necesitas, tranquilo majete en tu sillón) pero, tío, tienes gente que es capaz de entender conceptos complejísimos, enseñarles a parar y pensar no es tan difícil. Lectura obligada aquí el post del amigo txarly sobre “como lanzar un proyecto sin una línea de código”

• La gestión de frustración es crítica: hay bugs, las cosas se caen en producción, hay días que hay que tirarlo todo, nunca se puede hacer todo lo que uno quiere así que:
  • Aprender a priorizar, todo el mundo debe saber qué es su prioridad máxima. Y si no sabe debe preguntarlo.
  • Nunca hay tiempo para hacer las cosas bien. El tiempo es como el dinero, no te regalan, tienes que salir a por ello y lucharlo. Un comercial no va a llegar y te va a decir “Acabo de decir que no a este deal para que hagas este refactor que tenías tantas ganas de hacer”.

En esta etapa el ser un pequeño dictador es posible que sea la mejor opción. Si juntas a 4 desarrolladores en una habitación se van a poner a discutir sobre espacios versus tabs (no importa lo senior que sean, hay gente que no se da cuenta que usar tabuladores es de otro siglo). Alguien que tome las directrices, buenas o malas es mejor siempre tener una directriz a no tenerla. Y más te vale tener directrices en todos los temas importantes.

Una de esas directrices es la gestión de proyectos. Usa kanban, waterfall, agile o lo que te salga de las narices, pero usa una cosa clara y que todo el mundo sepa cómo lo haces.

Si eres ese pequeño dictador, machaca todo el rato con las cosas importantes (entre otras cosas porque así te ayuda a aclarar las cosas importantes) hasta que la gente lo tenga interiorizado. Ese es el germen de la cultura que se diluirá poco a poco cuando vayas creciendo pero que servirá como base.

Recuerda, ahora es cuando casi todo cuesta casi nada, hazlo aunque parezca una gilipollez que no necesitas.

Cuando ya sois un equipo de fútbol con suplentes

Las cosas van como un tiro, sois los putos amos y decides hacer crecer el equipo unas 10-15 personas. Todo es felicidad, estás en la adolescencia, qué esperas?

Cosas que van a pasar:

• La gente se empieza a frustrar porque no saben absolutamente todo lo que está pasando
• Empieza a haber más especialización
• Problemas de comunicación empiezan a salir
• “Qué lento que vamos”, “tenemos que ir más rápido”

Además la empresa ha crecido un poco, hay ya alguien vendiendo, parece que hay una persona escribiendo blogposts y el fundador ahora ya firma como CEO y no como “developer and coffee addict” en twitter. CARTO es un poco especial, fuimos galardonados con el premio de “la empresa más disfuncional en ventas que nunca habían visto”

• Si te van a meter gallina, antes de anunciar empieza a contratar gente técnica. Lo creáis o no hay gente que se mueve casi solo por dinero. Aún no estás en la fase de querer ese tipo de gente, te faltan otros 30 ó 40 empleados aún.

• Aquí necesitas ya un documento y fase de onboarding, cada persona nueva tiene que aprender, así que invierte en que sepan dónde poner los pies los primeros días.

• Enseña a tu equipo técnico a tener un par de bemoles. Fundamental para tratar con gente que su trabajo es convencer a otros. Importante también para saber tragarse su orgullo.

• El management: un día alguien llega y dice, “oye, a lo mejor deberíamos ir pensando en tener alguien que gestione un poco”. Entonces coges al mejor desarrollador o al que parece que siempre tiene más iniciativa y lo pones a gestionar:
  • La gestión no es mala pero es un trabajo muy diferente que necesita unos skills muy diferentes.
  • En un equipo técnico debe ser alguien que la gente respete. Si no le van a reventar vivo.
  • Los programadores tendemos a pensar que el management es una pérdida de tiempo. Saber qué hacer, cuando y mantener el foco vale más que 3000 líneas al día.

• Si has hecho crecer la empresa alrededor del producto (del software vaya) prepárate porque en general la gente de ventas, marketing y demás no tienen los procesos tan claros. Y si los tienen van a ser muy diferentes a los tuyos, así que más vale aclararlos porque vas a necesitar ir bien engranaditos. La diferencia entre acabado vs cerrado muchas veces es toda esa gente. Ellos no van a querer usar los issues the github así que haz que tengan un proceso, fuera o dentro, que encaje con el tuyo.

• Sabes lo que es cool y hace que un desarrollador esté contento: sentir que te ganas cada céntimo que te pagan haciendo cosas que sean útiles. Sea node o java. Las gilipolleces de la mesa de ping-pong, offsites y demás están bien pero si no hay una base profesional donde se sientan cómodos son adornos.

• Gestión de la frustración. Sí, de nuevo:

  • Sensación de ir despacio es brutal, piensas que eres una tortuga. No lo eres pero ahora todo necesita más trabajo, aprende a lidiar con ello.

  • La gente se empieza a sentir sola: empieza a forzar 1 to 1. En mi caso no me gustan los 1 to 1, me gusta mucho más pillar por banda al fulano en cuestión y hablar lo que tenga en ese momento en la cabeza. Esto último es cómodo pero un error garrafal, tienes que mantener un flujo continuo donde hablas no solo del día a día si no de lo que va a venir y de lo que piensas. Esto pasa a ser crítico con más de 20 personas.

  • No hay tiempo para hacer las cosas bien. Nunca hay tiempo para eso, el tiempo se gana, así que “pick your battles” y luchalos a muerte. Todo no puede estar perfecto, mejor que sea así, embrace lo cutre para lo que tenga que ser cutre.

   - Hay cosas que, símplemente, no se pueden hacer porque no hay tiempo. Los programadores piensan (pensamos?) que se puede hacer todo lo importante. Esto duele mucho.

• Evita cualquier cosa en la que no haya un control sobre la creación. Por ejemplo, la típica de “hacemos un wiki”. Los wikis son la peste si 1) no hay un índice claro o 2) no hay alguien gestionandolos. Miles de google docs, miles de ficheros en dropbox, etc, etc, sabes de lo que hablo.

• Un tema peliagudo, el firing (del hiring ya hay mucho escrito). Hay 3 clases de fires 1) la persona que no da palo, 2) la que no encaja 3) cuando no hay dinero o algo acaba. La 1 es muy raro a no ser que hayas contratado a lo bruto (como por ejemplo cuando te dan unos millones), pero tú eres listo, no vas a contratar a 10 personas en un mes. La 3 es cuando las cosas van mal, la 2 es la jodida: contratas a alguien listo, capaz, pero no sabes el porqué no funciona como debería. Todos nos las damos mucho de majetes y liberales con la mobilidad laboral, pero el despido sigue siendo de las cosas más desgradables y no deseadas, así que hazla cuanto antes y sé sincero. En esta etapa ya vas a tener (o habrás tenido) algún despido.

Cuando eres más de los que puedes contar (etapa de maduritos)

Este cambio pasa cuando eres más de 20, una sola persona no puede gestionar todo el equipo técnico (ni a nivel de gestión de proyectos ni al técnico) así que la cosa se complica: hay que hacer equipos y poner “jefes”. Lo camuflarás con títulos gilipollescos tipo “whatever lead”, “blabla manager” pero cuando alguien decide el sueldo de otro se acabaron las tonterías.

Ahora es el momento de contratar a los que vienen por dinero (y por el proyecto, claro), gente que sabe lo que hace, que no se anda con pijadas, que tienen hijos que mantener, que si eres gilipollas te lo plantan en la cara sin que te des cuenta. Esa gente es la que te hace crecer.

Aquí tendrás que elegir entre, generalmente, dos tipos de estructura: vertical u horizontal, esto es, por área (frontend, backend) o por unidad de trabajo o producto. Spotify tiene unos videos bastante famosos. Yo me descojono cuando los veo porque es como las películas, las partes aburridas de las vidas de los protagonistas nunca salen, son una mentira, igual que esos videos, pero para hacerte una idea vale.

En este punto los problemas técnicos principales son básicamente no técnicos:

• Hacer crecer a la gente como managers y hacer entender al resto cómo funciona
• Comunicación entre equipos y entre tu equipo y el resto de la empresa
• Que todo el mundo (a nivel personal y como equipo) esté enfocado y en la misma dirección

Los problemas técnicos principales son:

• Como ya no hay un control férreo de como se hacen las cosas cada uno empieza a aplicar su criterio, que está muy bien, pero sin seguir ninguna norma. Te encuentras a gente haciendo programación funcional, otros refactorizando partes que no conocen, usando librerías que no pondrías en producción aunque trabajases con nodejs.
• El rol del CTO pasa a ser mucho más influencer que activo. Ya no programas (o casi), la gente deja de confiar en ti para poner cosas en producción y los nuevos piensan que no has programado en tu vida (por eso tienes que sentarte un día con ellos y hacerles una performance para poner las cosas en su sitio)
• Es imposible que tomes todas las decisiones técnicas y también es imposible que se te vayan a ocurrir todas las buenas ideas. Tienes que hacer dos cosas fundamentales para que la gente crezca como líder técnico:
• Darles espacio para tomar sus decisiones y que la caguen, exactamente igual que lo harías tú pero esta vez es su responsabilidad y lo importante, su derecho.
• Darles tiempo. No me refiero a que esperes, me refiero no presionar tanto con las tareas que no les permita parar, analizar y buscar otras soluciones.
• Si tu producto ha crecido, y lo habrá hecho a golpe de remo comercial, habrá que hacer cambios grandes de arquitectura. Nunca es buen momento pero tienes que hacerlo, así que métete y tira millas. Ojo, con cabeza, a estas alturas tienes ya datos para tomar decisiones, así que haz pruebas de concepto y mide si tiene sentido.

La gente que se va es como los accidentes de tráfico: nunca te pasa a ti. Hasta que te pasa. Así que igual que te pones el cinturón de seguridad, compras coches seguros (esto es, no italianos) tienes que prepararte para cuando alguien se vaya. La estrategia perfecta sería tener 1 persona extra por equipo pero nunca funciona, más tienes, más haces y más tienes que mantener, así que mantén siempre a la gente con la que te gustaría trabajar cerca. Hay muchas formas de hacer esto, pero estas ya para otro post.

El punto crítico aquí es tener el músculo de la práctica bien fuerte, de esta forma las cosas, aunque parezca un caos, siempre irán razonablemente bien (teniendo en cuenta la velocidad de estas cosas). Ese músculo se empieza a trabajar cuando eres 3 pericos metidos en una habitación con mesas de ikea.

Seguro que me dejo en el tintero 200 mil cosas, lo único que puedo decir es: si estás pasando por un proceso así, ánimo.

Onpremise

When you start a SaaS company you think every single client will be happy to not have to manage their data, they just forget about servers, backups, maintenance… all those things that you don’t want to deal with.

And that’s actually the reality, you leave those tasks to some people that are experts on that matter and know how to do things far better than you. You only have to pay some amount of money (that of course is less than the one you’d pay if those services were managed within your company) and trust the people behind the service (the hardest part)

At some point in your company you will realize those amazing ideas are not that good when talking about data privacy and security among other things like enterprise authentication methods, custom hardware, redbooth private cloud landing sums up all the reasons quite well.

So yeah, you were using a dozen of amazon services that you can’t use in a private cloud, you will need to face the active directory reality, the high availability, the updates… outside your confy amazon cloud setup, managed by people don’t know anything about your service.

And the problem, there is a little information out there, so you will face a lot of problems, like:

• How to distribute: install script, RPM packages, virtual appliance…
• Managing updates: security updates vs major updates
• License systems
• High availability
• Backups and disaster recovery
• Support
• 3rd party auth (active directory, kerberos…)
• Monitorization
• How open the service should be (black box vs open)
• Internal release process
• Other things like announcements, communication channels, marketing, technical information and documentation…

There are some well know companies that have different approaches to the problem:

• Travis CI has an installer (docker based).
• Atlasian has a installer and pretty nice documentation on upgrades depending on the SLA you need. They actually moved from onpremise to have a SaaS according to David Bonilla.
• Github has a virtual appliance. I follow this one really closely because of the release process, they manage it incredible well, take a look at this update mail
• There is a meta company that provides a service to create onpremise versions, Replicated. I don’t think they can cover all the cases but it could be a pretty good solution for companies without resources to create the enterprise version.
• Of couse CartoDB provides an enterprise version, CartoDB enterprise, we have a mix of virtual appliance plus LXC and some other more customized installations based on an installation script. One of our challenges here is we are an open source company with the good and the bad parts.

Do you know more companies doing onpremise/enterprise versions? I’ve created a slack channel so you can join and share them or talk about your experience with the enterprise world problems, feel free to join.

Enterprise Software

Eres un pinpin y te pones a desarrollar software (no necesariamente en este orden), la cosa parece que mola, que no hay que doblar mucho el lomo y es fácil hacer dinero. Te gusta un sector, echas un ojo al software que trata de solucionar la vida de la gente y, como buen ignorante que eres, las primeras frases que salen de tu boca son “JAJAJAJA parece software de los 90”, “esto lo han hecho 4 becarios”, “no tienen ni idea, son unos aficionados”, “esto lo hacemos nosotros mejor con una mano atada a la espalda”. Nota importante: yo he sido el primero en estar en esa situación, así empecé agroguía, de hecho debes estar ahí en algún momento, tienes que ser un veinteañero.

Así que manos a la obra, creas tu proyecto en node.js, TDD, deployment automático, últimas técnicas de desarrollo, el recopón y toda la corporación bendita, después de 2 meses tu software está más o menos listo, ahora solo hay que captar usuarios para tu proyecto B2C.

Pasa 1 año, aprendes que no tenías ni puta idea pero vas malvendiendo, malcaptando clientes/usuarios, te sacan en los periódicos (dándote la falsa sensación de que lo estás haciendo bien) y ganas algún premio de esos que montan por que sobra presupuesto en algún departamente de alguna empresa.

Un día alguien se te acerca, un tío que tiene una empresa cargada de millones, que sabe lo que se hace, joder, que es el puto amo, ve tu software y te plantea: “yo te pagaría XXXX€ por esto si tuviese estas pequeñas modificaciones”. Ese XXXX es 100X de lo que estás cobrando al mes a tus usuarios del SaaS. Llamas a tus socios, lo celebras y sin saberlo estás dentro del mundo llamado “enterprise”, pero aún no eres consciente.

Te comes toda la mierda que el cliente quiere meter en tu producto, llegan otros clientes como ese y rápidamente te das cuenta (bueno, seguramente te lleve meses) que puedes cobrar 100X por lo mismo con mucho menos esfuerzo si empiezas a vender a empresas. Ahora sí, ya sabes que estás en el mundo enterprise, pero aún no sabes cuanta vaselina vas a tener que comprar.

Y aquí es cuando empieza la cosa a ponerse seria, empiezas a hablar con empresas gordas gordas, que tienen gallina de verdad y les dices que tu software es “best in class”. Entonces pasas por diferentes encorbatados y llegas al momento en el que de verdad están interesados. Te mandan la lista de requisitos, la abres pensando que eres el puto amo y entonces es cuando abres el tarro de vaselina.

Y es que además de añadir frases como “big data”, “enterprise ready” y otras perlas que no dicen absolutamente nada pero que debes tener para que los que manejan la gallina sepan posicionarte (sí, eres programador y sabes que todo eso es bullshit, pero no pasa nada, es solo un trámite) debes tener una lista de requisitos en tu software de los que no teías ni idea. Te dejo algunos de ellos.

• Requisitos: te pedirán una lista de cosas que tu software debe soportar. Verás que sospechosamente algunas de esas listas se parecen demasiado a lo que soporte tu competidor (que curiosamente ya no son tan aficionados como parecían hace 2 años). Obviamente no tendrás ni una linea de documenación, porque quién necesita documentación, somos un SaaS moderno que cambia todos los días!

• Onpremise: Una empresa que tenga dos dedos de frente no va a poner sus datos en tu infrastructura, así que vas a tener que montar todo el chiringuito dentro de su red. Así que olvida los servicios que te da amazon, tu elastic cloud provider y demás, aquí estás solo. Solo y en el infierno, vas a tener que instalar tu software en redhat con paquetes de hace 7 años (cuando no existía node.js). Aquí te ríes bastante.

• Requisitos técnicos y escalado: Van a querer saber qué máquinas hay que instalar y como escalar para una demanda concreta. Porque esta gente es seria, va a hacer dinero con tu software, no está levantando el dedo para ver de donde corre el aire, quieren saber lo que se van a gastar para saber la rentabilidad.

• Alta disponibilidad, disaster recovery, backups, SLAs: Eso, quieren que funcione, que funcione siempre y que responda bien a los fallos. En tu SaaS te importa poco si se cae 10 minutos porque eres guay, tus clientes son guays y eh! no pasa nada, somos una startup. Tampoco hay que volverse loco, los aviones llevan volando años y siguen fallando técnicamente y estrellándose.

• Updates, mantenimiento: quieren updates con bugfixes, deben de ser fáciles de hacer y la fiesta no debe parar, esto es, no vale tirar el servicio, montar el nuevo software y levantar. Este punto es más divertido cuando llevas un tiempo y alguien con la primera versión (que era una mierda) quiere actualizarse. Tienes que tener, además, una política de versiones, de tiempo de vida, etc. Esto hace que tengas que dedicar muchísimo tiempo a hacer que todo encaje y que versiones antiguas funcionen. Ese tiempo no lo dedicas a hacer que tu software no parezca de los 90 (guiño guiño)

• Soporte: quieren tener un teléfono al que llamar cuando entren en pánico. No, no quieren mail, quieren poder hablar con alguien que les solucione la papeleta. Tendrás que contratar a gente a turnos para esto, los márgenes ya no parecen tan altos eh?

• Seguridad: pasarán auditorías de seguridad, no servirán de nada porque solo encontrarán fallos de seguridad genéricos, los importantes vendrán después, cuando estés en producción. Protip: si no quieres gastarte una pasta habilita un programa de bug bounty. Invertirás bastante tiempo en seguridad y tendrás que recortar de otras cosas (adivina, los 90 están más cerca)

• Otros requisitos: cada cliente es de un padre y una madre, algunos no dejarán ejecutar cosas como root, otros no tendrás salida a internet, no podrás monitorizar ciertas cosas… preparate a meter miles de opciones y soportar casos absurdos.

En resumen, la aplicación de node que parecía simple y ágil ahora tiene una serie de limitaciones, añadidos de clientes, vaya, se ha hecho mayor y ahora miras a esas empresillas que empiezan con una sonrisa (pero por si acaso no dejas de mirarlas), con más pasta en el bolsillo y con suerte habrás dejado de ir a la oficina en bicicleta e irás en un coche como debe ser. Es posible que seas también menos feliz, pero no sabrás si es la edad o tu software enterprise.

Resumen 2015

Este año, igual que el anterior, seré breve. De hecho no tenía pensado escribir este post pero leer los resúmenes tras unos meses (o años) pone las cosas en perspectiva.

A nivel profesional ha sido un año increíble, todo el mundo conoce CartoDB, la gente cree que eres el puto amo, me han conocido en aviones, trenes y bares, he dado charlas, etc, etc. La otra parte, la de trabajar duro, ha sido y está siendo jodida, todo pasa tan rápido que no te da tiempo saborear nada.

A nivel personal ha sido lamentable. Este año que viene será mejor seguro, de hecho empiezo el año mudándome a Madrid después de 4 años y medio con medio pie allí y medio aquí. Por poner una nota positiva, he podido tachar uno de mis TODO vitales, conducir en Nürburgring: