Tras más de 20 años trabajando en todo tipo de empresas teniendo equipos de trabajo a mi cargo, pienso que gestionar a un equipo de desarrolladores de software no varía sustancialmente de coordinar a cualquier otro tipo de equipos de trabajo. La mayoría de los programadores lo que quieren es un jefe que:
- Les ayude a organizar el trabajo y les resuelva dudas
- Les ayude a avanzar en su carrera profesional
- Haga equipo frente al resto de la organización para defender al departamento
- Les diga lo que hacen bien y lo que hacen mal con buenas formas
- Y todas las demás cosas que las personas esperan de un responsable de un equipo de trabajo...
Aquí el matiz está en que no varía sustancialmente.
Por ejemplo, gestionando a equipos de venta nunca he tenido que hacer reuniones para fomentar la comunicación y que los miembros del equipo fueran asertivos y claros entre ellos. Eso ya se daba "por defecto". Todas las reuniones de aspectos de mejora eran sobre si se seguían mejor o peor los procedimientos de venta, si documentaban en la aplicación todos los datos de los preclientes y clientes, si un comercial no debería intervenir ni tener injerencia en la venta de otro comercial, y también mucha gestión de reconocimientos y logros.
Por otro lado, coordinando equipos creativos de diseñadores gráficos y redactores de contenidos, las reuniones siempre versaban sobre la productividad del equipo, sobre la importancia de vender bien el trabajo al cliente y de hacer cosas que el cliente percibiera como útiles, sobre cómo mantener el foco y no dispersarse; en general cosas relacionadas con la gestión del tiempo.
Un buen creativo pierde el tiempo, un buen comercial lo aprovecha al máximo para irse antes a casa, al igual que un buen piloto de una aerolínea comercial es organizado y metódico y sigue al dedillo todos los protocolos.
Todos los departamentos y los equipos de trabajo necesitan más o menos las mismas cosas, pero la forma de gestionarlos sí varía un poco en función de los perfiles. Para trabajar a gusto con un equipo comercial hay que ser muy estricto con los procedimientos y nunca hacer concesiones con el trabajo administrativo, y para que un departamento creativo funcione es fundamental que no pierdan de vista que trabajan con empresas que quieren comunicar para vender más, no solo para ser "guay" o artístico.
Este artículo va dirigido a los responsables de equipos de programación. Evidentemente la gestión de un equipo de desarrolladores sí tiene sus matices que voy a intentar desgranar a continuación. Algunos de estos consejos pueden ser utilizados para la gestión de personal en general, no sólo en empresas de desarrollo de software.
1.- Dales confianza y responsabilidad y evita ser un "mandón"
Una de las cosas que más quieren los desarrolladores es un responsable que reconozca sus capacidades y confíe en que harán bien su trabajo. Basta con encontrar la manera de que los programadores lo hagan de una manera que beneficie a la empresa.
Nunca le digas a un desarrollador qué método/lenguaje/entorno debe usar. El ejemplo más común es pedirles cosas del tipo "Necesito un sitio web hecho con Drupal" y quien lo pide es una persona que ni programa y que ni siquiera sabe lo que es Drupal, sólo ha oído que alguien en otra empresa lo ha hecho así y que iba muy bien...
Por supuesto, la excepción a este consejo es si eres desarrollador y sabes hablarles en el mismo idioma. Pero aun así, se debe especificar claramente el objetivo de la tarea y los plazos, y la toma de decisiones tecnológicas la debe hacer el desarrollador siempre que sea posible. Es más motivador y mejora ostensiblemente el rendimiento del programador si tienen voz y voto en la relación con las herramientas que van a usar.
Los desarrolladores (y, francamente, todos los profesionales con experiencia) no operan sobre la base de "Yo soy el jefe, tú eres mi empleado/esclavo".
Por lo tanto, es importante ser amigable, asignar las tareas, comentarlas, no forzar demasiado la urgencia - no dará resultados, sino que sólo añadirá estrés. De hecho, esto podría producir resultados a corto plazo, pero a largo plazo arruinará la relación laboral y personal.
Además, dar confianza también implica darles tiempo a los programadores para pensar más allá de la programación y el código. Dándoles la oportunidad de desarrollar soluciones autónomamente les ayudará a mantenerse creativos, que al final beneficiará a la empresa.
Nota de campusMVP: Incentivar el testing puede ayudar a la productividad de los equipos de desarrollo, por ello nos ha parecido oportuno incluir este video en el post.
2.- Haz de enlace con resto de la empresa y analiza bien los requisitos de cualquier tarea antes de asignarla
Los desarrolladores son unos profesionales con un talento especial, pero no hacen magia ni saben leer la mente del coordinador ni la mente del cliente. Necesitan instrucciones claras sobre lo que hay que hacer (recuerda - diles el qué, no el cómo, tal y como comentamos arriba).
Si dedicas más esfuerzo a escribir las especificaciones o detalles de las tareas, no sólo ahorrarás tiempo a largo plazo, evitando discusiones innecesarias, sino que también te ayudará a evitar errores o malentendidos por parte del desarrollador.
Otra ventaja de tener una tarea escrita (no importa dónde - a mí me gusta Jira o incluso Trello o un Google Docs también valdría) es que todo el mundo puede volver a ella más tarde y comprobar si lo han hecho todo correctamente. Créeme, te olvidarás de los detalles de las tareas en un mes o incluso en una semana - es increíblemente útil tener esta guía de referencia y no te llevará mucho tiempo prepararla, o al menos no tanto como luego tener que subsanar errores o malos entendidos.
Los desarrolladores quieren que un gerente les proporcione una lista de tareas priorizadas con prioridades coherentes. Ningún desarrollador disfruta de plazos poco realistas, y una de las únicas maneras de atenuar esto es analizar a fondo los requisitos de antemano. Hay que ser persistente en cuanto a los requerimientos y requisitos de una tarea en la programación de software. Es la única manera de comprender realmente el alcance y gestionar las expectativas en torno a las fechas de entrega de una manera razonable.
Cuando los resultados son significativamente diferentes de las expectativas, esto crea una carga operativa muy costosa. La mejor manera de evitar este problema es invirtiendo esfuerzos por adelantado y asegurándose de que los demás departamentos de la empresa vayan exigiendo resultados y productividad de una manera totalmente proporcionada y realista.
Para conseguir resultados finales, por lo general hay más de un desarrollador involucrado. También hay diseñadores, redactores, gerentes y otras personas. Tienes que ser un interlocutor entre todos ellos. Ten en cuenta que estas personas no hablan el mismo idioma que los miembros de tu equipo.
No sólo hay que transmitir y traducir la información, sino que también hay que ayudar a obtener toda la información necesaria para cumplir con las tareas en forma y plazo. Un ejemplo bastante común es cuando un desarrollador está esperando archivos de diseño o alguna aclaración de un gerente, y cuanto más tiempo se tarda, más problemas se presentan para el proyecto en su conjunto.
3.- Asigna las tareas en forma de reto y haz de ello un juego fomentando la comunicación
A los desarrolladores les gustan los retos. Adoran los desafíos. Es por eso que los eventos como los hackatones son tan populares - la gente se reúne durante 24 o 48 horas para crear proyectos increíbles en muy poco tiempo. Así que cuando se le da una tarea al desarrollador, hay que pensar en ello de esta forma: tú les dices la meta final, y luego ellos deciden cómo cumplirla eficazmente.
No sólo eso - si le dices la razón por la que estás desarrollando una funcionalidad, un desarrollador podría cambiar la forma de programarla para que sea más fácil de usar o de mantener en el futuro. Muchas decisiones técnicas dependen de cómo se vaya a utilizar la solución, y de si es una funcionalidad estrella o no.
Y aquí vuelve a tener relevancia el tema de tener bien detalladas todas las especificaciones de un proyecto. No basta con desmenuzarlas y repartir tareas... No importa lo bien que creas que has comunicado las especificaciones, los desarrolladores seguirán teniendo preguntas. El desarrollo es un proceso iterativo.
Este es otro escenario en el que el esfuerzo inicial da sus frutos: una vez que hayas reunido los requisitos que tengan más lógica, involucra a los desarrolladores antes de empezar a trabajar. Los técnicos deben tener la posibilidad de criticar, ampliar o rechazar directamente los requisitos si no tienen sentido para ellos.
Una vez repartidas las tareas y comenzado el trabajo, se aplica la misma lógica: los requerimientos y especificaciones son básicamente una especie de documento vivo que evoluciona durante el desarrollo del proyecto. Hay que iterar y promover métodos de trabajo que fomenten la iteración.
Por otro lado, no evalúes cada paso que den, no caigas en la micro-gestión. Si intentas participar en cada decisión, discutir cada detalle o medir sus horas de trabajo/minutos, puedes irritarles muy fácilmente. Y por consiguiente matas la productividad. Hay una delgada línea entre ayudar activamente y micro gestionar. Delega y mide, pero de forma equilibrada.
El beneficio final de tal diálogo es que el desarrollador puede encontrar una manera diferente de enfocar la misma función - incluso puede llevar a NO programarla siguiendo la regla de 80/20 que tan bien aplican los buenos programadores (lo que le ahorraría tiempo y dinero, ¡impresionante!). Así que prepárate para escuchar las opiniones de los desarrolladores, les encanta ser escuchados.
4.- Trabaja la motivación e impulsa la mejora continua
Los mejores desarrolladores están continuamente tratando de perfeccionar sus habilidades. Los mejores responsables de equipo facilitan el crecimiento. Para ello, busca una cosa específica en la que puedan centrarse.
Es motivante decirles cosas del tipo: "Enfócate en dividir tu trabajo en partes más pequeñas," o, "Me gustaría verte mejorar y hacer más refactorización y mantenimiento de código heredado."
Es buena idea usar un plan de desarrollo personal para sugerir áreas de estudio y formación que el desarrollador puede llevar a cabo durante tiempos de mayor inactividad en combinación con su tiempo libre. Tomar interés en el desarrollo profesional de los programadores a tu cargo te ayudará a tener un departamento puntero, beneficiando en última instancia a tu empresa. En mi empresa hacemos reuniones para hablar y medir el progreso de la mejora continua cada seis meses.
La retroalimentación constante en la empresa o simplemente minidebates aleatorios sobre el trabajo son una excelente manera de no perder el buen camino para tener un equipo motivado y para detectar necesidades.
Detrás de todo esto hay una parte psicológica: a los desarrolladores les gusta llamar la atención y estar visibles, sentirse importantes. En realidad, a todas las personas les gusta. Así que si de vez en cuando preguntas aleatoriamente "¿Cómo te va?", "¿En qué crees que puedes mejorar?", etc. puedes conseguir una buena motivación adicional para el desarrollador. Simplemente no te pases con esas preguntas - sé práctico y amigable, pero no molestes.
Nota de campusMVP: El hecho de hacer o no testing (a nivel de cultura empresarial) puede tener una gran repercusión en el enfoque de mejora continua de los equipos de desarrollo, por ello nos ha parecido interesante incluir este video en el post.
5.- Conoce bien a los miembros del equipo y reparte las tareas en consonancia con sus fortalezas y debilidades
El desarrollo de software es algo muy grande. Hay "mundos" móviles, web y otros de programación a más bajo nivel, y cada uno de ellos está subdividido en sistemas operativos, front-back-end, y luego hay mil lenguajes/tecnologías. Uno simplemente no puede ser bueno en todo. Por lo tanto, es necesario saber quién es la mejor persona para realizar una determinada tarea en cada momento.
Incluso dentro de una misma tarea, a veces tiene sentido dividirla en subtareas y delegar alguna parte en otro desarrollador. El objetivo aquí es obtener un buen resultado global, así que usa tus recursos sabiamente.
Y recuerda: si un desarrollador no sabe hacer algo, esto no lo hace directamente peor programador ni ser menos profesional, sólo significa que no tiene experiencia en algo que se necesita. Pero es probable que tenga más experiencia en otros campos, o que esté dispuesto a aprender/adaptarse rápidamente -a menudo es incluso más importante que tener conocimiento, tener una buena actitud.
Un responsable sin experiencia puede llegar a creer que si añade más desarrolladores a un proyecto, se incrementará la productividad. Esta práctica rara vez es útil, ya que los nuevos desarrolladores incorporados ralentizarán el desarrollo hasta que se pongan al día con el proyecto.
Una mejor solución para mejorar la productividad de los desarrolladores es reorganizar al equipo para avanzar haciendo pequeñas tareas, y que normalmente se pueden realizar en pocos días o semanas. Asigna a cada miembro del equipo funciones específicas como la programación de funcionalidades por un lado, las pruebas por otro y el despliegue por otro. Asegúrate de que los desarrolladores de cada tarea tengan una variedad de niveles de experiencia, no pongas a los más jóvenes juntos.
Por último, comentar que en muchos trabajos se requiere hacer multitarea, pero en el sector de la programación de software esta práctica va en detrimento de un desarrollo eficiente y rentable. Los programadores están mucho tiempo pensando para resolver tediosos problemas conceptuales. Cualquier interrupción de este proceso tiene un coste muy alto: una interrupción inoportuna podría retrasar a alguien un buen par de horas mínimo.
Cambiar de contexto es costoso y la sobrecarga cognitiva de la multitarea tiene como resultado un rendimiento deficiente. Cuando se trabaja en múltiples proyectos, algunos jefes piden a sus desarrolladores que trabajen en un proyecto por la mañana y en otro por la tarde. La mejor solución para manejar múltiples proyectos es la distribución de sus desarrolladores en pequeños grupos dedicados a un proyecto en particular.
Conclusión
Espero que lo mencionado anteriormente te ayude a gestionar mejor tu equipo de desarrollo de software.
Es obvio que la primera regla para formar un equipo sobresaliente es la siguiente: para liderar un equipo de manera efectiva, primero hay que establecer el liderazgo con cada uno de los miembros del equipo.
Recuerda que los líderes de equipo más influyentes forjan sus relaciones con confianza y lealtad, en vez de con miedo o con el poder de sus cargos.
Si gestionas equipos de programación, no dudes en comentarnos lo que mejor te funciona en la empresa 😊
Fecha de publicación: