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í.