Au stade actuel du développement des logiciels industriels, on peut observer une variété de rôles de production. Leur nombre augmente, la classification devient chaque année plus compliquée et, naturellement, les processus de sélection des spécialistes et de collaboration avec les ressources humaines deviennent plus compliqués. Les technologies de l'information (TI) sont un domaine de ressources en main-d'œuvre hautement qualifiée et de pénurie de personnel. Ici, le processus de développement du personnel et la nécessité d'un travail systématique avec le potentiel du personnel sont beaucoup plus efficaces que la sélection directe à l'aide des ressources Internet.
L'article aborde des questions qui intéressent les spécialistes RH des entreprises informatiques : les relations de cause à effet dans l'évolution des rôles de production, les conséquences d'une mauvaise interprétation du contenu des rôles pour le travail RH en général, ainsi que les options possibles pour augmenter le efficacité du recrutement de spécialistes.
Fabrication informatique pour les non-initiés
Le who's who en informatique est un sujet de discussion sur diverses plateformes. Il existe depuis aussi longtemps que l'ensemble de l'industrie informatique, c'est-à-dire depuis l'apparition des premières sociétés de développement de logiciels sur le marché grand public au début des années 90 du siècle dernier. Et depuis le même temps, il n'y a pas eu de vision commune sur cette question, ce qui crée des difficultés et réduit l'efficacité du travail du personnel. Essayons de le comprendre.
Pour moi, le sujet des rôles de production dans le secteur informatique est devenu pertinent et intéressant depuis que j'ai rejoint l'entreprise informatique. J'ai passé beaucoup de temps et d'énergie nerveuse à essayer de comprendre le processus de production. Ces coûts ont dépassé mes attentes et les coûts d'adaptation aux processus dans d'autres domaines : éducation, production matérielle, petites entreprises. J'ai compris que les processus sont complexes et inhabituels, car, en général, une personne est plus adaptée au monde matériel qu'au monde virtuel. Mais il y avait une résistance intuitive : il semblait que quelque chose n’allait pas ici, cela ne devrait pas être ainsi. Le processus d’adaptation a probablement pris un an, ce qui, à mon sens, est tout simplement cosmique. En conséquence, j'avais une compréhension assez claire des rôles clés dans la production informatique.
Actuellement, je continue à travailler sur ce sujet, mais à un autre niveau. En tant que responsable du centre de développement d'une entreprise informatique, je dois souvent communiquer avec des étudiants, des professeurs d'université, des candidats, des écoliers et autres personnes souhaitant participer à la création d'un produit informatique afin de promouvoir la marque employeur sur le marché du travail. d'un nouveau territoire (Iaroslavl). Cette communication n'est pas facile en raison de la faible connaissance des interlocuteurs de l'organisation du processus de développement logiciel et, par conséquent, de leur manque de compréhension du sujet de la conversation. Après 5 à 10 minutes de dialogue, vous ne recevez plus de commentaires et commencez à vous sentir comme un étranger dont le discours nécessite une traduction. En règle générale, parmi les interlocuteurs, il y a quelqu'un qui trace une ligne dans le dialogue et exprime un mythe populaire des années 90 : « De toute façon, tous les informaticiens sont des programmeurs ». Les origines du mythe sont :
- L'industrie informatique se développe rapidement, dans ces conditions toutes les significations et principes fondamentaux sont au stade de la formation ;
- Il est difficile d'exister dans des conditions d'incertitude, alors une personne essaie de se faciliter la compréhension de l'inconnu en créant des mythes ;
- une personne est plus habituée à la perception du monde matériel qu'au monde virtuel, et il lui est donc difficile de définir des concepts qui dépassent sa perception.
Essayer de combattre ce mythe peut parfois donner l’impression de jouer contre des moulins à vent, car plusieurs aspects du problème doivent être abordés. Un spécialiste des ressources humaines doit, premièrement, avoir une idée claire des rôles de production dans une entreprise informatique dans une incarnation idéale et réelle, deuxièmement, comprendre comment et quand les ressources internes de l'entreprise peuvent être utilisées le plus efficacement, et troisièmement, quelles méthodes réelles permettront contribuera à accroître la sensibilisation des acteurs du marché du travail et contribuera au développement de la marque employeur. Examinons de plus près ces aspects.
Cycle de vie du logiciel comme base pour les rôles de production
Ce n’est un secret pour personne : en général, tous les rôles de production dans toute entreprise informatique ont pour source le cycle de vie des logiciels. Par conséquent, si nous nous fixons pour tâche conceptuelle de s'entendre sur une perception unifiée de cette question au sein de l'ensemble de l'industrie informatique, nous devons nous appuyer spécifiquement sur le cycle de vie du logiciel comme base sémantique acceptée et clairement comprise par tous. La discussion d'options spécifiques pour mettre en œuvre la question des rôles de production se situe dans le plan de notre attitude créative envers le cycle de vie du logiciel.
Examinons donc les étapes que comprend le cycle de vie du logiciel, en utilisant la méthodologie RUP comme exemple. Ce sont des liens assez matures en termes de contenu et de terminologie. Le processus de production commence toujours et partout par la modélisation commerciale et la formation des exigences, et se termine (sous réserve, bien sûr) par la consultation des utilisateurs et la modification du logiciel en fonction des « souhaits » des utilisateurs.
Si vous faites une excursion historique jusqu'à la fin du siècle dernier (comme vous le savez, c'était la période de « l'automatisation insulaire »), vous remarquerez que l'ensemble du processus de création de logiciels a été réalisé par un programmeur-développeur. Voici les racines du mythe selon lequel tout informaticien est un programmeur.
Avec la complexité croissante des processus de production, l'émergence de plateformes intégrées et la transition vers une automatisation complexe des domaines, avec la réingénierie des processus métiers, l'émergence de rôles spécialisés liés aux étapes du cycle de vie devient inévitable. C'est ainsi qu'apparaissent un analyste, un testeur et un spécialiste du support technique.
Diversité des postes à l'aide de l'exemple du rôle d'analyste
Un analyste (également appelé ingénieur analytique, également appelé directeur, méthodologiste, analyste commercial, analyste système, etc.) aide à « se lier d'amitié » avec les tâches commerciales et les technologies pour leur mise en œuvre. Description de l'énoncé du problème pour le développeur - c'est ainsi que l'on peut caractériser la fonction principale d'un analyste abstrait. Il agit comme lien entre le client et le développeur dans les processus de formation des exigences, d'analyse et de conception du logiciel. Dans des conditions réelles de production, la liste des fonctions d'analyste est déterminée par le mode d'organisation de la production, les qualifications du spécialiste et les spécificités du domaine modélisé.
Certains analystes sont situés plus près du client. Il s’agit d’analystes métiers (Business Analyst). Ils comprennent parfaitement les processus métier du domaine et sont eux-mêmes experts en processus automatisés. Il est très important d'avoir de tels spécialistes parmi le personnel d'une entreprise, en particulier lors de l'automatisation de domaines méthodologiquement complexes. En particulier, pour nous, en tant qu’automatiseurs du processus budgétaire de l’État, il est simplement nécessaire qu’il y ait des experts en la matière parmi les analystes. Il s'agit d'employés hautement qualifiés possédant une bonne formation financière et économique et une expérience de travail au sein des autorités financières, de préférence dans le rôle de spécialistes de premier plan. L'expérience n'est pas extrêmement importante dans le domaine informatique, mais spécifiquement dans le domaine concerné.
L'autre partie des analystes est plus proche des développeurs. Ce sont des analystes système (System Analyst). Leur tâche principale est d'identifier, de systématiser et d'analyser les exigences des clients pour déterminer la possibilité de les satisfaire, de préparer les spécifications techniques et de décrire les énoncés des problèmes. Ils comprennent non seulement les processus commerciaux, mais également les technologies de l'information, ont une bonne compréhension des capacités du logiciel fourni au client, possèdent des compétences en conception et, par conséquent, comprennent la meilleure façon de transmettre les intérêts du client au développeur. Ces employés doivent avoir une formation dans le domaine des TIC et un esprit d'ingénierie et technique, de préférence une expérience en informatique. Lors de la sélection de tels spécialistes, disposer de compétences en conception utilisant des outils modernes constituera un net avantage.
Un autre type d’analyste est celui des rédacteurs techniques. Ils sont engagés dans la documentation dans le cadre des processus de développement de logiciels, en préparant des manuels d'utilisation et d'administrateur, des instructions technologiques, des vidéos de formation, etc. Leur tâche principale est d'être capable de transmettre des informations sur le fonctionnement du programme aux utilisateurs et autres parties intéressées, de décrire de manière concise et claire des choses techniquement complexes. Les rédacteurs techniques ont pour la plupart une excellente maîtrise de la langue russe, tout en ayant une formation technique et un esprit analytique. Pour ces spécialistes, les compétences nécessaires pour rédiger des textes techniques clairs, compétents et détaillés conformément aux normes, ainsi que la connaissance et la maîtrise des outils de documentation sont de la plus haute importance.
Ainsi, nous voyons le même rôle (et, soit dit en passant, le même poste dans le tableau des effectifs) - analyste, mais dans ses différentes incarnations d'application spécifiques. La recherche de spécialistes pour chacun d'eux a ses propres caractéristiques. Il est important de savoir que ces types d’analystes doivent avoir des compétences et des connaissances souvent incompatibles chez une seule personne. L'un est un spécialiste des sciences humaines, enclin au travail analytique avec de grands volumes de documents texte, avec des compétences développées en matière d'expression orale et de communication, l'autre est un « technicien » avec une pensée technique et des intérêts dans le domaine informatique.
Devons-nous prendre de l'extérieur ou grandir ?
Pour un grand représentant de l'industrie informatique, l'efficacité de la sélection directe à partir des ressources Internet diminue à mesure que les projets se développent. Cela se produit notamment pour les raisons suivantes : une adaptation rapide à des processus complexes au sein de l'entreprise est impossible, la vitesse de maîtrise d'outils spécifiques est inférieure à la vitesse de développement du projet. Par conséquent, il est important qu’un spécialiste RH sache non seulement qui rechercher en externe, mais aussi comment utiliser les ressources internes de l’entreprise, auprès de qui et comment développer un spécialiste.
Pour les analystes commerciaux, l'expérience de travail dans le cadre de processus réels dans le domaine est très importante, il est donc plus efficace de les recruter « de l'extérieur » que de les développer au sein de l'entreprise. Dans le même temps, il est important qu'un spécialiste RH connaisse la liste des organisations qui peuvent être des sources de ces ressources humaines et, lors de la sélection, se concentre sur la recherche de CV d'elles.
Au contraire, pour pourvoir des postes vacants tels que ceux d'analyste de systèmes et d'architecte logiciel, le processus de formation au sein de l'entreprise est d'une grande importance. Ces spécialistes doivent être formés dans l'environnement de production actuel et dans les spécificités d'une organisation particulière. Les analystes système se développent à partir d’analystes commerciaux, de rédacteurs techniques et d’ingénieurs de support technique. Architectes logiciels - des concepteurs (System Designer) et des développeurs de logiciels (Software Developer) à mesure qu'ils acquièrent de l'expérience et élargissent leurs horizons. Cette circonstance permet à un spécialiste RH d’utiliser efficacement les ressources internes de l’entreprise.
Intersection, intégration et évolution des rôles de production
Il existe une autre question difficile du point de vue de la mise en œuvre dans le processus de production : établir des limites claires entre les rôles. À première vue, tout peut sembler évident : la mise en œuvre est terminée, les documents de mise en exploitation commerciale du logiciel ont été signés et tout a été remis au support technique. C'est vrai, cependant, des situations surviennent souvent lorsque le client, par habitude, étant en contact étroit avec l'analyste et le considérant comme une « baguette magique », continue de communiquer activement avec lui, malgré le fait que le système a déjà été mis en œuvre. et la phase de soutien formel est en cours. Cependant, du point de vue du client, qui, mieux et plus rapidement que l'analyste qui a défini la tâche avec lui, répondra aux questions sur l'utilisation du système. Et ici se pose la question de la duplication partielle des rôles d'ingénieur support technique et d'analyste. Au fil du temps, tout s'améliore, le client s'habitue à communiquer avec le service d'assistance technique, mais au tout début de l'utilisation du logiciel, une telle « transition interne » ne peut pas toujours se faire sans stress des deux côtés.
L'intersection des rôles d'analyste et d'ingénieur de support technique se produit également lorsque le flux des exigences de développement se produit dans le cadre de la phase de support. En revenant au cycle de vie des logiciels, nous constatons un écart entre les conditions de production réelles et les attitudes formelles selon lesquelles l'analyse des besoins et la formulation des problèmes peuvent être effectuées exclusivement par un analyste. Bien entendu, un spécialiste des ressources humaines doit comprendre l’image idéale des rôles au sein du cycle de vie du logiciel ; ils ont des limites claires. Mais en même temps, il faut absolument garder à l’esprit que l’intersection est possible. Lors de l'évaluation des connaissances et des compétences d'un candidat, vous devez faire attention à la présence d'une expérience connexe, c'est-à-dire que lors de la recherche d'ingénieurs de support technique, les candidats ayant une expérience d'analyste peuvent très bien être pris en compte et vice versa.
Aux chevauchements s’ajoute souvent une consolidation des rôles de production. Par exemple, un analyste commercial et un rédacteur technique peuvent exister comme une seule personne. La présence d'un architecte logiciel (Software Architect) est obligatoire dans les grands développements industriels, alors que les très petits projets peuvent se passer de ce rôle : là les fonctions d'architecte sont assurées par des développeurs (Software Developer).
Les changements au cours des périodes historiques dans les approches et les technologies de développement conduisent inévitablement au fait que le cycle de vie des logiciels évolue également. Globalement, certes, ses principales étapes restent inchangées, mais elles se précisent. Par exemple, avec la transition vers des solutions basées sur le Web et la croissance des capacités de configuration à distance, le rôle d'un spécialiste de la configuration logicielle est apparu. Au début de l’histoire, il s’agissait d’exécutants, c’est-à-dire d’ingénieurs qui passaient la majeure partie de leur temps de travail sur les lieux de travail des clients. L’augmentation du volume et de la complexité des logiciels a conduit à l’émergence du rôle d’architecte logiciel. Les exigences d'accélération des sorties de versions et d'amélioration de la qualité des logiciels ont contribué au développement des tests automatisés et à l'émergence d'un nouveau rôle - ingénieur QA (Quality Assurance Engineer), etc. L'évolution des rôles à toutes les étapes du processus de production est étroitement liée au développement des méthodes, des technologies et des outils.
Jusqu'à présent, nous avons examiné quelques points intéressants concernant la répartition des rôles de production au sein d'une entreprise de logiciels dans le contexte du cycle de vie du logiciel. Il s’agit évidemment d’un point de vue interne, propre à chaque entreprise. Pour nous tous, en tant qu’acteurs du marché du travail de l’industrie informatique et responsables de la promotion de la marque employeur, le regard extérieur sera particulièrement important. Et ici, il y a un gros problème non seulement pour trouver un sens, mais aussi pour transmettre cette information au public cible.
Quel est le problème avec le « zoo » des postes informatiques ?
La confusion dans l'esprit des spécialistes RH, des responsables de production et la diversité des approches conduisent à une très grande variété, un véritable « zoo » de postes informatiques. L'expérience des entretiens et simplement des contacts professionnels montre que les gens n'ont souvent pas une compréhension claire de la signification qui doit découler des titres de poste. Par exemple, dans notre organisation, les postes qui incluent le terme « ingénieur analytique » supposent qu'il s'agit d'un définisseur de tâches. Cependant, il s'avère que ce n'est pas le cas partout : il existe des organisations de développement où un ingénieur analytique est implémenteur. Une compréhension complètement différente, n’est-ce pas ?
Premièrement, le « zoo » des postes informatiques réduit sans doute l’efficacité du recrutement. Chaque employeur, lorsqu'il développe et promeut sa marque, souhaite transmettre sous une forme concise toutes les significations qui existent dans sa production. Et s'il ne peut souvent pas dire clairement qui est qui, il est naturel qu'il diffuse l'incertitude à l'environnement extérieur.
Deuxièmement, le « zoo » des postes informatiques crée d'énormes problèmes de formation et de développement du personnel informatique. Toute entreprise informatique sérieuse, visant à former et à développer des ressources humaines, et pas seulement à « traire » les chantiers, rencontre tôt ou un peu plus tard le besoin d'interagir avec les établissements d'enseignement. Pour le personnel informatique hautement qualifié, il s'agit d'un segment d'universités, et les meilleures d'entre elles, du moins celles du classement TOP-100.
Le problème de l'intégration avec les universités lors de la construction d'un processus continu de formation de spécialistes en informatique est dû à environ la moitié du manque de compréhension des universités sur qui est qui au sein de l'entreprise informatique. Ils en ont une compréhension très superficielle. En règle générale, les universités ont plusieurs spécialités avec le mot « informatique » dans leur nom, et il arrive souvent que lorsqu'elles mènent une campagne d'admission, elles s'appuient sur la thèse selon laquelle toutes les spécialités portent essentiellement sur la même chose. Et cela revient à croire que nous nous appuyons sur le mythe populaire selon lequel tous les informaticiens sont des programmeurs.
L'expérience de notre étroite coopération avec les universités montre que la spécialité « Informatique appliquée (par industrie) » nous fournit du personnel pour les départements de méthodologie et de support technique, mais pas de développement. Tandis que « l'informatique fondamentale », le « génie logiciel » prépare une excellente ressource humaine pour les développeurs. Afin de ne pas orienter dans un premier temps le candidat sur une voie qui ne lui convient pas, il faut « dissiper le brouillard » qui entoure la production informatique.
Est-il possible de tout ramener à un dénominateur commun ?
Est-il possible d’unifier les rôles de production et d’en arriver à une compréhension commune à l’intérieur et à l’extérieur de l’entreprise ?
Bien sûr, cela est possible et nécessaire, car l'expérience collective accumulée de toutes les entreprises de développement démontre la présence de concepts communs et fédérateurs pour organiser le processus de production. Ceci est une conséquence du fait qu'il existe encore une conception unique du cycle de vie du logiciel et que les nouveaux rôles de production émergents (DataScientist, QA-Engineer, MachineLearning Engineer, etc.) sont une conséquence de la clarification et du développement du cycle de vie du logiciel en tant que tel, s'accompagnant de l'amélioration des technologies et des outils, ainsi que du développement et de l'élargissement des tâches métier.
Dans le même temps, il est difficile d’unifier les rôles de production, car l’informatique est l’un des secteurs de l’économie les plus jeunes et à la croissance la plus rapide. Dans un sens, c’est le chaos dont l’univers a émergé. Une structure organisationnelle claire est impossible et inappropriée ici, car l'informatique est un domaine intellectuel mais très créatif. D'une part, un informaticien est un « physicien »-intellectuel doté d'une pensée algorithmique et mathématique développée, d'autre part, il est un « parolier »-créateur, porteur et promoteur d'idées. Lui, tout comme l'artiste, n'a pas de plan clair pour peindre, il ne peut pas décomposer l'image en parties, puisque cette dernière cessera d'exister. Il est le maître des processus d’information, qui sont en eux-mêmes abstraits, intangibles, difficiles à mesurer, mais rapides.
Façons de créer un travail de personnel efficace dans la production informatique
Alors, ce qu'il est important de savoir pour un spécialiste RH afin de construire un travail RH efficace dans le contexte de la diversité des rôles de production informatique.
Tout d'abord, tout spécialiste RH d'une entreprise informatique doit avoir une idée de la situation typique spécifiquement de son entreprise : qui fait quoi, qui s'appelle quoi, et surtout, quel est le sens de ces rôles dans les conditions de une production particulière.
Deuxièmement, le professionnel des ressources humaines doit avoir une compréhension flexible des rôles de production. C'est-à-dire qu'au départ, il en forme une compréhension idéale, ce qui lui permet de tout comprendre par lui-même. Ensuite, il doit y avoir une véritable image de la production : où et de quelles manières les rôles se croisent et se combinent, quelle perception de ces rôles existe parmi les directeurs de production. La difficulté pour un spécialiste du personnel est de combiner mentalement les situations réelles et idéales, non pas pour essayer de reconstruire avec force les processus en fonction de leur compréhension idéale, mais pour aider la production à répondre aux besoins en ressources.
Troisièmement, vous devez absolument avoir une idée des trajectoires de développement possibles de certains spécialistes : dans quels cas la sélection externe peut être efficace, et quand est-il préférable de faire grandir un salarié dans votre équipe, en lui offrant des opportunités d'évolution, quelles qualités des candidats leur permettra d'évoluer dans une direction particulière, qualités qui ne peuvent être compatibles chez une seule personne, ce qui est initialement important pour choisir une trajectoire de développement.
Quatrièmement, revenons à la thèse selon laquelle l'informatique est un domaine de personnel hautement qualifié, où une intégration précoce dans l'environnement éducatif universitaire est inévitable pour un travail du personnel plus efficace. Dans cette situation, chaque spécialiste RH doit développer non seulement les compétences de recherche directe, de travail avec des questionnaires et des entretiens, mais également s'assurer de naviguer dans l'environnement de formation universitaire de spécialistes : quelles universités préparent le personnel pour l'entreprise, quelles spécialités au sein d'universités spécifiques couvrir les besoins en personnel, et quoi Il est important de savoir qui est derrière cela, qui gère et forme les spécialistes dans les universités.
Ainsi, si nous démystifions délibérément le mythe selon lequel tous les informaticiens sont des programmeurs, il est nécessaire de faire un certain nombre de pas dans cette direction et d'accorder une attention particulière à nos universités, où sont posées les bases de la perception du futur métier. En d’autres termes, nous avons besoin d’une interaction constante avec l’environnement éducatif, par exemple en utilisant le format moderne de collaboration dans les centres de coworking, les « points d’ébullition » et la participation à des activités éducatives intensives. Cela contribuera à détruire les idées fausses sur l'entreprise informatique, à accroître l'efficacité du travail du personnel et à créer les conditions d'activités conjointes dans la formation de divers spécialistes de notre secteur.
J'exprime ma gratitude aux collègues qui ont participé à la préparation et ont soutenu la pertinence de cet article : Valentina Vershinina et Yuri Krupin.
Source: habr.com