Sobre externalizar tu desarrollo si eres una Startup

Hace unos días Joel Gascoigne, cofundador de la herramienta SaaS para social media Buffer, escribió en su blog tres razones para no subcontratar el desarrollo de tu startup en freelances o agencias de desarrollo.

Imagen por John Kraus

Me parece un tema interesante, sobre todo para contar mi opinión trabajando con clientes que son startups en Simettric.

Las tres razones que exponía son las siguientes

1. “Los objetivos de un freelance y los de una startup están completamente desalineados.”

No puedo quitarle la razón si generalizamos, pero el problema es precisamente este, el generalizar.

En el artículo se hace referencia al concepto de “scope-creep” que se da cuando un proveedor se compromete a tener un desarrollo por una cantidad fija de dinero. A menudo el “contrato” del desarrollo son los requisitos funcionales presupuestados y cuando estos cambian, que es lo más normal cuando trabajas con startup, el desarrollador pueda ponerse a la defensiva y evite el cambio para no perder rentabilidad.

Esto es un error que se comete mucho por parte del proveedor o incluso viene impuesto por algunos clientes. Sin hacer una labor de producto previa se estima un presupuesto y un tiempo fijo para desarrollar funcionalidades en lugar de soluciones a problemas del producto.

Trabajando de este modo es muy fácil no satisfacer las expectativas del cliente y entregar un producto de software que incluso no solucione las cosas a nivel de negocio.

Pero… ¿esto se evita teniendo desarrolladores contratados? La respuesta es no. De hecho el problema no está en quién haga el desarrollo, sino en el pensar que el desarrollo es la solución a todos los problemas y que al delegarlo, puedes desentenderte de la labor de analizar lo que quieres solucionar.

Existe un paso previo al proceso de desarrollar un software y es saber por qué quieres desarrollar la solución del problema y cómo lo vas a resolver en base a los recursos que tienes. Puede que ciertos problemas no requieran tanto o incluso ninguna inversión en desarrollo y en su lugar hacer esfuerzos en otras partes como textos, diseño o soporte humano.

En Simettric no empezamos un desarrollo ni damos un precio cerrado hasta haber realizado un estudio del producto o servicio previamente. Sin esa labor es imposible cumplir con las expectativas del cliente y el proyecto no va a ir bien para ninguna de las partes involucradas.

No somos los únicos y creo que cada vez más agencias y profesionales están evolucionando hacia este punto en lugar de dar un precio fijo en base a unos requisitos vagos en detalle.

Pero no puedo decir que esto sea lo habitual. Desde hace tiempo cada vez se ven más empresas con un proyecto al que no sólo le falta funcionalidad o que pueda tener errores, sino que la funcionalidad planteada no sigue un sentido coherente con el problema que intenta resolver.

En estos casos se da que se ha intentado hacer demasiado en programación pero no se ha seguido evolucionando el diseño, comunicación y en general experiencia de usuario en coherencia, por lo que el producto siempre da la sensación de no estar acabado.

En otros casos, quizás los más habituales, el proveedor se ha salido del proyecto y necesitan alguien que lo continúe. Algunos de estos casos son dramáticos ya que el cliente ha invertido todo el dinero que tenía, incluso su casa y ha vendido su coche, para descubrir finalmente que el desarrollo no resuelva el problema o tenga demasiada deuda técnica.

Pero este caso también se da si contratas equipo interno y de hecho puede incluso ser más dramático dependiendo de cómo lo hagas.

Sin entrar en lo difícil que es retener a un desarrollador senior en una empresa en España y el sueldo que ese perfil esté dispuesto a cobrar, de no disponer de una persona que piense bien el producto y alguien que gestione el equipo de desarrollo cubriendo las necesidades técnicas de la empresa también, las cosas pueden salirse de madre muy fácilmente.

No pretendo dar a entender que externalizar es siempre la mejor opción, ni mucho menos, pero no creo que defender una fórmula u otra como si vendieses una bala de plata sea correcto.

De hecho hay casos en los que el desarrollo tiene cierta complejidad más allá de consultar a bases de datos o APIs REST, con algoritmos y know-how que el cliente pueda perder si no lo tiene en “casa”. En estos casos sí que veo importante el no sacar el desarrollo fuera.

Pero aún así hay fórmulas intermedias. Muchas veces puedes externalizar una parte o un primer producto muy acotado para probar si realmente funciona en el mercado, antes de contratar o hacer inversiones más potentes. Puedes pactar en que el proveedor imparta formación a tu futuro equipo de desarrollo, es algo que en Simettric hacemos e incluso acompañamos en algunos casos al equipo hasta que pueden desligarse del trabajo que hemos hecho.

2. “Te hace pensar de forma equivocada sobre lo que cuesta sacar un producto adelante.”

Esta idea la comparto totalmente, pero creo que también se aplica al ser cauto a la hora contratar un equipo de desarrollo desde el primer minuto.

El pensar en utilizar algo ya hecho, o incluso no utilizar software en absoluto para validar tu idea de negocio es algo que más que aconsejable, es lo que debería hacerse siempre que sea viable. Hay casos en España como el conocido de Carlos Sanchez, al que he hecho referencia alguna que otra vez por aquí.

De hecho creo que lo ideal es que nuestra labor, la de agencias y freelances, debería venir tras esa validación previa y siempre pensando en añadir soluciones con el mínimo desarrollo que aporte el máximo beneficio en mercado.

No nos interesa desarrollar funcionalidad por que sí, haciendo que el proyecto se alargue indefinidamente y que nunca llegue a salir al mercado, quemándonos y quemando al cliente. Salir al mercado cuanto antes de hecho es algo muy beneficioso para nosotros, se cierran etapas, se detectan necesidades reales que aportan beneficio al cliente y este cuenta con más recursos para invertir en desarrollo.

Llegará el momento en el que ya no nos necesite, pero eso también está genial. Nuestro negocio no puede basarse en depender de un único cliente al igual que dicho cliente no debe depender de nosotros. De darse este hecho, no puede ser una relación sana desde mi punto de vista.

3. “Cada fundador debe llevar cada uno de los sombreros (roles).”

Esta forma de pensar creo que depende más del tipo de servicio que ofrezcas y la filosofía de la empresa que del cómo ejecutes el desarrollo junto al resto de tareas en la empresa.

A las personas con perfil técnico nos gusta trabajar con personas de perfil técnico y aunque en algunos casos está muy justificado, hay muchos tipos de negocio en los que el punto de vista tecnológico no es lo más clave, a pesar de ser importante.

De nuevo, no creo que deba aconsejarse que todo el equipo fundador deba saber y encargarse de programar sin ver de qué tipo de negocio estamos hablando.

Lo que personalmente sí que veo importante es que el equipo fundador tenga experiencia previa creando proyectos de este tipo y sepa la importancia de pensar las cosas bien antes de afrontar una inversión de desarrollo apostando por la fórmula que sea.

Todo está bien

Hace año y medio me vine a vivir a Sevilla. Mi mente me pedía a gritos un cambio drástico en el 2013 tras pelear profesionalmente durante los últimos seis años de una forma muy dura en la zona del Gran Bilbao.

Durante esos años me enfrenté a varios retos, levantar mi anterior empresa Blackslot junto a mis exsocios, en la que ayudábamos en el día a día a clientes que tenían negocios en Internet de diversos tipos enfrentándonos a retos como el del cambio de arquitectura de un conocido portal de enlaces a series con un tráfico de cuatro millones de usuarios únicos al día. También recuerdo el crear Artesanio.com junto a ellos y el genial Jose, el forjar una comunidad técnica excepcional en Vizcaya junto a Fran, Ibon y los que nos ayudan siempre como pueden Vicenç, Eneko, Alfredo, Andoni y sin olvidar a Diego, que arrancó conmigo desde el principio. Dicha comunidad ha hecho posibles eventos como el Bilbostack y los techdays que solemos hacer en diferentes ciudades de España. Estas fueron experiencias increíbles que guardo en mis recuerdos junto a muchas otras de esos días.

Pero a pesar de conseguir hacer cosas con un éxito discutible o no, en el 2011 tomé una decisión muy difícil: salir de los dos proyectos profesionales que había estado defendiendo con mi salud y dedicación: Blackslot y Artesanio. Empecé a construir mi agencia de desarrollo de negocios para Internet Simettric y entré como socio en la empresa de mis clientes 4visionshq. Ese año me había dado tiempo a pensar en que realmente necesitaba un cambio personal con urgencia y estaba decidido a hacerlo.

Realmente esos años atrás habían significado mucho sacrificio. En esos años nunca recibimos ninguna subvención ni ninguna financiación privada externa de inversores y sin experiencia suficiente, aunque conseguimos cosas, yo personalmente cometí muchos errores. El más grave fue pensar que sacrificar mi vida personal, amistades y pareja era un coste perfectamente asumible.

Desde fuera, todo se ve muy evidente y claro, pero cuando estás ejecutando con intensidad un proyecto es muy difícil tener perspectiva si no tienes experiencia. Sobre todo si lo que más tienes es orgullo en bruto, sin pulir.

De cualquier forma en 2012, el año más duro que recuerdo con diferencia, tuve la suerte de reconciliarme con mi antiguo grupo de amigos, personas que no tienen ninguna relación con el campo tecnológico. Creo que esto fue algo que hizo que 2012 pasase de ser un infierno a simplemente ser una experiencia más gracias a disponer de una vía de escape personal diaria.

Hay una cosa curiosa con respecto al concepto de “la zona de confort”, y es que dicha zona no tiene por qué ser cómoda. Me explico, puedes estar pasándolo mal y sufriendo por los motivos personales o profesionales que sean pero aun así, aferrarte a esa situación como si fuese un clavo ardiendo.

Pero hay algo muchísimo peor a pasarlo mal o que las cosas no funcionen y es que lo hagan, pero sin permitirte avanzar para alcanzar objetivos más ambiciosos. Y creedme, si has sacrificado mucho a nivel personal, por mucho dinero que entre en tu cuenta, no se puede sentir que hayas tenido un beneficio o éxito claro.

Tampoco estoy diciendo que ganar dinero no mole, a mí me encanta tener una buena entrada de dinero. En un negocio hay que conseguir una entrada de caja potente o estás perdiendo el tiempo, algo mucho más caro que el dinero. Pero siempre hay que pensar que tú como persona, no eres tu negocio.

Ganar perspectiva

No puedo expresar lo importante que es esto. Ni creo que se pueda conseguir sin experiencia real pero hay un detalle o una forma de pensar que me ha ayudado muchísimo en los últimos cuatro años y es pensar que todo está bien.

Hace unos días Jason Fried, autor de los libros Getting Real, Remote y Rework, escribió este artículo en el blog de su empresa Basecamp (antigua 37signals). En él decía que prefería instagram a Twitter porque en Twitter su círculo cercano tendía a ser muy negativo, algo que le chocaba ya que él conocía a esas personas a nivel personal y no eran tan negativas. Esto le daba una influencia negativa que hacía contraste con instagram, que era mucho más positivo y hacía ver a sus amigos como realmente eran, sin tanta “nube negra” sobre sus cabezas.

Cuando siempre lees a las mismas personas o gente del sector hablando sobre lo mal que está todo, aunque sea en broma, por mucha seguridad en ti mismo que tengas, ese input puede llegar a influirte dudando de si realmente no es posible conseguir lo que quieres cayendo en la falsa confirmación de que no consigues lo que quieres porque todo está mal.

Sin embargo, si piensas que todo está bien, entonces el problema está en ti y en cómo estás haciendo las cosas. Igual no has tomado el camino correcto o no estás viendo las cosas con claridad.

Entonces te mueves e intentas hablar con más gente, conoces personas increíbles que hacen cosas brutales y no están ni en Silicon Valley ni en Marte, están en tu mismo país y están haciendo dinero sin renunciar a la felicidad ni a perder tampoco la ética.

Otra cosa importante para ganar perspectiva es separar tu negocio o proyecto de tu vida.

Puedes plantear tu negocio como una forma de vida, hay muchos ejemplos de esto. Sin embargo esto es muy distinto a poner tu tiempo y tu vida a merced de tu entrada de dinero. A lo que me refiero es que en tu vida puedes hacer muchas cosas, muchos negocios y proyectos, en el que estás es uno más.

Si actualmente estás haciendo los mismos sacrificios que yo hacía en su día pensarás que esto es fácil decirlo y algo también muy evidente, pero para mí no lo es. Bajo esa perspectiva, dejar de meter horas un día de una semana complicada puede significar caos y destrucción. Sin embargo, aunque hay semanas duras y algunos meses hay que priorizar, si no te tomas tiempo para ganar perspectiva acabarás por tener una nube gris encima y por perder perspectiva que afectará a la poca vida personal que te quede y al final, también afectará a tu negocio. Todo puede esperar una semana y a veces, debe esperar una semana.

La idea que pretendo transmitir es que por muy dura que sea la situación, todo puede estar bien. Si crees que trabajas demasiado para conseguir realmente poco, seguro que hay una forma de hacerlo. Si todo lo que escuchas es negativo, seguro que hay alguien que te mostrará un camino que ha podido encontrar que encaja con lo que estás buscando. Si estás trabajando en tu oficina hasta tarde por una entrega urgente, seguro que hay alguien dispuesto a tomarse una cerveza contigo cuando acabes. Puede que esto no sea en tu ciudad, país o se dé en tu círculo profesional cercano.

Pero especialmente en el mundo del desarrollo de software, actualmente se puede conseguir una muy buena calidad de vida obteniendo una buena entrada de dinero.

Sólo tienes que buscarlo.

Pet projects

El año pasado este artículo escrito por Mikael Cho tuvo bastante impacto en Hacker News y en general en el mundillo de desarrollo de servicios para Internet. En él se describía la exitosa experiencia personal del autor al crear un side project super simple mientras intentaba salvar su proyecto principal.

En el artículo también se hacía referencia a este otro artículo del genial blog del servicio Buffer donde se describen los beneficios de tener pet projects o side projects al margen de tu actividad o proyectos principales.

Y en ese genial artículo se referenciaba a este post publicado en The PsyBlog, un sitio especializado en psicología, en el que se resumían los resultados de un estudio científico publicado en este paper que recoge los beneficios de tener hobbies o proyectos personales al margen del trabajo principal.

Para el que no lo sepa, un pet project o side project, no es más que un proyecto que creas en tus ratos libres fuera de los proyectos de clientes o tu actividad principal.

Hay bastantes personas, sobre todo en el ámbito de Internet, que ven como algo peligroso el crear cosas al margen de tu proyecto principal, sobre todo si estás luchando por tu startup o tienes otras cosas más prioritarias en las que poner el foco.

El foco

Todos los que hayáis consumido propaganda para emprendedores en los últimos años hasta hartaros, habréis leído sobre la importancia del foco a la hora de crear un negocio o ejecutar un proyecto de cualquier tipo.

“Empezar muchas cosas y no acabar ninguna” es lo que en teoría el foco combate y realmente es así, si realmente se aplica en la práctica.

El problema es que no somos máquinas, somos humanos. Y creo que es genial serlo.

Pero si somos humanos y personas de perfil creativo (programadores, diseñadores etc.) es muy complicado tener la capacidad de poner el foco durante largos periodos de tiempo en un mismo proyecto sin que nuestra productividad y motivación se vean afectados.

Y no me refiero a que, de modo caprichoso, a la mínima desmotivación o cansancio abandonemos el proyecto en el que trabajemos, sino a que es posible que necesitemos desconectar para que nuestra mente recupere el foco o gane perspectiva, que creo que es algo que se puede perder si realmente se pone el foco a nivel obsesivo en un proyecto.

Pero como en toda ejecución, hay diferentes cosas a considerar cuando trabajamos en varios proyectos a la vez, sobre todo si queremos tener “sensación de avance”, algo crítico para no terminar de desmotivarnos o agobiarnos por completo.

El tiempo

“No temo a la muerte, temo al tiempo” Interstellar

No se puede luchar contra el tiempo. Cada día tenemos un número de horas muy reducidas para vivir, ser productivos y descansar.

Lo único eficaz para ejecutar cosas o lograr tener sensación de avance es hacer menos. Me encanta contradecirme, ¿a vosotros no?

¿Cómo puedo defender el aparentemente “dispersarnos” en varias cosas y decir que lo que mola es “hacer menos”? La respuesta es priorizar.

Priorizar es un arte. Cuando desarrollas software para clientes de Internet, tu foco es inexistente. Creas varios productos al año para empresas de todo tipo, al margen de los que hagas para ti mismo para generar negocio o hacer I+D.

La única forma de que no acabe todo en un desastre épico (tu vida incluida), es priorizar.

Hacer lo mínimo que de el mayor valor. Hablo de aplicar el concepto MVP a tus desarrollos y productos, pero también hablo de relativizar y aceptar lo imperfecto.

Al margen de lo que puedes llegar a pensar, el dinero no te salva de priorizar. Priorizar significa saber que el tiempo es mucho más caro que el dinero y lo que vale es alcanzar el objetivo con el proyecto que estás ejecutando, no buscar la perfección o quemar tiempo haciendo cosas que ni siquiera sabes si aportan valor al objetivo de un proyecto.

El proyecto

Lo primero que debes saber para priorizar cosas en un proyecto es saber por qué lo haces. Esto puede aliviar también muchas tensiones al llenarte la cabeza de problemas que no tocan y más aún si inviertes dinero en solucionarlos.

Por ejemplo, si decides que tu proyecto va a ser un negocio es algo genial ya que es posible que ni siquiera necesites invertir en desarrollo. Lo importante en un proyecto así  siempre es vender.

Si por el contrario decides que lo que haces es una herramienta o un I+D, que posiblemente no use nadie más que tú, es también genial ya que seguramente no tengas que lidiar ni con abogados, ni temas fiscales, ni otros dolores de cabeza asociados a temas que no son el mero hecho de “crear”. Lo importante en un producto así lo decides tú: investigar una tecnología, ahorrarte trabajo, visibilidad, aprender…

Ninguna de estas dos opciones “es mejor” que la otra. Al final tú eres el que pones el objetivo y dónde está el éxito. A nadie le debe importar más que a ti o tu equipo y esto aunque parezca evidente es algo que ahorra mucho ruido a la hora de ejecutar.

Para mí, crear algo es una experiencia similar a un viaje. Dar un sólo paso en un día es mejor que pensar en dar quinientos y al final, no dar ninguno.

Un proyecto de cualquier tipo raramente tiene un fin, sólo cuando muere. Si una persona ha creado un producto que se encuentre en la fase que sea y resuelve un problema suyo o de más gente, tanto el proyecto como la persona deberían ser respetados ya que conseguir esa meta no es algo trivial.

Por ejemplo en un proyecto Open Source, aunque no tenga finalidad económica, el que lidere su comunidad debe aprender a establecer unos estándares de calidad, buena comunicación, proteger la propiedad intelectual, ser pragmático a la hora de afrontar cambios sobre lo que el o ella habían imaginado y liderar la toma de decisiones a la hora de añadir o quitar características o funcionalidades. Todo esto al margen del trabajo del desarrollo en sí.

En nuestros días, en los que la palabra emprender ha perdido su significado, es posible que un proyecto que no de beneficio económico o no sea comprado por aparentemente una cantidad relevante de dinero sea tachado de fracaso o ignorado totalmente. Sin embargo, el beneficio tiene muchas facetas y no siempre aparece cuando lo buscas. La única verdad es que hacer cosas aporta y al igual que moverse por todo el mundo, hace que se generen oportunidades imprevistas que alimentan tu perspectiva.

El dar a conocer el proyecto

Decidamos lo que decidamos, si nuestro proyecto no es una mera herramienta para nosotros, para conseguir nuestros objetivos normalmente vamos a necesitar que el proyecto llegue a la gente.

Dos puntos importantes que he aprendido a respetar desde hace años en proyectos de cualquier tipo que se vayan a usar por personas son principalmente dos: el diseño y el copy.

Aquí adquiere mucha importancia aquello de hacer menos. Si realmente hacemos menos y tratamos a nuestro proyecto como un producto, vamos a tener menos problemáticas que diseñar y comunicar/explicar. Esto se traduce en que el coste global del proyecto (desarrollo+diseño+copy) se reduce e incluso puede llegar a ser mucho más efectivo que con presupuestos mayores pero con más problemáticas “a pulir”.

Con un buen copy, un buen diseño y un proyecto que resuelva problemáticas muy concretas podemos hacer que se entienda su valor a la hora de enseñarlo y darlo a conocer.

Sobre el canal para darlo a conocer, depende mucho del proyecto. Lo que sí es relevante bajo mi punto de vista es cuidar la comunidad en torno al mismo mediante charlas, entrevistas, desayunos de trabajo y cualquier idea loca que se pueda ocurrir para involucrar a la gente que realmente va a aprovechar el valor de usarlo.

Cuando hablo de la comunidad, no me refiero a redes sociales sino a personas. Y también al trato después de conseguirlas como clientes.

Conclusión

Desarrollar pet projects al margen de tu actividad principal puede ser beneficioso tanto a nivel profesional como personal.

Ejecutar un proyecto, indiferentemente de cual sea su objetivo, es una tarea que requiere constancia y priorizar. Si conseguimos alcanzar un equilibrio y ser conscientes muy bien de qué queremos obtener, es posible que obtengamos otras cosas que no esperábamos mientras creamos cosas muy chulas con pocos recursos.

Vas a cobrar

shutupandtakemymoneys

Esta mañana he visto como Rafa Vargas exponía en Twitter cinco puntos sobre que él ve claves a la hora de cobrar por tu trabajo y me decidido a aportar mi punto de vista inspirado un poco en su punto de vista.

Sus puntos eran los siguientes:

  • Cobrar por adelantado los presupuestos detallados.
  • Ofrecer un % de descuento sólo a quien pague por anticipado.
  • Eliminar cualquier tipo de flexibilidad en los pagos. Con la excepción de 50% al principio y 50% al final.
  • Introducir una penalización por cambios en un proyecto de 50€ + coste de ejecutar el cambio.
  • No trabajar con quién no quiera hacer sacrificios y compromisos para estar en Internet.

Voy a exponer mi visión sobre estos temas:

Cobrar los presupuestos

Yo en este sentido no cobro los presupuestos pero sí que es necesario que el cliente contrate una consultoría en el que se define el producto al detalle antes de empezar a plantear detalles técnicos a nivel de código o infraestructura.

Me es indiferente que esa consultoría la contrate en mi agencia o se la haga otro proveedor pero sin ella, es muy difícil trabajar bien e incluso hacer un presupuesto realista.

Sí que es una faena el invertir tiempo en redactar el presupuesto y que este no salga, pero eso forma parte del trabajo. Me gusta pensar siempre que eso es como una tarjeta de visita, que el cliente guarda en su memoria y la rescata cuando alguien le pregunta por proveedores a los que contratar.

Descuentos

Si un cliente te paga por adelantado hay que premiarlo de alguna forma, esto es así y una forma habitual de hacerlo es con un descuento.

Es peligroso sin embargo hacer descuentos en situaciones en las que te gusta el proyecto pero el cliente no puede invertir o la persona es un conocido tuyo. En los segundos casos me he arrepentido siempre y en los primeros en muchas ocasiones.

Un buen caso en el que aplicar descuentos bajo mi punto de vista suele ser cuando tienes clara una estrategia en la que tienes un target o perfil de cliente muy claro, o es una temporada concreta u otra situación en la que tengas una estrategia pensada.

En mi caso, desde Simettric ofrezco un precio bastante más bajo de desarrollo a microempresas y startups españolas con respecto a empresas grandes o startup de fuera de España.

Flexibilidad de pagos

Esto depende mucho del cliente, de ti y de la situación de cada uno. En el contrato siempre hay que marcar cómo se harán los pagos del trabajo y es imperativo el solicitar un porcentaje por adelantado. De hecho yo no considero como confirmado un proyecto sin un adelanto y en esto nunca hay problemas si tratamos con empresas y clientes normales.

Los problemas suelen llegar al finalizar el proyecto. Si hay mucho retraso en el pago final y la situación es comprensible, yo suelo ofrecer la posibilidad de pagar de una forma flexible.

Es una faena estar detrás de alguien para que te pague el trabajo y dedicación que le has puesto. Por desgracia hay que estar preparado también para esto y saber cómo actuar.

Es un tema complicado este, creo que para evitar esto es importante seleccionar bien los clientes, no depender mucho de uno solo y si se da el caso, mantener la serenidad y sin ser pedante (al menos al principio), reclamar lo que es tuyo.

Gestión de cambios en lo presupuestado

El hacer un estudio de producto realmente reduce bastante el número de cambios que puedan surgir durante el desarrollo. Sin embargo creo que debemos ser pragmáticos y asumir que va a haber cambios siempre y debemos estar preparados para ellos. Eso sí, si los cambios son a nivel de modelo de negocio, entonces es que se ha hecho una mala definición del producto o realmente se ha cometido un error de comunicación importante.

En mi opinión, lo mejor para evitar todo esto es hacer un producto mínimo viable, para reducir las posibilidades de cambio, salir antes al mercado y tener un mejor producto con más margen de adaptación a menos coste.

Si esto es inviable no queda otra que presupuestar los cambios aparte o cambiarlos, si es posible, por otras funcionalidades que tengamos previstas implementar cuyo coste y dificultad sean equivalentes a los cambios demandados.

Y como nota, creo que además del coste económico es importante que el cliente valore el tiempo de estos cambios. Para mí es mucho más valioso el tiempo que el dinero actualmente por lo que si se producen cambios, siempre intento comunicar que el tiempo de entrega se puede ver y se verá afectado.

Saber con quién trabajar

De esto ya he hablado por aquí antes. Es importante que para ser feliz haciendo lo que hacemos seleccionemos muy bien con quien vamos a trabajar.

Al final somos todos seres humanos y como en todo tipo de relaciones entre humanos, hay que saber muy bien a quien quieres a tu lado y sobre todo a quién no.

Para mi elegir a tus clientes es clave a todos los niveles y es un factor decisivo para que todo vaya genial o por el contrario todo termine convirtiéndose en un infierno.

 

¿Es rentable contratar a un programador?

Foto por HackNY

Un tema que últimamente suelo comentar con profesionales de mi sector es lo complicado que lo tienen para tomar decisiones correctas los dueños de negocios tecnológicos que no dominan temas relacionados con la tecnología en la que se basa su proyecto.

La crisis actual hace que nuestros clientes se planteen si de verdad están pagando de más por un servicio idéntico que podrían obtener a un coste mucho menor.

Por eso he considerado importante aportar mi punto de vista como proveedor de servicios a un artículo que he leído hoy que llevaba como título: ¿sale rentable contratar a un programador español?

En él se expone en un tono que algunos desarrolladores pueden encontrar francamente insultante* la ya clásica idea que ha circulado durante años en el mundo de los negocios en los que se desarrolla soluciones de software: contratar programadores ubicados fuera de España es mucho más económico en tiempo y en dinero.

Actualización: el autor ha corregido el tono empleado inicialmente y ha añadido conclusiones adicionales que resultan bastante interesantes y aclaran mejor sus puntos.

Sin embargo, la mayoría de mis puntos creo que siguen respondiendo y mantengo las frases que inicialmente estaban en su artículo ya que el objetivo de esta respuesta no es el de atacar directamente a una persona, sino a afirmaciones que son típicamente repetidas en general y creo que merece la pena que obtengan una respuesta.

Hay mucha gente que sabe ya, por experiencia propia generalmente, que nadie da duros a cuatro pesetas y cuando esto sucede, siempre hay algo que no cuadra. En este caso sucede lo mismo.

Voy a analizar algunas frases del artículo que me han parecido muy interesantes.

El artículo comienza con la siguiente frase que copio literalmente:

“He trabajado en consultoras que cobraban 12.000€ por hacer una sola página, un modelo obsoleto, sin futuro y por eso dejé de trabajar en consultoría. Pero también he visto a autónomos pedir 3.000€ por esa misma página.”

Hay algo clave que a mí me falta para valorar esta frase:

Definir lo que es “hacer una sola página.” 

Asumo que a lo que se refiere es a desarrollar una landing page, es decir, una sola vista en HTML y CSS o una página con varias secciones utilizando la técnica de diseño “one page website design“. El problema se complica porque también podría referirse a una Single Page Application (SPA), que requiere programación y un proceso de ingeniería que depende del proyecto podría no sólo alcanzar el precio de 12000€ sino triplicarlo o quedarse en 2000€, todo depende de lo que se quiera o necesite.

En cualquier caso, incluso sin referirnos a SPA o similares, no sabemos qué conlleva realizar “una sola página”:

  • no sabemos si conlleva integrarla con otros servicios
  • si conlleva realizar el diseño
  • si conlleva realizar la arquitectura de información
  • si conlleva que sea responsive
  • si conlleva que sea accesible
  • si conlleva que esté disponible en varios idiomas, incluidos los que se escriben de derecha a izquierda, con detección automática de cultura con el navegador
  • si conlleva recoger datos de un usuario
  • si conlleva implantar un seguimiento de conversiones personalizado
  • si conlleva conectarse al equipo del usuario por escritorio remoto

Podría seguir añadiendo puntos, pero creo que la idea está clara, no podemos valorar el precio sin tener más información acerca de lo que se necesita con esa “sola página”.

Seguimos con otro punto interesante:

“Los consumidores quieren comprar en la tienda más barata, es normal. Con la crisis que hay  la gente compara precios y acaba comprando en la tienda de menor precio. O reduces gastos como hacen ellos o cierras, no hay otro remedio.

Supongamos que necesitamos lanzar una promoción en la que esperamos vender unos 10.000€ en productos, y que para competir con tiendas como Amazon u otras extranjeras, tendremos un beneficio de unos 500€.

Si sólo tenemos 500€ de beneficio ¿Cuanto le puedo pagar a un programador si requiero algo para lanzar la promoción?”

Sin entrar en que con esta frase entiendo mayormente que está tratando de hacer que su problema al tratar de competir en precios con Amazon sea el del resto, de nuevo me falta información:

¿Qué es “algo” para lanzar la promoción?

No voy a repetir mi argumento, imaginemos que ese “algo” realmente se puede desarrollar en 4 horas.

Si su beneficio son 500€, desconozco si puede ser descabellado para él invertir en cuatro horas de un programador autónomo en España con experiencia, es decir 240€, a 60€ la hora. Seguramente podría bajar ese precio/hora, al igual que podríamos pensar que podría bajar el precio que le dan sus distribuidores si vendiese como Amazon, pero vamos a poner un precio serio de mercado.

Esa inversión de menos del 50% de su beneficio sería en la primera promoción, después en cada promoción siguiente su beneficio sería del 100%. Encima ese programador le ha emitido una factura y puede desgravarse el IVA.

En el artículo continúa con tres casos concretos en los que pidió presupuesto a varios programadores y en los que finalmente contrató a personas fuera de España.

El primero, que era un juego, literalmente comenta comentaba

“realmente el juego era para tirarlo después”

Consiguió un desarrollo por una persona que lo hizo muy rápidamente y prácticamente regalado. Nada que decir, le importaba muy poco el producto y obtuvo algo funcional, me parece correcto y una buena decisión.

Y es muy bueno que aprendiese a no marear a empresas y profesionales en España pidiendo presupuestos para desarrollar algo que ni valoraba de antemano.

Pero lo clave es su experiencia con los dos siguientes presupuestos:

“El hindú no programó absolutamente nada, instaló Gravity Forms, hizo el formulario y se llevo 50$ en una hora, con dos cojones. Pues bien, esto es lo que yo necesitaba, esto es lo que hace falta, las cosas rápido, por que este sector va muy rápido.”

En esto tiene razón, pero quizá no acudió de primeras a un profesional en España que le hubiese planteado esa misma alternativa, la de utilizar algo ya hecho que encajase con lo que necesitaba, al recibir la documentación que esto seguro que envió al detalle de los requisitos del formulario.

En lo del precio, ya no sabría valorar si algún proveedor en España le hubiese realizado esa gestión a ese precio. Creo que en ese caso seguramente el proveedor adecuado no sería un programador, ya que contratar a un programador en ese caso sería como contratar a un mecánico para que te cambie las escobillas del parabrisas en tu coche, lo puede hacer, pero no es lo más barato.

“Pues bien, 2 semanas más tarde ya tengo el API, funciona, código razonable y limpio con ejemplos de cómo usarlo, me da igual si lo ha copiado de un proyecto de otro cliente, si es Open Source, si lo ha sacado de otro sitio, simplemente tengo un producto funcionando.”

En este caso, pone como ejemplo el desarrollo de una API que le hicieron en dos semanas en el que recalca la idea anterior. Sin embargo no especifica el alcance del desarrollo que requería para ese API ni lo que es “un código razonable”, todo se justifica con que “el producto” que no resultado de un servicio, funciona.

Al margen del tono de los párrafos siguientes, en los cuales parece que las necesidades del autor son las de todo el mundo, (ya corregido) hay dejaba dos afirmaciones que me llaman llamaron especialmente la atención:

“Necesito algo y lo obtengo más barato fuera, al igual que los clientes de juguetes lo compran fuera si lo ven más barato, son las reglas del mercado.”

El problema de esta afirmación es que su negocio parece residir en vender producto y el de un programador es ofrecer un servicio. Son dos cosas distintas, con un valor distinto.

Un servicio de programación no es vender un producto ni configurar un desarrollo ya hecho, algo que puede servir a emprendedores que no tienen recursos suficientes o no requieren algo a medida.

También percibo que esa persona ha adoptado una estrategia de guerra de precios que al parecer le hace disminuir su margen de beneficio y pretende convencernos de que esa estrategia es la que deberíamos adoptar todos si queremos optar a clientes como él. La realidad es que clientes como él van a tender siempre a invertir menos recursos en desarrollo, por lo que a nosotros mayormente no nos es rentable darles servicio.

“if you pay peanuts you get monkeys

Si has pensando en esa frase, es que no has entendido casi nada. Al que llamas mono tiene una licenciatura, un master y pica más líneas de código al día que tú, y sí, están acostumbrados a hacer “mierda” de código para ganar el máximo dinero posible, pero algún día aprenden y empiezan a hacer las cosas más rápido, más optimizadas, mejor estructuradas.”

Hay cosas que no garantizan nunca el ser un buen programador:

  • Los títulos. En programación cuentan las horas de vuelo y las lecciones aprendidas después de equivocarse metiéndose en callejones sin salida.
  • Escribir muchas líneas de código. De hecho, los mejores desarrollos son normalmente los que menos código tienen que mantener.

Tampoco es un buen negocio entregar “mierda” al cliente ya que después esa “mierda” hay que mantenerla.

Conclusiones

He titulado el artículo ¿es rentable contratar a un programador?, sin especificar la ubicación geográfica ya que este detalle lo encuentro irrelevante por la sencilla razón de que en este caso concreto no se busca un programador sino otro tipo de proveedor por las siguientes razones:

  • Si no necesitas un desarrollo desde cero ni adaptar un desarrollo ya hecho, no necesitas a un programador, necesitas un producto ya desarrollado. Esto obviamente será más barato e incluso gratuito, ya que es algo totalmente distinto al servicio de desarrollo a media y por lo tanto, no es comparable.
  • Si no precisas calidad ni ingeniería ni invertir tiempo, no necesitas a un programador, necesitas a alguien que te haga chapuzas. Y un programador con experiencia no te sale rentable e incluso no te podrá dar servicio.
  • Un programador tiene su calendario de proyectos, muy rara vez puede ponerse con el desarrollo de un cliente en el día que entra el pedido. Incluso creo que es un síntoma claro de falta de experiencia el asumir que te dará presupuesto de un desarrollo en el mismo día.

Con respecto a la ubicación geográfica, echo en falta algunos puntos que al menos yo he podido comprobar por experiencia propia y que no he visto comentar en el artículo ya que en todos los casos que expone le ha funcionado muy bien el externalizar el trabajo.

Los puntos que yo creo que son críticos a tener en cuenta cuando externalizas buscando duros a cuatro pesetas son los siguientes:

  • El coste de comunicación. Cuando contratas profesionales (o chapuceros) fuera de tu país, si el desarrollo o el proyecto es importante para ti, es clave poder llevar un seguimiento. Hay muchos factores que incrementan indirectamente el coste de desarrollo, los que yo encuentro más importantes:
    • El idioma.
    • La diferencia de zona horaria.
    • La diferencia en la forma o metodología de trabajo en la primera iteración de desarrollo.
    • Que haya aceptado el proyecto sin leer la documentación, si esta existe, de lo que se requiere. En oDesk o eLance es muy conocido el terminar la descripción del trabajo que ofertas con una frase que el desarrollador debe introducir en su candidatura para descartar a la gente que no lee las descripciones.
    • Posibles problemas a la hora de informar el desarrollo, dichos problemas tienen relación con los puntos siguientes a este.
  • Que ese proveedor en realidad subcontrate el trabajo a otros proveedores y tampoco tenga los conocimientos técnicos adecuados.
  • Posibles problemas sociales en su zona, por ejemplo una revolución en Ucrania.
  • Posibles problemas meteorológicos en su zona que le impidan conectarse a Internet.
  • Entregar el trabajo, desaparecer premeditadamente o no y por lo tanto no dar soporte posteriormente.

La conclusión más importante que pretendo hacer llegar es que no todos los clientes requieren al mismo tipo de proveedor ni el mismo tipo de servicio.

Hay soluciones que como se comenta en el artículo pueden servir perfectamente sin necesidad de un desarrollo a medida. En otros casos esto puede significar el tener que rehacer en un futuro, lo cual puede ser asumible e incluso una buena elección, o tener problemas graves en el peor momento posible, lo cual puede significar perder mucho dinero sin posibilidad de virar a tiempo.

¿Es rentable contratar a un programador? Depende de si realmente necesitas o no a un programador.

Charla sobre negocio creando servicios para Internet en The Mêlée

La comunidad de The Mêlée suele estar presente en algunas iniciativas que hacemos desde El Comité por eso me hizo mucha ilusión que me invitasen a dar una charla cuando comenté en Twitter que me apetecía visitar su hermosa ciudad, San Sebastián.

Mi charla no va a ser sobre programación, al menos no directamente, sino sobre lo que he aprendido y creo que es relevante para crear un negocio o trabajar de forma libre desarrollando software para servicios de Internet con el objetivo de conseguir independencia económica/calidad de vida.

Hasta la fecha no he impartido ninguna charla sobre negocio a pesar de que me lo han propuesto en varias ocasiones. Esta va a ser la primera en la que trate estos temas y por lo tanto mi idea es ofrecer mi punto de vista en base a mi experiencia de estos últimos seis años creando cuatro negocios,tanto de servicio como de producto, además de ayudar a crear los que defienden nuestros clientes de Simettric en su día a día.

Os dejo el enlace a la web del evento.

Foto por Hugo Mañez Tamariz

El camino correcto

Desde que tengo memoria no me han faltado ocasiones de conocer a un montón de personas que no han dudado en expresar lo equivocado que estaba al elegir un camino en lugar de otro.

Recuerdo que en mis primeras prácticas profesionales un tipo que llevaba el mantenimiento de una red de colegios en Vizcaya me aseguró que esa inquietud y pasión que mostraba se acabaría y consumiría a lo largo de los años, con la experiencia.
En trabajos posteriores, tuve compañeros que se unieron a darme esa misma opinión y a darme consejos relacionados con esa idea, por mi supuesto bien.
Si que es verdad que mi pasión y forma de ver las cosas cambiaron, pero agotarse, ni remotamente.

Cuando empecé con los negocios, la cantidad de personas con las que me he encontrado que me han aconsejado no hacer algo o han insistido en que debería hacer las cosas de otra forma, basándose mayormente en consejos o en las enseñanzas de libros de moda, se han multiplicado. Muy pocas han considerado relevante saber algo sobre mí, sobre mi historia, a un nivel más profundo de lo que comento en mi Twitter (de forma personal) o aparece en mi linkedin o en este blog.

No creo que la crítica sea mala, ni mucho menos, tampoco creo que sea malo dar tu opinión. Creo que sí lo es el considerar que sabes al 100% lo que otra persona necesita o no para conseguir sus metas sin haberla conocido lo suficiente.

En los negocios, no me gusta dar consejos o criticar por este motivo a gente que empieza. Sí que me gusta dar mi opinión o comentar mi experiencia, sobre todo a personas que afirman tener una experiencia distinta a la mía o a personas que conozco bien a nivel cercano.

En el 2010 nadie hubiese apostado por desarrollar y defender una simple app para compartir fotos desde el móvil. En el 2012, tan sólo dos años más tarde de su lanzamiento, Instagram se vendió a Facebook por más cantidad de la que Audi compró la famosa marca de motocicletas Ducati.
Obviamente la app por si sola da igual, hay que ver la trayectoria de sus fundadores y seguramente un montón variables que no son públicas para comprender por qué ellos consiguieron eso y por qué otra persona lo tendría bastante más difícil.

Cada persona tiene su historia, unas circunstancias personales, aspiraciones, actitudes, recursos, amistades, contactos y sobre todo formas de pensar y actuar tan personales y variantes en el tiempo que ni Twitter, Facebook o un blog podrían reflejar en un porcentaje adecuado como para sacar conclusiones relevantes y mucho menos adecuadas.

Por experiencia, y también por mera estupidez, a veces se comente el error de creer saber lo que una persona o equipo pueden conseguir o no apostando por hacer las cosas de una determinada forma en lugar de otra.
Algo valioso que he aprendido es lo bueno y enriquecedor de ser cauto a la hora de asumir, la importancia de hacer cosas en lugar de creer saber hacerlas y el conocer a personas que las hagan con pasión y recursos limitados. Este tipo de cosas evita en gran medida caer en actos tan estúpidos como el de decirle a alguien aquello de que no puede conseguir hacer algo o el criticar la forma en la que lo hace, sólo porque un autor de moda lo haya escrito o no en un libro.

También veo interesante el tener criterio propio para detectar e ignorar este tipo de cosas, pero ese es ya otro tema.

Mercados de productos Open Source para desarrolladores

Ayer en Twitter se forjó un debate interesante inciado por Christian Soronellas, sobre este tema, concretamente sobre el cobrar por desarrollar productos y componentes de software para otros desarrolladores.

twit_chr

Esto me hizo recordar que, en el sitio web de Symfony en Español, Javier Eguiluz hizo una encuesta que tenía como objetivo recoger feedback para saber si la comunidad estaría interesada en desarrollar bundles (componentes de desarrollo) de pago. Estos fueron los resultados.

Otro tema interesante se lo leí a Álvaro Ortiz el otro día también en Twitter y me pareció una idea bastante chula: un servicio que pagase a los desarrolladores por solucionar issues pendientes en repositorios Open Source de github.

twit_furilo

El tweet de Álvaro se inspiró en el servicio GitTip, un crowdfounding en el que puedes pagar a desarrolladores en agradecimiento a su trabajo.

Volviendo al tema de los mercados, en algunas plataformas Open Source ya existen marketplaces que están funcionando bien, sobre todo en soluciones de eCommerce donde el valor que dan dichos componentes es muy claro ya que puede ahorrar costes y tiempos de desarrollo al desarrollador pero sobre todo al cliente final. Un ejemplo de mercado de este tipo es el Magento Connect.

En otras tecnologías emergentes, como Xamarin, podemos ver mercados de componentes que aparentemente también funciona muy bien.

Quizá uno de los principales impedimentos que tenemos en la comunidad PHP en comparación por ejemplo a la de Xamarin o quizá la de .net, es que históricamente los desarrolladores que han optado por esta tecnología no están acostumbrados a pagar por este tipo de cosas.

Sin embargo, creo que el mercado ha cambiado, o al menos está cambiando. Por dos motivos:

La expectación del cliente final ha cambiado

Los requisitos actuales para construir software web son mucho más exigentes que hace siete años.

A pesar de que cada vez hay más clientes que siguen la filosofía Lean o ya son conscientes de la importancia de desarrollar un producto mínimo viable, para ciertos servicios el optar por utilizar sistemas como Joomla o WordPress puede salir caro ya no a largo, sino a medio plazo.

Cada vez más, los servicios online requieren ser desarrollados con calidad, pero también en tiempos muy ajustados, sobre todo en mercados como el de Internet donde el time to market es importante.

Las herramientas han cambiado

Esto es una causalidad de lo anterior. Las herramientas se han adaptado a metodologías que nos permiten ser más productivos y adaptarnos a cambios drásticos del cliente.

En el mundo PHP, en menos de tres años, hemos visto aparecer no sólo frameworks como Symfony2, sino utilidades como composer que han dado un salto de calidad en nuestros hábitos de desarrollo.

Los frameworks nos están llevando a adoptar buenas prácticas de desarrollo como TTD, BDD o el uso de Inyección de dependencias. Esto nos hace posible desacoplar partes de nuestro código y poder por fin, acercarnos a una reutilización de calidad, calidad en el sentido de mantenimiento.

Teniendo en cuenta estos dos puntos, veo muy favorable, sobre todo mirando a largo plazo, el hecho de que nos planteemos de forma seria el rentabilizar esos desarrollos que podemos reutilizar en varios proyectos, ahorrando tiempo al cliente sin perder calidad.

Al igual que comentaba Javier Eguiluz en el resultado de la encuesta anteriormente citada, veo muy importante el crear un mercado de este tipo. Probablemente muchas de las cosas que echamos de menos en Symfony2 estarían resueltas y con mantenimiento gracias a dicho mercado.

Eso sí, si todos lo viésemos claro, el reto entonces sería cómo hacerlo, cómo vender esos productos.

Ahí van algunos puntos que veo que darían para un debate:

Producto y soporte

Desarrollas el producto y lo vendes. Pero es ahí cuando empieza todo, sobre todo si es basado en tecnología open source. No voy a decir que el código no vale nada, porque probablemente me mataríais, pero sinceramente creo que lo más valioso es estar detrás dando soporte y updates al producto.

El soporte es lo más caro del desarrollo de un producto y sin soporte, la experiencia es mala y tu producto es percibido como humo.

Hay muchos ejemplos de cómo enfocar esto, aunque como siempre, creo que sería posible darle una vuelta de tuerca al asunto.

Precio y forma de cobro

Teniendo en cuenta lo anterior, es clave poner un precio acorde a lo que vas a ofrecer. Es muy posible que si te equivocas en el precio, cuanto más vendas, más dinero pierdas.

El precio no se puede decidir en una mañana echando un café, es uno de los puntos más difíciles a la hora de crear un producto.

En un mercado de este tipo podríamos llegar a pensar que la guerra de precios es inevitable, pero al ser desarrolladores, sabemos diferenciar de forma muy directa qué producto tiene mejor calidad o soporte, que al final son los baremos más adecuados para medir si un precio es adecuado o no.

Distribución y licencia

Si hablamos de productos Open Source orientados al desarrollador y de que los updates son una parte muy importante, no sería descabellado el pensar que lo natural sería dar acceso al repositorio a nuestros clientes de pago.

Si esto nos parece exagerado o nos da pánico, gracias a composer podemos crearnos nuestro propio repositorio de paquetes privado para composer con la utilidad Satis.

Por último, podríamos optar por la manera tradicional de descarga vía zip y que nuestros clientes gestionen las actualizaciones de forma manual.

En el tema de las licencias tengo muchísimas dudas, incluso después de haberme leído unas tres veces este genial libro sobre el tema. Es un punto importante que nos sirve para proteger el producto de una forma más efectiva que cosas como la encriptación de código, que yo personalmente rechazo completamente.

En resumen, creo que crear mercados de este tipo son muy importantes para desarrolladores de PHP, tanto de Symfony como de otros frameworks y daría para un debate muy interesante e incluso para un evento en el que contar experiencias reales vividas al vender productos de este tipo.

Sobre la normativa de uso de cookies en sitios web

A raíz de la aparición de artículos de abogados haciendo referencia a las primeras sanciones por el uso “incorrecto de cookies”, concretamente este, he decidido publicar por aquí mi opinión sobre el tema.

Contexto

Hace relativamente poco tiempo, se aprobó una reforma por la cual se obligaba a los sitios web que instalasen cookies a notificar al usuario y pedir confirmación de que el mismo deseaba instalarlas en su navegador antes de que el sitio web lo hiciese.

La AEPD publicó una guía para explicar en detalle cómo y por qué se debe avisar al usuario de que el sitio web almacena información en su navegador.

Problema

Podemos decir que todos los sitios y aplicaciones web en Internet a los cuales se accede desde un navegador necesitan usar cookies. Hay excepciones, pero no pertenecen a lo que podemos calificar como sitio web o aplicación web normal.

Algunas cookies permiten que el usuario pueda iniciar sesión, otras recordarle aunque cierre el navegador para que no tenga que volver a indicar su usuario y contraseña, otras ayudan a mejorar la usabilidad y posicionamiento de la página, otras ayudan a mejorar la precisión a la hora de mostrar anuncios al usuario y otras tienen fines que podemos calificar de menos éticos.

Hasta ahora, el uso de las cookies se especificaba en los términos y condiciones del sitio web pero tras la reforma ya esto deja de ser suficiente y tendremos que avisar al usuario de que vamos a instalar cookies — antes de hacerlo — que hacen funcionar cosas tan normales como Google Analytics, videos de Youtube o el ya típico login  de Facebook.

El problema reside en que un aviso similar al que se pide puede echar atrás a una persona que no está entrenada o no entienda muy bien “los riesgos” que conlleva dejar al sitio web instalar las cookies.

Estamos viendo noticias de cómo Gobiernos espían a sus usuarios, cómo redes sociales hacen data mining con los datos de sus usuarios para venderlos a marcas o agencias de marketing, cómo se dan casos de estafa en sitios web y, aunque estas cosas tengan poco o nada que ver con el tema que estamos tratando, los usuarios ya tienen una desconfianza adquirida por ese contexto.

Esa desconfianza también es adquirida gracias a sitios web que permiten ver contenido online como series o películas, en las que al usuario se le bombardea con decenas de avisos en los que debe “aceptar o cancelar” y, dependiendo si se equivoca o no, puede acabar en un anuncio de contenido bien distinto a lo que buscaba.

Personalmente creo que el contexto no es favorable para añadir avisos o notificaciones que alerten al usuario de que vamos a hacer algo que llevamos haciendo desde que existe Internet y no tiene por qué suponer un riesgo a esa persona o su navegador.

Por otro lado, el rechazar el uso de cookies puede generar una mala experiencia de usuario que perjudique directamente al negocio y ventas.

Ni decir tiene que si un sitio instala cookies para mostrar publicidad al usuario y es su modelo de negocio principal, el que el usuario rechace las mismas puede suponer un problema muy serio para dicha empresa.

Una solución mejor

Aunque creo que es labor del usuario conocer de otra forma que existe un contrato con ese servicio y que en ese contrato se especifique cómo gestionar las cookies referentes a ese sitio web, pienso que una solución mejor sería que fuesen los navegadores los que se encargasen de la tarea de avisar al usuario por defecto, sin tener que configurar nada en los mismos.

De esta forma los usuarios aprenderían a reconocer y diferenciar este tipo de avisos, de otros como banners o advertencias que aparezcan en el propio sitio web.

Actualmente recae en el sitio web el poner la advertencia, y eso puede influir a que cada uno use un diseño y textos distintos, en idiomas distintos. Algo que algunos sitios web podrían usar en contra del usuario, mostrando avisos similares para confundirle y terminar llevándole a una página publicitaria o algo más ofensivo.

Desarrollar un servicio VS vender un servicio

Una de las cosas más interesantes de ofrecer servicio de desarrollo a clientes es lo que puedes aprender de perfiles no relacionados con la tecnología. Muchas veces descubres puntos de vista que te muestran realidades que van en contra de lo que has asumido o que no has visto por estar demasiado centrado en aspectos de desarrollo o ejecución.

Hace cinco años se dieron las condiciones para que los desarrolladores de aplicaciones web se pudiesen lanzar a crear servicios SaaS como la solución perfecta a la problemática de escalar sus negocios.

Desarrollar un producto y mantenerlo a cambio de pequeñas suscripciones suena como la salvación y camino a seguir, en lugar de tener que empezar de cero cada vez intentando ser cada año más competitivos en precio y tiempo, sobre todo ante clientes que no tienen ninguna experiencia en el sector y desconocen el coste de estos recursos a la hora de desarrollar proyectos de este tipo.

Durante estos cinco años hemos visto aparecer todo tipo de soluciones de este software como servicio, la mayoría muy factibles de desarrollar por un equipo de pocos desarrolladores con experiencia. Sin embargo, a pesar de esa aparente facilidad de ejecución, unas triunfan y otras se quedan en el camino, lo cual nos hace pensar con razón de que las cosas no pueden ser tan fáciles y que nos falta información.

A nada que nos adentramos en el apasionante mundo de los emprendedores tecnológicos, podemos encontrar historias de personas que salen de la nada y en menos de un año se vuelven millonarios y que gente muy simpática acude a ellos para inyectarles millones de dólares en sus negocios, casi suplicándoles que los acepten.

La realidad es fácil de comprobar cuando realmente decides ejecutar un proyecto en Internet que quiere ser rentable. En mi experiencia algunas cosas que he aprendido en los primeros años son las siguientes:

  1. Afortunadamente las cosas no son tan fáciles en general. Siempre hay variables que hay que resolver que van apareciendo segun te vas enfrentando al mercado real.
  2. Los desarrolladores que salen de la nada y reciben inversiones, ni salen de la nada, ni obviamente huelen ese dinero. La mayoría incluso se ven obligados a esclavizarse por un proyecto que nunca será lo que ellos pensaron al principio.
  3. En España, las subvenciones sólo las reciben personas bien situadas o que se dedican casi profesionalmente/socialmente a conseguirlas o que invierten dinero en conseguirlas.
  4. Puedes desarrollar un servicio, pero debe haber un negocio detrás.
  5. Hay servicios y empresas que no son conocidos por revistas o círculos de emprendedores que funcionan muy bien, venden y tienen mucha experiencia en el mercado.

El punto 4 es algo en lo que veo fallar frecuentemente, y no sólo es un fallo habitual en programadores.

En parte este punto es el que hace que asumamos cosas erróneas o nos pongamos una venda en los ojos, a menudo culpando al mercado, el momento o la crisis convirtiéndolos en motivos de nuestros fracasos.

Algunas cosas que suelo ver en perfiles de todo tipos, programadores o no, son las siguientes.

Esperar a tener el producto terminado para venderlo.

Tengo una mala noticia por si te ha chocado esta frase, el producto nunca se termina. Un síntoma de que no vas a se capaz vender el producto es si no eres capaz de venderlo sin tenerlo acabado.

Los desarrolladores cuando desarrollamos un servicio tendemos a enfocarnos en el desarrollo, esto es lo normal si nuestro rol es el desarrollo, pero si nuestro rol también es el de venta, hay que vender desde el día cero y tener un enfoque adecuado.

Vender es lo más importante y es la opción más inmediata para recibir feedback válido. El feedback de usuarios gratuitos o a los que no les supone un coste tu servicio no es tan preciso. Si tu producto no interesa, lo vas a ver de inmediato cuando intentes convencer a alguien de que invierta su dinero en él.

La sensación de vender humo es algo que los desarrolladores detestamos, pero es necesario dejarla atrás. Si eres desarrollador y estás fabricando el producto, no estás vendiendo humo, estás vendiendo el producto que estás desarrollando, punto.

De mis clientes y de la experiencia de los servicios en los que he participado, esta es una de las ideas que más me ha costado aprender y más valor creo que me ha aportado para tener un punto de vista adecuado.

El servicio o producto no se vende por sí solo.

Comprar y dominio, apuntar el DNS a tu servidor, lanzar un par de frases en Twitter o Facebook al día y esperar a que entren clientes, ¿fácil verdad? Demasiado para ser cierto.

El problema se complica si el producto encima no está terminado aún.

Hay que añadir algo más a los esfuerzos de venta, ¿el qué? tú debes saberlo y debes saberlo ya, esta es la parte complicada de hacer que un negocio funcione, bienvenido a la realidad.

Saber vender es lo que hace que unos caigan y otros funcionen, “cómo hacerlo bien” es la asignatura que estamos aprendiendo en el día a día todos y cada uno de los que nos dedicamos en serio a esto.

No todo es el software.

Pensar en servicios que sean complementarios a tu software no está de más en un sector en el que como ya he dicho, todos tenemos el mismo problema que tú: un software que vender.

Quizá una posible vía es explotar servicios que complementen a tu servicio principal. Puede que le reste escalabilidad dependiendo del tipo de servicio, pero de nada te sirve un modelo escalable que tiene cero clientes.

No todo es suscripción.

Ojalá lo fuese, pero en algunos servicios no hay valor suficiente para que tus usuarios acepten este tipo de modelo.

Y no se trata de precio, sino de percepción de pagar por algo que no se usa. En algunos casos se puede encontrar un modelo que suponga los mismos ingresos con los mismos usuarios, sin necesidad de suscripción.

Comunicación.

La comunicación no es actualizar Twitter o Facebook, ni poner un logotipo en un evento. Hoy en día eso ya no vale, la comunicación requiere identidad, la identidad requiere personalidad y la personalidad requiere pasión.

Y la pasión no entiende de medios, sino de sentidos.

Aprender a expresar en palabras que abran los sentidos de tus clientes es el reto. Es mi lucha personal, un reto al que me enfrento cada día y por el cual intento aprender con envidia sana de aquellos que logran transmitir con su voz algo que se compra de forma natural. Es algo casi poético y una cualidad que admiro en las personas.

Si no comunicas no existes. En algunos momentos o por tipo de servicios no existir está bien, en serio, pero cuando hay que vender un producto a consumidor final, es importante comunicar para que se vea que estás vivo y en proceso de mejora continua.

La tecnología.

En el 2008 la gente “normal” empezó a comprar móviles en los que se instalaban aplicaciones, sin tener conocimientos de programación ni dedicarse a este sector. No conocen las tecnologías detrás de iOS o Android, ni les interesa saberlo, simplemente pagan y usan el producto.

Programar tu producto en Python y decir que “Python es sexy” no va a hacer que vendas más. La gente que trabaja en WhatsApp a veces publica benchmarks sobre el rendimiento de su backend en erlang, pero eso no les ayuda a vender más, lo han hecho gracias a otras cosas que hemos visto este año, una lección que todo desarrollador debe aprender.

Las tonterías se acaban cuando la gente tiene que pagar dinero por lo que haces.

Como conclusión, sin el desarrollo los servicios no existen, sin ventas los negocios tampoco.