Plan de empresa

Dejando por un momento de lado la parte de desarrollo, el equipo de eventuo se encuentra en un punto de inflexión por él que toda startup ha de pasar antes o después: el plan de empresa.

El plan de empresa es necesario, porque entre otras cosas:

• Ayuda a ordenar ideas.
• Sirve para planificar y pensar anticipadamente en el nuevo negocio, para así prevenir dónde puede surgir problemas y tener preparadas alternativas.
• Da una visión global del proyecto y sirve de guía para cada fase del proceso de creación.
• Instrumento de autoevaluación.
  
• Reduce considerablemente el riesgo de fracaso.
• Herramienta de formación.
• Determina oportunidades de negocio y los mercado de interes mas prometedores para la empresa.
• Crea un marco de comunicación y venta.
• Permite analizar los costes y la rentabilidad.

Puntos extraídos de la Guía para la elaboración del plan de empresa (Catalán)

Si no me equivoco, la mayoría de empresas que nacen empiezan por el plan de empresa. Por los puntos antes comentados y, sobretodo, para defender el proyecto a la hora de buscar financiación e inversores. Si se piensa detenidamente, no cuesta darse cuenta que cualquier negocio que empiece necesita capital -capital que normalmente el emprendedor no dispone-, ya sea para alquilar un local y comprar el mobiliario, pasando por la compra de máquinas, hasta la contratación de personal.

En nuestro caso no sucede así. Nacemos como una puntocom. La inversión inicial para la puesta en marcha es mínima. De hecho, nuestros únicos gastos son el hosting y el alquiler de un lugar de trabajo. Y el alquiler es por el factor psicológico de tener un lugar donde trabajar juntos que consideramos importante, porque sino desde nuestras casas también habría sido posible.

Quitando el factor económico, en su momento no empezamos eventuo por el plan de empresa -aparte de no tener idea de qué era ni de cómo se hacía- muy probablemente porque no teníamos una idea clara de lo que tenía que ser eventuo. Sí que sabíamos que iba a ser una página social de eventos, y disponemos de mucha documentación sobre ello, pero nos faltaba saber qué hacía falta, qué sobraba, qué podría funcionar, etc. Y, como todo negocio, cuáles serían la fuentes de ingresos. Cierto es que el plan de empresa te ayuda a encontrar estas respuestas.

Pero el hecho que empezásemos con el desarrollo del producto, nos ha dado mucha libertad a la hora de crear, probar y errar, consiguiendo así un producto más sólido y definido. Además, a lo largo del desarrollo van surgiendo nuevas ideas, que se van implementando, enriqueciendo así el resultado final. Y en paralelo hemos tenido alguna que otra reunión con Joan Pinyol, del equipo de DexmaTech, quien nos ha orientado en los aspectos de enfoque del negocio para conseguir beneficios. Pensábamos que viviríamos de publicidad, ¡qué inocentes!.

Lo que está claro es que el plan de empresa se ha de hacer antes o después, aunque haya casos en que no sea tan necesario desde un principio. Contiene aspectos tan importantes pero tan desconocidos por la mayoría como un plan de Marketing -sólo anunciarse en AddWords no sirve- o el plan Económico-financiero -tendón de Aquiles de las startups-. Por suerte existen organizaciones como el Programa Innova y el Barcelona Activa que realizan, entre otras cosas, cursos para la elaboración del plan de empresa. Ahí estaremos.

No, no hemos hecho vacaciones

Queridos lectores y otros seres:

Aunque ha pasado mucho tiempo desde el último post, no es porqué hayamos hecho vacaciones. Ni mucho menos. Han sido semanas intensas que apenas nos han dejado tiempo para escribir.

Muchos de vosotros queréis ver resultados ya, y nosotros también. Nuestras previsiones decían que a finales de agosto tendríamos una versión operativa, y la tenemos. Sin embargo, aun faltan demasiadas cosas para sacar una beta en condiciones. Exactamente, la mitad:

Como habéis visto, nuestro Trac nos dice que estamos al 51%. No queremos que la pregunta "Qué página de eventos visitáis?" tenga una respuesta distinta a eventuo. Por ello los niveles de calidad que nos hemos impuesto nos impiden publicar ya mismo.

Además, antes de publicar eventuo al gran público, habrá una etapa de pruebas y testing, aunque internamente ya tengamos más de 100 tests escritos. Queremos que vosotros participéis y recibir vuestras opiniones. Los interesados que se apunten a nuestra mailing list, y a parte de recibir detalles más técnicos, quizá recibáis una invitación!

Mientras tanto, podríais escuchar el último disco de Neil Halstead (Mojave 3), qué para los tiempos que corren en el mundo indie, no está nada mal.

Hoygan, qué es la frikipedia?

El viernes estábamos hablando Giro y yo sobre los comentarios, opiniones personales, descripciones y demás opciones de edición que podría realizar el usuario en eventuo. Estas opciones crean la problemática de las faltas ortográficas, algo que puede dar un aspecto poco serio y dejado al sitio web: para muestra un botón.

Me vino a la cabeza un término que se utiliza mucho en foros pero cuyo significado desconocíamos: hoygan. Buscando en Google, las primeras entradas que nos aparecen son hoygan.info y la frikipedia. Esta última resultó ser todo un descubrimiento y pasamos un buen rato riendo. Según ellos:

La Frikipedia es un compendio extremadamente serio de todo el conocimiento humano (la tercera especie más inteligente de la tierra) y parte del de los delfines (que son la segunda).

Recomiendo darse una vuelta por la página buscando términos y navengando por los links. Las imágenes no tienen desperdicio. Aunque algunas entradas son bastante fuertes, que nadie se lo tome mal, hay descripciones de todo y todos:

• Cani, aka pelados, quillos, etc.
  
• Chuck Norris, no podía faltar
• Steven Seagal
  
• Sete Gibernau
• Franco
• Antena 3, mirar también sus presentadores
• Reggeatón
  

Hay un montón de personajes y términos, es cuestión de ir probando. Cuidado que engancha.

Por cierto, los hoygan tienen los días contados. No me extrañaría nada que en eventuo hiciésemos uso de un filtro.

Un día en el trabajo

17:38: Zoidberg empieza su presentación en eventuo towers. Fry llega tarde. Zoidberg nos revisa la estructura interna de nuestra plataforma. Además nos explica por qué declarar los atributos final en Java siempre que se pueda.

Gana credibilidad el Doctor.

17:53: Zoidberg sigue en lo suyo. Ahora nos explica la grandeza del Mylyn y como concentrarnos en lo que toca. "Viva el eclipse" dice.

Sería de locos no hacer caso a este crustáceo.

18:01: Ahora es turno para el Profesor Farnsworth. Este se aleja del dominio y se centra en las vistas. Nos descubre algunos trucos de Freemarker y nos convence por que dojo es nuestro framework de JavaScript. Y por qué debería ser también el vuestro.

No se puede decir que este viejo chochea.

18:09: Los asistentes están atentos a la presentación. En eventuo todos utilizamos nuestro propio sistema para apuntarnos a los eventos, aunque sean internos. En este caso fuimos cuatro que dijimos yo voy!

18:12: Todo el mundo sigue en su sitio. Nadie en su sano juicio ignoraría las enseñanzas de las dos eminencias encargadas de la presentación.

18:15: No había sillas para todos. Más bien para nadie.

18:27: El evento ha concluido. Todos vuelven a Planet Express. Parece que Bender Blending Rodríguez ha perdido su capa de aluminio.

18:28: Mordisquitos (Nibbler para los puristas) se ha comido un trozo de manzana.

Maldito bicho.

18:30: Vaya, ni ofreciendo tal espectáculo hacen caso al (gran) Doctor Zoidberg.

Pobre crustáceo.

El código importa

Tal y como ha explicado Jake en el post anterior, un buen diseño de cualquier aplicación es necesario. Por diseño debe entenderse siempre diseño interno, lo que acaba viendo el usuario puede encargarse, sin menosprecio, a cualquier diseñador gráfico que sepa que es un CSS y que el flash no es esa gran herramienta que para webs maravillosas.

Esta tarea de diseño suele encargarse a grandes Jefes de proyecto, para que luego sus lacayos, llamémosles becarios, lleven a cabo sus más maléficos planes. Sin embargo, esa gran persona encargada de poner los cimientos, de crear una estructura, decidir cómo hacer las cosas, va y coge el Word y te hace 4 cajas. Como maestro del wordart que es, te pinta cuatro cajas representado lo de siempre, lo que todo desarrollador deber saber: Vistas + Dominio + Persistencia + BD.

Mientras tanto, sigue maquinando con el cliente como tiene que ser la aplicación, rellenando miles de papeles, firmando contratos, garantías, actas... "Cualquier cosa que marque una metodología pesada como RUP nos llevará al éxito", deben pensar. Y eso no se puede negar, pero lo habitual es que entre tanto diseño, se olvida la figura del técnico, del ingeniero de software, del picateclas que le sacará las castañas del fuego.

Cuando su diseño llega a las manos de los desarrolladores, normalmente estos cogen las cajas y empiezan a crear monstruos. Y lo más grave de todo, no piensan en quien vendrá después o con quien tienen en su equipo. En quien cogerá semejante trozo-de-mierda para su mantenimiento y acto seguido hará las maletas para irse a la fin del mundo.

Esto es culpa tanto del Jefe de proyecto / diseñador, y el propio programador. Hacer un código elegante implica hacer buen código, código eficiente y efectivo. Todos los frameworks, libros, jefes y demás, se llenan la boca afirmando que su código es reutilizable. Eso no es más que una gran mentira si el código que implementa tu aplicación no se revisa y no se tiene en cuenta.

El código debe ser revisado por otros, pulirse y rehacerse, es decir hacer refactoring. La típica frase de "si funciona no lo toques" no debería ser vuestra pan de cada día. Sin lugar a dudas las metodologías ágiles como eXtreme Programming te llevan a crear una aplicación de calidad en poco tiempo. Te obligan a testear (ave JUnit) cada parte de tu software, reescribir tu código y en definitiva, mejorar tu software.

Los grupos de trabajo jerárquicos con el gran Jefe de proyectos en la cima, con sus expertos haciendo las mil maravillas, deben pasar a la historia. Hay que apostar por grupos colaborativos donde todos dependen de los demás y todos hacen de todo. Hay que dedicar más tiempo al diseño y a una buena implementación. Seguramente al principio se avanzará más lentamente, pero la curva de desarrollo aumentará de tal manera que compensará el esfuerzo inicial. Los que crean que es mejor hacer que simplemente todo funcione de cualquier manera, ya tardan en seguir a nuestro enviado al fin del mundo.

Somos ingenieros

Una de las cosas que más nos motivan en el proyecto de eventuo es el probar y experimentar con nuevas tecnologías, patrones de software, frameworks, etc. Principalmente para hacer las cosas bien e incluso mejorarlas -se está haciendo un gran esfuerzo en este aspecto, para así cumplir una serie de características del la ingeniería del software- o simplemente para innovar -siempre que sea a mejor-.

De hecho, a falta de una remuneración económica -esperemos que no muy lejana-, el aprender nuevas tecnologías supone nuestra mayor motivación y recompensa. Obtenemos así un amplio abanico de conocimientos y habilidades que nos permiten poder enfrentarnos a cualquier desafío, pudiendo casi asegurar que creamos un software de calidad, un software creado por ingenieros.

Y es que la mayor parte de los problemas que aparecen a lo largo de la vida de un sistema software, ya sean simples webs o complejas aplicaciones, vienen dados porque no se consideran obras de ingeniería.

Me explico. Sólo un ingeniero de caminos puede crear la estructura de un puente, porque se supone que sólo él es capaz de tener en cuenta todas las variables necesarias para su construcción. Si otra persona que no fuese ingeniera de caminos diseñase el puente, seguramente no se aguantaría.

Pues ocurre lo mismo con la ingeniería informática. Parece que, sobretodo en las consultorías, el trabajo de un ingeniero informático lo puede realizar cualquiera. Después los proyectos van como van.

Por eso en eventuo dedicamos todo el tiempo necesario a aplicar los conocimientos de la ingeniería informática y sobretodo de la ingeniería del software a hacer las cosas bien. Ahora estamos en la fase de implementación, quedando patente que realizar un buen diseño hace que el desarrollo sea mucho más guiado y sencillo. Y sabemos que los cambios y las revisiones no supondrán problemas.

Entonces, ¿no es mejor dedicar más tiempo a realizar un buen diseño -por alguien que sea ingeniero- para que luego todo sea más sencillo y elegante, en lugar de, realizar un diseño rápido que habrá que ir modificando constantemente teniendo que rehacer código o creando parches?

Adobe Flex y eventuo

Cuando aún no se había empezado en serio con el proyecto de eventuo, se barajaron diferentes tecnologías para la realización de la capa de presentación. Personalmente era partidario de utilizar Adobe Flex, ya que en la empresa donde antes trabajaba -SITEP- se estaba utilizando cada vez en más proyectos. De hecho, mi proyecto de final de carrera lo utilizaba y quedé bastante satisfecho con los resultados.

Mi amigo y partner Giro, realizó prototipos de lo que sería la pagina principal de eventuo con Adobe Illustrator y a partir de las imágenes creadas, se pasaron a código. Giro lo hizo mediante HTML, CSS, JavaScript y JSP, y yo con Flex. Tal vez por mi falta de experiencia el resultado con Flex era bastante distinto al de los prototipos. Además, la interfaz se mostraba inestable colocando de vez en cuando, por ejemplo, elementos donde no tocaba. Finalmente, se optó por las tecnologías que ambos conocíamos , y otras de las que se hablará en futuros post.

A continuación, enumero los elementos que considero positivos y negativos, y que habría que tener en cuenta antes de desarrollar en Flex:

Ventajas

• Al compilar Flex se crea un archivo Flash, pudiendo asegurar que se verá igual en cualquier navegador, sin necesidad de pelearse con los estilos.
• Se crean páginas de manera rápida, sencilla y con un acabado excelente.
• La ayuda y los ejemplos ofrecidos por Adobe son muy buenos.
• El framework es gratuito, antes era de pago.
• Ahora Google puede indexar páginas Flash.
• Facilidad para separar por componentes.
• Se pueden añadir componentes a la web, como gráficas, que dan un aspecto muy conseguido.
  

Desventajas

• A mi modo de ver, orientado a páginas donde el usuario ha de interactuar con una interfaz de aplicación o con fines comerciales como la venta o presentación de productos.
• Para sitios más dinámicos, donde se manejan grandes cantidades de información, no me parece la solución más idónea.
• Con páginas de cierta complejidad se pierde pierde rendimiento y estabilidad.
• Las barras de loading al cargar, sobretodo si estos son largos, hacen que la página se vuelva pesada.
• Nunca será tan rápido como una página de texto plano.
• Dificultad para aplicar patrones software.
• A fecha de hoy, no se puede desarrollar en Linux.

En resumen, Flex es muy bueno para unas cosas, sobretodo cuando se quiere conseguir una estética de aplicación vía web, por ejemplo. Pero no es tan bueno para sitios donde el usuario está de paso y sólo busca información.

Hefner: Britain's Largest Small Band > 1996 - 2002

Sir Darrey Hayman acompañado de Jack Hayter recordaron esos tiempos en que Hefner era sin duda una de las bandas más prolíficas del Reino Unido. El pasado sábado ofrecieron un corto pero nada despreciable concierto en el Parc de l'Escorxador de Barcelona. Que el concierto fuera corto Darren lo solucionó con una más que simpática frase: "El concierto es gratis y que yo sepa ninguna de las canciones que hemos tocado hasta ahora estaban incluidas en la entrada". Pues claro que sí hombre. La otra opción era pagar un abono para el Primavera Sound y ver conciertos de misma duración.

La selección de temas fue de lo más precisa posible, seleccionando hits de casi todos sus álbums. Además, por si era poco que una parte de Hefner decidiera volver a sus andadas, Darren decidió rodearse de varios discípulos de The Wave Pictures en la batería y el bajo.

La cercanía del grupo y la idoneidad del lugar, rodeados de palmeras, hacía que al acabar el concierto quisieras asaltar la improvisada mesa de terraza Estrella Damm en busca de preciosos tesoros. Como era de esperar, indumentarias varias ya habían sido adquiridas por inmerecidas manos, dejando en la mesa de operaciones joyas como una edición limitada de The Fidelity Wars. Suerte tenemos de los popis.

Personalmente, poder dar la mano a un sex symbol internacional es todo un Honor. Más aun cuando ves como ídolos nacionales, llamémosles Los J, repudian a sus seguidores nada más acabar su actuación. Otro dia publicamos la lista de bandas que deberían separarse antes que su mierda actual tape lo que eran en el pasado. Si no lo decía explotaba.

Esto es un Blog

eventuo está en camino. Añadir este blog a vuestro Reader favorito para estar al tanto de las últimas actualizaciones. Combinaremos opiniones personales sobre eventos, detalles del proyecto en si, artículos más técnicos, etc. Nuestro primer objetivo, alabar al Señor: Guice