À l’étape actuelle du développement industriel du logiciel, on peut observer une diversité de rôles de production. Leur nombre augmente, la classification se complique chaque année et, bien sûr, les processus de sélection de spécialistes et de gestion des ressources humaines deviennent également plus complexes. Les technologies de l'information (TI) représentent un domaine de ressources humaines hautement qualifiées et de pénurie de main-d'œuvre. Ici, le processus de développement des talents et la nécessité d'un travail planifié avec le potentiel humain s'avèrent souvent beaucoup plus efficaces que le simple recrutement via les ressources Internet.
Cet article aborde des questions pertinentes pour les spécialistes des ressources humaines dans les entreprises de TI : les relations de cause à effet dans l'évolution des rôles de production, les conséquences d'une mauvaise interprétation des contenus des rôles pour le travail des ressources humaines dans son ensemble, ainsi que des options potentielles pour améliorer l'efficacité du processus de sélection des spécialistes.
La production TI pour les non-initiés
Qui est qui dans le secteur IT – ce sujet suscite des discussions sur différentes plateformes. Il existe depuis aussi longtemps que l'industrie IT elle-même, c'est-à-dire depuis l'apparition des premières entreprises de développement de logiciels sur le marché des consommateurs au début des années 90. Cela fait aussi longtemps qu'il n'y a pas de vision unique sur cette question, ce qui crée des difficultés et réduit l'efficacité du travail des ressources humaines. Essayons d'y voir plus clair.
Pour moi, le sujet des rôles de production dans le domaine des TI est devenu pertinent et intéressant depuis mon arrivée dans une entreprise de TI. J'ai passé beaucoup de temps et d'énergie à comprendre le processus de production. Ces efforts ont dépassé mes attentes et les coûts d'adaptation aux processus dans d'autres domaines : l'éducation, la production matérielle, les petites entreprises. J'avais conscience que les processus étaient complexes et inhabituels, car, en général, l'homme est plus adapté au monde matériel qu'au monde virtuel. Mais il y avait une résistance intuitive : il semblait qu'il y avait quelque chose de pas normal ici. Le processus d'adaptation a probablement duré un an, ce qui, à mes yeux, est simplement une durée astronomique. Au final, j'ai acquis une vision suffisamment claire des rôles clés dans la production IT.
Actuellement, je continue à travailler sur ce sujet, mais à un niveau différent. En tant que responsable du centre de développement d'une entreprise IT, je suis souvent en contact avec des étudiants, des enseignants d'universités, des candidats, des lycéens et d'autres personnes souhaitant participer à la création d'un produit IT afin de promouvoir la marque de l'employeur sur le marché du travail d'un nouveau territoire (Ville de Yaroslavl). Cette communication n'est pas facile en raison du faible niveau de connaissance des interlocuteurs sur l'organisation du processus de développement de logiciels (DL), et par conséquent, de leur incompréhension du sujet de la conversation. Après 5 à 10 minutes de dialogue, on cesse de recevoir des retours et l'on commence à se sentir comme un étranger dont le discours nécessite une traduction. En général, parmi les interlocuteurs, il y a toujours quelqu'un qui tire une conclusion dans le dialogue et évoque le mythe populaire des années 90 : « De toute façon, tous les informaticiens sont des programmeurs ». Les sources de ce mythe sont les suivantes :
- L'industrie IT se développe rapidement, dans ce contexte, tous les sens et principes fondamentaux sont en cours de formation ;
- Dans des conditions d'incertitude, il est difficile d'exister, donc les gens essaient de faciliter leur compréhension de l'inconnu en créant des mythes ;
- L'homme est plus habitué à percevoir le monde matériel plutôt que virtuel, c'est pourquoi il lui est difficile de définir des concepts qui dépassent ses perceptions.
Les tentatives de lutte contre ce mythe ressemblent parfois à un combat contre des moulins à vent, car il y a plusieurs aspects du problème qui nécessitent d'être abordés. Un spécialiste des ressources humaines doit d'abord avoir une image claire des rôles de production dans une entreprise IT, à la fois dans leur idéal et dans leur réalité; deuxièmement, comprendre comment et quand il peut être le plus efficacement utilisé les ressources internes de l'entreprise, et troisièmement, quelles méthodes concrètes aideront à sensibiliser les participants du marché du travail et favoriseront le développement de la marque de l'employeur. Examinons ces aspects plus en détail.
Le cycle de vie des logiciels comme fondement des rôles de production
Il n'est pas secret que, dans l'ensemble, tous les rôles de production dans une entreprise informatique ont pour origine le cycle de vie du logiciel. Par conséquent, si l'on souhaite convenir d'une approche commune sur cette question dans l'ensemble du secteur informatique, il convient de se baser précisément sur le cycle de vie du logiciel comme une base de sens acceptée et comprise par tous. La discussion des options concrètes de mise en œuvre des rôles de production repose sur notre rapport créatif au cycle de vie du logiciel.
Examinons donc les étapes comprises dans le cycle de vie du logiciel, en prenant comme exemple la méthodologie RUP. Ce sont des maillons suffisamment établis en ce qui concerne le contenu et la terminologie. Le processus de production commence toujours et partout par la modélisation des affaires et la formation des exigences, et se termine (de manière conditionnelle, bien sûr) par le conseil aux utilisateurs et les améliorations du logiciel basées sur les « désirs » des utilisateurs.
Si l'on fait un retour historique à la fin du siècle dernier (comme on le sait, c'était une période d'« automatisation en silos »), on peut constater que l'ensemble du processus de création de logiciel était pris en charge par un programmeur-développeur. C'est ici que résident les racines du mythe selon lequel chaque informaticien est un programmeur.
Avec la complexification des processus de production, l'émergence de plateformes intégrées et le passage à l'automatisation intégrale des domaines d'application, le réingénierie des processus d'affaires rend inévitable l'apparition de rôles spécialisés, liés aux étapes du cycle de vie. C'est ainsi que l'analyste, le testeur et le spécialiste du support technique font leur apparition.
La diversité des postes à travers le rôle de l'analyste
L'analyste (également appelé ingénieur analyste, redacteur de spécifications, méthodologue, analyste métier, analyste système, etc.) aide à "mettre en relation" les problématiques commerciales et les technologies nécessaires à leur mise en œuvre. La description des besoins pour le développeur peut être considérée comme la fonction principale d'un analyste abstrait. Il sert de lien entre le client et le développeur dans les processus de formation des exigences, d'analyse et de conception logicielle. Dans des conditions de production réelles, la liste des fonctions de l'analyste dépend de l'organisation de la production, des qualifications du spécialiste et de la spécificité du domaine modélisé.
Une partie des analystes est plus proche du client. Ce sont les analystes métier (Business Analyst). Ils comprennent en profondeur les processus commerciaux du domaine et sont eux-mêmes des experts des processus à automatiser. Il est très important d'avoir de tels spécialistes au sein de l'entreprise, notamment lors de l'automatisation de domaines méthodologiquement complexes. En particulier, pour nous, en tant qu'automaticiens du processus budgétaire de l'État, il est indispensable que parmi les analystes se trouvent des experts en la matière. Ce sont des employés hautement qualifiés, dotés d'une bonne formation économique et financière ainsi que d'une expérience dans les organes financiers, de préférence en tant que spécialistes principaux. L'expérience dans le domaine non-IT est d'une importance cruciale.
L'autre partie des analystes est plus proche des développeurs. Ce sont les analystes systèmes (System Analyst). Leur tâche principale est d'identifier, de systématiser et d'analyser les exigences du client pour déterminer leur faisabilité, ainsi que de préparer des cahiers des charges et de décrire les tâches. Ils comprennent non seulement les processus métier, mais aussi les technologies de l'information, connaissent bien les capacités du logiciel fourni au client, possèdent des compétences en conception et, par conséquent, savent comment mieux communiquer les intérêts du client au développeur. Ces employés doivent obligatoirement avoir une formation dans le domaine des TIC et un esprit technique, de préférence avec une expérience dans le secteur IT. Lors de la sélection de tels spécialistes, il sera clairement favorable d'avoir des compétences en conception avec l'utilisation d'outils modernes.
Une autre sorte d'analystes – les rédacteurs techniques (Technical Writer). Ils s'occupent de la documentation dans le cadre des processus de développement de logiciels, préparent des manuels d'utilisation et d'administration, des instructions techniques, des vidéos de formation, etc. Leur principale tâche est de transmettre aux utilisateurs et à d'autres parties intéressées des informations sur le fonctionnement du programme, de décrire des choses techniquement complexes de manière concise et claire. Les rédacteurs techniques, dans leur ensemble, maîtrisent parfaitement la langue française, tout en ayant une formation technique et un esprit analytique. Pour ces spécialistes, l'accent est mis sur la capacité à rédiger des textes techniques clairs, corrects et détaillés conformément aux normes, ainsi que sur la connaissance et la maîtrise des outils de documentation.
Ainsi, nous voyons un même rôle (et, d'ailleurs, un poste dans l'organigramme) – analyste, mais dans ses différentes incarnations concrètes et appliquées. La recherche de spécialistes pour chacun d'eux présente ses particularités. Il est important de savoir que ces types d'analystes doivent souvent posséder des compétences et des connaissances qui ne sont pas compatibles chez une seule et même personne. L'un est un humaniste, enclin à travailler analytiquement avec de grands volumes de documents textuels, avec un discours développé et une grande capacité à communiquer, l'autre est un « technicien » avec un esprit d'ingénieur et des intérêts dans le domaine des technologies de l'information.
Faut-il recruter de l'extérieur ou former en interne ?
Pour un grand acteur de l'industrie informatique, l'efficacité du recrutement direct via des ressources Internet diminue à mesure que les projets se développent. Cela s'explique, notamment, par les raisons suivantes : il est impossible de s'adapter rapidement aux processus complexes au sein de l'entreprise, et la vitesse d'apprentissage des outils spécifiques est inférieure à celle du développement du projet. Par conséquent, il est essentiel pour le spécialiste RH de savoir non seulement qui rechercher à l'extérieur, mais aussi comment mobiliser les ressources internes de l'entreprise, à partir de qui et comment faire grandir un spécialiste.
Pour les analystes commerciaux, il est essentiel d'avoir une expérience concrète dans les processus réels du domaine, c'est pourquoi leur recrutement « de l'extérieur » est plus efficace que leur développement interne dans l'entreprise. Dans ce contexte, il est important pour le spécialiste RH de connaître la liste des organisations pouvant être des sources de ce type de ressource humaine et de se concentrer sur la recherche de CV en provenance de ces dernières.
Pour des postes tels qu'analyste système ou architecte logiciel, en revanche, le processus de préparation des employés en interne a une immense importance. Ces spécialistes doivent être formés dans le contexte d'un environnement de production actif et en fonction des spécificités de l'organisation concernée. Les analystes systèmes se développent à partir des analystes d'affaires, des rédacteurs techniques et des ingénieurs de support technique. Les architectes logiciels émanent des concepteurs système et des développeurs logiciels au fur et à mesure qu'ils acquièrent de l'expérience et élargissent leurs horizons. Cette situation permet au spécialiste RH d'utiliser efficacement les ressources internes de l'entreprise.
Intersection, fusion et évolution des rôles de production
Il y a également une question délicate concernant l'établissement de limites claires entre les rôles dans le processus de production. À première vue, il peut sembler que tout soit évident : l'implémentation est terminée, les documents de mise en service du logiciel sont signés et tout est transféré au support technique. C'est exact, cependant, des situations se présentent souvent où le client, habitué à rester en contact étroit avec l'analyste et le voyant comme une « béquille », continue d'interagir activement avec lui, même après que le système a été mis en œuvre et que l'étape de soutien est formellement en cours. Du point de vue du client, qui peut répondre mieux et plus rapidement que l'analyste ayant aidé à définir la tâche ? C'est ici qu'émerge la question du chevauchement partiel des rôles de l'ingénieur de support technique et de l'analyste. Avec le temps, tout se stabilise ; le client s'habitue à communiquer avec le support technique, mais au début de l'exploitation du logiciel, cette transition « interne » n'est pas toujours réalisable sans stress des deux côtés.
Le chevauchement des rôles d'analyste et d'ingénieur de support technique se produit également lorsque le flux des exigences de développement se situe dans le cadre de l'étape de maintenance. En revenant au cycle de vie des logiciels, nous constatons un décalage entre les conditions réelles de production et les directives formelles selon lesquelles l'analyse des exigences et la formulation des tâches ne peuvent être effectuées que par un analyste. Un spécialiste des ressources humaines doit sans aucun doute comprendre le tableau idéal des rôles dans le cadre du cycle de vie des logiciels, qui ont des frontières bien définies. Cependant, il est tout aussi important de garder à l'esprit qu'un chevauchement est possible. Lors de l'évaluation des connaissances et des compétences d'un candidat, il convient de prêter attention à l'expérience connexe ; ainsi, lors de la recherche d'ingénieurs de support technique, des candidats ayant une expérience d'analyste peuvent tout à fait être envisagés, et vice versa.
En plus du chevauchement, on observe souvent une fusion des rôles industriels. Par exemple, un analyste commercial et un rédacteur technique peuvent exister en une seule personne. La présence d'un architecte logiciel (Software Architect) est essentielle dans le développement industriel à grande échelle, tandis que des projets très petits peuvent se passer de ce rôle : là, les développeurs (Software Developer) assument les fonctions de l'architecte.
Le changement des périodes historiques dans les approches et les technologies de développement conduit inévitablement à une évolution du cycle de vie des logiciels. Globalement, bien sûr, les principales étapes restent inchangées, mais elles se détaillent. Par exemple, avec le passage aux solutions Web et l'augmentation des possibilités de configuration à distance, le rôle d'un spécialiste de la configuration logicielle a vu le jour. À un stade historique précoce, ces rôles étaient remplis par des implantateurs, c'est-à-dire des ingénieurs qui passaient la majeure partie de leur temps de travail chez les clients. L'augmentation des volumes et de la complexité des logiciels a conduit à l'émergence du rôle d'architecte logiciel (Software Architect). Les exigences d'accélération des versions et d'amélioration de la qualité des logiciels ont favorisé le développement des tests automatisés et l'émergence d'un nouveau rôle – celui d'ingénieur en assurance qualité (Quality Assurance Engineer), etc. L'évolution des rôles à toutes les étapes de l'organisation du processus de production est étroitement liée au développement des méthodes, des technologies et des outils.
Nous avons examiné certains points intéressants concernant la répartition des rôles de production au sein d'une entreprise de développement de logiciels dans le contexte du cycle de vie des logiciels. Il est évident que cela représente un point de vue interne, spécifique à chaque entreprise. Pour nous tous, en tant qu'acteurs du marché du travail dans le secteur IT et responsables de la promotion de la marque employeur, un point de vue externe est particulièrement important. Et ici, il existe un grand problème, non seulement en termes de recherche de significations, mais aussi dans la transmission de cette information au public cible.
Qu'est-ce qui ne va pas avec le « zoo » des postes IT ?
La confusion dans l'esprit des spécialistes des ressources humaines, des organisateurs de production et la diversité des approches conduisent à une grande variété, véritablement un « zoo » des postes IT. L'expérience des entretiens et des contacts professionnels montre que les gens n'ont souvent pas une compréhension claire de la charge sémantique qui devrait découler des titres de poste. Par exemple, dans notre organisation, les postes incluant le terme « ingénieur analyste » sous-entendent qu'il s'agit d'un rédacteur de cahier des charges. Cependant, il s'avère que ce n'est pas nécessairement le cas partout : certaines entreprises de développement considèrent l'ingénieur analyste comme un intégrateur. Ce sont des interprétations complètement différentes, n'est-ce pas ?
Tout d'abord, le « zoo » des postes IT réduit indéniablement l'efficacité du recrutement. Chaque employeur, dans le développement et la promotion de sa marque, souhaite transmettre clairement tous les sens qui existent dans sa production. Et si lui-même ne peut souvent pas clairement dire qui est qui, il est naturel qu'il transmette à l'extérieur une certaine incertitude.
Deuxièmement, le « zoo » des postes IT crée d'énormes problèmes dans la préparation et le développement des talents IT. Chaque grande entreprise IT, désireuse de former et de développer son potentiel humain, plutôt que de simplement exploiter les sites d'emploi, se trouve tôt ou tard confrontée à la nécessité de collaborer avec des établissements d'enseignement. Pour les professionnels IT hautement qualifiés, cela concerne les universités, en particulier celles qui figurent dans le classement des meilleures.
Le problème de l'intégration avec les universités dans l'établissement d'un processus continu de formation des spécialistes en informatique repose en partie sur l'absence de compréhension de la part des universités concernant les rôles au sein des entreprises IT. Leur compréhension est très superficielle. En général, les universités ont plusieurs spécialités avec le mot « informatique » dans leurs titres, et souvent, lors de leurs campagnes d'admission, elles fondent leur argumentation sur l'idée que toutes ces spécialités traitent essentiellement du même sujet. Cela ressemble à l'idée reçue selon laquelle tous les informaticiens sont des programmeurs.
L'expérience de notre collaboration étroite avec les universités montre que la spécialité « Informatique appliquée (par secteurs) » nous fournit des personnels pour les départements de méthodologie et de support technique, mais pas du tout pour le développement. En revanche, « Informatique fondamentale » et « Génie logiciel » préparent d'excellentes ressources humaines pour les développeurs. Pour éviter de diriger un étudiant vers une voie inadaptée, il est nécessaire de « dissiper le brouillard » qui entoure la production informatique.
Peut-on ramener tout cela à un dénominateur commun ?
Peut-on unifier les rôles de production et parvenir à une compréhension unique de ceux-ci, tant à l'intérieur qu'à l'extérieur de l'entreprise ?
Bien sûr, c'est possible et nécessaire, car l'expérience collective accumulée par toutes les entreprises de développement montre l'existence de concepts communs unifiant l'organisation du processus de production. C'est le résultat du fait qu'il existe un concept du cycle de vie des logiciels qui est unanimement interprété, et les nouveaux rôles de production (Data Scientist, QA Engineer, Machine Learning Engineer, etc.) sont le résultat de l'affinement et du développement du cycle de vie des logiciels tel qu'il est, en cours d'évolution avec l'amélioration des technologies et des outils, ainsi qu'avec le développement et l'expansion des tâches commerciales.
Il est difficile d'unifier les rôles de production, car l'informatique est l'une des industries les plus jeunes et en pleine expansion de l'économie. En un sens, c'est le chaos d'où est née l'univers. Une structure organisationnelle claire est ici impossible et inappropriée, car l'informatique est un domaine intellectuel mais très créatif. D'un côté, un informaticien est un « physicien » intellectuel avec une pensée algorithmique et mathématique développée, et de l'autre, un « poète » créateur, porteur et promoteur d'idées. Tout comme un artiste, il n'a pas de plan clair pour peindre son tableau, il ne peut pas décomposer une image en parties, car elle cesserait d'exister. Il est le maître des processus d'information, qui sont en eux-mêmes abstraits, intangibles, difficilement mesurables, mais rapides.
Les voies pour construire un travail efficace des ressources humaines dans la production informatique
Alors, que doit savoir un spécialiste des ressources humaines pour établir un travail efficace des ressources humaines dans un environnement de diversité des rôles de production informatique ?
Tout d'abord, tout spécialiste des ressources humaines dans une entreprise informatique doit avoir une idée de la situation qui caractérise précisément son entreprise : qui fait quoi, qui est appelé comment, et surtout, quelle signification est attribuée à ces rôles dans le cadre de la production spécifique.
Ensuite, le spécialiste des ressources humaines doit avoir une représentation flexible des rôles de production. C'est-à-dire qu'il doit d'abord se forger une compréhension parfaite de ces rôles, ce qui lui permettra de se débrouiller seul. Ensuite, il doit y avoir une image réelle de la production : où et comment les rôles se croisent, s'unissent, quelle perception de ces rôles existe chez les responsables de production. La complexité pour le spécialiste des ressources humaines réside dans la capacité à concilier dans son esprit la situation réelle et l'idéale, sans tenter de reconstruire de force les processus selon leur compréhension idéale, mais en aidant la production à répondre à ses besoins en ressources.
Troisièmement, il est essentiel d'avoir une idée des trajectoires possibles de développement des spécialistes : dans quelles situations le recrutement extérieur peut être efficace, et quand il est préférable de faire croître un collaborateur au sein de son équipe en lui offrant des opportunités de développement, quelles qualités des candidats leur permettront d'évoluer dans une direction spécifique, et lesquelles ne peuvent pas être compatibles au sein d'une même personne, ce qui est initialement important pour le choix de la trajectoire de développement.
Quatrièmement, revenons à l'énoncé selon lequel l'IT est un domaine de haute qualification, où pour un travail plus efficace en matière de ressources humaines, l'intégration précoce avec le milieu éducatif universitaire est inévitable. Dans cette situation, chaque spécialiste RH doit développer non seulement des compétences en recherche directe, en gestion des candidatures et en entretiens, mais il doit également se familiariser avec l'environnement de formation universitaire : quelles universités préparent des professionnels pour l'entreprise, quelles spécialités dans des universités spécifiques répondent aux besoins en personnel, et, ce qui est important, qui est responsable de cette formation, qui dirige et effectue la préparation des spécialistes dans ces établissements.
Ainsi, pour déconstruire de manière ciblée le mythe selon lequel tous les informaticiens sont des programmeurs, il est nécessaire de franchir toute une série d'étapes dans cette direction et de prêter une attention particulière à nos universités, où les bases de la perception de la future profession sont établies. En d'autres termes, un contact constant avec l'environnement éducatif est requis, par exemple, en utilisant des formats modernes de collaboration dans des espaces de coworking, des « points de fusion », et en participant à des intensifs éducatifs. Cela permettra de briser les idées fausses sur l'entreprise IT, d'améliorer l'efficacité du travail en ressources humaines et de créer un cadre pour la collaboration dans la préparation de différents spécialistes de notre secteur.
Je tiens à remercier mes collègues qui ont participé à la préparation et au maintien de la pertinence de cet article : Valentina Vershinina et Yuri Krupin.
Source : habr.com
