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

Libro: Getting Real (book)

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 un 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.

5 comentarios

  1. Gracias por la referencia Aitor. Estoy de acuerdo en todo, excepto quizá en lo de decir NO al cliente. Soy más de la idea de que el propio cliente diga NO, si finalmente es necesario, cuando se le explique el tiempo que va a llevar el desarrollo y se ponga todo lo que quiere hacer en una lista priorizada por él. De esta manera creo que se le ayuda a que él tenga más control sobre lo que quiere y cuando lo quiere.

    A raíz de esto, creo que metodologías como Scrum son un buen camino a seguir. Añado un enlace muy interesante que he encontrado recientemente sobre scrum:

    http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
    .-= Lo último publicado por Víctor Velarde: Geoproceso interactivo / geoproceso en batch =-.

  2. Hola Victor. Yo pensaba como tu antes, pero la realidad (I finally got real) me ha puesto en mi sitio. Muchas veces los clientes no saben lo que quieren, tienen ideas muy vagas, o se dejan llevar por “modas” que no tienen mucho que ver con lo que realmente necesitan. Por supuesto hay que ser flexibles, pero un NO a tiempo y justificado puede resolver muchos problemas.

    En cuanto a Scrum, yo también he visto hace poco como funciona, y creo que es muy interesantes pero ¿sómos capáces de ponerlo en práctica?
    .-= Lo último publicado por Aitor Calero García: Artículo invitado en el Gachupas: Getting Real =-.

  3. Muy interesante, todo esto es aplicable no solo al desarrollo, creo a cualquier campo relacionado con la tecnología. si hablamos de soluciones relacionadas con la gestión de la empresa, ¿ya puedes morir, como le vas a decir a un gerente que ha llevado a su empresa donde está que este proceso lo tiene que hacer así?, hay que ser valiente, por que al final el que quedas mal eres tú, en hora buena por el post
    .-= Lo último publicado por Nicolas Suárez: Necesito hacer una segmentación de mercado =-.

  4. Si Nicolás, yo creo que todo se puede tratar de justificar y negociar. Al final lo que importa es el resultado, y si un gerente se muestra un poco reacio al método, debemos tratar de hablar con el para explicárselo.

  5. Pingback: Primer aniversario de 1C11 con regalo incluido | Un Cafelito a las Once - 1C11

Deja un comentario