archivo

Productividad

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.

Respeto mucho a la gente que trabaja duro, a las personas que tienen un nivel de responsabilidad y compromiso para consigo mismo y su equipo (extenderlo a nivel organizativo sería generalizar demasiado porque no son muchas las organizaciones que hace sentir a las personas que trabajan en ellas como parte importante de la mismas). Después las cosas saldrán bien o mal, pero no será por el empeño que se ha puesto.

Ahora bien, si no sale bien, tampoco es cuestión de mala suerte (o por lo menos no se puede recurrir siempre a eso) porque trabajar duro y de manera efectiva no significan lo mismo.

Por ese motivo no se debe ligar productividad a horas trabajadas sino a la efectividad, extendiéndose este último concepto a algo más que completar tareas de manera adecuada, llegando incluso a considerarse como parte del mismo al aprendizaje que vamos obteniendo incluso en aquellos casos donde los resultados no sean todo lo positivos que esperamos.

Si además de no conseguir resultados, no extraemos conocimiento todo será desperdicio.

La productividad entendida de esta manera puede crear controversia porque nos estamos saliendo de la ortodoxia de su concepción clásica, no obstante, si no tenemos en cuenta esos otros activos que se pueden obtener como consecuencia del trabajo que realizamos, estamos dejando fuera del análisis a una parte importante del producto obtenido, intangible, sí, aparentemente (solo aparentemente) inútil, que tal vez no permita recuperar el tiempo perdido pero que más adelante (tal vez mañana mismo) puede producir resultados tangibles y efectivos.

La productividad pasa por ser efectivo y no por echar más horas. Los que nos dedicamos al mundo del desarrollo de software sabemos que en diferentes ocasiones tenemos que echar horas de más para completar determinadas tareas, sin entrar a analizar si es algo que se debe admitir o no, sabemos que en ocasiones es necesario y la mayoría lo tenemos asumido.

También sería de interés que los responsables de las organizaciones lo tuvieran asumido y reconociesen ese esfuerzo de alguna manera y no hablo de palmaditas en la espalda. Ahora bien, si el sobreesfuerzo es consecuencia de haber dejado las cosas para última hora o por no haber hecho un buen trabajo, no se debe esperar, por lógica y por justicia para el resto de tus compañeros que encima te recompensen.

Sin embargo, echar más horas puede ser efectivo a corto plazo pero perjudicial a medio y largo plazo, sobre todo si esas horas de más se convierten en interminables jornadas que abarcan prácticamente todos los días de la semana. No somos robots, no somos máquinas, más pronto que tarde notaremos física e intelectualmente ese agotamiento y el resultado de nuestro trabajo será un reflejo de ello. Por ese motivo es fundamental saber repartir los esfuerzos y dejar las heroicidades para los superhéroes ya que esa no es nuestra misión.

La competitividad no pasa por malvender proyectos a costa de las personas que después tienen que realizarlos y/o a costa de las satisfacción final del usuario, sino pasa por ser efectivo, ahí es donde se marca la diferencia porque lo otro es capaz de hacerlo cualquiera y, además, suele tener, a la larga, efectos negativos.

¿Y qué se hace con esas horas que no se facturan? La respuesta a esta pregunta no es simple, de hecho no la voy a responder, solo dejo unas cuantas reflexiones:

– Llegado a un punto, en un proyecto llave en mano las horas que superen lo contratado no serán facturables (salvo pacto contrario) ya que el compromiso es desarrollar un producto con el precio y las condiciones fijadas. En este tipo de proyectos lo que interesa, por tanto, es cumplir la agenda con el objeto de no incurrir en pérdidas y para ello la medida más óptima es que el equipo y las personas que lo componen sean productivas por encima de que el 100% de sus horas sean facturables o no porque al final si no cumples, si no trabajas bien, todas las horas te costarán dinero.

– En general un trabajo que no esté bien hecho y que haya que volver a hacer y/o que erosione tu credibilidad con respecto al cliente es dinero perdido y/o que se dejará de ganar.

– Si una persona o un equipo tiene trabajo que potencialmente supera el 100% de su capacidad corre el riesgo de que en determinados momentos se sature y que la misma afecte a la productividad y a la calidad.

– Lo ideal es que la dedicación de personas a proyectos sea del 100%. El problema de la saturación es provocado generalmente al compartirse entre diferentes proyectos, incluso en aquellos casos donde se quiera tener cuidado de que la dedicación total no supere el 100% porque, ¿quién es capaz de delimitar con tanta precisión las fronteras?, ¿alguien ha tenido en cuenta el esfuerzo real que supone cada cambio de contexto?, ¿quién tiene la suficiente capacidad para olvidarse de los problemas que tiene en otros proyectos en los que esté trabajando?, ¿qué pasa cuando los diferentes proyectos en los que se trabaja están en “crisis”?.

– No todos los perfiles funcionan igual al compartirse entre proyectos distintos. Cuanto mayor sea el nivel de detalle con el que trabaje en el proyecto menos productiva será esa división.

– La productividad de una persona o de un equipo no se debe medir por el número de horas que facturen sino por la efectividad de las horas facturadas, si se es efectivo seguro que será rentable.

Uno de los aspectos en los que he cambiado de opinión está relacionado con la carga de trabajo que debe tener asignada ya sea un equipo o una persona. Justificaba y en mi blog hay artículos hablando de ello que cada persona tuviera tareas que en potencia superasen el 100% de su capacidad de manera que siempre (o casi siempre) hubiera la posibilidad de estar trabajando en tareas aunque uno de los proyectos o líneas de trabajo sufriera un parón.

Desde el punto de vista empresarial la situación ideal es aquella en la que la mayor parte de las horas laborables sean facturables o a través de ellas se generen oportunidades de negocio.

Sin embargo esta situación ideal llevada al mundo real presenta inconvenientes que, por supuesto, los ven solo quienes tienen una visión a ese nivel de detalle o se preocupan por analizar qué mecanismos permiten obtener la máxima productividad de las personas o de los equipos.

Es curioso, en propia persona sufría y sufro esa capacidad potencial de trabajo superior al 100%, veía y notaba sus consecuencias y, sin embargo, lo justificaba. ¿El motivo? Lo terminé considerando como algo normal y a partir de ahí trataba de dar una explicación a ese hecho.

También me pasaba con el enfoque de desarrollo clásico y les pasa a muchos que no terminan de considerar los enfoques ágiles como una alternativa.

Siempre suelo poner los mismos ejemplo. ¿Trabaja mejor tu ordenador cuándo lo tienes saturado de procesos abiertos?, ¿funciona mejor tu conexión a Internet cuando tienes prácticamente ocupado de manera continua tu ancho de banda?, ¿verdad que no?, ¿lo mismo nos pasa a nosotros?. Llega a un punto donde la saturación de trabajo bloquea a todo lo demás y el avance en esas tareas será más lento y probablemente con unos resultados de menor calidad y con una finalización de las mismas mucho más tarde de lo que sería deseable.

La saturación no es positiva, tampoco lo es la situación contraria, de ahí que el objetivo deba ser limitar la cantidad de trabajo y adaptarla a la capacidad que esa persona o equipo pueda asimilar en ese momento. El “ese momento” es importante porque la capacidad no tiene por qué ser siempre la misma y eso es inherente a las personas.

Esto no es fácil, habrá veces que nos quedemos cortos o que nos pasemos, sin embargo lo realmente importante es intentar poco a poco que la desviación con respecto a la situación ideal sea la menor posible.

Lo que hay que evitar es que la práctica general sea saturar a personas o equipos, ¿que de esta forma no se llega al límite de la capacidad potencial? Os pongo el siguiente ejemplo: cuando hacéis palomitas en el microondas siempre hay maíz que no se termina de abrir, ¿qué pasa si dejáis más tiempo el microondas para que esas pepitas terminen por abrirse? pues que se te habrán quemado las palomitas y la mayoría de las pepitas pendientes de abrirse (que no serán muchas) seguirán sin hacerlo. En este caso, la estrategia más productiva no es calentar las palomitas al 120% sino hacerlo dentro de unos márgenes apropiados aunque no se consiga que el 100% del maíz se abra.

La falta de tensión no es buena, tampoco el exceso de presión. La presión en un momento dado puede ayudar a mantener o recuperar el enfoque en el proyecto, incluso a dar ese 110% que puede ser necesario, siempre y cuando sea durante un período de tiempo soportable.

Pero más allá de eso, es nefasta. También lo es en períodos cortos cuando se trata de conseguir un sobreesfuerzo que está por encima de la capacidad de los desarrolladores y/o del problema en cuestión que existe en ese momento.

Yo también he dicho más de un vez que bajo presión funciono mejor, pero no es así realmente. Bajo presión estás más concentrado y tienes tus sentidos dedicados al objetivo, pero eso es así porque es una presión controlada, no te obligas o no te obligan más allá las de lo que puedes admitir, en el momento en que te exiges o te exigen más, empieza el bloqueo, los nervios y las contramedidas para quitarte de encima esa presión que pasa por tratar de terminar cuanto antes y como sea, con la consiguiente merma de calidad del producto final.

Resulta complicado no trasladar presión a tu equipo si a su vez estás sometido a una gran presión. Es importante que ellos vean y sientan lo que está en juego pero no ir más allá. Tener la capacidad de absorber esa presión y no saturar con ella al equipo es una gran virtud y en contraprestación conseguirás mejores resultados gracias a un trabajo más productivo.

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