Etiquetas

Es muy habitual que cuando un servicio introduce modificaciones en sus programas o diseño, enseguida los usuarios critican duramente hasta los aspectos más superficiales: el color es malo, el espacio no es el adecuado, no se debería haber cambiado de lugar ese botón, debería haberse usado otro icono, ese enlace debería estar arriba y no abajo, la información se debería mostrar como estaba antes, etc.

Este tipo de críticas es proporcional a la popularidad del servicio o sitio. Pero voy a explicar algnas cosas. Aunque existen numerosos casos de decisiones muy estúpidas (prefiero no dar ejemplos, algunos son amigos… o yo mismo 😉 ), la mayoría de las empresas más populares tienen programadores y arquitectos de software muy buenos, no son idiotas. O al menos, no todos, la media no es más estúpida de la media de los que escriben en blogs y Twitter. Lo que pasa es que en el desarrollo web se suelen aplicar unas pocas reglas que no suelen ser conocidas por los no programadores:

  1. Experimentar. La única forma de saber si algo va a funcionar o es mejor que lo que había antes, es probarlo. Cuando se desarrolla un nuevo servicio, no se puede saber a priori cómo lo usarán sus usuarios, qué características serán las más usadas, cuáles las irrelevantes que quizás valga la pena desechar. Este tipo de experimentos son tan comunes que hasta le han puesto un nombre: balas trazadoras. Si quieres acertar en el objetivo, puedes pasar meses haciendo cálculos, o desarrollando aparatos y métodos muy complejos, de la capacidad explosiva exacta de la pólvora, peso de la bala, velocidades, aceleraciones, cambios de dirección, gravedad, resistencia del aire, etc. O puedes poner unas cuantas balas trazadoras que den información inmediata y así poder corregir sin necesidad de complejos y lentos cálculos previos.
  2. Cambios incrementales (para permitir experimentos). En la época del desarrollo web,  los cambios constantes no sólo son deseables, son imprescindibles. No tiene sentido desarrollar módulos durante meses si no se sabe si serán usados o útiles, es mejor probar poco a poco, e introducir esas nuevas caratecterísticas que harán de balas trazadoras para el futuro desarrollo. No tiene sentido desarrollar una nueva versión (de programas o diseño) durante meses sin que sea probado por los usuarios. El momento que se publique, las quejas serán mucho más numerosas, y más caras de corregir y/o volver atrás. Hay que aprovechar al máximo posible la opinión de sus usuarios, y vale tanto para los programas como para el diseño: también se pueden hacer cambios incrementales en el diseño (vomo habéis visto recientemente en Google y Google+).
  3. Ciclos de desarrollo breves. No es como construir un rascacielo: hay que estar seguro de que lo que hacemos o usamos es adecuado, no se puede permitir que se caiga todo el edificio porque falló una de las vigas, o el viento genera más fuerzas laterales que no fueron tomadas en cuenta. Hay que estar muy seguro  de comenzar a cavar los cimientos. Con los programas -y diseños- no es igual, no hace falta que se haya puesto el cristal hasta la última ventana para poder empezar a usarlo, se pueden solucionar problemas sin demasiados costes (siempre teniendo en cuenta de asegurarnos en el núcleo: seguridad, esquema fundamental de la base de datos, etc.). Mientras los módulos principales -la estructura básica- funcionen, los pequeños fallos se pueden solucionar rápido (en general son tolerados, e incluso no percibidos, por la mayoría de usuarios). Tampoco hay que hacer una «copia de oro» para estampar millones de CDs o DVDs, desplegar una nueva versión de aplicación web requiere esfuerzo y tiempo mínimos.
  4. La usabilidad no es una ciencia exacta (tampoco el diseño). Puedes tener los mejores expertos en usabilidad, pero la realidad es que hay pocas reglas objetivas, y éstas dependen de muchas situaciones. Lo que es deseable para un usuario novato, puede convertirse en molesto a los pocos días de uso. Lo que puede ser esencial para un experto, o para un programador, puede ser irrelevante para la mayoría de los usuarios. Lo que puede parecer una virguería de diseño o funcionalidad, puede ser sólo más bloating para los usuarios (y otros programadores). Lo que puede funcionar para un experto en usabilidad, quizás moleste a la mayoría (basta leer en Internet las críticas al sitio web de unos de los mayores gurús de usabilidad).
  5. Mediciones de uso. Las empresas hacen mediciones del uso de las diferentes funcionalidad de un programa, es muy sencillo en programas web. Por ejemplo, pueden descubrir que hay funcionalidades que nadie usa, pero que cargan innecesariamente a los servidores, o al navegador (los «javascripts» no son gratis). O que un botón secundario genera muchos clics innecesarios porque induce a confusión. Los programadores saben que descubrirán cosas como estas, aunque pasen miles de horas diseñando y discutiendo. Por eso a veces se prefiere poner límites a las etapas de diseño, y dejar que sean los usuarios los que den la información con su propio uso: lleva menos tiempo, y se puede solucionar rápidamente.
  6. Motivación. No hay nada más desmotivador para un programador que sus programas tarden eones en ser desplegados y utilizados. No hay nada más motivador para un programador que probar cosas nuevas, salirse de una idea o diseño precocencebido meses antes de que el programa tenga el uso actual. Los buenos directores de proyectos lo saben, y por eso suelen tomar la [acertada] decisión de reducir al mínimo los ciclos de desarrollo, y permitir experimentar con nuevas funcionalidades.
  7. Los errores son inevitables. Un programa nunca está libre de fallos, es inútil buscar la perfección. Puedes hacer todos los unit tests que se te ocurran, pero los programas son complejos, cuando lo usan miles, o millones de personas, siempre aparecen bugs y situaciones imprevistas. Un buen programador lo sabe, un buen director de proyecto, también, por eso se planifica antes: el tiempo para desarrollar un nueva característica, y el tiempo que llevará corregir los fallos que encuentren los usuarios. Lo fundamental es ser muy cuidadosos y estrictos con temas de seguridad, privacidad, datos, y el tronco principal de la aplicación (nunca debe caer completamente), pero más flexibles en el desarrollo de nuevas funcionalidades.
  8. Resistencia al cambio. Los programadores y directores de proyectos saben que los usuarios son muy resistentes a cualquier cambio. Saben que estos se quejarán mucho inmediatamente después de cualquier cambio, sin tener en cuenta las reglas anteriores. Por eso, la mayoría de estas quejas son filtradas e ignoradas, para poder concentrarse en aquellas que sí son importantes.

Estimados usuarios, antes de quejaros de cualquier cambio, tened en cuenta los que os comenté antes. Bueno, en realidad os mentí.

Aunque os puede servir como información básica, estas no son recomendaciones para usuarios, está bien que sean así. Los puntos #1 a #8 son recomendaciones a mis colegas programadores y directores de proyectos. Sobre todo para aquellos que todavía enfocan un desarrollo web como si fuese una aplicación de hace 20 años. O peor, con la analogía errónea de construir rascacielosm y luego se quejan de la falta de motivación de sus programadores, o no entienden por qué a los usuarios no les gusta el último diseño sobre el que han estado trabajando un año.

Recomiendo unos pocos libros que leí, o releí, recientemente y que considero imprescindibles: