Aujourd'hui nous continuons notre connaissance du livre " Team Geek: The Ideal IT Company " de Brian Fitzpatrick et Ben Collins-Sussman, dédié à la communication "au travail" sous toutes ses formes. La dernière fois, nous avons commencé par les communications intra-équipe et nous avons principalement parlé de la façon dont l'état d'esprit de chaque employé les affecte. Cette fois, nous devons regarder l'équipe plus largement - comme un groupe uni avec sa propre culture interne, qui est en quelque sorte formée et nécessaire pour quelque chose.
La culture d'équipe est un ensemble de connaissances, de valeurs et d'objectifs spécifiques à un groupe particulier de programmeurs. Cela inclut les méthodes de création de code de programme, le style de communication entre les personnes et les façons d'organiser le flux de travail - il existe de nombreux composants. Certains d'entre eux ne sont pas trop critiques, ils vont et viennent facilement (par exemple, la coutume de commander des pizzas et de jouer à des jeux de société le vendredi), d'autres forment la «colonne vertébrale» de la culture et peuvent survivre à des générations entières de programmeurs (par exemple, procédures pour les processus d'inspection du code, de test, de documentation, etc.
Dans sa forme originale, la culture est généralement définie par les fondateurs et l'équipe technique d'origine. Par la suite, il se développe et subit inévitablement des changements, mais pour les équipes fortes et éprouvées (Google, Apple, Microsoft, Oracle peuvent être cités en exemple) conserve le plus souvent son visage d'origine dans une certaine mesure - le lien avec les racines n'est pas complètement perdu.
Contrairement aux idées reçues, la culture d'équipe n'est pas entièrement entre les mains et la conscience du leader. S'il existe vraiment (de ce qui se passe s'il n'y a vraiment pas de culture, nous en reparlerons un peu plus tard), il est diffusé par presque tous les employés. Cela devient évident lorsque vous regardez comment une équipe de débutants s'intègre généralement. Le nouveau développeur se fait une idée de la manière dont il est accepté ici, de ce qui est important et de ce qui ne l'est pas grâce à l'interaction avec ses collègues: à quoi fait-il attention dans son code, comment et dans quel ton ils expliquent le besoin de corrections, comment sont les conflits. résolu.
Culture d'équipe autonome: une métaphore de la boulangerie
Pourquoi travailler sur la culture d'équipe?
Ainsi, la culture de l'équipe est une sorte de mélange diffus d'attitudes et d'accords différents qui permet aux gens qui travaillent ensemble de rester sur la même longueur d'onde. Une question naturelle se pose: cela vaut-il la peine de s'en inquiéter? L'influence mutuelle des employés les uns sur les autres dans le processus de travail se produit naturellement, de sorte que toute culture est susceptible de se former d'elle-même.
Le problème ici est que, comme pour tous les processus spontanés, une culture en évolution spontanée générera plus d'entropie et peut produire des résultats imprévisibles. En d'autres termes, tôt ou tard, il y aura des gens qui décideront de leurs propres mains de déterminer «comme il est d'usage ici». S'ils s'avèrent sains d'esprit et agissent dans le même sens, la fin sera heureuse. Mais le plus souvent, cela se transforme en la même bonne vieille guerre de bureau ou, pire encore, en poches de décomposition au sein de l'équipe.
Lâcher prise n'est donc pas le meilleur choix. Ci-dessus, nous avons parlé du fait que la culture ne peut pas être instillée de force, mais que vous pouvez aborder sa formation avec conscience. Si chaque participant non seulement se comporte conformément aux principes du dernier chapitre, mais essaie également de les amener au niveau de l'équipe, supprime les actions dangereuses pour la coopération et n'a pas peur de négocier des règles communes pour tout le monde, le risque de mauvaises surprises diminue.
Quelle devrait être la culture d'équipe?
Il est bien entendu impossible de répondre à cette question de manière non équivoque et exhaustive. Les cultures sont extrêmement diverses et l'éventail des variations saines et productives est large. Un travail bien organisé et confortable peut être à la fois dans une start-up chaotique, où tout le monde est au conseil, et dans une grande entreprise avec des processus clairs et gardant une distance. Il est inutile d'essayer d'établir une référence pour chacun des nombreux éléments.
Dans les termes les plus généraux, la culture devrait être:
- . . , , . , : .
- . , , , , . . , , – .
- . , , , : , , . , – , .
- . , , . , . , .
Les canaux de communication sont la composante de la culture la plus facile à contrôler, et les auteurs y accordent le plus d'attention. Cependant, avant d'entrer dans leurs détails, ils donnent quelques conseils sur d'autres éléments plus subtils.
Quand il s'agit de prendre des décisions, alors pour la plupart, les programmeurs préfèrent les modèles démocratiques. Cela est peut-être dû à leur désir notoire d'indépendance, ou peut-être au fait que la profession est intrinsèquement créative, mais le fait demeure: il est important que les développeurs aient une voix et la capacité de partager leurs propres pensées. Les dirigeants doivent en tenir compte lors de l'organisation des processus décisionnels. Il n'est pas nécessaire de résoudre tous les problèmes par un vote général, il suffit que les employés soient réellement écoutés et le système présuppose un consensus suffisant pour qu'ils se sentent propriétaires.
Quant au mode de communication, elle devrait se tourner vers la politesse accentuée plutôt que vers l'agressivité. Le problème avec les équipes qui utilisent un cri ou un ton assertif pour s'affirmer est qu'elles poussent et accablent les personnes d'un esprit plus calme. Une personne sujette aux conflits se sentira assez à l'aise à la fois dans un environnement agressif et parmi des personnes polies. Une personne calme et réservée (dont il y en a beaucoup parmi les programmeurs), au contraire, ne pourra pas s'ouvrir correctement dans une équipe agressive. En conséquence, en encourageant ou en adoptant simplement un mode de communication offensant, nous coupons automatiquement certains des employés potentiels forts. Cela n'est pas pratique.
Dans le même temps, il faut comprendre que la culture de la correction et du respect mutuel est plus fragile et vulnérable aux influences extérieures. Un débutant affirmé suffit à secouer l'harmonie. Par conséquent, il est très important de mettre fin à toute tentative d'aller à l'encontre du mode de communication accepté et d'empêcher les gens de remporter des victoires par un comportement destructeur. La meilleure façon de faire est de simplement refuser de communiquer sur un ton agressif.
Canaux de communication
Nous avons constaté que la fixation et la transmission d'informations jouent un rôle décisif dans la culture d'équipe. Dans les conditions modernes, de nombreux outils sont à notre disposition à cet effet; cette section fournit un aperçu des plus courants.
Une caractéristique commune des équipes qui réussissent est qu'elles utilisent activement divers canaux de communication pour s'assurer que chacun reste conscient à la fois de la direction générale du mouvement et de l'avancement actuel du travail. Dans le même temps, l'accent est mis sur les canaux qui, d'une part, rendent l'information accessible au public et, d'autre part, exploitent au mieux les possibilités de communication asynchrone.
En outre, les auteurs considèrent un certain nombre d'outils spécifiques grâce auxquels la communication a lieu dans les équipes techniques; clarifier leur objet et leurs règles d'utilisation.
Définition de la mission
A partir d'un tel titre, le lecteur-programmeur se croisera probablement, mais en fait, tout n'est pas si effrayant. Dans le travail technique, la mission est formulée au niveau des projets individuels et vise non pas à louer l'entreprise dans des expressions vaguement ornées, mais à indiquer clairement ce qui est fait et ce qui ne se fait pas. En d'autres termes, un énoncé de mission est une définition laconique de la direction du développement du produit et en limitant la portée.
Disons-le:
La mission de GWT est d'améliorer radicalement l'expérience utilisateur du World Wide Web en permettant aux développeurs d'exploiter les outils Java existants pour créer des applications AJAX pour n'importe quel navigateur moderne.
En tant que personnes activement impliquées dans des projets open source, Fitzpatrick et Sussman ont pu voir à partir de leur propre expérience combien de temps, d'énergie et de nerfs une telle mesure peut faire gagner à l'équipe à long terme. Lorsque de nouveaux membres se joignent constamment au travail, chacun avec ses propres ambitions, commentaires et idées brillantes, le «noyau» du groupe doit avoir une compréhension claire et uniforme de l'essence du projet. Sinon, le travail se déroulera soit selon le scénario de la fable sur le cygne, le cancer et le brochet, soit il se déclenchera constamment en raison des tentatives de clarification de ces questions en cours de route.
En conséquence, un énoncé de mission est utile de deux manières. Premièrement, s'il y a un désaccord entre les principales parties prenantes sur les objectifs et la portée du projet, celui-ci apparaîtra immédiatement et sera résolu sans délai. Deuxièmement, le résultat de la discussion sera un document avec les thèses principales, auquel il sera possible de renvoyer des nouveaux arrivants ennuyeux ou trop zélés.
L'énoncé de mission donne à l'équipe un pied dans toutes les décisions concernant le projet, mais il ne doit pas être considéré comme absolument inviolable. Parfois, il arrive (principalement dans les startups) que les objectifs ou les circonstances de travail changent radicalement. Dans les situations d'urgence, il est logique d'évaluer honnêtement si la mission initiale est toujours pertinente et de la modifier en conséquence.
Documentation du projet
Si la mission est conçue pour développer une réponse unique pour tous les participants au projet à la question «quoi», alors la documentation du projet implique un travail similaire sur la question «comment».
Le document de projet présente une esquisse plus détaillée du futur projet et de son rembourrage technique. En règle générale, il a un propriétaire, deux ou trois auteurs et un bon nombre de critiques contribuant à leurs commentaires. L'écriture de la documentation, quelle que soit la difficulté à supporter, doit précéder le travail sur le code - le moment où aucune ligne n'a été écrite est le mieux adapté pour écouter les critiques et ajuster les plans d'implémentation. Le document de projet fini est très pratique à utiliser lors de l'élaboration d'une feuille de route, de la mise en évidence des étapes de travail, etc.
La documentation de conception, de par sa nature, est beaucoup plus flexible que l'énoncé de mission; ce n'est pas un dogme, mais une substance vivante. Au cours du processus de développement, il est nécessaire de réviser certains détails, et idéalement, la documentation doit refléter tous ces changements en temps réel afin que l'équipe puisse se tenir au courant. En réalité, hélas, il est souvent édité après la sortie du produit.
Réunions
Beaucoup de gens penseront que ce serait bien de faire le signe de croix ici aussi - les réunions ont plutôt mauvaise réputation parmi les développeurs. Selon les auteurs, la raison est qu'ils sont mal organisés et sont souvent utilisés là où il serait plus raisonnable de se tourner vers un canal de communication asynchrone.
Un bon exemple de sélection infructueuse du format est la «réunion», qui se tient avec une certaine régularité (généralement une fois par semaine) et avec beaucoup de monde. Généralement, les annonces importantes y sont lues, les résultats généraux sont résumés, etc. En fait, tout le contenu des dépliants est très facile et productif à traduire dans une liste de diffusion électronique, sauf dans les cas où c'est précisément une large discussion collective qui est nécessaire.
En ce qui concerne les réunions, dont vous ne pouvez vraiment pas vous passer, les règles suivantes doivent être gardées à l'esprit lors de leur conduite:
- . – , , , . « » — . , - .
- , , . , . , , .
- . – .
- (, ). , – Google .
Listes de diffusion Le courrier électronique est un outil très utile pour documenter l'historique du projet en arrière-plan. Il est beaucoup plus facile d'en extraire des informations qu'à partir de messageries instantanées, où il y a beaucoup plus de trafic et beaucoup moins de réglementation. Par conséquent, il est conseillé d'envoyer toutes les informations importantes dans des listes de diffusion, peu importe où elles ont sonné auparavant: copies de plans et notes de réunions, résultats de discussions sur certains problèmes, documents de projet, analyse des erreurs. Ainsi, un entrepôt de données centralisé est formé, où à tout moment il sera possible de revenir afin non seulement de trouver certaines informations, mais aussi de retracer l'origine des décisions et le déroulement de la discussion. Bien entendu, l'archive doit être équipée d'une recherche indexée.
L'importance de la documentation et, par conséquent, des mailings est déterminée par la compacité de l'équipe dans l'espace. Si certains employés travaillent à distance ou se présentent au bureau de manière irrégulière, la pratique durable consistant à dupliquer les actualités des grands projets par courrier devient un besoin urgent. Sinon, la plupart des informations qui «sont dans l'air» (discussions dans les couloirs et près des tables, transmission orale de nouvelles informations à ceux qui n'étaient pas à la réunion) passeront par eux.
Si l'équipe est nombreuse et que les processus sont turbulents, les participants commenceront bientôt à se noyer dans un flot d'annonces hétérogènes. Dans cette situation, la documentation est divisée en différents mailings thématiques (développement, analyse du code du programme, support utilisateur, tests, etc.), qui incluent les employés intéressés. Cependant, il est préférable de commencer avec un seul flux - s'il y a un besoin de séparation, ils vous le communiqueront rapidement.
Messagers en ligne Les messagers
se situent quelque part entre la communication synchrone et asynchrone. Ils ne sont pas optimaux pour la documentation, mais ils sont indispensables pour résoudre rapidement les problèmes, en particulier dans les équipes distribuées. Du point de vue de la culture de commandement, deux aspects sont ici importants.
Premièrement, la ligne de démarcation entre les discussions privées et publiques. La grande majorité des messagers internes et commerciaux donnent à l'utilisateur la possibilité de choisir entre communiquer avec une personne spécifique ou un groupe de personnes, ce qui est très pratique. Cependant, selon Fitzpatrick et Sussman, il y a eu une tendance à l'isolement ces derniers temps - les discussions ont de plus en plus lieu en privé.
À certains égards, ce n'est pas mal - les problèmes privés ne «boucheront certainement pas» tous les employés. Mais d'un autre côté, les gens sont privés de la possibilité de suivre le cours de la discussion, d'insérer leurs commentaires et d'être immédiatement informés des changements. Les débutants perdent également beaucoup, car ils pourraient gagner beaucoup d'informations précieuses simplement en lisant silencieusement des discussions actives dans le chat général. Souvent, les discussions se déroulent en privé, non pas parce qu'elles sont trop niches, mais toutes à cause de la même peur de la vulnérabilité: vous ne voulez pas poser de questions ou faire des suggestions devant tout le monde - et si elles s'avèrent stupides? Les développeurs devraient se rattraper sur une telle motivation et essayer de ne pas cacher ce qui est plus sage de rester dans le domaine public.
Deuxièmement, vous devez vous rappeler que les messageries instantanées, malgré toutes les réactions instantanées, ne remplacent pas complètement la communication en direct. Ils n'ont pas d'intonations et d'expressions faciales qui pourraient adoucir ou clarifier certaines phrases. Cela augmente le risque de malentendus qui menacent les principes de modestie, de respect et de confiance, et cela doit être gardé à l'esprit.
Système de suivi des bogues
Cet outil n'est pas aussi courant que ceux mentionnés ci-dessus. Il peut être très bénéfique sous certaines conditions:
- Disponibilité d'une procédure de traitement et de tri des erreurs, qui garantit leur enregistrement et leur correction en temps opportun. Si le débogage du système ne reçoit pas suffisamment d'attention, les gens ne l'utiliseront pas, ou ils en abuseront de petites manières.
- . « » , .
- . – .
- . , , .
La communication dans le cadre du développement La
communication au sein de l'équipe technique a lieu non seulement autour, mais aussi directement au sein du code. Le canal principal ici est, bien sûr, les commentaires des développeurs .
Les auteurs abordent brièvement les règles de base du commentaire de code, qui sont probablement familières à tout le monde: expliquer non pas ce qui est fait, mais pourquoi cela se fait, essayer de commenter au niveau des fonctions et des méthodes, être laconique et ne pas se laisser emporter. loin avec les détails. Le reste du style de commentaire est une chose subjective, chaque équipe développe le sien en fonction des besoins et de l'ambiance générale. L'essentiel est que ce style général existe en principe; le fait même de l'uniformité dans ce cas est plus important que les caractéristiques spécifiques.
Un autre moyen de communication dans le code est l' attribution , c'est-à-dire la signature du développeur dans le fichier. La coutume de laisser votre nom sur un document remonte aux temps anciens; dans les anciens programmes, vous pouvez souvent voir de tels autographes:
Fitzpatrick et Sussman insistent sur le fait qu'aujourd'hui ces signatures doivent être considérées comme anachroniques. D'un point de vue psychologique, le désir d'indiquer la paternité, bien sûr, reste naturel et compréhensible: il s'agit d'une manifestation de fierté et d'un sens de responsabilité pour le travail accompli. Sur le plan pratique, cependant, cela pose plus de problèmes que d'avantages. Désormais, le développement, comme nous l'avons déjà établi dans la première partie de l'article, est devenu une activité d'équipe. En réalité, plusieurs personnes peuvent être impliquées dans un seul morceau de code à la fois, ce qui signifie que la résolution du problème de la paternité peut provoquer des controverses, du ressentiment et, en fin de compte, une perte de temps.
Dans l'environnement actuel, il est plus opportun de garder une trace de la paternité au niveau du projet, plutôt que directement dans le code. Lorsque vous avez besoin de savoir exactement qui contacter pour des questions sur une partie particulière du code, le système de contrôle de version viendra à la rescousse.
Maintenant que nous avons regardé le cœur de la «dimension humaine» dans une entreprise informatique de tous côtés, nous pouvons passer aux couches périphériques: des éléments étrangers qui entourent les équipes et les utilisateurs.