Cuando trabajamos en equipo uno de los objetivos que tenemos que tener como programador o gestor es que cuando se trabaja con otros compañeros, ser un elemento de suma al equipo y sus procesos, no de resta.
Esto en ocasiones no es fácil ya que en ocasiones la forma de trabajar de los equipos en los que entramos (o creamos), no comparten una cultura favorecen la integración y revisar los procesos (si existen) para mejorarlos.
La palabra “cultura” es muy importante en este contexto, ya que trata de definir que los procesos y hábitos que mantienen un grupo de personas. Es el ambiente de trabajo que nos vamos a encontrar en un equipo.
Ahí es donde entramos nosotros (y este artículo) y nuestras ganas de generar cambios para mejorar.
Que buscamos en un equipo
Hay mucha literatura sobre el caso ideal de un equipo, donde todo los componentes tiene una cultura de colaboración, transparencia y comunicación.
En ocasiones no se puede.. y no se puede
Voy a poner sobre la mesa, algo que no te van a contar en los cursos de “mentoring” ni en la mayoría de los textos que tratan este tema. En ocasiones, no se puede.
Un equipo tiene unas dinámicas que llevan años implantadas, y que influirlas o intentar cambiarlas supondría desmontar todos los procesos actuales y volverlos a pensar, y la resistencia al cambio que te vas a encontrar es tan alta, que sinceramente puede no merecer la pena.
Resumiendo, si entras en un equipo que lleva años trabajando mal, separado, con fricciones constantes, pero defienden ese modo de trabajo la mejor opción es salir del equipo, o bien explicar que no es una buena forma de trabajar, y hablar con tu responsable para que te cambien de equipo.
No es es un fracaso, sencillamente nadie va a cambiar si no quiere.
Que hay que evitar
Antes de empezar a hablar de como ir generando cultura, creo que es importante identificar algunos problemas que son un clásico dentro de los equipos, y que pueden provocar que no mejoremos la cultura si no que empeoremos.
Lobos solitarios
Tienes un compañero ante cualquier tarea suele responder: “ya me ocupo yo”, o “yo trabajo mejor solo”… O a la inversa, donde otros compañeros no pueden trabajar con una persona del equipo porque sencillamente rechaza cualquier interacción o colaboración. Se suele asociar a los programadores que son muy productivos “pero solos”, y que no saben trabajar en equipo.
Estas actitudes tendrían que levantar alarmas dentro de un equipo, ya que llevan a los silos de conocimiento (que trataremos mas adelante), y además son bastante complicados de eliminar porque habitualmente, al principio suelen dar la impresión de aumentar la productividad del equipo. Yo, me encargo de esto, y solo de esto.
¿Pero entonces porqué hay que preocuparse de estas cosas?, si esta persona es más productiva trabajando solo o sin que nadie le interrumpa habrá que dejarle. Porqué tarde o temprano este tipo de actitudes van a llevar a problemas dentro del equipo. Estos compañeros suelen ir por libre, llegará a tomar decisiones que pueden provocar problemas a otras partes del equipo, o que directamente van en contra del resto. Además atesorará su “territorio” como propio, es decir, su código es suyo y sólo suyo, y hará que el resto se haga dependiente de él, o tengamos que aceptar cualquier decisión que tome ya que nos “tenemos que adaptar a él/ella”.
Esto tiene que se atajado tanto por los compañeros como los responsables del equipo, ya que tiene que hacerse entender que un equipo se sustenta en que todas las personas que forman el equipo van a apoyarse unas a otras y además cualquiera puede cubrir a cualquier otro.
Silos de conocimiento
Sabes ese oscuro código que nadie comprende, o ese script que parece mágico y que usa conjuros arcanos. O incluso magos que tienen la sabiduría de como hacer una migración o corregir un error recurrente. Es una parte del conocimiento que alguien atesora y mima como si fuera suya, y no es compartido por nadie más del equipo. ¿Os acordáis del anillo único?, pues algo asi.
Este es otro gran problema. Es un silo de conocimiento que provoca que el equipo no pueda avanzar hasta que alguien pueda hacer frente al problema. ¿Nunca te ha pasado que hay unos SQLs oscuros dentro del código, o bien unas relaciones entre entidades del código, y que sólo una persona (habitualmente el que las escribió) entiende y que solo es puede cambiar?. Y si, tiene mucho que ver con los lobos solitarios, pero también como efecto secundario tenemos estas partes que nadie entiende y que posiblemente sean importantes en tu código.
Evitar los silos de conocimiento es algo que se tiene que detectar antes de que ocurra, y cuando ocurre hay que forzar la entrada de otro compañero dentro del desarrollo de esa parte, y que también termine entendiendo que magia arcana se produce en esa parte de nuestro producto.
Para evitar estos silos la mejor solución es la documentación, pero todos sabemos que en muchas ocasiones esto no es tan sencillo ya que implica mantener la documentación, y además una infraestructura compartida para que todos podamos tener acceso y actualizarla de manera ágil. Una opción mucho más aplicable directamente es incentivar a que se comparta el conocimiento, y se valore dar charlas explicando dichos silos, o descubrimientos que hagas mientras estas trabajando, o fallos que se encuentre. Hacer la información abierta y accesible.
El eslogan más trillado: “Somos un equipo/familia/amigos”
No hay mayor “red flag” que usar la frase “somos una familia”. Esto solo indica una cosa: quieren que te esfuerces por encima de lo que te retribuyen. Huye de esta frase, y de la gente que las abandera.
La relación en un equipo es sencilla, haz un trabajo (el cual genera un beneficio a tu empresa) y se te será retribuido. Nada más, no tiene que existir una relación más profunda.
Forzar una solución, si no la hay
Se que llegar a este punto no lo que nadie quiere, pero en ocasiones un equipo no funciona.
¿Y que queda entonces?. Pues es complicado, pero desde luego si el equipo o parte de él no puede funcionar en conjunto. La solución es la obvia: no puede funcionar. Si eres un gerente, tendrás que hablar para que los elementos que no funcionan salgan del equipo, y si eres un desarrollador tendrás que hablar con tu gerente/jefe de proyecto.
No hay que darle más vueltas, y es cierto que de todo se aprende, aunque estas acciones suelen tener muchas fricciones en la parte personal.
Mejorar y mejorar
Vale, hemos listado las cosas que queremos evitar, pero porque no centrarnos en que procesos podemos incluir en la cultura de nuestro equipo para ir poco a poco mejorando.
Poco a poco
A ver, es obvio. No hay que forzar un cambio de arriba a abajo en una semana. No va a funcionar, ya te lo adelanto yo, porque la resistencia al cambio va a ser muy fuerte, y además vas a provocar que el rendimiento del equipo se resienta, lo que puede ser la lápida a los cambios, y la justificación de quedarnos como estamos.
Mi recomendación: mejora un problema cada vez, definiendo un alcance realista, y muy concreto. Por ejemplo, no decir “vamos a documentar” en general, si no “vamos a hacer un documento donde cada vez que se termine una feature se escriba que el caso de uso, y su lógica de negocio” y dejar un documento de prueba en una directorio común para todos.
Confianza para hablar de los problemas
“No lo entiendo”. Esta frase denota mucha madurez, e indica que no hay miedo a reconocer que puede que no tengas una solución a cada problema.
Esto es lo que buscamos, un equipo que no tenga miedo a indicar que no conoce la solución, la tecnología o que no cree que sea la solución correcta la tomada desde el manager.
Escuchar a todos los miembros del equipo, y ofrecer siempre una justificación a las acciones tomadas. Esto da confianza a la gente con la trabajas de tener todo un sentido y estar orientados hacia algo común.
Cuando alguien proponga algo que no se puede añadir a los procesos del equipo, hay que justificar el porque no se incluye. Es muy importante, un “no” puede ser frustrante para la gente que haga una propuesta, pero un “no, porque esto choca con … Pero habrá que analizarlo mas adelante”, es mucho más gratificante.
Todas las opiniones son escuchadas, y valoradas
Continuando con lo anterior, hay que escuchar todo lo que nos venga de otros compañeros, e incluso aunque la idea o la propuesta se alocada, no desecharla, si no al menos tratar de entender porque se ha llegado a proponer.
Es fácil que se llegue a proponer una mejora que empeore el rendimiento del equipo, cuando busca lo contrario, y la experiencia nos dicta que no hay que aplicarla. Pues es muy valioso, sencillamente tratar de entender lo que se propone y explicar el porque no se debe o puede aplicar. De nuevo y como contamos en la parte de confianza esto ayuda a que la gente no tenga miedo o reparo a proponer ideas, por alocadas que sean.
Comunicación sencilla y transparente
Hay que ofrecer maneras de comunicar de manera sencilla, sin burocracia. Tener la mensajería abierta puede ser sencillamente la mejor manera de facilitar dicha comunicación.
Establecer procesos para centralizar la información y que sea accesible por todo el equipo sin trabas. Puede ser un directorio en un FTP, un gestor documental, o una carpeta compartida. Da igual, todo tenemos que tener en mente que hay una manera de dejar la información de manera que todo el mundo la pueda consultar.
Generar envidia sana
Quizás sea el mejor consejo que te puedo dar, ya que no es algo que te vaya a generar fricciones personales, ni te va a generar problemas con el equipo que sea reticente a trabajar en equipo: Generar envidia.
Para lograr esto, tienes que demostrar que trabajar de otra manera es posible, y además que este nuevo proceso funciona, con el equipo trabajando con confianza, coordinación, más tranquilo y con menos trabajo.
Y como afronto obtener este objetivo, vamos a verlo. Por ejemplo, comentar en las dailys los progresos obtenidos por cambios en los procesos puede ser un buen escaparate, pero si no involucras a terceros no se extienda entre el equipo. Por lo que quizás lo que mejor funcione según mi experiencia es buscar un problema que se dentro del equipo, por ejemplo, fallos en la comunicación entre dos servicios, y anunciando que te vas a enfrentar a este problema intenta formar equipo con otras personas que lo sufran y busca una solución consensuada con el resto. Puede ser definir un contrato, o un documento donde se describa una API, eso ya dependerá del problema o el equipo, pero soluciona (o al menos mejora el problema), y luego vende tu pequeña victoria.
Esto va a hacer que los que no confiaban en ti, ya te vean con otros ojos, o al menos entiendan que los cambios que propones no son para molestar, si no para mejorar.
Automatizar te hace feliz
Una cosa que quema mucho a los equipos es la burocracia o tareas repetitivas que no añaden mucho valor al producto.
Escribir una y otra vez la misma documentación puede lleva a un hastío por parte de un compañero de equipo. Quizás hacer una plantilla del documento, que sólo te obligue a generar la documentación que cambia, ayuda mucho y a la larga va a hacer que la documentación este más actualizada.
Test, test y test
¿Y este punto que pinta aquí?. Personalmente creo que los test transciende los procesos, y la cultura de equipo. Tener test es parte de una cultura de equipo que va facilitar mucho la confianza entre todos, y en la calidad del software que desarrollamos.
No hay nada mas gratificante que un compañero añada una funcionalidad, donde haya unos test que comprueben que todo funciona bien. Además de ser incluso si se quiere parte de la documentación al explicar una entrada y una salida de la lógica de negocio.