Una reflexión personal sobre el leak de Ashley Madison

Desde hace unos días venimos leyendo decenas de artículos sobre el leak (filtración) de Ashley Madison, uno de los hackeos que van a pasar a la historia de Internet por la “delicadeza” de la temática del servicio.

Dicho servicio online y aplicación, al igual que otras alternativas dentro del sector contactos, es especializado en facilitar principalmente la búsqueda de personas para tener una relación adúltera.

Oficialmente tanto el ataque y posterior filtración tuvieron como objetivo el demostrar que este portal estafaba a sus usuarios cobrándoles una cuota por borrar sus perfiles y datos asociados, algo que nunca llegaban hacer tras dicho pago.

Los responsables del portal han visto cómo esto salía a relucir junto a otras malas prácticas éticas, como “fabricar” miles de usuarios femeninos falsos por ejemplo, y también malas prácticas técnicas a nivel de programación del propio software o la seguridad en general del sitio web, haciendo que finalmente el Director Ejecutivo haya anunciado su dimisión.

Pero al margen de los perjuicios que tendrá que asumir y enfrentar la empresa, los más perjudicados bajo mi punto de vista serán sin duda sus propios usuarios. Han sido expuestos públicamente a las miradas de un postureo ético sin precedentes en nuestra historia y algunos de ellos han sido puestos incluso en situaciones de peligro de muerte.

“Que se jodan por adúlteros”. En el caso de este servicio parece que “el pecado” o el “acto perverso” ha obtenido una especie de Karma. No puedo describir con palabras lo deleznable y corto de miras que me parece juzgar a una persona que no conoces de plantearse engañar o tener sexo con otra persona.

Pensaba que en nuestra sociedad y sobre todo en personas que nos dedicamos a trabajar con información, datos y creamos productos de software de naturaleza social, deberíamos tener una mentalidad abierta y valorar la libertad sexual de cada persona, al margen de lo socialmente “aceptable”. Puede que no compartamos ciertas cosas y eso me parece normal además de lo natural, pero es muy diferente no compartir una idea o acto a juzgarlo como si estuviésemos por encima de nuestros deseos más primarios y tuviésemos el poder de establecer lo que nos define como una buena persona o una persona despreciable.

Se ha podido leer como a los usuarios también se les ha tachado de insensatos o incluso “torpes” al registrarse en el servicio, como si los correos electrónicos que dichos “jueces” envían y reciben desde las cuentas de las empresas en las que trabajan o han fundado no fueran completamente accesibles por una persona o equipo con privilegios de administrador.

Los desarrolladores, arquitectos de software y profesionales de producto ya tenemos presente la importancia de la privacidad e intimidad cuando diseñamos cómo debe ser una aplicación o un servicio en Internet basado en software, a pesar de esto personalmente a mí me ha impactado ver las consecuencias y juicios sociales que ha originado este leak.

Jamás se nos pasaría por la cabeza espero, justificar a un cirujano que se niegue a operar a alguien porque haya engañado a su pareja o tenga una sexualidad concreta, pero en algo como esto me ha preocupado mucho cómo se trivializa el derecho a la intimidad de una persona, se juzga sin conocer nada acerca de la misma y se asume como karma el acto de compartir nombres, apellidos, email y ubicación exponiéndola incluso en situaciones de peligro de muerte.

Y realmente no es necesario que el producto, aplicación o servicio online tenga un fin sentimental o relacionado con conocer a personas. Al diseñar servicios como planificadores de vuelos o de viajes, una persona que utilice tu servicio puede quedar expuesta si se comparte “un plan” que forma parte de su privacidad y que no ha compartido o con su pareja, familiares, amigos o gobierno. Y dicho plan también se puede asociar con algún evento con temáticas de género, religión o motivos políticos que tenga lugar en una zona o fecha concretos.

Realmente determinadas decisiones de producto pueden influir no sólo en la vida de una persona negativamente, sino que ciertas exposiciones que en nuestro contexto social pueden simplemente no ser aceptadas, en otros contextos pueden significar la persecución y muerte de dichas personas que han confiado en los productos y servicios que les ofrecemos.

Más allá de las leyes que debemos cumplir, es importante aprender de lo que está pasando con este leak para tener una perspectiva más amplia y real de las consecuencias que ya conocemos al hacer servicios que permitan compartir información de nuestros clientes y usuarios.

Algunas cosas que he aprendido con la experiencia

  • Puedes morir en cualquier momento.
  • “Hacer más” no es hacer más cosas en menos tiempo, es hacer menos pero lo que hagas esté completo y aporte valor.
  • El silencio bien usado, es una herramienta muy potente. Lo mismo que las palabras.
  • No existe “la oportunidad de tu vida”, a lo largo de tu vida tienes varias oportunidades a las que puedes optar dependiendo de lo que te muevas, tu actitud, tus recursos y tu perspectiva.
  • El tiempo es más caro que el dinero. El tiempo con tus amigos o gente que te importa, y a la cual le importas, no tiene precio.
  • Con dinero se compra tiempo. Con tiempo, actitud, experiencia y conocimientos se puede generar mucho dinero.
  • Aunque tu causa sea buena y moral, no tiene que dejar de ser menos buena y moral si generas dinero con ella.
  • La libertad y la soledad deben ir acompañados de disciplina, al menos la mínima disciplina para no abandonarse.
  • Si estás cómodo en la soledad, es importante forzarte a relacionarte con otra gente para que esa comodidad no se te vaya de las manos.
  • A veces es mejor no cumplir un objetivo, que cumplirlo a medias y acomodarse con lo conseguido. Dedicar tiempo a pensar si merece la pena o necesitas un cambio, es de los tipos de inversión más importante que puedes hacer en tu vida.
  • En los negocios llevarse las cosas al terreno personal es falta de experiencia. Tomarse un negocio como algo personal o que se convierta en “tu vida”, es falta de experiencia y de perspectiva.
  • Fuera del sector tecnológico y en España, puede dar peor imagen presentarse como un emprendedor o CEO que tener una cuenta de correo electrónico en hotmail.
  • Si en un negocio o proyecto tienes socios, ese proyecto no es tuyo, es de todos. Pero todos no deben tomar la decisión final en todo.
  • Ser un líder no puede forzarse.
  • Si lees en un medio de comunicación que hay una oportunidad en un sitio o en un sector, ya es tarde.
  • No tienes por qué montar negocios o trabajar para otro, las cosas surgen de forma natural. En la vida hay más colores que el blanco y el negro, debes aprender a distinguirlos todos por ti mismo y hacer lo que te aporte o necesites en cada momento.
  • Perder a una persona de las que tienes en tu vida por un negocio, es algo muy lamentable.
  • La mayoría de los problemas no son más que una tarea más que debes atender y resolver lo antes posible.
  • Tu físico importa y es prioritario cuidarlo por ti. Para atraer o seducir otras cualidades como la seguridad y actitud son más relevantes, aunque también depende mucho de lo que quieras y de con quién lo quieras.
  • “Quien anda mucho y lee mucho, ve mucho y sabe mucho” Don Quijote de la Mancha.
  • El orgullo es una espada de doble filo. Sin orgullo no se llega a nada, pero como decía Fernando Fernán Gómez en “El Abuelo“, el orgullo sin controlar es una mierda.
  • Antes de concluir que una persona o idea es estúpida, escucha o piénsalo dos veces antes.
  • Eres un ser humano y puedes ser más que competente en varios campos totalmente distintos. Si tienes hambre de conocimiento y dedicas tiempo, puedes alcanzar buen nivel en casi cualquier campo con cuatro años de experiencia real y aprendizaje. Y tener experiencia en unos campos aporta perspectiva a otros distintos.
  • A programar se aprende programando proyectos reales.
  • Dependiendo de lo que hagamos como persona y nuestras experiencias, podemos ser varias personas distintas en distintos momentos de nuestra vida.
  • Es mejor hacer que decir lo que vas a hacer. Aunque a veces la ilusión te impide contenerte.
  • Ser humano conlleva ser imperfecto. Y en general, aprender a apreciar lo imperfecto y aprovechar al máximo lo que puede aportar, te hace conseguir más con menos recursos.
  • Ser humano, tener inteligencia y hacer cosas conlleva cometer errores.
  • El conocimiento y las experiencias son más importante que las cosas. Pero darse un capricho o premiarse de vez en cuando alimenta la ilusión y la ilusión, es clave.
  • La religión es algo personal de cada uno, imponer tu vista sobre otro es una falta de respeto, un ataque brutal a su libertad de elegir y sentir.
  • Cambiar de opinión no es haber mentido, a menudo es reconocer tu error.
  • Sobre el sexo: no es aceptable ni justo para otros ser mediocre, conformista o egoista en el sexo. Tener mentalidad cerrada con respecto al sexo te limita a la hora de entender y aprender de las personas. El sexo no se pide.
  • Pareja se es, no se tiene.
  • No conoces a una persona por lo que escribe o dice, la conoces por situaciones que vives con ella. Compartir un café vale más que cuatro años de following en Twitter.
  • Nunca vas a hacer todo tú solo. No aceptar o pedir ayuda es falta de experiencia.
  • Tu hogar no tiene por qué estar en un sólo sitio.
  • Escribir bien es básico. Leer bien también.

 

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.

Lo que vi en el Build 2015 y el nuevo Microsoft

Hace casi un mes estuve en San Francisco y gracias a Microsoft, acudí a su evento más importante para desarrolladores, el Build.

11193070_503361936494064_1696561452_n

Lo primero que me impactó de este evento antes de ir es que costando la entrada 2000$ se agotasen el mismo día. Más de 5000 desarrolladores de nivel internacional acudieron al evento. Siendo español y organizador de eventos técnicos, esto me llama poderosamente la atención ya que en España hay poca costumbre de asumir inversiones de mucha más baja cuantía independientemente de la calidad del evento al que queramos acudir.

Lo segundo que me impactó fue Microsoft. Bueno realmente no Microsoft, sino la comunidad y todo el cambio que se está dando en torno a sus productos y que dista muchísimo con lo que conocí cuando trabajaba administrando sistemas basados en Windows Server y Exchange 2003, antes de dedicarme al mundo de producto y desarrollo de soluciones de software con tecnologías open source.

Os voy a contar un resumen de lo que vi allí esos días y algunas reflexiones personales desde mi punto de vista.

El día antes de comenzar el evento, tras acreditarnos, acudimos a una fiesta privada organizada por la gente de Xamarin y allí nos encontramos a gente muy crack del desarrollo mobile como Josue Yeray. En la fiesta había un catering de calidad, barra libre y una concentración de talento increíble.

Para el que no lo sepa, Xamarin es una solución para desarrollar de forma nativa (realmente nativa) aplicaciones para Android, iOS, Mac, Windows Phone, Windows y wearables que usen estas tecnologías. Es un proyecto que tiene detrás a la gente del proyecto open source Mono y al creador de Gnome, Miguel de Icaza.

Para desarrollar en Xamarin, debes tener conocimientos de Android e iOS así como de C#, lenguaje de programación estándar de Microsoft.

No sorprende entonces que en un evento de Xamarin no encuentres sólo a gente pro-Microsoft, sino también a desarrolladores de nivel internacional enfocados en Android e iOS.

Al día siguiente acudimos al evento a primera hora para asistir a la primera keynote del evento.

Lo primero que me sorprendió y que fue recurrente en la segunda keynote que tuvo lugar al día siguiente, fue la presentación de aplicaciones profesionales como StaffPad para componer música. Esta aplicación fue creada por el músico David William Hearn, quien escribió una pieza en directo durante la keynote.

Más tarde, la gente de Docker comentó su visión y estrategia de integración con el servicio de cloud Azure y se hizo una demo con Visual Studio y un plugin de docker para gestionar contenedores Linux desde el IDE.

La impresión 3D también tuvo su hueco. Para presentar nuevas tecnologías en Web, crearon una plataforma y caso de éxito ficticio llamado Fabrikam. Me sorprendió cómo tenían desarrollador a nivel de web responsive todos los flujos de diseño de las piezas en 3D y su posterior pedido a través de la web, con la gestión de negocio. Esta demo seguramente se vea en más presentaciones de Microsoft y la verdad si estás en el mundo de impresión 3D, deberías echar un ojo.

Algo que era sutil pero no dejaba de sorprender es que los ponentes hacían todas las demos de la keynote en teléfonos Android e iPhone junto a tablets iPad, no sólo con dispositivos con Windows Phone o Windows.

Pero la sorpresa de verdad fue sin duda cuando se presentó Visual Studio Code. Un editor de código que Microsoft publicó ese mismo día para desarrollar bajo Linux, Mac y Windows.

Posteriormente acudí a una charla donde se presentaron features avanzadas de este editor, especialmente relacionadas con el trabajo con c#, asp.net y javascript. En este último se han volcado en dar muy buen soporte en general.

Es un editor que da lo que puede dar Atom de Github, pero se ha añadido buen soporte de intellisense y debug, sobre todo ahora mismo para Javascript y C#. Se rumorea que podría acabar siendo OpenSource, pero no está confirmado aún.

Yo he sustituido Brackets para editar archivos simples de php. Aunque se me queda corto para programar aplicaciones php y no me sustituye a phpStorm, para desarrolladores Javascript o Asp.net bajo entornos linux o mac creo que puede ser una opción más que interesante.

También fue increíble cuando se anunció que Objective C se incluía dentro del catalogo de lenguajes .net. Se mostraron juegos de iOS programados en este lenguaje, corriendo nativamente en Windows10 e integrados con XBox.

Estos dos anuncios ya dejaron ver que Microsoft estaba apostando por un cambio de visión en la que en lugar de cerrarse, parecía que se abría a otras plataformas.

Otro anuncio ya esperado fue el de Microsoft Edge, que sustituirá a Internet Explorer como navegador.

La keynote se cerró con la presentación de las gafas de visión holográfica HoloLens, lo más alucinante y esperado del evento. Hubo desarrolladores que fueron al evento sólo por este anuncio.

 

Las aplicaciones y objetos holográficos de ese mundo de realidad aumentada se programan como si fuesen juegos pero se puede intuir que las aplicaciones para el mundo de los negocios, I+D, ingeniería y medicina no tienen prácticamente límites.

Algunos afortunados tuvieron la oportunidad de probarlas y recibir formación para desarrollar software para ellas, uno de ellos fue Josue Yeray y escribió un resumen sobre las mismas en su blog.

El resto del evento estuvo cargado de charlas sobre productos más en detalle.

El segundo día empezó con la segunda keynote del evento. Antes de empezar, un Deejay amenizó el ambiente con un set en directo haciendo uso de software bajo Windows10. De hecho la keynote empezó también con las experiencias de Muzik y Propellerhead.

Yo soy muy fan de Propellerhead, a finales de los 90 me flipaba componer con su Rebirth338 y no me esperaba verles presentar en ese evento.

Para mí fue una sorpresa la importancia que Microsoft le está dando a la producción musical.

Otra cosa que me llamó la atención fue el trabajo que están haciendo para emular la escritura con tinta en pantallas táctiles. Esto puede dar mucho juego para software relacionado con diseño o dibujo.

Otra noticia que dejó en silencio a toda la sala fue el proyecto Astoria. Lo que promete este proyecto es la posibilidad de ejecutar aplicaciones en Windows escritas en código Android nativo.

Este anuncio ha provocado polémica y también escepticismo en la comunidad .net de desarrollo Mobile, pero sin duda alguna es otra señal de que Microsoft ha cambiado totalmente su estrategia y forma de ver las cosas.

Hubo más cosas interesantes como el SDK para Microsoft Band (es una pena que este producto no haya llegado a España) y las posibilidades de extensión de Office e integraciones del mismo con Android/iOS.

Además de Cortana, el “siri” de Microsoft, se habló del proyecto Continuum para Windows10. Básicamente han logrado que los dispositivos Windows Phone se integren totalmente con Windows10 de tal forma que las aplicaciones con las que trabajas en el móvil, al conectar el terminal al pc, puedas seguir utilizándolas con los recursos y pantalla del equipo de escritorio. Esto sin interrumpir la experiencia de uso.

En la keynote también se mostró una demo de una aplicación web que se convirtió sin querer en trending topic y que calculaba la edad de una persona en base a su foto de avatar. La demo se usó para mostrar las APIs de análisis y monitorización disponibles en servicios Azure.

Esta última keynote finalizó con la temática Big Data y su aplicación en el mundo de la salud.

Durante el resto del evento acudí a charlas sobre novedades en ASP.net, servicios de búsqueda de Azure (que están basados en Elastic Search) y una charla de negocio sobre Office 365 Online.

El día final no hubo keynote pero sí charlas tecnológicas muy interesantes, en especial la de Azure Media Services, en la que Ming Feiy dio un repaso sobre todas las nuevas características y opciones para gestionar el reto de servir vídeo desde servicios cloud.

Conclusiones

Microsoft no está cambiando, ha cambiado ya y dicho cambio es tan real como evidente.

Mis opciones tecnológicas principales actualmente son Symfony2 para desarrollar aplicaciones web bajo linux y Xamarin para desarrollar aplicaciones nativas en iOS/Android. Por ello, mi interés principal de acudir al evento era el descubrir opciones tanto tecnológicas como de negocio, para desarrollar proyectos open source y servicios de Internet con herramientas Microsoft como c# y Azure que no me atasen a nada.

Me volví del evento con ganas de investigar las opciones que vi en allí y es algo que ya he empezado a hacer y muy en serio.

Por un lado hay herramientas muy maduras a nivel de desarrollo que es interesante tenerlas disponibles ahora de forma abierta bajo entornos linux. Por otro, hay APIs y herramientas cloud de Azure que pueden ahorrar mucho dinero e incluso hacer viables proyectos que antes requerirían una inversión de desarrollo e infraestructura importante.

Poco a poco, Microsoft se está abriendo y facilitando la vida a los desarrolladores para integrarse con otras plataformas como Android y Apple. Algo impensable hace unos años de Microsoft y algo impensable actualmente de empresas como Apple.

Me queda agradecer a la gente de Microsoft que me acompañó en el evento, Jose y Alex. También fue un placer conocer a Pablo Iglesias y Jorge del Casar.

 

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.

Desarrollo de aplicaciones móviles multiplataforma

Con este artículo pretendo recoger mi punto de vista, resumiendo lo que he comentado en mis charlas sobre estas temáticas y también las conclusiones tras invertir casi dos años en investigar sobre cómo afrontar este tipo de desarrollos y proyectos.

Desde hace ya unos años, cuando desarrollamos proyectos web de gran envergadura como plataformas SaaS (software como servicio), marketplaces, redes sociales o portales de otro tipo, debemos tener en cuenta la experiencia del usuario que accede a estos servicios web desde el móvil.

Desde el punto de vista del cliente, las preocupaciones u objetivos que más destacan en su feedback suelen ser estos tres:

  • El servicio debe ser accesible desde el móvil
  • Nuestro servicio debe poder ser consumido desde un canal móvil
  • Nuestro servicio debe tener una buena experiencia desde el móvil

Hasta ahora, los desarrolladores web contábamos con la ventaja de poder desarrollar nuestra plataforma y mantenerla de forma centralizada en nuestros servidores, preocupándonos únicamente en la parte frontal de los detalles o soportes de diferentes navegadores.

Habíamos huido del trabajo que suponía el mantener y dar soporte a instalaciones de nuestro software en distintos entornos o sistemas operativos que controlaba el cliente. Esta sensación que creíamos olvidada, ha retornado con la revolución de las aplicaciones móviles que suponen una oportunidad para los negocios que construimos: la oportunidad de estar en el bolsillo del cliente vaya donde vaya.

Los usuarios pueden acceder a nuestro servicio mientras van en el metro o consumen los últimos minutos del día antes de dormir.

Sin embargo, aprovechar esta oportunidad, aumenta el coste del desarrollo y de su posterior mantenimiento ya que supone desarrollar una aplicación para cada uno de los sistemas implantados en los teléfonos disponibles, teniendo en cuenta versiones del sistema y la experiencia de uso.

Por lo tanto, un desarrollador web o un equipo de desarrollo web tiene que tener en cuenta:

Las cosas que no son programación

Aunque un desarrollador delegue la parte de definición del producto o el diseño de la interfaz, es imperativo ser consciente de que una aplicación móvil se utiliza de forma distinta a un sitio web y la arquitectura de información junto a la navegación deben cumplir las expectativas de un usuario.

La idea es que no se trata de que nuestra aplicación se “parezca” a una aplicación móvil sino de que lo sea y se comporte como tal.

Al margen del diseño, importan cosas como la estrategia de notificaciones, la cantidad de información a mostrar o pedir, el comportamiento táctil, las reducción de features a ofrecer en comparación a la plataforma web y sobre todo, las integraciones con el dispositivo móvil y las implicaciones del hacerlo (consumo de batería, tipo de conexiones a hardware externo etc.)

Lo que sí es programación

Y en lo referente a la programación, aquí debemos tomar decisiones importantes:

  • Si nuestra aplicación debe instalarse en el dispositivo o no
  • Si nuestra aplicación debe ser nativa o no
  • En el caso de que optemos por desarrollar en nativo, si utilizamos una solución multiplataforma o no
  • Si requerimos un acceso web
  • Si en la parte web de nuestro servicio tiene sentido ejecutar una aproximación responsive Mobile First o por el contrario ser Tablet First y crear una webapp

Voy a dar mi opinión sobre estos puntos comentando algunas de las herramientas que he probado empezando por el último punto.

Responsive sigue sin ser opcional pero el ‘mobile first’ es muy del 2011

A menos que tu servicio sea extremadamente simple, atacar una estrategia teniendo en cuenta la adaptación del diseño en la resolución móvil bajo mi punto de vista puede aportar mayor coste de desarrollo, diseño y mantenimiento sin llegar a cumplir las expectativas del usuario.

Hay excepciones, como los sitios web de contenido que no vayan a crecer en otros aspectos de negocio. Sin embargo, en una plataforma en la que tenemos mucha problemática de interacción, intentar llegar a la vista móvil a base de adaptar el diseño puede conllevar:

  • Aumentar el peso de la página. Normalmente la técnica principal a la hora de hacer responsive es ocultar o mostrar elementos del HTML en base a la resolución de la pantalla, por lo que si nuestra plataforma crece también crecerá la cantidad de código a servir que tiene implicaciones como el tiempo de carga del sitio web.
  • Aumentar la complejidad en el front. Si para evitar aumentar el peso, decidimos aplicar o crear soluciones de carga bajo demanda, estaremos aumentando la complejidad del código en el frontal que realmente no está aportando valor de negocio y encarece el mantenimiento.
  • Mezclar problemáticas de experiencia de usuario. En ambos casos, estamos mezclando dos experiencias de uso totalmente distintas e intentando resolverlas prácticamente con calzador en el peor de los casos o intentando “parecer una aplicación móvil” en el mejor de ellos.

En mi opinión, si la plataforma es grande y planea crecer en requisitos de interfaz ya no es opcional el crear un acceso móvil separado con su propia experiencia de usuario.

Crear una webapp mobile

Como he comentado anteriormente, cuando atacamos el problema de desarrollar una aplicación móvil, aunque sea basada en web, tenemos que aprender a enfocar el diseño del servicio de una forma totalmente distinta a como lo platearíamos para una solución web en otras resoluciones y sobre todo, si estamos hablando de pantallas no táctiles.

En algunos servicios como Facebook, Badoo o Soundcloud tenemos buenos ejemplos de webapps.

IMG_0645Aunque el desarrollo sea web, no nos libramos de comprender cómo funciona cada plataforma, qué tipo de menús e interacciones el usuario espera encontrar y qué herramientas tiene el navegador para dotar a nuestra aplicación web de navegador de un comportamiento nativo.

Por ejemplo en iOS podemos hacer uso de los Smart Banners, las Safari notifications que permite enviar notificaciones al móvil aunque no este el navegador abierto o mejorar el rendimiento del scroll con un sencillo hack de CSS.

Para afrontar este tipo de desarrollos podemos optar por utilizar algún framework que nos facilite la tarea que ya implementan algunas de estos hacks a nivel de CSS.

Existen buenas opciones, algunas incluso adaptan el diseño dependiendo de la plataforma con la cual se acceda. Entre las más utilizadas están ionic, onsen uichocolat chip ui, ratchet y app.js.

Personalmente echo en falta una opción que no implemente javascript y sea una solución potente a nivel de css y html compatible con navegadores que no tengan que ser los más modernos.

Crear una aplicación instalable híbrida

Si queremos instalar nuestra aplicación en el dispositivo móvil la opción más socorrida por desarrolladores con experiencia web es la utilizar tecnologías como Phonegap/Cordova.

Básicamente estas aplicaciones se desarrollan de forma similar a una aplicación web móvil de navegador pero teniendo acceso a recursos del sistema como los sensores, cámara y almacenamiento.

Aunque parece la solución perfecta ya que el desarrollador puede aprovechar su experiencia en desarrollo web para ser productivo y crear aplicaciones con muy poca curva de aprendizaje inicial, disponemos de limitaciones con respecto a las aplicaciones nativas.

Al ser desarrolladas en HTML/CSS/Javascript es menos costoso también lograr implementar diseños con cierta complejidad o incluso imposibles de realizar en una aplicación nativa.

Simplificando mucho, una aplicación híbrida no es más una web en HTML y programación en javascript que funciona dentro de un navegador que el usuario no ve.

Sin embargo, si queremos realizar operaciones pesadas con el móvil (procesar video, componer música, mover mapas con gran cantidad de información) el rendimiento puede verse comprometido o incluso no poder hacerse con HTML o Javascript, teniendo que crear algún plugin nativo para cada una de las plataformas.

Normalmente, prácticamente el 90% de las aplicaciones que se desarrollan para un servicio online no requieren realizar tareas tan pesadas y una aplicación híbrida puede reducir mucho el coste de desarrollo.

Crear una aplicación instalable nativa

Esta es la opción que nos permite aprovechar todo el potencial del hardware del usuario.

Tenemos dos opciones cuando afrontamos un desarrollo de este tipo: desarrollar una aplicación por cada una de las plataformas (android, iOS, windows phone..) o utilizar una solución que nos quite el mayor trabajo posible de mantenimiento en cada una de ellas.

Hay que tener en cuenta que aunque desarrollemos para una plataforma en concreto podemos tener versiones que no tengan nada que ver. Por ejemplo en Android, una versión 3 difiere en tantas cosas de una versión 4 que podríamos tener que plantearnos tratar esas versiones como dos plataformas distintas y dos apps distintas. Es un problema que no afecta sólo a aplicaciones nativas sino también a webapps híbridas o incluso de navegador.

Si optamos por una solución que nos permita compartir código entre plataformas, las opciones más visibles en la actualidad son Appcelerator Titanium y Xamarin, la opción que más he investigado.

En mi caso descarté Titanium en favor de Xamarin porque todo el conocimiento que adquiría con la herramienta me ataba a ella. La forma de trabajar en Titanium no se parece ni se puede llevar al desarrollo de la plataforma en concreto.

Esto es especialmente importante en la parte de las vistas ya que sin lugar a dudas, la implementación del diseño es la parte más costosa en un desarrollo móvil nativo. En Xamarin puedes copiar y pegar todo el trabajo realizado en las vistas de una aplicación Android a una aplicación Xamarin.Android y funciona sin tocar absolutamente nada. Esto para mí significa no perder ni dinero ni conocimiento en el caso de que la herramienta en un futuro cambie de rumbo o desaparezca.

Otro punto en contra de Titanium es que aunque el código del framework es nativo, el código de tu aplicación en javascript es interpretado, perdiendo rendimiento en comparación al desarrollo nativo de cada plataforma o el desarrollo con Xamarin.

Xamarin tiene muchas más ventajas adicionales, por ejemplo se comprometen a dar soporte en el mismo día de las nuevas funcionalidades que salgan en las actualizaciones de los sistemas operativos soportados. También disponen de un framework (Xamarin.Forms) para construir vistas convencionales con una sola base de código.

Aunque no todo es maravilloso ya que tanto el IDE Xamarin Studio y las extensiones para Visual Studio deben mejorar muchísimo todavía. Tampoco te libra de conocer las particularidades de cada plataforma pero sí que te evita tener que dominar lenguajes específicos permitiendo centrarte en c#

Aunque sea de pago, merece mucho la pena evaluar el desarrollo con esta herramienta, sobre todo si no quieres mantener desarrollos en tecnologías distintas o tener en tu equipo desarrolladores especializados en cada lenguaje concreto de cada plataforma.

Conclusión

El camino para desarrollar aplicaciones móviles viniendo del desarrollo web, que es naturalmente multiplataforma, no es para nada trivial.

No sólo requiere que tomemos decisiones en cuanto a herramientas a utilizar para crearlas sino también pensar en su posterior mantenimiento.

También debemos cambiar la forma en la que diseñamos nuestros servicios para tener en cuenta las expectativas de nuestros usuarios fuera de su portátil o equipo de sobremesa.

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.

 

Kintsugi

Kintsugi” es un método tradicional japonés de reparación de objetos de cerámica rotos.

Unían las piezas con una mezcla nada discreta de oro y plata.

En lugar de ocultar la unión de las piezas al máximo posible, la exponían haciendo evidente que el objeto se rompió en el pasado y tras ser reparado, se convirtió en algo nuevo, bello, singular e irrepetible.

Muy inspirador.

Kintsugi: The Art of Broken Pieces from Greatcoat Films on Vimeo.

Un diseño más interactivo

Hay palabras que sirven para detectar cuando un cliente no tiene su idea clara, no tiene experiencia o no sabe lo que quiere.

La reina de todas esas palabras para mí es: “interactiva/vo”.

“Que permite una interacción, a modo de diálogo, entre el ordenador y el usuario.”
RAE

Típicas frases en las que se suele incluir dicha palabra:

  • Quiero un diseño más interactivo.
  • Necesitamos una aplicación, debe ser muy interactiva.
  • Nuestro valor diferencial es crear un producto con funcionalidades que ofrecen una mayor interactividad de la que se puede encontrar en los productos de nuestra competencia.

Las palabras interactiva, interactivo e interactividad son tan difusas que evitan hacer el ejercicio de pensar en resolver o incluso detectar los problemas que intentamos resolver en cada proyecto.

Si alguien te ofrece un presupuesto para hacer algo interactivo, sin entrar en el detalle que define el alcance de dicha “interactividad”, prepárate para una gran decepción.

foto por Mint Digital