Las 10 Cosas Que Destruyen La Productividad De Los Desarrolladores

Muchos artículos abordan el papel de los líderes tecnológicos y los gerentes de ingeniería. Un tema común con el que nos encontramos a menudo es cómo aumentar la productividad de un equipo. Pero antes de enfocar su energía tratando de aumentar su productividad, es posible que primero desee considerar qué lo está destruyendo, para tener una base sólida sobre la que pueda construir. Desafortunadamente, a pesar de que Peopleware se publicó hace casi 30 años, vemos que muchos equipos sufren una gran pérdida de productividad de algunas maneras (negativas) notables.

Nadie espera que un programador haga su trabajo sin acceso a una computadora, pero hay muchas compañías que esperan que los programadores hagan su trabajo sin acceso a su mente. Esto es igualmente irreal.

Así que profundicemos en nuestra lista de 10 cosas que impiden que sus desarrolladores se “metan en la zona” y sean productivos. Trataré de priorizar esta lista de la más a la menos impactante. Siéntase libre de comentar!

Si se pregunta si todo esto vale la pena la inversión, solo considere los salarios del desarrollador. ¡Incluso un 10% más de productividad es MUCHO!

1) Interrupciones y reuniones
En mi opinión, las interrupciones son el principal asesino de la productividad para los desarrolladores. Los desarrolladores no pueden volver fácilmente a donde estaban justo antes de una interrupción. Necesitan entrar en la mentalidad para el desarrollo y luego volver lentamente 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 errores, y continúa.

“Cuantas más veces me tropieces mientras estoy tratando de comenzar, más tiempo pasaré entre cada vez que lo intente. Si llenas mi mañana de 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 empeora aún más. Los desarrolladores no pueden progresar en una tarea si saben que tendrán una interrupción mientras trabajan en ella. Por lo tanto, si tienen una reunión en una o dos horas, no podrán progresar 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 arruinar una tarde entera al dividirla en dos partes, cada una demasiado pequeña para hacer algo difícil.”

¿Cómo se puede evitar esto? Esta parte está bien documentada, no tienes excusa. Organice reuniones breves de estado al comienzo del día o justo antes del almuerzo, por ejemplo, para evitar interrupciones innecesarias.

2) Microgestión
De los diferentes tipos de gerentes, los micro gerentes pueden ser los peores en términos de productividad de los desarrolladores. Claro, los microgestores tienden a tener más reuniones e interrupciones no planificadas. Pero no es solo eso. Muestran falta de confianza y, al hacerlo, sientes que constantemente socavan tus habilidades y tu capacidad para hacer las cosas. Cualquier motivación que un desarrollador tuviera entre interrupciones desaparecerá 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 van, o al menos, cambian de equipo.

3) Vaguedad
Hay muchas maneras de ilustrar la vaguedad. Informes de errores como “¡Está roto, arréglalo!”no tengo suficiente información para que los desarrolladores trabajen. Por cierto, tener 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 correcto, antes de tener que comenzar de nuevo desde cero una vez que el administrador detalle mejor el comportamiento esperado.

La priorización poco clara también pertenece a esta categoría. El tiempo que un desarrollador pasa preguntándose si está trabajando en la tarea correcta se puede evitar fácilmente. Y si alguna vez reciben un comentario del gerente preguntándoles por qué trabajaron en esta tarea en particular (mientras que las prioridades no estaban definidas)well bueno, lo entiendes — mucha frustración…

4) Gestión de Gaviotas
¿Alguna vez has oído hablar de él? Sucede cuando los gerentes no están involucrados en el trabajo, pero just se abalanzan de vez en cuando para cagar por todo. “Esto está mal, y esto, y esto se ve mal”, etc., antes de volar de nuevo. Tengo que admitir que me encantó la imagen, pero desafortunadamente, esto sucede 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
¿Alguna vez ha tenido un gerente u otro desarrollador que se llevó todo el crédito por el trabajo que ha realizado en las últimas semanas? Los desarrolladores valoran la competencia por encima de todo. Tomar el crédito de otra persona es tomar la competencia de la otra persona para ti y quitársela a él o ella. Esto es bastante alto en mi lista, ya que siento que crea tanta tensión que simplemente destruye la productividad de todos los desarrolladores durante bastante tiempo.

6) Entorno: Ruidos, Movimiento, Diseño del Espacio de Trabajo…
Esto puede parecer extraño para los no 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 (aire acondicionado ruidoso, escuchar pasar automóviles y camiones) les ayuda a concentrarse mejor. ¡Es por eso que muchos de nosotros nos ponemos auriculares! De hecho, acabo de descubrir RainyMood, ¡realmente genial 👍!

Del mismo modo, si el espacio de trabajo está diseñado para tener la mayor cantidad de movimiento posible, ¡eso no los ayudará a concentrarse! O tener las pantallas de las computadoras de escritorio orientadas de tal manera que sean altamente visibles para los gerentes well bueno, eso crea un estrés adicional y aún más oportunidades de ser interrumpido.

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

Scope creep convierte solicitudes relativamente simples en monstruos horriblemente complejos y que consumen mucho tiempo. ¡Y la mayoría de las veces sucede durante el desarrollo! Por ejemplo, para una función simple:
Versión 1 (antes de la implementación): la función es “Mostrar un mapa de la ubicación”
Versión 2 (cuando la versión 1 está casi terminada): la función se cambia a “Mostrar un mapa 3D de la ubicación”
Versión 3 (cuando la versión 2 está casi terminada): la función se cambió nuevamente a “Mostrar un mapa 3D de la ubicación por la que el usuario puede volar”

8) Proceso de Definición de Producto
Así que este 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 (a través de los comentarios 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 a la Deuda Técnica
La deuda técnica es una decisión deliberada de implementar una solución que no es la mejor o escribir un código que no es el mejor para lanzar software más rápido. Asumir cierta deuda técnica es inevitable y puede aumentar la velocidad en el desarrollo de software a corto plazo. Sin embargo, a la larga, contribuye a la complejidad del sistema, lo que ralentiza a los desarrolladores. Los no programadores a menudo subestiman la pérdida de productividad y se sienten tentados a avanzar siempre, y eso se convierte en un problema.
Pero si la refactorización nunca es parte de las prioridades, no solo afectará la productividad sino también la calidad del producto.

10) Multiplicidad de herramientas y hardware
Los desarrolladores utilizan muchas herramientas para programar, insertar y fusionar su código todos los días. Cuanta más automatización, mejor. No hace falta decir que si usa herramientas “antiguas”, esto afectará su productividad. Del mismo modo, tener una pantalla grande frente a solo una computadora portátil puede tener un impacto. Dado el costo del hardware y el salario del desarrollador, tener solo un aumento de productividad del 5% definitivamente vale la pena cualquier inversión en ese punto. Solo proporcione las herramientas y el hardware que prefiera su equipo de desarrolladores (individualmente para el hardware, pero como grupo para las herramientas).

Add Comment