12 cosas que perturban la productividad de los desarrolladores

En Cloud Custom Solutions, contratamos a muchos desarrolladores para todos nuestros proyectos multifacéticos, por lo que pensamos que vale la pena leer este artículo.

Nadie espera que un programador haga su trabajo sin tener acceso a un ordenador, pero hay muchas empresas que esperan que los programadores hagan su trabajo sin tener acceso a su mente. Esto es igualmente irreal.

Así que vamos a profundizar en nuestra lista de 12 cosas que impiden a sus desarrolladores entrar en la zona y ser productivos. Intentaré priorizar esta lista de mayor a menor impacto. No dude en comentar.

Si te preguntas si todo esto merece la pena, sólo tienes que tener en cuenta los sueldos de los promotores. Incluso un 10% más de productividad es MUCHO.

1) Interrupciones y reuniones 

En mi opinión, las interrupciones son el principal factor de pérdida de productividad para los desarrolladores. Los desarrolladores no pueden volver fácilmente a donde estaban justo antes de una interrupción. Tienen que entrar en la mentalidad del desarrollo y luego volver poco a poco a donde lo dejaron. Esto puede llevar fácilmente más de 30 minutos. Y cuantas más interrupciones, más frustración, menos trabajo de calidad, más fallos… y así sucesivamente.

«Cuantas más veces me hagas tropezar mientras intento empezar, más tiempo pasará entre cada vez que lo intente. Si llenas mi mañana con interrupciones – no te sorprendas cuando el día sea improductivo». -un desarrollador en Reddit

¿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. Los desarrolladores no pueden avanzar en una tarea si saben que tendrán una interrupción mientras trabajan en ella. Así, si tienen una reunión en una o dos horas, no podrán avanzar en nada, ya que la mayoría de las tareas de ingeniería requieren más tiempo.

Como escribió Paul Graham, «una sola reunión puede echar a perder toda una tarde al dividirla en dos partes, cada una de ellas demasiado pequeña para hacer algo difícil».

¿Cómo se puede evitar esto? Esta parte está bien documentada; no tienes excusa. Celebre breves reuniones de estado al principio de la jornada o justo antes del almuerzo, por ejemplo, para evitar interrupciones innecesarias.

2) Microgestión

De los diferentes tipos de gestores, los microgestores pueden ser los peores en cuanto a la productividad de los desarrolladores. Por supuesto, los microgestores tienden a tener más reuniones e interrupciones imprevistas. Pero no es sólo eso. Muestran una falta de confianza y, al hacerlo, sientes que socavan constantemente tus habilidades y tu capacidad para hacer las cosas. Cualquier motivación que un desarrollador tuviera entre las interrupciones se esfumará en ese momento. El impacto va más allá de la productividad. Los microgestores pueden ser la primera razón por la que los desarrolladores se marchen o, como mínimo, cambien de equipo.

3) Vaguedad

Hay muchas formas de ilustrar la vaguedad. Los informes de errores del tipo «¡Está roto, arréglalo!» no tienen suficiente información para que los desarrolladores trabajen a partir de ella. Por cierto, tener una plantilla de informe de errores puede ayudar en ese caso.

O una especificación poco clara sobre una característica, en cuyo caso los desarrolladores comenzarán a implementar lo que les parezca correcto antes de tener que empezar de nuevo desde cero una vez que el gestor detalle mejor el comportamiento esperado.

El establecimiento de prioridades poco claras también pertenece a esta categoría. El tiempo que un desarrollador pasa preguntándose si está trabajando en la tarea correcta puede evitarse fácilmente. Y si alguna vez reciben un comentario del gerente preguntando por qué han trabajado en esta tarea en particular (mientras que las prioridades no estaban definidas)… bueno, lo entienden: mucha frustración…

4) Gestión de la gaviota

¿Has oído hablar de ella? Ocurre cuando los directivos se desentienden totalmente del trabajo, pero… se abalanzan de vez en cuando para cagarlo todo. «Esto está mal, y esto, y esto tiene mala pinta», etc., antes de volver a volar. Tengo que admitir que me ha encantado la imagen, pero desgraciadamente, esto ocurre más a menudo de lo que nos gustaría. Este comportamiento es profundamente frustrante para los desarrolladores; no podrán volver a la zona en las próximas horas, y a veces ni siquiera durante días.

5) Avaricia crediticia

¿Has tenido alguna vez un jefe u otro promotor que se haya llevado todo el mérito del trabajo que has hecho en las últimas semanas? Los desarrolladores valoran la competencia por encima de todo. Tomar el crédito de otra persona es tomar la competencia del otro para ti y quitársela. Esto está muy arriba en mi lista, ya que creo que crea tanta tensión que acaba con la productividad de los desarrolladores durante un tiempo.

6) Entorno – Ruidos, movimiento, diseño del espacio de trabajo…

Esto puede parecer extraño para los que no son programadores, pero el entorno en el que trabajan los desarrolladores tiene un impacto importante en sus actividades. Por ejemplo, tener un poco de ruido blanco -un aire acondicionado fuerte, oír pasar coches y camiones- les ayuda a concentrarse mejor. Por eso muchos de nosotros nos ponemos auriculares. Acabo de descubrir RainyMood, ¡estupendo!

Del mismo modo, si el espacio de trabajo está diseñado para tener el mayor movimiento posible, eso no les ayudará a concentrarse. O tener las pantallas de los ordenadores de sobremesa orientadas de tal manera que sean muy visibles para los directivos… bueno, eso crea algo de estrés adicional y aún más oportunidades de ser interrumpido.

7) La escalada del alcance

En la gestión de proyectos, la fluencia del alcance (también llamada fluencia del enfoque, fluencia de los requisitos, fluencia de las características y, a veces, síndrome del fregadero) se refiere a los cambios incontrolados en el alcance de un proyecto. Esto puede ocurrir cuando el alcance de un proyecto no está correctamente definido, documentado o controlado.

El «Scope creep» convierte peticiones relativamente sencillas en monstruos terriblemente complejos y que consumen mucho tiempo. Y la mayoría de las veces ocurre durante el desarrollo. Por ejemplo, para una función sencilla:

• Versión 1 (antes de la implementación): la característica es «Mostrar un mapa de la ubicación»
• Versión 2 (cuando la versión 1 está casi terminada): la característica se cambia a «Mostrar un mapa 3D de la ubicación»
• Versión 3 (cuando la versión 2 está casi terminada): la característica se cambia de nuevo a «Mostrar un mapa 3D de la ubicación por la que el usuario puede volar»

8) Proceso de definición del producto

Este tema puede parecer extraño a primera vista, pero en realidad es bastante fácil de entender. Si un equipo de producto define las prioridades de su equipo sin validar nunca (mediante el feedback de los clientes o cualquier otro medio) el interés de las características correspondientes, y los desarrolladores ven que la mayoría de las características finalmente no se utilizan, sentirán que lo que hacen es inútil y perderán su motivación. Todos queremos sentirnos impactados, y eso puede ser aún más importante para los desarrolladores.

9) Falta de consideración de la deuda técnica

 La deuda técnica es una decisión deliberada de implementar una solución que no es la mejor o de escribir un código que no es el mejor para lanzar el software más rápido. Asumir cierta deuda técnica es inevitable y puede aumentar la velocidad del desarrollo de software a corto plazo. Sin embargo, a largo plazo, contribuye a la complejidad del sistema, lo que ralentiza a los desarrolladores. Los no programadores suelen subestimar la pérdida de productividad y tienen la tentación de avanzar siempre, y eso se convierte en un problema.
 Pero si la refactorización nunca forma parte de las prioridades, no sólo afectará a la productividad sino también a la calidad del producto.

10) Multiplicidad de herramientas y hardware 

Los desarrolladores utilizan cada día muchas herramientas para programar, empujar y fusionar su código. Cuanta más automatización, mejor. Ni que decir tiene que si utilizas herramientas «antiguas», esto repercutirá en tu productividad. Del mismo modo, tener una pantalla grande frente a sólo un portátil puede tener un impacto. Teniendo en cuenta el coste del hardware y el salario del desarrollador, tener sólo un 5% de aumento de la productividad merece sin duda cualquier inversión en ese sentido. Sólo tienes que dar las herramientas y el hardware que tu equipo de desarrolladores prefiere (individualmente para el hardware, pero como grupo para las herramientas).

11) Documentación sobre el «cómo»

Cuando aprendíamos a codificar, nos decían que comentáramos pronto y a menudo. La idea es que es mejor tener muchos comentarios que tener pocos. Desgraciadamente, muchos programadores interpretan incorrectamente que deben comentar cada línea de código, por lo que a menudo vemos código como éste (del post de Jeff Atwood sobre «Codificación sin comentarios»):

r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)}

¿Tienes idea de lo que hace este código? Yo tampoco. El problema es que aunque hay muchos comentarios que describen lo que hace el código, no hay ninguno que describa por qué lo hace. Si hubiera un error en el programa y te encontraras con este código, no sabrías por dónde empezar.

12) Plazos de entrega imposiblemente ajustados

Esto último está relacionado con la tendencia de los directivos a pedir estimaciones a los desarrolladores, para luego presionarles para que bajen esas estimaciones lo máximo posible, ¡y luego considerarlas mágicamente como plazos! Los directivos incluso considerarán que, como los propios desarrolladores «decidieron» la estimación, se comprometieron con los plazos y, por tanto, éstos deben considerarse lo suficientemente válidos como para compartirlos con la alta dirección.

No es de extrañar que los desarrolladores sientan que esos plazos son poco razonables y arbitrariamente ajustados, lo que genera tensión e incapacidad para concentrarse.

¿Cómo es que todas esas cosas son exclusivas de los desarrolladores? Si se observan las 12 cosas, en realidad son bastante comunes a la mayoría de los otros trabajos basados en proyectos. Pero el impacto de cada uno de ellos es aún más importante para los desarrolladores, ya que necesitan una profunda concentración para progresar en sus tareas.

Si reconoce algunos de los puntos mencionados anteriormente en su empresa, podría ser interesante abordarlos con sus desarrolladores. Habla con ellos; averigua si son un problema y cómo se puede resolver. Digan lo que digan, lo más importante es confiar en sus comentarios y opiniones. Y aunque la tecnología actual es muy diferente a la de hace 30 años, la lección sigue siendo la misma. No se puede ignorar el factor humano cuando se considera la productividad del equipo. Repasa tus procesos, tu entorno y tus hábitos de trabajo con tu equipo, y deja que te guíen sobre cómo tener la mayor productividad e impacto.