Está surgiendo entre los programadores y los equipos de desarrollo un enfoque demasiado individualista y perjudicial en la forma en que se gestionan los proyectos. El objetivo de las personas parece haberse convertido únicamente en cerrar sus propias tareas lo más rápido posible, sin preocuparse por cómo esto puede afectar el trabajo de los demás miembros del equipo.
Cerrar tareas no es el objetivo final
Este enfoque también podría ser el primer indicio de una falta de gobernanza por parte de la empresa, se produce en proyectos altamente estructurados por tareas, donde a cada persona se le asigna una tarea que debe completarse lo antes posible y sobre la cual se evalúa el rendimiento de su trabajo.
Ese programador es una máquina de guerra, termina todo lo que se le asigna por la mañana y luego se pone a hacer otra cosa.
¿Cuántas veces has escuchado esta frase y la satisfacción generalizada por parte de colegas y gerentes? Pero, ¿es realmente tan positivo?
Para lograr cierto rendimiento, se tiende a encerrar a la persona en un entorno aislado, despojándola de cualquier preocupación, para impulsarla hacia el máximo resultado.
Desde un punto de vista, esto es positivo: se eliminan todas las distracciones, las reuniones constantes, las interminables llamadas telefónicas y las situaciones de multitarea para enfocarse en el objetivo. Desde otro punto de vista, se pierde de vista el panorama general y se corre el riesgo de crear un ambiente de trabajo tóxico, altamente individualista, en el que las personas no se ayudan mutuamente ni comparten sus conocimientos.
El hecho de que muchos programadores sean propensos al aislamiento cuando realizan su trabajo no ayuda a esta situación.
El síndrome del caballo de carreras
Se entiende lo fácil que es, en un entorno como este, no darse cuenta de los descontentos o de la desconexión entre las diferentes figuras, si solo se mira el resultado a corto plazo. Al igual que un caballo de carreras lleva anteojeras para correr rápidamente hacia la meta sin mirar el mundo exterior, los programadores se lanzan a resolver sus propias tareas.
Lo importante es terminar la tarea, no la economía del proyecto.
Premiando el individualismo
Se premia el individualismo, vinculado al resultado tangible.
Es una lástima que un proyecto también esté compuesto por una serie de resultados intangibles, como compartir conocimientos, colaboración y crecimiento personal y profesional de las personas involucradas.
Las métricas establecidas por la gerencia y muchas herramientas utilizadas en la empresa tienden a evaluar solo lo tangible: el número de tareas cerradas, las líneas de código escritas, el tiempo entre la apertura de un problema y su resolución: rara vez tienen en cuenta las tareas intangibles.
Piensa en todas las veces que has ayudado a un colega a superar un problema, corregido una línea de código que resuelve un problema conocido desde hace meses y nunca resuelto, las sesiones de programación en pareja o los consejos dados durante el café.
Por lo tanto, es necesario pensar en los proyectos de manera holística y tratar de alejarse de la lógica de la tarea como único objetivo. Un equipo que trabaja junto debe alcanzar un objetivo común. No ganan los individuos, sino que gana el grupo que es capaz de evolucionar y mejorar el producto de manera continua y armoniosa.
El problema de «terminar las tareas»
El verdadero desafío es convertir a un grupo de personas, insertas en un contexto donde se premia el rendimiento individual, en un equipo que piensa, actúa y trabaja hacia objetivos a largo plazo.
Trabajar en equipo no es solo una cuestión de habilidades blandas, sino también de cultura empresarial y de cómo se evalúa a las personas dentro de la empresa.
Crear compartimentos estancos no beneficia a nadie y debe equilibrarse con actividades que aporten valor incluso a las personas más lentas o aisladas, para poder impulsarlas hacia una mejora cultural y personal.
Cuando se tienen equipos compuestos por personas más o menos experimentadas, si se encuentra la manera de transferir conocimientos de una persona a otra, se convierte en un enriquecimiento tanto para el proyecto como para las personas individuales.
Para aquellos que gestionan un proyecto de software, es fundamental utilizar el tiempo de las personas de la mejor manera posible para aumentar el valor del proyecto además de cerrar las tareas.
Es esencial fomentar una cultura colaborativa dentro del equipo, donde las personas puedan ayudarse mutuamente y compartir conocimientos.
¿De quién es la responsabilidad?
Sin duda, fomentar un enfoque colaborativo es responsabilidad de la gerencia, pero también los miembros individuales del equipo desempeñan un papel importante en este proceso. Es fundamental que los miembros del proyecto sean conscientes de que su trabajo no se limita únicamente a cerrar sus propias tareas y regresar a casa lo antes posible.
En las reuniones periódicas, en las reuniones de pie, es responsabilidad de los miembros del equipo informar a los demás si hay bloqueos o si necesitan ayuda. De la misma manera, los miembros del equipo deben estar dispuestos a ayudar a sus colegas compartiendo sus conocimientos y habilidades.
Sin embargo, esto no significa que este aspecto surja de forma espontánea. Por eso es necesario que la gerencia promueva activamente la colaboración, identificando estas situaciones y alentando a las personas a trabajar de manera colaborativa.
¿Qué estrategias podemos implementar para mitigar este problema?
Existen varias formas de evitar que este enfoque comprometa la economía del proyecto.
Si hablamos de habilidades blandas, definitivamente debemos incluir en el equipo de trabajo personas que tengan una predisposición natural para el trabajo en equipo, que sepan trabajar en grupo y que sean capaces de compartir sus conocimientos.
Si una persona termina sus tareas y no tiene nada más que hacer, se le puede animar a realizar revisiones de código del trabajo de otros miembros del equipo, a realizar refactorizaciones del código recién agregado o a brindar mentoría y capacitación a las personas menos experimentadas, y el rendimiento individual debería evaluarse en función de este tipo de actividades.
Gestión de «SuperStar»
En un mundo perfecto, todos pueden hacer su trabajo, almorzar en casa con la familia y jugar al tenis por la tarde.
En un mundo real, nos enfrentamos a problemas y no todos se pueden resolver por sí solos. A veces es necesario pedir ayuda a los llamados «programadores SuperStar».
En este sentido, me viene a la mente un discurso de Ottavio Bianchi a los jugadores del Napoli cuando Maradona se unió al equipo:
Él es Maradona y nosotros somos nosotros. El problema surge si alguno de nosotros quiere ser Maradona. Si aceptamos esto, es decir, que él es él y nosotros somos otra cosa, podemos ganar, pero si nosotros no lo aceptamos o alguno de nosotros no lo acepta, las cosas no funcionan.
A veces, la SuperStar es necesaria para cerrar algunas tareas: imagina todas las situaciones en las que te has encontrado con un problema que una persona muy competente en el tema habría resuelto en minutos, mientras que tú has tardado días.
En estos casos, es fácil que la persona individual trabaje en tareas bien definidas y que no necesite, o tenga poca necesidad de ayuda de los demás.
La obsesión por completar la tarea por parte de la SuperStar no es un problema, pero es fundamental que la gerencia sea capaz de gestionar estas situaciones y garantizar que el trabajo de la «SuperStar» sea comprensible y mantenible para todos los miembros del equipo.
Por eso es fundamental que el equipo analice posteriormente el código escrito por la «SuperStar», lo revise, lo documente y realice refactorizaciones para que sea comprensible y mantenible para todos.
El efecto de la «cadena de montaje»
Por lo tanto, debemos evitar pensar en la programación como una cadena de montaje, en la que cada persona es responsable de una sola tarea y no tiene ninguna responsabilidad hacia los demás.
¿Por qué has puesto esta línea de código que ralentiza el programa?
Porque de esta manera resolví una advertencia de seguridad.
¿Pero no te diste cuenta de que podrías haberlo hecho de esta manera?
No, no me di cuenta, no era mi tarea.Sin embargo, ten cuidado de no abusar del enfoque opuesto, donde tan pronto como una persona termina sus actividades, se le asignan continuamente nuevas tareas o se cierran los trabajos de otras personas.
Esto podría llevar a situaciones en las que las personas perciben un aumento del estrés y una carga de trabajo excesiva, lo que les impide gestionar de manera óptima sus propias tareas.
El «burnout» es un problema real y tangible, y una situación mal gestionada podría fomentar la insatisfacción laboral y el alejamiento de las personas más talentosas, que se sienten abrumadas por la cantidad de tareas que deben completar.
Del mismo modo, puede haber personas que deliberadamente ralenticen su trabajo para evitar tener que hacer el trabajo de los demás. En estos casos, es fundamental que la gerencia sea capaz de gestionar estas situaciones, garantizar que la carga de trabajo se distribuya equitativamente entre los miembros del equipo y poner en práctica una serie de estrategias para mejorar la colaboración dentro del equipo.
Conclusiones
Un buen programador no es aquel que completa todas las tareas asignadas, sino aquel que se le permite trabajar de manera colaborativa y compartir sus conocimientos con los demás miembros del equipo.
Es necesario hacer crecer al grupo de trabajo en el que uno está inserto, y es importante que la gerencia no evalúe sus resultados solo en función de datos numéricos, sino que sea capaz de gestionar a las personas, escucharlas, motivarlas y comprender dónde están las diferencias para nivelarlas.
El valor que puede aportar un senior va más allá de la resolución de tareas, debe extenderse a actividades de coaching y mentoría, para hacer crecer a aquellos con menos experiencia.
Esta es la mejor manera de garantizar que el proyecto de software sea exitoso y que el equipo sea capaz de crecer y mejorar con el tiempo.
