Halloween est le moment de parler des peurs. Je travaille en tant que chef de produit dans une entreprise informatique, donc ce sera sur les cauchemars des développeurs. Mais pas ordinaire, mais ceux qui apparaissent en période de changement.
Lorsqu'une entreprise se développe, elle change son approche du développement, crée de nouveaux produits et étend les capacités des produits actuels, accepte des employés par dizaines, et ceux qui ont travaillé à l'ancienne peuvent avoir du mal à reconstruire. Nous nous réjouissons des changements, mais parfois, pourquoi se cacher, nous en avons peur. Je travaille en tant que chef de produit depuis un an et pendant ce temps, j'ai fait face à cinq peurs majeures de mon équipe. Aujourd'hui, je vais parler de ces craintes et de la manière dont nous avons réussi à les surmonter.
1. Peur de tout laisser tomber
Les tests sont un moyen sûr de publier un produit sans bogues. Mais parfois, il n'y a pas d'équipement pour vérifier le code.
Nous faisons
DCImanager , un panneau de gestion des serveurs et des centres de données, et il est souvent impossible de créer des conditions dans lesquelles le code fonctionnera dans un environnement virtuel. Par exemple, nous ajoutons la prise en charge du nouveau modèle de commutateur, de routeur ou de PDU au panneau de commande, mais il n'y a pas de tels équipements sur le banc de test.
Dans certains cas, les tests peuvent être négligés, mais pas les nôtres. L'erreur coûte cher. Vous n'initialisez pas une seule variable et dans la moitié des cas, le système d'exploitation cessera d'être installé. Vous vous trompez dans quelques lignes de code - et le centre de données «s'allongera». Comme vous le savez, personne ne veut être responsable du datacenter «déchu», donc cette peur vient en premier dans mon équipe (même si elle n'est pas liée aux transformations de l'entreprise).
Comment surmonter la peur de tout laisser tomber- Tous les développeurs d'équipe font une révision du code de chaque fonctionnalité.
- Nous conservons des listes de choses sans lesquelles la tâche ne peut pas être libérée.
- Après la version de développement, nous analysons que nous n'en avons pas tenu compte. Nous décrivons en détail ce qui a été fait et quel comportement a été observé afin qu'à tout moment vous puissiez reprendre la tâche et tout restaurer en mémoire.
- Mise à jour constante de la base de connaissances. Nous consacrons du temps à la documentation pour les développeurs, nous partageons nos connaissances à ce sujet. formation et stand-up.
- Et enfin et surtout. Nous testons les développements personnalisés pour les clients avec eux sur l'équipement fourni.
Une fois que nous avons ajouté le contrôle d'agrégation de ports pour les commutateurs existants. Si une erreur était commise, le fonctionnement de l'équipement réseau dans le centre de données serait complètement arrêté. Le client est arrivé à son centre de données à trois heures du matin et a contrôlé la situation afin que, dans ce cas, il puisse rapidement revenir à l'ancienne version et reprendre le fonctionnement de l'équipement. Nous pourrions perdre l'accès à distance et le centre de données serait paralysé.
2. Peur de se retrouver sans testeur
Nos développeurs écrivent des tests unitaires et des personnes individuelles sont engagées dans des tests manuels. Mais une fois qu'il y a eu un cas de force majeure, l'équipe s'est retrouvée sans testeur manuel. Nous n'avons pas pu publier de fonctionnalités, les développeurs ont donc dû se vérifier mutuellement.
Ce fut un coup porté à la fierté. Il se trouve que tous les programmeurs de mon équipe ont quitté les testeurs (manuels et automatiques). Revenez aux tests manuels pour eux - prenez du recul. Les gars avaient peur que s'ils pouvaient s'en sortir seuls, les testeurs ne leur seraient pas retournés. Mais la peur s'est avérée sans fondement, après quelques sprints, le testeur a pris sa place dans l'équipe, et de l'expérience nous avons appris beaucoup de choses utiles.
Quel est l'avantage des tests croisés- Ils se souviennent de la «jeunesse» et regardent à nouveau le développement du côté du testeur. Dans certains cas, des actions supplémentaires ont été ajoutées pour faciliter la vie du testeur. Par exemple, générer des statistiques pour vérification.
- Ils ont confirmé le fait connu depuis longtemps que le développeur ne peut pas tester son code, car il ferme les yeux sur certaines choses. Par conséquent, les gars ont testé le code de l'autre.
- Une fois de plus, nous étions convaincus que les testeurs sont une partie importante de l'équipe. Ils sont responsables de la qualité des fonctionnalités publiées dans la version.
3. Peur de rejoindre une autre équipe
DCImanager est sorti en 2013. Depuis six ans, la technologie a changé, il est temps de faire une nouvelle version, nous avons décidé de le faire à partir de zéro. Nous avons dessiné des prototypes, déterminé MVP et priorisé. Le développement de l'ancienne version était gelé, mais ils ne pouvaient pas démarrer la nouvelle - deux nouveaux produits étaient déjà en préparation pour la sortie, toutes les forces leur étaient consacrées, nous avons dû attendre un peu. Pendant l'accalmie, mes développeurs devaient devenir l'équipe de projet de
BILLmanager , notre autre produit pour l'automatisation d'hébergement.
Et puis une autre peur est apparue. Les développeurs d'ingénierie dans tous les sens du terme produit avaient peur de se lancer dans la facturation. Il leur semblait que ce n'était pas leur domaine, qu'il n'était pas intéressant de comprendre un tas de comptes. J'avais peur que cela démotive mes développeurs. Contrairement à nous, l'équipe de facturation s'est réjouie du déchargement.
Pendant quelques sprints, nous sommes allés travailler sur BILLmanager, et cette expérience a également été utile.
En bref sur le déroulement de la mise en œuvre- Pour minimiser le stress de passer à un autre produit, l'équipe est restée une équipe et ne dépendait pas des gars de BILLmanager.
- Les tâches ont été choisies selon le principe "vous devez le faire hier, mais vous n'avez pas assez de mains". Les productologues ont discuté des tâches, puis lors de la planification du prochain sprint, je les ai traduits dans l'équipe.
- Les développeurs de BILLmanager étaient nos mentors. Le réceptionniste a répondu à toutes les questions et le chef d'équipe a expliqué comment et comment cela devait fonctionner.
- Nous avons eu deux standups. Au début, nous sommes passés à la facturation, puis nous avons discuté des résultats au sein de notre équipe.
Quels avantages les développeurs ont-ils retirés de l'introduction à une autre équipe- Un autre produit est le code de quelqu'un d'autre que vous devez comprendre; ainsi que d'autres logiques de travail à comprendre. Grâce au mentorat et à la patience de l'homme d'exécution, nous avons réussi à nous habituer à la facturation, à développer de nouvelles compétences et à voir les améliorations assez rapidement.
- Bien sûr, nous avons espionné le fonctionnement de certaines choses au sein d'une autre équipe. Il peut sembler que tout est le même pour tout le monde, mais peu importe comment. Les différences résident dans les détails. En règle générale, ils ont pris le meilleur et le plus pratique pour eux-mêmes (par exemple, ils ont espionné et, après avoir légèrement changé pour eux-mêmes, ont commencé à utiliser une mêlée, adopté certains points dans le style de code, etc.).
4. Peur de devenir mentor / de rester sans chef d'équipe
L'entreprise a besoin d'autant de programmeurs solides que possible, donc quand un développeur développe des compétences solides et passe au niveau intermédiaire, la formation des débutants devient sa responsabilité. Mais le mentorat global incombe généralement au chef d'équipe. C'était donc dans notre équipe, jusqu'à ce que l'expérience d'un développeur leader soit requise de toute urgence dans un autre produit. Les programmeurs qui se sont retrouvés sans teamlade ont dû suivre la formation des débutants et les uns des autres.
Être mentor est effrayant. Vous devez être distrait de vos tâches, être à l'écoute d'une autre personne, expliquer ce que vous comprenez parfois au niveau de l'intuition et expliquer de manière à être compris. Si le Padawan n'a pas compris, c'est votre problème. S'il a fait une erreur et que vous ne l'avez pas remarqué, vous répondez.
Je ne donnerai pas de conseils sur la façon de devenir un bon mentor, c'est un sujet pour un article séparé. Mais nous avons réussi, et de cette expérience plutôt stressante, nous avons appris ce qui suit:
- Pour expliquer, il faut donner plus de contexte. Tout est beau dans la tête, et quand vous le dites, il se révèle arraché et incompréhensible.
- Il ne faut pas simplement regarder un code dans une revue, mais comprendre ce qu'une personne a essayé de résoudre avec ce code. Ensuite, il est plus facile de comprendre sa logique et de trouver des erreurs.
- Le partage des connaissances est utile: apprendre à formuler des pensées; mettez tout sur les étagères dans votre tête; pendant que vous expliquez, vous trouvez la meilleure solution au problème.
5. Peur de ne pas apprendre les nouvelles technologies
Une fois la pause terminée, il est temps de démarrer une nouvelle version du produit DCImanager. Il semblerait que voici le moment tant attendu. Maintenant, avec une équipe pleine de personnes ambitieuses, nous allons tout recommencer à zéro - sans regarder les vieux bogues et les dépendances étranges développées historiquement dans le code. Mais il y avait une place pour la peur.
Depuis plusieurs années, la technologie est allée très loin. Nous avons écrit l'ancienne version en C ++ 11 et en utilisant make, pour la nouvelle nous avons choisi C ++ 17, CMake, Conan et Docker. L'équipe doit apprendre tout cela et apprendre à postuler. La prochaine sortie de la zone de confort, le défi et la pensée «et si je ne peux pas et sera pire que les autres», «et s'il y a plus de problèmes qui m'attendent, je ne le comprendrai pas et me chassera.» Nous maîtrisons toujours les nouvelles technologies et la lutte contre cette peur est toujours en cours.
Comment apprendre plus rapidement les nouvelles technologies- N'hésitez pas à demander à des collègues plus âgés et expérimentés, n'ayez pas peur de paraître stupide.
- Documenter, afin d'accélérer le processus d'immersion des nouveaux arrivants et ne pas dire la même chose 10 mille fois. Maintenir une base de connaissances.
- D'accord, Google est toujours là pour vous aider. Si cela ne fonctionne pas, voir le point 1.
Pas des craintes, mais des défis
Je saisis les expériences comme une opportunité d'apprendre de nouvelles choses, de devenir meilleur, et j'essaie aussi de faire examiner leurs peurs par mon équipe. Je pense que l’humeur des gars dépend beaucoup de moi. Lorsque vous croyez en un produit et en développeurs, écoutez-les en stand-up et analysez les problèmes rétrospectivement, soutenez-les en difficulté et expliquez le besoin de changement, alors il est plus facile pour eux de surmonter leurs peurs.
Mais soyons honnêtes, en stock, nous avons encore quelques phobies invaincues. La peur des délais, par exemple, ou la peur de ne pas s'entendre avec les débutants. Jusqu'à présent, il semble que rien ne peut être fait à leur sujet - il suffit de mettre en place. Mais peut-être qu'avec le temps, notre point de vue changera.
Pourquoi as-tu peur?
PS Si vous voulez être le premier à voir la version de démonstration de DCImanager - envoyez des contacts à bizdev@ispsystem.com avec le sujet "Je veux voir le nouveau DCImanager". Quand il sera prêt, nous vous écrirons. Ou si vous avez besoin d'un produit pour la gestion de serveur, mais que le DCImanager actuel ne convient pas et qu'il n'y a pas de solution appropriée sur le marché, écrivez vos souhaits pour un tel logiciel, peut-être que nous inclurons quelque chose dans le plan de développement.