Muchas veces las empresas de desarrollo y los departamentos de recursos humanos invierten muchísimo en formar a los equipos directivos para intentar mejorar la productividad, y eso está muy bien. No obstante, en muchos casos, esas mismas empresas obvian otros aspectos que minan la productividad de los programadores y que, en términos de inversión, son mucho más fáciles de asumir económicamente, ya que son hábitos que se pueden adquirir y fomentar desde recursos humanos y dirección. Lo que se necesita es tiempo y constancia. Se trata de formas de trabajar que deben ir incorporándose progresivamente a la cultura de cada organización.
Si te estás preguntando si todo esto justifica la inversión, sólo tienes que pensar en los sueldos de los desarrolladores. Por ejemplo, si se consigue un incremento del 10% en la productividad ya obtienes un retorno muy elevado.
En este artículo veremos 5 cosas que dañan la productividad de un programador en las empresas, en orden de mayor a menor en importancia y qué conductas se pueden incorporar en la compañía para evitarlas.
1.- Interrupciones, reuniones y distracciones varias
Las interrupciones son el mayor enemigo de la productividad para los desarrolladores. No es fácil para un desarrollador volver al punto en el que estaba justo antes de una interrupción. Necesita volver a entrar en "modo desarrollo" y luego, lentamente, retomar el hilo de lo que dejó para atender la interrupción.
Esto puede llevar fácilmente unos 10 minutos de media, y más de media hora en los casos más complejos. Y cuantas más interrupciones, más frustración, menos trabajo de calidad, más errores... y así sucesivamente.
Un programador con muchos años de experiencia me dijo una vez:
"Cuantas más veces me hagas parar cuando estoy tratando de empezar, más tiempo transcurrirá entre cada vez que lo intente. Si me llenas la mañana con interrupciones, no te extrañes al ver que el día resulta improductivo."
A partir de ese día mi forma de interactuar con él en horas de trabajo cambió. Le pedí que me dijera en qué momentos del día le podía interrumpir. Me ofreció dos ventanas horarias al día y problema solucionado.
¿Y las reuniones? La única diferencia entre una reunión y una interrupción es que una reunión es una interrupción planificada, lo que la hace aún peor.
A los desarrolladores les cuesta avanzar en una tarea si ya saben que tendrán una interrupción mientras trabajan en ella. Así que, si tienen una reunión en una o dos horas, no podrán hacer mucho progreso en nada, ya que la mayoría de las tareas de programación no triviales llevan más tiempo.
Desde recursos humanos se pueden adoptar medidas que fomenten estos comportamientos dentro de la empresa. Y sin coste alguno.
No hay excusas. Por ejemplo, celebrar breves reuniones al comienzo del día o justo antes de la comida, con el fin de evitar interrupciones innecesarias.
Relacionado con lo anterior, el entorno en el que trabajan los desarrolladores tiene un impacto importante en sus actividades. Si el espacio de trabajo está diseñado para tener tanto movimiento como sea posible, eso no les ayudará a concentrarse. Tener las pantallas de los ordenadores orientadas de tal manera que sean fácilmente visibles para los jefes crea un estrés extra y además ofrece más probabilidades de ser interrumpido.
Invertir en espacios de trabajo, monitores grandes, y accesorios que a día de hoy ya son indispensables para cualquier programador (como auriculares de cancelación de ruido) son un plus que hace subir exponencialmente la productividad.
2.- Microgestión
Entre los diferentes clases de gestión, los microgestores quizás sean los peores en cuanto a la productividad del desarrollador. De hecho, los microgestores tienden a celebrar más reuniones y a hacer más interrupciones no previstas.
Pero no es sólo eso. Exhiben falta de confianza y, al hacerlo, los desarrolladores sienten que socavan constantemente sus habilidades y su capacidad para hacer las cosas. Toda la motivación que un desarrollador tenía entre las interrupciones simplemente se irá en ese momento.
El impacto va más allá de la productividad. Los microgestores quizás sean la primera razón para que los desarrolladores se vayan de una empresa o, como mínimo, para que cambien de equipo.
Cambiar este tipo de gestión es muy difícil y exige mucho esfuerzo por parte de todos los miembros implicados. También exige mucho trabajo a la hora de reclutar personal.
Lo cierto es que hay perfiles que solo saben trabajar si los microgestionas, es una realidad. Si la empresa quiere huir de esto tiene que incorporar perfiles que se sepan autogestionar y que sirvan de ejemplo a otros.
Por otro lado, la empresa debe asignar de forma pactada objetivos con todos los miembros de la empresa y controlar el trabajo midiendo resultados y no dictando o contando tareas.
No es imposible cambiar, pero sí reconozco que es muy difícil y que lleva mucho tiempo -años-, esfuerzo colectivo y constancia.
3.- Imprecisión y falta de detalle en la información
Hay muchas maneras de ilustrar la imprecisión. Los informes de errores como "¡Tiene un bug, arréglalo!" no contienen la suficiente información como para que los desarrolladores trabajen en ello. Por cierto, disponer de una plantilla de informe de errores puede ayudar en ese caso.
O una especificación poco clara de una característica, en cuyo caso los desarrolladores comenzarán a implementar lo que les parezca adecuado para poco después tener que empezar de nuevo desde cero una vez que la persona responsable detalle mejor el funcionamiento esperado.
La falta de claridad en las prioridades también entra en esta sección. El tiempo que un desarrollador invierte en preguntarse si está trabajando en la tarea apropiada puede evitarse fácilmente. Y si alguna vez reciben un comentario del jefe preguntando por qué trabajaron en esta tarea en particular y no en otra (cuando las prioridades no estaban definidas)... bueno, ya sabes, les genera mucha frustración.
Los mismo se puede decir de las especificaciones y el alcance del proyecto. Toda esa información debe quedar clara antes de empezar el proyecto y en ningún caso deben alterarse sin prolongar los plazos.
La tendencia es que los jefes pidan estimaciones a los desarrolladores del tiempo que van a tardar en hacer x cosas, luego los presionen para que bajen el tiempo de esas estimaciones lo más posible, y luego en su mente se crean la expectativa de que se cumplan por arte de magia esos plazos impuestos.
Algunos jefes considerarán incluso que, como los propios desarrolladores "determinaron" la estimación el plazo, ya implícitamente se comprometieron a cumplir los plazos y, por lo tanto, estos deben considerarse suficientemente válidos para ser comunicados a la alta dirección.
Nunca se puede equiparar un estimación con un plazo. Cualquier estimación que haga un programador debe incrementarse al menos un 30% más. Si dicen dos semanas, serán tres. Si dicen 40 días, échale 60. Hay imprevistos, errores, I+D, detalles que parecían más sencillos, etc...
Por último, si un equipo de desarrollo de producto define las prioridades del software sin haber validado nunca el atractivo y el beneficio de las características correspondientes (a través de las opiniones de los clientes o por cualquier otro medio), y los desarrolladores observan que la mayoría de las características simplemente no se utilizan, sentirán que lo que hacen es inútil y dejarán de estar motivados de cara a seguir mejorando y manteniendo ese software.
Para solucionar esto es recomendable que la labor del jefe de proyecto se rija siguiendo metodologías ágiles, con sprints, iteraciones y demás.
Implementar esta forma de trabajo es un cambio cultural muy grande y el camino está lleno de baches. Las empresas de desarrollo que lo consiguen ganan muchísima productividad y calidad en el software.
4.- La gestión estilo gaviota
Es un estilo de gestión que consiste en interactuar con los miembros del equipo para abroncarlos y solo cuando hay problemas. De ahí la metáfora con la gaviota: viene, sobrevuela, hace sus necesidades y se marcha 😆
"Esto está mal, y esto, y esto se ve fatal", etc. Este comportamiento es profundamente frustrante para los desarrolladores; no podrán volver a recuperar la concentración y motivación plena en las próximas horas, y a veces tardan hasta días.
Los equipos de desarrollo necesitan un estilo de gestión más horizontal. Necesitan sentirse importantes, escuchados y también tiene que tener un margen de libertad para poder trabajar. Ser reconocidos en público y recibir reprimendas en privado.
En este sentido la empresa y los departamentos de recursos humanos juegan un papel importante. Promover e implementar un sistema de gestión más horizontal no es fácil y exige un sistema de control y de digitalización que garantice que todos los indicadores clave de la empresa se puedan monitorizar a diario sin necesidad de estar todo el día pidiendo informes, a modo de panel de control de los KPI's de la empresa.
5.- Acaparar el mérito de otros
¿Alguna vez has tenido un jefe que se haya llevado todo el mérito y el reconocimiento por el trabajo que has hecho tú? 🤔
Esto es algo que desmoraliza totalmente a cualquier trabajador, incluyendo a los programadores. Los desarrolladores valoran la competencia y capacidad profesional ante todo.
Asumir el mérito de otros y recibir el reconocimiento que le corresponde a los demás es expropiar la competencia profesional de un compañero, quitársela y para que otro se cuelgue una medalla. Tanta tensión destruye la productividad de los desarrolladores por un tiempo.
Los departamentos de recursos humanos tienen que detectar este tipo de situaciones en el momento que se producen y dar el reconocimiento a cada programador. No hay nada peor que tener un equipo de programadores desmotivados por culpa de un jefe que usurpa los logros del resto.
El mayor logro de cualquier gestor es que su subordinados conquisten los más grandes hitos y reciban el reconocimiento que merecen por ello.
Conclusión
Si reconoces algunos de los puntos mencionados anteriormente dentro de tu empresa, podría ser interesante abordarlos con tus desarrolladores. Habla con ellos; averigua si representan realmente un problema y la forma en que pueden ser resueltos. Digan lo que digan, lo más importante es confiar en sus comentarios y opiniones.
No se puede hacer caso omiso del factor humano cuando se analiza la productividad del equipo. Hay que iterar los procesos, el entorno y los hábitos de trabajo de manera conjunta con el equipo, y dejar que ellos orienten las decisiones de cómo tener la mayor productividad e impacto.
Fecha de publicación: