¿Cómo puedo evitar el agotamiento del equipo?

Trabajo para una pequeña empresa web que se ocupa de muchos proyectos, algunos en un momento dado requieren mucho desarrollo para nosotros (400-1500 horas o más) y me he dado cuenta de que los desarrolladores se agotan mucho en un proyecto después de 150 horas más o menos.

He estado jugando con la idea de trabajar en algún tipo de rotación/descanso para que cuando alguien alcance el umbral, al menos tenga algo de tiempo libre para trabajar en ese proyecto. ¿Existe un enfoque estándar de la industria?

No está claro: ¿cada desarrollador está trabajando en varios proyectos a la vez? ¿Cuántas horas a la semana trabajan realmente?
40-45 horas a la semana, y la mayoría de los desarrolladores trabajan en varios proyectos a la vez. Algunos, sin embargo, se centran en un proyecto durante meses.
¿Los desarrolladores que trabajan en múltiples proyectos quieren hacer eso? ¿Los desarrolladores que trabajan en proyectos individuales durante meses quieren trabajar así? Nadie es lo correcto, ya que a diferentes personas les gustan cosas diferentes. Cuando coincide = más feliz.
Lamento tener que preguntar esto, pero ¿las personas realmente están haciendo 40-45 horas a la semana, o simplemente están poniendo 40-45 horas a la semana en sus hojas de tiempo? Además, ¿se les está dando tiempo para hacer bien su proyecto o se les apresura a completarlo antes de una fecha límite? A menudo, sentir que tiene que tomar atajos puede ser desmoralizador. Finalmente, ¿las personas van directamente de un trabajo de 150 horas a otro sin descanso? A menudo, obtener el tiempo para hacer una retrospectiva de un proyecto puede marcar la diferencia entre sentir que el proyecto fue malo o simplemente fallido.
¿Están trabajando solos o en equipos/parejas? Si trabajan en equipos o parejas, ¿qué les impide rotar entre proyectos ahora?

Respuestas (11)

En cada punto a continuación, mi objetivo es proporcionar opciones utilizables para "¿Cómo puedo evitar el agotamiento del equipo?"

Aunque a menudo no hay una causa única para esto, dado "extremadamente agotado en un proyecto después de 150 horas más o menos", miraría todas las áreas posibles. Conviértalo en un "proyecto" y preséntelo hacia arriba (gerencia) y hacia abajo (equipo) para obtener recursos y aceptación.

Descubrí que el agotamiento no ocurre tanto "en" un punto específico y varía de persona a persona. Para algunos son 300-400 horas. Para otros es 1000-5000 o más como se nota. Independientemente de las horas, el agotamiento se acumula con el tiempo y refleja muchas cosas.
Sin conocer los detalles, tanto de usted como (confidencialmente, ¡ja!) de su personal, sugeriría las siguientes áreas para examinar y enfocarse.
Muchas de las cosas que pueden marcar la diferencia son intangibles sutiles, pero se suman.
El siguiente resumen es lo que he aprendido de décadas de desarrollo y debería adaptarse a su empresa/presupuesto:

El equipo:

  • ¡Escucha primero! Pregúntale a tu equipo. Pregunta de nuevo. Pregunta todas las semanas "¿qué puedo hacer para ayudarte? ¡Es mi trabajo!". Busca primero comprender y luego ser comprendido. :)

  • Sea honesto Los programadores, como la mayoría de la gente, pueden olfatear la falsedad rápidamente y ¡es muy desmotivador!

  • No te centres en las horas (largas o cortas) céntrate en la dedicación y el rendimiento .

  • Anime, recompense y promueva a los desarrolladores que quieran utilizar las mejores prácticas .

  • Dar a los desarrolladores la mayor autonomía posible. Permitir errores (a veces) cuando no son críticos.

  • Ofrezca a los desarrolladores variedad en los proyectos en los que están trabajando al mismo tiempo.

  • Proporcionar formación general . Los desarrolladores deben continuar mejorando sus habilidades en una variedad de áreas para mantenerse actualizados.

  • Proporcionar formación específica . Los desarrolladores necesitan las habilidades para realizar las tareas específicas en cuestión, o se ven obligados a aprender en el trabajo, lo que reduce el tiempo para hacer el trabajo (y mucho menos hacerlo bien), lo cual es frustrante y estresante.

  • Envíe a los desarrolladores a conferencias sobre tecnologías relevantes. Ellos mejoran sus habilidades y usted puede beneficiarse. Los desarrolladores a menudo están mucho más dispuestos a trabajar en 'aburrimiento, agotamiento; cosas si también pueden asistir a un par de conferencias divertidas al año y otras reciben otras formas de capacitación. Viajar aquí también es bueno, ya que puede ser un gran beneficio en sí mismo.

  • Dirección Deuda Técnica . Entiéndalo y reconózcalo públicamente con su equipo técnico y con la gerencia cuando exista. Difundir conocimientos sobre por qué es mala y mejores prácticas para abordarla y evitarla. La deuda técnica puede ser muy desalentadora para sus mejores desarrolladores.

  • Fomentar una buena actitud y predicar con el ejemplo . Vaya a capacitarse USTED MISMO en una mejor gestión.

  • Reconoce, elogia y fomenta el buen trabajo de tu equipo.

  • Use el humor (con cuidado, considerando a las personas) para calmar las situaciones tensas y difíciles.

El flujo de trabajo

  • Si hay mucha burocracia o lentitud en la organización, evite el aburrimiento compensando el 'tiempo de inactividad' con una variedad de otros trabajos, educación, etc.

  • Los desarrolladores que trabajan con Usuarios a veces tienen conflictos debido a diferentes perspectivas y áreas de especialización. Fomentar una mayor comunicación para abordar esto.

  • Utilice buenas herramientas para el seguimiento de proyectos/características/errores, por ejemplo, Pivotal Tracker. Elija una herramienta que su equipo encuentre fácil y útil de usar. Acuerde los patrones de uso y la denominación adecuada, la categorización de los problemas (gravedad, prioridad), etc.

  • Defina el flujo de trabajo con reuniones claras, comunicaciones, mensajes, etc. Asegúrese de que todos estén en la 'misma página' en cuanto a cuál es la dirección. No asuma que lo son.

  • Aborde los problemas con reuniones regulares programadas y nunca asuma que todo está bien.

Las Tecnologías:

  • Proporcionar equipos de calidad . No le pague a un desarrollador 70,000 (o mucho más) y luego escatime unos cientos de dólares en equipo.

  • Ofrezca a los desarrolladores variedad en las tecnologías que utilizan para mantenerlos actualizados.

  • Proporcionar herramientas de calidad. El trabajo de calidad de artesanos y artesanas requiere herramientas de calidad, como en todas las industrias. Brinde a las personas herramientas que les resulte placentera utilizar. No es un dolor y frustración.

  • Mantenga un suministro constante de herramientas, tecnologías y juguetes geniales . El tipo de desarrolladores que puede querer a menudo aman estas cosas más que $$$.

  • Anime a los desarrolladores a especializarse en las tecnologías que más les interesen y disfruten .

  • Busque e implemente tecnologías que automaticen tareas repetitivas, como ejecutar pruebas, construir pilas de código.

  • Use herramientas que informen sobre la calidad del código y use el resultado de estas herramientas para guiarlo y ayudarlo a crear un código de mejor calidad, de modo que el caso para hacerlo no tiene que ser solo una conversación, las estadísticas pueden ser poderosas.

Las Cosas (Entorno Físico):

  • Proporcione un gran lugar de trabajo que aliente a los desarrolladores a venir a la oficina (todavía es mejor para grupos que trabajan juntos) en lugar de trabajar de forma remota con: café, refrigerios, jugo y un ambiente fresco.

  • Proporcione estaciones de trabajo y sillas de calidad. Proporcione la opción de escritorios de pie que algunos disfrutan. Los de cartón (que funcionan) están disponibles.

  • Proporcionar un edificio y habitaciones con buen aire acondicionado y calefacción. Asegúrese de que haya buenas persianas en las ventanas e iluminación para todos.

  • Proporcione múltiples pantallas grandes para cada desarrollador y una pantalla de gráficos visibles grandes para mostrar imágenes rotativas de indicadores clave (éxitos de construcción, tickets de seguimiento de proyectos, informe de nuevas reliquias, Google Analytics en visitas al sitio, etc.

  • Fomente los descansos . Encuentra actividades divertidas tanto en equipo como entre equipos (fuera de IS).

  • Respetar los hábitos de las personas . Algunas personas necesitan paz y tranquilidad a veces. Otros no notan el ruido nunca.

  • Examine la composición del equipo, ¿es un miembro (incluso si es técnicamente competente) consistentemente 'tóxico'?

  • Si es posible, ubique al equipo de desarrollo en un lugar amigable para 'geeks' .

  • Fomente los hábitos saludables con membresía en el gimnasio, duchas en el sitio (si es posible) para hacer ejercicio en los viajes diarios, refrigerios saludables (barras de granola, fruta, cereal saludable, etc. en lugar de pizza, donas, productos horneados. Si las personas quieren otras cosas, pueden ¡todavía cómprelo de todos modos!) Cuerpo sano = cerebro sano y menos tiempo de enfermedad.

  • Admite grupos de usuarios locales para las tecnologías que utiliza. Elementos como este pueden ser sutiles, pero son básicamente como marketing de imagen: usted compra pizzas para un grupo de usuarios local o organiza una reunión, su empresa se ve bien y brinda apoyo, y la gente se siente mejor trabajando allí.

Comentario final: date cuenta de que este es un trabajo de tiempo completo con poco tiempo para el desarrollo y sal corriendo con el pelo en llamas. Oh sí, la comedia y el sentido del humor ayudan MUCHO. ¡La mejor de las suertes!

En mi opinión, esta es la única respuesta hasta ahora que realmente aborda la pregunta en cuestión al brindar apoyo e ideas para seguir adelante. Buen trabajo Miguel.
Marcos, gracias por el formato! ¡Haría +1 en eso!
@Michael Durrant: no hay problema, es una buena respuesta, así que me alegró pasar unos momentos mejorando un poco el formato. Además, me dio dos repeticiones completas. Juerga. *8')
+1: las conferencias también son divertidas, porque puedes conocer gente y hablar de negocios sin que parezca trabajo.
Michael- Increíble respuesta. Lo he copiado en mi carpeta de Consejos y trucos para un uso futuro repetido y pesado.
@Michael Durrant - (+1) Esta es una gran respuesta, Michael. Está enfocado en el problema real y muy bien estructurado. Gracias por tu aporte :D
una de las mejores respuestas en el sitio PM stackexhange

Algunas razones comunes para esto pueden ser (una o más de las siguientes):

  • Los desarrolladores no son lo suficientemente fluidos en las tecnologías utilizadas y pasan tiempo aprendiendo en el trabajo, por lo que tienen que trabajar más para entregar lo esperado.

  • Falta de buen análisis y mucho re-trabajo

  • El cliente sigue cambiando los requisitos.

  • Objetivos/tiempo poco realistas establecidos por la gestión del proyecto o en el plan del proyecto

  • Falta de un enfoque de proceso para el desarrollo, las tareas no se simplifican

  • Bajo uso de buenas herramientas

  • Reutilización insuficiente del código común

  • Falta de concentración, con 1 desarrollador asignado a varias tareas no relacionadas

  • Pago ilimitado de horas extras: cuanto más trabajas, más te pagamos

  • Insistencia de la gerencia en el cumplimiento de estándares como CMM sin proporcionar tiempo en el plan del proyecto para el esfuerzo de documentación

Resolver algunas de las causas debería mejorar la situación. El examen del caso de cada desarrollador también ayudaría.

¡Sentí que el agotamiento me invadía solo al leer los primeros puntos!
@John Fisher, esta no era mi intención, John... :)
Esta pregunta no pregunta cuáles son las razones del agotamiento del equipo, sino cómo manejarlo. ¿Tienes algo que decir al respecto?
De hecho, si bien este es un buen análisis, no siempre es tan simple como "haz lo contrario" o "no hagas esto" cuando ya estás en la situación, ya que tienes que trabajar para salir del agotamiento.
@MarkTrapp, para ser justos, pregunta cómo evitar el agotamiento. Sin duda, identificar las causas de un problema es un paso clave para evitarlo.
Es un paso clave, sí. Sin embargo, no es una 'respuesta'. Parece más un comentario. O sugirió una adición a la pregunta misma.

Como muchos han dicho, 1 mes de trabajo es demasiado pronto para que uno se queme.

Supongo que tienes un problema con la moral baja. No uno de "Burnout".

Ni siquiera puedo comenzar a adivinar por qué es así, pero creo que es algo que deberías investigar.

Esta pregunta no pregunta cuáles son las razones del agotamiento del equipo, sino cómo manejarlo. ¿Tienes algo que decir al respecto?
Sí, no creo que el equipo esté quemado.

La gente "se quema" porque se "quema". Como han dicho otros, si solo están trabajando semanas normales (40-45 horas) durante el horario normal (no cualquier tontería forzada del tercer turno, que ha demostrado ser perjudicial para la salud), entonces necesita encontrar lo que falta.

Ya que tienes muchos proyectos cortos, te sugiero algo tan simple como una fiesta importante (almuerzo incluido), y tal vez una fiesta de fin de proyecto (nuevamente con comida preparada) y el viernes de esa semana libre. La comida es buena, te sorprendería lo mucho que una caja de donas todos los viernes por la mañana te levantará la moral. Psicología humana básica: si tienes una barriga llena de comida decente, comienzas tu día un par de puntos más feliz :)

Donuts = comida decente ahora?

Hice mi ensayo de MBA sobre el agotamiento, especialmente con los gerentes. Hice mi investigación con un cuestionario y estadísticas en un hospital.

Mi conclusión fue que cuando en un lugar de trabajo las expectativas son la mayor parte del tiempo más altas de lo que la gente puede dar, creas un ambiente de trabajo que en el corto plazo se vuelve cada vez más estresante. Eso es evidente.

El estrés innecesario se vuelve rápidamente improductivo. Usted paga los beneficios de licencia por enfermedad, por ejemplo. Eso es muy costoso.

Lo que ayuda a un trabajador a evitar el burnout es el apoyo social del jefe, compañeros + autonomía en la toma de decisiones. En otras palabras, si tus empleados se sienten a cargo de su situación (empowerment) evitarás muchos casos de burnout.

Pero hoy en día, muchos gerentes de alto nivel no se preocupan simplemente por si un empleado falla o no (solo hay que reemplazarlo). Pero si realiza una consulta de costos ajustados, siempre descubrirá que, a largo plazo, es mucho más costoso administrar de esa manera. Además, contratar y capacitar a los empleados es la tarea más costosa en una organización.

Claramente, no estoy familiarizado con su empresa o su entorno y políticas, por lo que solo son posibles las sugerencias más generales.

Me pregunto si hay otros motivadores además de un ambiente agradable y ventajas, y tal vez desmotivadores más allá de las 150 horas. En muchas empresas, la gente está contenta trabajando en el mismo producto durante meses y 45 horas no parece abusivo en absoluto. Entonces, tal vez este sea un buen momento para un análisis de la causa raíz de los cinco porqués.

Mientras tanto:

¿Has considerado los motivadores en Drive (Daniel Pink)? ¿Sienten los desarrolladores que están progresando o simplemente produciendo productos? Tómese unos minutos para ver este video: http://www.youtube.com/watch?v=u6XAPnuFjJc Vea si le habla.

¿Quizás si pudieran dedicar tiempo a reorganizar para hacer que los proyectos futuros sean más fáciles y divertidos?

En la forma de eliminar los desmotivadores, considere esta lista: http://www.cio.com/article/123406/Stop_Demotivating_Me_

Los gerentes de Theory X en el pasado han considerado el agotamiento como una señal de que están ejercitando al máximo sus recursos. Creo que es genial que seas consciente de la motivación y el agotamiento y estés interesado en hacer algo al respecto. Buena suerte.

Código de envío. Los desarrolladores pueden sentirse como si estuvieran en una larga sesión de gimnasio que solo termina cuando su código llega a los usuarios reales y pueden pasar a la siguiente tarea.

Las personas se sienten más desmotivadas e incluso deprimidas (burnout es depresión) cuando su trabajo parece no dar frutos.

Depende de cuantas horas hagan a la semana. El exceso de trabajo debido a los plazos a menudo genera estrés para los desarrolladores.

s/desarrolladores/personas
Si bien la forma original de la pregunta preguntaba en parte si era normal, pregunta cómo administrar un equipo de programadores agotados. ¿Tienes algo específico que decir al respecto? Estamos buscando más que si algo es normal o no.
Muy deacuerdo con este. Me encanta programar 100 horas a la semana. Sí, incluso el aburrido software empresarial. Sin embargo, trabajar 4 horas a la semana en un supermercado llevaría rápidamente al 'agotamiento' después de 2 o 3 semanas.
No estoy seguro de que sea un exceso de trabajo. 40-45 suena como la cantidad de horas que la mayoría de los desarrolladores desean. Sugiero que probablemente no sea la semana laboral. Es bien sabido que los equipos ágiles trabajan muy poco tiempo extra, pero aun así lo hacen de vez en cuando ( softwarequalityconnection.com/2011/04/an-agile-pace ).

Si ha identificado un patrón, probablemente debería seguirlo. El tiempo libre preventivo para evitar el agotamiento es ciertamente una idea viable.

Dicho esto, 150 horas parece ser una cantidad de tiempo bastante corta para comenzar a agotarse, y 40-45 horas a la semana no es excesivo, por lo que es posible que desee examinar qué es lo que está causando el agotamiento en sus condiciones de trabajo. fuera. @Emmad Kareem sugiere algunas buenas posibilidades.

Salga y escuche lo que los desarrolladores están hablando y/o quejándose. ¿Hay algún patrón allí también? ¿Los que trabajan en varios proyectos se quejan del constante cambio de contexto? ¿La gerencia los está volviendo locos? Una buena comunicación constructiva es el mejor preventivo para el agotamiento.

Intente crear un proceso estándar para la forma en que se hacen las cosas, tanto técnicamente como en cuanto al flujo de trabajo.

Esto aumentará su confianza en el liderazgo (verán que alguien está dirigiendo el barco) y les permitirá concentrarse en hacer su trabajo/realizar proyectos en lugar de reinventar la rueda cada vez.

Además, mejorar los canales de comunicación. Pasa tiempo hablando con la gente. Les permite desahogarse y usted puede aprender formas de mejorar sus vidas y, por lo tanto, sus proyectos.

  • deja de contar horas, las horas no importan, el software si,
  • barco del que solo los desarrolladores de software pueden estar orgullosos ,
  • no creas la ilusión de "personas que trabajan en un par de cosas al mismo tiempo", el cambio de contexto duele y cuesta. Apuesto a que los desarrolladores que trabajan en un proyecto durante períodos más largos se quejan menos de "agotamiento".

Algunos puntos excelentes sobre el medio ambiente, los gimnasios, etc., pero la clave es: asegurarse de que a las personas les encante el código que hacen. Y no los exija demasiado por un par de dólares más.