Cómo ir de ‘startup’ a empresa y no morir en el intento

En el tiempo que llevo en Karumi, son muchas las startups y grandes empresas por las que he pasado y a las que he ayudado. En algunos casos a nivel tecnológico, intentando mejorar su software, y otras veces ayudándoles a organizarse bien.

Muchas veces creemos que el gran problema de una empresa es su componente técnico cuando en verdad es el organizativo, las empresas de tecnología están formadas por personas y son el eje más importante de las mismas. No solo debemos saber cómo se debe escalar nuestra base de código, cómo escalar nuestras instancias de Amazon o cómo se va a comportar nuestra base de datos con 5 millones de usuarios, también debemos estar preparados para hacer crecer nuestros equipos y a cómo seguir funcionando bien cuando entres por la puerta y no conozcas ni el nombre de la mitad de la gente que trabaja contigo.

En Karumi hemos vivido mucho esta situación con varias empresas y a continuación voy a enumerar los problemas más importantes que nos encontramos y los consejos que nosotros les damos.

Implicación personal

Cuando se monta una startup la idea es sacar un producto al mercado lo antes posible, pones todas las horas de trabajo que puedes, sacrificas salario, comprimes varios años de tu vida en unos meses para intentar tener en el menor tiempo disponible el producto en el mercado y validar la idea que tienes en mente. El problema es que esto deja de funcionar cuando la empresa crece, es difícil pedirle a una persona que cobra un salario que lo dé todo por un producto que no es suyo o que no lo siente como suyo.

La solución más común es darle un porcentaje de la empresa a esos primeros trabajadores para que sientan el negocio más suyo, esto puede funcionar al principio pero el equilibrio sobre el porcentaje de la empresa y la implicación suele ser difícil de medir.

A mi entender, lo mejor es escuchar a los trabajadores, oír sus opiniones y sobre todo tenerlas en cuenta. Si la gente está contenta con lo que hace y además la idea parte de él su implicación será mayor, esto ayudará a hacer equipo y será más fácil integrar a nuevos miembros.

Trabajando juntos y periodos de Crunch

Otro problema inherente en las startups es las horas que se trabajan y los periodos de ‘crunch’. Cuando un equipo lo forman dos personas el objetivo por el cual se va rápido es claro, hay que salir y conseguir dinero, pero cuando el equipo crece hay que aprender que la gente tiene una vida fuera del trabajo. Para no quemar a los empleados lo mejor es dejar claros los objetivos tanto de la empresa, como los objetivos personales de cada miembro y que no existan dudas sobre ellos. La comunicación tiene que ser clara y concisa, y sobre todo ser honestos.

Decirle a un equipo que hace falta trabajar un fin de semana o una semana de 14 horas porque se ha cerrado un contrato o porque hay que sacar una nueva versión para una campaña señalada es entendible por todos y a nadie le importará hacer un sobre esfuerzo. Para complementar esto, intentad recompensar estos empujes extra, no solo de forma económica a través de un bonus, si no complementarlo con días de vacaciones después de un crunch, una cena o un viaje, aunque sean pequeños detalles que parezcan que no tienen importancia.

Los periodos de crunch nunca deben ser sin motivo justificado, ni por caprichos del jefe o porque se quiera que algo esté para ya, porque si algo se debe aprender es que el software lleva su tiempo. Y como mínimo dad las gracias a la gente.

Por último, todo el mundo tiene que tener clara la visión de empresa a corto, medio y largo plazo, aunque vayamos virando esa visión de medio y largo plazo. Cuando las empresas crecen, la gente que entra nueva a veces no sabe hacia dónde se dirige la empresa y el trabajo de las tareas del día a día se come la visión a largo. Además si una empresa cambia de objetivos cada semana y todo es importante y lo queremos todo para ya, terminará con nuestros equipos y generará desmotivación en la gente.

Una empresa está hecha de profesionales, es difícil encontrar buenos trabajadores, si una persona está descontenta se irá de nuestra empresa. Debemos intentar que la gente no llegue a dicha situación.

Liderazgo

Uno de los problemas de crecer los equipos es que debemos empezar a crear estructura organizativa y poner a gente liderando equipos. El principal problema es que muchas veces los propios fundadores se asignan roles como CTO, CEO o Head of design sin tener la menor idea de lo que el cargo implica.

Una de las cosas que recomiendo a muchas empresas es que cambien de CTO o de CEO porque no está preparado para el cambio de dejar de ser una startup. Esto no implica que deba de abandonar la empresa, simplemente debe saber echarse a un lado y hacer el trabajo para el cual es útil y ha llevado a la empresa hasta allí.

Otro problema es que solemos pensar que grandes técnicos van a ser a su vez grandes gestores y tenemos la idea de que para cobrar más hay que gestionar a gente. Hay que ser eficientes con los trabajadores, colocar en puestos de gestión a aquellos que sean buenos en esas labores y les guste ese trabajo, además de mantener a los técnicos en aquellos puestos en donde rindan más. Si encuentras un buen técnico intenta retenerlo porque escasean y te va a costar mucho cubrir su puesto, y mucho menos no le subas en el escalafón organizativo, te va a ser mucho más útil si le tienes ayudando al resto de técnicos desde abajo. Eso implica que puedes tener buenos técnicos cobrando más que sus jefes, eso no debería sorprender, ya que esa persona nos va a aportar mucho valor.

Un buen líder debe hacer dos cosas bien: escuchar y predicar con el ejemplo. Debe escuchar a todo el mundo porque las mejores ideas vienen de las preguntas más simples y porque el nuevo en entrar no está viciado por el coro de voces de la empresa. Además debe predicar con el ejemplo, no le pidas a tu equipo algo que tú no harías, si hay un periodo de más curro quédate allí con ellos y échales una mano y que sientan que les defiendes.

Lenguaje común

Es importante que desde el principio se establezcan una serie de herramientas y normas para todo el mundo, aunque al principio esté uno solo o las podamos cambiar en el futuro.

En la parte de tecnología es importante establecer unas reglas que deben seguir todos. Las más importantes para mí y que recomiendo siempre son: establecer un sistema de trabajo con el control de versiones, un sistema de code reviews y tener una guía de estilo de código. Estas tres cosas me parecen básicas y las introduzco siempre en los equipos con los que trabajo, si no las tienen ya.

En una empresa todo el mundo tiene que trabajar con un control de versiones y usarlo de la misma manera; no voy a entrar si hay que usar ramas por funcionalidad o usar gitflow, tampoco qué tecnología usar, ya que para videojuegos recomendaría usar Perforce mientras que para aplicaciones recomendaría Git, pero sí que todo el mundo debe trabajar de la misma forma.

Los commits que hagamos deben ser pequeños y descriptivos. Esto va ayudar a la hora de tener que resolver conflictos o si tenemos que irnos atrás en la historia del repositorio para ver por qué se introdujo un cambio o investigando por qué ocurre un fallo. Un control de versiones no es una carpeta compartida de Dropbox, basta ya de usarlo como tal, basta de empujar un montón de cambios con una descripción que pone “preparando release“.

La code reviews van a ayudar a que el conocimiento fluya por el equipo y que el código tenga un estilo homogéneo. La idea es que antes de subir código a nuestro proyecto, al menos un par de compañeros opinen sobre el mismo, con el fin de encontrar posibles fallos, mejoras o errores de estilo. Además conseguimos que varias personas tengan una idea mínima de cómo funciona esa pieza de software, ya que han tenido que dedicar tiempo a ver cómo está hecha. Así conseguimos que la gente aprenda entre ellos, que las personas más senior puedan explicar errores a los más junior y estos mejorar sus habilidades.

Las code reviews hablan del código y no de quien lo escribe, por lo que deben de ser cordiales y escritas con la mentalidad de un principiante, pensando que todos cometemos errores y que los seguimos cometiendo todos los días. Una cosa que recomiendo es destacar aquello que esté especialmente bien y alabar el trabajo de nuestros compañeros.

La última, y no menos importante, es definir un lenguaje común, tanto en la parte más estricta de cómo se escribe el software; cómo vamos a nombrar las clases, los métodos, la tabulación… Como para la parte semántica del software; cómo vamos a llamar a las cosas que un “usuario” sea siempre un “usuario” y no lo llamemos “cliente” en otro sitio o “cuenta” en otro, si todo se refiere a lo mismo.

La parte sintáctica nos va a ayudar a la hora de tener que unir código de varias personas y para leer código de otros. Esta parte se puede automatizar en la mayoría de lenguajes y está bien definir hasta el grado de cómo los artistas llaman a los assets o cómo se definen las tareas y los bugs.

En la parte semántica recomiendo siempre sentarse y hacer un glosario de términos para todas las plataformas y personas, incluso la gente de producto debería saber que a esto lo llamamos “usuario” y no “comprador”. Tener un vocabulario común nos va a hacer más fácil la comunicación y más fácil moverse entre equipos.

Si todo esto está escrito en un manual de empleado va a facilitar el proceso de entrada de una persona nueva para que se enganche a estas formas de trabajar y las code reviews le van a guiar en la buena dirección.

Automatización

Una de las principales cosas que tiene que hacer una empresa cuando va creciendo es automatizar todo aquello en lo que invierte tiempo y no es la parte central de su negocio. Veo que muchas empresas gastan mucho tiempo de sus ingenieros generando versiones demo para enseñárselas a un cliente, preparando una release o tomando capturas para el market de una app. Esto es una pérdida de tiempo.

Todas estas cosas son fáciles de automatizar, la mayoría no llevan más de un día de trabajo y a la larga nos pueden ahorrar mucho tiempo, además de eliminar fallos humanos. A todos nos ha pasado sacar a producción una aplicación con el debug activado o apuntando a un entorno que no es.

Un error muy común es que los ingenieros que hacen las aplicaciones tengan las claves de firmado de las mismas, cuando tu empresa crece esto no funciona, ya que un trabajador puede acabar cabreado con la empresa por cualquier razón y te puede hacer un destrozo considerable, o se puede perder un portátil y comprometer la seguridad de tu producto. Al igual que no le das las llaves de tu casa al primero que conozcas aunque parezca un buen chico, tienes que tener cuidado a quien le das las llaves de tus aplicaciones.

No hay que dejar que el día a día de trabajo no nos deje mejorar nuestros procesos de desarrollo y más cuando nos pueden ahorrar mucho tiempo y problemas.

Testing

¿Os imagináis un cocinero que no pruebe su propia comida? Pues esto es lo que pasa en el mundo del software, los programadores no prueban su propia comida, la hacen, miran un poco que se parezca a un plato de comida y se la dan al cliente, sin importarles que esté buena o no. Este un problema que tienen la mayoría de la empresas que visito, muchas no se preocupan si su plato de comida está bueno o no, incluso algunas recalcan que probar la comida es una pérdida de tiempo y que automatizar ese proceso lo es aún más.

Muchas empresas optan por contratar a gente que pruebe los platos antes de servirlos, a mí me suena raro que en una cocina hubiera un cocinero y alguien que probara la comida, pero lo hacemos y le damos el nombre de QA. Me parece una pena tener a gente probando las aplicaciones, más cuando esa gente podría estar ayudando a sacar tareas y funcionalidades adelante. Debe de ser responsabilidad de cada uno hacer que el software funcione correctamente y no delegar esto a un tercero.

Cuando me encuentro con esto, demuestro empíricamente que es más rápido automatizar las pruebas que testear las cosas a mano cada vez, el gran problema es que es que mucha gente no ha hecho nunca un test, tienen miedo a hacerlo y es un proceso casi sádico demostrarte a ti mismo que el software que has escrito está mal. Por lo que veo siempre, la gente cuando empieza a escribir tests no deja de hacerlo, es una red de seguridad que demuestra que lo que has hecho está bien, y te da tranquilidad a la hora de trabajar o arreglar fallos en el software. Los tests se escriben para uno mismo no para nadie más, es la forma de saber que lo que has hecho funciona y no destruyes el trabajo de tus compañeros.

Otro problema es saber qué testear y qué no testear. Se deben cubrir aquellas cosas que sean importantes para el negocio o para la funcionalidad a desarrollar y apoyarse en la gente de producto para ver qué es para ellos importante y deben ser ellos los que nos marquen qué áreas debemos cubrir.

Además, los técnicos deben ser capaces de descubrir qué pieza de software es más sensible para poder cubrirla bien de test por si debe ser modificada. No hay que volverse paranoicos con los tests y se debe elegir bien el alcance de los mismos, pero para esto no hay una fórmula secreta, sólo el tiempo y la experiencia sirven de ayuda.

Demasiado Agile

Otro gran problema de las empresas que he percibido es que dan más importancia a los procesos que al uso de los mismos. Cuando una empresa empieza a introducir metodologías ágiles en sus equipos, intentan imponerlas o aplicarlas directamente sin comprenderlas o valorar qué aportan a su ciclo de desarrollo. Instaurar scrum o kanban no va a resolver por sí mismo los problemas de tu organización, aunque sí que tienen herramientas que bien usadas pueden mejorar el flujo de trabajo. Cuando en un equipo es más importante asistir a una retrospectiva que a una formación, o las standups son una reunión donde voy obligado a contar mi historia y ni oigo lo que dicen los demás, usar scrum no funciona.

Cuando los equipos crecen, no hay espacio para desarrolladores cowboys que hacen la guerra por su cuenta. Claramente hay que establecer metodologías de trabajo, pero estas deben salir de los equipos, hay que hablar con ellos, ver qué problemáticas tienen y cómo resolverlas, porque no sirve de nada obligar a un equipo a adoptar una serie de reglas que van a seguir a desgana y que van a intentar saltarse, son ellos los que van a usarlas y deben estar contentos con esas metodologías.

Otro problema es convertir Agile en Waterfall encubierto. Muchas empresas dicen que usan metodologías Agile, pero en el fondo todas las tareas son igual de prioritarias, no hay iteraciones, no se actualiza el flujo de trabajo y el triángulo del proyecto, donde se revisan recursos, tiempo y funcionalidades, es inamovible. A estas empresas hay que enseñarles a priorizar, a decir que no a cosas, a saber posponer decisiones y a intentar hacer más con menos.

Con todo esto, quiero decir que crecer no es fácil, habrá gente que se quede en el camino y vendrá nueva gente con muchas ganas, pero lo más importante es trabajar como un equipo, que trabaja a gusto y está orgulloso de su día a día. Recordad que trabajáis con personas y que son sin duda alguna lo más importante que tenéis en vuestras empresas.

Foto | Flickr

Por Jorge J Barroso:

Jorge J Barroso es Android expert en Karumi, un estudio de desarrollo donde le dan mucha importancia a la calidad y trabajan muy cerca de sus clientes. Trabajó en Tuenti entre 2009 a 2013, siendo en su última etapa tech lead del equipo de Android Core. Ha participado en varios proyectos móviles de la compañía como j2me, Blackberry y Android. Antes de Tuenti trabajó en varias empresas desarrollando juegos para dispositivos móviles y juegos multiplayer. Desde el mes de febrero es Google Developer Expert en Android.

Síguenos en @BBVAAPIMarket