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.