Horario del Gerente, Horario del Programador

Hoy he tenido una reunión en la que me han mencionado el problema de la planificación del tiempo. El problema parte de cómo se gestiona en sí el tiempo disponible y cómo lo hacen dos perfiles dentro del mismo entorno, un manager, gerente o directivo por un lado y un programador, creador o fabricante por otro lado. ¿Cuál es la diferencia?

Según dice en un artículo Paul Graham, la organización del tiempo para ambos perfiles es completamente diferente. Tiene razón. Desde que monté mi empresa he pasado de tener unas ocho horas de programación delante del ordenador a tener unas jornadas aún más largas en la que la mayor parte del tiempo la destino a hablar, o leer y escribir, y planificar. Últimamente ya no programo tanto como antes.

La principal diferencia radica en cómo se afronta la jornada laboral desde cada punto de vista. Quiero decir, un jefe, directivo, gerente… trabajará haciendo pequeñas tareas de corta duración y muy seguidas, una tras otra. Estas tareas tienden a ser tareas organizativas y comunicativas principalmente donde se involucran a otras personas (clientes, empleados o proveedores entre otros).

Por otra parte, un programador, creador o fabricante mide su trabajo en jornadas laborales o al menos medias jornadas laborales. El trabajo requiere mucha concentración lo que indica que se requieren muchas horas para llevarlo a cabo. Para estas personas, trabajar en un ambiente donde se suceden las reuniones de dos a tres por día es un desastre y merma la productividad. Esta imagen muestra de forma gráfica lo que intento decir en este punto.

Por ello, si eres un programador y estás frustrado porque ves que no tienes suficiente tiempo para dedicar a un proyecto específico. Para todo lo que estés haciendo, apaga el teléfono, enciérrate en algún sitio durante un día si hace falta y concéntrate en desbloquear tu mente y progresar.

Si eres un administrador, gerente o directivo concreta tus tareas, tu agenda y organización semanal, intenta improvisar lo menos posible y realiza antes las tareas más pequeñas y livianas para obtener una sensación de que avanzas más rápido antes de enfrentarte a una de las tareas más grandes que tengas planificadas para el día en curso.

Sobre todo y ante todo, hay que aprender a respetar la forma de trabajo de cada uno de los puestos y poder y saber adaptarse a cada una de las situaciones.

Habiendo estado en los dos frentes puedo decir a los gerentes que un programador necesita entender el problema a ser desarrollado para poder traducirlo al lenguaje en el que debe programar la solución y esto lleva su tiempo porque debe comprobar lo desarrollado poco a poco y finalmente en conjunto. Empleando Scrum se intenta que la mayor parte del entendimiento del problema se haga en común y se realicen tareas lo más pequeñas y simples posible para ocupar el menor tiempo posible y, aún así, la unidad de medida mínima es la hora y hay tareas que pueden estimarse en planning poker hasta en 20 y 50 horas.

También puedo pedir a los programadores comprensión ante el comportamiento de los gerentes. Realizar tantas tareas pequeñas a lo largo del día hace en ocasiones que se eternice y si no se recibe una retroalimentación adecuada y el stress se presenta, puede estallar una disputa en base a considerar que no se está realizando el trabajo acordado o se toma demasiado tiempo. En este tipo de tareas tan largas, conviene marcar hitos (como checkpoints) que puedan visualizarse en algún sitio, como el tablero de Scrum, y permitan al gerente o directivo ver progreso sin interrumpir.

¿Qué problemas organizativos has tenido con tu jefe o empleados? ¿Muchas reuniones que consideras tóxicas o por el contrario muy útiles y satisfactorias?