Archivo mes Octubre, 2011
CUENTO: "EL KARMA DE CIERTAS CHICAS" – JUAN FORN
Léalo en la pag. “Almacén de cuentos” de este blog
Oferta de Empleo: Técnico Informático (Arriondas, Parres)
Contrato temporal con posibilidad de fijo discontinuo (8/10 meses al año). Media jornada en horario flexible. Salario a convenir
Requisitos y Funciones diseño web, photoshop, pasarela de pago, dominio de adwords, posicionamiento natural (abstenerse candidatos/as sin los conocimientos necesarios)
Enviar curriculum vitae a trabajo@canoasdelsella.com
Teatro antes de comenzar la jornada laboral
Hoy fue un inicio de jornada laboral sui generis, el grupo de teatro Rumbos de Pinar del Río se presentó en mi trabajo con una obra de menos de 20 minutos de duración. Reímos mucho con la puesta de El espejo, una pieza simpática, con muchos matices de la realidad que sirvió para que el día se iniciara con alegría. Ojalá hubiera muchas mañanas así. Lea el resto de la entrada »
Aprendiendo a enseñar, enseñando a aprender
Constantemente me veo en la situación de enseñar algo a alguien y casi siempre dentro de el frenético estilo de vida al que la sociedad me tiene acostumbrado no tengo tiempo de producir la documentación necesaria y los procesos para poder formarlo “en condiciones”. Que ese alguien encuentre el tiempo para leer y estudiar esa documentación es una segunda parte del problema. Pero lo peor sucede cuando sí se produce esa documentación, sí se lee y se estudia y los resultados de aplicar el conocimento no son los deseados.
Y esto me ocurre tanto a la hora de enseñar como de aprender. Así que he aprendido técnicas orientadas al liderazgo y las he enfocado al aprendizaje. No es algo innovador y tampoco reinvento la rueda.
Dos no se pelean si uno no quiere. ¿Pasa lo mismo en la transferencia de conocimiento? En principio se necesita que la persona que tenga que enseñar esté dispuesta a hacerlo (mal vamos si no) y la que tiene que adquirir cierto nivel de competencia tiene que estar igualmente dispuesta y motivada.
Motivación y Competencia
<<Primer día en la oficina: llego con energía, tengo un sitio limpio – y si no lo está, lo limpio – me hago con un ordenador, los programas que uso para mi trabajo funcionan (espero), tengo un boli rojo, uno azul, un lápiz y una goma al lado de un cuaderno que huele a nuevo y que tiene el mimbrete de mi empresa. Estoy esperando y, tarde o temprano, aparecerá alguien con algo para mí. Sí ahí viene un chico, delgado, con gafas, pelo largo y enmarañado: “Necesito tu ayuda para arreglar un defecto en uno de nuestros productos para que el cliente pueda realizar una operación antes del miércoles”. Oh sí, soy un buen programador y tengo que arreglar un bug, perfecto, tengo un objetivo que es específico, medible, alcanzable, relevante y definido en el tiempo que es ayudar a un importantísimo cliente a ejecutar una necesidad de negocio crítica con nuestro producto estrella. O no, pero da igual porque estoy motivado, ¡sí!, ¡sí!, estoy motivado, hell yeah!
¿Pero cómo lo hago?
“La descripción del problema está en la aplicación de gestión de incidencias, incidencia número 6532, tienes que descargarte el código a tu ordenador que esta en el repositorio de código en tal ruta, reproducir el problema y cuando lo identifiques, vienes y me lo dices”.
Me ha dicho exactamente lo que necesito saber: haces tal, cual y pascual. Excelente, lo voy a hacer, estoy motivado.
2 horas después sigo tratando de reproducir el problema, no tenía cuenta en el gestor de incidencias ni en el repositorio, he preguntado y lo he conseguido, no me compila bien el código, no entiendo el sistema, el error no me sucede, va a venir el greñudo y va a pensar que soy un paquete, soy un paquete, mierda, soy un incompetente y lo peor es que soy consciente de ello, ¿por qué he cambiado de curro, con lo bien que yo estaba?, Dios mío, ¡ahí viene!
“¿Qué tal, cómo vas?”
Suelto un chorreo de excusas, un par de maldiciones y juramentos aderezados de tartamudeo constante. El gafas no se inmuta, solo espero que no me humille quitandome el ratón y resuelviéndolo con dos clicks. No lo hace, ¿qué hace? me habla, me pregunta hasta dónde he llegado, cuál es el problema que tengo, se lo explico con un poco más de caaalma, asiente, me pregunta que qué creo que debo hcer, sugiero contactar con el cliente para ver el defecto en primera persona, niega, “¿qué otras opciones tienes?”, creo que me faltan cosas, afirma, me dice que las busque, las encuentro (¿¿de dónde han salido esas carpetas??), sonríe por primera vez, me pregunta que si sé cómo seguir, afiiirmo, se levanta, “luego vengo”, se va.
3 horas más. Al principio bien, luego mal. Reproduzco la incidencia pero no sé por qué sucede. He investigado el producto, entiendo cómo está diseñado, parece que problema reside en un paquete común que utilizan varios productos de la empresa. Parece que tienen un sistema de test automático bastante sólido pero, ¿toco, no toco? ¿Romperé todo? Me van a despedir, y sin indemnización porque estoy en periodo de prueba, y precisamente ahora, tal y como está el patio…
Ahí viene el jevi melenudo, espero que pase de largo.
“¿Qué tal, cómo vas?”
Mierda.
“¿Necesitas ayuda?”
Sí. “No. Sólo estoy pensando en las implicaciones del cambio que tengo que hacer”.
“¿Cuáles son?”
Pues que lo voy a romper todo, que no sé lo que estoy haciendo, sí, tiene buena pinta, pero Dios sabe, porque no hay diagramas UML, ni documentación escrita y nadie me explica nada. “Creo que puede afectar otros productos”.
“¿Y qué vas a hacer?”
No sé, dímelo tú, capullo. “Creo que el sistema tiene bastantes casos de test”. Que seguramente no estén actualizados.
“Aham”.
“Quizá podría pasar los tests tras actualizar mi código”. Ahora es cuando me dices que no puedo confiar en los tests.
“Aham”.
“Y pasar el código a producción después”. No vaya a ser que la líe parda antes de tiempo.
“Correcto. Aquél es Carlos, él se encarga del test automatizado”.
El tal Carlos es un friki enjuto con la boca llena de dientes y con réplicas de armas sobre su escritorio. Pregunta si mis tests unitarios garantizan el correcto funcionamiento de por lo menos el 80% de mi código, le digo que esa es la intención, dice que “aquí la mayor parte de nosotros utilizamos TDD“. Me dice que suba el código mañana a la rama de desarrollo y que el servidor de integración continua comprobará que nada se rompe antes de publicarlo.
Al día siguiente el melenudo se sienta a mi lado justo en el momento en el que el informe web dice que mi código funciona y no rompe nada.
“Hay 10 incidencias más que hay que resolver antes del final de la semana, el viernes nos juntamos para repasar el informe web”.>>
¿Y qué?
Pues que hay que ajustar el estilo de formación con el nivel de motivación y de competencia de la persona a ser formada.
Veamos los estados por los que pasa el programador de la historia:
- El estadío Flipao descerebrao: Al principio la motivación es alta y el nivel de competencia es bajo o null.
- Iniciado desengañado: Según va adquiriendo un conocimiento más profundo de la tarea, es decir un nivel de competencia mayor, va entendiendo el alcance y dificultad de la tarea, con lo cual su motivación cae.
- Experto acojonado (o cínico). Que ha alcanzado un nivel de competencia más bien alto pero su motivación es baja o variable ya que le falta un nivel mayor de seguridad en sí mismo para poder ser totalmente independiente.
- Experto autónomo o Crack. Es la parte de la historia que no está escrita: El programador resuelve las 10 incidencias sin ningún apoyo antes de mediodía del viernes, ya que tiene un nivel de competencia alto (cada vez mayor) y su motivación es muy alta, porque ha adquirido seguridad en sí mismo, sabe lo que tiene que hacer y lo hace sin tener que depender de nadie, que es lo que todos preferimos.
Es decir, mientras que su nivel de competencia está casi constantemente en aumento, su motivación empieza alta, va bajando hasta tocar fondo y de ahí sólo le queda subir, aumentando hasta su nivel máximo. Una cosa así:
En esencia se podría decir que lo ha conseguido solo, pero nunca hubiera podido llegar hasta el final del proceso si el greñas no se hubiera adaptado a la fase en la que se encontraba el programador de la forma que describe el modelo de liderazgo situacionalde Paul Hersey y Ken Blanchard descrito en sus libros:
- Cuando el programador estaba en flipao descerebrao el melenudo ha usado un modelo absolutamente directivo en el que le ha dicho qué hacer exactamente y cómo, aprovechando la primera interacción para definirle el objetivo en toda su extensión. Esto es, Directing: decir qué hacer.
- Cuando estaba en iniciado desengañado ha buscado una interacción mayor, reduciendo su nivel de dirección e incrementando el nivel de apoyo, pero sin dejar de decidir qué hacer en cada momento. Esto es el Coaching tal y como lo conciben Hersey-Blanchard: vender qué hacer.
- En su momento cínico de experto acojonado – que sabe, pero no se atreve – el hijo del metal lo único que hace es apoyarle y reforzar sus conclusiones y decisiones. Supporting: que implica participar en la toma de decisiones, pero no decidir que hacer.
- Finalmente da un paso para atrás ya que – en cuestión de arreglo de incidencias – ha formado a un crack. Delegating: dejar hacer. Qué bonita sería la vida si todo fuera así de sencillo.
Aprendizaje y liderazgo
Vienen unidos de la mano, ya que si contrastamos el método de Hersey-Blanchard con el diagrama de las 4 fases de la competencia de Gordon Training International reproducido arriba del todo vemos cómo el programador empieza desde un estado de incompetencia inconsciente – cuando está ordenando sus bolis en la mesa y no sabe la que le viene encima – hasta un estado de competencia inconsciente, probablemente cuando ya lleva resueltas 4-5 incidencias y ya ni se plantea qué pasos tiene que dar para resolverlas.
Pues así, todo
El proceso – que parece tan fácil – realmente no lo es, ya que me requiere estar constantemente atento para entender en qué punto está la persona a la que estoy instruyendo ya que hay momentos en los que no hay progreso y hay que volver un paso para atrás o incluso a la primera casilla del tablero. Por otra parte, también sucede que un objetivo le entre a alguien con poca motivación, en cuyo caso hay que acalarar si es porque ya sabe de qué va el percal y le huele a cuerno quemado – que viene a ser un iniciado desengañado en toda regla y tiene la solución de “vender lo que hacer” – o bien es porque el individuo está realmente desmotivado con las tareas que forman la esencia de su trabajo, lo cual es mala cosa.
Desde el punto de vista del que aprende, es también complicado en ocasiones hacer entender a la persona que te forma en qué punto estás y qué tiene que hacer, pero la gente más experta lo tolera inmediatamente.
Evidentemente cada persona en un momento dado de su vida está en diversos puntos del desarrollo de una habilidad, como en un juego de rol, y por lo tanto un formador o un líder requeriría combinar todos los estilos a la vez para hacer progreso en una tarea que implique varias habilidades.



