Get best of the week

Quelles erreurs font les gestionnaires sur un site distant

Bonjour, Habr! Je ne suis pas développeur, mais manager. Pendant un certain temps, on m'a appris à gérer les gens, puis j'ai plongé dans le monde sombre du développement, où tout va mal, comme on dit à l'université. Maintenant, je dirige la pratique de la gestion du cycle de vie du logiciel et je veux vous dire quelques choses qui peuvent être importantes pour les chefs d'équipe et les PM concernant le passage à un site distant. Parce que dans nos équipes, les gens commençaient déjà à plisser les yeux. Et puis je montrerai et raconterai notre pile d'automatisation pour les télécommandes, et comment nous publierons les versions des salles de chat sur le téléphone avec un seul bouton, plutôt que d'élever le VPN à un périmètre sécurisé, et cela accélère la coordination, et cela aide à coordonner au jour le jour.

Le premier conseil suffit pour amener votre peuple!



Je sais que cela semble très stupide, mais de nombreux gestionnaires, ne voyant pas les gens à proximité, commencent à compenser en quelque sorte leur désir de s'assurer qu'ils fonctionnent. Voici les chats:


Woodpecker dans sa forme pure.

S'il y a une tâche pour augmenter l'efficacité de l'équipe maintenant et à l'avenir, laissez les gens tranquilles. Et réglez les 15 minutes tous les jours le matin. J'ai déjà réussi à voir la synchronisation générale du projet une fois toutes les quatre heures, et le quotidien pendant deux heures, et les gestionnaires qui sont tombés dans la frustration, qui avaient l'habitude de négocier face à face avec quelqu'un.

Qu'est-il arrivé au développement à distance au CROC


Nous avons basculé très simplement car nous avons déjà une structure géo-distribuée de bureaux de développement. Ces dernières années, ils sont habitués au fait que la journée de travail d'un des développeurs peut commencer à 23 heures, heure de Moscou. En conséquence, il n'y a eu pratiquement aucun problème de gestion pour les équipes avec de tels participants, mais pour ceux qui travaillaient dans le même fuseau horaire, des difficultés pouvaient survenir. Par exemple, une de mes équipes avait besoin de nouveaux rendez-vous chez Zoom pour la synchronisation et a commencé à sélectionner l'heure optimale. Au début, ils l'ont fait le lundi et le mercredi, puis le mercredi et le vendredi, car certains développeurs ont choisi de travailler le week-end et de se détendre du lundi au mardi. Cela est dû en partie au fait qu'ils sont moins disponibles dans les salles de chat ces jours-ci.

La deuxième chose importante est que nous avions déjà des outils pour connecter les chats, les trackers, un réseau social d'entreprise et l'ensemble de la pile de devoop CI / CD, et tout cela a été partiellement re-lié afin que les données d'un système soient automatiquement transférées vers un autre. Par exemple, nous nous sommes mis d'accord sur quelque chose dans le chat, vous pouvez dire au bot de l'apporter à Jira. Et il va déraper. Si vous le faites vous-même, vous devez entrer, percer tous les champs et ainsi de suite, eh bien, et vous connecter en quelque sorte au périmètre protégé. Un bot est plus facile. Le plus difficile, c'est le système d'autorisation. Nous y avons réfléchi, l'avons raté et l'avons fait il y a plus d'un an.

Comment tout a commencé.Tout d'abord, tout le monde est passé à un site distant et s'y est habitué pendant une semaine. Quelqu'un a de mauvaises chaises et son dos lui fait mal, les enfants de quelqu'un se mordent les pieds à la maison, la femme de quelqu'un était heureuse que son mari passe plus de temps avec sa famille et demande toutes les cinq minutes d'ouvrir une boîte. Une semaine s'est installée les outils. Puis, soudain, les développeurs ont réalisé qu'ils étaient heureux d'être assis à la maison. Et vous ne devez aller nulle part, aller nulle part, mais lors des réunions, il est immédiatement clair qui était nécessaire et qui a été nommé pour le rituel. Eh bien, les réunions ont commencé à l'heure, car il n'y a aucune raison d'être en retard. Puis les managers ont commencé à souffrir, car la communication avec le client est devenue un enfer. Nous avons commencé à planifier des réunions régulières de trois heures dans le calendrier (trois à quatre jours d'affilée), juste pour passer en revue le contrat avec un avocat, sinon tout durerait des mois. Pendant que ça marche.

La prochaine étape- la question est que les développeurs sur un site distant ont besoin de motivation. Pas comme au bureau. Il est très important de ne pas pousser, il est très important de poser une tâche intéressante et de donner une image du résultat visé. Sinon, il y aura procrastination, et le chef lui-même la projettera. Sortir du lit pour faire quelque chose d'ennuyeux est tout simplement physiquement difficile. Les chefs de file du projet devraient avoir une latitude égale pour la prise de décision. Notre situation est que les savoirs traditionnels ne changent généralement pas, mais le pouvoir au sein du sprint appartient à l'équipe, pas au chef de projet.

Naturellement, en chemin, vous pouvez casser du bois de chauffage assez drôle.

Qu'est-ce qui pourrait mal se passer?


Eh bien, vous devez d'abord vous rappeler que, malgré l'urgence (et il y avait beaucoup de monde après être passé sur un site distant), il est préférable de suivre les processus. À l'un de nos clients, nous expédions une version de notre développeur à son développeur. Sinhro après une traction sur eux. Nous avons expédié la version, ils ont dû effectuer des tests d'intégration et une régression. Et gardez-le dans ma nourriture. Et le lendemain, ils écrivent et nous demandent de leur proposer cette version dans un environnement de test. Parce qu'ils l'ont immédiatement présenté sur la prod, puis se sont souvenus que ce serait bien de synchroniser notre environnement. Heureusement, la sortie n'a pas plop, mais, de mon point de vue, elle semble quelque peu dangereuse ou quelque chose.

Pour un autre client, nous avons restauré l'un des projets tiers après avoir transféré le travail vers un site distant. Tout y est beaucoup plus simple: les experts du client ont mis la base de données en même temps, pour une raison quelconque, mis du texte brut avec des mots de passe, également à l'extérieur. Certains jeunes kulhackers ont tout piraté, naturellement.

Vous connaissez probablement le résumé quotidien avec les vulnérabilités de Zoom et la fin de l'histoire avec une fuite d'enregistrements. Tous les cadres (souvent issus des tâches informatiques de l'entreprise) n'ont pas compris ce qu'est Zoom, comment cela fonctionne exactement et que certaines choses confidentielles ne valent pas la peine d'être mentionnées lors de l'enregistrement. Nous avons rédigé un mémo pour les clients sur la manière d'utiliser quel canal. Cela semble avoir aidé. Au moins, de nombreux ingénieurs industriels plus âgés ont soupiré un peu plus. Et ils ont cessé d'ajouter «mydomain.ru» aux conférences générales, sans préciser s'ils connaissent cet employé.

Un autre de nos clients a oublié qu'il restait des fleurs dans le bureau qui devaient être arrosées. Nous l'avons découvert accidentellement lors de l'analyse des menaces. Fleurs sauvées.

Les réunions avec le client étaient divisées en celles où les gens portent encore des cravates à la maison et celles où vous pouvez vous permettre de vous asseoir en pyjama. Lors d'une de nos réunions, le développeur principal est sorti de la salle de bain, juste dans la mousse. Personne ne s'y est opposé.



Ces spécialistes agiles qui ont l'habitude de parler et de coller des autocollants sur les murs ont connu un effondrement créatif, car il est désormais impossible de le faire. Dans de nombreux cas, Trello ou Miro ont résolu le problème. Tout le monde est devenu plus facile. J'aime regarder mes collègues apprendre à communiquer dans un nouvel environnement à partir de zéro, et leur socialité ne leur donne pas des bonus comme avant.

Une bonne approche consiste à enregistrer quelque part près les modes de chaque développeur. Nous le connaissons à cause de la géographie, mais des ajouts comme «de 16h00 à 19h00 uniquement par téléphone dans les cas urgents» aident beaucoup. C'est là que la demande de demande de fichier Dock et les résultats des contrôles fonctionnent très bien: vous pouvez même le faire depuis le lit, si vous le souhaitez. Sinon, vous devrez attendre le matin suivant de huit à neuf heures. Nous essayons de transmettre la même pile simple aux clients avec lesquels nous travaillons étroitement, car si nous sommes habitués au fait que le document passe de système en système, alors la pile atlasienne du client peut ne pas être disponible et il sera nécessaire d'envoyer des fichiers * .docx avec des rapports intermédiaires.

Dans un certain nombre d'équipes, il y avait un problème avec le fait que les réunions soient envoyées au calendrier sans regarder ce même calendrier. Trois invitations peuvent être faites par emplacement, et l'emplacement lui-même est déjà occupé. Cela est également résolu de manière simple et organisationnelle.

Voici nos développeurs disent:

Ils ont fait un bot pour la démo - plus pour celui à qui tout le monde est plus. Et bien avec les enfants assis.
— - . , . , , : 10 000 10 , , . , -, , . , , ! , , . : , , , - . . … , .
Il n'y a aucune différence avec le développement conventionnel sur un site distant. Eh bien, vous travaillez toujours avec des services. Il y a longtemps, il y a eu un cas où mon collègue a accidentellement cloué un serveur VPN par lequel il s'est connecté pour maintenir ce serveur VPN ... Avec une fenêtre de cinq minutes pour mettre à jour le système, la charge est soudainement tombée lorsque l'application s'est arrêtée et avant le lancement de la nouvelle version (à l'époque mises à jour semi-manuelles) ... Ou lorsque vous exécutez les commandes rm -rf / data, et que vous vous rendez compte ensuite que vous les avez productives, et ctrl-c plus rapide, plus rapide.
Chatops du fumeur:



Ils ont remis en liberté un collègue déjà libéré. Annulant son travail. Arrive.

Existe-t-il des exemples de pile?


Oui, les voici:

Lien de demande


Gitlab + timcity

Aide des robots

Gitlab + jira



gitlab + timcity

Schéma de montage

Exemple de pipeline de développement

Ceci est un exemple de chat de discussion technique



Les outils devops et CI / CD des équipes normales sont élaborés depuis longtemps. Du point de vue du contrôle des processus, il est important qu'à chaque étape, il soit nécessaire de réduire le nombre d'actions inconfortables, en ne laissant que des actions utiles. Par exemple, ci-dessus, vous voyez des bots qui rendent compte de l'état de la version - une telle poussée est beaucoup plus pratique que d'entrer et de regarder comment cela se passe. Mais la vraie valeur apparaît lorsque tout cela vous permet de créer un processus continu à partir de «discuté du problème dans le chat» pour «définir toutes les tâches avec des liens vers la discussion», «la tâche a été attachée et balayée à travers tous les systèmes» à la construction, plus toutes les mesures nécessaires ont été supprimées en cours de route comme des marques d'estime de soi. Pour les développeurs, ce projet était un défi, car généralement ils écrivent du code, plutôt que de dessiner des architectures, d'écrire des concepts, etc. Et si le développement est automatisé autant que possible,alors pour de nombreuses équipes l'automatisation de l'échange de documents ou de documents n'est pas très bien mise en œuvre.

Voici un exemple. La tâche est considérée comme terminée lorsque chaque ligne des TdR sera un lien de travail vers le tableau croisé.

Les étapes sont
:



, . - .

() «»:



. , . - .

- -:



( ) «» ( ). Jira . . «» , . — . . «».

Je suis manager, sur quoi dois-je me concentrer maintenant?





Une priorité importante n'est pas de partager rapidement, mais de communiquer normalement. Le monde a déjà changé et il y a maintenant deux menaces importantes pour les entreprises: l'épuisement professionnel (si vous vous engagez dans la gestion des pics et évincer les gens) et la question d'une restructuration complète des structures de gestion, lorsque les équipes comprennent qu'elles peuvent tout faire de manière autonome et avec un nouveau leader informel . Cela peut entraîner le fait qu'au moment de la fin de la crise, toute l'équipe, si difficile à trouver et à former, se lèvera et partira immédiatement pour son propre projet. Par conséquent, je le répète encore une fois - même si votre productivité a chuté, n'obtenez pas votre personnel. C'est dans votre propre intérêt.

S'il est intéressant de discuter séparément du processus purement de leadership, alors nous organisons un webinaire le 27 à 16h00, ici vous pouvez vous inscrire. Ce sera sur la façon dont vous pouvez construire le processus, diverses erreurs et cas de gestion, la séparation des responsabilités (en particulier avec la sécurité de l'information), sur le flux de documents entre développeurs, analystes, testeurs, un peu sur CI / CD. Eh bien, même s'il vous semble que vous savez déjà tout, vous pouvez le faire comme un vrai Jedi - inscrivez-vous à un webinaire, baissez le son et asseyez-vous pour faire votre travail!

More articles:


All Articles