No dejes que la tarea se muera

Cuando le asignas una tarea a un programador el programador debe tener claro en que consiste, cuando debe empezar y cuando debe acabar. Esto lo tenemos todos bastante claro pero ¿realmente se cumple? En la mayoría de los casos no debido a factores como la perdida de motivación, a las prisas por terminar o al estar demasiado ocupado.

Al principio de una tarea es fácil planificar y determinar en que consiste una tarea pero una vez hecho esto el seguimiento se reduce a dos preguntas ¿como vas? y ¿cuanto te queda?.

El gran problema (ademas que la correcta definición y seguimiento de una tarea lleva su gasto en tiempo) es que el tiempo corre y al final hay muchas cosas que hacer antes del plazo por lo que hay que priorizar tareas y eso siempre deja en ultimo lugar al seguimiento y la retroalimentación de la documentación de la tarea.

Esto hace que el final de una tarea sea un acuerdo verbal entre el programador y el responsable. No se ha indicado como se ha terminado cada punto de la tarea que se estableció al principio, si ha habido cambios, problemas que han generado retrasos, riesgos, puntos que han quedado sin terminar, etc. En conclusión, se ha desarrollado código pero la tarea ha muerto.

No existe tarea sin todo lo que implica: definición, seguimiento, rediseño, etc. Mantén siempre el seguimiento, retroalimenta el diseño y la tarea en general con lo que va pasando, identica riesgos, deja anotado lo que alta por hacer, etc.

Es cierto, hay épocas de prisas y esto implica poner el foco en lo mas importante "picar" pero ten siempre presente que dejar que las tareas se mueran es una metrica de que el proyecto esta mal.

Ten piezas en el tablero

Hay veces en el ciclo de vida del desarrollo de un proyecto donde la situación parece que supera a todo el equipo (o no es por superación pero no esta claro que camino coger). Solo un par de ramas de trabajo parecen importantes y parece que sobra gente. En ese momento, al responsable del proyecto le entra la necesidad de quedarse solo con lo justo. En todo, tanto en lineas de trabajo como en personas. Sobre todo en personas.

No hace falta una situación critica, puede ser simplemente que parece que las personas encargadas del desarrollo de proyecto no están progresando nada por cualquier razón y el responsable tiene la necesidad de "reducir el problema".

Sea cual sea el motivo que lleve al responsable a reducir el equipo, hay que cambiar de idea y buscar otro planteamiento:

• Puede que el problema sea una liena de trabajo erronea
• Puede que se necesiten nuevas divisiones dentro del grupo
• Puede que los miembros del equipo necesiten formacion
• ...  

Hay que mantener el equipo de desarrollo. Ampliarlo si cabe. 

Como en una partida de ajedrez, puede que el intercambio de piezas te de la sensación de seguridad pero sin piezas te limitas el numero de jugadas, de opciones, de posibilidades... Puede que cueste coordinar mas a un grupo mas numeroso pero es el talento del conjunto lo que hace grande a un grupo no "el brillo se su parte mas reluciente".

El símil del cuadrado

Este símil viene muy bien para explicar de manera sencilla y rápida porque es necesario mas definición inicial (funcionales, requisitos, historias de usuario, etc..) para conceptos como:

•           Empezar un desarrollo software.
•           Empezar una definición de maquetación.
•           Empezar una definición de usabilidad.
•           Etc…

Opción A: Si se define claramente que se quiere un cuadrado (en el símil es el software, maquetación, etc…)

Las personas que tienen que hacer el cuadrado pueden dividirlo como mejor les venga para poder implementarlo

Implementar las partes por separado

Así al juntar lo implementado se tiene más posibilidades de que se parezca al cuadrado original

Opción B: Si lo que se hace es definir las partes suponiendo que al final se conseguirá un cuadrado

Cuando se junten hay muy pocas posibilidades de que parezca a un cuadrado

Prepara el Sprint

Tras el uso de la metodología Scrum en varios proyectos te das cuenta de que el equipo de desarrollo nunca va a ser responsable del desarrollo. El equipo, por lo general, esta formado por personas que solo quieren programar. No quieren tener una visión global del proyecto y no quieren hacerse responsable del trabajo de los demas.

Esto implica que al final se tenga un jefe de proyecto o un Scrum master o product owner mas parecido a un jefe de proyecto que al puesto que Scrum indica que debe tener. Si al final te decantas por usar Scrum pero con responsables entonces ten en cuenta varias cosas:

- Antes de la reunion de cierre de Sprint recuerda a la gente que lleven el estado de las tareas y el estado de lo que le quede sin finalizar preparado.

- Ve con el Sprint preparado a la reunión de definición del Sprint. Es decir, ya ten preparadas las tareas que tiene asignado cada miembro del equipo para el siguiente Sprint. En la reunión habla con los miembros del equipo de las tareas. En función de lo que se diga entonces se puede modificar. Pero llevalo preparado. 

Si estas ocioso propon un proyecto.

A todas las personas que hemos programado nos ha pasado que en algún momento de nuestra carrera hemos pasado periodos de estar ociosos completamente o casi completamente. Y estos periodos pueden durar meses.

Por lo general, el motivo es coyuntural: el proyecto entra en un periodo en el que se decide el rumbo que debe tomar, la empresa no tiene muy claro donde encaja mas tu perfil, el proyecto esta sobredimensionado, etc.. Pero sea cual sea el motivo, el animo del programador empieza a descender ya que aparecen sentimientos deprimentes: quieren que me vaya de la empresa, estoy perdiendo el tiempo, etc..

Puedes empezar a estudiar y a hacer cursos como loco de cualquier cosa y/o tecnología. No es mala solución pero si la situación se alarga entonces las energias que tenias para estudiar desaparecerán.

La mejor solución es que enfoques la situación como si tu jefe te hubiese mandado hacer una propuesta de una mejora completa del proyecto en el que estes. Por ejemplo, si trabajas en un proyecto que esta implementado en Java Structs entonces propon implementarlo con Spring Boot. Y no te quedes en un documento, implementa código.

Como abordar un problema concreto

Cuando se tiene se tiene que abordar un problema concreto (por ejemplo te piden que hagas una aplicación en Java o uses Docker para desplegar tu aplicación), se tiene que afrontar como una serie de tareas no ordenadas. Estas tareas se pueden dividir en dos:


- Tareas informativas: Son las tareas en las que adquieres conocimientos para formarte pero no da una productividad directa.

- Tareas creativas: Son las tareas que van a dar como fruto la solución al problemas que se esta abordando. Son las tareas que dan una productividad directa.

Por nuestra naturaleza humana, las tareas informativas son mas divertidas y enriquecedoras que las tareas creativas por lo que estamos mas predispuestos a abordar tareas informativas. Para que te estresen las tareas te recomiendo:

1º Haz la división del problema en tareas.
2º Identifica cuales son las creativas y cuales son las informativas.
3º A por las tareas:
3.a Un las horas de trabajo que estes en mejor forma o estes mas predispuesto aborda las tareas creativas.
3.b Cuando te sientas mas bloqueado o con menos ganas aborda las tareas informativas.

Casos:

1º El problema no tiene tareas informativas porque ya soy un experto: Es dificil de creer que no te quede nada por aprender (y mas en el mundo del software) pero lo que si que puedes hacer es (en la hora de las tareas informativas) abordar tareas informativas de otros problemas.


2º No tengo suficiente con mi horario laboral y sigo en la oficina despues de la hora o trabajo desde casa: Este tiempo debe ser completamente de tareas informativas.

3º Me quiero especializar en tareas informativas. No quiero hacer tareas creativas: Esta bien especializarse pero hay que ser franco, si solo te mueven las tareas informativas y no quieres hacer nada de creativas (o un numero muy bajo de tareas creativas) entonces existe un problema porque ninguna empresa te va a pagar para que solo te formes. La formación tiene siempre un fin productivo. Lo mejor que puedes hacer es buscar otras orientaciones como ser formador de otros profesionales.     

Vértigo técnico

Cuando en proyecto de desarrollo de software se ofrece formación tecnológica, tanto si va a usar dicha tecnología en el proyecto como si no se va a usar, el técnico siempre mostrará predispuesto a realizar dicha formación. Es normal, es bueno para el técnico y para el proyecto en general. Pero es muy diferente aprender que producir. Es decir, se puede producir un efecto en la respuesta del técnico que confunda y parezca extraño desde la gestión ya que el técnico puede estar muy dispuesto a formarse pero puede puede mostrar muchas pegas a la hora de desarrollar tareas productivas con lo que ha aprendido. Esto puede parecer contradictorio pero tiene mas sentido de lo que parece.

Desarrollar una tarea productiva tiene asociadas una serie de características que no son técnicas como son:

• Se le pedirá al técnico una fecha fin.
• Se le pedirá al técnico una calidad.
• Se le pedirá al técnico que explique que es la mejor solución.

 y por supuesto es mas fácil para técnico (y para cualquiera) garantizar estos puntos usando la tecnología con la que trabaja siempre que una tecnología que acaba de aprender.

A este efecto lo llamo vertigo técnico.

Como solucionarlo:

• Mas formación del técnico: para que adquiera mas conocimiento y pueda garantizar todos los puntos anteriores.
• Selección del técnico: puede que el mismo técnico no quiera moverse de su zona de confort. Si este es el caso se debe considerar la opción de no pedir al técnico que aprenda algo nuevo y seleccionar a otro técnico en su lugar.
• Comprensión en la gestión: Por parte del gestor hay que entender que una nueva tecnología convierte a un técnico senior en uno junior y no se le puede pedir resultados tan rápido como se hacia antes.