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.

Anuncios

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.

Mis errores como CTO en BuyVIP


Me incorporé a BuyVIP en febrero de 2007. Primero como empleado de Medianet, empresa socia fundadora de BuyVIP, siendo CTO part-time compartiendo tareas con otros proyecto de dicha empresa. Pero rápidamente las necesidades de la empresa requerían una dedicación a tiempo completo y pasé a la plantilla de BuyVIP. En aquel momento toda la tecnología estaba externalizada en Medianet y hacía falta que BV tomara dicho control por lo que mi primera preocupación fue crear equipo propio. Para ello conté con varias personas que conocía de etapas anteriores y en las que confiaba. Era la primera vez que era CTO y de ahí vinieron muchos de mis errores. Los que más destaco son:

  • Falta de seniority. No es tanto un error mío sino una característica inherente a mi situación en aquel momento. Era la primera vez que era CTO y además no había tenido ningún espejo en el que mirarme. Por suerte, este tipo de “errores” se corrigen con el tiempo y con ejercicios de autocrítica como esta serie de posts. Ya lo he comentado en algún post anterior, un CTO no es un programador venido a más o como en mi caso en aquel momento, un jefe de proyecto venido a más.
  • No pensar a lo grande. En un proyecto como BuyVIP en el que todo va muy rápido y el crecimiento es enorme hace falta pensar a lo grande y concebir la estrategia técnica de la misma manera. Siempre intenté dar los pasos adecuados cimentados en base sólida pero en algunos momentos en BuyVIP ese no era el mejor camino.
  • No imponer más mi criterio. Derivado del primer error comentado y en un entorno donde el CEO de la empresa tiene un carácter y un empuje muy importantes y que intenta imponer su criterio en todos los órdenes de la empresa, me dejé influir en muchos aspectos en contra de mi criterio y creo que de esa influencia vinieron las peores decisiones o acciones tomadas en el departamento técnico. Debería haber sabido demostrar que mi criterio era el correcto y no dejarme influenciar. Este punto fue la principal razón de mi salida voluntaria de BV en junio de 2008.
  • No pedir ayuda. Hay veces que hay que reconocer que te hace falta ayuda. Yo quería hacerlo lo mejor posible y quería hacerlo demostrando que podía hacerlo con mi equipo pero en aquella situación lo mejor hubiera sido reconocer que hacía falta un CTO con más experiencia y ponerme a rebufo suyo para ganar experiencia y conocimientos.

De todo se aprende. Muchas veces repaso situaciones de aquella época y pienso cómo las hubiera afrontado ahora. Las cosas hubieran sido diferentes aunque a toro pasado todo se ve de otra manera.

Tal y como he dicho antes, me fui voluntariamente de BV en junio de 2008. Tomé la decisión de marcharme un par de mese antes y así lo comuniqué. El nivel de estrés que tenía junto con mi falta de feeling con la dirección de la empresa me hicieron tomar esta decisión. El siguiente paso fue incorporarme a Toprural como CTO. Pero eso lo cuento en el siguiente post…

Mis defectos y virtudes


Voy a empezar a escribir una serie de posts bastante reflexivos, con una dosis fuerte de autocrítica y auto análisis que espero que sirvan a alguien para no cometer los mismos errores y de paso os animen a hacer el mismo ejercicio. Creo que es importante conocer nuestras fortalezas y debilidades para intentar corregir las segundas e impulsar las primeras. Como le decía a un gran amigo hace ya algunos años en tono jocoso: “lo primero es reconocer que eres un atraso de persona. A partir de ahí todo es construir”.

Los posts que quiero escribir en esta serie son:

No van a ser posts demasiado largos ya que no tengo demasiado tiempo. Mi hijo ha cumplido un año hace pocos días y le dedico el poco tiempo libre que tengo. Por eso voy a escribir en ratos cortos e intentaré que los posts sean muy concentrados.
Me pongo a ello…

Robo de información a BuyVIP


Escribí este post hace algunos días y lo dejé en borradores. Mejor publicarlo tarde que nunca.

Las noticias en Internet vuelan y lo que es actualidad un lunes, ya no lo es un jueves. Por eso este post puede parecer un poco obsoleto, ya que hace días que BuyVIP mandó un email a todos sus usuarios activos indicando que habían sido víctimas de un robo en el que les habían sustraído la información de sus usuarios. Fui CTO de BuyVIP durante un año y medio y por tanto soy especialmente sensible a estas cosas y en base a ello me gustaría compartir con vosotros mi opinión.

Información sustraída
Tal y como indica la propia BuyVIP en su comunicado, les han robado nombre, dirección de email, dirección de envío, fecha de nacimiento, teléfono y contraseña. Es decir, les han robado aquella información que tenían en la base de datos. Ellos mismos dicen que los datos de pago no se han visto afectados, pero creo que está mal expresado. No se han visto afectados porque BuyVIP no almacena esa información y por tanto al no tenerla no se la pueden robar. Yo hubiera remarcado este hecho, ya que creo que transmite más confianza al usuario.

Otro punto que merece la pena comentar es el de la contraseña. BuyVIP no almacena la contraseña en claro, si no encriptada con MD5 usando una semilla, dando por tanto un código alfanumérico de 40 caracteres. Un MD5 no se puede desencriptar y para saber si la password es válida lo que se hace es encriptar la recibida y comparar con la almacenada. Por tanto si alguien quisiera obtener la password debería hacer un proceso de prueba y error encriptando todas las combinaciones de letras y números (si no recuerdo mal hasta 100 caracteres) y compararlo  con lo almacenado. Eso suponiendo que tenga la semilla, ya que si no la tiene ni aún así se obtendría la password. En resumen, han robado la encriptación de la password, pero no la password real. Personalmente estoy tranquilo porque tengo claro que nadie va a obtener mi password en base a lo robado de BuyVIP.

Comunicación a los usuarios
Todo el mundo intuía que pasaba algo ya que tiraron voluntariamente la tienda un miércoles (hablo de memoria) y no volvió a estar operativa hasta el sábado, pero la gente pensaba que estaría relacionado con la apertura de la tienda de Amazon en España. El mismo sábado avisó a sus usuarios activos en los términos comentados, pero hasta varios días después no avisaron a los usuarios dados de baja. Ya comenté en twitter que pensaba que era un error ya que, si bien un usuario dado de baja ha decidido no recibir más notificaciones, estamos ante un hecho extraordinario y al fin y al cabo también han robado la información de los usuarios dados de baja. Pero lo más crítico de este hecho es que indirectamente BuyVIP ha reconocido que guarda toda la información del usuario a pesar de haber sido dado de baja. Me gustaría conocer la opinión de un abogado al respecto ya que esa información debería haber sido borrada con la baja y podría haberse hecho perfectamente ya que no debería afectar en ningún caso a la información financiera relacionada. Algún abogado en la sala que nos de su opinión?

Qué pueden hacer con la información robada
Si el autor del robo lo ha hecho con el fin de obtener datos de pago, la jugada le ha salido mal, pero si simplemente quería obtener una bbdd grande, cualificada y bastante completa de usuarios y compradores de toda Europa, le ha tocado el gordo, ya que BuyVIP tiene varios millones de usuarios en su base de datos. Esa información la puede vender a empresas de email marketing no muy legales para enviar publicidad. La pueden vender incluso a empresas de publicidad física que te envían cartas a tu buzón. Se pueden hacer muchas cosas y no me extrañaría que en los próximos días o semanas recibiéramos más spam del habitual.
Otra alternativa es usar esa información para obtener todavía más info por physing, mucho cuidado con las próximas notificaciones que recibáis en el email pidiendo confirmar datos.

Espero que dentro de unos meses todo quede en una anécdota y los problemas no vayan a más para BuyVIP.

Qué hace falta para ser CTO


En mi anterior post sobre equipo técnico en una startup, Luis Clemente me preguntaba sobre qué hace falta para llegar a ser CTO. Tal y como le contestaba a él en ese comentario, esa reflexión tiene contenido suficiente como para escribir un post y por ello aquí estoy reflexionando sobre, lo que bajo mi punto de vista, hace falta para llegar a ser CTO.

No quiero parecer que hago una descripción de mis aptitudes y cualidades profesionales, ya que alguna de las que mencionaré yo no las tengo, pero cuando me las encuentro en otros profesionales las aprecio mucho y creo que son importantes.

Formación

El primer punto que considero básico es la formación. No quiero decir que para ser CTO hace falta ser Ingeniero Informático o de Telecomunicaciones, pero si considero casi imprescindible tener una base técnica que nos permita entender y desarrollar nuestras funciones sin limitaciones.  Como CTO vamos a necesitar saber de desarrollo, sistemas, infraestructuras, etc… además de otros conocimientos más relacionados con gestión económica, estrategia y negociación, aunque estas últimas es más normal adquirirlas durante nuestra trayectoria profesional. No descuidéis vuestra formación en ningún momento ya que en nuestra profesión tenemos que estar en continuo aprendizaje.

Experiencia

Como decía mi abuela: “más sabe el diablo por viejo que por diablo”. En el ámbito profesional muchas veces tenemos capacidad de resolver problemas o aportar soluciones cuando basamos nuestros criterios en experiencias anteriores de las que hemos aprendido qué funciona y qué no, aunque más veces aprendemos qué es lo que no funciona que al contrario. Por ello creo que un buen CTO suele ser un profesional con unos 10 años de experiencia.

Mi primer puesto de CTO fue en BuyVIP en el 2007 cuando tenía unos ocho años y medio de experiencia y aunque en aquel momento pensaba que estaba sobradamente preparado, ahora me doy cuenta que no me hubieran venido nada mal un par de años más de experiencia. Por el contrario al incorporarme en Toprural creo que tenía una madurez profesional mayor además de más experiencia y conocimiento y pude desempeñar algo mejor mis funciones, aunque quién mejor lo puede juzgar son mis jefes.

Por ello creo que no hay que tener prisa en llegar a un puesto de dirección. En varias ocasiones en mi carrera me he encontrado con buenísimos profesionales que han llegado a puestos de dirección demasiado pronto y no han tenido la madurez profesional suficiente como para asumir las responsabilidades del puesto y aceptar la presión y el stress de una forma natural, lo que en muchas ocasiones desembocó en un profesional quemado, que no hace bien su trabajo y que sufre un parón muy grande en su progresión profesional.

Buenos mentores

Ya que hemos empezado con los refranes, voy a usar uno más: “al que a buen árbol se arriba, buena sombra le cobija”. Es decir busca siempre los mejores jefes posibles e intenta aprender de ellos. En este concepto creo que yo he tenido excelentes jefes y mentores de los que he aprendido y sigo aprendiendo mucho. Por mencionar algunos: Alejandro García y Paco Romero en Capgemini, José Luis Vallejo y Gustavo García en BuyVIP y François Derbaix y Rafael Pérez-Olivares en Toprural.

A todos ellos los identifique como profesionales con más experiencia que yo y con excelente aptitudes en algunas áreas. Lo que hice fue intentar siempre aprender el máximo de ellos en cada oportunidad que tuve e intentar que no se me pegaran algunos de sus defectos (todos tenemos defectos). Sin duda ellos tienen gran parte de culpa en mi perfil profesional.

Por el contrario me he encontrado con algunos profesionales que tienen un potencial enorme y un recorrido importante, pero que, o bien no han tenido buenos jefes y mentores, o bien no han aprendido de ellos lo que deberían. Esta circunstancia les lleva muchas veces a tener experiencias y ejemplos no demasiado buenos y a imitar esos comportamientos cuando están en una situación similar.

Sin duda es esencial tener buenos jefes y aprender el máximo posible de ellos.

Jugador de equipo

Bajo mi punto de vista el trabajo técnico es un trabajo en equipo y en gran medida nuestros resultados, éxitos o fracasos dependen del trabajo y rendimiento del equipo. Por ello creo que es importante ser jugador de equipo en fases previas a ser CTO y aprender a trabajar por y para el equipo. Eso nos llevará a tener una actitud hacia los compañeros muy buena que arrastraremos cuando lleguemos a ser CTO.

Una vez que hemos llegado y en nuestros primeros meses en ese puesto creo que es básico tomarlo con la mayor humildad posible tratando de seguir haciendo equipo, respetando y apoyando al máximo a los compañeros. Sin duda obtendremos mejor rendimiento de todos y mucho más cohesión y mejor ambiente de trabajo.

Orientación a resultados

Mi experiencia es que los puestos directivos son mayoritariamente orientados a resultados. Es decir, no nos van a medir por cuánto trabajamos si no por si obtenemos los resultados adecuados. Esta orientación es importante que se adquiera cuanto antes mejor en nuestra trayectoria profesional y aprendamos a trabajar por objetivos. Si estamos acostumbrados a trabajar nuestro horario y si el trabajo sale bien y si no pues también, sin duda tendremos experiencias muy traumáticas en nuestro camino hacia ser CTO.

Visión comercial y de negocio

En este punto voy a ser un poco polémico, pero creo que merece la pena. Es habitual encontrar profesionales del área técnica que no quieren saber nada del cliente, del negocio y de la estrategia. Si éstos llegan a ser CTO’s no creo que sean demasiado buenos en su trabajo ya que un puesto directivo requiere de una visión mucho más amplia que la técnica para entender los objetivos de la empresa y poder aportar con la tecnología para conseguirlos. Igual estos profesionales de los que hablo podrán ser excelentes arquitectos técnicos o algún otro puesto de alto nivel que sea simplemente técnico, pero para ser CTO hay que tener otra visión mucho más cercana al negocio y poder aportar a mejorar el negocio con la tecnología. Esta visión y orientación al negocio no se adquiere de un día para otro y es importante ir cultivándola durante nuestra carrera profesional. Si trabajáis en consultoría, no perdáis la oportunidad de participar en reuniones con clientes y en cualquier caso intentad siempre plantearos de qué manera ayuda vuestro trabajo al negocio de vuestra empresa.

 

Creo que no me dejo ninguno de los atributos que creo necesarios para llegar a ser CTO. Como siempre me encantará conocer vuestra opinión y si consideráis que me falta algún atributo, no dudéis en comentarlo.

Amazon compra BuyVIP por 70 millones


Mañana día 7 de octubre de 2010 se anunciará formalmente en rueda de prensa la noticia de la que llevan hablando varios medios como Cinco Días o Expansión e importantes blogs como el de Carlos Blanco, que una vez más demuestra tener las mejores fuentes de información. Se trata de la compra por parte de Amazon de BuyVIP, uno de los más grandes, si no el más grande, club de ventas privadas de España, por 70 millones de euros.

Antes de entrar en más detalles, mi mas sincera enhorabuena a los tres fundadores Gustavo García, José Luis Vallejo y Gerald Heindenreich. Sin duda su visión y trabajo han hecho de BuyVIP una de las empresas de comercio electrónico más importantes de España, con una visión internacional desde su nacimiento.

Buena o mala negociación

Una operación de este tipo lleva varios meses de duro trabajo y negociación por lo que sin duda cuando se cierra es siempre un éxito, aunque en las últimas horas se ha visto empañada por la excelente operación que ha cerrado Privalia, que ha hecho una ronda de 70 millones, los mismos que ha pagado Amazon por BuyVIP, lo que pone de manifiesto que quizá Amazon es buen negociador o  los responsables de BuyVIP son malos negociadores.

En mi opinión la valoración ha sido baja, teniendo en cuenta el fuerte crecimiento que siempre ha tenido BuyVIP desde su nacimiento y su presencia internacional, aunque sin duda el momento económico que vivimos habrá afectado. Además, al igual que pasa con Privalia, su mayor competidor nacional, corren rumores de su precaria situación financiera, lo que sin duda ha reforzado la posición de negociación de Amazon.

Acuerdos de permanencia

Ahora se abre una nueva etapa en BuyVIP en la que está por ver cómo se integra dentro del negocio de Amazon y cómo Amazon desembarca en España y cómo afectará esto a los directivos de BuyVIP. Se habla de que la cúpula directiva ha firmado un acuerdo de permanencia de tres años y que parte de sus participaciones en BuyVIP se transforman en phantom shares convertibles año a año. Éste es quizá el punto que veo más controvertido y al que si yo fuera todavía CTO de BuyVIP hubiera puesto más pegas, aunque no conozco los detalles de dicho acuerdo por lo que es mejor no especular.

Operaciones de este tipo son muy buenas para el sector, ya que ponen de manifiesto que Internet y el comercio electrónico son negocios con grandes posibilidades, tanto para los emprendedores como para los inversores. Espero que esta sea otra más de una larga lista de operaciones de éxito para empresas de Internet españolas.