¿Existe tal cosa como demasiada comunicación de mensajes instantáneos para un equipo remoto?

El equipo desea que cada desarrollador informe a los demás desarrolladores sobre el progreso que están logrando en sus historias. Por ejemplo, "Listo para revisión por pares", "Revisado por pares", "Control de calidad aprobado", "Implementado en producción", etc. El equipo es 100 % remoto. Estos estados se comunican a través de notificaciones por correo electrónico mediante herramientas existentes como JIRA y service now (una aplicación de CRM), así como también se informan oralmente en las reuniones diarias. Pero el equipo afirma que no siempre controlan su correo electrónico y que la información permanente se retrasa, por lo que quieren estar informados a través del canal de mensajes instantáneos del equipo. Personalmente, me parece innecesario (y molesto) proporcionar estas actualizaciones en el chat cuando ya tenemos herramientas que comunican esto. Mi argumento es la simplicidad - (maximizar lo que no se hace) y la eficiencia. ¿Qué piensan ustedes?

Tal vez pueda encontrar una forma de que las herramientas existentes publiquen en su canal de mensajería instantánea...
¿No es la noción de un equipo auto-organizado lo que ellos organizan? ¿Por qué es necesario controlar su flujo de información? (¿y por qué no pueden publicar las notificaciones en los canales que les parezcan?)

Respuestas (6)

Tu problema no es la mensajería instantánea. La mensajería instantánea en un equipo remoto es un sustituto de hablar en un equipo local. Tratar de decir que toda comunicación verbal debe cumplir con la máxima eficiencia y nunca decir nada innecesario es... bastante tonto.

Pero.

Es igualmente tonto que las personas se comuniquen constantemente entre sí (verbalmente o de otra manera) sobre el estado de las tareas.

Para eso sirve un tablero Sprint/Kanban.

Un tablero Sprint/Kanban es un radiador de información , es decir, es un informante de tipo pull, no de tipo push. Cuando alguien quiere saber el estado, solo mira el tablero sin molestar a nadie.

Esta pregunta no se trata realmente de "demasiada comunicación de mensajes instantáneos", sino de canales de comunicación efectivos. Algunas cosas se destacan.

No me preocupa el hecho de que el equipo no siempre controle su correo electrónico. El correo electrónico no debe usarse para comunicaciones sensibles al tiempo. Creo que es razonable que la mayoría de los desarrolladores revisen su correo electrónico dos o tres veces al día. Las personas en puestos de liderazgo o gerencia o que se comunican con los clientes con más frecuencia pueden necesitar manejar su correo electrónico con más frecuencia.

El mayor problema que veo es que uno o más miembros del equipo afirman que "no siempre controlan" la información presentada en el stand-up. Esto parece ser un problema bastante grande. El propósito de un stand-up (o Scrum diario de Scrum) es permitir que el equipo coordine y planifique su día. Si hay personas que no prestan atención, sugeriría profundizar en cómo el equipo está usando este tiempo.

Si su equipo cree que necesita actualizaciones más visibles y en tiempo real del estado del trabajo, entonces parece que tiene sentido integrar su rastreador de problemas, repositorio de código fuente, software wiki y otras herramientas con su mensajería instantánea. plataforma. Los equipos con los que trabajo también han integrado calendarios de equipo, el servidor de compilación y el software APM con la plataforma de mensajería instantánea. Hay diferentes formas de hacer esto que podrían funcionar para el equipo, pero la solicitud parece razonable. Esta integración también es mucho mejor que hacer que cada desarrollador se tome el tiempo de publicar actualizaciones en la plataforma de mensajería instantánea.

La comunicación de mensajes instantáneos es imprescindible para un equipo remoto

Aquí hay un gráfico que muestra la 'riqueza del canal de comunicación' preparado por el Dr. Alistair Cockburn: La riqueza del canal de comunicaciónLa curva en la parte superior muestra las comunicaciones que son interactivas. La comunicación cara a cara en la pizarra es la más efectiva. La siguiente curva muestra comunicaciones unidireccionales. Este gráfico es antiguo. Deberíamos agregar videoconferencia por encima de las llamadas telefónicas. Y chat de texto por encima del correo electrónico.

Aquí está uno de los Principios detrás del Manifiesto Ágil :

El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él es una conversación cara a cara.

Sin embargo, los equipos remotos ya se estaban volviendo necesarios con el desarrollo en alta mar. Con la pandemia, la FMH se ha convertido en la práctica de desarrollo por defecto. Entonces, tenemos que hacer todo lo posible para que la comunicación sea más efectiva.

He sido Scrum Master para varios equipos remotos durante casi una década. Recomiendo encarecidamente agregar comunicación de mensajes instantáneos.

No creo que la pregunta fuera: si un equipo usara mensajería instantánea (a lo que respondes afirmativamente y estoy de acuerdo), la pregunta era: ¿podría alguna vez ser demasiado? Soy un ferviente usuario de Slack, pero los canales en los que los equipos obtienen actualizaciones voluminosas sobre cada cambio de estado y cada comentario de revisión de código y cada implementación (exitosa y fallida) están demasiado ocupados para mí.
El equipo quiere mensajería instantánea y el OP dice "Personalmente, me parece innecesario (y molesto) proporcionar estas actualizaciones en el chat" porque ya hay correo electrónico. Entonces, esta pregunta no se trata realmente de 'demasiada comunicación de mensajes instantáneos', aunque se plantea de esa manera.
Veamos si el autor original puede comentar, pero para mí, parece que la pregunta no se trata de una conversación humana (a través de mensajería instantánea), sino específicamente de las notificaciones automáticas de JIRA y ServiceNow. Sin embargo, me gusta mucho el contenido de tu respuesta.

La eficacia de la comunicación y el volumen de la comunicación no son lo mismo. Es posible verse abrumado por demasiada comunicación, especialmente si es del tipo incorrecto. También es posible distraerse con demasiada comunicación, lo que provoca interrupciones en la concentración y la consiguiente pérdida de tiempo rehaciendo el trabajo o corrigiendo los errores que puedan surgir. Por lo tanto, la comunicación eficaz consiste en utilizar el medio correcto en un volumen apropiado.

Dado que la información necesaria está disponible en Jira y/o Service Now, ¿por qué no echan un vistazo a estos sistemas cuando quieren información? Me parece que una fuente de información por goteo de varias personas cada vez que cambian el estado de una tarea es el tipo de comunicación equivocado en el momento equivocado, y realmente no da una idea general de cómo progresa el trabajo en general.

Sin embargo, si su equipo puede justificar por qué quieren la comunicación de la forma en que la pidieron, entonces está bien: debe tratar de apoyarlos. Si solo quieren saber sobre el progreso de todos los demás por interés, pero no esperan actuar sobre la información de ninguna manera como resultado de recibirla, ¿por qué la piden? Me preocuparía que estén utilizando la provisión de información como una forma de romper la monotonía o el aburrimiento de trabajar de forma remota, y sugeriría que hay mejores formas de lograrlo.

Esto parece ideal para un experimento:

  • Determine qué valor está tratando de obtener de la comunicación como equipo
  • Encuentre una manera de cuantificarlo y medirlo
  • Ejecutar un experimento para una serie de sprints
  • Revisar si el nuevo enfoque tuvo el impacto deseado

Ciertamente, también encuentro que la "charla" es enormemente contraproducente.

(Divulgación completa: nunca he usado Facebook, Twitter o Instagram. Y no ha habido un televisor en mi casa durante más de treinta años).

Los miembros del equipo siempre deben sentir que pueden ponerse en contacto con otro miembro del equipo cuando sea necesario , pero en mi experiencia, "[chit-]chat" probablemente no sea el medio más efectivo. Jira y otros "tableros de proyecto" similares, según mi experiencia, proporcionan un rastro de migas de pan mucho más utilizable.