¿Quién se beneficiará de este artículo?
El artículo será útil para líderes y miembros de equipos de proyectos pequeños de 5-10-15 personas.
¿Qué usar y por qué?
Utilizamos Slack personalmente para comunicarnos y compartir información.
La mayor parte de lo que se escribe a continuación, de una forma u otra, se puede organizar en otros mensajeros.
Razones por las que usamos Slack:
- Conveniencia para organizar chats grupales (canales)
- La presencia de hilos: la capacidad de crear ramas de diálogo.
- Diferenciación entre diálogos laborales y no laborales. Trabaja en Slack. Otro - en telegram / watsap / where
- Disponibilidad de reacciones
- Disponibilidad de recordatorios
- La capacidad de integrar Slack con muchas herramientas.
Si hay alguna alternativa de Slack para la que los 6 puntos anteriores serían ciertos, dímelo en los comentarios. Y para una alternativa de este tipo, dígame qué características interesantes tiene y que se utilizan con frecuencia en su equipo.
¿Cuáles son las reglas de comunicación en el equipo y por qué?
1. No te comuniques en PM
Dejamos la comunicación en PM solo para dos casos:
- Hablar de algo que requiera privacidad.
- Memasiks / bromas y otras inundaciones.
Para todo lo demás, utilizamos canales de comunicación comunes.
Ahora te diré para qué sirve. Te contaré un poco más adelante cómo organizar los canales de comunicación comunes para que no haya desorden y caos.
¿Por qué es necesaria esta regla?
Esta regla es necesaria para:
- Era posible detectar situaciones en las que alguien se desviaba del curso y comenzaba a hacer algo mal.
- Era posible detectar situaciones en las que alguien comenzaba a hacer algo mal.
- No hubo situaciones en las que dos personas estuvieran de acuerdo en algo y alguien más sufrió esto.
- Los líderes podrían monitorear la coordinación del trabajo en equipo.
- Los gerentes podrían rastrear la ocurrencia de conflictos, resentimientos y la ocurrencia de otra negatividad.
2. Etiquete a aquellos a quienes va dirigida la apelación
Cualquier mensaje debe tener un destinatario. Uno o mas.
Cuando se refiera a alguien, debe etiquetarlo.
Cuando se dirija a varias personas, etiquete a todos, no a todos en el canal.
¿Por qué es necesaria esta regla?
Esta regla es necesaria para:
- No todos los participantes del chat se distrajeron con los mensajes en los chats / conversaciones grupales, sino solo aquellos que fueron etiquetados.
- La probabilidad de que el destinatario mostrara una notificación era máxima. Por ejemplo, en Slack, las notificaciones a veces se pierden.
3. Reaccionar a los mensajes
Los destinatarios de este mensaje no deben ignorar cualquier mensaje enviado por alguien (no automáticamente) . El destinatario, al recibir un mensaje, debe dar una respuesta. Si hay varios destinatarios, todos deberían reaccionar.
Para no escribir las frases "ok", "entendido", etc., Slack tiene una función conveniente: reacciones. Los miembros de nuestro equipo suelen poner una reacción: ojos:. El líder usa la reacción: ojo:.
¿Por qué es necesaria esta regla?
Esta regla es necesaria para que el remitente sepa que su mensaje "no se perdió".
4. Usa hilos
Slack tiene una función como los hilos: la capacidad de crear un "hilo de conversación" y realizar una conversación en él, y no en el flujo de mensajes principal.
Esta función es adecuada para discutir un solo tema.
¿Por qué es necesaria esta regla?
Esta regla es necesaria para no ensuciar el flujo principal de mensajes, aumentando así la estructura de la información y la facilidad de navegación a través de ella.
5. Registra las conversaciones que tuvieron lugar fuera de Slack
Si tuvo lugar algún diálogo, por ejemplo, en la llamada, entonces debe incluir un protocolo basado en los resultados de la llamada, un conjunto de tesis que reflejen los resultados de la conversación.
¿Por qué es necesaria esta regla?
Esta regla es necesaria para:
- Asegúrese una vez más que los participantes del diálogo se entendieron correctamente.
- No olvidamos lo que acordamos
- Fueron conscientes de lo que estaba pasando quienes no aceptaron en el diálogo, pero se interesaron por el tema del diálogo.
- Se pudo hacer referencia a los resultados de la conversación.
- ... y los mismos argumentos del primer párrafo sobre canales de comunicación comunes
Los protocolos deben tener destinatarios y recibir respuestas.
No todo el mundo debe ser puesto como destinatario, sino aquellos a quienes concierne el tema de este diálogo.
6. Inicie una llamada / reunión si el problema no se resuelve en 15 minutos de correspondencia activa
Aquí todo es simple: si ves que tienes que escribir mucho texto, si comienza un lío en el chat, necesitas iniciar una llamada y discutir todo con una voz.
Y como resultado de la llamada, envíe a todos el protocolo.
7. Realizar reuniones diarias por escrito.
Una reunión diaria es una reunión de grupo en la que cada miembro del equipo debe responder varias preguntas candentes y discutir temas / problemas actuales para sincronizar el equipo. Ejemplo de una serie de preguntas para reuniones diarias:
- ¿Qué hiciste ayer?
- Que haré hoy
- ¿Qué problemas tengo en mi camino?
Celebramos reuniones diarias de 11:30 am a 11:35 am en un chat grupal dedicado. El gerente escribe en último lugar: a las 11:36. Cualquiera que cancele la suscripción después de que se considere tarde. El trabajo educativo debe realizarse con los recién llegados. Todo el mundo debería poner debajo del mensaje de cada uno la reacción: ojos:. Esta reacción es la confirmación de que todos han leído cada mensaje diario.
Nuestra plantilla de mensaje diario:
- ¿Qué he hecho?
1. Método API / hola
2. Método API / cómo estás - ¿Que haré?
1. Método API / adiós - Preguntas:
1. Alice, ¿cuánto tiempo crees que te llevará tu tarea? - Problemas:
1. La implementación falla. ¡Ayuda!
Al discutir preguntas / problemas, no se olvide de la regla número 6: si la pregunta / problema no se resuelve en 15, lo contamos.
En su mayor parte, nuestro diario toma 15 minutos del tiempo de todos, teniendo en cuenta el tiempo de preparación para el rally.
¿Por qué es necesaria esta regla?
Esta regla es necesaria para gastar eficazmente el tiempo de trabajo del equipo. Y paciencia.
No importa qué tan optimista intente hacer nuestro mundo de Scrum, en la práctica, a diario, durante un discurso de un miembro del equipo, no todo el equipo restante lo escucha, sino 1-2 personas. El resto está esperando en la fila. Por lo general, para equipos de 10 personas, un día de este tipo dura de media hora a una hora, lo que significa que la mayoría del equipo simplemente se sienta y hace pasteles durante la mayor parte de esa hora. Traducir a formato de texto hace que el día a día sea rápido, conciso y, sobre todo, fijo.
8. Bono: En equipos internos, discutir en formato de texto todo lo relacionado con los productos y el proceso de su creación.
Mi experiencia personal es que la vida mejora cuando se habla por escrito:
- demandas
- diseño
- realización
- procesos de trabajo
- sugerencias y problemas
En la práctica, esto no siempre es posible al 100%.
Luego, cuando se discute en vivo algo de la lista anterior, se deben registrar los resultados de la discusión.
¿Por qué es necesario?
Para resolver los siguientes problemas en equipos internos:
- Siempre: los líderes piensan que “tienen el dedo en el pulso”, pero en realidad prácticamente no ven cómo está el equipo. Todo lo que se puede captar al comunicarse en chats grupales es prácticamente inaccesible en formato en vivo
- A menudo: las decisiones se toman en la sala de fumadores, que luego no se transmiten a todas las partes interesadas
- A veces: la discusión de temas laborales va acompañada de conversaciones de "nada" en grandes cantidades
¿Cómo configurar un mensajero?
Para que los canales estén convenientemente ordenados, utilizamos un sistema de prefijos.
Dado que nuestro equipo está involucrado en diferentes proyectos, creamos un prefijo para cada proyecto y lo usamos en los nombres de los canales.
Por ejemplo, tenemos 2 proyectos: GoldFixing y Aurrency. Para estos proyectos usamos los siguientes prefijos: gf para GoldFixing y aurm para Aurrency. Luego, todos los canales asociados con GoldFixing comenzarán con el prefijo gf_ y se verán como gf_somechannel. De manera similar con Aurrency: los canales se verán como aurm_somechannel.
Al mismo tiempo, también puede haber muchos canales dentro del proyecto. Para organizarlos, se nos ocurrió una categorización de canales por su propósito. Y para cada categoría, tienen su propio prefijo.
Los canales se pueden dividir en 4 categorías:
1. Abarrotes
Estos son canales que se dedican a los productos que se crean dentro del proyecto.
Prefijo: prdct_
Los canales de esta categoría discuten todos aquellos temas que de una forma u otra se relacionan con este o aquel producto.
Así, si en el marco del proyecto GoldFixing se crean dos productos - una plataforma y un back office, entonces para ellos creamos los siguientes canales:
- gf_prdct_platform
- gf_prdct_backoffice
2. Información
Los canales de esta categoría no están destinados a la comunicación, sino a la difusión de información.
Prefijo: info_
En los canales de esta categoría llegan todo tipo de notificaciones y mensajes con fines organizativos. Por ejemplo, las notificaciones del administrador de tareas vienen exactamente aquí.
Así, si usamos JIRA en el proyecto GoldFixing, entonces tendremos el canal gf_info_jira.
3. Equipo
Estos son canales dedicados a equipos en función de sus profesiones.
Prefijo: equipo_
Los canales de esta categoría discuten temas relacionados con una disciplina profesional en particular (frontend / backend / etc.) y no relacionados con otras disciplinas.
Por ejemplo, si hay varios desarrolladores frontend en el proyecto GoldFixing, entonces tendremos el canal gf_team_frontend.
Si las mismas personas participan en varios proyectos, puede omitir el prefijo del proyecto y simplemente nombrar el canal: team_frontend.
4. Temporal
Estos son los canales en los que desea discutir algo con lo que no desea cargar a personas no relacionadas.
Prefijo: tmp_
Por ejemplo, si en el proyecto GoldFixing es necesario discutir la compra de vasos con el logo del proyecto, entonces creamos un canal gf_tmp_brand-cups.
Si necesita discutir algo que no está vinculado a un proyecto específico, omitimos el prefijo del proyecto.
Configuración básica de canales de información
A pesar de que esta configuración se hizo para el equipo de TI, creo que los equipos que no son de TI pueden tomar algo prestado.
- gf_info_general - para todo lo relacionado con la parte organizativa: declaraciones, arreglos de acuerdos y procesos. Suele estar dirigido a todos y requiere una respuesta de todos.
- gf_info_daily - aquí todo el mundo da de baja sus mensajes diarios
- gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
- gf_info_jira — JIRA
- gf_info_confluence — Confluence
- gf_info_deploy — . :
— Instance — Repository —
— Branch —
— Pipeline — gitlab
— Job — gitlab
— Triggered by — Slack ,
— Commit — - gf_info_sentry — Sentry
- team_backend — backend
- team_dlt — DLT
- team_frontend — frontend
- team_qa — QA
Advanced JIRA
Si vierte notificaciones sobre todo lo que sucede en JIRA en un canal, el canal se convertirá en un desastre de mensajes.
Para hacer esto, ajustamos las notificaciones e hicimos no uno, sino varios canales para JIRA:
- gf_info_jira_comments - para notificaciones de comentarios en JIRA
- gf_info_jira_qa : para recibir notificaciones de control de calidad sobre la aparición de tareas listas para probar. Este canal solo tiene control de calidad y un administrador
- gf_info_jira_qa_verdict - para notificaciones sobre la transferencia de tickets del estado "TEST" a "DONE" o "REWORK"
Configuración avanzada de notificaciones de Sentry
Tenemos varias instancias de proyectos (stands) en cada proyecto:
- Soporte para desarrolladores: soporte para desarrolladores
- Banco de pruebas - soporte para probadores
- Soporte de lanzamiento: un soporte para ejecutar candidatos de lanzamiento
- Stand de producción - stand de producción
Para cada uno de ellos, creamos un canal centinela separado.
Y para que los desarrolladores de frontend no se muevan cuando se produce un error en el backend y viceversa, también dividen estos canales en grupos de frontend / backend.
Resulta:
- gf_info_sentry_back_dev
- gf_info_sentry_back_test
- gf_info_sentry_back_release
- gf_info_sentry_back_prod
- gf_info_sentry_front_dev
- gf_info_sentry_front_test
- gf_info_sentry_front_release
- gf_info_sentry_front_prod
Por lo tanto, los frentes no se mueven debido a errores en el backend y viceversa.
Para diferentes stands, es aceptable una urgencia diferente de la respuesta de los desarrolladores.
Debido al hecho de que la instancia de producción del proyecto está ubicada en un clúster y todas las demás instancias en otro, estamos pensando en cómo agrupar canales por clústeres y obtener:
- gf_info_sentry_back_dev-cluster
- gf_info_sentry_back_prod-cluster
- gf_info_sentry_front_dev-cluster
- gf_info_sentry_front_prod-cluster
Ejemplo de organización de canales
Preguntas a la audiencia
- ¿Qué reglas de comunicación agregaría a las que he enumerado?
- ¿Qué otras cosas útiles puedes personalizar / usar en Messenger a nivel de equipo?