Dans l'
article précédent, il avait été question d'embaucher dans notre entreprise, mais ce n'est pas si mal - après tout, il est tout aussi important et compétent de présenter un nouvel employé au cours de ce qui se passe! Je partagerai notre expérience dans ce domaine dans le nouveau matériel.
Aller au travail et les trois premiers mois
Si tout a grandi ensemble, l'employé se met au travail. Nous lui donnons des équipements d'entreprise pour les ingénieurs DevOps, par exemple, un ordinateur portable de travail et un casque testé pour la qualité et la compatibilité avec le bon matériel. Tout cela est renvoyé à la maison en utilisant le service de livraison.
Le logiciel nécessaire est installé sur l'ordinateur portable (y compris l'intégration avec les services internes) et des mesures de sécurité obligatoires sont fournies (par exemple, le cryptage des données). Tous les ingénieurs ont Ubuntu. Les sources d'intégration à nos services sont ouvertes aux salariés.
Nous aimons généralement
les logiciels open source : les sources de tous les projets internes sont à la disposition de tout ingénieur. Et sur chacun d'eux, vous pouvez voir, par exemple, ceci:
En cliquant sur le numéro de commit, vous y accédez dans le GitLab interne. Vous n'aimez pas quelque chose? Vous voulez le réparer? Lisez le code, éditez, envoyez une demande de fusion - nous sommes finalement des ingénieurs!
Remarque : Notre amour de l'Open Source, cependant, s'étend plus loin. Nous avons ouvert toute une série de nos développements à la communauté sur GitHub , et avant de l'utiliser, depuis environ 2009, nous l'avons fait en utilisant d'autres ressources. Et nous continuons à l' ouvrir autant que possible (indice: en route nous avons un autre projet, dont la source est déjà accessible au public ... suivez les annonces sur notre blog!). De plus, nous allons passer en contrebande dans des projets proches de nous (comme Helm et GitLab ) et parfois nous adonner .Méthodologies flexibles comme le code
Flant fonctionne selon des méthodologies flexibles, mais au lieu d'holivars sur la formulation correcte dans le manifeste Agile, nous implémentons des méthodologies dans le code. Les services internes de suivi des tâches, du temps, des projets et d'autres choses sont
bien intégrés les uns aux autres et nous privent d'un énorme mal de tête. Comment?
Par exemple, nous avons notre propre système d'enregistrement des «cartes» et du temps de la journée, réalisé à l'aide de deux services Web: Nixon et Ford (du nom des présidents américains).
Pourquoi pas Trello? Parce que nos Nixon et Ford, entre autres, peuvent:
- comprendre qu'une personne peut résoudre des problèmes dans différentes équipes au cours de la journée (et elle doit le faire facilement!);
- créer des tâches à partir de cartes dans Redmine en un seul clic, et également intégrer avec GitLab et GitHub;
- diviser les cartes par priorité, les reporter par date ou par carnet de commandes;
- organiser un workflow simple avec confirmation;
- filtrer, rechercher et fournir de nombreux raccourcis clavier pertinents.
En termes simples - ces services sont optimisés autant que possible pour nos demandes spécifiques, qui changent au fil du temps, et sont complétés par des commentaires approfondis d'utilisateurs directs (ingénieurs).
Pour gérer les incidents, les ingénieurs de service ont Polk (oui, il y avait un tel
président ) - il est également intégré à tout ce qui est possible. Création rapide de tâches (si l'incident n'est pas urgent et nécessite beaucoup de travail), collecte des alertes entrantes de plusieurs types de surveillance, communication directe avec les clients via le bot Slack et de nombreuses autres fonctions nécessaires ... Nous ne pouvons tout simplement pas imaginer un travail efficace autrement.
Ou, par exemple, la gestion de projet. Il existe un service Bush qui se souvient de tout sur les clients, leurs projets, les employés et les équipes. Créez-vous un projet dans GitLab interne? Entrez simplement les informations nécessaires dans Bush - il créera tous les paramètres, fournira tous les accès et ouvrira un référentiel.
L'adaptation
Tout d'abord, le débutant suit le cours d'un jeune combattant dans une équipe spécialisée engagée dans la diffusion des connaissances. Nous lui apprenons le minimum nécessaire, avec lequel il peut rejoindre immédiatement son équipe, avoir une compréhension de ce qui se passe et déjà comprendre les spécificités des projets clients. Cela prend les 3-4 premiers jours, après quoi l'ingénieur, sous l'attention vigilante du chef d'équipe et des ingénieurs de l'équipe de diffusion des connaissances, commence à plonger dans de véritables missions de combat.
Afin qu'un nouveau venu puisse naviguer en toute sécurité dans le flux de nouvelles connaissances, nous formulons pour lui une
liste de réalisations - «réalisations». La première fois est très effrayante et cool en même temps, et nous mettons beaucoup d'efforts pour «refroidir».
Plus tard, lorsque l'ingénieur passe la période d'essai (par défaut c'est 3 mois, mais parfois moins en fonction de différents critères - voir la note ci-dessous), la liste des réalisations du trimestre sera formée individuellement, mais dans un premier temps nous saisissons l'initiative et lui donnons
des points clés comme:
- Cluster Kubernetes bricolage bricolage. Collègues d'aide occasionnels possibles. Maximum - en 2 jours ouvrables.
- Ceph entièrement auto-déployé à Kubernetes.
- Accepté par MR ou créé par Issue dans tout projet de documentation.
- Journée fermée, remplie de cartes correctement conçues avec les bons minuteries.
- ...
Remarque : Soit dit en passant, l'une des incitations supplémentaires pour terminer la période d'essai (au cours de laquelle les employés reçoivent un correctif) sont les mêmes bonus qui viennent dans notre système de paiement immédiatement après.Nous intégrons progressivement les tâches clés dans des cours internes et des guides dans la base de connaissances.
Ces réalisations aident le chef d'équipe à choisir le bon artiste pour les tâches. Il y a toujours la tentation de lancer des tâches à ceux qui les traiteront rapidement, en ignorant ceux qui ont besoin de resserrer leurs compétences. Nous luttons avec succès contre cela.
Le point clé auquel un débutant cherche à venir est en service dans son équipe. Chaque ingénieur d'équipe passe une de ses journées de travail à tour de rôle sur des projets d'équipe: répondre rapidement aux questions des clients et répondre aux accidents. Bien sûr, il ne reste pas seul: les questions les plus simples portent sur la première et la deuxième ligne de support, les plus complexes s'adressent à des équipes plus expérimentées. Et l'équipe elle-même est toujours disponible, l'officier de service, si nécessaire, peut appeler les ingénieurs nécessaires pour obtenir de l'aide.
Cela aide tous les membres de l'équipe à se tenir au courant de tous les projets et leur donne également une image réelle des problèmes qui peuvent être éliminés dans l'œuf, et grâce à cela, commencez à gagner plus d'argent.
Salaire et bonus
Nous nous efforçons d'obtenir des résultats avec l'aide de notre cerveau, et non les investissements monstrueux de temps et d'énergie. Par conséquent, plus une équipe prend de projets sans perdre en efficacité, plus les employés obtiennent d'argent. Nous avons développé un système de paiement plutôt rusé et rare, ce qui est surprenant pour certains. J'essaierai d'expliquer.
Toute notre vie, nous avons vécu sur une base horaire, mais reposait sur le fait que les gens se fanent progressivement et ne résolvent pas les problèmes de manière systémique. Au fil du temps, nous sommes passés à une nouvelle approche, qui implique le montant de: un taux fixe + une certaine partie, en fonction des heures passées, + des primes pour l'efficacité de l'équipe. La transition a nécessité du courage de la part des ingénieurs, mais en conséquence, tout le monde était satisfait, a commencé à recevoir un gros salaire et un meilleur sommeil.
L'équipe reçoit l'argent que l'équipe a reçu au-delà du minimum nécessaire pour couvrir les salaires, en fonction des accords avec son équipe. Le plus souvent, la carcasse d'un ours chassé est divisée en fonction des heures passées et du niveau des salaires.
Pour comprendre le niveau général: le salaire de notre ingénieur dans les régions est d'environ 90 à 150 mille roubles par mois (par personne). Bien sûr, c'est la «température moyenne à l'hôpital», car c'est toujours un domaine d'entente personnelle et une combinaison de nombreux facteurs différents.
Tous les employés de notre entreprise travaillent dès le premier jour "en blanc", officiellement, dans le cadre d'un contrat de travail à durée indéterminée et conformément au Code du travail de la Fédération de Russie. Un salaire complètement blanc (payé en deux versements à des dates fixes du mois) implique que les impôts en sont payés et que des retenues sont effectuées sur tous les fonds nécessaires. En conséquence, tous les revenus de nos employés sont affichés dans les certificats 2NDFL et il n'y a aucun problème lors de la demande de prêt.
De plus, Flant paie, bien entendu, les congés de maladie et les congés. Soit dit en passant, nous avons deux types de vacances: annuel (d'une durée de 28 jours civils) et supplémentaire, trois autres jours payés par an. Des vacances ou des jours de vacances sans maintenance sont également possibles, mais il est important d'avertir l'équipe, de coordonner le problème avec le chef d'équipe et de s'assurer que l'absence d'un employé n'entraîne pas de conséquences critiques. Comprenant qu'il existe des cas de besoin urgent, nous essayons de trouver des moyens de libérer le salarié dans de telles situations, malgré les restrictions législatives (le Code du travail de la Fédération de Russie exige un avertissement de ses vacances et de ses congés à l'avance).
Croissance de l'entreprise
Bien que ce ne soit plus le sujet de l'article, je ne peux ignorer le fait que la croissance d'une entreprise n'est pas un vide marketing pour nous. Nous nous efforçons vraiment de fournir toutes les opportunités de relations à long terme avec les employés et de participer à leur développement (conformément aux dispositions et aux préférences). De plus, grâce à l'échelle existante de l'entreprise et à la diversité des clients et des activités connexes (y compris nos processus internes), nous avons vraiment quelque chose à offrir.
Bien sûr, il y a un «chemin par défaut» L1 → L2 → Ingénieur DevOps (dont un qui exécute les fonctions L3) → ingénieur principal, chef d'équipe, PM ... Mais il y a des mouvements plus complexes qui dépendent non seulement des capacités humaines, mais aussi des capacités réelles besoins de l'entreprise. Ainsi, par exemple, un jour, nous avons occupé le poste de «directeur de service», auquel a grandi l'un des ingénieurs en service (L1 / L2), et il suffit de se rappeler que nous avons des équipes spéciales, telles que la R&D.
Si les lecteurs sont intéressés (écrivez dans les commentaires!) - nous parlerons des histoires de croissance et de développement de l'entreprise qui sont vraiment arrivées à nos employés et qui apparaissent maintenant.
Au lieu d'une conclusion
Les processus d'adaptation sont devenus plus pertinents que jamais à mesure que l'entreprise grandit. Dans notre cas, le tournant - l'étape à laquelle nous avons estimé qu'un changement qualitatif dans le travail avec de nouveaux ingénieurs est critique pour l'entreprise - s'est produit autour de la marque de 50 employés. Cependant, à bien des égards, ce n'est que le début de la route - notre approche de l'adaptation se développe activement en ce moment. Nous construisons des processus d'embauche interne et d'échange d'expériences, affinons les outils du travail quotidien et développons une base de connaissances. Cependant, c'est une histoire complètement différente ...
PS
J'exprime ma gratitude à mes collègues: la directrice des ressources humaines Anna et
shurup - pour leur aide dans la préparation des deux parties de cet article. Nous sommes heureux de partager notre expérience dans d'autres domaines liés à cette «cuisine interne» de notre entreprise, à votre demande.
PPS
Lisez aussi dans notre blog: