Aunque este año no estoy escribiendo con tanta asiduidad como solía hacer cuando estaba estudiando (una mudanza y un cambio de ciudad tienen parte de la culpa), quería aprovechar el primer artículo de 2019 para hablar sobre gestión de equipos.
Tabla de contenidos
El equipo de trabajo, ¿es necesario?
Como muchos sabréis cada vez es más popular trabajar en remoto u otras modalidades similares de teletrabajo, que unido a la superespecialización, están haciendo que los clásicos equipos de trabajo se tambaleen. Además, muchos desarrolladores estamos acostumbrados a desempeñar nuestra labor para pequeños clientes, dónde los equipos de trabajo suelen ser unipersonales o muy pequeños (2 o 3 personas).
Desde mi experiencia, el equipo de trabajo permite mejorar en gran medida lo anterior y esta tesis vengo a defender en este artículo. Anteriormente ya hablé de las habilidades que debería tener un informático, a nivel individual.
¿Qué aporta un buen equipo de trabajo?
Para analizar el por qué de la necesidad de crear buenos equipos de trabajo, me gustaría resaltar algunas cosas que aportan tenerlos:
- Gran flexibilidad para adaptarse a los cambios técnicos, al ser varias personas es posible que unos empiecen a analizar e investigar el nuevo cambio y luego ese conocimiento sea transmitido a la otra parte del equipo.
- Acabar con las dependencias clásicas y el discurso este tema lo hizo X, es responsabilidad suya/sin él nadie sabe cómo va.
- Permite crecer de manera mucho más rápida, al poder incorporar perfiles más junior e irlos formando dentro de una cantera, siendo más fácil de gestionar su progresión y seguimiento.
Las 2 características claves de un buen equipo de trabajo
En mi caso, si solo tuviera que quedarme con 2 conceptos me quedaría con los siguientes:
- El conocimiento técnico, ya que permite al equipo hacer las tareas indicas en tiempo y forma.
- El personal que forma el equipo, que mediante su cohesión y buen ambiente permite solventar crisis de manera más suave y dotan de gran flexibilidad al equipo en todos los aspectos (tareas, turnos, vacaciones, responsabilidades, etc).
¿Cuáles son los aspectos técnicos más relevantes?
La verdad es que hablar de los conocimientos técnicos de un equipo, cómo elegir al personal según este aspecto y otros temas similares, darían no solo para otro artículo, sino quizás para un blog entero. Por esta razón, en este apartado sólo voy a dar unas pinceladas que creo interesantes.
La técnica es importante, pero también la experiencia. Esta frase, para mí incomprensible hasta hace algunos meses por mi corto bagaje en el mercado de trabajo, tiene una gran importancia. Una persona que lleva tiempo desarrollando ese mismo proyecto u otros similares, puede aportar muchísimo tanto en momentos de crisis (seguramente le habrá pasado algo similar anteriormente), como a la hora de enfocar el proyecto.
Locura es hacer lo mismo una y otra vez esperando obtener resultados diferentes. Esta genial frase que algunos atribuyen a Einstein, me sirve para ilustrar el problema de tener un equipo muy uniforme, cuyas soluciones suelen ser siempre las mismas y por tanto, los resultados también. Tener un equipo técnicamente muy uniforme, con una experiencia similar, sin gente que venga de otros sectores, paradigmas, lenguajes, etc. tiende a crear un equipo que consigue una calidad muy alta, pero que luego no es flexible a los cambios.
Todo el mundo es un genio. Pero si juzgas a un pez por su habilidad para trepar árboles, vivirá toda su vida pensando que es un inútil. Siguiendo con otra frase del autor anterior y para cerrar este apartado, considero indispensable que cada miembro del equipo pueda especializarse en algunos aspectos concretos del trabajo. Esto no significa que todas las tareas de ese tipo las haga él, sino que él pueda ser el encargado de revisarlas o supervisarlas. Muchos equipos cuentan con excelentes desarrolladores, pero no se aprovecha las capacidades de cada uno de sus miembros para contar con un analista, una persona que sepa optimizar consultas a bases de datos, etc.
Las personas, esas variables no definidas
Si comentaba en el apartado anterior lo complejo de abordar la técnica, hablar de las personas es todavía más difícil porque hasta que no trabajas con ellas y compartes varios meses juntos, no vas a poder ver cómo se acoplan al equipo. Así que mis pequeños consejos son los siguientes:
- Huye de las personas que se autoproclaman genios, nadie quiere trabajar con gente que no es humilde y desprecia a sus otros compañeros.
- Intenta conseguir un lenguaje común, para que distintos departamentos o miembros sepan de qué se está hablando en cada instante.
- Implementa actividades o acciones que permitan crear equipo: reuniones donde todos estén presentes, pair programming, alguna actividad lúdica…
- Si quieres flexibilidad, da flexibilidad, es muy común que el trabajador vea que a él se le pide ayudar en algunas tareas, hacer alguna hora extra, etc. pero luego no vea el mismo comportamiento por parte de la empresa, negando el teletrabajo, la jornada intensiva, horarios flexibles…
- Hacer equipo se puede fomentar pero no forzar, al igual que la amistad, el compañerismo es algo que surge, no se puede forzar a ello. La personalidad de cada uno hace que se conecte más que unas personas o con otras.
- Purga a la gente tóxica a tiempo, aunque es muy delicado, algunas personas con su comportamiento pueden tornar en altamente tóxico el ambiente de trabajo de un equipo. Enfrentamientos internos, críticas exacerbadas o una inmensa competitividad interna pueden ser indicios de que se está creando un mal clima.
Mi equipo, una pequeña familia
Sí, mi equipo funciona, aunque lo primero de todo es mostrar dos advertencias: ni somos un equipo perfecto, ni lo que a nosotros nos funciona es aplicable a todos.
Si tuviera que comparar a mi equipo, lo haría con una familia numerosa puesto que actualmente somos 10 personas organizadas de la siguiente manera:
- Dos progenitores, que son nuestro jefe de producto (hablaré de esto en otro artículo) y nuestro jefe de proyecto. El primero define las características del software que creamos y el segundo cómo, quién y en qué orden hacer las tareas.
- Un tío, hermano del jefe de producto, que aporta sus dotes creativas y de puesta en valor del usuario, siendo nuestro diseñador (UI y UX)
- 5 hermanos, que han acabado haciendo la misma carrera (desarrolladores backend), que comparten muchos conocimientos. Pero divergen en experiencia, trayectoria y muchas veces, enfoque.
- 2 hermanos, que al contrario que los anteriores, se centran en la parte más visual del desarrollo (desarrolladores frontend).
Respecto a algunas actividades que intentamos hacer de manera más o menos usual para hacer equipio, detallaría las siguientes:
- Todos los jueves solemos comer juntos fuera de la oficina.
- Prácticamente cada día intentamos tomar un café juntos mientras hacemos una pequeña daily.
- Intentamos asistir todos a las reuniones de desarrollo de nuestro equipo y obligamos, a que todos valoren cada tarea (tiempos, enfoque, etc.).
- Usamos pair programming, cuando hay que desarrollar o refactorizar aspectos críticos de la aplicación.
- Los viernes también es costumbre tomar una caña al salir de trabajar.
Otros consejos para mejorar tu equipo
Aprovechando que cada vez hay más conferencias, muchas de ellas de gran importancia y centradas en la gestión de los equipos, os recomiendo la siguiente ponencia. La misma trata de como poner en valor a las personas del equipo, así como mejorar la manera de transmitir las ideas, sugerencias y quejas.
Espero que os parezca tan interesante como a mí.
¿Tienes un equipo de desarrollo? ¿También tu equipo funciona? ¿No acaba de arrancar? ¿Sigues alguna otra metodología? Déjanos un comentario y pon en común tu visión/problemas para tener otras opiniones.
Un saludo.