motivadores-¡Vaya! ¿Conque te han castigado?
Tom no se dignó a contestar. Seguía pintando entusiasmado, separándose de vez en cuando de la valla y observándola con mirada de artista.
Ben, que tenía en la mano una manzana muy apetitosa, se quedó con la boca abierta, pues no acertaba a comprender nada.
-Oye, Tom, me voy a nadar, ¿no quieres venir? ¿O es que tienes que trabajar?
-¡Hola, Ben! Estaba tan entusiasmado pintando la valla que ni siquiera te había visto.
-¡No dirás que prefieres trabajar a ir a nadar!
-Depende de lo que tú llames trabajo. A mi me encanta pintar la valla.

Mark Twain. Las aventuras de Tom Sawyer


Es posible que en otros sectores sea difícil contar con personas o equipos motivados, pero con programadores es, debería ser extraño. Por eso, las empresas de soft que se preguntan "Cómo motivar a los programadores" no suelen tener el problema en la plantilla, sino en la cultura de la organización.

Sin Semaforos¿Qué es mejor: gestión externa, o autogestión del propio equipo? ¿Es un criterio igual de válido, se trate de un equipo grande o pequeño? ¿Es esta una razón por la que la agilidad (equipos autogestionados) funciona mejor con equipos pequeños, y escala en arquitecturas fractales? ¿El criterio es también válido sea cual sea la cultura, o los valores del equipo? ...

Estas son algunas de las cosas en las que hace pensar este vídeo del experimento que se realizó en septiembre de 2009 en Portishead, un pequeño pueblo británico cerca de Bristol, al apagar los semáforos para dejar que se autoregularan los conductores.



BrújujaAplicar prácticas ágiles no siempre es agilidad, puede ser ingeniería concurrente.

"Scrum" y "Kanban" son prácticas de desarrollo incremental, las primeras basada en iteraciones y las segundas en el mantenimiento de un flujo continuo de tareas.

Cambiar las prácticas de gestión predictiva por prácticas ágiles con iteraciones cortas es Ingeniería concurrente: desarrollo gestionado (no autogestionado) basado en ingeniería de procesos más que en el talento del equipo, pero con solapamiento de las fases de desarrollo y entregas incrementales.

Normalmente decimos gestión ágil cuando quizá tiene más sentido hablar de gestión evolutiva...

Este es el mapa de conceptos que me sirve de brújula para no perderme en el laberinto de Scrum - Kanban - Scrumban - PMI Agile - Cascada - Gestión ágil etc. Aquí lo comparto para los que también le encontréis sentido.

Gestión de proyectos: diagrama de conceptos

 

Safe Creative #1306235311935

tio gilito

Como tengo instalado en la mesa de al lado al nuevo director de proyectos,(1) estoy viendo la presentación que prepara para aleccionar mañana a su equipo de gestores a "facturar". 

El título de la primera diapositiva es "¿Para qué existen las empresas?", y a continuación presenta con letra de gran tamaño, como remarcando que  "¡Toodo el mundo lo debería sabeeer porque es evideeente!: "PARA GANAR DINERO". 

Resulta tan obvio que acompleja no entenderlo. ¿Obvio?

¿En todas las empresas, es esta la meta de su emprendedor? Seguro que en muchas sí, pero también es seguro que otras han nacido para dar vida a proyectos ilusionantes por sí mismos.

Desde luego, sin dinero la empresas no tienen oxígeno, pero la diferencia es que en las primeras es el objetivo, y para las segundas, la consecuencia.

Quizá sea porque no sé de "bisnes",  pero me gustan más las segundas, y me da la sensación de que las primeras confunden el medio con el fin.

Hace poco me aconsejaba el director de negocio de la software factory en la que trabajo:(1) "El cliente no sabe lo que quiere. Copia y pega este informe que hice yo hace unos peses para Fulanitez, cambia los datos y ya tenemos facturado el estudio"  ¡?!

No le entendía, y sin duda él no habría entendido por qué yo no le entendía a él. Seguramente las dos visiones tienen razón: la una, en una empresa cuyo fin es facturar, y la otra en una empresa cuyo fin es construir soluciones.

Se me ocurre hacer un paralelismo con  la finalidad por la que algunas personas deciden ser médicos. Seguro que las hay que quieren alcanzar un nivel social y económico alto, y ven en la medicina una profesión adecuada para su objetivo, y seguro que las hay también que sencillamente, quieren curar enfermos.

Los primeros tienen que curar pacientes para ganar dinero, los segundos ganan dinero porque curan enfermos. Puede parecer lo mismo, pero hay mucha diferencia.

----

(1) Nota: Este es uno de los post que por "entrañables" estoy trasladando aquí desde el anterior navegapolis.net donde fue publicado el 31 de marzo de 2005. Hace ya algunos años que dejé de trabajar en la empresa aludida ;-)

edadSe dice que son necesarias 10.000 horas de trabajo de programación para alcanzar el nivel de experto, pero una vez llegado a él, ¿cuál es la evolución? ¿Se mantiene? ¿Continúa mejorando? ¿Retrocede?

Aunque hay diversas opiniones, posiblemente la más habitual considera que la edad desgasta la capacidad para adoptar y absorber nuevos conocimientos, por lo que al avanzar va transvasando a puestos comerciales, de gestión, de asesoría, o incluso a otras actividades. 

Como la demanda de software continúa creciendo, y en el medio plazo no es probable un cambio de tendencia, se empieza a cuestionar si la preferencia de candidatos jóvenes, o la percepción del "demasiado mayor" tiene sentido o puede ser un comportamiento inducido por una falsa lógica.

Patrick Morrison y Emerson Murphy-Hill del departamento de Ingeniería del Software de la Universidad de Carolina del Norte, han realizado un estudio pionero en esta línea, basándose en el análisis de los datos de la comunidad de programadores de stackoverflow.com (edad, reputación en la comunidad, tecnologías tratadas).

El objetivo de su primer estudio en esta línea es identificar si se aprecia algún tipo de correlación entre edad y nivel de programación, antes de profundizar con posibles correlaciones entre la "inteligencia fluida" o capacidad para identificar relaciones complejas y sus inferencias, y la "inteligencia cristalizada" que refleja la amplitud de conocimiento, comprensión juicio y sabiduría adquirida por la experiencia".

La conclusión a la que llegan los autores es que sí que existe una correlación entre la edad y la reputación de los programadores en stackoverflow.com, que parece indicar que se puede mantener un nivel de programación alto en los 50 y los 60, y que los usuarios más veteranos de stackoverflow se encuentran al día y adquieren sin problemas los nuevos conocimientos en las tecnologías que ha examinado este estudio.

Este es el documento del estudio: Is Programming Knowledge Related to Age? que presentarán los autores el 18 de mayo en el eventop "10th Working Conference on Mining Software Repositories" en San Francisco.

satisfaccion thumb"Un problema de los equipos de programación con importante impacto económico es la alta rotación de personal. La relación entre insatisfacción y rotación es una evidencia contrastada. El estudio (Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams) investiga si existe una relación entre la satisfacción laboral y el método de desarrollo empleado, y encuentra una correlación positiva moderada entre el nivel de satisfacción y el uso de metodologías ágiles..." (1)

satisfaccion laboral en equipos ágiles y no ágiles

 "El análisis comparativo entre equipos ágiles y la media general de profesionales TIC, ha revelado tasas significativamente más altas de satisfacción en los miembros de equipos ágiles. Además no sólo en los trabajadores, sino también en los administradores se da mayor satisfacción con sus empleos. Este es un claro indicador de que los métodos ágiles no son un movimiento orientado sólo a los programadores".

El informe completo y todas tablas comparativas del estudio en:

(1) Melnik, G., & Marurer, F. (2006). Comparative Analysis of Job Satisfaction in Agile and Non-agile Software Development Teams. Extreme Programming and Agile Processes in Sotware Engineering, 32-42.

motivandoEn otras profesiones no sé, pero si se trata de programadores, de gente apasionada por la tecnología y por la programación de nuevas soluciones, no se preocupe por motivarles. Son profesionales motivados por su trabajo mucho más de lo que usted lo está por el suyo.

La cuestión no es motivar, sino no desmotivar con "programas de motivación", planes de desempeño, control de horas de trabajo, recompensas y castigos, etc.
Quieren programar, son gente inteligente y los modelos de motivación de manual de recursos humanos, les resultan pueriles y denigrantes y les quitan las ganas que traían con ellos cuando llegaron a su empresa el primer día.

Estamos hablando de programadores, "programadores": personas a las que les gusta su profesión. Son un porcentaje escaso. Gente que cuando deja el equipo de la oficina, continúa, investigando y "jugando", que disfruta con retos intelectuales y a la que gusta estar en continuamente descubriendo y aprendiendo.

Si los programadores de su empresa no son de este tipo, si desde que dejan la oficina hasta que vuelven a la mañana o el lunes siguiente, no echan de menos un teclado... seguramente el consejo de este post no es bueno para usted, y es posible que sí que necesite las prácticas de motivación del manual de RR.HH. También es posible que no consiga nunca productos brillantes.