À qui appartient l'information - il possède le monde. Comment organiser la communication et la diffusion des informations sur le projet?

Une communication bien établie et une diffusion bien organisée des informations sur le projet sont les conditions les plus importantes pour un travail d'équipe bien coordonné. Je pense que dans toutes les équipes, qu'elles soient éloignées ou non, elles ont été confrontées à des problèmes comme «Pourquoi ne m'ont-ils pas dit», «Mais on s'est mis d'accord sur autre chose» ou «Merde, je n'ai pas vu». Malheureusement, de telles situations ne peuvent être complètement évitées. Mais vous pouvez réduire au minimum la probabilité de leur apparition. Dans cet article je vais vous parler des règles de communication et des paramètres de messagerie que nous avons résolu ces problèmes.

A qui profitera cet article?

L'article sera utile pour les dirigeants et les membres de petites équipes de projet de 5 à 10 à 15 personnes.

Quoi utiliser et pourquoi?

Nous utilisons personnellement Slack pour communiquer et partager des informations.



La plupart de ce qui est écrit ci-dessous, d'une manière ou d'une autre, peut être organisé en d'autres messagers.



Raisons pour lesquelles nous utilisons Slack:

1. Commodité dans l'organisation des discussions de groupe (canaux)
2. La présence de threads - la possibilité de créer des branches de dialogue
3. Différenciation entre les dialogues de travail et ceux qui ne fonctionnent pas. Travaillez dans Slack. Autre - dans télégramme / watsap / partout
4. Disponibilité des réactions
5. Disponibilité des rappels
6. La possibilité d'intégrer Slack avec de nombreux outils

S'il existe une alternative à Slack pour laquelle les 6 points ci-dessus seraient vrais, veuillez me le dire dans les commentaires. Et pour une telle alternative, dites-moi quelles fonctionnalités intéressantes il a et souvent utilisées dans votre équipe.

Quelles sont les règles de communication dans l'équipe et pourquoi?

1. Ne communiquez pas en PM

Nous laissons la communication en PM uniquement pour deux cas:

• Discuter de quelque chose qui exige la confidentialité.
• Memasiks / blagues et autres inondations.

Pour tout le reste, nous utilisons des canaux de communication communs.

Maintenant, je vais vous dire à quoi ça sert. Je vous dirai un peu plus tard comment organiser les canaux de communication communs de manière à ce qu'il n'y ait pas de désordre et de chaos.



Pourquoi cette règle est-elle nécessaire?



Cette règle est nécessaire pour:

1. Il était possible de détecter des situations où quelqu'un s'écartait du cours et commençait à faire quelque chose de mal.
2. Il était possible de détecter des situations où quelqu'un commençait à faire quelque chose de mal.
3. Il n'y a pas eu de situations où deux personnes se sont mises d'accord sur quelque chose, et quelqu'un d'autre en a souffert.
4. Les dirigeants pourraient surveiller la coordination du travail d'équipe.
5. Les gestionnaires pourraient suivre l'occurrence des conflits, des ressentiments et l'apparition d'autres négativité.

2. Identifiez les destinataires de l'appel

Tout message doit avoir un destinataire. Un ou plus.



Lorsque vous faites référence à quelqu'un, vous devez le taguer.



Lorsque vous vous adressez à plusieurs personnes, marquez tout le monde, pas tout le monde dans la chaîne.



Pourquoi cette règle est-elle nécessaire?



Cette règle est nécessaire pour:

1. Tous les participants au chat n'ont pas été distraits par les messages des discussions / fils de groupe, mais uniquement ceux qui ont été tagués.
2. La probabilité que le destinataire affiche une notification était maximale. Par exemple, dans Slack, les notifications sont parfois perdues.

3. Réagissez aux messages

Tout message envoyé par quelqu'un (pas automatiquement) ne doit pas être ignoré par les destinataires de ce message. Le destinataire, lorsqu'il reçoit un message, doit donner une réponse. S'il y a plusieurs destinataires, chacun doit réagir.



Afin de ne pas écrire les phrases «ok», «compris», etc., Slack a une fonction pratique - les réactions. Les membres de notre équipe mettent généralement la réaction: yeux:. Le leader utilise la réaction: oeil:.



Pourquoi cette règle est-elle nécessaire?



Cette règle est nécessaire pour que l'expéditeur sache que son message n'a pas été perdu.

4. Utilisez des fils

Slack a une fonctionnalité telle que les fils - la possibilité de créer un «fil de conversation» et d'y mener un dialogue, et non dans le flux de messages principal.



Cette fonctionnalité est bien adaptée pour discuter d'un seul problème.



Pourquoi cette règle est-elle nécessaire?



Cette règle est nécessaire pour ne pas gâcher le flux principal des messages, augmentant ainsi la structure des informations et la facilité de navigation à travers celle-ci.

5. Consignez les conversations qui ont eu lieu en dehors de Slack

Si un dialogue a eu lieu, par exemple, lors de l'appel, il est nécessaire d'introduire un protocole basé sur les résultats de l'appel - un ensemble de thèses qui reflètent les résultats de la conversation.



Pourquoi cette règle est-elle nécessaire?



Cette règle est nécessaire pour:

1. Assurez-vous une fois de plus que les participants au dialogue se sont bien compris
2. Nous n'avons pas oublié ce sur quoi nous nous sommes mis d'accord
3. Étaient conscients de ce qui se passait qui n'a pas accepté dans le dialogue, mais étaient intéressés par le sujet du dialogue.
4. Il était possible de se référer aux résultats de la conversation
5. ... et les mêmes arguments du premier paragraphe sur les canaux de communication communs

Les protocoles doivent avoir des destinataires et recevoir des réponses!



Tout le monde ne doit pas être mis comme destinataire, mais ceux que le sujet de ce dialogue concerne.

6. Lancer un appel / une réunion si le problème n'est pas résolu après 15 minutes de correspondance active

Tout est simple ici: si vous voyez que vous devez écrire beaucoup de texte, si un désordre commence dans le chat, vous devez lancer un appel et discuter de tout avec une voix.



Et à la suite de l'appel - envoyez le protocole à tout le monde.

7. Mener des réunions quotidiennes par écrit

Une réunion quotidienne est une réunion de groupe dans laquelle chaque membre de l'équipe doit répondre à plusieurs questions brûlantes et discuter des questions / problèmes actuels afin de synchroniser l'équipe. Exemple d'un ensemble de questions pour les réunions quotidiennes:

• Qu'est-ce que vous avez fait hier?
• Que vais-je faire aujourd'hui?
• Quels problèmes ai-je sur mon chemin?

Nous tenons des réunions quotidiennes de 11h30 à 11h35 dans un groupe de discussion dédié. Le manager écrit pour la dernière fois - à 11h36. Quiconque s'est désabonné après qu'il est considéré en retard. Le travail éducatif doit être réalisé avec les retardataires. Chacun doit sous le message de chacun apposer la réaction: yeux:. Cette réaction confirme que tout le monde a lu chaque message quotidien.



Notre modèle de message quotidien:

• Ce que j'ai fait?
  
  1. Méthode API / bonjour
  
  2. Méthode API / howareyou
• Que vais-je faire?
  
  1. Méthode API / bye
• Questions:
  
  1. Alice, combien de temps pensez-vous que votre tâche vous prendra?
• Problèmes:
  
  1. Le déploiement échoue. Aidez-moi!

Lorsque vous discutez des questions / problèmes, n'oubliez pas la règle numéro 6 - si la question / le problème n'est pas résolu en 15, nous le mettons sur le compte.



Pour la plupart, notre quotidien prend 15 minutes du temps de chacun, en tenant compte du temps de préparation du rallye.



Pourquoi cette règle est-elle nécessaire?

Cette règle est nécessaire pour passer efficacement le temps de travail de l'équipe. Et la patience.



Peu importe à quel point notre monde de Scrum tente de rendre rose, dans la pratique, au quotidien, lors d'un discours d'un membre de l'équipe, non pas toute l'équipe restante l'écoute, mais 1-2 personnes. Les autres n'attendent que leur tour. En règle générale, pour des équipes de 10 personnes, un tel quotidien dure d'une demi-heure à une heure, ce qui signifie que la plupart des membres de l'équipe s'assoient et gâteaux pendant la majeure partie de cette heure. La traduction au format texte rend le quotidien rapide, concis et, surtout, fixe.

8. Bonus: Dans les équipes internes, discutez au format texte de tout ce qui concerne les produits et le processus de leur création

Mon expérience personnelle est que la vie s'améliore lorsque vous discutez par écrit:

• demandes
• conception
• la concrétisation
• processus de travail
• suggestions et problèmes

En pratique, ce n'est pas toujours possible à 100%.



Ensuite, lorsque quelque chose de la liste ci-dessus est discuté en direct, les résultats de la discussion doivent être enregistrés.



Pourquoi est-ce nécessaire?



Afin de résoudre les problèmes suivants dans les équipes internes:

1. Toujours: les managers pensent avoir le pouls, mais en réalité ils ne voient pratiquement pas comment l'équipe va. Tout ce qui peut être capturé lors de la communication dans les discussions de groupe est pratiquement inaccessible en format live
2. Souvent: les décisions sont prises dans le fumoir, qui ne sont alors pas diffusées à toutes les parties intéressées
3. Parfois: la discussion des problèmes de travail s'accompagne de conversations sur «rien» en grand nombre

Comment configurer un messager?

Pour que les chaînes soient commandées de manière pratique, nous utilisons un système de préfixe.



Comme notre équipe est engagée dans différents projets, nous proposons un préfixe pour chaque projet et l'utilisons dans les noms de canaux.



Par exemple, nous avons 2 projets - GoldFixing et Aurrency. Pour ces projets, nous utilisons les préfixes suivants: gf pour GoldFixing et aurm pour Aurrency. Ensuite, tous les canaux associés à GoldFixing commenceront par le préfixe gf_ et ressembleront à gf_somechannel. De même avec Aurrency - les canaux ressembleront à aurm_somechannel.



Dans le même temps, il peut également y avoir de nombreux canaux dans le projet. Pour les organiser, nous avons élaboré une catégorisation des chaînes en fonction de leur finalité. Et pour chaque catégorie, ils ont leur propre préfixe.



Les canaux peuvent être divisés en 4 catégories:

1. Épicerie

Ce sont des canaux dédiés aux produits créés dans le cadre du projet.



Préfixe: prdct_



Les canaux de cette catégorie discutent de tous les problèmes qui d'une manière ou d'une autre se rapportent à tel ou tel produit.



Ainsi, si dans le cadre du projet GoldFixing, deux produits sont créés - une plateforme et un back office, alors nous créons pour eux les canaux suivants:

• gf_prdct_platform
• gf_prdct_backoffice

2. Informations

Les canaux de cette catégorie ne sont pas destinés à la communication, mais à la diffusion d'informations.



Préfixe: info_



Toutes sortes de notifications et de messages à des fins d'organisation arrivent sur les canaux de cette catégorie. Par exemple, les notifications du gestionnaire de tâches viennent exactement ici.



Ainsi, si nous utilisons JIRA dans le projet GoldFixing, alors nous aurons le canal gf_info_jira.

3. Équipe

Ce sont des canaux dédiés aux équipes en fonction de leurs métiers.



Préfixe: team_



Les canaux de cette catégorie traitent de problèmes liés à une discipline professionnelle particulière (frontend / backend / etc) et non liés à d'autres disciplines.



Par exemple, s'il y a plusieurs développeurs frontend dans le projet GoldFixing, alors nous aurons le canal gf_team_frontend.



Si les mêmes personnes sont engagées dans plusieurs projets, vous pouvez omettre le préfixe du projet et simplement nommer le canal - team_frontend.

4. Temporaire

Ce sont les canaux dans lesquels vous souhaitez discuter de quelque chose avec lequel vous ne voulez pas charger des personnes non liées.



Préfixe: tmp_



Par exemple, si dans le projet GoldFixing il est nécessaire de discuter de l'achat de tasses avec le logo du projet, alors on crée un canal gf_tmp_brand-cups.



Si vous avez besoin de discuter de quelque chose qui n'est pas lié à un projet spécifique, nous omettons le préfixe du projet.

Configuration de base des canaux d'information

Malgré le fait que cette configuration ait été faite pour l'équipe informatique, je pense que quelque chose peut être emprunté par des équipes non informatiques.

1. gf_info_general - pour tout ce qui concerne la partie organisationnelle: déclarations, fixation des accords et processus. Habituellement adressé à tout le monde et nécessite une réponse de chacun.
2. gf_info_daily - ici tout le monde désabonne ses messages quotidiens
3. gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
4. gf_info_jira — JIRA
5. gf_info_confluence — Confluence
6. gf_info_deploy — . :
   
   — Instance — Repository —
   
   — Branch —
   
   — Pipeline — gitlab
   
   — Job — gitlab
   
   — Triggered by — Slack ,
   
   — Commit —
7. gf_info_sentry — Sentry
8. team_backend — backend
9. team_dlt — DLT
10. team_frontend — frontend
11. team_qa — QA

Advanced JIRA

Si vous versez des notifications sur tout ce qui se passe dans JIRA dans un seul canal, le canal se transformera en un désordre de messages.



Pour ce faire, nous avons affiné les notifications et créé non pas un, mais plusieurs canaux pour JIRA:

1. gf_info_jira_comments - pour les notifications de commentaires dans JIRA
2. gf_info_jira_qa - pour les notifications de contrôle qualité sur l'apparence des tâches prêtes à être testées. Ce canal n'a qu'un contrôle qualité et un gestionnaire
3. gf_info_jira_qa_verdict - pour les notifications concernant le transfert des billets du statut «TEST» à «DONE» ou «REWORK»

Configuration avancée des notifications de Sentry

Nous avons plusieurs instances de projet (stands) sur chaque projet:

• Dev Stand - Stand pour les développeurs
• Banc d'essai - banc pour testeurs
• Release stand - un stand pour courir les candidats à la libération
• Stand de production - stand de production

Nous avons créé un canal de sentinelle distinct pour chacun d'eux.



Et pour que les développeurs frontend ne tremblent pas lorsqu'une erreur se produit sur le backend, et vice versa, ils divisent également ces canaux en groupes frontend / backend.



Il s'avère:

1. gf_info_sentry_back_dev
2. gf_info_sentry_back_test
3. gf_info_sentry_back_release
4. gf_info_sentry_back_prod
5. gf_info_sentry_front_dev
6. gf_info_sentry_front_test
7. gf_info_sentry_front_release
8. gf_info_sentry_front_prod

Ainsi, les fronts ne tremblent pas en raison d'erreurs dans le backend, et vice versa.



Pour différents stands, une urgence différente de la réponse des développeurs est acceptable.



Étant donné que l'instance de production du projet est située sur un cluster, et toutes les autres instances sur un autre, nous réfléchissons à la manière de regrouper les canaux par clusters et d'obtenir:

1. gf_info_sentry_back_dev-cluster
2. gf_info_sentry_back_prod-cluster
3. gf_info_sentry_front_dev-cluster
4. gf_info_sentry_front_prod-cluster

Exemple d'organisation de canal

Questions au public

1. Quelles règles de communication ajouteriez-vous à celles que j'ai répertoriées?
2. Quelles autres choses utiles pouvez-vous configurer / utiliser dans le messager au niveau de toute l'équipe?