APZ: Como solucionar problemas de comunicaciones en el equipo
APZ: Armado de Procesos desde Zero. Cómo armar todos los procesos de negocio y trabajo en un equipo de desarrollo, sea presencial, distribuido o mixto.
Arrancando con este long read quiero compartir experiencia de armado de procesos de negocio y trabajo en un equipo de desarrollo. En el caso, equipo 100% remoto sin dependencia geográfica. Tenga en cuenta, que es una experiencia propia, aplicando un mix de tecnologías, metodologías conocidas y herramientas disponibles.
Vamos a tomar un mate (ó cafe)
Comencemos por construir una comunicación efectiva dentro del departamento de desarrollo. En cualquier equipo, es importante crear canales efectivos y formas de comunicación, pero cuando el equipo es remoto, esta necesidad aumenta aún mas. La necesidad se logra su máxima agudeza cuando el equipo está parcialmente distribuido. Tienes que buscar manera de empalmar dos mundos: de la oficina y de los remotos.
El problema de comunicación más importante — son diálogos y discusiones verbales. Los co-workers de oficina tienen una costumbre, es un clásico “vamos a tomar un mate” para conversar los asuntos del proyecto. En este caso, los remotos se quedan por fuera de la conversación. Por consiguiente, no estarán al tanto de las cosas, tampoco van a poder dejar su opinión y participar en el diálogo. Esto es una desincronización, desbalance el equipo. Por último, esta “taza de cafe” dejará un mal sentimiento para los remotos y aislará dos segmentos de co-workers.
Esta claro que asuntos más importantes y críticos para todos hay que documentar en forma escrita ( por el medio de un chat grupal o llamadas grupales, haciendo un scrum)
Cultura de escribir y expresarse con claridad
Sin embargo, (y nadie lo tiene presente), esta conclusión (ref: hacer un scrum) genera otro problema muy común que aparece en los equipos cuando se requiere escribir bastante y frecuente: el problema de la cultura de la escritura.
Ya no habrá posibilidad de acercarse al colega, sonreír, expresas con gestos, mímica, dibujar algo en papel, interactuar físicamente. Por un lado, esto complica en cierta forma el trabajo y comunicación en sí. Por otro lado, las personas desarrollan la habilidad de expresar sus pensamientos escribiendo y en una forma comprensible y estructurada. Como resultado, la documentación de proyectos, comentarios en código serán mejor descriptas, los tasks serán expresados con mejor claridad. Cada uno comenzará a pensar cómo presentar su idea de tal manera, que los demás se la comprendan desde la primera lectura.
Todo lo antedicho no significa que comunicación verbal debe desaparecer. A lo que voy, es que esta modalidad deberá tomarse como una medida de restricción.
Si hubo una comunicación verbal, hay que declararla en una base de conocimientos. Mantengan como regla documentar su Wiki propia del equipo en base de lo que conversan verbalmente o un un scrum. Este artefacto de conocimientos debe ser accesible para todos siempre.
Brevemente
Herramientas que pueden ayudar a construir procesos de comunicación:
- Llamadas grupales (audio y video): Hangouts Meet / appear.in
- Chat grupal, integraciones, notificadores, monitoreo: Slack
- Para Wiki: Confluence (o cualquier otra alternativa)
- Tasks, Bug Tracker: Jira (o similar)
Por último, tiene que haber un reglamento que dice dónde, cuando debemos escribir. Los reportes de bugs también tiene que tener un formato único.
Tienes algo que agregar? Deja un comentario o manda un PM.