La oposicion al cambio

En el mundo del software (y supongo que de todos los trabajos en general) la mayoria de personas son reacias al cambio. Si es un subordinado te dira cosas como:"esto no lo comprendo", "asi no se como trabajar", "yo creo que asi es peor", etc... y si es un jefe se reira de ti o te tratara de forma condescendiente.

Ojo, el cambio no siempre es bueno. O si? es dificil determinarlo. Por lo general, se puede tomar como axioma que el cambio es bueno cuando se puede demostrar que algo no funciona. Pero cambiar algo que funciona... es peligroso.

Todo el mundo que ha trabajo en el mundo del software sabe que una idea que ha tenido siempre ha tenido mas retractores que apoyos (sobre todo en los superiores). La claves para conseguir cambio es:

- Tamaño. Si un cambio es muy grande lo tienes que dividir. Y esos cambios (que han de ser pequeños) han de conseguir una victoria lo mas rapido posible. Como no se muestre algun indicio de valor al cambio enseguida se echara para atras y restara credibilidad a los impulsores.

- Apoyos. Hay que buscar apoyos. De jefes, de subordinados, de iguales... de los que sean pero los cambios son como las politicas. Para el exito de un cambio es mas importante que parezca bueno que realmente sea bueno el cambio.

- Fuerza de voluntad. No hay que desanimarse porque el cambio no parezca servir. Y si realmente no es bueno eso no significa que los impulsores del cambio no puedan tener buenas ideas en el futuro.

- Presentacion. Este es posiblemente la clave mas importante para que un cambio tenga exito. Hay que presentar la idea bien y tiene que ser entendible para el publico al que va orientado.

Recordar las cosas

Cuando un lider del proyecto quiere comunicar un hecho de importancia que quiere que todo el equipo de desarrollo tenga en cuenta (por ejemplo; la fecha de entrega de la ultima version es el dia 30 del mes que viene)  realiza una accion para comunicarlo. Esta acción siempre la piensa como algo definitiva. Puede ser algo registrable (como mandar un correo con importancia alta) o algo mas grafico (como una reunion con todo el equipo). El lider piensa que, con esta acción, todo el equipo conoce ya el hecho de importancia, lo tendra en cuenta siempre y le dara el mismo valor que él. NADA MAS LEJOS DE LA REALIDAD.

El hecho que el lider ha expuesto es importante para el lider porque esta alineado directamente con su trabajo y es un hito para él pero si los miembros del equipo no tienen este hecho importante como un hito directo en su trabajo diario entonces tenderan a olvidarlo o no lo olvidaran pero no le daran el mismo valor al hecho importante que le da el lider (siguiendo con el ejemplo de la fecha de entrega, los programadores no le daran importancia a la fecha ya que los programadores solo ven importantes sus hitos, es decir la tarea de una semana que les ha tocado y como mucho la tarea siguiente pero no les importa tanto que el dia 30 se tenga que entregar la version).

La unica forma, real, de solucionar esto es tener reuniones periodicas con el equipo y comentar las tareas individuales de cada uno alineandolas con el hecho importante. Pero ojo, periodicas porque sino olvidaran el hecho importante.

Falta de horizonte

Un gran problema que tienen los programadores, ya sean jóvenes o viejos, es la falta de un objetivo. Es es una característica normal, no solo en programadores, el hecho de no tener muy claro que se quiere o si tenerlo pero no saber como conseguirlo y dejar pasar el tiempo hasta que surge algo que nos hace ponernos en el camino correcto.

Pero en esa espera pasan cosas curiosas y contradictorias; por ejemplo, todos sabemos que en un desarrollo, sobre todo si es largo, la programación se vuelve cíclica (desarrollos nuevos-pruebas-incidencias-desarrollos nuevos-pruebas-etc…) y esto hace que “siempre sea todo los mismo” (misma tecnología, mismos problemas, mismos procedimientos, etc..). Por lógica, cualquier cosa que se salga de la rutina debería ser bien recibida, al menos de primeras. Pues la experiencia me ha demostrado que no. Los programadores no quieren cosas nuevas, prefieren seguir en el ciclo que se ha convertido la programación del proyecto.