En Fon buscamos software development manager

Publicado el por

Mi amigo, colega y compañero Javier Fernández, hasta ahora software development manager en Fon, quiere enfrentarse a nuevos retos fuera de Fon por lo que la que considero una de las posiciones más interesantes relacionadas con tecnología en Madrid se queda vacante.

Todo lo que hemos vivido juntos a nivel profesional Javier y yo necesitaría de una colección de posts pero hasta que la escriba, solo puedo desearle lo mejor en esta nueva etapa profesional.

Aquí os dejo la descripción formal del puesto. Si hay alguien interesado me puede contactar a mi directamente:

Software Development Manager

The Company

Fon is the world’s largest WiFi network. The company was founded in 2006 by CEO, entrepreneur and internet pioneer, Martin Varsavsky, with the goal of blanketing the world with WiFi that is free for everyone. Today Fon is the largest WiFi community in the world with over 13 million hotspots globally. Fon has a growing list of Telco partners who build Fon WiFi sharing functionality into their broadband routers or bundle Fon products together with their own technology. Atomico, British Telecom, Coral Group, Skype, Google, and Index Ventures are investors in Fon.

Fon is a young and dynamic company that is growing fast on a global scale. It is a great place to develop your technical and commercial skills and work with a multi-talented, multi-cultural team. In addition, Fon has the atmosphere, casual dress and contagious energy of a start-up.

The position

Software Development Manager will ensure that the development of Fon products are delivered effectively, efficiently, on time, in specification and in quality.

This role includes management of multiple teams, each team have its own team leader. The Software Development Manager have to coordinate each team development cycle with product owners roadmap.

Other responsibilities include:

  • Organizes, mentors and motivates a team of 20-25 software developers
  • Manages and maintains the organization’s repository of software applications through best practices and the appropriate staffing and management of the development teams
  • Works together with product managers to develop products on-time and in quality
  • Works together with principal engineer to align the development with technical strategy and technical decisions

Requirements and necessary experience

  • 2+ years of experience in managing managers or team leads
  • 5+ years of experience in managing small-sized teams (5-10 people)
  • 5+ years of experience managing developments with scrum methodology
  • 5+ years of experience acting as java architect
  • Experience developing high availability and high scalability software
  • 3+ years of experience managing development teams using CI, unit testing (JUnit), functional testing (Selenium, SoapUI)
  • Dynamic and motivating personality adaptable to the changing environment of a startup company

Preferred

  • Experience in the telecommunications industry, notions of WiFi systems
  • Understanding of protocols and communications systems
  • Scrum master certification

La decisión colectiva es mejor que la individual

Publicado el por

La afirmación que lanza el título de este post creo que es conocida por todos pero no por eso deja de ser importante.

Estadísticamente se ha demostrado en multitud de ocasiones que una decisión colectiva es más efectiva, obtiene mejores resultado, que una decisión tomada por una persona sola, de manera individual. ¿Quiere eso decir que nunca es mejor una decisión individual? No, hay casos en que la decisión individual se demuestra mejor que la tomada por un grupo pero en una sucesión grande de decisiones, las tomadas por un grupo serán mejores que las individuales.

Hace años, en un curso de equipos de alto rendimiento, había una dinámica de grupo que consistía en elegir, de una lista bastante grande, qué elementos nos llevaríamos a una isla desierta. Se elegía individualmente y después de discutía en grupo hasta llegar a un consenso. Al terminar, el monitor del curso empezaba a contar qué cosas nos iban a pasar en la isla desierta y teníamos que ver si con los elementos que nos habíamos llevado podríamos o no sobrevivir. En el 90% de los casos los objetos elegidos por el grupo garantizaban mejor la supervivencia que los elegidos individualmente por cada miembro del equipo.

Si nos llevamos esta afirmación al mundo del desarrollo de software y concretamente a un entorno ágil, de equipos multidisciplinares más o menos auto organizados, a lo largo de la construcción de un producto las decisiones que tome el equipo nos van a acercar más a un mejor producto que las tomadas por una única persona. En ese escenario, los managers deben trabajar en que todo el equipo se implique, que participe y que, por falta de experiencia, no se tomen algunas decisiones de calado importante sin la necesaria reflexión pero no deben ser los managers los que tomen las decisiones, al menos de manera individual.

En un equipo pequeño es muy fácil proceder de esta manera. El problema viene cuando se quieren escalar estos equipos ágiles para poder abordar el desarrollo de productos grandes y además tener una velocidad de crucero importante. En ese entorno creo que es muy importante el trabajo que desempeñas los managers, creo que son necesarios pero más en tareas de mentoring y coordinación entre los equipos en lugar de en la toma de decisiones.

Escalar equipos ágiles es bastante complicado y es en la batalla en la que estamos ahora mismo en Fon. En otro post contaré cómo estamos librando la batalla de escalar la agilidad.

Do your job

Publicado el por

Los que somos seguidores de la NFL todavía estamos con la resaca de la posiblemente mejor Super Bowl de la historia. Una remontada épica por parte de New England Patriots dificil de olvidar.

El equipo ganador es el mejor equipo de la NFL de los últimos 15 años, con siete presencias en la SuperBowl, ganando cinco de ellas. Todos estos títulos los han conseguido con la misma pareja entrenador-quarterback: Bill Belichick-Tom Brady.

NFL: Miami Dolphins at New England Patriots

El futbol americano a máximo nivel como el que se juega en la NFL tiene muchas similitudes con una empresa de tamaño medio o grande. Para salir victorioso se requiere estrategia, táctica y operativa de primer nivel. Cuanto más te gusta el juego y más atención pones a los pequeños detalles más valoras un trabajo pensado, entrenado y ejecutado con precisión milimétrica que marca la diferencia entre los ganadores y los perdedores. Se podría hacer un post entero sobre este tema…. pero no será hoy.

Los Patriots tienen un lema principal que se ha convertido prácticamente en una forma de entender el deporte y que se podría aplicar sin duda al entorno empresarial: do your job. Lo voy a repetir más alto todavía: DO YOUR JOB. Lo que le pide su entrenador a cada miembro del equipo es una única cosa, que hagan su trabajo. Ni más ni menos. Si todo el mundo hace su trabajo Bill Belichick no tiene dudas en que ganarán los partidos y los campeonatos. Además, el bueno de Bill tiene claro que son tan fuertes como su miembro más débil y por tanto lleva este lema hasta el extremo. Si no haces tu trabajo, estás fuera.

b-9mxy8uqaavmxl

Si nos lo llevamos al mundo laboral, a cada empleado o colaborador sólo habría que pedirle que haga su trabajo. Debe estar claro cuál es el trabajo de cada uno y ahí es donde fallan muchas organizaciones pero si este punto está claro y todo el mundo hace su trabajo se conseguirán los objetivos.

Si eres líder o manager y quieres aplicar esta filosofía al liderazgo y la gestión debes tener en cuenta:

  • Comunica el plan de trabajo a tu equipo aportando una visión completa permitiéndoles interiorizarla y verse dentro de ella y entender cómo cumplir con el plan
  • Define y comunica las expectativas sobre cada miembro del equipo traduciendo el plan de trabajo en acciones de las que cada uno se pueda responsabilizar y ejecutar
  • Practica los fundamentos (muy aplicable al deporte y más dificilmente traducible en el entorno laboral). Sería algo así como repetir una y otra vez los puntos básicos de tu plan y metodología hasta que se ejecute casi sin pensar
  • Da feedback inmediato para facilitar el aprendizaje. Si ves que alguna cosa no se está ejecutando bien, no lo dejes pasar y comunícalo de manera positiva para que se pueda corregir cuanto antes
  • Fomenta e inspira la confianza entre los miembros del equipo promoviendo una serie de valores que respalden la lealtad e inculcando una fuerte sensación de pertenencia a un equipo

Si eres un miembro de un equipo y te gusta esta filosofía puedes hacer lo siguiente:

  • Si no tienes claro cuál es tu trabajo, pregunta a tu jefe. Intenta que te cuente el plan y las expectativas
  • Céntrate en hacer tu trabajo y evita otras distracciones. Déjalas para cuando hayas completado tu trabajo
  • Antes de mirar si otros están haciendo su trabajo, haz tu trabajo
  • Preocúpate de generar confianza en otros miembros del equipo. No es algo sencillo y muchos hemos necesitado ayuda y/o orientación para aprender a hacerlo
  • Si haces consistentemente tu trabajo y alguien cercano a ti no lo está haciendo, habla con él de manera positiva, el feedback siempre debe ser bienvenido

 

Espero que os guste esta filosofía.

Cómo y cuándo pedir un aumento de sueldo

Publicado el por

Cómo y cuándo pedir un aumento de sueldo

Este post va dedicado a perfiles técnicos. Voy a hablar sobre cuál es el momento para  plantear algo tan humano como pedir más retribución por nuestro trabajo y cómo articularlo en el universo corporativo  para tener más probabilidad de éxito.

Todas las ideas vienen de mi experiencia y no hay que  tomarlas  como verdades absolutas. Espero que os sea útil.

Desde el punto de vista del empleado, una subida de sueldo se puede abordar de dos maneras,  inmediata (frito con el fuego a tope) o encauzada (cocido a fuego lento). Desde el lado de la empresa se puede plantear mal o bien.

Manera inmediata

Bajo mi punto de vista es la manera mala. Consiste  en salir al mercado, buscar trabajo, conseguir una oferta por el salario que quieres ganar y volver  a hablar con tu empresa para decirles que tienes una oferta de trabajo. Que consigas un aumento de sueldo va a depender de que tu empresa se pueda o no permitir que te vayas justo en ese momento. Si les viene mal, te subirán el sueldo para retenerte y habrás conseguido tu objetivo: subida de sueldo con carácter inmediato. Si se pueden permitir prescindir de ti, simplemente  te dejarán marchar y pondrán en marcha un plan para sustituirte. Entonces en lugar de conseguir la subida de sueldo, te encontrarás con un nuevo trabajo aunque mejor pagado.

Aunque te suban el sueldo, no creo que puedas quedarte contento. Casi con toda seguridad la empresa lo percibirá como una “infidelidad” y  perderás parte de la confianza y apoyo que tenías de tu jefe. Más abajo hablo de modelos de “relación abierta” que son poco comunes y en los que no se vería mal esta forma de abordar una subida de sueldo pero, al igual que en una relación de pareja, estos modelos son escasos y deben estar aceptados por ambas partes.

Sin que tu lo sepas y con mucha probabilidad tu jefe se preparará para que en el futuro vuelvas a jugar la misma carta y estará preparado para dejarte marchar. Es muy probable que baje su nivel de confianza en ti y empiece a dar las tareas más interesantes a otras personas en las que siga confiando. Al fin y al cabo somos humanos y necesitamos apoyarnos en gente en la que podamos confiar.

Manera encauzada

Bajo mi punto de vista es la manera buena. Se trata de ir dando poco a poco los pasos adecuados para obtener una subida de sueldo y que se produzca sin que sea traumática.

Cuándo

En primer lugar hay que saber cuándo se revisan los sueldos en tu empresa. En casi todas las empresas se abre una ventana de revisión de sueldos con el cierre del año fiscal (cuando se cierran las cuentas anuales). En algunas empresas coincide con el final del año natural, en otras no. Es típico en empresas americanas que el cierre del año fiscal se haga en mayo, junio o julio. Unas semanas antes del cierre o justo después, tu jefe tendrá que presentar los presupuestos del siguiente año y ahí incluirá los costes de los salarios. Que sea consciente de  que quieres o esperas una subida de sueldo le dará la posibilidad de presentar a nivel corporativo esa subida para que sea aprobada junto con el resto del presupuesto. Ese es el momento correcto. Una vez aprobados los presupuestos, cualquier subida es una excepción y es más difícil que se apruebe y, aunque tu jefe quiera, puede ser que no se lo aprueben.

Si se pasa el momento y quieres hacerlo bien, casi seguro que tendrás que esperar un año. Si lo anticipas demasiado, sólo le vas a calentar la cabeza a tu jefe sin que pueda hacer demasiado. Un mes o mes y medio antes de que tenga que presentar el presupuesto es buen momento. Se lo puedes recordar llegando las fechas pero no le persigas cada semana.

Cómo

Obtener una subida de sueldo por el camino bueno es como preparar un plato a fuego lento, hay que darle su tiempo y tener paciencia. Piénsalo y prepara una estrategia.

Bajo mi punto de vista el mejor argumento para pedir una subida de sueldo es haber demostrado durante un tiempo que eres capaz de desempeñar las tareas en forma y fondo que se esperan de alguien que tiene el sueldo que tu quieres conseguir. Pueden ser las mismas tareas pero con más calidad, pueden ser las mismas tareas con la misma calidad pero hechas en menos tiempo, puede ser demostrar liderazgo, puede ser asumir determinada gestión, etc… Sería bueno saber qué espera tu jefe de alguien con más experiencia, mejor posición o mejor categoría para evitar algún disgusto. Por ejemplo, que supongas que espera que tengas capacidad de gestión de un equipo y realmente lo que espere sea liderazgo técnico. No tengas problema en preguntarle, de manera distendida y así afinas el tiro. A partir de ahí durante un periodo de varios meses empieza a hacer, sin montar mucho jaleo, lo que se espera de alguien con mayor sueldo y/o responsabilidad. Todos los ingredientes están en la olla y ahora hay que esperar a que se cuezan.

Llegado el momento de pedir una subida de sueldo presenta tus argumentos apoyado en que llevas un tiempo demostrando que puedes hacer lo que se espera de alguien con ese sueldo. No tengas problema en presentar evidencias de esas tareas, siempre son bienvenidas. Es posible que te lleves una sorpresa y tu jefe ya contaba con subirte el sueldo. Aunque no lo creas, a veces los jefes suben el sueldo sin haberlo pedido.

Tu jefe no te podrá dar  una respuesta inmediata, no la esperes. Sólo pregúntale si él cree que te mereces la subida pero recuerda que puede ser que por otras razones corporativas esa subida no llegue al final del año fiscal. No te desanimes ni dejes de hacer lo extra que estabas haciendo, el año que viene vuelve a la carga y seguro que lo consigues.

Cuánto

Éste es un punto importante. En una empresa es muy difícil justificar una gran subida a nivel porcentual si no hay un cambio importante de puesto de trabajo. Si pasas a ser manager o director si puedes pedir una subida más grande pero si símplemente es una subida porque tienes más experiencia o el precio de mercado sube, no esperes más de un 10% como mucho. Igual te parece poco pero el IPC raramente sube más de un 2% así que una subida del 10% supone un aumento de tu poder adquisitivo.

Otro error importante es pensar que el sueldo debe subir muy rápido los primeros años. Es cierto que cuando tienes poca experiencia y el sueldo es bajo sube más alegremente pero cada vez las subidas serán menores y más espaciadas, no pueden ser infinitas.

Relaciones abiertas

En este mismo post hago mención a las relaciones abiertas en el ámbito profesional. Como me ha quedado un post muy largo, lo dejo para el próximo post. Es como cuando en una serie te cortan en una parte interesante y tienes que esperar al próximo capítulo. Continuará…

Qué no es la agilidad

Publicado el por

Creo que está bastante aceptado dentro de la industria de desarrollo de software que la forma en la que se obtienen mejores resultados es siendo ágil, aplicando metodologías ágiles que permitan obtener software lo más cercano posible a las necesidades y que el proceso de desarrollo sea lo más sostenible posible.

En muchas empresas la alta dirección acepta el concepto de agilidad pero no tienen claro lo que es ser ágil y mucho menos, lo que no es ser ágil.

Creo que todos tenemos claro que desarrollar software no es un proceso industrial, proceso tipo con el que se ha querido comparar durante varias décadas, es algo diferente. Los actores son diferentes, el resultado es diferente, la manera de obtener el resultado es diferente.

No soy la persona más adecuada para decir qué es la agilidad, para eso hay gente muy buena divulgando sobre ello como Javier Garzás al que sigo desde hace tiempo, pero si quiero listar una serie de cosas que, bajo mi punto de vista, muchas veces llevan a confusión y que mucha gente cree que tienen que ver con la agilidad y no es así. Esta confusión es mayor entre la alta dirección que no está estrechamente ligada con el desarrollo de software:

  • No hay que documentar. Quizá la confusión viene porque en proyectos en cascada hay mucha documentación y en contraprestación mucha gente cree que en metodologías ágiles no se documenta. Nada más lejos de la realidad. Hay que documentar igualmente aunque otras cosas o de otra manera. Los epics deben tener una descripción suficiente, las historias de usuario necesitan estar documentadas, incluso el definition of ready o el definition of done debería estar documentado para no tener lugar a dudas. Es importante tener claro que ser ágil no es sinónimo de sentar a cuatro o cinco personas alrededor de una mesa a desarrollar lo que a uno de ellos se le acaba de ocurrir, sin estructura ni análisis previo.
  • El alcance se puede cambiar en cualquier momento. Es cierto que las metodologías ágiles nos separan de un desarrollo en cascada en que el alcance no tiene que estar cerrado ni firmado a fuego antes de empezar, pretenden tener un proceso más iterativo que permita que el resultado sea lo más cercano posible a lo que necesito. Pero de ahí a cambiar el contenido de un sprint en curso, cambiar la visión del producto o símplemente dejar de hacer lo que se tenía previsto para hacer lo que a un iluminado se le ha ocurrido hoy, hay un paso muy grande. Sí a tener un proceso iterativo vivo; no a ir como pollos sin cabeza.
  • No hay fechas. Es uno de los errores más comunes. Hay gente que piensa que porque esté usando metodologías ágiles no tiene que comprometer una fecha. Se puede y se debe comprometer una fecha. Lo que no está cerrado es la lista de funcionalidades que se entregará en una fecha o el detalle de cada funcionalidad. Eso está vivo y cambiarlo depende de muchos factores (daría para hablar mucho sobre esos factores) pero poner una fecha yo creo que es sano.
  • No hay managers, no hace falta gestión. Este es quizá el punto más controvertido. Cuando hablamos de equipos ágiles hablamos de equipos autogestionados. Por definición son equipos que no necesitan la figura de un manager ya que todo el mundo sabe lo que tiene que hacer y el propio equipo busca el mejor resultado por si mismo, con una dinámica siempre positiva. Este modelo puede funcionar en equipos donde todo el mundo es bastante senior, ya ha trabajado con metodologías ágiles anteriormente y el tamaño del equipo no es demasiado grande (3-6 personas). El problema viene cuando no se cumplen estos puntos. Es decir, hay personas más junior que necesitan de gestión y supervisión técnica, alguien tiene que ser su mentor. También cuando el equipo trabaja en un subproducto de un producto grande. En este caso hay que mantener una estrategia y táctica tecnológica común entre todos los equipos de subproducto y por tanto hay un marco de decisión más amplio que el del propio equipo. Por último, la gestión es necesaria cuando se quiere escalar los equipos ágiles, cuando hace falta ser más rápidos y se requiere de más gente trabajando. Pasar de un equipo de 6 personas a un equipo de 40 trabajando en un producto no es nada fácil y eso se tiene que hacer de manera ordenada y bien gestionada para evitar que sea un caos. En este caso hace falta una gestión y liderazgo compartido entre todos los equipos.

 

Es muy posible que esté equivocado en algún punto o que alguien no comparta mi visión. Por favor, no dudéis en comentar el post y darme vuestro punto de vista al respecto.

Por qué corro

Publicado el por

Como algunos ya sabéis porque de vez en cuando doy el coñazo por Twitter publicando mis sesiones de entrenamiento, una de las actividades que hago habitualmente es correr. El otro día iba haciendo una tirada de 15km y estaba tan a gusto y disfrutando que me di cuenta que las razones por las que corro actualmente nada tienen que ver con las razones por las que empecé a correr hace dos años.

Cuando empecé a correr buscaba una actividad que pudiera hacer a medio día, que fuera flexible a nivel de horarios y de días de práctica y me permitiera estar un poco en forma y perder algo de peso. No nos engañemos, el peso es como el paso de los años: va creciendo poco a poco y sin darnos cuenta, sin cambiar nada, cada año que pasa la báscula marca algún kilo de más que es dificil de perder. Si eso ocurre durante varios años te encuentras rozando los 40 y bastante lejos de tu peso ideal, lo que afecta principalmente a nivel de salud.

Aprovechando que en Fon tenemos duchas en la oficina y que estamos en Las Tablas (Madrid) que es una zona más o menos abierta, pensé que correr me podía ayudar a perder peso y recuperar la forma, además de ser una actividad que cumplía los requisitos que he mencionado anteriormente.

Pero actualmente la motiviación para salir a correr no tiene que ver con mantenerme en forma o perder peso. Tras dos años corriendo dos o tres días a la semana he conseguido que me guste correr, disfrutar durante el tiempo que estoy practicando esa actividad, sentirme como si algo me falta si una semana corro dos o menos días y, para mi los más importante, poder estar ese tiempo sólo con mis pensamientos.

A lo mencionado anteriormente hay que unir uno de los puntos principales: cuando corro por Boadilla del Monte, localidad de Madrid donde resido, lo puedo hacer por el monte y eso me da la oportunidad de estar en contacto con la naturaleza, de poder disfrutar el aire limpio, un paisaje impresionante, un cúmulo de olores frescos, etc… en definitiva, reforzar la sensación de bienestar que me proporciona correr.

Poder disfrutar de hacer una actividad física al aire libre y en el monte ha sido una de las razones por las que he empezado a salir con la bici de montaña. De la mano de mi amigo y compañero Javier, he empezado a practicar otro deporte que me proporciona similares sensaciones y bienestar que correr. Intento salir una mañana del fin de semana con la bicicleta y siempre buscando rutas que vayan por monte. Poder estar en contacto con la naturaleza me aporta mucha energía positiva y me permite recargar las pilas.

Mucha gente piensa que correr es aburrido y no puedo negar que al principio a mi también me lo parecía y tenía que buscar la motivación para salir a correr en mis ganas de bajar de peso pero a día de hoy no necesito buscar una motivación externa. Es necesario ser constrante durante algo de tiempo pero si se le dedica ese tiempo, merece la pena.

Os animo a todos a hacer deporte y si puede ser en contacto con la naturaleza, mucho mejor.

Retomo el blog

Publicado el por

Joder, hace mucho que tengo el blog olvidado. De hecho la última entrada era de cuando trabajaba en etece y desde entonces ha llovido mucho.

En septiembre de 2.014 dejé etece y me incorporé a Fon como director de desarrollo de software. Puedo decir que aquí he encontrado mi casa profesional por muchos motivos pero lo principal sería porque Fon tiene lo bueno de una empresa pequeña como estar constantemente haciendo cosas nuevas, nuevos productos, nuevos desarrollos, un ambiente cercano y familiar, etc… Pero también tiene algunas cosas buenas de una empresa grande como un negocio rentable y estable, trabajar en un entorno multinacional con los mejores clientes, sentirte arropado con una gran familia de más de 150 miembros…

A partir de ahora voy a retomar el blog y voy a volver a escribir habitualmente. Mi idea es tratar temas profesionales de tecnología pero también algunos de opinión personal.

Los primeros que tengo en mente son deuda técnica oculta, transformación hacia devops, cómo usamos AWS en Fon, cómo intentamos ser ágiles en Fon, el stack tecnológico de Fon…

Si hay algún tema que os interese especialmente o alguna sugerencia, no dudéis en añadir un comentario y hacermelo saber.

Un saludo

Nuevo diseño de etece.es

Publicado el por

Hoy hemos subido a producción el nuevo diseño de etece.es. Con este rediseño no sólo queremos darle un lavado de cara a la web, que falta hacía, si no que perseguimos dos objetivos principales:

  1. mejorar la comprensión y experiencia de los nuevos usuarios que aterrizan en nuestra web
  2. mejorar el posicionamiento orgánico

diseño_etece

El primer objetivo, el de mejorar la comprensión de nuestro modelo y mejorar la experiencia de nuevos usuarios, estamos convencidos de alcanzarlo ya que el rediseño se ha hecho en base a los resultados de un test de usuarios que hicimos hace dos meses y donde aprendimos cómo usan nuestra web los nuevos usuarios, qué entienden de nuestro modelo y qué y dónde esperan encontrarlo.

El segundo objetivo, el de mejorar el posicionamiento orgánico, lo pretendemos conseguir mediante la inclusión de más contenido que trabaje de manera natural nuestras palabras clave. Este es más complicado porque nunca sabes a ciencia cierta si los cambios van a ser a mejor, pero estamos confiados de ver los resultados en un plazo de seis meses.

Espero que os guste el nuevo diseño y, como siempre, cualquier crítica constructiva es bienvenida.

El diseño responsive no siempre es lo mejor

Publicado el por

Últimamente todo el mundo apuesta por el diseño responsive y tiene sentido. Con un único diseño que se adapta a los diferentes tamaños de pantalla estoy dando a mi usuario la mejor experiencia en mi web. Pero no siempre es la mejor alternativa si tenemos en cuenta las diferentes condiciones que rodean a la navegación desde diferentes dispositivos. Un smartphone puede acceder a Internet a través de WIFI o a través de la red móvil, mucho más lenta. Lo mismo pasa con las tablets aunque en este caso el porcentaje de accesos a través de WIFI es mucho mayor que a través de la red móvil. Esta sutil diferencia puede suponer que la experiencia de un usuario sea completamente diferente en función de cómo esté accediendo a Internet.

Veamos dos ejemplos diferentes:

  • etece.es
    • diseño responsive: no
    • versión web móvil: si
    • peso de la home de escritorio: 477,5 KB
    • peso de la home móvil: 140,2 KB
  • otogami.com (espero que los camaradas del metal no les importe que la coja como ejemplo)
    • diseño responsive: si
    • versión web móvil: no porque ya tienen el diseño responsive
    • peso de la home en tamaño escritorio: 478,5 KB
    • peso de la home en tamaño móvil: 473,5 KB

Como podéis ver, aunque lo esté viendo en un tamaño mucho más pequeño, el diseño responsive necesita cargar la mayoría de los elementos que existen en una versión web de escritorio y por tanto el peso de la home es prácticamente el mismo.

Si tenemos en cuenta que una conexión 3G media en España está en torno a los 1,5Mbps (fuente adslzone.net) , esto supone unos 192 KB por segundo. Es deir, la home de etece en un móvil por 3G se cargará en menos de un segundo mientras que la de otogami tardará 2,5 segundos. A lo mejor esa diferencia de tiempo no supone un cambio en la experiencia de usuario en algunos casos, aunque en algunos otros puede ser la diferencia entre que el usuario se quede en mi web y acabe convirtiendo o que el usuario abandone.

Además de las razones que tienen que ver con experiencia de usuario, hay otras razones técnicas por las cuales el diseño responsive no siempre es la mejor opción. Si consideramos que un hilo de Apache está ocupado durante todo el tiempo que dura la descarga de lo que esté subiendo, con diseño responsive estaré consumiendo 2,5 veces más tiempo que con una versión móvil específica. Eso supone recursos de mi servidor o lo que es lo mismo, podré soportar más usuarios concurrentes desde dispositivos móviles con el mismo hardware si uso una versión móvil específica frente a un diseño responsive.

Durante todo el post estoy diciendo que el diseño responsive no es siempre la mejor opción lo que quiere decir que hay veces que si que lo es. Cuando el peso de una página es bastante bajo, no merece la pena hacer una versión web y es mucho mejor tener un diseño responsive. Soy especialmente fan de los diseños responsive en webs de contenidos muy sencillas tipo wordpress y similar.

Me encantaría que este post abriera un debate y espero no quedarme solo defendiendo las versiones web móviles específicas.

¿Usarías un navegador desarrollado por Facebook?

Publicado el por

Seguramente la respuesta fuera NO. En mi caso, sin duda, la respuesta sería no. No, porque siempre tendríamos la duda de qué uso haría Facebook de mis datos en su propio beneficio, como por ejemplo publicidad.  Igual que es la respuesta a la pregunta ¿usarías un navegador desarrollado por Google?

Vaya por delante que utilizo a diario muchos de los productos y servicios de Google. Uso Gmail tanto a nivel particular como a nivel personal, uso Drive y Gdocs, utilizo de vez en cuando Google+ para compartir contenido, tengo un móvil con sistema operativo Android, etc… Es decir, Google ya tiene muchísimos datos sobre mi vida. Pero, pudiendo elegir, no quiero que tengan mis datos de navegación. No porque esté permanentemente navegando por páginas porno o por sitios que no quiera que se sepa si no porque prefiero que esos datos estén en manos de una fundación como Mozilla que me despierta mucha más simpatía. Por eso uso Firefox, tanto en el móvil como en el PC tanto en Ubuntu como en Windows.

Está claro que hoy en día es imposible tener privacidad digital. Nuestros datos, emails, fotos, comentarios, etc… están en la red y es imposible que no lleguen a manos de las empresas. Después entramos en la disyuntiva de qué hacen esas empresas con los datos. Igual hacen como Google y firman un acuerdo con la NSA o igual los protegen como oro en paño, cosa que dudo.

Tengo la sensación de que el navegador más usado por la comunidad de profesionales técnicos y de Internet es Google Chrome. Esa misma comunidad cada vez usa menos Facebook y cada vez es más cuidadosa con lo que comparte de su vida personal en las redes sociales. No obstante, usa Chrome con la sesión de Gmail iniciada, para que no quede duda de quién es y Google pueda tener información de primera mano del uso que hace del que es, posiblemente, el software más usado en un PC, en navegador de Internet. Si Firefox no me gustara o fuera una mierda de navegador como lo es Internet Explorer, también usaría Chrome, igual que si la fundación Mozilla tuviera un webmail tan bueno o casi tan bueno como Gmail, también lo usaría en detrimentro de éste último.

Habrá mucha gente que diga que Chrome es el mejor navegador que hay, opinión que respeto y que llevaría a abrir un debate sin fin. No es el objetivo de este post. Símplemente, si no te importa, por favor, dime qué navegador utilizas y así podré confirmar o desmentir mi sensación de que los más técnicos son los que más datos de su vida le dan a Google: