El cambio de contexto

Cuando se abandona el trabajo de mas bajo nivel y se empieza con tareas de gestión de equipo de desarrollo de software la primera actividad que te golpea en la cara y no sabias que venia es tener que llevar varias cosas a la vez. Si le preguntas a la mayoría de personal que no han gestionado un equipo te dirán cosas como:

• Tienes que planificar.
• Habla con el cliente.
• Hacer seguimiento de las tareas.
• Etc..

Pero, simplificando, todo al final se divide en tareas que tienes que ir asignado a miembros del equipo para que las lleven acabo y esas tareas tienen sus caracteristicas:

• Estado de desarrollo.
• Complejidad.
• Prioridad.
• Etc...

Por lo que te encuentras gestionando multiples tareas (de las cuales una puede ir adeltanda, otra atrasada, una mal estimada, una bloqueada, una efectada por errores de los miembros del equipo que la llevan a cabo, etc..) a la vez y seguramente el mismo dia tengas que atender a varias.

Las dificultades del cambio de contexto son muy importantes y son dificiles de detectar. Se puede notar sensaciones muy frustrantes ya que puedes tomar decisiones como si llevas 3 tareas dejar una de ellas de lado por razones completamente personales y terminar las otras dos. Esto es un error enorme y cuando se hace balance lo primero que se pregunta uno mismo son cosas como :¿ Por que hice esto? ¿ Que ha pasado aqui?

Desafortunadamente no conozco ninguna solución para gestores de equipo con este problema pero al menos identificar que este puede ser el problema que se tiene es el primer paso para poder solucionarlo.

La importancia de cumplir un hito

Para el que gestiona un equipo de trabajo, la importancia de cumplir los  hitos fijados es fundamental. Que una tarea no se termine a tiempo y con la calidad suficiente es un problema que no se le va de la cabeza y tener que retrasar una fecha de entrega es una linea roja que si se traspasa empieza la debacle:

• Todo parece estar mal hecho.
• Los jefes nos miran con cara de decepción.
• Salen mas errores de la nada.
• ...........un caos

Por increíble que parezca, para un programador un hito no tiene ningún significado especial. Si se cumple bien y si no pues que me den mas tiempo. No conozco la manera de cambiar este comportamiento en un programador pero lo que si se puede hacer es "evolucionar al programador", es decir, crear un puesto intermedio donde tiene que gestionar a otros programadores y hacerse responsable de algo y hacer que un programador ocupe dicho puesto.

¿Como se le asigna el puesto a un programador? Se tiene una reunión con él y se le explica que:

• Tiene que ser una persona de referencia para todos sus programadores y para los cargos superiores que quieran conecer algo de la parte de la que es responsable.
• Se le indica que se le va a presionar mas y que CUMPLIR LOS HITOS SON IMPORTANTES.

Con esto ya se tiene al programador donde se quiere para que comprenda la importancia de cumplir los hitos. A partir de ese momento lo que hay que hacer es ir poniendole hitos periodicamente y controlar que los cumpla. En los primeros hitos que no cumpla, seguramente lo que te diga es que por los motivos que sea no puede llegar. Este momento es clave. Tienes que indicarle que si no llega que te busque la solución para llegar; ya no vale el no voy a llegar. Puede darse el caso que es cierto que no llegue (los problemas son insalvables), en este caso lo que tenemos que hacer es que no plante una alternativa, es decir que si no puede entregar todo lo comprometido pues que entregue algo equivalente y que el jefe de equipo considere valido. Pero el hito hay que cumplirlo.

Manejo de equipo. El grupo

El grupo de desarrollo lo mas normal es que te venga impuesto. Seran muy raras las ocasiones en las que puedes elegir. La mejor que tienes es olvidar el hecho de que tu no has elegido a la gente y partir siempre del punto de que tienes que desarrollar un trabajo con el equipo que te han dado.

El grupo no se puede cambiar nunca completamente (siempre con el tiempo podrias cambiar a alguien pero lo normal es que se queden todos) y este hecho es inmutable por lo que lo primero es alinear los objetivos de desarrollo con el grupo que tenemos. Esto le dará un estructura al grupo que servirá para completar el grupo. La estructura siempre sera un arbol con varios ramas:

Al tener estructura, se dispone de varias opciones que antes no tenias:

• Puedes asignar roles intermedios para mejorar las habilidades de los miembros del equipo. A estos roles intermedios les tienes que dar guias de lo que quieres que hagan pero no olvides que una vez que empiecen con su nuevo rol son ellos los que tienen que cumplir con el rol y que lo haran como ellos creen que tienen que hacerlo. Esto tiene dos resultados posibles:
• No cumplen con el rol. Por lo que tienes que  hacer que cumplan en rol.
• Si cumplen el rol. Analiza como lo cumple ya que en la mayoria de los casos lo cumplirán de una manera que no esperabas y te puede servir para mejorar (feedback)
• Tiempo. La estructura te obliga a delegar por lo que tendrás mas tiempos que puedes invertir en procesos de mejora.

Evita la sensación de que una persona sobra del grupo. Puede que realmente un miembro del equipo estorbe en el grupo y sea mejor que no esté en el grupo pero no olvidemos dos cosas:

• Es muy dificil que un miembro del grupo sea un estorbo y que no puede aportar nada de nada(Aunque se puede dar el caso de que si que lo sea por lo que ojito ;)=).
• Es una reacción muy comun librarse de lo que estorba lo primero (sea cual sea el contexto) pero esta reacción es mas un sintoma de no querer calentarse la cabeza que una reacción inteligente.

Una lección muy valiosa en el ajedrez es que evites cambiar piezas por cambiar porque no sabes que hacer con las piezas. NO SABES COMO USARLAS PARA GANAR LA PARTIDA. Si crees que tienes que prescindir de un miembro del grupo  primero piensa en dos cosas:

• No quiero a ese miembro del grupo por que realmente estorba o por que no se como usarlo?
• Estorbe o no estorbe en realidad, puedo usar a ese miembro del grupo de alguna manera no convencional para que me sirva? Por ejemplo, como una justificación de que no has conseguido objetivos porque no tienes suficientes miembros validos en el grupo para acometer el desarrollo.      

Decir lo que otro no quiere oir

La evaluación de un trabajo siempre es complicada por muchos aspectos:

- Calidad del servicio.
- A tardado mucho o poco.
- Ha dejado su trabajo mantenible.
- Ha usado la ley del minimo esfuerzo o ha hecho todo lo que ha podido.
- Como condiciona el resultado de esta evaluación para futuras tareas.
- Etc..

La lista es muy larga y cada evaluador puede usar las que mas le guste pero lo mas dificil de evaluar no es la lista de aspectos a tener en cuenta, ni si los aspectos se estan evaluando correctamente. Lo mas dificil es tener que decirle a alguien algo que no quiere oir sobre su trabajo.

La mejor forma de afrontarlo (lo enfoques como lo enfoques) es plantear la charla que uses para contarle lo que no quiere oir de forma constructiva, es decir; en todo momento di cosas buenas y di las cosas malas como continuación (o conclusion) de una cosa buena. Por ejemplos, si el problema es que tienes que decirle a alguien que no sabe mantener el control en una situación de estrés puedes decir:

             - "Eres una persona que habla claro y tienes capacidad para dominar una situación de estrés pero en ciertas ocasiones he visto que ... has perdido la partida (di esto con cara de complicidad) porque te ha faltado ese ultimo esfuerzo de control al final... tienes que pulir eso".

En resumen, le has dicho que si ha tenido 5 situaciones donde deberia haber controlado la situación no ha controlado como minimo tres por lo tanto es un parcial negativo. Ha fallado. Es un punto negativo pero lo comprenderá y lo aceptará mejor que si se lo dices claramente.

Estas siendo falso? puede que si o puede que no. Pero estas son ese tipo de situaciones en las que lo importante es el objetivo no los medios. Pero no puedes olvidar la moralidad ¿verdad? Te dices voy a decir la verdad y que lo acepte. Al principio me odiara pero mas adelante me lo agradecerá. Esto si que es falso (ademas de iluso). A nadie le gusta que le digan claramente los fallos que ha cometido en el trabajo pero a todo el mundo le gusta QUE LE MARQUEN EN CAMINO. Y eso es lo que estas haciendo. Solo tienes que decir la frase anterior (la frase de decierle suavente que no sabe afrontar situaciones de estres) como una directriz de como puede conseguirlo.

Y cuando descubres que tienes que mandar

Cuando te asignan un grupo de programadores para acometer un desarrollo, te das cuanta de muchas factores que no parecen tener con el propio trabajo en si (con el software):

• Puede que te hagan caso y puede que no
• Que hacer cuando le dices a alguien que haga una tarea, lo hace y el resultado no es lo que quieres y te dicen que si lo es.
• Que hacer si ves que claramente no esta al nivel que necesita el proyecto
• Puede que todo empiece bien y se vaya degradando aspectos como el interes, la intensidad, etc..
• Y si no cumplen su horario
• Y si les llamas la atencion por algo y se nota que no les ha gustado porque piensan algo como: Siempre yo. Es que este no hace nada. 
• Y si tienen temas sindicales que les hacen hacer mal su trabajo
• Etc...

No hay una receta mágica para estas situaciones y desde luego no hay receta que dure desde el principio hasta el final del desarrollo de una aplicación software. Debes pensar en desarrollo como en un castillo de piezas de distintas formas que estan unas encima de otras manteniendo un equilibrio:

A medida que avance el desarrollo, los distintos factores que he indicado al principio ejercen presión sobre las piezas y si no se actua contra esos factores pasara lo siguiente:

Algunas piezas seguirán en pie, otras seguirán en equilibrio ellas solas, otras estarán a punto de caer,etc... en general un desastre ingobernable. 

A las conclusiones que he llegado para  que no suceda un desastre ingobernable y se mantenga el equilibrio hasta el final son las siguientes:

• Nunca acometas una acción intimidatoria si no estas seguro de que la respuesta va a ser favorable. Desde una simple llamada de atención hasta una bronca delante de todo el equipo, si no estas seguro de que es útil y de que va a acabar bien mejor no lo hagas y espera el momento oportuno.
• Nunca dejes la parte tecnica de lado completamente. Recuerda que al fin y al cabo estas mandando lo que se tiene que programar y como se tiene que programar. Si tus programadores no ven que al menos estas a un nivel aceptable entonces no respetaran tus decisiones tecnicas,
• Establece las metricas que consideres oportunas para el seguimiento y mejora y se constante en ellas. Si las abandonas que sea por decision propio y no por la desidia de tus programadores. 

Diseño. Cuando modular y cuando no

A la hora de diseñar cualquier tarea se debe de plantear dos cosas:

•           Ya existe algo que lo pueda hacer
•           Si no existe, hacer algo que sirva para solucionar esta tarea y una problemática igual en otro sistema.
• 
  

Hacer algo genérico para resolver tu problema (tu tarea) siempre es la mejor solución pero en teoría. Si tenemos en cuenta aspectos prácticos como rendimiento, líneas de código, sostenibilidad, etc… La regla es:

•           Si la solución es exactamente igual para todos los sistemas si se debe algo genérico para todos.
•           Si casi todo es igual pero hay pequeños cambios pero muy significativos entonces lo mejor es buscar una única solución si pero que se implemente como se necesite en cada sistema.

Cuando todo fallo

El fin de año es una época para hacer balance de como ha ido el proyecto  desarrollo de software. Podemos pensar en todo lo que hemos hecho, en todas las decisiones que hemos tomado, en como hemos afrontado los problemas, etc..

si todo ha ido genial entonces hasta el próximo post.

Si todo no ha ido tan genial entonces sigue leyendo.

Ahora que se hace resumen, me doy cuenta de cosas, aspectos, decisiones, etc… (métodos en general) que debería haber sido de otra manera. Somos humanos y todo el mundo se puede equivocar. Lo realmente complicado de interpretar es que pasa con las cosas, aspectos, decisiones, etc… que fueron correctas en su momento, que ahora razonas y sigues pensado que fueron lo mejor que se podía hacer… pero aun asi fallaron o no fueron suficiente. Se pueden tomar de dos maneras:

• Puedes hacer lo mismo de otra manera. Aunque pienses que tu forma de hacer las cosas es la correcta puede que existan factores (como que tu equipo no asimila tus métodos o que tu proyecto software no tenga una arquitectura que se adapte a tus métodos) que lleven tus métodos al fracaso. Por lo que tendrás que adaptar tus métodos aunque no te parezca lo mas correcto,
• Puedes hacer otras cosas. Seguro que hay muchos métodos que no has probado y que pueden ser un revulsivo perfecto.

En general, probar otras cosas suele ser lo mejor. Sobre todo si el equipo de desarrollo ya ha manifestado ser contrario a tus métodos o ha mostrado indiferencia.