{"id":749,"date":"2018-11-13T13:24:03","date_gmt":"2018-11-13T13:24:03","guid":{"rendered":"https:\/\/www.cloudcustomsolutions.com\/12-cosas-que-perturban-la-productividad-de-los-desarrolladores\/"},"modified":"2018-11-13T13:24:03","modified_gmt":"2018-11-13T13:24:03","slug":"12-cosas-que-perturban-la-productividad-de-los-desarrolladores","status":"publish","type":"post","link":"https:\/\/www.cloudcustomsolutions.com\/es\/12-cosas-que-perturban-la-productividad-de-los-desarrolladores\/","title":{"rendered":"12 cosas que perturban la productividad de los desarrolladores"},"content":{"rendered":"
\n
\n
\n

En Cloud Custom<\/a> Solutions, contratamos a muchos desarrolladores para todos nuestros proyectos multifac\u00e9ticos, por lo que pensamos que vale la pena leer este art\u00edculo.<\/p>\n

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.<\/p>\n

As\u00ed que vamos a profundizar en nuestra lista de 12 cosas que impiden a sus desarrolladores entrar en la zona y ser productivos. Intentar\u00e9 priorizar esta lista de mayor a menor impacto. No dude en comentar.<\/p>\n

Si te preguntas si todo esto merece la pena, s\u00f3lo tienes que tener en cuenta los sueldos de los promotores. Incluso un 10% m\u00e1s de productividad es MUCHO.<\/p>\n

1) Interrupciones y reuniones <\/h2>\n

En mi opini\u00f3n, las interrupciones son el principal factor de p\u00e9rdida de productividad para los desarrolladores. Los desarrolladores no pueden volver f\u00e1cilmente a donde estaban justo antes de una interrupci\u00f3n. Tienen que entrar en la mentalidad del desarrollo y luego volver poco a poco a donde lo dejaron. Esto puede llevar f\u00e1cilmente m\u00e1s de 30 minutos. Y cuantas m\u00e1s interrupciones, m\u00e1s frustraci\u00f3n, menos trabajo de calidad, m\u00e1s fallos… y as\u00ed sucesivamente.<\/p>\n

\u00abCuantas m\u00e1s veces me hagas tropezar mientras intento empezar, m\u00e1s tiempo pasar\u00e1 entre cada vez que lo intente. Si llenas mi ma\u00f1ana con interrupciones – no te sorprendas cuando el d\u00eda sea improductivo\u00bb. -un desarrollador en Reddit<\/p><\/blockquote>\n

\u00bfY las reuniones? La \u00fanica diferencia entre una reuni\u00f3n y una interrupci\u00f3n es que una reuni\u00f3n es una interrupci\u00f3n planificada, lo que la hace a\u00fan peor. Los desarrolladores no pueden avanzar en una tarea si saben que tendr\u00e1n una interrupci\u00f3n mientras trabajan en ella. As\u00ed, si tienen una reuni\u00f3n en una o dos horas, no podr\u00e1n avanzar en nada, ya que la mayor\u00eda de las tareas de ingenier\u00eda requieren m\u00e1s tiempo.<\/p>\n

Como escribi\u00f3 Paul Graham<\/a>, \u00abuna sola reuni\u00f3n puede echar a perder toda una tarde al dividirla en dos partes, cada una de ellas demasiado peque\u00f1a para hacer algo dif\u00edcil\u00bb.<\/p><\/blockquote>\n

\u00bfC\u00f3mo se puede evitar esto? Esta parte est\u00e1 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.<\/p>\n

2) Microgesti\u00f3n<\/h2>\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\u00e1s reuniones e interrupciones imprevistas. Pero no es s\u00f3lo eso. Muestran una falta de confianza y, al hacerlo, sientes que socavan constantemente tus habilidades y tu capacidad para hacer las cosas. Cualquier motivaci\u00f3n que un desarrollador tuviera entre las interrupciones se esfumar\u00e1 en ese momento. El impacto va m\u00e1s all\u00e1 de la productividad. Los microgestores pueden ser la primera raz\u00f3n por la que los desarrolladores se marchen o, como m\u00ednimo, cambien de equipo.<\/p>\n

3) Vaguedad<\/h2>\n

Hay muchas formas de ilustrar la vaguedad. Los informes de errores del tipo \u00ab\u00a1Est\u00e1 roto, arr\u00e9glalo!\u00bb no tienen suficiente informaci\u00f3n para que los desarrolladores trabajen a partir de ella. Por cierto, tener una plantilla de informe de errores puede ayudar en ese caso.<\/p>\n

O una especificaci\u00f3n poco clara sobre una caracter\u00edstica, en cuyo caso los desarrolladores comenzar\u00e1n 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.<\/p>\n

El establecimiento de prioridades poco claras tambi\u00e9n pertenece a esta categor\u00eda. El tiempo que un desarrollador pasa pregunt\u00e1ndose si est\u00e1 trabajando en la tarea correcta puede evitarse f\u00e1cilmente. Y si alguna vez reciben un comentario del gerente preguntando por qu\u00e9 han trabajado en esta tarea en particular (mientras que las prioridades no estaban definidas)… bueno, lo entienden: mucha frustraci\u00f3n…<\/p>\n

4) Gesti\u00f3n de la gaviota<\/h2>\n

\u00bfHas o\u00eddo hablar de ella? Ocurre cuando los directivos se desentienden totalmente del trabajo, pero… se abalanzan de vez en cuando para cagarlo todo. \u00abEsto est\u00e1 mal, y esto, y esto tiene mala pinta\u00bb, etc., antes de volver a volar. Tengo que admitir que me ha encantado la imagen, pero desgraciadamente, esto ocurre m\u00e1s a menudo de lo que nos gustar\u00eda. Este comportamiento es profundamente frustrante para los desarrolladores; no podr\u00e1n volver a la zona en las pr\u00f3ximas horas, y a veces ni siquiera durante d\u00edas.<\/p>\n

5) Avaricia crediticia<\/h2>\n

\u00bfHas tenido alguna vez un jefe u otro promotor que se haya llevado todo el m\u00e9rito del trabajo que has hecho en las \u00faltimas semanas? Los desarrolladores valoran la competencia por encima de todo. Tomar el cr\u00e9dito de otra persona es tomar la competencia del otro para ti y quit\u00e1rsela. Esto est\u00e1 muy arriba en mi lista, ya que creo que crea tanta tensi\u00f3n que acaba con la productividad de los desarrolladores durante un tiempo.<\/p>\n

6) Entorno – Ruidos, movimiento, dise\u00f1o del espacio de trabajo…<\/h2>\n

Esto puede parecer extra\u00f1o 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\u00edr pasar coches y camiones- les ayuda a concentrarse mejor. Por eso muchos de nosotros nos ponemos auriculares. Acabo de descubrir RainyMood<\/a>, \u00a1estupendo!<\/p>\n

Del mismo modo, si el espacio de trabajo est\u00e1 dise\u00f1ado para tener el mayor movimiento posible, eso no les ayudar\u00e1 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\u00e9s adicional y a\u00fan m\u00e1s oportunidades de ser interrumpido.<\/p>\n

7) La escalada del alcance<\/h2>\n

En la gesti\u00f3n de proyectos, la fluencia del alcance (tambi\u00e9n llamada fluencia del enfoque, fluencia de los requisitos, fluencia de las caracter\u00edsticas y, a veces, s\u00edndrome 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\u00e1 correctamente definido, documentado o controlado.<\/p>\n

El \u00abScope creep\u00bb convierte peticiones relativamente sencillas en monstruos terriblemente complejos y que consumen mucho tiempo. Y la mayor\u00eda de las veces ocurre durante el desarrollo. Por ejemplo, para una funci\u00f3n sencilla:<\/p>\n