La réunion s'est tenue dans le cadre de la série «L'ingénieur entre dans un bar», où des ingénieurs de différentes sociétés informatiques abordent des sujets professionnels non liés à l'ingénierie. Une série d'événements a été organisée par des ingénieurs de la société Miro , avec le soutien du bureau Dolgushev et Storozhilov DevRel .
Le deuxième meetup de la série aura lieu le 20 août. Le sujet est la toxicité dans les équipes, les entreprises et l'industrie. Les intervenants sont des ingénieurs et des responsables techniques de Miro, SEMrush, Parma TG, Xsolla. L'inscription est déjà ouverte .
Table des matières:
- Les spécificités de l'entreprise et le système actuel de développement professionnel des ingénieurs
- Défis des systèmes de développement actuels
- Comment mettre en place une culture de développement au départ d'une nouvelle équipe
- Question chaude sur l'argent
- Comment soutenez-vous pour une entreprise que les employés ont besoin d'un pourcentage de leur temps pour l'éducation et le développement?
- Enquête sur les outils de développement professionnel
Les spécificités de l'entreprise et le système actuel de développement professionnel des ingénieurs
Artyom Susekov, responsable de l'ingénierie logicielle produit, Miro. Nous créons un produit pour la collaboration en ligne d'équipes, une plateforme de tableau blanc collaboratif en ligne. L'entreprise emploie 400 personnes, dont un peu moins de la moitié sont des ingénieurs. Bureaux de développement de produits à Perm et Amsterdam. Les équipes sont transverses: ingénieurs, chefs de produits, designers et, si nécessaire, marketeurs. Ils utilisent Scrum, certains utilisent Kanban. Pour la planification - OKR au niveau de la campagne et au niveau de l'équipe individuelle.
Nous avons des notes, les attentes de chacun sont formulées sous forme d'exemples spécifiques de comportement (modèles de comportement). Ceci est fait pour ne pas s'attarder uniquement sur les attentes formelles («faire autant de tâches, obtenir tel ou tel certificat»). Il est plus important que les connaissances acquises soient appliquées au travail quotidien, c'est précisément ce que montrent les exemples spécifiques qui sont décrits pour chacun des grades.
Niveaux standard: Junior, Moyen, Senior, il y a plusieurs étapes dans chaque année. Après Senior, il y a des opportunités de devenir un spécialiste technique ou de devenir chef d'équipe puis directeur de direction.
Il y a un examen du rendement, que nous menons deux fois par an. Pendant ce temps, vous recevez des commentaires de vos coéquipiers, les chefs d'équipe reçoivent des commentaires de ceux qui sont des subordonnés directs pour eux. De plus, l'employé rédige une auto-évaluation, c'est-à-dire qu'il évalue son travail de manière indépendante.
Les résultats sont résumés, après quoi la Conversation de Carrière est menée: ce qui s'est bien passé, ce qui s'est bien passé, ce qui devrait être souligné à l'avenir, avec quoi travailler. Ensuite, le manager aide à formuler un plan de développement pour les six prochains mois ou un trimestre.
Career onversation ( , , ), : , , .Alexander Borisov, responsable du centre de compétence technologique Innopolis, X5 Retail Group. Probablement, la plupart de tout le monde est familier avec X5. Nous possédons les chaînes Perekrestok, Pyaterochka et Karusel. S'il y a trois ans, nous étions une entreprise qui vend des tomates, et maintenant nous nous efforçons de devenir une entreprise informatique qui vend des tomates.
La plupart des bénéfices proviennent de nos services informatiques. Comment fonctionne Pyaterochka et quels prix il donne, peut-être en raison d'une logistique bien construite et d'un système de gestion pour ce grand processus. Nous avons plus de deux mille informaticiens dans l'entreprise, rien qu'à Innopolis, il y a près de 150 personnes.
Au cours de l'année écoulée, tout cela a commencé à passer d'un format de service à un format d'équipe de produit. Nous avons divisé les services et produits en microservices et sous-produits, dont une équipe peut être responsable. Nous avons maintenant des Product Owners pour chaque produit, des équipes interfonctionnelles, dont chacune a des développeurs, des testeurs, des analystes et une partie des fonctions dans lesquelles les gens peuvent se chevaucher.
Naturellement, nous avons des réunions individuelles, des OKR, des commentaires 360. La fonction de propriétaire du pool de ressources est intéressante. Ce sont les personnes responsables du pool Java, JS, Python, des tests, des analyses, etc. Chaque ingénieur de l'entreprise a un chef d'entreprise (Product Owner) qui comprend combien une personne investit dans un produit et combien de profit son travail rapporte, et il y a une personne qui est responsable du développement technique dans sa compétence spécifique.
Nous avons refusé d'officialiser la transition entre les grades, comme «pour passer du Junior plus au Moyen moins, il faut faire ceci et cela». Nous craignons que si nous donnons des critères clairs pour la transition, les gens commenceront à aborder cela de manière trop formelle. Mais la formalité est nuisible ici, car dans chaque équipe, tout peut être très individuel: une seule et même personne peut prendre plus de responsabilités et à cause de cela se développer, ou pomper dans un segment étroit de technologies qui nous sont spécifiques, et de ce fait devenir plus précieux pour l'entreprise.
Pour les postes supérieurs, la diffusion des connaissances est une condition préalable importante à la croissance. Vous n'êtes pas un Senior en vase clos, vous partagez votre expérience avec l'équipe et tirez le reste avec vous.
Sergey Averyanov, directeur technique, Funbox. Nous développons des logiciels pour les trois grands opérateurs depuis plus de 10 ans. À l'heure actuelle, nous avons environ deux cents développeurs de profils variés et un assez grand nombre de spécialistes techniques en support technique.
D'une part, nous n'avons pas un seul produit dans lequel toute l'équipe est engagée, et d'autre part, il n'y a pas de gros flux de projets et de tâches comme en externalisation. C'est là que se développe notre développement professionnel spécifique des ingénieurs. Nous avons délibérément abandonné les systèmes de notation formels: c'est peut-être ce que souhaiteraient la direction et les employés eux-mêmes, mais c'est un système extrêmement rigide qui tente de donner à tout le monde le même style, ce qui n'est pas toujours possible dans la pratique. Au lieu de cela, nous utilisons des choses assez standard: une évaluation périodique des progrès de l'employé et des conversations en tête-à-tête. Nous avons la possibilité d'évaluer objectivement la contribution de chaque Task Tracker. Tout cela pris ensemble nous permet de comprendre le niveau de chacun des ingénieurs.
D'autre part, l'un de nos principaux objectifs est de faire comprendre à chacun comment et où il peut se développer. Nous essayons de prendre en compte le fait que toutes les personnes sont différentes: quelqu'un est intéressé à travailler comme experts techniques, à communiquer au minimum avec les gens et à ne pas se plonger dans les choses administratives; quelqu'un veut communiquer, travailler avec les gens, participer au développement de ses collègues. Tout cela est normal, toutes les options de développement sont possibles.
Nous essayons de créer un système qui nous permette d'élever le niveau des ingénieurs et de leur donner des conseils clairs sur ce que l'entreprise attend d'eux et où ils peuvent aller ensuite. Nous accordons également une grande attention à la croissance interne. Moi et toute l'équipe pensons que le meilleur spécialiste est celui que nous avons élevé au sein de l'équipe. Par conséquent, nous investissons activement dans le développement interne, dans des rencontres, des conférences internes et externes. C'est également l'un des principaux objectifs - le développement complet et de haute qualité de tous nos ingénieurs.
Un département de développement abstrait ne doit pas être impliqué dans le développement des employés. C'est l'une des responsabilités du supérieur hiérarchique.
Cette approche est un plus pour nous et les employés eux-mêmes. D'une part, nous avons une croissance organique constante parmi le personnel. D'autre part, nous pouvons faire des juniors seniors et des chefs d'équipe d'anciens juniors, et l'employé lui-même voit que son supérieur immédiat est celui qui était junior sur ce projet il y a quatre ans, ce qui signifie qu'avant de collaborer maintenant les mêmes opportunités et étapes compréhensibles pour croissance.
Mikhail Mazein, responsable de l'ingénierie, ManyChat.Nous développons une plateforme de marketing SaaS qui vous permet d'organiser les communications entre les entreprises et leurs clients. L'entreprise est en pleine croissance: il y a trois ans, l'équipe comptait 15 personnes, maintenant nous sommes plus de 120. Dans les premières étapes, nous avons travaillé avec des équipes fonctionnelles classiques: backend, frontend, tests, équipes de conception. Chaque équipe avait un chef d'équipe qui était responsable de la planification du sprint et de la décomposition des tâches.
Dans le processus de croissance, nous avons réalisé que cela nous empêchait d'avancer à la vitesse souhaitée et avons reformaté le travail en équipes interfonctionnelles. Nous avons maintenant neuf équipes interfonctionnelles de ce type, il n'y a pas de chef d'équipe, car les équipes se sont révélées auto-organisées et peuvent être responsables de leur façon de travailler.
Pour synchroniser les choses fonctionnelles, nous développons des approches communes afin que le développement ne se transforme pas en anarchie. Cela est nécessaire, par exemple, lorsque les développeurs backend sont répartis entre différentes équipes, mais travaillent avec un projet, avec une base de code, et y livrent du code. Nous organisons des communautés fonctionnelles pour résoudre ces problèmes. Au fil du temps, des leaders informels apparaissent dans les communautés qui dirigent les processus et les communications. Le résultat est une structure plate qui ne limite pas le rôle du développeur à celui d'un ingénieur qui n'écrit que du code, mais vous permet de faire diverses choses utiles à l'entreprise et en même temps intéressantes pour la personne elle-même.
Depuis que nous avons abandonné le rôle de chef d'équipe, nous avions besoin d'un processus qui nous permette de construire de manière claire et transparente des pistes de croissance pour les ingénieurs. Pour cela, nous utilisons un système de mentorat: chaque collaborateur dispose d'un mentor qui est responsable de sa croissance et de son développement au sein de l'entreprise.
Vous ne pouvez pas simplement vous approcher d'une personne au hasard et lui dire: «Laissez-vous être un mentor». Premièrement, plusieurs facteurs doivent être réunis: le désir de la personne elle-même; haut niveau de confiance dans l'équipe envers la personne; confiance de l'entreprise elle-même et de la direction. L'une des tâches d'un mentor est d'élever de nouveaux mentors. Il s'avère que c'est en herbe, de mentor à mentor.
On distingue trois principaux vecteurs de développement:
- La première grande piste est un travail plus approfondi au sein de l'équipe produit pour le développement de produits, avec une compréhension plus approfondie des valeurs commerciales et des mesures.
- – , , .
- – , .
Nous avons également essayé de créer un système de notation: nous ne pouvons pas encore décrire formellement toutes les notes, donc le système est construit au niveau de la contribution d'une personne, au niveau de l'équipe, au niveau de toute l'entreprise. Nous avons décrit les attentes à chaque niveau, le domaine de responsabilité ou le domaine d'influence que nous attendons d'une personne, avec des exemples clairs. Le mentor, quant à lui, peut dire à une personne quelles compétences doivent être renforcées pour arriver au point souhaité.
Anton Grishin, responsable du développement, MadRobots. À première vue, notre entreprise est un commerce électronique qui traite des gadgets, mais en général, nous sommes engagés dans la distribution en Russie et le développement de marques de produits sympas.
Notre équipe s'est réunie relativement récemment, nous n'avons donc toujours pas le mal de tête associé au développement des ingénieurs au sein de l'entreprise. Avant Madrobots, j'ai travaillé dans l'externalisation pendant 6 ans, dont trois étaient directement en charge de la production à l'agence, et j'aimerais vous en dire plus sur cette expérience.
Dans l'externalisation, notre douleur était un flux important de projets et de rotation du personnel, dans l'externalisation c'est toujours le cas. Nous avons décidé que nous devions surmonter cela d'une manière ou d'une autre et avons commencé à investir dans le développement des employés.
Oui, nous avions un système de notation, une fois tous les six mois, une personne recevait les commentaires d'un responsable technique, construisant son propre chemin avec lui pour les six prochains mois.
, . , . , , , .
Par la suite, nous avons eu une autre douleur. Dans le flot de projets, souvent nombreux, les gens se sont désintéressés du développement personnel. Ce n'était pas parce qu'ils n'avaient pas assez de temps, mais parce qu'ils étaient fatigués du nombre de tâches à accomplir. Nous avons introduit la pratique des rencontres individuelles, une fois par mois, qui visaient à parler avec une personne et à lui rappeler que vous avez un plan de développement et qu'il devrait vraiment être respecté. Si vous avez besoin de temps pour cela et que vous devriez être libéré de la routine ou de la constante hors site, discutons-en, car votre point de contrôle approche et vous devez faire quelque chose à ce sujet. Cela a aidé. En règle générale, cela était fait par les PM des équipes, car qui, sinon eux, savait mieux planifier les ressources pour l'avenir.
Défis des systèmes de développement actuels
Artem Susekov, Miro. Il est difficile d'équilibrer tout de suite le système de notation, nous procédons donc à des itérations. Par exemple, la première version de la piste du chef d'équipe s'est avérée surchargée: des attentes trop élevées, un super soldat universel, ce qui n'est guère possible dans la vie.
Nous essayons actuellement de simplifier le seuil d'accès au rôle de chef d'équipe afin de faciliter le passage d'une branche purement d'ingénierie à une branche de gestionnaire. Je ne veux pas surestimer la barre, nous avons besoin d’une opportunité pour entrer en douceur dans ce nouveau domaine d’activité.
Une autre difficulté est l'approche trop formelle du processus. Par exemple, "J'ai fait 8 points sur 10 dans le plan, ce qui signifie que je réponds aux attentes et que je peux passer au niveau suivant." Nous ne voulons pas transformer tout cela en une liste de contrôle qu'il vous suffit de fermer pour passer au niveau suivant, comme dans un jeu.
Je voudrais que les gens puissent réfléchir aux perspectives sur la base du plan, réfléchir de manière indépendante aux domaines qui les intéressent, c'est-à-dire pour qu'ils travaillent avec cela comme une stratégie, et non comme une liste de tâches formelles.
Alexander Borisov, X5 Retail Group. Les gens ne comprennent souvent pas exactement comment ils peuvent évoluer dans une entreprise, car il n'y a pas d'algorithmes clairs. En même temps, les personnes qui peuvent vraiment déjà être promues trouvent des choses dans lesquelles elles peuvent et devraient grandir, ces choses qui peuvent être prises sur elles-mêmes et améliorées. Mais il se trouve qu'il est nécessaire de «simplement grandir». Mais il est probablement impossible de grandir dans l'entreprise comme ça, parce que vous voulez grandir.
Vous ne grandissez que lorsque vous assumez plus de responsabilités, prenez de nouveaux projets.
Sergey Averyanov, Funbox . Depuis que nous travaillons depuis de nombreuses années, nous avons eu de nombreux problèmes et défis. L'une des premières est de comprendre avec qui nous voulons travailler, avec qui nous voulons développer. En conséquence, nous sommes arrivés à la conclusion que nous voulons travailler avec des gens qui savent comment bien faire quelque chose, et peu importe sur quoi. Nous prenons volontiers des spécialistes de n'importe quelle pile qui sont prêts à utiliser ce que nous utilisons. Cela s'est avéré être une pratique assez réussie: il est toujours agréable et pratique de développer des personnes qui ont déjà des compétences dans un domaine connexe. Le manque de connaissances qu'ils ont n'est pas un défaut fatal, mais une nouvelle motivation pour une personne, l'étude d'un nouveau champ d'activité.
Le deuxième défi est de comprendre comment les ingénieurs de l'entreprise peuvent évoluer. Pour le développement, il faut créer des conditions de travail confortables: un bureau normal, des procédures et des règles de travail claires, simples mais strictes, le respect du Code du travail, une aversion pour le surmenage. Tout cela donne à une personne l'assurance qu'elle peut augmenter son niveau sans tracas, sans travail précipité. Ils lui montreront, lui diront, l'aideront.
Vous pouvez crier sur les pommes de terre autant que vous le souhaitez: «Pommes de terre, grandissez! Les tomates, allez! »- mais elles ne pousseront pas à partir de là. Ils ont besoin d'un bon sol et d'un bon arrosage.
Le dernier défi est que tout le monde ne veut pas grandir là où nous le voulons. Il arrive qu'un spécialiste chevronné ne veuille en aucun cas faire face à la charge administrative et travailler avec des collègues plus jeunes. Ici, la question n'est pas dans les choses formelles, pas dans le salaire, mais simplement dans ce pour quoi une personne a un intérêt et une inclination. C'est pourquoi, chez tous les ingénieurs, nous valorisons la passion, la capacité à prendre une tâche complexe et à la mener à bien à travers un processus en plusieurs étapes du début à la fin. En règle générale, tout ingénieur qui en est capable est intéressant et agréable pour nous. Mais, comme je l'ai dit, parallèlement à cela, nous laissons toujours la possibilité à une personne de devenir un expert technique, sans se plonger dans des fonctions administratives et de gestion.
Mikhail Mazein, ManyChat... Il est déjà assez difficile de formaliser les exigences pour les notes, et nous n'avons pas non plus cherché à les formaliser strictement, focalisés sur des exemples d'attentes de ce que nous aimerions voir d'un ingénieur à différents stades de développement. Tout cela s'est enveloppé dans un impact spécifique que les gens apportent aux processus au niveau de l'équipe ou de l'entreprise.
Cela crée des difficultés. D'une part, on ne limite pas les gens en croissance, une toile vierge apparaît devant eux, sur laquelle ils peuvent dessiner leur piste de développement. Mais dessiner une nouvelle image sur une feuille de papier vierge est bien plus difficile que de suivre les sentiers battus. Nous résolvons ce problème par le mentorat. Les mentors aident à construire des pistes basées sur les désirs des personnes et à les synchroniser avec les besoins de l'entreprise. Nous essayons également de développer la mentalité de recherche de problème afin que les ingénieurs détectent les problèmes dans les processus et tentent d'initier eux-mêmes leur solution. Là encore, les mentors aident.
Anton Grishin, MadRobots.Il y a des gens pour qui la croissance est leur propre besoin, et il y a des gens qui grandissent parce qu'elle est tellement établie autour et pour cela les conditions ont été créées. Mais ils ont tous périodiquement une question - pourquoi? La motivation personnelle pour apprendre de nouvelles choses, pour le développement est perdue, car cela peut ne pas être applicable dans les réalités actuelles ou avec les collègues actuels.
Comme l'une des solutions, nous avons organisé des rencontres internes, mais pas en tant que groupe de loisirs, mais en tant que conférence interne, avec une réelle préparation d'un nouveau sujet. Une histoire positive a émergé de cela, les gars ont commencé à comprendre entre eux que si, par exemple, les frontends peuvent faire quelque chose de nouveau, alors nous, designers et designers, pouvons repenser nos approches et essayer de nouveaux outils. Il s'avère que la motivation naturelle de chacun est d'essayer de faire quelque chose de nouveau ensemble.
La douleur provoque toujours l'approche personnelle de chaque personne à son propre développement.
Comment mettre en place une culture de développement au départ d'une nouvelle équipe
Sergey Averyanov, FunBox: Le fait même de la croissance de l'entreprise nous a aidés. Quand il n'y a pas beaucoup d'ingénieurs, ils cuisinent tous ensemble, ils se connaissent tous et font à peu près le même type de tâche. Et dès que différents types de projets et de rôles commencent à s'aligner, tout le monde est doté de pouvoirs différents. Quelqu'un fait des tâches, quelqu'un est engagé dans des déploiements, des clusters, quelqu'un est impliqué dans la conception de produits.
Il est important pour nous que chaque membre de l'équipe comprenne ce dont il a besoin pour passer d'un développeur à un développeur de niveau supérieur ou un chef d'équipe.
, 125 , , , , .
Les rencontres internes sont très utiles. Lorsqu'une entreprise a de nombreuses équipes et plusieurs produits, les gens cuisinent chacun à leur sauce, et lors de rencontres, ils discutent, racontent ce qu'ils font, échangent des connaissances. Cela ne génère pas de compétition entre les équipes, mais la recherche de l'excellence.
Artem Susekov, Miro: À un stade de la croissance de l'équipe, diverses guildes qui se forment autour des technologies aident bien: backend, frontend, QA. Dans les guildes, les connaissances sont échangées entre différentes équipes.
Les événements internes aident également: les Meetups, les Sprint Reviews publics, où les équipes partagent un contexte commun, parlent des résultats. Il est important ici d'aider les ingénieurs à se préparer à de telles performances.
Alexander Borisov, X5 Retail Group:Vous ne pouvez pas espérer dire que des rencontres sont nécessaires et que les gens commencent à s'organiser. Ils doivent également être traités. Dans le cas de notre échelle, il est logique de distinguer les personnes responsables qui l'organisent. Les équipes ont souvent des choses sympas à l'intérieur, mais elles cuisinent à l'intérieur d'elles-mêmes, elles n'ont tout simplement pas assez de temps pour organiser une rencontre et partager leurs bonnes pratiques. Il semble que nous aurions pris une demi-heure, réunis dans une salle de réunion et dépensé, mais non. Il y a quelques nuances.
Mikhail Mazein, ManyChat: Un processus d'intégration bien structuré pour les nouvelles personnes nous permet de leur transmettre les principes généraux et les approches, pour former correctement une image de l'équipe et du projet. Ainsi, la culture avec l'arrivée de nouvelles personnes s'accumulera et se transmettra.
Question chaude sur l'argent
Une question d'un spectateur: «Vous n'abordez pas les problèmes de viabilité financière de l'organisation. Comment la part des dépenses de l'entreprise est-elle déterminée pour qu'un employé lise des livres pendant les heures de travail? Le second est un exemple, laissez la solution d'un problème prendre 80 heures pour un développeur qui a déjà résolu un tel problème, et 150 heures prendront la solution du même problème pour un développeur qui ne connaît pas le contexte, mais en même temps il grandira et pompera. La question est de savoir qui paiera la différence de 70 heures consacrées au développement. "
Alexander Borisov, X5 Retail Group:Dans notre cas, il n'y a pas de client. Nous avons commencé à constituer activement une équipe interne au lieu de continuer à sous-traiter certaines choses, car nous comprenons que la compétence nous coûte très cher et entraîne des coûts finaux, en augmentant la marginalité de l'entreprise, d'un Pyaterochka particulier près de chez vous. C'est un investissement pour l'avenir.
Mais si une personne, au lieu de faire une tâche pendant trois heures pendant 150 heures, s'est mise à lire un livre, la question se posera uniquement du propriétaire du produit ou du propriétaire du pool de ressources. S'il s'agit d'un investissement compréhensible dans le fait qu'une personne a grandi, alors, encore une fois, au niveau de ces deux personnes, cela est facilement résolu. Par exemple, un plan pour un sprint, respectivement, à l'intérieur, nous avons établi quelque chose qui devra être lu, et nous y intégrons, c'est une histoire normale.
Artem Susekov, Miro:Il existe un accord au niveau de l'entreprise selon lequel nous aidons les ingénieurs à se développer à l'aide de cours et d'ateliers, qui ont lieu pendant les heures de travail. C'est-à-dire que l'entreprise paie pour cela, c'est un investissement dans chaque membre de l'équipe, car nous pensons que ce type d'investissement aidera toute l'équipe à progresser plus rapidement à l'avenir.
Le temps spécifique réservé à l'ingénieur pour l'enseignement du sprint est discuté au niveau de l'équipe spécifique. Il est important ici qu'il n'y ait pas de distorsions dans l'autre sens, que nous n'étudions que tout le temps pendant le sprint et ne fassions rien d'autre.
Sergey Averyanov, FunBox:Je pense que la question sur 80 et 150 heures est plus aiguë pour l'externalisation, quand vous pouvez demander - pourquoi un développeur inexpérimenté devrait-il faire 150 heures pour moi, en tant que client, si un développeur expérimenté a fait la même chose pour moi plus de 80? Je ne peux pas dire comment l'externalisation résout ce problème, car nous ne sous-traitons pas. Dans le cadre d'une société de produits, cela est résolu par le fait que le budget est consolidé, et les coûts de main-d'œuvre pour le développement sont exprimés en profit du fait qu'un membre de l'équipe élève son niveau, commence à mieux travailler, plus vite.
À propos de la lecture de livres pendant les heures de travail. Nous avons l'habitude que le besoin d'apprendre quelque chose est une étape tout à fait naturelle dans le travail sur un problème. Nous ne jetons pas le développeur dans un maelström, fixant des tâches comme: «Lire un livre» ou «étudier une technologie qui n'a pas de but ultime». Cela ne devrait pas être tel qu'une personne s'assied et pense - ai-je déjà étudié la technologie ou dois-je étudier davantage? Une tâche hors contexte, hors but conduit à la procrastination, au fait qu'une personne perd confiance en elle et ne sait pas quand faire quelque chose.
La recherche et la lecture de la littérature, l'étude de quoi que ce soit devrait faire partie de la tâche, mais il devrait y avoir un objectif final tangible pour lequel cette étude peut être appliquée.
Anton Grishin, MadRobots: Je viens du monde où chaque heure, quelqu'un gagnait et quelqu'un perdait de l'argent. En règle générale, le client est honnêtement dit: "Nous ne vous retirerons plus d'argent, mais nous ferons la tâche plus longtemps." L'entreprise, son employeur, paie de toute façon le développement d'un ingénieur. Le client attend simplement un peu plus longtemps, mais à l'avenir, il comprend que maintenant non pas un, mais deux développeurs sont engagés dans le développement de son produit, tout est résolu plus rapidement, l'échelle de mise en œuvre augmente.
Dans les studios et les agences, où les processus sont normalement construits, le développeur ne sera jamais mis sur un projet qui objectivement ne le tire pas, car il apportera plus de pertes à l'entreprise qu'il n'en gagnera sur le développement.
Alexander Borisov, X5 Retail Group:En plus de mon travail chez X5, j'ai mon propre petit studio d'externalisation. Je comprends très bien son économie. Nous avons fixé 80 heures rémunérées, mais nous avons compris que c'était 150, et le nombre d'heures rémunérées et le temps de développement, ils différaient très souvent. Nous avons toujours pris une sorte de stock, et nous avons simplement payé ce stock avec notre propre argent. S'il y a quelque part un cas de force majeure, cela signifie qu'il est payé sur leur propre argent.
Mikhail Mazein, ManyChat: Le développement de produits, où nous n'avons pas de client externe, nous délie grandement les mains à cet égard. En général, nous ne suivons pas la performance de chaque personne individuellement, nous mesurons la performance de l'équipe.
Chaque équipe a sa propre capacité et vitesse, elles peuvent varier considérablement, mais en général, nous nous concentrons sur la performance de toute l'équipe dans son ensemble. Le temps libre dont dispose un ingénieur dans le sprint actuel n'est pas très important pour nous, car pour une entreprise, ce temps reste toujours à l'entraînement, et d'un sprint à l'autre, il diffère en principe pour chaque ingénieur. Quelque part dans le sprint, il y aura plus de charge sur le frontend, dans le prochain sprint, il y aura plus de charge sur le backend, et toute cette histoire se stabilisera à long terme.
Si nous parlons d'évaluer la performance de chaque personne, c'est l'équipe elle-même qui en est responsable, c'est comme une structure autorégulée. Il y a des situations où la rétroaction vient, par exemple, du mentor de cette personne, que quelque chose ne va pas avec la performance, ou de ses pairs de la communauté fonctionnelle.
, ?
, Miro: , , . , , … , .
Sergey Averyanov, FunBox: Je pense qu'il peut y avoir des entreprises qui se concentrent sur des spécialistes de niveau fixe, elles ont toujours le même travail avec les mêmes qualifications, elles ne veulent élever personne. Ce problème est résolu par le fait qu'il y a un roulement important et que les employés qui pourraient grandir trouvent de nouveaux emplois. Soit nous investissons dans le développement des collaborateurs et l'expansion de l'entreprise, soit nous avons un chiffre d'affaires.
Artem Susekov, Miro: Cela peut déjà être calculé, si nous parlons de chiffre d'affaires, nous nous en tiendrons à cette métrique, s'il s'agit d'argent, non? Le coût d'attirer chaque nouvelle personne, combien de temps est passé sur les recruteurs, combien nous dépensons pour l'intégration et combien nous puis, lorsque la personne quitte, nous fermons à nouveau le poste. Tout cela peut être compté en argent.
Sergey Averyanov, FunBox:Soit dit en passant, un indicateur intéressant qui est même utile pour soi-même est la période médiane de travail dans l'entreprise. Cela nous permet d'estimer le chiffre d'affaires, c'est-à-dire combien de personnes travaillent dans notre médiane. Quand on voit que la médiane est grande et en marge de cette distribution il y a des gens qui ont travaillé pendant huit à dix ans, qui n'ont pas épuisé, ils vont bien et tout le monde est content l'un de l'autre, c'est une bonne nouvelle.
Anton Grishin, MadRobots: Il me semble que maintenant l'entreprise n'a pas besoin d'expliquer tout cela, il est évident que le besoin de développement personnel est inhérent aux personnes qui créent des produits intellectuels. Par conséquent, je ne peux même pas penser à des exemples où des spécialistes du même niveau sont nécessaires, car les technologies mêmes que nous utilisons nous dictent que nous devons développer.
Mishan Storozhilov, bureau du DevRel:Il me semble qu'il ne s'agit pas seulement de personnes avec des performances fixes et des technologies fixes. Je pense que cette histoire concerne aussi une grande refactorisation, une grosse dette technique. Nous travaillons avec des entreprises qui comprennent la nécessité de développer des ingénieurs, mais la question de la justification du coût de la formation et du développement se pose toujours.
Sergey Averyanov, FunBox:Ici, le mot «refactoring» a retenti, et l'attitude à son égard peut être intéressante. Beaucoup de gens pensent à tort, en particulier des spécialistes non techniques, que ce sont des gestes étranges de mecs en pull qui ne font rien et dépensent de l'argent. Le problème ici est précisément dans la communication, c'est-à-dire que le manager doit comprendre que le refactoring qui ne s'est pas produit aujourd'hui est l'augmentation du temps de développement demain. Aujourd'hui, nous économiserons quelques heures de travail, et demain nous les dépenserons.
Nous avons convenu en interne que le chef d'équipe a le droit de dire que la condition nécessaire pour mener à bien la tâche est de procéder à la refactorisation, sans cela, nous obtenons un tel non-sens qu'il est impossible de travailler avec.
Naturellement, c'est finalement une question d'accord, mais nous ne considérons pas le refactoring comme une activité parallèle et un gaspillage de ressources, mais comme une partie du flux de travail.
Artem Susekov, Miro: Si nous parlons de développement de produits, les accords sont importants. Par exemple, le chef de produit détermine les priorités en fonction de la notation, et l'équipe ou la voix de l'équipe, du responsable technique ou du chef d'équipe, détermine comment le faire. Le produit dit ce qui est le plus important maintenant, l'ingénieur dit comment nous allons le faire.
Le refactoring est un processus naturel. Le refactoring aujourd'hui nous coûtera beaucoup moins cher que le refactoring en un quart. C'est comme avec un prêt - si vous ne payez pas, la prochaine fois, vous devrez payer plus.
Alexander Borisov, X5 Retail Group: Il y a un terme «dette technique», et juste au stade de la communication entre l'équipe et le produit, on comprend que si on ne le fait pas maintenant, c'est une dette technique. En conséquence, la dette technique à travers le sprint sera plus importante, dans six mois elle le sera encore plus et vous devrez payer avec ce pourcentage. En fait, comme pour un prêt ordinaire, exactement de la même manière l'équipe négocie avec le produit, si vous le souhaitez, plus rapidement ou plus humainement. Si c'est plus rapide, vous devrez un jour payer beaucoup plus. Comme pour un prêt.
Mishanya Storozhilov, DevRel-bureau: Soit cette dette se transforme simplement en «hypothèque technique».
Nous avons réuni cinq ingénieurs, ils n'ont parlé que d'une heure et demie et ont déjà commencé à parler de refactoring.
* * * Le
deuxième meetup de la série aura lieu le 20 août . Le sujet est la toxicité dans les équipes, les entreprises et l'industrie. Orateurs - ingénieurs et responsables techniques de Miro, SEMrush, Parma TG, Xsolla.
L'inscription est ouverte .