Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Lo más bonito de mi trabajo es que los clientes no dejan de sorprenderte nunca. Hace unos días llegue a un cliente, en el que recientemente hemos arrancado un piloto de un equipo. De las primeras cosas que llamaron mi atención fue ver tres líneas diferentes en su burndown chart. Tras preguntar, el jefe de desarrollo y el Scrum Master del equipo, me contaron, no sin cierto pudor, que las líneas representaban diferentes grados de cumplimiento de los objetivos del sprint, ¡cómo si fuese posible cumplir en diferentes medidas el trabajo comprometido para un sprint!.

Me reacción fue de clara contrariedad. Ellos sabían que la cosa no me iba a hacer gracia, pero se veían en la necesidad clara de ¡motivar al equipo!. Yo sabía que no era buena idea intentar ‘motivar’ al equipo prometiéndoles recompensas económicas por cumplir ‘más’ el sprint. Lo sabía porque ya había sufrido estos intentos de ‘motivarme’ durante mi carrera profesional y siempre habían tenido resultados dañinos. Lo sabía empíricamente, pero claro, cuanto te pagan por tu conocimiento, generalmente, no vale solo con decir, ‘tu idea no vale porque yo ya la he visto fallar’. Se espera una respuesta más analítica. Les apunté un artículo de Joel Spolky sobre el tema, titulado, Los pagos de incentivos considerados dañinos, pero me quede con la sensación de no haber respondido a su necesidad. La gente cuanto te paga por responder preguntas y ayudarles no quieren solo saber que puede pasar y como debe actuar sino los porqués…

La siguiente cuestión que se puso sobre la mesa fue: ¿tú qué haces para motivar a tu equipo? Mi respuesta es clara: tratar de no desmotivar. Hace tiempo leí o alguien me conto, que una buena forma de actuar es tratar de no hacer lo que a ti te han hecho y te ha desmotivado. Y a eso me suelo ceñir en lo que ha motivación se refiere.

Automáticamente me di cuenta de una realidad: ¡No sabía gran sobre la motivación! Y la motivación es el factor que más influye en el rendimiento de un equipo de desarrollo, eso sí que lo tengo muy claro, gracias al trabajo de Boehm que Steve McConnell refleja en sus libros que yo he leído con deleite. Si queremos equipos motivados no es para ser nominados a gestores del año, no, es simple egoísmo (léase sin connotaciones negativas) económico. Los desarrolladores motivados producen más.

En esta tesitura, tras dejar al cliente y llegar al aeropuerto, en una de esas casualidades que tiene la vida, mirando libros en el aeropuerto, tras el enésimo retraso del Vueling, encontré ‘La sorprendente verdad sobre qué nos motiva’ de Daniel H. Pink. Y ahora, unos días después de devorar el libro, puedo escribir este post.

¿Por qué mi intuición de que ofrecer dinero a un equipo de desarrollo por completar más historias que las comprometidas para un sprint no funciona es cierta?

Lo que debemos saber es que hay dos tipos de labores que los empleados pueden realizar. Hay tareas que son algorítmicas, que consisten en repetir una determinada receta para lograr un determinado objetivo productivo sin cabida para la creatividad o tareas heurísticas en las que el componente creativo es un factor relevante. ¿Alguien duda de que el desarrollo de software es una tarea de creación? Desarrollar software exige tomar continuamente decisiones de diseño. Cada línea es una decisión de diseño o varias. No es para nada una tarea repetitiva. Un desarrollador está continuamente solucionando problemas.

Hay un experimento esclarecedor descrito en el libro de Pink que demuestra científicamente que para tareas que requieren de creatividad y de dotes de resolución de problemas los incentivos económicos son dañinos. El experimento consistió en proponer a dos grupos de personas la resolución de un problema, el problema de la vela, cuyo planteamiento y solución podéis ver en la siguiente imagen, que exige cierta componente de pensamiento creativo. Se trata de sujetar la vela a la pared sin derramar una sola gota de cera. La solución una vez la conoces parece obvia, pero exige cierto pensamiento lateral para ver que es necesario sacar los clavos de la caja y que no es necesario usar las cerrillas.

Experimiento de la vela

A un grupo se le dijo que se le pagaría una cantidad si lograba resolver el problema, y a otro no. Sorprendentemente, el grupo remunerado obtuvo peores resultados a la hora de resolver el problema. El experimento demuestra que el hecho de establecer una recompensa económica automáticamente desvía nuestra atención de resolver el problema a obtener la recompensa.

El libro de Pink describe un motón de experimentos similares que llegan a una conclusión que es contraintutiva: tratar de motivar el trabajo mediante incentivos económicos solo funciona para tareas muy simples. Y desarrollar software no es una tarea simple. Además y de manera sorprendente, los incentivos económicos no solo no mejoran el rendimiento de los equipos de desarrollo, sino que además, a menudo ¡lo empeoran!. Es curioso ver en libro ejemplos de investigaciones que demuestran resultados muy ‘extraños’: incentivar económicamente la donación de sangre se traduce en una menor tasa de donaciones, los artistas realizan obras de peor calidad cuando están trabajando por encargo, los escolares que reciben un diploma por pintar pierden el interés por esta actividad… ¡cuando menos sorprendente!. Esto resultados ponen en evidencia la creencia general en gestión de que las personas respondemos al palo y la zanahoria, a un esquema de incentivos y castigos.

Para conocer el porqué hay que tener en cuenta que existen dos tipos fundamentales de motivación: la motivación extrínseca, es aquella que aparece cuando lo que atrae no es la acción que se realiza en sí, sino lo que se recibe a cambio de la actividad realizada (por ejemplo, dinero, comida o cualquier otra forma de recompensa) y la motivación extrínseca, que aparece cuando el individuo realiza una actividad por el simple placer de realizarla, sin que nadie de manera obvia le de algún incentivo externo. Cuando hablamos de trabajos en los que la creatividad juega un papel, la motivación intrínseca es sumamente importante, muchísimo más que la motivación extrínseca. Y lo que es más relevante, la motivación extrínseca forzada daña el rendimiento en este tipo de actividades.

No hay mejor manera de convertir un trabajo interesante y motivador en una pesada carga que tratar de incentivarlo. Si a un desarrollador le ofreces incentivos por realizar su trabajo, automáticamente le estas lanzando el mensaje de que el trabajo que realiza no debe despertar en él el interés suficiente por si mismo. Todos los desarrolladores odiamos los trabajos que no son interesantes, que no plantean un reto o una oportunidad de aprendizaje. Evidentemente en el desarrollo de software hay muchos trabajos que son repetitivos, pero por suerte, esto son susceptibles de ser automatizados, pedir a un desarrollador que automatice un trabajo repetitivo es mucho más productivo que remunerarle por realizar un trabajo que considera desagradable.

La psicología ha dado la explicación a algo que se sabía hace mucho tiempo. Fijaros en los factores que motivan a los desarrolladores, descubiertos por Barry Bohem hace décadas, tal y como aparecen en recomendable artículo Best Practices to Increase Productivity and Decrease Turnover de Janet Amirault:

image

El salario, en el caso de los desarrolladores de proyectos y los gestores aparece en el noveno lugar, tres más abajo que para la gente en general. Vamos que intentar motivar a desarrolladores con dinero, no da buenos resultado, hay factores mucho más influyentes y adecuados.

El corolario, expresado por Pink en su libro es que debemos recordar siempre que los incentivos basados en ‘si haces esto obtendrás aquello’ pueden eliminar la poderosa motivación intrínseca, reducir el rendimiento, dañar la creatividad, apartarnos de una conducta adecuada para lograr los objetivos volverse adictivos (necesitándose mayores y mayores incentivos cada vez) y potenciar el pensamiento cortoplacista.

Veamos qué escenario nos encontraríamos si cogemos un equipo y le ofrecemos dinero por terminar más historias de las comprometidas para un sprint. Para empezar, algo que es una meta loable, conseguir los objetivos marcados, algo a lo que nuestro ‘buenismo’ natural nos empuja, se convertiría en algo por lo que debemos ser sobre compensados. Implícitamente es admitir que el trabajo no es interesante, o no es motivador por si mismo o que los objetivos solo son factibles con una sobre motivación. Además la gente, como demuestra el experimento de la vela la gente se concentraría en fin, y olvidaría los medios. El fin de obtener el objetivo haría que fuésemos menos eficientes en el proceso de obtenerlo. Además seguro que algunos desarrolladores, sino todos, tomarían atajos de calidad, o no escribirían test unitarios o actualizarían la documentación solo para cerrar un historia más y obtener la recompensa, sutilmente estaríamos recompensando comportamientos anómalos. En el hipotético caso de que los incentivos funcionasen a corto, nunca funcionarían a largo plazo, pues cada vez serían necesarias mayores dosis para lograr los mismos resultados, algo insostenible económicamente.

Lo que si funciona, siempre administrándolo con juicio, son las recompensas no esperadas. Y sobre todo, aunque parezca mentira, lo que más funciona, es el reconocimiento al trabajo bien hecho. Un simple reconocimiento explícito es lo que mejor resultado da según muestran los estudios que Pink muestra en su libro.

Creo que después de todo, mi táctica de simplemente tratar de no desmotivar, es más que acertada. Y creo que la táctica de las metodologías ágiles de establecer metas claras, dar voz a los desarrolladores y permitir la excelencia son poderosos catalizadores de la motivación intrínseca.

Por si este post no ha despertado suficiente interés en vosotros sobre este tema, os dejo un video (en inglés) resumen brutal del libro de Pink, espero que lo disfrutéis:

¿A vosotros que os motiva?.

P.D.: Los videos con subtítulos en español (La soprendente verdad sobre los que nos motiva 1/2 y La sorprendente verdad sobre lo que nos motiva 2/2).

Published 11/10/2010 12:32 por Rodrigo Corral
Comparte este post:
http://geeks.ms/blogs/rcorral/archive/2010/10/11/leer-antes-de-motivar-o-lo-que-debe-saber-todo-jefe-de-proyecto-sobre-la-motivaci-243-n.aspx

Comentarios

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Esto me recuerda en parte a una entrada que escribí hace ya algún tiempo:

geeks.ms/.../el-valor-humano-la-motivaci-243-n-y-el-sentirse-valorado.aspx

Monday, October 11, 2010 1:07 PM por Jorge Serrano

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Muy de acuerdo, Rodrigo. Cuando se establece una política de incentivos económicos se está estableciendo una relación más cercana a la cliente/proveedor que a la de equipo.

De todos modos este tema se abre a muchísimos puntos polémicos, porque hay quienes defienden que la relación empresa/equipo debe de ser cliente/proveedor, y quienes defienden que una empresa y sus trabajadores son un "equipo" (aunque esa relación también está descompensada, no puede ser "entre iguales").

Uno de los mayores problemas derivados  de los incentivos por sprint/release/contrato... por resultados a corto plazo, es que los esfuerzos se desvían hacia ejercicios de justificación, y generan una tensión adicional sobre la definición de "Hecho".

Equipos justificando los resultados, discusiones sobre grados de cumplimiento/responsabilidades, etc...

*Pero*... a todos los que quieran usar este post tuyo para el mal (son muchos, ya lo verás), y que decidan que esto justifica la ausencia de políticas de incentivos, les digo:

RECORDAD QUE DEBÉIS TRABAJAR A DIARIO PARA ELIMINAR LOS ELEMENTOS QUE DES-INCENTIVAN. Si no estáis haciendo esto... no vengaís con excusas. Vuestros equipos necesitan un entorno donde fluir, donde refugiarse y ser felices mientras trabajan duro.

No asumáis que todo el esfuerzo debe de ser por su parte ;)

Monday, October 11, 2010 1:19 PM por Jorge Uriarte

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Buen post!.

A mi lo que me motiva es creer en lo que hago. Identificar la utilidad, ver su coherencia con el resto de acciones que mi entorno lleva a cabo. Ser parte de un todo con sentido. Los incentivos, sean cuales sean, deberán ser coherentes con ese objetivo. Si no lo son, destruyen.

Respecto al incentivo económico estoy de acuerdo en que en muchas situaciones no funciona. Siempre que el salario llegue a un mínimo que le permita a la persona sobrevivir, los incrementos son inmediatamente diluidos en el ego de cada persona.

A seguir así.

Monday, October 11, 2010 1:36 PM por Jorge Román

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

¿Estás motivando a las cárnicas a pagar aún menos a los curritos, ya que la recompensa económina no sirve en software????

Sí, que vayan con su reputación online a pagar el alquiler...

:) , en serio, muy interesante.

Monday, October 11, 2010 2:16 PM por José

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

@José, a mí me gusta muchísimo lo que sale en el video que dice algo así como que si a un empleado se le paga lo que es justo de acuerdo a su trabajo y esfuerzo, éste no reclamará más sueldo.

Creo que el problema no es pagar menos a los curritos, sino pagar lo que es justo e incentivar con otras cosas, no con variables (de los cuales siempre me he negado).

Otro problema es discernir lo que unos y otros opinan como "sueldo justo", pero eso es otro cantar.

Monday, October 11, 2010 3:54 PM por Jorge Serrano

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

@Jorge Uriarte cuanta razón. Lo que te ahorras en incentivos te lo tendrías que gastar en eliminar elementos desincentivadores, en mejora continua y en quitar los impedimentos.

@José no hace falta incentivar a las carnicas a obrar de manera desincentivadora... el problema también es que no todos los trabajadores creen en la parte creativa del desarrollo de software y esos son carne de carnica. El que revosa motivación intrínseca no dura ni un cuarto de hora en una cárnica pura y dura. De todos modos, no sufras, los gerentes de las carnicas están demasiado ocupados contando horas como para leer esto.

@Jorge, tio, es que tu rebosas motivación intrenseca!!! :)

@MrSerrano, un sueldo justo es aquel que permite que mientras estás trabajando no estés pensando en si llegarás a fin de mes o mirando webs de trabajo para ver si puedes conseguir un buen sueldo. Es aquel que, como mínimo, no supone una preocupación.

Monday, October 11, 2010 8:24 PM por Rodrigo Corral

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Muy buen articulo!

Con respecto al sueldo justo... muchas veces tendemos a cometer una equivocación, vemos el sueldo obtenido como una medida de lo que valemos, y esto no debería ser así, lamentablemente hace falta dinero para vivir, pero en mi caso personal, también necesito sentirme retado por mi trabajo, sentir cada día la adrenalina de un reto imposible y la euforia de conseguir batir mis propios límites, y sobre todo, necesito una palmada en la espalda cuando el sudor y el esfuerzo dan su resultado.

He visto pasar a mi lado muchos compañeros cuya única motivación es el dinero, para eso mejor hacerse futbolistas que se gana más, aqui en nuestro trabajo, debe primar la ilusión y las ganas de romper barreras.

Monday, October 11, 2010 8:42 PM por Josué Yeray Julián Ferreiro

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

@Rodrigo, excelente definición de sueldo justo, pero tal como comenta Josué a los que nos gusta la informática y nos motiva nuestro trabajo, necesitamos retos para trabajar independientemente del sueldo que tengamos.

No es lo mismo estar haciendo un proyecto en .net 2003, que hacer una web en SL, por poner un ejemplo. O trabajar con LotusNotes y con vb5...

A mi cuando busco un cambio no es por motivos de dinero, normalmente es por motivos tecnológicos.

Monday, October 11, 2010 9:10 PM por Javier Torrecilla

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

El video de CognitiveMedia es impresionante. Si sirve de algo mi aportación, creo que el axioma fundamental para que todo esto se cumpla es que no debes depender del $$$ (en el video comenta algo así como que la persona no piense en el dinero). Lamentablemente, se tiende a estar cada día más entrampado y se depende mucho del dinero que entra a final de mes. Sin embargo, también hay que dejar claro que del término entrampado hay que descontar los caprichos y cuestiones accesorias que al final hacen subir mucho el salario mínimo de supervivencia. En fin...

Gran post, titán!

Monday, October 11, 2010 9:26 PM por Eladio

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

muy buen articulo Rodrigo, como se ve en el video y ceo que todos los vemos a diarios, mientras que estemos contentos con nuestro trabajo y la parte economica esta a nuestra medida vamos a ser mas productivos ya que nos enfocariamos en nuestra labor.

Monday, October 11, 2010 10:40 PM por Yurivan

# direccion recursos humanos

Muy interesante artículo. La motivación del personal es muy importante dentro de una empresa. Hay que tener en cuenta que un empleado feliz trabaja mejor y en consecuencia aumenta su productividad y la productividad de la empresa.

Tuesday, October 12, 2010 2:15 AM por alejandro@cenys.com

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Hola a todos... Sobre el tema del dinero en el libro cuentan un estudio en el que estudian la relación entre la preocupación por obtener una buena remuneración y la optenida a futuro para un grupo de estudiantes universitarios, si no recuerdo mal, de bellas artes.

El resultado del estudio es muy curioso: los que menos preocupados se mostraron por obtener unos buenos ingresos son los que los obtubieron mejores. Parece que exito económico evita a aquellos que se preocupan demasiado por el en lugar de preocuparse por disfrutar, avanzar y aprender en su trabajo.

¡Un saludo a todos!

Tuesday, October 12, 2010 11:59 AM por Rodrigo Corral

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Cuanta razón !!!!!!

Enhorabuena por el post, he leido los artículos, he visto los videos y aun no he tenido tiempo de leer los libros, pero seguro que lo haré !!!!

Siempre que hemos intentado motivar con remuneraciones económicas a los equipos de desarrollo no han funcionado como esperabamos, quizás si a corto plazo, pero en cuanto ven que eso va a durar mucho, se acabó !!!! Conseguimos desmotivar.... si a eso le añadimos las complejidades de las organizaciones y de las personas que las dirijen, el tema se vuelve aun más en tu contra.

Así pués, deja que las cosas fluyan de forma natural, que las personas se adapten a las organizaciones y a la inversa, permite que realicen su trabajo de forma razonablemente cómoda y los resultados seguro que llegarán....

Personalmente he probado otras cosas y no han funcionado...

PD: La narca del vino es Becker...

Tuesday, October 12, 2010 1:15 PM por Albert Martín

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Que bueno! La motivación es la base para la inspiración, que es condición necesaria para la creatividad y por lo tanto es la piedra angular de la construcción de software.

Wednesday, October 13, 2010 1:44 PM por Miguel Sierra

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Estaba respondiendo aquí, pero la respuesta creció y creció. Así que decidí ponerla en mi blog.

cnatra.blogspot.com/.../un-equipo-motivado.html

Excelente post, Rodrigo.

Wednesday, October 20, 2010 11:15 AM por CNatra

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Interesante el debate, pero quiero regresar a al punto de partida: evitar lo que desmotiva.

Algo que de veras desmotiva son los cambios abruptos en las especificaciones, vamos que no estamos hablando de agregar dos campos a un formulario, no... sino cuando se deciden eliminar formularios complicados o reescribir totalmente la funcionalidad que ya se estaba por terminar....

Yo era responsable tecnico, pero no funcional asi que me correspondio a mi transmitir las noticias de esos cambios a mi equipo y no veas el bajon que se dieron mis juniors, solo me quedo demostrarles que estaba con ellos y que estaba reclamando eso ante los superiores pues eso no era sano para la "moral de la tropa", en esas circunstancias solo queda ponerse junto a tu equipo para que la desmotivacion no vaya a mas, pero claro.. mejor hubiera sido tener en cuenta de antemano la desmotivacion ocasionada por el cambio abrupto.

Sunday, November 7, 2010 9:50 AM por Ernesto

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

¿Cómo recompensarían al equipo cuando terminan la iteración antes de tiempo? Este planteo surgió del equipo luego de varios sprints con los items cumplidos en tiempo total menor al estimado

(Usamos SCRUM)Este planteo de solicitar recompensa surgió del equipo luego de varias iteraciones con los items terminados en un tiempo total menor al estimado.

a)¿Sería apropiado recompensar? ¿A individuos o al equipo?

b)¿Qué clase de recompensa sería apropiada? Dinero? Regalo?

c)Ante reiteradas oportunidades debería replantearse si la estimación fue hecha adecuadamente?

d)¿Debería esperarse a efectuar una revisión de calidad de los items cumplidos, para luego recompensar?

e)¿Debería realizarse una relación entre items cumplidos Vs Items defectuosos para luego recompensar? (por ejemplo, items que el product owner haya sugerido, y estos hayan sido, dependientes de otros items aun no incluidos o items definidos de forma que no fuera posible cumplir, u otro defecto que haya imposibilitado el desarrollo del item, aunque al momento de la planificación haya parecido apto.)

f) Cuando un miembro termina antes de tiempo, tiene la costumbre de ayudar a sus compañeros a terminar sus items. Y esto colabora con que el equipo completo termine antes de tiempo. En este caso ¿se debería premiar al individuo? ¿al equipo?

g) Otra posibilidad de recompensa es retirarse antes de la oficina el viernes.

Agradecería todas las sugerencias sobre este planteo. Gracias por el interés.

Tuesday, November 9, 2010 11:27 PM por Maria Cecilia PeTri

# Cómo recompensar al equipo de desarrollo que cumple o no hacerlo

Lo que me gusta de los blogs es que la gente puede departir, debatir, comentar y opinar respecto a las

Wednesday, November 10, 2010 10:24 AM por Jorge Serrano - MVP Visual Developer - Visual Basic

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Wednesday, November 10, 2010 10:25 AM por Jorge Serrano

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Maria, yo creo que los incentivos tienen más inconvenientes que ventajas.

Se pueden usar ocasionalmente, para premiar sobreesfuerzos que también deben ser ocasionales. Si no la ciencia a demostrado que son altamente ineficientes. Ese es el asunto principal del post.

Me gusta especialmente el artículo de Joel Spolsky en el que explica, de manera bastante mundana por que los incentivos son dañinos:

spanish.joelonsoftware.com/.../IncentivePayConsideredHar.html

Un saludo.

Wednesday, November 10, 2010 1:18 PM por Rodrigo Corral

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Ya había leído esta serie de experimentos y sus extrañas conclusiones. El problema es que la gente las malinterpreta.

Dicho de otra manera: págale poco a un empleado bueno y al final perderás talento. El problema no es el dinero, el problema es anunciar la recompensa del tipo que sea (generalmente alta), antes de que se produzca el hecho a recompensar, porque envía al subconsciente el mensaje de que es una tarea tediosa que debe evitarse.

Y volviendo al salrio, en Google lo suben: www.cincodias.com/.../cdstec

Thursday, November 11, 2010 9:40 AM por Boriel

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Yo creo que lo primero que debería saber cualquiera que es responsable de alguien, es que lo que aplicaba en 1980 tiene pocas posibilidades de seguir siendo válido ahora.

Lo digo por la tabla de Boehm donde pretende definir lo que le interesa a las personas según su pertenencia laboral. Me parece muy osado y muy probablemente erroneo a día de hoy, puesto que en 30 años la sociedad ha cambiado radicalmente y las motivaciones no tienen porqué ser las mismas.

La generación del "Cuéntame" tiene poco que ver poco con los que nacimos en los 80, y nosotros seguramente no nos parecemos a los que lo hicieron en los 90. Meternos a todos en el mismo saco es simplificar en exceso, algo por otra parte entendible porque, al fin de cuentas, se trata de algo que desconocemos y no estamos preparados para enfrentarnos a ello (en la mayoría de los casos) como es el comportamiento humano.

A nivel personal, me gusta mi trabajo, pero lo que más me gusta es mi tiempo libre, mi ocio, mi familia y pasarlo bien, y ningún framework o beta puede superar eso. Y para poder disfrutar a tope de ello, siempre es mejor tener un sueldo generoso que me permita hacer realidad mis deseos. El dinero no da la felicidad, lo da conseguir nuestros objetivos, y en muchas ocasiones el vil metal se interpone entre ellos.

Y en cuanto a la receta mágica de la motivación, personalmente creo que es que cada persona es diferente y cualquier intento de aplicar un patrón universal a todo un colectivo, es un mero intento de escabullirse.

Tuesday, December 14, 2010 5:58 PM por javier

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Despues de variadas experiencias en este singular sector del desarrollo de software en nuestro pais, y ultimamente fuera de el;

mi opinion es que el mas efectivo metodo de motivacion se basa como muchas cosas en el equilibrio.

No creo que se pueda motivar a un profesional a base de dinero, ya que eso mas alla del "subidon" que te puede dar

el dia que recibes la noticia y por supuesto, cuando la compartes con los amig@s :) ; no te va a recompensar cuando te pases un par

de meses trabajando de sol a sol y de lunes a domingo; al final te veras descompensado en otros aspectos, como por ejemplo la vida personal.

Por el contrario, si trabajas en una empresa donde no tienes un salario razonable (y no me refiero a lo que a todos nos gustaria para tener el

ultimo coche molon), directamente estas de paso; con lo que los objetivos que se te fijen en el proyecto en el que estes, es lo de menos.

Tu solo tienes un objetivo, salir de ahi.

Por ultimo, creo que coincidireis conmigo que muchos de los que trabajamos en el desarrollo de software somos distintos (no dire raros); y por

ello, a lo mejor motiva mas a un desarrollador el ponerle un monitor auxiliar de 32" o el darke la posibilidad de que asista a un evento tecnico,

que esos mismos 200€ en un bonus extra. Esto posiblemente, en otros sectores no se da.

Para mi la mejor formula se aproxima a conjugar un salario justo (y lo de justo que cada uno lo "ajuste" a su idea), "la regla de

los tres 8" (duerme 8, trabaja 8 y vive 8) y jugar con las singularidades de la gente con la que trabajamos.

Wednesday, December 15, 2010 11:18 AM por Julio Alamo

# re: Leer antes de motivar… o lo que debe saber todo jefe de proyecto sobre la motivación

Pense que se hablaba de incentivos económicos para trabajar mejor, o mas a gusto, pero aqui se habla de incentivos económicos para hacer las cosas mas rapidos, y con este tipo de incentivos lo que te dicen es que eres incompetente o vago, porque se puede hacer antes de lo que tu lo haces. No parece muy motivante, je,je. Tambien aparece stress por las prisas. En el caso de la vela el grupo incentivado parece estar compitiendo para solucionar antes el problema que el otro, con lo que se estreda, aunque no me quedo claro en el enunciado.

Respecto a la pregunta:

¿Cómo recompensarían al equipo cuando terminan la iteración antes de tiempo?

1/Suponiendo que "antes de tiempo" es que lo han hecho antes de las horas de trabajo estimada, pues entonces lo que estaba mal era la estimacion, asi que eso fue un error del estimador. Lo mismo ocurre al contrario, si el trabajo no se hace a tiempo, la culpa es del estimador, que supongo que tendra la autoridad sobre el equipo, aunque cualquiera sabe, porque parece que con la modernidad, no se lleva aquello de ligar autoridad y responsabilidad, algo basico en mis estudios de empresariales, anteriores a mis estudios de informatica.

2/Si lo que han hecho es trabajar mas tiempo, es que lo que pueden es trabajar mas horas por dia o mes o periodo, vamos que no se cansan, son unas maquinas,je,je. Modo ironico on. Estrujemosles mas y mas, como un limon, hasta que se queden sin zumo,ja,ja, asi tenemos que contratar a menos, mas paro, mas necesidad de trabajar, mas facilidad de estrujar, repitamos el ciclo: Modo ironico off. En teoria, esto no funciona, pero parece estar pasando.

Ahora entrariamos en el temas de las estimaciones de tiempos. Todo lo que he leido sobre estimaciones gira entorno a la experiencia en trabajos anteriores, pero en desarrollo de software, y exagerando un poco,la experiencia cuenta poco: si lo has hecho antes es que ya lo tienes y si no lo has hecho no tienes experiencia. En todos los libros que he leido sobre gestion en desarrollo siempre hablan del tiempo, pero no sueltan el tema de "la experiencia" hasta el final de todas las tecnicas ¿porque será?, ja.

Incluso en carpinteria artesanal y en un proyecto medianamente facil, a no ser que hagas una simulacion  no veras todos los problemas con que te podras encontrar (puede valer un dibujo en 3d). Incluso asi se te escapan algunos, facilmente solucionable, eso si. Asi que en un proyecto de desarrollo soft, infinitamente mas complejo, que no mas dificil, es facil ver solo una minima parte de los problemas, y las soluciones ni las hueles.

En desarrollo de soft lo unico etico que se puede hacer es pensar un producto que se pueda vender mucho, e invertir en el, si aciertas te forras y si no, la cagas. Lo no etico es pensar algo e intentar encajarlo en tu presupuesto, estrujando, recortando, mintiendo, sin calidad.... Esto de encajar, pasa mucho incluso en cosas no artisticas, ni creativas, ni ingenierias...

je,je, voy a opositar a auxiliar, no se si administrativo o informatico, quizas mejor administrativo... Ya programare en casa, para mi

Sorry...

Monday, April 4, 2011 5:36 PM por lc