Getting Real. El libro que todo nuevo Jefe de Proyecto debería leer y hacer leer a su equipo

Foto por liewcf (via Flickr)

“No me gusta la expresión ‘menos es más’, porque significa implícitamente que ‘más es mejor’, yo prefiero ‘menos es menos’” – Jason Fried, presidente y fundador de 37Signals.

Nota del editor: Este es una artículo invitado de Aitor Calero García del blog Un Cafelito a las Once | Si quieres publicar un artículo en El Gachupas, revisa la página de colaboraciones.

Hace ya algún tiempo, y no sé muy bien cómo, llegué a la página de 37Signals. Supongo que sería por algún tipo de publicidad de alguno de sus productos. Allí me encontré con un libro que me hizo reflexionar profundamente sobre la forma en la que se deben plantear y ejecutar los proyectos del mundo de las tecnologías de la información. Toda mi vida profesional ha estado vinculada a internet y las tecnologías de la información, y durante toda mi vida profesonial, he oído siempre el mismo mantra: requerimientos, análisis, diseño, implementación, pruebas y puesta en producción. El ABC de cualquier proyecto en informática. ¿Es este planteamiento el adecuado en una época en la que todo se puede hacer de una forma mucho más dinámica? ¿Hay otras vías posibles? ¿Es el cliente quien debe marcar siempre los requisitos? ¿Sabe o quiere hacerlo?

Antes de entrar en materia, y para quienes no conozcan 37Signals, comentaros que es una compañía fundada en 1999 con base en Chicago, que se decida en exclusiva a hacer proyectos web. La filosofía de 37signals es la simplicidad por encima de todo. Hace poco, uno de sus fundadores y presidente Jason Fried nos contaba cómo era su forma de trabajar en 37signals.

El libro, Getting Real (traducido como “Haciéndolo Real” en la web, aunque yo hubiera preferido “Siendo Auténtico”) introduce en 16 capítulos toda una nueva forma de afrontar los proyectos. Por supuesto, está muy orientado a los proyectos de internet y/o software, pero creo que contiene principios que podrían ser extrapolables a cualquier otro. No voy a entrar en todos los detalles de cada capítulo, porque el libro está disponible en la web de forma gratuita, aunque bien merece los 30$ que vale impreso.

A mi me llamaron especialmente la atención dos principios:

1. La respuesta por defecto a cualquier nueva funcionalidad es NO. Creo que es justo lo contrario de lo que ocurre en la mayoría de los proyectos de software, donde el “cliente tiene la razón” impera. Analicemos com más detalle esta frase. El cliente tenía la razón, cuando va a una tienda y quiere un producto físico. El sabe qué necesita de ese producto y porqué lo está comprando. En informática no suele ser así. El cliente muchas veces no sabe lo que quiere (al menos en mi experiencia) y tu sabes mucho más del producto final que él. Cuando se pide que se añada cierta funcionalidad a algo, esta petición no suele estar basada en una necesidad real, sino más bien en un “estaría bien incorporar esto”, “seguro que a los usuarios les gusta”. En resumen, están lanzando una vaga hipótesis que van a comprobar con nuestro proyecto. La respuesta debe ser NO, siempre. Solo un análisis que lo justifique realmente debería llevarnos a implementarla. (Más sobre esto en el capítulo 5 del libro.) Yo nunca decía no a nada, más bien era un “lo veremos”, “se estudiará”, “a ver si lo podemos hacer”, es decir un sí implícito, ¿y vosotros sabéis decir no por defecto?

2. Haz primero el diseño de la interfaz. Mi carrera profesional empezó como programador, y por eso lo primero que me sale es tirar código, pensar en cómo haría esto o aquello, en qué librería voy a utilizar o en qué plataforma voy a desarrollar. ¿Y el diseño? ¡Qué mas da! Mientras funcione. Luego se les da un buen curso de formación y listo. Craso error. Cuántas aplicaciones habré conocido que no se usan simplemente porque al usuario final no le gustan… Como afirman en el libro, hacer el diseño debería ser lo primero. Diseñar es fácil, y en los proyectos de software más. Es la diferencia entre un proyecto de arquitectura y uno de software. En el primero no puedes hacer la fachada “real”, enseñársela al cliente y ver si le gusta. En informática sí. Puedes enseñarle varios bocetos de interfaces, aunque no haya nada por debajo. Esta será la única garantía de que lo que vas a construir se va a usar. Además, forzará a tu equipo a que el desarrollo se ajuste a esa interfaz y no al revés. Los diseñadores, al menos en los proyectos en los que he trabajado, siempre han estado relegados a un segundo plano, son los que lavan la cara con “iconitos” y “logos” al programa. Si alguien se tiene que incorporar al equipo al principio debería ser un buen diseñador y uno que supiera de verdad de interfaces de usuario. Caros y escasos, sí, pero muy necesarios. ¿Y vosotros? ¿Cuándo pensáis en las interfaces de usuario y en el diseño?

Como reza el título del post, 37Signals es el libro que todo jefe de proyecto debería leer y hacer leer a su equipo. Muchos podréis decir que es imposible aplicar los conceptos que se exponen en él a vuestro caso. Da igual. Siempre habrá detalles que se podrán aplicar, siempre se podrán subdividir los trabajos y las tareas para poder aplicarlos a sub-proyectos. En la época de la Web 2.0 y redes sociales, en la época en la que interactuar con clientes y usuarios viaja a la velocidad de la luz, es posible que una forma más ágil de enfocar los proyectos sea imprescindible.

¿Qué pensáis? ¿Conocíais ya el libro? Si es así, ¿qué otras partes os han resultado interesantes y/o útiles?

Puedes seguirme en Twitter: 1cafelitoalas11, o a través de mi blog Un Cafelito a las Once, donde encontrarás ideas, trucos y tecnología para la vida diaria.