5 cosas que matan la productividad de un desarrollador. En este post me gustaría compartir con ustedes algunas de las secciones de un artículo que leí hace poco tiempo, con el cual en ciertos puntos coincido. Creo que vale la pena que lo lean, porque estoy seguro de que a muchos les interesará también.

El artículo original al cual me refiero está escrito en inglés (https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190), y menciona las 12 cosas que destruyen la productividad de un desarrollador. Sin embargo, y con el fin de que este post no sea tan extenso, voy a mencionar solamente 5 de los 12 factores que se mencionan en dicho artículo (los que consideré de mayor importancia). En ciertos pasajes voy a intentar traducir al español algunas de las frases que menciona el autor del artículo, así que me disculpo por adelantado si mi traducción no es exactamente fiel a lo que dice en el texto original.
Muchos autores se dedican a investigar sobre cuáles son los diversos factores que hacen que la productividad de un equipo de desarrollo aumente, pero muy pocos se enfocan en analizar aquellos aspectos o prácticas de trabajo que provocan la pérdida de la productividad.

Interrupciones y reuniones

El autor del artículo es crítico en este punto, y afirma que las interrupciones son las asesinas por excelencia de la productividad de un desarrollador. Esto es así porque los desarrolladores no pueden retomar fácilmente la tarea que estaban llevando a cabo justo antes de que se produjera la interrupción, siendo necesario reconstruir mentalmente todo lo que estaban haciendo hasta llegar al punto en el cual abandonaron el desarrollo. El proceso de reconstrucción puede llevar fácilmente unos 30 minutos de tiempo, y un aumento en la cantidad de interrupciones traerá aparejado el aumento de la frustración y de la cantidad de errores en el sistema, lo que además implica una disminución de la calidad del trabajo.
El autor cita una frase genial de un desarrollador que dice algo así como: “Si llenas mi mañana de interrupciones, entonces no te sorprendas cuando el día sea improductivo.”
También se critica a las reuniones, diciendo que la única diferencia entre una reunión y una interrupción común y corriente, es que la reunión es planificada. Los desarrolladores no pueden progresar en una tarea si saben de antemano que dentro de una o dos horas tendrán una interrupción, dado que la mayoría de las tareas de desarrollo toman más de dos horas.
Se propone como solución a este problema, planificar reuniones breves de status en un horario que sea temprano en la mañana, o justo antes del almuerzo, para evitar interrupciones innecesarias.

Scope Creepiness

En esta parte se define el concepto de Scope Creepiness (su traducción es algo así como “El escalofrío del alcance”, pero no me gusta mucho), como un fenómeno producido por los cambios no controlados en el alcance de un proyecto. Esto puede pasar cuando el alcance de un proyecto no está claramente definido, documentado, o controlado, lo cual puede llevar a que cualquier mejora que parece simple de desarrollar, se transforme en un monstruo difícil de controlar.

Tomemos como ejemplo la siguiente mejora (extraída del propio artículo):

Versión 1 (antes de la implementación): La mejora dice “Mostrar un mapa de la ubicación”.

Versión 2 (cuando la versión 1 está casi terminada): La mejora se modifica a “Mostrar un mapa 3D de la ubicación”.

Versión 3 (cuando la versión 2 está casi terminada): La mejora cambia nuevamente a “Mostrar un mapa 3D de la ubicación, en el cual el usuario pueda navegar”.

Falta de consideración hacia la “deuda técnica”

Se menciona a la deuda técnica como el acto de implementar una solución que no es la mejor, o escribir código de una manera no óptima para poder liberar el producto lo más rápido posible. Esta práctica puede ser buena en el corto plazo (dado que se pretende cumplir con las fechas de entrega), aunque en el largo plazo acarrea problemas de complejidad en el desarrollo del sistema y de mantenibilidad. Algunos no-programadores subestiman la pérdida de productividad en favor de mejorar la calidad del producto, ya que están tentados siempre a ir hacia adelante, y eso se transforma en un problema. Si estamos la mayoría del tiempo enfocados en entregar un producto que funcione dentro de los plazos especificados, y no le damos importancia a aspectos como por ejemplo la calidad del código que escribimos, eso puede provocar incidentes en el sistema que a futuro sean difíciles de resolver.

Documentación

En cuanto a la documentación del código, el autor del artículo afirma que uno de los grandes problemas de documentación que atentan contra la productividad de los desarrolladores es la documentación de código excesiva, la cual se lleva a cabo con la finalidad de explicar el código escrito de manera confusa. Se plantea como solución a esta situación, el tratar de re-escribir el código de forma tal que no sea necesario el agregar comentarios, o en todo caso, que los comentarios sólo sean de utilidad para explicar por qué se hicieron las cosas de esa manera, y no qué es lo que se hizo.
Un código confuso y con demasiadas líneas comentadas, solo logra la frustración de los demás colegas a la hora de leerlo y de tratar de comprender qué es lo que hace.

Deadlines ajustados e imposibles

Este punto está vinculado a la tendencia de los gerentes a pedir estimaciones a los desarrolladores, luego presionar para que la estimación baje en cantidad de horas tanto como sea posible, y finalmente considerar esa estimación ajustada como un deadline o fecha límite de liberación. Los gerentes consideran en este caso que, cuando el desarrollador brinda una estimación, el mismo está comprometido a entregar la tarea dentro del tiempo estimado, por lo que asumen que va a aumentar su productividad debido a ese compromiso, y más aún si esa estimación es ajustada a una menor cantidad de horas. Sin embargo, esta práctica tiende a generar discusiones entre desarrolladores y gerentes, ya que no se toma como límite la estimación inicial, sino la ajustada, lo cual provoca tensión e incapacidad para enfocarse en el trabajo. Lo que en principio se creía que iba a aumentar la productividad, en realidad termina causando un efecto totalmente contrario.

 

Estos son sólo algunos de los puntos que se tratan en el artículo, los que consideré más importantes o que tal vez más influyen en cuanto a la pérdida de productividad de los desarrolladores. Si les interesa el tema, pueden profundizar al respecto leyendo el artículo original que se encuentra en el enlace que dejé en el primer párrafo de este post.

 

 


Espero que haya sido de tu agrado este post, y que los diferentes ejemplos e ideas expresadas en el mismo se hayan entendido. Por cualquier duda, consulta, aporte o crítica, puedes dejar un comentario al final de la página.

Suscríbete al Newsletter de Carbasoft:

 

Si te gustó esta entrada del blog, puedes darle a Compartir a esta página de Carbasoft en Facebook: