Qué motiva a las personas: los 3 elementos de la motivación

Hace unos años escribí un post sobre productividad y felicidad. Y en ese post decía algo así como "es curioso que los diseñadores de videojuegos tengan claro que hay una relación entre la felicidad y la productividad y algunas empresas/managers aun no se hayan enterado".
Y esto venía por un juego de estos "city builder", de los que construyes ciudades y vas aumentando la población y avanzando en tecnología, y había ciertos items que hacían subir la felicidad del ciudadano, lo que se traducía en mayor productividad en las fábricas. 

Y además esto está calculado. Los estudios dicen que un trabajador feliz produce un 12% más que uno infeliz. 

Llámale felicidad, llámale motivación.

Pero entonces, ¿qué nos hace felices/nos motiva en el mundo real? 

Sobre qué motiva a las personas se ha escrito mucho, pero la visión de Daniel Pink es la que más encaja con mis experiencias: los 3 elementos de la motivación.

Pink empieza hablando de la motivación 2.0, que serían los motivadores extrínsecos. Las recompensas. 
En el caso del videojuego, mis trabajadores eran más productivos si les conseguía cerveza. Y ya no te digo si les conseguía ron xd 

Pero en el mundo actual, donde nuestras necesidades básicas están cubiertas, la cosa se complica. Cuando llegar a fin de mes ya no es un problema, o salir a cenar, o tener la plataforma de streaming de turno, las recompensas externas no son suficientes para mantener la motivación de una persona. 

Y entonces llegamos a la motivación 3.0. Los motivadores intrínsecos. Donde la realización de la tarea es una motivación en sí misma. Y esta motivación 3.0 se sustenta en 3 elementos. 

Autonomía 
Es la libertad para decidir cómo hacer la tarea que te han encomendado. Puedes tomar ciertas decisiones sobre el trabajo que realizas.

"El control lleva a la obediencia, la autonomía lleva al compromiso."

Si sabéis algo sobre equipos ágiles, esto os sonará a "auto organización". Casualmente. 

Finalidad 
Es el para qué. Es el objetivo. Es "una causa mayor". 
Por ejemplo, si el objetivo de mi empresa es "que los accionistas ganen un 5% más que el año anterior" pues lo mismo eso no me motiva especialmente.  
Pero si la empresa dedica tiempo y dinero a la diversidad, a la equidad y a la inclusión, y el objetivo es romper los techos de cristal y tener paridad en puestos ejecutivos para el 2030, pues lo mismo eso sí 😏. 

Dominio 
Conocimiento. Habilidades para realizar una tarea. Hasta el punto de dominarla. 

"Ser cada día mejor en algo que nos importa."

Y aquí llegamos al elemento que en mi experiencia más dolor de cabeza nos va a dar, más frustración acarrea y más nos expone a la desmotivación. 

El señor Mihály Csíkszentmihályi lo explicó hace años con una gráfica: 

Donde vemos la relación entre la dificultad de la tarea que debemos realizar y nuestro nivel de conocimientos. 

Si el reto es muy sencillo respecto a nuestros conocimientos, caemos en el aburrimiento. Si hay un equilibrio, entramos en la zona de máximo rendimiento, el estado de fluidez. Pero si el reto es demasiado complicado respecto a los conocimientos que tenemos, caeremos en la ansiedad. 

"Una de las fuentes de frustración en el trabajo es el frecuente desajuste entre lo que la gente debe hacer y lo que puede hacer."

Así que ya lo veis, el camino hacia el dominio es doloroso (tienes mi historia personal con el dominio en este artículo).

Pero es que además el dominio no se alcanza: Última ley del dominio: el dominio es una asíntota.

Perseguir ese dominio es lo que nos motiva. Seguir aumentando nuestros conocimientos. Seguir aprendiendo cosas nuevas.

Dicho esto, cada persona le dará mayor o menor importancia a cada uno de estos 3 elementos. Descubrir qué motiva a cada individuo y, sobre todo, comprobar si esa motivación se encuentra o no cubierta en el entorno de trabajo, es el deber de cualquier manager.

Y en caso de no estar cubierta, ver qué podemos hacer para mejorar la situación.

Y una práctica que nos puede ayudar a averiguarlo es la de "Moving Motivators" de management 3.0. Pero eso os lo cuento otro día 😊

#thisistheway

Mi transformación ágil

Me he dado cuenta de que nunca he puesto por escrito cómo fue "mi transformación ágil". Que transformó el proyecto en el que trabajaba pero también a mí misma.
Aquí va la historia.

Año 2015 (o fue en 2016?). Después de más de 2 años en el proyecto, y una bajada de trabajo (y presupuesto) tremenda, solo quedamos 6 personas (más el jefe).

Éramos casi silos independientes. El jefe daba tarea a cada uno de nosotros, y apenas sabíamos lo que hacían los demás. Era como estar en cubículos al estilo americano.

A veces al marcharme a casa, veía como otro compañero se quedaba con algún marrón. Nadie le ayudaba (ni yo) y básicamente era mutuo.

Pero algo estaba cambiando en el cliente para el que trabajábamos. Estaban implantando algo llamado "agilidad" y nuestro responsable del cliente quiso subirse al barco.  Nos explicó que quería implantarlo en nuestro proyecto, y que íbamos a tener una serie de reuniones con un "coach agile" para que nos guiase en el camino.

Y así fue. Primero empezamos conociendo de qué iba eso de la agilidad un poco "por encima" y luego nos hablaron de Scrum y Kanban. La gente del cliente había recibido formación pero nosotros (como empresa externa) estábamos totalmente verdes.

Nos hablaron de las ceremonias, la daily, la retro, la review y la retrospectiva. Y que necesitábamos un Scrum Master. Ahí yo levanté la mano: me presento voluntaria! Ya que la coach había dicho que el jefe no podría hacer ese rol, vi la oportunidad y me lancé.

Nos preguntó qué tipo de tareas hacíamos. ¿Evolutivos o incidencias? Nosotros hacíamos sobre todo evolutivos, aunque también tratábamos las incidencias de producción. Nos propuso tener 2 tableros, uno para los evolutivos y otro para las incidencias.

Tuvimos que definir nuestro tablero para evolutivos (llamémosle tablero Scrum), identificar las columnas que queríamos visualizar, cómo indicar que teníamos algo bloqueado, cómo saber quién estaba tratando ese ticket... (pensad que era todo en físico, no usábamos ninguna herramienta tipo Jira).

El tablero Kanban

Para las incidencias usábamos un tablero kanban básico: to do, doing, done. Y a un lado un contador: ¡Llevamos x días sin incidencias! xD

El tablero Scrum

Tenía unas cuantas columnas. Recuerdo que había una parte para "los Product Owner" para que pudiesen indicar los tickets en los que estaban trabajando. Digamos que ellos tenían su propio "to do, doing, done". Y luego estaban las columnas para lo que estábamos desarrollando en ese sprint.

Desarrollo, tests unitarios, tests de integración, tests de usuario, listo para subir a producción, en producción.

El sprint

Inicialmente definimos que nuestros sprints durarían 3 semanas y con el tiempo pasamos a sprints de 2 semanas. Y no tardamos mucho la verdad.

En el cliente se hacían subidas a producción planificadas cada 2 semanas, así que los sprints de 2 semanas nos permitía alinearnos y subir a producción lo más rápido posible.

Las historias de usuario

En todo ese tiempo no escuché hablar de historias de usuario, pero sí que definimos entre todos qué información debía figurar en los post-it: 

• 

  Mi avatar :-)

  Título resumen para saber de qué iba el evolutivo.
• Horas de trabajo estimadas (no sabíamos lo que eran puntos historia), fecha prevista de subida a producción.
• Tecnología en la que había que desarrollar (podía ser cobol, o una herramienta con código propio que usábamos para la generación de documentos, o javascript para el front).
• Quién estaba con el desarrollo (para esto imprimimos unos avatares para identificar a cada persona del equipo).
  
• Dependencias con otros equipos.
• Quién era el peticionario (hacíamos evolutivos para diferentes departamentos del cliente).

Los bloqueos y las dependencias

Si un ticket estaba bloqueado, le poníamos un punto rojo (una pegatina xd), y si tenía dependencias por resolver, un punto azul.

De las dependencias se encargaba la gente del cliente ya que nosotros no teníamos digamos "autoridad" para reclamar según que cosas a otros departamentos.

Las estimaciones

Nosotros éramos todos de un mismo proveedor, y facturábamos por evolutivo realizado. Cada evolutivo se estimaba en horas siguiendo un ábaco que estaba "validado" por el cliente. Aunque en ocasiones lo usábamos simplemente para que reflejase las horas que nosotros considerábamos que eran necesarias.

Las estimaciones junto con el análisis técnico las solíamos hacer los que conocíamos mejor la aplicación. No significa que no hablásemos entre nosotros, pero teniendo en cuenta que yo era la que menos tiempo llevaba en el proyecto y lleva 3 años, podemos decir que éramos un equipo muy maduro, que conocía muy bien la aplicación, y que no solíamos errar el tiro en las estimaciones.

Nunca llegué a estimar en story points en ese equipo.

La capacidad

La calculábamos en horas teniendo en cuenta cuántos días íbamos a trabajar ese sprint, y de ahí restábamos las horas de ceremonias. Cada uno se preocupaba de conocer su capacidad antes de ir al sprint planning, y lo solíamos compartir en un excel para que tuviésemos la info de todo el equipo en un mismo sitio.

Para las incidencias, cada sprint, o cada 2 sprint, se ocupaba una persona. En caso de que no hubiese incidencias, trabajaría en algún ticket de evolutivos. Lo quisimos hacer rotativo porque encargarse de la producción siempre es agobiante. No era justo que siempre estuviese el mismo...

La autoorganización

Esto fue lo que más nos cambió. Como decía, trabajábamos cada uno en nuestro cubículo y eso no era compatible con la agilidad. Ahora los PO (el cliente) iba a presentarnos lo que querían realizar de cara al próximo sprint, y nosotros, el equipo, decidiríamos cuánto podíamos hacer y quién haría qué.

Ya nadie nos asignaría una tarea, la cogeríamos nosotros.

Esto al jefe no le gustó nada. La agilidad le quitaba totalmente el control sobre las personas. Vio un peligro ahí y empezó a revolverse: no quería aceptar la agilidad.

Lamentablemente para él, el hecho de que se opusiese a la agilidad hizo que nos uniésemos más como grupo: todos veíamos ventajas en pasar a trabajar así y, aprovechando que la petición venía del cliente, no íbamos a quedarnos callados.

Como yo había sido voluntaria para ser Scrum Master, me tocó lidiar con esta situación.

Reunión a 4 bandas (mi jefe, el cliente, la coach agile y yo como Scrum Master)

Antes de esta reunión me había reunido con el equipo para saber qué querían hacer: peleábamos por la agilidad o no? El resultado fue un sí rotundo. Queremos ser ágiles!

El hecho de vernos reunidos sin él, mosqueó mucho al jefe.

Al llegar a la reunión sabía que me iba a tocar enfrentarme a él. Y así fue.

No sé muy bien cómo pero acabamos hablando de nuestra situación como equipo, a lo que respondí que ahora mismo no éramos un equipo, tan solo individuos cada uno trabajando en sus cosas. Pero en agilidad, tendríamos un compromiso compartido, el compromiso del equipo, y trabajaríamos juntos para alcanzarlo. Además de que desde que habíamos empezado a "transformarnos" la gente estaba más animada.

Recuerdo que la coach me preguntó algo como "pero algo habrá que os empuje a levantaros cada día para venir a trabajar". A lo que respondí: claro que sí, cobrar a final de mes.

Aquí mi jefe estalló en llamas. En su cabeza, éramos todos súper amigos y nos llevábamos genial, y nos encantaba nuestro trabajo y nos apoyábamos unos a otros. Vivía en un mundo paralelo de fantasía!

Sabía que aquella reunión me traería consecuencias. Pero cuando vives con una carta de dimisión en el cajón a la que solo le falta la fecha en la que causarás baja... poco te importa.

La magia de la agilidad

Desde que empezamos a adquirir compromisos como equipo, la vida mejoró para todos. Cuando a uno le iba muy bien, se ponía a ayudar al otro que no le iba tan bien, para cumplir con el sprint goal.

La gente dejó de quedarse después de la hora. Si el cliente quería añadir una tarea "urgente" debía quitar otra equivalente.

Solamente por eso, habían valido la pena las broncas con el jefe.

Las habilidades en T

Lo comenté por encima en "El camino hacia el dominio II: un equipo con 11 delanteros". Yo era de cobol y sólo hacía tareas de cobol. Pero al llegar la agilidad me lo replanteé. Aceptaría aprender a trabajar con la herramienta chunga de los documentos si pasábamos a agilidad. Pero no me afectó solo a mí.

A raíz de poder elegir nuestras propias tareas, otras personas empezaron a pedir tareas de cobol para poder aprender. También pasó a nivel funcional: la gente empezó a pedir tareas de áreas que no conocían para aumentar su conocimiento de la aplicación.

¡Todo de forma natural!

Conclusión:

La auto organización, hizo que las personas del equipo se interesasen en adquirir habilidades en T.

La auto organización, hizo que las disfunciones de nuestro equipo empezasen a desaparecer.

La auto organización, hizo que las personas volviesen a estar motivadas.

¿He dicho ya que la clave fue la auto organización? :-P

No fue fácil, no fue rápido, pero marcó un antes y un después. Y por eso siempre seré del #teamAgile :-)

#thisistheway

Cobol VS Java: vuelve el debate

Hola amigas y amigos del Consultorio Cobol.

Como sabéis, hace tiempo que no escribo artículos de COBOL porque hace ya un tiempo que no programo. Pero es que ahora ni siquiera trabajo en un proyecto COBOL. Me he cambiado de bando...

Últimamente estoy trabajando con equipos Scrum que programan en java (o algo parecido), con su control de versiones con Bitbucket, sus branchs y demás.

El caso es que cada vez que digo: 

"recordad que lo prioritario es completar el sprint goal. Si terminamos lo nuestro, vemos de ayudar a los demás para asegurar que cumplimos el sprint goal."

Me responden: "es que no podemos trabajar más de una persona en un ticket."

Y si digo: "vale, pero hay 2 tickets." 

Entonces me dicen: "no, es que todos afectan a la misma clase. Solo puede tocar uno."

Y claro, yo que no estoy metida en la parte técnica, y que además soy de cobol-mainframe, no lo entiendo del todo.

Porque en cobol, recuerdo perfectamente repartirnos los programas (y rutinas) que había q tocar/crear. Incluso una persona podía hacer el JCL (en la versión Java el equivalente imagino que será un script) y otro el programa. O si había que tocar alguna tabla para añadir datos (parametría por ejemplo) lo podía hacer otra persona. 

Y sí, claro que para implantar/testear teníamos que ponernos de acuerdo si eran cosas enlazadas, pero podíamos trabajar varios en la misma funcionalidad. Digamos que el código estaba lo bastante troceado como para poder trabajar varios a la vez.

Eso ayudaba mucho a trabajar conjuntamente en el objetivo del sprint (cuando alguien terminaba, podía ponerse a ayudar al resto).

Entonces yo me pregunto, ¿esto es una cosa de la aplicación en cuestión con la que trabaja mi actual equipo? ¿Es que el código no está bien hecho y por eso todo está metido en el mismo "archivo"?

¿Es porque no estamos dividiendo bien las features? ¿O soy yo que no me entero?

Otra cosa que me dicen es que claro, que si cada uno se crea una branch, luego hay conflictos. Y yo me pregunto, ¿y eso es un problema? Te detecta los conflictos a la hora de hacer el merge y los "resuelves", ¿no?

¿Tan complicado es o es que buscamos la comodidad?

Por favor java developers, arrojad algo de luz... Mi objetivo sólo es terminar las cosas en curso antes de empezar otras nuevas...

#thisistheway

Ansiedad VS Motivación: epílogo por S.F.

Antes de empezar, si no lo has hecho ya, te recomiendo leer el artículo "Ansiedad VS Motivación: el estado de fluidez" para dar contexto a lo que te voy a contar a continuación.

¿Alguna vez habéis estado en un traspaso de conocimiento? Me refiero a cuando una empresa sale y entra otra a quedarse con una aplicación de software.

Es decir, cuando las personas que llevan años trabajando en una aplicación se van, y llegan otras que no la conocen en absoluto para tomar el relevo.

¿Esto os suena? 
Si tú que estás leyendo esto lo has vivido, sabrás que es imposible "traspasar el conocimiento".

  
Lo que va a ocurrir, es que las personas que acaban de llegar y que no tienen ni idea de lo que se van a encontrar, van a pasar tal vez 2-3 meses con este traspaso, y luego 1 año fácilmente de sufrimiento hasta "entender algo" de lo que tienen que hacer. 

¿¿¿Cómo se sobrevive a 1 año en la zona de ansiedad??? 

Muchas personas no sobreviven. No tengo una estadística más allá que la experiencia de mi amiga S.F. y la mía propia, pero en algunos casos puede llegar al 50%. 
Esto no es normal. Esto no es vida. 

Os dejo aquí el testimonio de mi amiga que lleva ya 3 proyectos de traspaso. Es bastante ilustrativo...
 
Traspaso A: 2022

"Con traspaso de 1 mes llevamos un infarto, una baja por jaquecas diarias, el equipo X empastillado porque no pueden dormir. Y en el mío hay una persona de baja por ansiedad, y ha llorado ya medio equipo en plan ataque de ansiedad.

Otro chico acudió a la psicóloga de riesgos laborales de la empresa y tras darle las pastillas correspondientes le dijo: no te preocupes, que las toma la mitad de la empresa."

Traspaso B: 2021

"Con traspaso de 3 meses tuvimos: un jefe de baja por amago de infarto, un ataque de ansiedad con salida de proyecto por petición propia (obviamente), un chico con varios meses de baja por ansiedad y varias bajas voluntarias. Todo en año y pico."

 
Traspaso C: 2018

"Fueron 3 meses de traspaso con 12 horas de curro al día, pero aquí no recuerdo que mucha gente se pirara. El jefe cayó una vez acabó el proyecto, pero este ya era repetidor, ya estando en otro proyecto se había cogido un año de baja por ansiedad." 

Conclusiones de S.F. 

"Y contándolo así, la verdad que da gusto mi currículum, ¡qué buenos proyectos! 😂😂😂"

¿Os imagináis en qué tipo de proyecto estaba yo cuando caí en la zona de ansiedad en 2011?

Cooorrecto.

This is NOT the way!!!!