Con una simple búsqueda puedes encontrar millones de artículos sobre cómo mejorar la productividad, básicamente la misma murga o cosas que no casan con tu personalidad. En este lo que quiero es mostrarte qué prácticas pueden destruir tu productividad como programador, desarrollador o profesiones similares.
Más que un tutorial, mi idea en esta lista es que te puedas dar cuenta de algunas cosas que nos pasan a casi todos en el proceso de desarrollo de una aplicación por ejemplo. He hablado con mucha gente, y me ha sorprendido que buena parte de mis compañeros de hobby/profesión, no hubiesen caído en la cuenta de algunas de estas cosas.
Todas las cosas que pueden reducir tu productividad al desarrollar aplicaciones
Espero que al final esta lista te sirva para abrir los ojos en algunos puntos, y cuando no son tu culpa puedas echar la bronca a quienes colaboran a bajar tu rendimiento, y también satisfacción, porque estos dos van ligados.
Sé que en algunas me vas a decir que es imposible cambiarlo, o que no está en tus manos, pero siempre se puede abrir un diálogo. Piensa que por muy poco que se pueda mejorar la productividad, si te dedicas a diario a ello un 5% ya es una barbaridad.
Reuniones e interrupciones
A quién no le pasa que algún compañero necesita algo o que le toca ir a un “meeting” en un par de horas. Estas interrupciones son las que más daño causan a los desarrolladores, párate a pensarlo.
Cuando estás en medio de algo, concentrado y en materia, todo funciona perfecto, pero ¿cuanto cuesta estar en ese estado? Si preguntas a un profesional te dirá que en la mayoría de los casos se tarda de 15 a 30 minutos volver a concentrarse.
Esto parece una tontería, pero cuando estás trabajando en algo, y sabes exactamente lo que estás haciendo, al ser interrumpido el cerebro cambia de modo y luego tienes que volver a revisar código y buscar donde te habías quedado, no es tan fácil.
Las reuniones son aún peores, porque son interrupciones pero programadas. Es diferente a cuando un compañero o encargado te pide ayuda con algo y te hace perder el foco, ya que en este otro caso eres consciente de cuando lo vas a perder.
Pero, ¿cómo evitarlo? La forma más efectiva (aparte de documentada), es el mover los meetings al principio o final de la jornada, cuando aún no has necesitado concentrarte, o ya no tienes que volver a hacerlo.
Para las interrupciones es más complicado, puesto que ahí deberías acordar algunas reglas y que por ejemplo las cosas te las pidan por email a no ser que sean de vida o muerte (porque si no todo es de vida o muerte al final).
Micro-management
Este es un término que ha crecido bastante en los últimos años y que es especialmente nocivo para la productividad de un programador. Se trata de un “jefe” que le da mucha importancia a tonterías y que no para de criticar hasta lo más absurdo sin tener ni idea.
Esta monitorización constante y la falta de apoyo suelen dar lugar a una sensación de que no estás haciendo bien tu trabajo y una falta de motivación.
Es uno de los principales motivos por los que cambiar de trabajo o al menos de equipo si tu encargado es de este tipo.
Vaguería
Se me ocurren infinitas formas de explicar lo que es la vaguería. Reportes de Bugs como “no funciona el click” o “no se abren las páginas”, no solo no tienen suficiente información para solucionarlo, sino que hace que tengas que ir detrás de los demás.
Para evitar este tipo de problemas existen plantillas dependiendo del tipo de mensaje a introducir en el sistema.
Otra de las cosas es no pararse a determinar lo que es más importante o prioritario y no especificar categorías. Cuando estás desarrollando no te quieres parar a pensar en qué tareas son más importantes para la empresa, quieres hacer lo que te gusta, y es difícil para un desarrollador determinar qué hacer primero, lo que se acaba traduciendo en frustración.
Encargado gaviota o Seagull Management
Es gracioso el nombre que se le da, pero explica perfectamente el problema. Si no has oído hablar de ello, el encargado gaviota es el que no tiene ni pajolera idea de lo que van los proyectos y simplemente va saltando de uno a otro cagándose en todo.
Sí, no suelo expresar las ideas con este vocabulario, pero era necesario, lo siento. Es el tipo de encargado que mira un poco por encima tu trabajo y se dedica a soltar “esto está mal, y esto”, “aquello no puede estar así”, etc, pero que no tiene ni idea de como tiene que ser (ni de como es realmente lo que has desarrollado).
Esto solo sirve para frustrarnos como desarrolladores, y lo peor es que una vez se cagan se piran y no vuelven en horas o días a dar la tabarra. Por supuesto esto te deja con la sensación de que lo estás haciendo mal o de no saber por donde continuar, por lo que el rendimiento se ve afectado.
Trepas
¿Alguna vez te has topado con algún ecanrgado, o incluso otro compañero de trabajo que se ha atribuído el mérito a algo en lo que llevas trabajando semanas? Todo simplemente para ir subiendo en la empresa y ponerse por encima de los demás con méritos.
Esto básicamente es un trepa, y en ocasiones una vez tirada la bomba no puedes hacer nada, te quedas con cara de poker pensando en para qué te esfuerzas tanto.
Esto además es capaz de crear cierta tensión entre trabajadores, y hace que el espacio de trabajo sea menos adecuado y la comodidad afecte a la productividad.
Entorno de trabajo
El ruido, diseño, agetreo alrededor son cosas que para los no programadores o desarrolladores puedan sonar a tontería, pero para los que trabajamos en ello tiene impacto directo en el rendimiento.
En la mayoría de los casos, tener ruido alrededor nos ayuda a concentrarnos, como tráfico o ruido blanco. Es por esto precisamente que muchos tenemos puestos los cascos casi todo el tiempo con la música que mejor nos ayuda a aislarnos del entorno.
En mi caso suele ser música sin cantar, muy animada, algo rápida y que suena bastante. He encontrado que algún tipo de techno (la mayoría de serl), hace que mi cerebro se olvide del entorno cuando hay mucho ruido (conversaciones y demás) en la oficina.
Otra de las cosas es el diseño del espacio de trabajo. No digo que tengas que estar en un cubículo metido, pero a mucha gente le estresa que sus monitores estén a la vista, o espacios demasiado abiertos, o incluso le distrae estar junto a una ventana, por lo que se generan más posibilidades a interrupciones.
Scope Creepiness o síndrome del fregadero
En administración de proyectos significa que hay cambios que no se pueden controlar y no se han tenido en cuenta desde un principio. Esto puede pasar sobre todo cuando el objetivo de un proyecto no está bien definido.
El síndrome del lavadero, puede convertir tareas relativamente fáciles en monstruos contra los que no se puede combatir sin armas. Lo peor es que la mayoría pasan durante el desarrollo…
Por ej:
- Primera versión: “mostrar las imágenes del artículo.”
- Segunda versión: cuando ya casi está integrada la primera, “mostrar las imágenes del artículo en 3D”
- Tercera versión: cuando ya casi está la segunda, “mostrar las imágenes del artículo en 3D y que el usuario pueda moverlo a su antojo”
Proceso de definición del producto
Puede parecer raro, pero es bastante sencillo. Si un equipo define sus prioridades sin haber revisado a fondo todo lo que se ha de hacer, y al final la mitad de las funcionalidades no se usan, se va a minar su moral.
Los desarrolladores o programadores van a sentir que el trabajo ha sido inútil y la motivación se va a ir por el retrete. A todos nos gusta hacer algo que sea realmente útil y sentir que hemos trabajado para algo.
No considerar la “calidad aceptable”
En inglés Technical Debt, se refiere a la decision deliberada de implementar algo de una forma no tan perfecta, que sea funcional y que permita poner en producción el producto o programa más rápido.
En cuanto a programación, esto puede ser una buena opción a la hora de lanzar algo más pronto, ya que no suele haber riesgos para terceros (siempre que no hablemos de por ejemplo conducción autónoma).
De todas formas puede ser bueno y malo, porque desarrollar soluciones no tan perfectas pero funcionales ayuda, pero si siempre hacemos eso y nunca hay refactorización de código en un futuro podemos empezar a tener problemas. Yo lo he vivido en algunos proyectos y se puede convertir en un problema y grande.
Demasiada variedad de software y hardware
Como desarrollador seguro que usas un montón de programas para escribir código, trabajar en equipo, guardar tu trabajo, hacer copias de seguridad.
En este punto, cuanta mayor automatización se implemente mejor, hay que dejar las tareas repetitivas a sistemas que se dediquen solo a eso, para nosotros concentrarnos en lo que importa, el desarrollo.
Esto no es solo a nivel de software, yo por ejemplo no trabajo con menos de dos monitores precisamente por el aumento de rendimiento, al igual que poder utilizar un equipo centralizado al que conectarte para desarrollar desde cualquier sitio y no andar moviéndote entre el equipo portátil y el de la oficina.
Cuando haces un gran volumen de trabajo diario, un 5% marca la diferencia y merece la pena la inversión.
Cómo documentar
He visto código sin un ápice de comentarios, y otros que tenían tantos comentarios que además de acabar siendo un código espaguetti, era casi imposible de leer entre tanto texto en gris.
No se trata de comentar cada línea de código incluso para decir que es una variable, pero tampoco acordarnos solo en un método de cada clase.
Te puedes dar cuenta de que necesitas empezar a poner algunos comentarios en el código, cuando vuelves a algo que has escrito y no sabes para qué sirve, o cuando trabajas en equipo y te pierdes en el código de los demás.
Lo ideal es poner algún comentario normalmente en los métodos y funciones que no tengan un nombre lo suficientemente claro (como isAllowed que se explica por sí mismo), o si la funcionalidad es un poco compleja.
Fechas límite imposibles
Lo último viene también por parte de los encargados y el punto de vista de la realidad (en muchos casos). El factor común a la hora de actuar es pedir estimación a los desarrolladores, poner una fecha aproximada en base a sus propios criterios, y luego exprimir esa fecha al máximo hasta convertirla en la fecha límite o deadline.
Seguramente has visto esto más de una vez, y esta presión que recae sobre los desarrolladores cuando estos saben que son límites prácticamente imposibles. Por supuesto esto mina el rendimiento ya que con cualquier imprevisto no se van a conseguir los tiempos requeridos.
En este punto y si la cosa es recurrente, habrás notado que tu nivel de estrés está siempre por las nubes e incluso a veces te quita las ganas de ir al trabajo. Es el momento de buscar otro o hablar claramente con la persona al mando.
Indiferencia entre compañeros de equipo
Cuando se trabaja en equipo, tu trabajo y el de los demás está estrechamente relacionado. Cosas que tú hagas pueden afectar a los demás, y cosas que hagan los demás te pueden afectar a tí, tanto positiva como negativamente.
Es el segundo caso el que hay que intentar afrontar y solucionar. Por ejemplo, es posible que si no se hacen pruebas o tests de funcionamiento (al menos que confirmen que no dejan otras partes del proyecto de funcionar), al integrar el trabajo de otros en el tuyo te veas bloqueado porque lo que habías hecho no funciona debido a errores de código.
Si es un caso aislado no pasa nada, pero cuando se convierte en una costumbre tu moral y ganas de ir al trabajo pueden verse gravemente afectadas. ¿No te ha pasado nunca que tienes miedo de hacer un “git pull” de la rama master?
Lo mejor es fijar unas reglas cada vez que tu trabajo se tenga que integrar con el de los demás, de forma que te asegures de que las partes principales del proyecto van a seguir funcionando. Esto se puede solucionar con diálogo, pero sobretodo con tests unitarios y también automatizados de usuario.
Tiempo de desarrollo estrictamente controlado
No sé calcular el tiempo que tardo en hacer algo me dirás, y es perfectamente normal. Dependiendo de tu nivel como desarrollador, o de si estás solo o no en un proyecto es difícil hacer el cálculo, pero puedes pensar aproximadamente cuanto puede costarte hacer algo si sabes hacerlo y multiplicarlo por 2, y si no sabes por donde cogerlo multiplicarlo por 5 para tener una idea holgada de lo que puedes tardar.
El problema viene cuando el encargado o jefe, se piensa que desarrollar una aplicación o funcionalidad a base de una serie de vagas instrucciones es como escribir un documento de algo que sabes y tienes en la cabeza.
Sé que lo de multiplicar por 5 puede parecer demasiado, pero hablo del caso en el que no seas capaz de calcular un tiempo de desarrollo.
Lo que puede pasar cuando no calculas bien los tiempos, es que no cumplas tus propias expectativas (al igual que cuando te pongan metas surrealistas los encargados). Si te ponen un reloj para ver cómo de rápido eres capaz de desarrollar, es momento de cambiar de empresa.
Lo mejor para arreglar esto es que vayas fijándote en lo que te cuesta hacer partes del proyecto, te anotes dificultades y lo que tardas en hacerlo, en poco tiempo serás capaz de dar tiempos aproximados y decir directamente cuando lo que te están pidiendo es imposible.
Conclusión
¿Todas estas cosas son solamente para los desarrolladores o programadores? No. Es bastante probable que lo puedas aplicar a casi cualquier trabajo que se base en proyectos, sobretodo cuando hay que trabajar con la cabeza, ya que en trabajos manuales se pueden predecir más cosas.
Esto significa que podrías aplicarlo si eres diseñador gráfico, UX, creador de productos, etc.
Mi consejo es que si en tu trabajo o empresa eres capaz de identificar algunos de estos puntos, los intentes comentar con los departamentos correspondientes para localizarlos y resolverlos. Aumentará la productividad y la moral general.
En este artículo te he dejado los motivos que me parecen más importantes en cuanto a lo que productividad y ánimo en el trabajo se refiere, pero si te viene a la cabeza algún otro que no haya puesto en la lista déjamelo en los comentarios. Le echo un ojo, y podemos hablar de ello, es posible que lo integre en la lista y también lo intente poner en práctica.
¿Y tú? ¿Qué es lo que más afecta a tu productividad? Comenta y comparte
