Picacodigos

Mi bloguero favorito, Jeff Atwood, habló hace unos meses de su oficina. Con fotos. Si en su día no lo visteis, no os lo perdáis porque de verdad merece la pena ver como se trabaja en una empresa en la que los desarrolladores importan.

Hoy no he podido evitar acordarme de las condiciones de trabajo de Jeff:

Tened en cuenta que lo que estáis viendo es sólo mi mesa, pero estoy en un despacho en el que trabajamos 12 personas. Las condiciones de abarrotamiento son evidentes, aunque por suerte temporales: el mamotreto que veis a la izquierda es un escáner Canon DR 6080 que tengo que devolver en cuanto termine de hacer unas pruebas con él. Comparadas con las mías, las condiciones de trabajo de Atwood son como comparar el hostal La Pepa con el Ritz. Y seguramente haya gente que esté peor que yo: yo al menos tengo plantas y luz natural.

Es evidente que no todos podemos trabajar con un despacho como el de Atwood: no hay, literalmente, sitio. En el caso de algunas empresas, tampoco hay dinero. Pero sí que se puede hacer un esfuerzo extra por mejorar las condiciones de todos nosotros, sí que los empresarios podrían hacer un esfuerzo para mejorar nuestro office space. Y como hablar es gratis, me permito hacer unas cuantas sugerencias.

• Dobles monitores.- Cada vez surgen más testimonios que aseguran que dos buenos monitores planos aumentan maravillosamente la comodidad (ergo, la productividad) del usuario. Es lógico a nada que lo pensemos un poco: todo el tiempo que me dedico a abrir y cerrar ventanas dentro y fuera de Visual Studio, a organizar esas ventanas para poder hacer n cosas a la vez es tiempo que pierdo. Puede parecer poco tiempo, pero al cabo del día se acumula... y se nota. Si no se pueden poner dos monitores, como mínimo absoluto un buen monitor plano de 19 pulgadas. En mi anterior empresa, gobernada férreamente con un puño de hierro que no se abría jamás para soltar un duro, tuve que soportar durante mis últimos seis meses de estancia un monitor de tubo de 17 pulgadas.
• Sillas.- Si me voy a tirar, como mínimo, ocho horas sentado en la silla; ¿qué menos que sea cómoda? ¿Resistente? ¿Nueva? De nuevo, nos enfrentamos a algo que es de puro sentido común: si un programador está incómodo y tiene que cambiar de postura cada poco rato, difícilmente podrá concentrarse para realizar su tarea.
• Mesas amplias.- Con sitio para todo. Tengo que tener sitio, como mínimo, para que teclado y ratón estén a una distancia cómoda el uno del otro, para poder utilizar un cuaderno sin tener que mover el teclado de sitio, para poder colocar el monitor a la distancia adecuada y, por supuesto, para poder personalizar mi mesa a mi gusto: con fotos o alguna planta o juguetes o lo que quiera cada cual.
• Ordenador.- Simple: lo más potente que pueda comprarse. Como mínimo absoluto dos gigas de RAM, el micro más potente del momento, una tarjeta gráfica potente. De nuevo es algo que cae por su propio peso: no estoy pidiendo esto para poder jugar a Quake en la oficina, estoy pidiendo esto para que cada vez que compilo la solución no tenga que quedarme parado cinco minutos enteros esperando a que mi pobre equipo de desarrollo termine. Pero lo verdaderamente peligroso, desde el punto de vista del empresario, es que esos cinco minutos son una invitación abierta para procastrinar: mientras compilamos la solución abrimos un navegador, o el correo, o un lector de noticias y los cinco minutos se pueden convertir fácilmente en diez o veinte.
• Teclado y ratón a elección del desarrollador.- Así de simple. Yo no sé el resto, pero yo soy muy picajoso con los teclados y los ratones: al fin y al cabo, son mis herramientas de trabajo diario. Y mis gustos en hardware de entrada no tiene por qué ser los mismos que los de mis compañeros. Por lo tanto, en lugar de tener que aguantarse todo el mundo con el mismo equipo (sub)estándar, y seguramente barato, hagamos algo elegante: dejar a cada desarrollador que elija personalmente el teclado y el ratón que quiera, de un catálogo.
• Software y soporte ORIGINALES.- Esto no debería ser ni siquiera un punto de esta lista pero, desgraciadamente, lo es en muchos casos. Señor empresario, si tiene una empresa de informática, si usted vende productos o servicios basados en ciertas tecnologías y gana un beneficio con ellas, debe pagar por ellas. Así de simple. Llevo más de ocho años y seis empresas en este negocio y sólo he estado en dos empresas con software original, sólo una de ellas con suscripción a MSDN. En el resto , todo pirata: desde los sistemas operativos a las herramientas de desarrollo, pasando por todo lo demás. En muchos casos yo tenía en mi casa más software original que la empresa que me contrataba. Las ventajas son obvias: acceso a versiones recientes del software, acceso a soporte para el software. En una memorable ocasión tenía que hacer una tarea complicada en VB6 para un cliente (algo relacionado con códigos de barras y OCRs), y le ofrecí a mi gerente dos opciones: hacerla yo mismo y reinventar la rueda en el proceso, con las consecuentes incógnitas en cuanto a tiempo de desarrollo y resultado final; o comprar un componente de terceros para resolver el problema con garantías y rápido. Mi gerente encontró una tercera vía: descargarlo de eMule.
• Biblioteca.- El departamento de desarrollo debe disponer de una biblioteca técnica para uso de los miembros. Se puede hacer de varias formas: previa asignación de un presupuesto mensual, bimensual, semestral o al gusto; se podría designar un comité que se encargaría de recoger las necesidades del departamento (presentes y futuras) y comprar libros para cubrirlas. O confeccionar entre todos los desarrolladores una wishlist, en la cual cada persona podría sugerir títulos y votar los títulos sugeridos por los demás. Cada periodo de tiempo, los x títulos más votados hasta cubrir el presupuesto se compran, y se renueva el ciclo.
• Área de descanso.- Un área en la cual los programadores puedan relajarse, hablar con otros integrantes del equipo o sencillamente distraerse de lo que están haciendo. Cuando uno está encallado con algo que no sale, con un error que es capaz de ver; el truco más viejo del manual es ponerse inmediatamente a hacer otra cosa: salir a fumar un cigarrillo si se es fumador, acercarse a la máquina de bebidas, leer algo. Aunque aparentemente no estás pensando en el problema, es muy fácil tener un momento eureka cuando estás separado del mismo. O al volver del descanso, inmediatamente ves el problema con nuevos ojos y encuentras una solución que ahora parece obvia. En el área de descanso podrían estar los libros de la biblioteca, por ejemplo. Si se es muy generoso con el equipo, y si éste merece nuestra confianza, incluso podemos tener algo de material recreativo: una consola de videojuegos, una máquina de dardos. Y, por supuesto, máquina de refrescos gratuita.
• Proyectos personales.- Éste es un favorito personal mío. Cada viernes, todos los viernes, todos los integrantes del equipo de desarrollo dejan de realizar su trabajo normal. Cada programador tiene que elegir un proyecto personal para realizar durante las horas de trabajo del viernes, y a ser posible el proyecto personal no tiene que tener absolutamente nada que ver con el proyecto que está realizando de lunes a jueves. Cada desarrollador tiene completa libertad para elegir el proyecto que quiera, usando la tecnología que prefiera. Un reproductor de vídeo, una programa que compile recetas, un juego de Go, lo que sea. Si un programador no tiene una idea propia que quiera desarrollar, puede ofrecérsele una lista de los proyectos personales en curso para que se una al que prefiera, o puede unirse al proyecto de Open Source de su elección, o puede unirse al...
• Laboratorio de investigación.- Este equipo dedicará los viernes a investigar y probar nuevas tecnologías. No tienen porqué ser estrictamente nuevas, pero sí que tienen que ser nuevas para el equipo de desarrollo en su conjunto. Por ejemplo, si normalmente el equipo de desarrollo trabaja con ADO.NET, el laboratorio de investigación puede aprender a trabajar con NHibernate. Si normalmente se trabaja con el framework ASP.NET tal y como Microsoft lo presenta, se investiga con la implementación MVC de Castle. O se aprende Ruby On Rails. Al final de la investigación, el equipo será responsable de vender esa tecnología a los jefes de proyecto y gerentes, que decidirán si es aplicable a nuevos proyectos. En caso de serlo, el equipo de investigación dedicará un viernes (o los que hagan falta) a entrenar a otros compañeros en el uso de esa tecnología, según lo requiera el proyecto para el que se va a usar.

Lo sé. Muchos de los anteriores puntos son más adecuados a una software factory, cuando el grueso del trabajo de desarrollo en este país es en las instalaciones del cliente. Pero seguro que, con un poco de esfuerzo, el empresario creativo puede crear condiciones similares también para sus desarrolladores destacados en cliente.

Y no, esta lista no es una lista compuesta por un sindicalista radical, o un amargado picacódigos soñando despierto con una mejora de sus condiciones. Es una lista pensada con un solo objetivo en mente: ganar dinero. Prácticamente todos los puntos de la lista requieren una inversión por parte del empresario, cierto. Pero en muchos casos es una inversión que (debería estar) está asumida: equipos, mobiliarios y software original. El gasto extra en comprar equipos buenos, buen mobiliario y software original se compensa por la falta de pérdidas de tiempo, por la mejora en la concentración y la capacidad de trabajo de los desarrolladores, por el soporte añadido y el ahorro de tiempo en reinvenciones de rueda innecesarias. El presupuesto que un empresario tendría que desviar para permitir que su equipo compre libros o tenga bebidas gratis es ridículo comparado con los beneficios que se obtienen de su trabajo. Y todos los puntos de esta lista traen consigo unos beneficios adicionales nada desdeñables: mejora del conocimiento y preparación del equipo técnico, que lleva a una mejora de la calidad del software, que lleva a una mejor relación con los clientes, lo que lleva a conservar clientes y a conseguir mejores clientes por el siempre útil boca a oreja. Eso por un lado, por el otro todos estos puntos (unidos, por supuesto, a un salario y condiciones a la altura del mercado) traerían de la mano un índice de rotación bajísimo en el equipo de desarrollo. Y sí, señor empresario, ya sé que a usted el índice de rotación de los técnicos le trae al pairo: siempre hay más gente en Infojobs. Pero un equipo se hace con el tiempo, los buenos desarrolladores se hacen con el tiempo y no olvidemos que los clientes, que al fin y al cabo son los que nos dan de comer a todos, ven con muy malos ojos un alto índice de rotación en los equipos de desarrollo.

Incluso los puntos más aparentemente de ciencia-ficción como son los proyectos personales o el laboratorio de investigación son puntos que redundan directa, aunque quizás no obviamente, en beneficio de la empresa. Lo primero, son excelentes motivadores. Por lo menos, son motivadores para el tipo de trabajador que usted quiere en su empresa. Segundo, sus empleados aprenderán tecnologías y métodos que pueden serle útiles en sus próximos proyectos. Tercero, si alguno de sus programadores dedica tiempo pagado por usted a colaborar con un proyecto Open Source, eso puede convertirse en una buena fuente de publicidad para su empresa. Cuarto, ¿quién le dice a usted que el próximo YouTube no sale de un proyecto personal de uno de sus empleados?

Anímense, señores empresarios. Mejoren las condiciones laborales de sus desarrolladores. Ustedes también saldrán ganando.