Resumen: Las jornadas de trabajo largas son un indicador importante de la ejecución del proyecto y por lo tanto tu planificación no se está cumpliendo. En gestionar estas situaciones se encuentra la diferencia entre cumplir o incumplir tus objetivos.
Probablemente a lo largo de nuestra carrera profesional, todos hemos visto y vivido épocas donde la carga de trabajo es muy alta y por lo tanto, nuestros equipos de desarrollo se ven sometidos a jornadas interminables.
El exceso de horas en el desarrollo de software es un indicador claro de que las cosas no van bien y como líderes del proyecto tenemos que ser capaces de identificar estas situaciones y adelantarnos a problemas más importantes. No hay que engañarse, por mucho que nos guste nuestro trabajo, por muy apasionados que seamos de la tecnología a nadie nos gustan las jornadas de 10, 11, 12 horas. Todos necesitamos a lo largo del día tiempo para nuestra familia, amigos u otros proyectos en los que estemos participando así que si a aspectos tan importantes de la vida le estás quitando tiempo básicamente es por algo que parece importante. Ese algo es la fecha de cierre de tus tareas.
Si la tarea ha sido creada como tiene que ser, esta tendrá asociado un esfuerzo que en conjunción con la fecha de inicio nos devuelve una fecha de cierre. Cuando un desarrollador detecta que no va a poder cerrar la tarea en la fecha prevista normalmente comienza a alargar su jornada.
Entonces la pregunta que nos tenemos que hacer es ¿Por qué una tarea no puede cerrarse con el esfuerzo previsto? Suele ser debido a un error en la estimación del esfuerzo, errores en la definición o errores en la ejecución.
Desde el punto de vista del desarrollador, la solución esta en comunicar que algo está fallando de manera que podamos analizar qué es exactamente lo que no va bien y tomar decisiones que nos permitan seguir con el plan. Aunque no lo creas, que un desarrollador haga un ejercicio de buenismo y eche un par de horas al día para cerrar sus tareas es un escenario que no es mantenible y sobre todo, un escenario que termina siendo perjudicial. Levanta la mano y comunica la situación, verás cómo recibes ayuda y todo mejora.
Desde el punto de vista del arquitecto / líder del proyecto, la solución es un poco más compleja no obstante yo trato de seguir las siguientes pautas:
- Correcta definición de tareas, metas e hitos y correcta definición del resultado esperado
- Correcta dimensión de la tarea
- Conoce al equipo con el que trabajas
Correcta definición de tareas, metas e hitos y correcta definición del resultado esperado.
Evidente pero muchas veces esto no se realiza y en historias de usuario de cierta entidad te encuentras que no hay ni siquiera una descripción de la tarea… Define correctamente la tarea. Trata por todos los medios que sea específica, que no sea ambigua y que no sean posible las libres interpretaciones etc… Ya sabes requisitos smart.
Correcta dimensión de la tarea.
Dimensionar correctamente las tareas es básico para ejecutar un plan. No es posible planificar nada con un esfuerzo subestimado o sobrestimado. Si el esfuerzo está subestimado nos encontramos con un equipo con una moral baja y poca motivación debido a las jornadas y sensación general que les transmite el proyecto.
Si el esfuerzo está sobrestimado, estaremos desaprovechando las capacidades de nuestro equipo y probablemente el que sufra desmotivación y baja moral será el líder.
Conoce al equipo con el que trabajas.
Si la tarea está bien definida y está correctamente dimensionada y no se cierra a tiempo es debido a que hay un error en la ejecución. Conoce a tu equipo, como son estas personas, sus fortalezas y debilidades, trata de asignarles las tareas que mejor vayan a ejecutar y sobre todo ayudarles a cambiar lo que hacen peor (todos hacemos alguna cosa mal 😉 ).
Probablemente no sea la única forma de evitar errores en la ejecución, pero creo que esta más o menos funciona.
Conocer al equipo suele ser más complicado y más cuando los equipos cambian a una velocidad importante, pero sin embargo, definir las historias de usuario correctamente de manera que tus desarrolladores entiendan que es lo que tienen que hacer y estimar el esfuerzo con una aproximación lo más acertada posible debería ser relativamente sencillo y mejora mucho la ejecución del proyecto.
A deshoras 