Generalmente, lo que se hace en estas situaciones es tomar un par de medidas absurdas como cortar el acceso a Internet, establecer una jornada de trabajo de 12 horas u obligar a los desarrolladores a tomar clases de mecanografía para que escriban más rápido. Otras opciones requieren más trabajo. Por ejemplo, hablar y actuar sobre productividad con conocimiento de causa. Si esa es la opción que uno desea tomar, un buen comienzo es comenzar a leer sobre el tema.
Tom DeMarco y Timothy Lister han estudiado durante años los factores que afectan la productividad en nuestra industria y han escrito un libro con los resultados de su investigación y sus conclusiones: Peopleware: Productive Projects and Teams.Los temas tratados son variados pero todos muy presentes en nuestra realidad. Por ejemplo, las horas extra.
Nuestra actividad parece estar marcada a fuego por el trabajo en horas extra. Nos cuesta pensar en un proyecto sin ellas. Muy a menudo estas vienen acompañadas de la falta de una justificación convincente y de un gerente de pocas luces que piensa que este coctel infalible para derrumbar la moral de cualquier equipo de desarrollo puede de alguna manera aumentar la productividad. DeMarco y Lister escriben al respecto:
"Las horas extra son una fantasía de la imaginación del gerente ingenuo. Oh, puede existir cierto beneficio en horas extra trabajadas el sábado para cumplir con la entrega del lunes, pero esto es casi siempre seguido por un periodo igual de horas menos compensatorias mientras los empleados se ponen al día con sus vidas... Realmente nadie puede trabajar mucho más de cuarenta horas [semanales], al menos no de manera continua y con el nivel de intensidad requerida para el trabajo creativo"
Una característica remarcable del libro son la cantidad de datos empíricos que forman la base de las conclusiones expuestas. Muchos de estos datos surgen de los Coding War Games, una serie de competencias para completar tareas de programación y testing en un tiempo mínimo y con defectos mínimos que DeMarco y Lister organizaron durante años. Estos juegos demostraron consistentemente algunos cuestiones importantes relacionadas con la productividad. Por ejemplo, que los mejores programadores son 10 veces más productivos que los peores.
Pero demostraron algo más interesante: las variaciones de productividad están más relacionadas con las características del espacio físico de trabajo que con lenguajes de programación utilizados, años de experiencia, salario u otro factor.
Por ejemplo, los desarrolladores más productivos en las Coding Wars contaban en su lugar habitual de trabajo con un espacio físico promedio de 7,25 m2. Los peores contaban con sólo 4,25 m2.
En relación a este tópico DeMarco y Lister cuentan:
"Antes de diseñar los planes iniciales para sus nuevas oficinas en Santa Teresa, IBM violó todos los estandares de la industria estudiando cuidadosamente los habitos de trabajo de las personas que ocuparían ese espacio... "
El arquitecto que se encargó de estos estudios determinó que las características mínimas del espacio eran las siguientes:
- 9,3 m2 de espacio dedicado a cada trabajador.
- 2,8 m2 de superficie de trabajo (escritorios) por cada trabajador.
- Protección de ruido en forma de oficinas cerradas o particiones de 1,80 m de alto.
DeMarco y Lister concluyen:
"De hecho IBM siguió las recomendaciones y construyó un lugar de trabajo donde las personas pueden trabajar. (Predecimos que esta compañía llegará lejos)"
Resumiendo, la experiencia de los autores indica que los aspectos físicos y sociales de un grupo de desarrollo de software de primera linea debe incluir varios de los siguientes factores:
* Adecuado espacio silencioso y privado para cada desarrollador con un escritorio amplio.
* Areas comunes de fácil acceso para discusiones espontaneas de pequeños grupos sin que estas molesten a los demás desarrolladores
* Un entorno que posibilite minimizar las interrupciones a los desarrolladores cuando lo deseen.
* Planificaciones que permitan a los miembros de un proyecto "tener una vida" fuera del trabajo.
* Posibilidad de los desarrolladores para configurar y reconfigurar su entorno físico para adaptarlos a sus necesidades actuales.
Por supuesto, hablamos de un grupo de desarrollo de software de primera línea. No todos son capaces de aspirar a tener uno en su empresa.
Si alguien se presenta a hacer planteos y sugerencias sobre la productividad de un equipo de desarrollo de software, se puede saber si sólo busca a alguien a quien cargarle la culpa de sus males o si le interesa seriamente el tema, haciendo una simple pregunta: ¿has leído Peopleware?
