Reunión MadriAgil 24/11/2010

¡Después de un tiempo de descanso vuelvo al ataque!

Hoy os traigo un resumen de lo que pasó el miércoles 24 de Noviembre en la reunión de MadriAgil.

Antes de empezar hubo un cambio de última hora dado que la reunión se iba a hacer en las oficinas del Vivero pero como el anfitrión se encontraba enfermo cambiamos el lugar a las oficinas de IPSA.

El tema que se había propuesto para la reunión era hablar sobre la primera parte del libro Peopleware, y aunque algunos no llevábamos todos los deberes hechos, íbamos con tantas ganas como siempre de escuchar, aprender e intercambiar opiniones.

En esta reunión me acompañaron Arturo(@ArturoHerrero), Jerónimo(@jerolba), Alberto Peña(@plagelao),  Raquel(@rlaina), Marcin, José Luis(@reemplazable) y Jose Manuel Beas(@jmbeas).

Empezamos con un resumen muy escueto para contextualizar el libro. Escrito en 1987 por los consultores Tom DeMarco y Timothy Lister habla de cómo gestionar a las personas en una empresa. Se cuentan fallos detectados por los autores explicados con historias concretas y se van proponiendo posibles medidas a tomar.

El término Peopleware, como puede leerse en esta entrada de la Wikipedia, se utiliza para referirse a cualquier cosa que tenga que ver con las personas en el desarrollo o uso de software y sistemas hardware.

Y la mejor forma de empezar a abordarlo nos pareció ir por cada capítulo, resumiendo un poco la idea general que aporta y discutiendo sobre ella.

En la introducción de la primera parte se presenta la teoría de que muchos de los problemas se producen porque las personas que gestionan tienden a adoptar las mismas medidas que ya conocían con las personas. Se planteó que esta problemática viniera dada porque las personas que gestionan vienen de la rama técnica, debido a cosas como la gestión de carrera que hay en España, donde llegado a un punto, para seguir ascendiendo un técnico tiene que dejar de ser técnico para pasar a ser gestor. Sobre este punto surgieron discrepancias ya que algunos de los asistentes apoyaban esta idea, mientras que otros alegaban que, al menos en su experiencia, las personas que se habían encontrado en puestos de gestión no tenían experiencia previa en puestos técnicos.¿Qué opinais vosotros?¿Cuál es vuestra experiencia?

En el capítulo 1 se expone la gran cantidad de proyectos que fracasan. Si se analizaran las causas de muchos de los fracasos, cosa para la que nunca hay tiempo porque siempre hay cosas más urgentes, se comprobaría que la mayoría no han sido producidos por problemas tecnológicos, sino por problemas sociológicos que habría que abordar mediante habilidades sociales. Y es que, al contrario de lo que muchos piensan, ¡no trabajamos con alta tecnología! La mayoría de nosotros nos limitamos a trabajar utilizando el trabajo de aquellos que sí están en la cima de la tecnología.

Del capítulo 2 la idea principal es que esto es desarrollo de Software, no un McDonald, y la forma de gestionarlo no puede ser igual. En entornos tipo cadena de producción lo que se necesita es hacer y vender rápido, con gente altamente reemplazable, donde todo se hace siguiendo unas instrucciones sin necesidad de creatividad. Pero si se aplica la misma mentalidad en un área de desarrollo sólo se conseguirá minar el espíritu del equipo.¿Y cómo se puede mejorar la cultura de empresa? Pues hay algunas pautas que habría que seguir:

1. Permite fallos, no presiones a la gente para que no los cometa. Hay que fomentar que la gente no busque culpables en los demás, que asuma sus errores. Pero hay que tratar con cuidado el tema de los fallos, porque también hay que fomentar que se aprenda de los errores no dejar que se cometan una y otra vez.
2. Los trabajadores no son piezas completamente reemplazable. Reemplazar a un trabajador en entornos de desarrollo de software tiene un coste que hay que tener en cuenta, pero una empresa no puede morir porque se vaya uno de sus trabajadores, por lo que es necesario que se comparta el conocimiento.
3. En proyectos de desarrollo no existe un estado estacionario que no sea de rigor mortis. Además, no se puede medir el valor que las personas aportan a un proyecto únicamente midiendo características como la cantidad de código que escriben o cuánta documentación han escrito.
4. Otro punto a tener en cuenta es que no todo el tiempo puede ir dedicado a hacer algo, porque, si dedicas todo tu tiempo a eso, ¿qué tiempo le dedicas a pensar en lo que tienes que hacer? Es necesario dejar tiempo para investigar, probar o leer libros.

En el capítulo 3 se habla de la productividad, un tema siempre presente en cualquier equipo de desarrollo. Sobre este tema las ideas que nos surgieron es que muchos gestores se encargan de buscar la forma de ganar batallas haciendo que los trabajadores intenten cumplir con entregas imposibles, sin pasarse del presupuesto (muchas veces a costa de horas extras gratis), cumpliendo con su labor de atender al cliente… pero al final pierden guerras porque acaban perdiendo a esos empleados, perdiendo con ellos el conocimiento adquirido. Me gusta cuando se dice en el libro que la gente bajo presión no trabaja mejor, sólo trabajan más rápido, y para ello hay que saccrificar o bien calidad del servicio o bien calidad de trabajo de los propios empleados.

¿Y por qué en la mayoría de las empresas de España se cuida tan poco al personal cuando son una parte tan importante del negocio?

A veces también da la sensación de que sólo se mide el coste del desarrollo inicial perdiendo visión del coste total que se incrementa en gran medida cuando empiezan a aparecer los bugs y son necesarios los mantenimientos.

Todo esto viene por vender tiempo de desarollo en lugar de vender un servicion. En este punto Marcin nos aportó un punto interesante de vista con su experiencia en Alemania y es que allí vendían un desarrollo, no a x personas trabajando x tiempo y la calidad no queda en manos del cliente que pueda elegir si quiere que trabajen 4 becarios y 2 analistas o 1 becario y 3 analistas, quien da el servicio establece la calidad, el cliente únicamente decide si compra el servicio o no.

Y continuando con el tema de la calidad llegamos al capítulo 4, “Calidad, si el tiempo lo permite”. Y es que esa es la actitud que nos encontramos en nuestros entornos mayoritariamente. Si el tiempo apremia, ¿qué podemos dejar de hacer?¡Las pruebas y las refactorizaciones! Quizás hubiera sido bueno que hubiera gente de las ‘altas esferas de gestión’ que quizás hubiera aportado algún otro punto de vista, porque todos los asistentes estábamos de acuerdo en que la calidad no puede negociarse ni pasarse por alto. Por ello, en lugar de seguir discutiendo sobre eso, enfocamos el tema desde el lado de cómo conseguir que se valore la calidad porque a la mayoría de los clientes no puedes hablarles de tu artesanía y la forma más efectiva parece llevarlo al terreno del dinero y mostrar por qué de una forma y otra ganas o pierdes dinero.

El último capítulo del que discutimos fue el capítulo 5 que versa sobre la ley de Parkinson la cual afirma que “el trabajo se expande hasta llenar el tiempo disponible para que se termine”. Pero poniendo fechas límite no se consigue que personas que no pueden realizar las tareas por falta de competencia, falta de confianza o falta de afiliación con otras personas del proyecto o con los objetivos de este vayan a rendir más. Además, presenta estudios donde se demuestra que cuando son los propios programadores quienes ponen las fechas la productividad aumenta frente a proyectos en los que las fechas vienen impuestas.

Así que con todas estas cosas en la cabeza dimos por terminada la reunión para ir a tomar unas cañitas y seguir discutiendo sobre temas varios. Para más información lo mejor es leerse el libro, que es cortito pero tiene mucho que aportar.

¡Así fueron las cosas y así se las he contado! :p