Emprendiendo proyectos de software

Ahora mismo se está viviendo una auténtica ola sobre el emprendimiento en mi país; no sé si en otros lugares está sucediento lo mismo. Lo que debería ser una actitud que se les enseña a los niños desde parvulario, ahora parece que lo estamos aprendiendo a marchas forzadas (por la urgencia de la crisis económica y financiera que llevamos arrastrando desde hace tiempo).

Revistas y publicaciones, programas de radio y televisión, másters y mucho libro de autoayuda para el desarrollo personal y coaching así como programas de apoyo al emprendedor están ahora por todos sitios.

Para mí todo esto es bueno porque supone que dejamos de pensar que los demás nos van a dar un trabajo y tomamos la responsabilidad de pensar por nosotros mismos, lo que en algunos círculos llaman el empoderamiento personal. Esta misma actitud es también muy positiva como empleado de una compañía, lo que se llama intraemprendedor, es decir, aquella persona que trabajando en una empresa innova o aporta ideas desde su ámbito de responsabilidad manteniendo una actitud proactiva continuamente, con él mismo y con todo lo que le rodea.

Los desarrolladores de software quizá tengamos más facilidades que otros profesionales para emprender en un momento en que todo el mundo mira a Internet y el paradigma económico impulsa la eficiencia y el uso masivo de dispositivos siempre conectados. De ahí que muchos desarrolladores tengan continuamente ideas que poner en marcha con las que intentar emprender un proyecto empresarial.

Programar bien y dominar tecnológicamente ciertas plataformas, no tiene nada que ver con emprender un buen proyecto que funcione comercialmente. Para esto hacen falta muchas otras habilidades que, por supuesto, se pueden aprender.

Lo que no es nada bueno es que se ignoren todas esas habilidades y conocimientos necesarios para montar comercialmente un proyecto. Me preguntaron no hace mucho qué pensaba yo al respecto y cuáles podrían ser los primeros pasos para pasar de la idea al producto, de modo que en esta ocasión me voy a extender un poco más de lo habitual y aportar mi granito de arena para al menos indicar todo lo que hay que tener en cuenta.

Hay cientos de libros, seminarios, cursos y hasta másters que cubren este tema, que, además, evoluciona igual que las tecnologías software. Por tanto, este post viene a ser algo así como una introducción acelerada al emprendimiento con proyectos software.

Por su extensión, he dividido este trabajo en las siguientes secciones.

De la idea al proyecto

En cierta medida, emprender es probar si lo que tienes en mente puede funcionar o no y encontrar un mercado para esa idea o producto. Si de lo que se trata es de probar algo y según los resultados obtenidos, evolucionarlo tantas veces como sea necesario, entonces todo esto huele un poco a ágil y a lean, a iterar sobre algo hasta conseguir un buen resultado.

Muchas veces los errores son grandes maestros. Allá por el 2008 tuve mi primer contacto con un proyecto y una idea emprendedora que fue un auténtico desastre a los pocos meses; la razón es que confundimos la idea con su realización, la amistad con un relación de compromiso en un proyecto común y, por supuesto, una ignorancia total sobre cómo darle cuerpo empresarial a lo que queríamos desarrollar, entre otros muchos errores... Ese primer proyecto fracasado lo recuerdo con cariño por todo lo que me enseñó; también es cierto que ahora se hace mucha apología del fracaso como herramienta de aprendizaje. Digo yo que en un punto intermedio entre la indolencia y el no fustigarnos al tropezar estará la virtud.

En cualquier caso, desde entonces han pasado muy cerca mía multitud de proyectos de conocidos, charlas en eventos sobre modelos de innovación y muchas, muchísimas lecturas al respecto. Igualmente proyectos personales con mayor o menor éxito.

Si estás pensando en poner en marcha una idea que implica el desarrollo de cualquier tipo de software me gustaría decirte que el desarrollo del mismo es tan sólo el centro de un universo de variables y tareas que hay que hacer bien, relacionadas o no con el software pero que sin ese universo tu idea no llegará a ninguna parte, me temo.

Como desarrolladores nos gusta dedicar gran parte de nuestro tiempo programando, creando artefactos que hacen algo, pero si desarrollamos un proyecto emprendedor basado en software, entonces no podemos ignorar dotarle de la estructura emprendedora correcta. Y, por supuesto, estar dispuesto a gastarte algunos eurillos... Esa coletilla de comenzaron sin nada es sólo un mito urbano que pudo funcionar para algún visionario pero de ninguna manera es lo general. No entiendo cómo alguien que dice creer en su idea después no es capaz de invertir en ella algo de dinero.

Veamos cuáles son esas piezas fundamentales en las que casi ningún emprendedor de software ilusionado apenas repara y ni le da importancia y, sobre todo, cómo algunas decisiones desde el punto de vista del software son fundamentales.

La idea, por evidente que parezca decirlo, sólo existe en la cabeza

¡Qué sorpresa! En otras palabras, lo que quiero decir es que si esa idea no sale de la cabeza cobrando vida mediante la acción, ahí quedará, como un ente mental sin valor. Para la mayoría de la gente, las ideas se quedan ahí dentro, sólo para unos pocos la idea es lo suficientemente fuerte para pasar a la acción.

En multitud de ocasiones pensamos idílicamente en un proyecto maravilloso, único, que podría funcionar, es decir, generar usuarios y clientes y por tanto, ingresos. Entonces hacemos planes de cómo hacer esto o aquello, sobre qué tecnologías usar (a menudo son siempre las que más conocemos), las posibilidades que se podrían abrir y un largo etcétera. 

En ocasiones, también, estas maravillosas ideas no son más que quimeras mentales para huir de una realidad personal o laboral que no te gusta. Esto lo he visto hasta la saciedad.

Si eres un iluso, quédate en el mundo de las ideas, pero sólo las que inducen a la acción, al trabajo y al esfuerzo, saldrán adelante.

No hace falta inventar un proyecto maravilloso y totalmente innovador: muchas veces, propuestas que parecen triviales y hasta aburridas son las que encuentran un mercado y una viabilidad.

En mi opinión existen dos momentos claves para pasar de esta fase (llamémosla de la idea al proyecto). La primera es sentarse tranquilamente a poner por escrito una descripción clara del proyecto, su misión, sus expectativas, etc. Poner por escrito todo lo que tenemos en la cabeza tiene un valor incalculable por la sencilla razón de que te obliga a definir cosas que hasta ese momento sólo eran entelequias un poco vagas. Muchas ideas no pasan de esta prueba...

Existen técnicas para pasar al papel una idea de proyecto, como la técnica del canvas (o lienzo), con herramientas online que te ayudan a su definición, como Canvanizer. Del mismo modo, los mapas mentales también ayudan en esta fase.

El segundo momento, si es que se ha superado el primero, es adquirir un compromiso con uno mismo. Ningún proyecto incipiente se va a desarrollar si antes no nos comprometemos personalmente con él, esto es, no nos comprometemos a sacar tiempo extra (quitándonos tiempo de ocio, de fines de semana, etc.). Sólo cuando hay compromiso personal es cuando se llega a algo. Lo sorprendente es que cuando crees en algo, no hay esfuerzo que valga, ya que estás deseando dedicarle tiempo.

Al menos eso funciona para mí: cuando hemos terminado una fase de un proyecto a tiempo, o realizado cualquier proyecto personal sea del tipo que sea, la mayor satisfacción me la produce el haber cumplido con un compromiso personal previo autoimpuesto.

Si este paso a la acción te cuesta trabajo necesitas urgentemente El Arte de Empezar de Guy Kawasaki.

Hay que validar la idea

Me gusta el enfoque lean en la realización de proyectos, sobre todo si son proyectos basados en software que viven en un mundo acelerado en donde los paradigmas cambian tan rápido. Lo que triunfa ahora es la disrupción. 

En un mercado tan saturado de todo, ¿cómo podemos averiguar si ese proyecto que has definido puede funcionar o no? Atrás quedan los años de grandes inversiones en proyectos tecnológicos muy largos para llegar a la conclusión, tras su finalización, de que la idea era equivocada o no existía un mercado para tan maravilloso proyecto.

¿Para qué dedicar todos los recursos de tiempo y dinero sólo para comprobar si algo puede funcionar o no? 

El enfoque lean se basa precisamente en probar esa idea en etapas tempranas (y baratas) en la realización del proyecto.

No hay que leer, sino estudiar estos dos libros: El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua de Eric Ries  y El Emprendedor Lean, ambos amenos de leer y complementarios.

Diseña un producto base, mínimamente funcional, con las características básicas necesarias para mostrar tu idea de proyecto y el problema que pretende resolver.

A continuación, antes de publicarlo oficial y globalmente, valida el producto en primer lugar con una muestra pequeña de usuarios. Esos primeros usuarios pueden ser perfectamente tus amigos, familiares, conocidos y amigos de amigos. Ellos te van a indicar qué piensan, seguramente te den un feedback de incalculable valor porque esto te va indicar si tu idea puede seguir creciendo en la dirección que esperabas o sencillamente hay que volver atrás, darle una vuelta o bien tirarlo todo a la basura. Si ocurre esto último, ¡maravilloso!, no has dedicado un tremendo esfuerzo en tiempo y dinero en un producto totalmente terminado sólo para comprobar que a nadie le interesa y, de paso, habrás aprendido bastantes cosas.

Básicamente, la realización lean de proyectos se basa en realizar experimentos para comprobar si tu idea de proyecto funciona, según el resultado de esos experimentos, hay que modificar el proyecto (pivotar) o bien se llega a la conclusión de que no existe viablidad.

Hasta hace poco tiempo, probar la viabilidad de un proyecto software era caro, pero hoy día esto resulta muy barato y lo puedes hacer tú mismo en tu tiempo libre. Hay sonados casos como el dueño de Groupon, que comenzó su idea probando con sus amigos y familiares y las tiendas de su barrio.

Si estas primeras fases de validación de tu idea son positivas, entonces es el momento de crecer, en mejorar el producto, en búsqueda de socios (será más fácil encontrarlos si tienes algo tangible que mostrar), de financiación, etc. Es decir, pasamos de jugar con una idea a darle un poco más de seriedad.

No es lo mismo buscar financiación con una idea vaga (o un abultado plan de negocio sobre el papel) que enseñar un prototipo funcional que muestre claramente lo que quieres desarrollar.

Por otra parte, antes de haber invertido mucho tiempo y esfuerzo en tu proyecto, podrás valorar la viabilidad del mismo según el interés que puede despertar de manera muy sencilla y barata. También incluso antes de tener nada que enseñar, ¿cómo?

Una forma se trata de la prueba de la infame página de inicio: antes de tener nada realizado, publicar una sencilla web estática que muestra claramente tu propósito e incitar a que los usuarios que llegan a ella te reporten algún tipo de información.

A poco que muevas y divulgues esa web, recibirás feedback, comentarios y sugerencias, información que te indicará mejor el posible interés en ese proyecto. Créeme, cuando a la gente se le pregunta es sorprendente cuántas personas están dispuestas a colaborar, sobre todo si perciben que están ayudando a alguien.

Otra forma de validar la idea que se está usando cada vez más es publicarla en un portal de crowdfunding: si recibes rápidamente los fondos que has solicitado, seguramente estés en el buen camino.

Pivotando y mejorando la idea

Ningún proyecto va a tener un éxito rotundo desde que lo concebimos hasta que lo publicamos (a no ser que seas un visionario, claro). Lo habitual es que pongas en marcha una parte de la idea de tu proyecto y sólo tras publicarlo podrás comprobar en qué medida encaja y tiene éxito. Por tanto, se intenta publicar lo más pronto posible para aprender y experimientar la viabilidad del mismo. Esto a mí siempre me ha sonado a conceptos muy de software como continuous delivery (entregas continuas) y continuous improvement (mejora continua). De hecho, el enfoque lean de desarrollo de proyectos está muy emparentado con el desarrollo ágil, o dicho de otra forma, en realidad no se lanzan productos y proyectos para conseguir comerte mundo, sino para experimentar con el mercado y escuchar detenidamente qué tiene éste que decir. 

De esta experimentación se aprende a aproximar tu producto lo mas posible a un mercado que lo demanda y aprendiendo de esta experiencia te permitirá volver un poco atrás y pivotar, esto es, evolucionar tu proyecto para acercarlo mejor al feedback y todo aquello que has aprendido tras su primera publicación. Quizá lo que aprendas es que no merece la pena pivotar de ningún modo, que tu producto no le interesa a nadie, lo cual no es bueno sino magnífico ya que has averiguado en una etapa muy temprana que tu propuesta no tiene viabilidad (ahorrando así mucho esfuerzo y recursos económicos).

Se pivota para mejorar tu producto y acercarlo mas a las necesidades y el feedback que has decubierto y para aportar valor continuamente. Lo curioso de pivotar es que en ocasiones las respuestas del mercado te hacen dirigir tu producto por un camino totalmente nuevo e insospechado al comienzo.

Este proceso de experimentar / aprender / pivotar / volver a publicar no es que se haga sólo al inicio del proyecto, sino que es la filosofía básica de trabajo que lo acompañará durante toda su vida, del mismo modo que no es imaginable un Amazon con la misma funcionalidad y posibilidades que ofrecía hace tan sólo dos años. 

Nada peor que volver a un portal un año después y comprobar que no ha cambiado nada, lo que da la impresión de estancamiento. Penoso.

Como decía antes, las primeras pruebas (o experimentos) se pueden hacer de manera trivial con tus familiares, conocidos y amigos.

Branding y diseño

En un mercado supercompetitivo (estamos hablando de productos hechos con software, webs, portales, aplicaciones móviles, desarrollos específicos para la nube, etc.), con millones de aplicaciones disponibles a golpe de clic y una web saturada, ¿cómo comienzas a distinguir tu proyecto de otros?

Hay que definir todo lo relacionado con el branding, esto es, definir tu estilo de marca. 

Esto se suele asociar únicamente con inventar un nombre para tu proyecto y nada más, pero el branding es muchísimo más hasta el punto de que hay compañías especializadas en proveer este tipo de servicios.

El branding abarca:

• Elegir un nombre correcto para tu producto o proyecto
• Comprobar que no están registrados los dominios
• Comprobar que no existan ya compañías con ese nombre registradas
• Crear una buena imagen de marca que incluya un logotipo o isotipo (o una mezcla de ambos)
• Darle una identidad coporativa a tu proyecto
• ¿Suena bien en otros idiomas el nombre del proyecto que has elegido?
• y un largo etcétera

Este trabajo importa y mucho: según la calidad de tu branding tu proyecto llegará más fácilmente a los usuarios o será ignorado totalmente. El contratar este servicio a una empresa especializada lógicamente requiere de un coste, pero el coste puede ser mayor si no se hace.

La cuestión aquí es: ¿branding antes o después?, pues dependerá de tu tipo de proyecto, de la capacidad inversora que tengas, etc.

No hace mucho asistí a una charla de Máximo Gavete, experto en branding que dispone de su propio estudio de asesoramiento, Omixam Studio. En esa charla me quedó más que claro que el branding es de vital importancia.

Elección de tecnologías

La elección de las tecnologías más apropiadas para un proyecto de software es todo un arte en sí mismo al tiempo que una decisión que puede lastrarlo en el futuro. Lo habitual es que usemos aquellas tecnologías que mejor conocemos (lo cual no siempre es lo más acertado).

Hay que analizar bien qué necesidades de escalabilidad podría tener el proyecto en el futuro, qué APIs de terceros debería integrar, qué modelos de seguridad, etc. 

Si se elije una tecnología que no conocemos bien, tendremos que superar su curva de aprendizaje para comenzar a avanzar productivamente en el proyecto.

Igualmente, según las tecnologías que usemos se puede tener un coste posterior mayor en el despliegue (en licencias, hosting más elevado, etc.).

La elección no es sencilla, pero sí sugeriría lo siguiente:

• Si lo único que quieres es validar una idea y evaluar el posible interés en ella, entonces trabaja rápido con la tecnología que mejor conozcas. Si después obtienes un respaldo positivo, entonces plantea mejor técnicamente el proyecto.
• Si no estás seguro de haber elegido la mejor opción, intenta por lo menos que ciertas partes del sistema se puedan intercambiar en el futuro por otro tipo de tecnologías o proveedores (repositorios abstractos de datos no ligados a una base de datos en concreto, frontend muy ligero, etc.)

Sentido común, en definitiva.

Costes de despliegue

Si estás trabajando en un proyecto web, es una obviedad decir que vas a tener que desplegarlo para que esté a disposición de todos los usuarios a nivel global.

Dependiendo de las tecnologías que hayas usado y de la naturaleza del proyecto, hay que considerar un coste de despliegue y explotación que se suele ignorar hasta que el proyecto está maduro para publicarlo.

Internet no es gratis, otra obviedad, cuando despliegas un proyecto no es sólo cuestión de buscar un hosting; se incurren en costes tales como:

• Registros de dominios.
• Certificados SSL (que no son baratos precisamente).
• Servidores dedicados o máquinas virtuales.
• Si su despliege es en la nube, coste de servicios relacionados (base de datos, cuentas de almacenamiento, etc.)
• Si tu aplicación hace un uso intensivo y comercial de correos, tendrás que contratar un proveedor como SendGrid, MailChimp o Mandrill, por poner un ejemplo.
• Tráfico de datos. Aunque los gigas de bajada y subida son baratos, si tu proyecto require un uso intensivo de tráfico entre tus usuarios, el ancho de banda usado supondrá un coste adicional.
• Servicios de CDNs (content delivery networks).

Todo esto, como digo, depende de la naturaleza del proyecto, pero es importante tenerlo en cuenta sobre todo porque te indica (junto con otros costes) un umbral económico que tendrás que monetizar en algún momento.

Igualmente, no hablamos de los costes de mantenimiento: si crees que el proyecto termina cuando lo has publicado, te puedes llevar una gran sorpresa. Las bases de datos hay que mantenerlas, los servicios en la nube hay que comprobar su buen comportamiento, si el proyecto crece sustancialmente en usuarios lo más probable es que descubras cuellos de botella si antes no has hecho pruebas de rendimiento, hay que mantener la misma gestión de los usuarios que escriban al formulario de contacto, que hagan solicitudes de cualquier tipo o necesiten resolver cualquier incidencia, etc.

No es por desanimar, pero es que todo esto va en el mismo paquete.

Definiendo KPIs (indicadores de rendimiento)

Como personas que además estamos muy implicadas y vemos desde dentro nuestro proyecto, nada peor que imaginar las impresiones que este está causando según comentarios o respuestas subjetivas. 

Hay que validar el proyecto con datos objetivos, simples y medibles (KPI) y para ello tenemos que definir métricas que nos indiquen lo más claramente posible el interés que despierta así como gestionar correctamente todos aquellos comentarios, sugerencias, usabilidad y funcionalidad del proyecto.

Antes de lanzar y expermimentar con la primera publicación, hay que definir qué métricas necesitamos para valorar precisamente el interés que puede despertar la idea. No solo hay que definirlas, sino que también hay que determinar cómo se van a implementar. En un principio, hasta puede que la analítica web gratuita de Google sea suficiente, pero seguramente no sea suficiente.

Esta métricas son muy particulares para la naturaleza de cada proyecto, aunque por poner algunos ejemplos:

• Número de usuarios registrados a la semana. Parece una obviedad, pero si detectamos que el número de usuarios crece semanalmente un 5%, estamos por el buen camino, siempre que estos vayan generando un retorno en la misma proporción.
• Tiempo de permanencia del usuario en la web.
• Tasa de rebote (usuarios que llegan a la web y no ven nada más).
• Recurrencia en el acceso de los usuarios.
• Obviamente, si la web comercializa algo, medir cantidad de productos vendidos así como su tipología. Si la web vende algún tipo de objetos físicos, hay que hacer un seguimiento de los pedidos, su pago, la gestión logística con el operador de transporte, etc.
• Porcentaje de uso de todas y cada una de las funcionalidades del proyecto. Así descubriremos qué cosas les interesan más a los usuarios y qué características no.
• etc.

No validamos una idea con comentarios positivos y subjetivos sobre la misma, sino con datos medibles y los más objetivos posibles, sobre todo aquellos que nos permiten mejorar el producto, qué partes merece la pena potencias y cómo todo eso se traduce en ingresos. Nada sencillo.

Esto no es es final, ni mucho menos

Hasta aquí ya tenemos una idea de la distancia enorme, a veces abrumadora, que existe entre tener una idea feliz y ponerla en marcha, y esto es sólo la punta del iceberg. Cubriendo esos temas que he tratado muy resumidamente estamos en el camino de materializar con éxito un proyecto; en mi opinión, llegar a publicar algo para validarlo y comprobar que no es acertado, no deja de ser un tipo de éxito (hemos experimentado con el mercado, según la terminología lean).

Si no has reparado hasta ahora en todos estos temas, siento actuar de abogado del diablo, pero se trata de tener claro en qué consiste poner en marcha un proyecto junto con todos sus pros y contras.

Pero espera, que aún no hemos terminado...

Todo lo anterior es importante pero no suficiente. Aún queda mucho camino por andar y nada hemos comentado sobre los siguientes temas:

• SEO, SEM, marketing, comercialización y redes sociales. Según la naturaleza del proyecto, habrá que implantar una política de gestión en todos y cada uno de esos aspectos. Sí, existen ejemplos de proyectos que han triunfado sin apenas trabajo de comercialización o de community management, pero la mayoría sí se tienen que tomar en serio este trabajo ya que actúa como palanca de difusión del mismo.
• Estructura empresarial. No se pueden obviar aspectos legales a la hora de publicar algo que vaya a suponer transacciones económicas. Facturar, llevar una correcta contabilidad, cumplir con la hacienda pública, etc., todo ello es necesario tenerlo también muy en cuenta desde el primer momento en que vemos que la idea ha superado esa fase inicial de validación.

Por último, algunas conclusiones

Me preguntaron no hace mucho cómo comenzar los primeros pasos de un proyecto interesante para su publicación en Internet, de modo que aquí, muy resumidamente, he intentado indicar lo más relevante de todos aquellos aspectos necesarios para ejecutar cualquier idea o proyecto de la manera más profesional posible.

Me atrevería a decir que todas esas cuestiones se pueden aprender casi sobre la marcha, de hecho me encanta en concepto de learning by doing en contraposición al parálisis por análisis que también he visto en muchas ocasiones. Aprendemos (y tenemos éxito) actuando, y es sólo en la acción cuando uno se choca de cara con el fracaso y con el éxito, sea lo que sea que cada uno entienda por ello.

Para aprender sobre nuestras deficiencias tenemos librerías llenas de libros reconocidos y recomendados que por poco dinero nos pueden ahorrar meses de trabajo.

Para mí, sin ninguna duda poner en marcha un proyecto es la mejor fuente de aprendizaje que podemos tener.

Lo más importante para materializar cualquier proyecto, y lo digo completamente convencido, es el compromiso con uno mismo, más aún si lo hacemos personalmente con poco tiempo por tener compromisos laborales, una familia, etc. 

Meses de ensoñaciones y de planes maravillosos (incluidos visualizaciones de qué hacer cuando este genial proyecto triunfe) se quedan en una simple e infantil quimera si un lunes a las diez de la noche o un sábado temprano no nos ponemos a trabajar. Internet está plagado de fracasos, pero ese número de proyectos fallidos se queda corto con todos aquellos proyectos que se han quedado en la mente de sus dueños.

Sólo la gente de acción es la gente que progresa.