SQA en una startup


SQA (software quality assurance) o aseguramiento (vaya palabro) de la calidad del software es un concepto con el que convivimos los que nos dedicamos, de una u otra manera, al desarrollo de software. Definir qué es el SQA es algo complicado y cada uno tendrá una versión distinta pero para mi no es más que la colección de procesos y herramientas que permite asegurar en cada nueva release que el software desarrollado tiene la calidad suficiente como para poder ser desplegado en producción. Existen metodologías muy desarrolladas en torno a este tema pero yo prefiero ir a lo práctico y sencillo y al final lo reduzco a una serie de pruebas funcionales que debe pasar el software. Estas pruebas deben cubrir todos los procesos de negocio soportados por el software, tanto el funcionamiento esperado como los errores controlados.

La gestión de la calidad del software debería formar parte de manera natural del ciclo de vida del software pero todos sabemos que no es así. En casi todos los proyectos brilla por su ausencia.

SQA en una startup

En la mayoría de los casos, unir en una misma frase startup y SQA es ciencia ficción. Casi siempre en las startups tendemos a confundir rapidez, agilidad y calidad. Pero claro, los recursos y el tiempo en una startup son muy limitados y si hay que reducir por algún sitio, normalmente suele ser a costa de suprimir el SQA. Aunque por otro lado, nuestra tolerancia a los errores es muy baja y siempre queremos que las cosas funcionen perfectamente. Estoy seguro que a muchos os ha venido a la cabeza alguna conversación con vuestro CEO en la que habéis discutido sobre la necesidad de hacer un desarrollo para ayer pero luego, cuando las cosas han fallado por hacerlas deprisa y corriendo, ha puesto el grito en el cielo.

Cuando nos movemos en el entorno de una startup, parece bastante asumido que el SQA hay que dejarlo para más adelante, para cuando la empresa deja de ser una startup y te puedes parar un poco a afianzar todo. Algunos ejemplos:

  • En BuyVIP durante el tiempo que  fui CTO no teníamos ni un plan de pruebas definido ni un proceso de pruebas exaustivo previo al paso a producción.
  • En tagUin, teníamos una guía básica de qué había que comprobar y teníamos en la cabeza el detalle de lo que había que probar pero no lo hacíamos siempre y casi siempre nos dejábamos cosas por probar.
  • En Planeo mientras yo gestioné el proyecto, nunca hubo plan de pruebas y la parte de negocio nunca se involucró lo suficiente en hacer pruebas funcionales de calidad. Así pasaba, que casi siempre había errores totalmente evitables si el negocio hubiera probado lo que le pedíamos que probara.

Qué hacíamos en etece

Digo “hacíamos” y no hacemos porque estamos trabajando para cambiar y mejorar el SQA. Un poco más adelante os cuento qué estamos haciendo.

Desde la primera versión de etece que vio la luz a mediados de julio de 2012, hemos tenido un documento muy sencillo donde hemos ido incorporando las pruebas que considerámos necesarias para comprobar, en cada nueva release, que todo funciona según esperamos. En esa primera versión eran alrededor de unas 80 pruebas. Ahora vamos por casi 300. Estas son algunas de nuestras pruebas:

  • Grupo: registro de cliente
  • Prueba: registro correcto de cliente
  • Pre-requisitos: ninguno
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos con un email que no haya sido registrado previamente y se completa el registro
  • Resultado esperado: 1.- Llega correctamente el email de bienvenida; 2.- El usuario está correctamente registrado en el CRM; 3.- El cliente queda correctamente suscrito a las listas usuarios y clientes tanto en la web como en MailChimp
  • Grupo: registro de cliente
  • Prueba: registro de cliente con email dado de baja
  • Pre-requisitos: disponer de un usuario registrado y dado de baja
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos usando el email de un usuario dado de baja y se intenta completar el registro
  • Resultado esperado: El registro no se completa, se muestra un mensaje genérico de error y además se marca en rojo el campo email indicando que ya existe

Al principio, hacer todas las pruebas nos llevaba un día de una persona. Ahora, con casi 300 estamos en un par de días de dos personas. Además, según vamos incorporando funcionalidad a la web, las pruebas cada vez son más complejas y requiren de más tiempo. Estaba claro que teníamos que ir un paso más allá, automatizando las pruebas.

Qué estamos haciendo ahora en etece

Desde hace un par de semanas estamos trabajando para automatizar el mayor número de pruebas que podamos. Las ventajas de automatizar las pruebas son claras:

  1. mejora del tiempo necesario para pasar el plan de pruebas.
  2. minimizar la intervención humana. No hace falta, en un procentaje grande, que intervenga ninguna persona.
  3. mejorara la calidad de las pruebas. Es casi consecuencia del punto anterior. Al eliminar el factor humano, eliminamos aquellas pruebas que se dan por buenas por error o que directamente, la persona encargada no las hace ( pasa más de lo que pensáis).
  4. hay que ser más metodológico. Todo lo nuevo que se desarrolla o que se modifica debe tener sus pruebas funcionales programadas. Es algo bueno, pero también lo incluyo como punto negativo ya que muchas veces te puede complicar de más algún desarrollo.

En cambio, hay que asumir algunos puntos negativos:

  1. aumento del tiempo de desarrollo. Ahora, además de programar la funcionalidad, hay que programar las pruebas que comprueban que todo funciona correctamente y hay que mantener operativas las pruebas ya programadas. Estimamos que el tiempo se va a aumentar entre un 10% y un 15%.
  2. hay que se más metodológico.

Para automatizar las pruebas  estamos usando Seleniun2 con JUnit4. En los próximos días publicaré un post escrito por Javier Fernandez que explica a nivel técnico cómo está montada toda la automatizacion de pruebas. Avanzando un poco de lo que él contará, para cada una de las pruebas que teníamos escritas es nuestro plan de pruebas, hemos creado un test de Selenium que hace el proceso completo de la prueba y comprueba todos los resultados esperados. Hemos hecho cada prueba independiente de la anterior de manera que una prueba empieza sin necesitar datos anteriores, se ejecuta y al terminar borra todo rastro para así poder ser ejecutada de nuevo sin problemas. Como imaginaréis, hay muchos procesos que están compartidos entre muchas pruebas (registro de usuario, registro de solucionador, encargar una tarea, etc…) por lo que la estructura de clases que hemos montado nos permite independizar del test toda esta navegación común. El plan de pruebas lo lanzamos desde nuestro servidor de integración contínua (Jenkins) lo que nos permite conocer en todo momento la salud de nuestro proyecto.

Hasta la fecha hemos conseguido automatizar alrededor de un 90% de las pruebas del plan lo que reduce a poco más de un par de horas el trabajo el tiempo humano necesario para completar las pruebas.

Espero que estas líneas os sirvan de estímulo para incluir, de manera más o menos sencilla, el SQA como parte de vuestros proyecto.

Personas, procesos, herramientas


A lo largo de mi carrera siempre he intentado aprender lo máximo de la gente que tengo alrededor. He intentado quedarme con lo mejor de cada uno de los profesionales con los que he trabajado y trabajo, sobre todo de aquellos que han tenido más experiencia o conocimientos que yo.
De Gustavo García, cofundador de BuyVIP, aprendí que una empresa se sustenta en tres patas: personas, procesos y herramientas.

Para que una empresa funcione, las personas de los puestos clave deben ser muy solventes, con mucho talento y capaces de definir e implementar los procesos sobre los que soportar, de una manera eficiente, las necesidades del negocio. Las herramientas deben permitir ejecutar los procesos de manera rápida y sencilla con la menor cantidad posible de personal.

Según se desarrolla una empresa, cada una de las tres patas debe crecer de manera similar de forma que no haya grandes desfases entre ellas. Una empresa con muchas personas pero sin procesos y/o herramientas no es eficiente. Igualmente, una empresa sin el talento suficiente no tendrá los procesos definidos de manera eficiente y no se hará un uso adecuado de las herramientas. Una empresa sin herramientas necesitará mucho personal, agudizando el desfase entre las tres patas.

Cómo aplicamos esto en una startup
Cuando una empresa arranca, no tiene personas, procesos o herramientas. Por tanto, por algún punto hay que empezar. El punto de partida es, como no podía ser de otra manera, las personas. Yo creo firmemente que, al menos, las diez primeras personas de una startup deben ser sobresalientes, con un talento enorme, autonomía y liderazgo. Esas diez personas (aproximadamente) deben ser capaces de definir, desarrollar e implantar, en cada una de las áreas, los procesos y las herramientas. ¿Tienes en tu empresa las personas adecuadas sobre las que sustentar el crecimiento? Merece la pena invertir el tiempo necesario para buscar y seleccionar esas personas. En gran medida, el éxito de tu empresas dependerá de ello.

Impacto de salir en TV sobre la infraestructura de etece


El pasado 13 de febrero de 2013 TVE emitió el programa Comando Actualidad hablando sobre consumo colaborativo. Una pequeña parte del programa mostró el funcionamiento de etece a través del día a día de nuestro trabajo y el de algunos solucionadores.
Con independencia del impacto en el negocio, quiero compartir el impacto que tuvo en nuestra infraestructura, cómo planificamos la escalabilidad y qué hicimos bien y mal, esperando que sea útil para otras empresas que vayan a pasar por situaciones similares.

Cómo está montada nuestra infraestructura
Tal y como comentaba en un post anterior, nuestra infraestructura está en la nube de Amazón. Una de las características que ofrece es la capacidad de auto escalado en función de la carga que están soportando las máquinas virtuales EC2. Para poderte beneficiar de esta característica, la arquitectura debe estar concebida para ello. No voy a entrar en detalle sobre cómo montar grupos de auto escalado porque ya hay mucha literatura al respecto y no es el propósito de este post. No obstante, si alguien quiere que lo detalle, lo haré sin problema.
Nuestro grupo de auto escalado está configurado para tener como mínimo una máquina, ya que normalmente tenemos poco tráfico, añadiendo una máquina cada vez que la CPU de las máquinas que forman el grupo supera el 75% de carga. Este chequeo de la carga de la CPU del grupo se hace cada minuto (no se puede configurar cada menos). Eso quiere decir que, ante un pico de carga, escalamos añadiendo una máquina por minuto. Teniendo en cuenta que en levantar una nueva máquina lleva entre 20 y 30 segundos, desde que se supera el umbral de carga, tardamos 30 segundos como mínimo y 90 como máximo en incrementar el número de máquinas.

Cómo nos preparamos para el presumible pico de tráfico
Presuponiendo que salir en TV nos iba a suponer un pico de tráfico, modificamos el grupo para que tuviera como mínimo 10 máquinas. En Amazón se paga por tiempo de uso de las máquinas (además de tráfico y alguna cosa más) por lo que tener muchas máquinas durante un rato sólo supone un sobrecoste de unos pocos euros. Además, al salir en TV se producen unos picos de carga muy agudos por lo que más valía prevenir que… morir de éxito.

Qué pasó
Pues pasó lo previsible. No soportamos el pico que se produjo, el escalado, añadiendo una máquina por minuto fue demasiado lento y estuvimos caídos durante unos tres minutos. A partir de ahí fuimos remontando y pudimos volver a estar operativos.
A toro pasado parece obvio que las cosas iban a suceder así, pero antes del momento no lo teníamos tan claro.

Conclusiones
Después de soltar la chapa, esta es la parte más interesante del post. Analizando lo sucedido e intentando aprender de los errores, estas son las conclusiones que hemos sacado:

  • Nuestra configuración de auto escalado está bien para el día a día, cuando no sales en prime time en TV pero no es correcta ante grades picos de carga muy agudos.
  • En este tipo de casos hubiera sido mucho más correcto escalar de cinco en cinco máquinas.
  • Tener un único umbral de auto escalado no es suficiente. Si quieres cubrir picos moderados y grandes sin matar moscas a cañonazos lo mejor es establecer tres umbrales: uno que levante una máquina, el segundo que levante dos máquinas y el último que levante cinco. Los valores de los umbrales podrían ser 60, 75 y 90% de carga de CPU aunque habría que verlo en cada caso.

Otro tema importante es cuándo parar las máquinas que se han levantado una vez que pasa el pico de carga. Nosotros paramos una máquina cada tres minutos siempre que la carga de CPU del grupo esté por debajo del 40%. Esto supone parar tres veces más lento que levantamos. Nos pareció un valor correcto aunque no hay ninguna ciencia detrás de ello y todavía tenemos pendiente optimizarlo.

El tema de la escalabilidad me parece apasionante así que iré escribiendo más sobre cómo afrontamos este tema en etece tanto a nivel de software como de hardware.

Programador: medir también es importante


Casi todos los que de una u otra manera nos dedicamos a Internet, tenemos clara la importancia de la analítica web, de medir los más posible y con el mayor detalle posible. Pero existe un colectivo que suele no entender este punto. Ese colectivo son los programadores web, entre los que me incluyo parcialmente.
Desde el punto de vista de un programador, cuando la persona que lleva la analítica web define cómo hay que marcar y etiquetar las diferentes páginas, suele entender que debe hacer cambios en la programación que normalmente ya ha terminado, sin hacer esfuerzo en entender que esos cambios que tiene que hacer suponen una mejora importante para el negocio y que van a permitir entender mucho mejor el comportamiento de los usuarios.
Todo sería mucho más fácil si los programadores entendiéramos desde el principio que la analítica web es una pieza imprescindible, irrenunciable y tan importante como una buena programación. Al igual que poco a poco los programadores incorporamos de manera natural las buenas practicas de SEO, debemos incorporar el etiquetado a nuestras web y cambiarlo tantas veces como sea necesario entendiéndolo como parte de nuestro trabajo. Medir es muy importante!!

Por otro lado, hace tiempo que creo que los equipos que se dedican al SEO deberían estar bajo el paraguas de IT. Pero en el caso de la analítica web, no lo tengo del todo claro. En mi opinión están a caballo entre IT y marketing.

En los próximos años viviremos cambios en las estructuras de los equipos. SEO, analítica e IT estarán juntos y social media estará junto con atención al cliente. Aunque eso es otro tema.

Infraestructura de etece en la nube de Amazon


Hace pocas semanas que hemos lanzado etece.es, tiempo para los que no tienen tiempo. En los próximos posts iré comentando algunos aspectos que creo que merece la pena compartir por si a alguien le puede ayudar. El primero que voy a abordar es el relacionado con la infraestructura y cómo lo hemos montado en la nube de Amazon.

Antecedentes
La primera vez que analicé a fondo la nube de Amazon como alternativa al hosting tradicional fue en 2008 cuando era CTO de Toprural. En aquel momento estábamos planificando un cambio de CPD y Amazon fue una de las alternativas que estudiamos. En aquella época, los servicios de Amazon se limitaban a EC2, S3 y muy poco más lo que suponía demasiadas limitaciones para lo que Toprural necesitaba. Finalmente y hasta hace bien poco, dejamos Toprural funcionando en máquinas propias en una huella contratada en un CPD de Madrid.
El segundo contacto serio con la nube de Amazon lo tuve en Planeo. Toda la infraestructura de Planeo se montó en Amazon, aunque fue el equipo de sistemas de Medianet quien montó todo en base a los requisitos que les transmitimos. En cualquier caso, me permitió conocer de primera mano muchos de los servicios que ofrecen actualmente.

Infraestructura para etece
Tenía bastante claro que Amazon nos ofrecía todos los servicios de infraestructura que vamos a necesitar, al menos en los primeros años, y que lo podíamos montar de manera fácil y rápida. Por ello nos pusimos manos a la obra y hemos montado la infraestructura de etece usando lo siguiente:

  • EC2 (máquinas virtuales) para los servidores web donde básicamente corren los Apache con PHP
  • Los EC2 de la web están detrás de un balanceador ELB que permite añadir y quitar de manera muy fácil, rápida y dinámica (si tienes tiempo de configurarlo) servidores web en función de la demanda (autoscaling).
  • Como base de datos usamos RDS, servicio de base de datos relacional que puede correr Oracle, SQL Server o MySQL, nuestra elección.
  • ElastiCache, el servicio de Memcache que ofrece Amazon, para la caché de aplicación y la gestión de las sesiones de Apache, permitiendo así la alta disponibilidad de los servidores web.
  • CloudFront, CDN de Amazon, que sirve el contenido estático por diferentes dominios. En nuestro caso usamos subdominios distintos para estilos, imágenes y scripts.
  • SES, servicio de envío de emails (se terminaron los dolores de cabeza para mantener un SMTP que envíe correctamente sin llegar a spam) para los emails transaccionales de la aplicación.
  • Route 53, el DNS de Amazon, necesario si quieres apuntar un dominio directamente a un CNAME. Los balanceadores no tienen IP fija y si no usas este servicio necesitaras un subdominio por delante de tu dominio, por ejemplo www.
  • CloudWatch en conjunción con SNS (servicio de notificaciones) para la monitorizacion y alertas de todos los servicios anteriormente indicados. Asociado a alertas puedes lanzar acciones como levantar o parar más instancias de las mismas máquinas.

Amazon tiene más servicios pero a nosotros con esto nos basta y nos sobra.
Entrar al detalle de cómo hemos montado todos y cada uno de los elementos llevaría mucho tiempo y no es el objetivo de este post. No obstante, es posible que aborde algún aspecto en concreto bajo petición de algún lector.

Pros
Llevar tu infraestructura a la nube de Amazon tiene muchas ventajas. Algunas de las más significativas para etece son:

  • Alta disponibilidad nativa en muchos de los servicios como SES, ElastiCache, RDS, etc…
  • Escalabilidad horizontal muy sencilla si has definido todo bien desde la base.
  • Pago por uso. Puedes tener una infraestructura muy potente y pagar muy poco si tienes poco tráfico.
  • Servicios en continua mejora y evolución. Amazon está apostando fuerte por sus servicios web y se nota.
  • Olvidarte por completo de algunos servicios que son comodity y que causaban muchos dolores de cabeza como SMTP, réplicas de base de datos, rotación de backups, etc…

Contras
No todo puede ser prefecto y existen algunos puntos que hay que considerar. La mayoría tienen que ver con detalles de algunos servicios pero no por eso dejan de ser contras:

  • No es barato. La nube de Amazon te da muchas cosas pero las pagas. No es prohibitivamente caro pero si algo más que otras alternativas como VPSs de algunas empresas.
  • El servicio de base de datos relacional con MySQL (no se si pasa con los otros SGBD) sólo funciona con timezone UTC sin posibilidad de cambio lo que te obliga a tenerlo en cuenta en tus aplicaciones.
  • Si vas con Amazon es para ir con todo y no quedarse a medias tintas. Es la maneja de usar todo su potencial.
  • Debes controlar la calidad de tus emails para mantenerte dentro de unos criterios que define Amazon si quieres usar SES.
  • La invalidación de contenido servido por CloudFront es muy lenta, es mejor usar versionado de los elementos y controlar tu mismo su invalidación.
  • La consola web está muy bien pero hay cosas que se tienen que hacer mediante el uso del API a través de la SDK como el autoscaling lo que supone, en algunos casos, invertir más tiempo del deseable para dejar todo muy fino.
  • No existe a día de hoy un servicio de almacenamiento compartido. Hay gente que usa S3 para este propósito pero el tiempo de acceso a los recursos lo desaconseja totalmente. Nosotros hemos montado un servidor que comparte su almacenamiento por NFS y mientas las máquinas con las que comparte estén en la misma región, el tráfico es gratuito.

Operativa
Como parte de nuestras tareas básicas de operaciones hacemos algunas preventivas que se podrían automatizar pero de momento no tenemos tiempo:

  • Tenemos siempre una imagen actualizada de cada tipo de máquina que usamos. Así levantar nuevas imágenes clon manualmente y escalar a demanda es casi inmediato, aunque es manual.
  • Guardamos snapshots de cada máquina después de cada cambio para poder recuperar el último punto bueno conocido y poder crear nuestras propias imágenes cuando necesitemos.
  • Monitorizamos mediante CloudWatch todos los parámetros importantes de cada servicio y asociamos alarmas a los más importantes.

Todavía nos queda mucho camino que recorrer pero creo que tenemos un buen punto de partida. Espero que estas líneas puedan ayudara alguien y por supuesto, estaré encantado de contestar las preguntas relacionadas con el tema, siempre que conozca la respuesta.

Mi opinión sobre el programador perdido


Desde la publicación por Enrique Dans del artículo El programador perdido se ha levantado un gran revuelo y diferentes corrientes de opinión al respecto. Tanto es así, que Wilhelm Lappe, Emilio Rey e Iván Pérez han organizado #debate10 un evento para debatir, comentar e intentar encontrar el punto de encuentro entre programadores y emprendedores. He tenido la suerte de ser invitado a participar pero como seguro que hay poco tiempo y hay que condensar mucho cada opinión, voy a desarrollar un poco mi punto de vista al respecto y así, de paso, me vale para ordenar mis ideas, que falta me hace. Para ello voy a plantear algunas preguntas e intentaré dar respuesta.

¿Existe el programador-emprendedor?

Rotundamente si. Yo soy el claro ejemplo de ello. Tanto en TagUin como ahora en Etece dedico una parte muy grande de mi tiempo a programar, sin abandonar otras tareas necesarias para sacar adelante el proyecto. Pero no soy el único. Mi amigo, socio y compañero de viaje Javier Fernandez es otro claro ejemplo. Pero a eso puedo añadir a otro colaborador cercano como Fran de la Fuente, que no tiene problema en unirse a un proyecto emprendedor si ve que es un proyecto serio. Estos son algunos ejemplos, pero conozco muchos más.  La clave está en el matiz proyecto serio.

¿Existen proyectos serios que necesiten de programadores?

De nuevo, rotundamente si. Y cuando se tiene un proyecto serio entre manos, y en este caso hablo como emprendedor, no es dificil convencer y atraer talento. Eso si, el talento se paga y como dice David Bonilla, no es barato. Por tanto, si quieres tener una buena base técnica en tu proyecto, prepara el dinero. Aunque no todo es dinero, también se puede ofrecer un atractivo paquete que incluya un salario más que decente más una parte en participaciones más un futuro plan de stock options. Los técnicos somos raros pero no gilipollas y si todos los socios de una empresa se pueden forrar, nosotros tambíen queremos forranos. Y de nuevo doy la razón a David Bonilla, si pagas poco obtendrás un proyecto con unos cimientos técnicos muy malos que no te llevarán a ninguna parte.

¿Están los emprendedores dispuestos a pagar lo que cobra un buen programador?

De nuevo hablo como emprendedor y se que el dinero es un bien escaso en un proyecto por lo que todo emprendedor intenta recortar de donde puede. Pero creo que ahí está el error. Si tienes un buen equipo técnico te será más fácil encontrar inversión. Por tanto, paga lo que tengas que pagar pero haz ver a los inversionres que es dinero bien invertido. Ahorrarte 10.000 o 15.000€ al año en el sueldo de un buen programador es un gran error porque a la larga te vas a gastar mucho más dinero en cambiar o incluso rehacer aquello que no quedó bien hecho por falta de experiencia del programador. De nuevo el matiz es lo importante, a la larga es lo que piensan muchos emprendedores y creen que si el proyecto va bien, no será problema en rehacer muchas cosas a la larga, pero que si va mal, se han gastado menos dinero. Ahí tenemos un proyecto que no es serio. En un proyecto serio se hacen las cosas bien desde el principio.

¿Existen programadores con experiencia dispuestos a unirse a una startup?

No nos engañemos, una startup es sinónimo de cierta inestabilidad profesional, muchas horas de dedicación, mucho stress, noches sin dormir, y un largo etcétera de cosas malas, pero también hay una gran lista de cosas buenas. El caso es que no todo el mundo quiere y puede unirse a una startup pero si creo que hay gente con el perfil adecuado esperando la oportunidad. Para muchos profesionales una startup puede ser la oportunidad de crecer profesionalmente y pasar de ser un programador senior a un futuro responsable de desarrollo o incluso CTO. Y hay gente que está dispuesta a asumir ciertos riesgos por esa oportunidad. También hay gente con espíritu emprendedor y que el trabajo en un gran empresa no le llena. Hay muchos más ejemplos, pero prácticamente nadie se va a rebajar el sueldo un 70% para unirse a una startup. Todos tenemos que vivir, pagar hipotecas, colegios, etc… Hay mucha gente, sobre todo inversores, que piensan que emprender tiene que ser sinónimo de sueldos bajos o casi inexistentes para los fundadores. En un post anterior ya di mi opinión sobre el sueldo de los fundadores y en el caso de los programadores es lo mismo. Seguro que con un proyecto serio y un plan de retribución adecuado encuentras gente que se baje el sueldo un % razonable durante los dos primeros años pero no se puede pretender que trabajen por amor al arte.

¿Las ganas valen más que la experiencia?

Hay veces que se contrata a un programador con poca experiencia, 4-5 años, y se le pone el título de CTO. En ese caso se está dando más peso a las ganas del programador de unirse al proyecto y tener un puesto de responsabilidad que la experiencia real que pueda aportar. Anteriormente ya comenté lo que creo que hace falta para ser CTO así que, bajo mi punto de vista, es más importante la experiencia que las ganas.

¿Hay suficientes programadores en España?

Vamos a dejar a un lado las obviedades que se oyen en algunos medios  de que hacen falta menos economistas y abogados y más ingenieros y programadores. Eso está claro y por mucho que lo repitamos, si no tomamos medidas serias, el problema no se va a resolver. En este punto le doy la razón a Enrique Dans cuando dice que habría que afrontar este problema desde la base, incluyendo asignaturas de programación en los colegios e institutos. Yo empecé a programar con 10 años en un dragon 32 que le regalaron a mi hermano y que sólo entendía basic. Nadie me enseñó, símplemente me picaba la curiosidad, me hice con un libro y me puse a ello, sin más conocimiento. Pero no podemos esperar que los programadores salgan de manera expontánea, hay que incentivarlo desde la base y para ello hay que hacer planes de estudio a largo plazo que favorezcan el cambio productivo de nuestro país. Pero ahí entramos en el terreno de los político y estamos bien jodidos. Lo más que van a hacer son políticas cortoplacistas (como mucho 4 años que dura una legislatura) para salvar su culo y con un poco de suerte estar otros 4 años chupando de bote. La educación, como la sanidad, el terrorismo y alguna cosa más son problemas de estado que no deberían obedecer a ciclos legislativos. No pude ser que cada gobierno cambie los planes de estudio a su antojo y mucho menos que en cada comunidad autónoma se estudie cosas distintas. Pero bueno, me estoy metiendo en temas políticos y ahí me enciendo demasiado…. Volviendo al tema que nos ocupa, en España hay menos programadores de los que necesitamos, hay un porcentaje razonable de programadores que no saben hacer bien su trabajo, como en todas las profesiones, pero también hay grandísimos profesionales que están a la altura de los mejores del mundo. Por tanto, hay menos de los que necesitamos pero los hay, sólo hay que proponerles un proyecto serio y unas condiciones adecuadas.

¿Emprender en Internet en barato?

Pues depende con qué lo compares. Si lo comparas con montar un bar de copas con un colega, emprender en Internet es caro, pero si lo comparas con montar una planta de tratamientos de resíduos radioactivos, es barato. El caso es que, no se muy bien por qué, hay bastante gente, principalmente emprendedores de otros sectores, que piensan que emprender en Internet es barato. Piensan que invirtiendo 50.000€ se puede montar una empresa que facture 50 millones en tres años y se la puedes vender a Amazon por 100 millones. Si quieres montar un buen proyecto de Internet te hace falta bastante dinero y debes pensar que, al menos, el 30% de esa inversión debe ir destinada a la parte técnica.

Resumiendo…

… que me lio y al final no digo nada. En mi opinión:

  1. SI existen los programadores-emprendedores o los emprendedores-programadores.
  2. SI se pueden encontrar buenos profesionales con experiencia, capacidad y ganas de unirse a un proyecto serio, pero hay que pagarlo.
  3. SI existen proyectos serios, bien financiados y con un gran futuro donde los buenos programadores pueden desarrollar una buena carrera profesional.
  4. NO hay tantos programadores como nos gustaría pero hay más de los que nos pensamos.
  5. Cualquier programador no vale para montar técnicamente bien una startup, hace falta un equipo con experiencia.
  6. Hacen falta cambios importante es la base educativa para que la falta de programadores no vaya a peor e incluso pueda suponer un punto de pivote del modelo productivo español.

Como seguramente en #debate10 no tenga tiempo de desarrollar todos estos puntos, me centraré en comentar mis conclusiones. Cualquier comentario o debate al respecto será bienvenido.

Mis errores como emprendedor líder en tagUin


En noviembre de 2009 dejé Toprural para liderar un nuevo proyecto que había concebido algunos meses antes. Me fui de Toprural movido por el gusanillo emprendedor y por el deseo de liderar mi propio proyecto. Si no hubiera sido por eso, voluntariamente me hubiera quedado mucho más tiempo ya que sentía que aportaba cosas a la vez que aprendía otras muchas.
En aquel momento las redes sociales verticales estaban en pleno auge y yo venía de participar en dos proyectos muy exitosos, pensaba que mi momento había llegado. Como ya conté en un post anterior, tanto François Derbaix como José Luis Vallejo me apoyaron desde el principio, me ayudaron con el plan de negocio y me enseñaron cómo encontrar financiación. En paralelo, Javier Fernández y Alberto Rodríguez completaban el equipo emprendedor y trabajaban en ls primera beta del proyecto, que vio la luz en junio de 2009 en forma privada para algunos beta testers. Mi rol no era tan técnico como en anteriores proyectos, para eso estaba Javier. En este caso tenía que liderar el proyecto en todos sus aspectos.
Conseguimos 160.000€ de capital semilla aportado por amigos, familiares y algunos business angels lo que suponía un inmejorable punto de partida. No obstante cometí muchos errores que han hecho que hoy tagUin esté en una vía muerta. Entre tantos errores he destacado tres que creo que son los más significativos, aunque si preguntáis a mis socios, seguramente identifiquen otros muchos:

  • No crear un equipo más heterogéneo. Es uno de los errores de libro pero yo lo cometí. Los fundadores teníamos un perfil demasiado parecido y dejamos cojas áreas clave en una startup. Hacer un buen equipo es muy difícil y además uno de los factores de éxito más importante. Como fundador líder debería haber buscado un equipo más complementario.
  • Invertir demasiado pronto en marketing. En una startup que arranca con poco capital, invertir correctamente cada euro es otro de los factores de éxito y yo no lo hice bien. En mi deseo de crecer rápidamente y alcanzar unos objetivos de negocio razonables que nos permitieran cerrar con garantías la siguiente ronda de financiación, invertimos en marketing cuando nuestro producto no estaba suficientemente maduro y eso suponía que cada usuario que captábamos, no lo rentabilizábamos correctamente. Además, el capital inicial que teníamos no nos permitía hacer demasiados experimentos por lo que teníamos una bala y teníamos que acertar en la diana a la primera. Lo he comentado alguna vez a quien me pregunta sobre el tema: es mejor apuntalar y mejorar el producto antes de invertir en marketing. Si no te puede pasar como a nosotros.
  • Arrancar sin capital suficiente como para demostrar a los inversores que el proyecto tiene “tracción”. Este es quizá el punto más controvertido, sobre todo entre los más firmes defensores del emprendimiento low-cost pero me voy a explicar. Cuando un proyecto va orientado al gran público y además necesita de un volumen importante para que el modelo de negocio tenga sentido, hay que tener claro que la inversión necesaria es muy grande. Los inversores que invierten después de la ronda semilla esperan ver que el proyecto ha despejado algunas de las incógnitas del business plan y además ha encontrado un camino hacia el éxito. Mi error fue arrancar tagUin sin capital suficiente como para llegar con garantías a ese punto, sin gasolina para llegar al punto que los inversores esperan de un proyecto invertible en búsqueda de su segunda ronda de inversión. Sin esa gasolina, nos quedamos a mitad de camino, en la vía muerta en la que estamos ahora. Fueron mis ganas de emprender y mi falta de experiencia en el arranque de proyectos lo que me llevó a pensar que con 160.000€ en un proyecto como tagUin se puede llegar a ese punto, pero no creo que sea así.

Estos errores fueron, bajo mi punto de vista, los más importantes, aunque hubo otros. En diciembre de 2010 y de la mano de José Luis Vallejo a través de su empresa Medianet, Javier y yo pasamos a formar parte del equipo técnico que desarrolló un core de ecommerce para Prisa Digital en paralelo a Planeo, el site de ofertas de ocio del Grupo Prisa. Esto suponía aparcar definitivamente tagUin, dejándolo en modo supervivencia. En este momento tagUin tiene unos 40.000 usuarios registrados, aunque muy poco tráfico. De hecho estamos buscando la mejor manera de liquidar el proyecto, vendiéndolo, traspasándolo o cerrándolo.
Mi rol en Prisa fue la de responsable técnico de Planeo y product-proyect manager de ecommerce en Prisa Digital. Esta nueva fase tampoco estuvo exenta de errores. Pero eso lo contaré otro día.