archivo

Archivo de la etiqueta: motivación

Utilizar el dinero como motivador suele ser eficaz a corto plazo, a medio y largo plazo resulta fatal para tu departamento u organización.

¿Por qué? Pues porque lo excepcional se convierte en costumbre y al cabo del tiempo ya no será suficiente para motivar o no tendrá el mismo efecto. Además, en el momento en que falta ese ingreso se suele obtener el efecto contrario: reducción del rendimiento por falta de motivación.

De esta forma se crea en la cultura de que lo que realmente mueve a los profesionales de la organización es el dinero y no el interés por el trabajo que se realiza en la misma, el propio afán del desarrollador por mejorar o la pasión que puede sentir por su profesión.

Otro problema lo tenemos en que la persona tenderá a ir a por los objetivos que le permiten obtener la recompensa, dejando de lado otros que pueden ser igualmente importantes para la organización. La persona se convierte en cumplidor pero en cumplidor de lo que le interesa, de lo que le hace ganar más dinero.

Estoy hablando de recompensas sistemáticas y no de retribuciones justas. Soy de la opinión de que un profesional debe estar pagado acorde a sus méritos, conocimientos y experiencia (aunque raras veces se pague a los profesionales siguiendo esos criterios). Tampoco estoy en contra de las retribuciones variables siempre y cuando las mismas se realicen siguiendo criterios objetivos y estén al alcance del conjunto de empleados de la organización.

Principio 6: La calidad solo la producen profesionales motivados orgullosos de su trabajo.

Asunto controvertido, pero real. Y no solo afecta a la calidad, sino a otros muchos factores en los proyectos de desarrollo de software como la productividad, la confianza, etc…

El respeto por nuestra profesión y por nosotros mismos es algo que sale de dentro de cada uno. Después hay factores que modulan su intensidad en cada momento, si bien, tienen un límite inferior que hace que determinadas personas independientemente de las circunstancias sean capaces de rendir por encima de las mismas (lo cual no quiere decir que siempre sea suficiente como para superar todos los problemas que se puedan encontrar).

Los desarrolladores que no respetan nuestra profesión, no lo harán ni en los buenos ni en los malos momentos y la calidad media de sus trabajos, sumando éxitos y fracasos, será deficiente.

Pero incluso esas personas que están motivadas de serie para tratar de hacer el mejor trabajo posible, sufren mucho y ven mermado considerablemente su potencial y rendimiento cuando muchas organizaciones (o determinados responsables dentro de las mismas), en lugar de tratar de sacar lo mejor de esas fortalezas se empeñan en debilitarlas, convirtiendo lo económico u otros intereses en la única prioridad de los proyectos y haciendo que el trabajo bien hecho (y conseguir un producto de calidad es uno de los factores para considerarlo así) queda en un muy segundo plano.

De esta manera nos encontramos proyectos mal vendidos, condenados desde un principio al fracaso (Death March Project), en los que desde un primer momento se trata de recortar alcance y calidad, para tratar de sacar algo de él.

O proyectos que tal vez sí estaban bien dotados económicamente pero que se ha gestionado negligentemente o que son vistos como una oportunidad para cumplir con determinadas aspiraciones o ambiciones personales, motivo por el cual se trata de conseguir unos beneficios por encima de los que realmente se podrían conseguir.

En ambas situaciones, no solo sufre el producto, no solo sufre el proyecto, no solo sufre el cliente (que también tiene su parte de culpa en todo eso, cuando trata de conseguir precios absolutamente fuera de mercado, aún a sabiendas de lo que eso trae consigo), sino que sufren y mucho los desarrolladores que se encuentran en medio de las líneas de presión que ejercen sus jefes y los clientes, que generalmente deben echar muchas más horas de las que le corresponden, que muy pocas veces son valorados como se merecen y que se ven obligados a desarrollar con unos niveles de calidad con los que no están en absoluto de acuerdo.

El factor clave de los proyectos de desarrollo de software son las personas. Si no están motivadas, si no creen en su trabajo, pocas posibilidades tendremos de conseguir unos resultados acordes a las expectativas que se tenían puestas.

Se cree que pagando un salario se asegura todo esto, eso tal vez funcionase hace muchos años, hoy día, las personas necesitan otro tipo de incentivos, como por ejemplo, sentir que su trabajo ha servido para mejorar algo.

Por último, es importante señalar que no solo se trata de motivación y de respeto a tu profesión, se trata también de cualificación.

La voluntad y la actitud son importantes, permiten llegar lejos, pero la experiencia (real) y la aptitud, sumadas a lo anterior, son las que permiten marcar la diferencia.

Comenta William Grosso que: “El código que aburre al programador es probable que contenga errores”. Esta reflexión es extensible a cualquier trabajo que no nos parezca lo suficientemente motivante como para centrar nuestro enfoque en él.

Cuando desviamos la atención de la tarea que estamos realizando se incrementan drásticamente las probabilidades de que cometamos errores.

La atención se desvía cuando encontramos una situación u otra tarea que nos parece más interesante y/o porque hay algo que nos preocupa o inquieta.

Cuanto más interesante (por el motivo que sea) nos parece una tarea más capacidad tenemos de mantener nuestro enfoque en la misma y menos errores tendremos como consecuencia de despistes, además de manera inconsciente le daremos más vueltas (productivas) a nuestro trabajo con el objeto de eliminar (o por lo menos reducir) posibles incidencias porque estaremos más implicados en que el resultado final sea lo más óptimo posible.

No siempre vamos a tener la oportunidad de que nos llegue trabajo interesante o motivante. En este caso si las tareas no lo son implícitamente tendremos que ser nosotros los que pongamos ese interés o esa motivación y si nos ponemos a buscar encontraremos motivos para ello y si aún así no lo conseguimos tendremos que tirar de profesionalidad para intentar que el trabajo salga de la mejor forma posible y mantener el enfoque en el mismo todo lo que se pueda.

El desarrollo de software requiere un importante esfuerzo intelectual por parte de las personas que participan en él. La efectividad depende de que el talento y experiencia de cada persona esté enfocada en el trabajo, tarea o proyecto que mejor se adapte a esa capacidad y que, además, le motive.

Dado que no se trabaja solo, resulta muy importante que las personas que conforman los equipos encajen.

Obtener el máximo rendimiento de las personas no es tarea fácil, ya que son muchos los factores que pueden influir en el mismo, para empezar sus propias circunstancias.

Sabiendo que no es sencillo y que es utópico pensar que el 100% del tiempo se va a tener un rendimiento óptimo de las personas y de los equipos, sí que existen una serie de aspectos a tener en cuenta, porque el hecho de que sea difícil no significa que no se intente, es más, es necesario dedicar el esfuerzo necesario para intentar aproximarnos lo máximo posible a ese límite:

– Fomenta la autogestión de las equipos. Los que viven el día a día del proyecto saben mejor que nadie cómo deben organizarse, quién se organiza tiende a ser más responsable con el resultado de su trabajo. Eso no quiere decir que los desatiendas, ya que muchas veces desde fuera se ven cosas que no se ven desde dentro y porque hay información ya sea del cliente o de la propia organización que llega a través de ti. Por otro lado, si respetas el espacio de tu equipo, ellos respetarán el tuyo y las retrospectivas sobre el trabajo que se está realizando serán más provechosas.

– Intenta minimizar los cambios de contexto. El fraccionamiento de las personas en múltiples proyectos es ineficiente para las personas y para los proyectos. Hay determinados tipos de perfiles donde no queda más remedio, en ese caso, trata de ajustar la capacidad de trabajo que puede absorber a su límite real.

– Trata de evitar los parones en los proyectos. Esto es algo que no dependerá de ti en la mayoría de los casos, pero sí que puedes intervenir para tratar de prevenirlo. Esto requerirá una atención tanto al proyecto como a la información que te haga llegar tu equipo.

– Las personas no son robots, ni sus aptitudes son las más adecuadas para todos los contextos, por tanto, no les trates como máquinas, conoce sus puntos fuertes y sus puntos débiles, dedica tiempo a saber qué le motiva y con qué grupo de personas puede encajar mejor. Si existen diferentes alternativas, pregúntale cuál se le apetece más, a cuál cree que puede aportar más y por qué. No es lo mismo que tu empujes a una persona a dar un paso a que sea ella misma quién lo decida, ya que el nivel de implicación no será el mismo.

La organización debe tratar de no ser rígida en la promoción profesional, centrándose exclusivamente en promociones verticales y en un itinerario establecido. Las personas son diferentes, plantea diferentes itinerarios.

– Buscar el rendimiento óptimo de las personas basado en mecanismos de recompensa, no suele proporcionar buenos resultados a la larga porque en el momento en el que por el motivo que sea esas recompensan menguan o desaparecen, la motivación se irá con ellas.

Es importante premiar a quién lo hace bien y eliminar de la organización la idea del “nunca pasa nada” aunque se falle estrepitosamente en una serie de proyectos, pero orientarlo más que a un hecho concreto a una trayectoria (lo cual no quita que puedan existir logros excepcionales con recompensas también excepcionales), esto implica la existencia de una carrera profesional, en donde buenos resultados se terminen consolidando en tus ingresos.

– Adapta la cantidad de trabajo que puede asumir un equipo a su capacidad real, lo contrario da lugar a situaciones de bloqueo y de pérdida de calidad que influyen directamente en los resultados. Es posible que el overtime consiga solventar estas dificultades durante un tiempo, pero poco después, la cantidad de trabajo real que se pueda sacar será menor que con el horario normal (fruto del cansancio y de modular tus fuerzas a la jornada laboral), a lo que habrá que sumar el sobrecoste de una mayor deuda técnica y tasa de fallos.

– Siempre hay trabajo que hacer, si hay una persona o un grupo de personas desocupadas y te interesa mantenerlas en la organización, crea un proyecto o proyectos internos, haz que actúen de soporte en proyectos que estén en marcha (siempre y cuando su entrada no rompa el ritmo de trabajo) y/o realicen tareas de testing, utilízalos de apoyo para tareas comerciales, etc…

En estas circunstancias, además, se puede saber si una persona está motivada o no por seguir en la organización, ya que quien quiere trabajar, se inventará el trabajo y si le preguntas te expondrá muy probablemente diferentes alternativas en las que poder ayudar.

Lo peor que se puede hacer es dejar a estas personas sin hacer nada porque muy probablemente afectarán directa o indirectamente a las personas que sí están implicadas en proyectos.

El desarrollo de software es una disciplina complicada y que generalmente es poco generosa con las personas que día a día trabajan en ella.

Construir un producto, ladrillo a ladrillo, línea a línea (por mucho que nos podamos apoyar en frameworks, generadores de código y librerías) es una actividad compleja, sobre todo teniendo en cuenta que el desarrollo de software no es solo programación. Para ejecutar (programar) es necesario haber llegado antes a la determinación y conocimiento de qué es lo que se va a hacer y eso resulta complejo y puede ocasiones desgaste entre las partes sobre todo si los contextos no son favorables y/o las personas no ponen de su parte.

A los desarrolladores nos cuesta mucho trabajo desconectar cuando salimos del trabajo sobre todo cuando hay problemas y desgraciadamente nos encontramos con problemas con demasiada frecuencia.

Y dentro de trabajo si nos encontramos motivados o si el propio reto o problema nos motiva toda nuestra atención se dirigirá a la resolución del mismo independientemente de que la misma nos lleve días (o semanas). Cuando entramos en lo que los expertos en productividad llaman “la zona” parece que no existe el tiempo y de existir siempre nos va a aparecer que avanza demasiado deprisa (no es sencillo gestionar esto cuando tenemos otras tareas que también están pendientes de nuestra atención).

Creo que es interesante reflexionar sobre la siguiente cita de Orson Scott Card (traducción libre): “La programación (el desarrollo de software) es el gran juego. Te consume a ti, tu cuerpo y tu alma. Cuando estás atrapado en él, nada importa”.

Jerry Weinberg considera que: “Cualquiera que haya visto a un programador trabajando… sabe lo que es la programación en sí, si al programador se le da la oportunidad de hacerlo a su manera, es la mayor motivación que puede tener el programador”.

Podemos extender la reflexión de Weinberg al concepto de desarrollador.

Estoy de acuerdo si bien es importante diferenciar autonomía de anarquía. Trabajas de manera autónoma si se te indican cuáles son tus objetivos (o bien desde tu rol en el proyecto o en la organización te los defines tu) y conociendo y respetando las reglas del juego (procesos, enfoques, metodologías, estrategias de diseño, herramientas, etc…) además de tener siempre presente que trabajas en equipo tienes libertad para realizar la solución.

Para que exista autonomía es necesario que las reglas del juego den el suficiente margen de maniobra. También es necesario entender que lo mismo todos los roles (y dentro de cada rol las personas que lo componen) no tienen la misma autonomía para realizar su trabajo ya que dependerá del tipo de proyecto, del tipo de sistema que se desarrolla, de las propias reglas del juego y de la experiencia y conocimientos del desarrollador.

El trabajo que se realiza de forma autónoma motiva y por eso es importante desarrollar este esquema de trabajo. Es cierto que al principio costará un poco que la maquinaria funcione ya que será necesario que cada uno entienda que la autonomía implica responsabilidad contigo mismo, con tus compañeros y con el proyecto y para que se pueda trabajar de manera adecuada hay que respetar las reglas el juego.

Hay quien se pierde trabajando de esa manera pero principalmente es provocado por el hecho de no entender o eludir esa responsabilidad y por la falta de una visión colaborativa en el desarrollo de software. Como es lógico implantar este esquema de trabajo requiere de personas que funcionen en él.

Uno de los problemas de que a los desarrolladores se les trate como ganado es que de esta forma es muy complicado que vean un propósito que les sirva como elemento motivador en su día a día. De esta forma solo ven tareas, una tras otra y nada más.

Un desarrollador puede ser productivo de esa manera, pero será menos consistente y más irregular, y tendrá que ser bastante fuerte para no dejarse vencer por la tentación de convertirse en un cumplidor o todavía peor en alguien que aparente cumplir (muchos más frecuentes estos últimos).

El desarrollo de software produce mucho desgaste porque los problemas no se terminan cuando sales de la puerta del trabajo sino que te lo llevas en tu cabeza y tardan en desaparecer (si es que lo hacen). Si detrás de esto no hay algo que te motive, te terminas convirtiendo en un robot.

El propósito no se toma en pastillas, ni se construye con cuatro gestos bien intencionados o de cara a la galería. El propósito es creer en un proyecto (es algo más amplio que un proyecto concreto de desarrollo de software), en una forma de hacer las cosas, en sentir de verdad que tu trabajo hace mejor y te hace mejor. Además debe alimentarse de un trato justo por parte de la organización porque de lo contrario se pierde equilibrio.

El problema de todo esto es que muchos gestores piensan que con el salario ya se ha conseguido todo y no es así.

Mirar para atrás sirve si nos permite aprender. Tanto del éxito como del fracaso se aprende, sobre todo de estos últimos, porque cuando las cosas salen bien o muy bien se nos suele nublar nuestro espíritu crítico.

Está bien recordar las hazañas y logros de personas que ya no están en la organización y que en un momento dado de su trayectoria profesional quisieron buscar otros destinos, lo que lo convierte en antipatrón es cuando las mismas se ponen continua y repetidas veces como ejemplo a los demás, ya sea a modo de reproche cuando los resultados no han sido los esperados o para tratar de demostrar, simplemente, que las cosas se pueden hacer mucho mejor.

Cuando se mitifica se magnifica, lo bueno es más bueno y lo malo es más malo. En este caso, las hazañas se convierten casi en leyendas y lo que fue un trabajo en equipo (porque en este negocio se trabaja de esta manera) se ha convertido en un gesto de heroicidad de un solo individuo.

El culto al mito, presenta los siguientes inconvenientes:

– Se intenta trasladar al presente resultados que personas concretas (con los equipos en los que trabajaron) consiguieron en un momento dado, generalmente exagerados por el paso del tiempo, sin tener en cuenta que el contexto de la organización y del negocio ha cambiado, de tal forma que lo mismo ahora conseguir esos objetivos (o la mitad de los mismos) resulta mucho más complicado aún invirtiendo el doble de esfuerzo.

– A las personas a las que les toca sacar las castañas del fuego en estos momentos se les minusvalora con esa continua comparación. Esa circunstancia termina provocando desmotivación y pérdida de confianza, factores que afectan directamente a la productividad.

– A las personas que continúan en la organización y que participaron en los equipos de trabajo de esos mitos se sienten menospreciadas, cuando tal vez su esfuerzo, dedicación y ganas fueron esenciales para el cumplimiento de esos objetivos.

La rigidez en los procesos afectan por regla general a la autonomía de las personas que trabajan con los mismos. Tiene su lógica, más procedimientos y mayor nivel de detalle suele ser equivalente a un menor margen de maniobra.

Puede resultar razonable procesos rígidos en contextos donde el trabajo sea mecánico, de hecho el siguiente paso a eso sería la cadena de montaje donde cada secuencia en el desarrollo de un producto está mecanizada y si hay intervención humano está tremendamente reglada.

Trabajar en un contexto de este tipo donde la autonomía y la creatividad están limitadas o son inexistentes no resulta sencillo, al menos, para mi no lo es. En estos casos el trabajo se convierte en un automatismo en el que hay que tener el aguante suficiente para hacer lo mismo un día sí y otro también.

Sé que hay quienes se sienten cómodos con este tipo de trabajos: se ha adquirido un conocimiento y/o una habilidad y se pone en práctica todos los días, no hay que ir más allá ni tener otro tipo de preocupación que producir en cantidad y en calidad lo que tu organización te haya marcado. Se termina la jornada laboral y mañana será otro día.

Incluso quienes se sienten cómodo con estos trabajos no encuentran más aliciente en el mismo que el propio sueldo, es decir, el trabajo en sí no les supone ningún aliciente más.

El desarrollo de software es diferente siempre y cuando no estés encorsetado en el proceso.

Los procesos son necesarios, proporcionan un background común a los proyectos, ahora bien, deben ser flexibles y no meterse en demasiado nivel de detalle. Armonizar los trabajos resulta interesante pero no debe condicionar los proyectos si hay circunstancias que justifican una desviación de los procesos establecidos (circunstancias objetivas y no caprichos personales).

Procesos rígidos además de afectar a la propia adaptación al cambio afectan a la autonomía que los desarrolladores necesitan para hacer su trabajo con un mayor nivel de motivación y con un mayor enfoque en el problema o problemas con los que se está trabajando: la atención está en el producto y no en el proceso.

¿En qué circunstancias sueles entrar con más frecuencia en lo que los estudiosos de la productividad llaman “la zona”?, ¿suele coincidir con la resolución de problemas en los que te han dado un cierto grado de autonomía y que suponen un reto personal superarlos?, ¿suele coincidir con aquellos momentos en los que aplicas tu creatividad para dar solución a un problema o a una tarea?.

Cuando en el artículo anterior hablaba de entornos que te llenasen profesionalmente estaba refiriéndome precisamente a aquellos en los que se fomente la autonomía y la creatividad (dentro de los límites del trabajo que estás desarrollando, ya que como en otros muchos campos el exceso, en este caso, de creatividad puede dar lugar a muchos problemas).

Esa mayor autonomía hay que ganársela (y mantenerla) y eso se consigue a base de conseguir resultados dentro de los márgenes de responsabilidad que te vayan asignando.

Te pedirán unos resultados, existirán unas ciertas reglas del juego (procesos, condiciones contractuales con el cliente, etc…) y unos ciertos puntos de control (que serán más frecuentes y con más detalle en función de la naturaleza de los trabajos y del grado de autonomía que te hayas ganado).

¿No prefieres trabajar en un entorno así?, ¿no te importa eso y sí el sueldo que recibes? Cada cual tiene en la vida unas prioridades y las respeto, este artículo y el anterior los publico con el objetivo de que reflexionemos sobre esto.

Nuestro primer instinto puede ser intentar conseguir el mayor sueldo posible pero pasado un tiempo se empiezan a valorar más otras cosas si estás en un trabajo en el que no progresas (y no me refiero necesariamente a conseguir ascensos), en el que todos los días hay una crisis o en el que estás encorsetado y no tienes prácticamente margen de maniobra no es precisamente el sueldo lo que tiene más importancia. Es posible que el salario que cobres, la situación del mercado laboral o tu situación personal te tengan atado a tu organización pero probablemente si tuvieras la oportunidad aceptarías irte a otro entorno laboral que te llenase más profesionalmente incluso cobrando menos (siempre y cuando se supere el umbral de lo que consideras necesario para vivir).