Parcours d'un 'nouvel arrivant'

Introduction

Après quelques années de vie active et un parcours qui m’a mené des laboratoires au développement informatique et quelques mois chez mon client, j’ai constaté des manques fréquents au sein des projets relatifs à la prise en charge des « nouveaux arrivants » :

• Une présentation simple et synthétique du « métier »
• Inexistence d’une présentation fonctionnelle simple du projet.
• Manque de documentation claire sur les différents environnements de travail.
• Un guide d’installation du poste de travail réellement exhaustif.
• Une présentation claire de l’application et de son architecture
• Un lexique des sigles utilisés dans le milieu.

Ceci semble être un syndrome répandu et est probablement lié à la volatilité du statut de nouveau, qui ne perdure pas par rapport au statut d’ancien. Dans un premier temps nous allons essayer de décrire comment se manifestent ces manques, et dans un second temps nous intéresser aux actions à mener pour y remédier.

Les écueils

L’accueil

La première journée d’un nouvel arrivant est généralement marquante pour celui qui arrive. De même qu’on se fait une idée de la personne à qui on a affaire en quelques secondes, ces premières heures vont construire l’image que l’on se fait du projet sur lequel on arrive. Un nouvel arrivant a besoin d’un accueil chaleureux (cela va de soi) mais aussi d’un ordinateur, de licences logicielles, de droits d’accès à des outils (JIRA, Gitlab, ressources client).

Cette première journée devrait être un succès pour faire bonne impression au “nouveau”, mais la préparation de cette journée est généralement incomplète. Le plus surprenant dans ceci est que le même dialogue semble avoir lieu pour chaque nouvel arrivant :

“Qu’est-ce qu’on a besoin de faire pour les nouveaux ?” “Je ne sais pas, demande à untel (généralement le précédent nouvel arrivant) ?”

L’obtention de l’ensemble des outils matériels, accès et licences est souvent longue et coûteuse, tant pour le nouveau que pour les acteurs du projet. Mon expérience m’a montré que sur mon premier poste en informatique mon ordinateur n’était pas prêt et a mis 48h à m’être fourni, tandis que sur mon deuxième projet l’ordinateur était prêt mais a dû être formaté et réinstallé car l’image installée n’était pas bonne. L’obtention des accès à l’ensemble des ressources nécessaires a pris en tout et pour tout deux semaines.

Le métier

Quand on arrive sur un projet, le premier écueil que l’on rencontre est bien entendu ce qu’on appelle le « métier ». D’une banque à un opérateur téléphonique il existe une ribambelle de métiers, mais on évoque toujours LE métier. Alors, c’est quoi LE métier ??? Le métier c’est tout ce qui gravite autour d’une activité (dans le cas des développeurs tout ce qui gravite autour d’une application), mais cette idée est un peu abstraite, et difficile à saisir sans un minimum d’explications. On pourrait dire que le métier regroupe les éléments suivants (parmi d’autres, loin de moi la prétention d’être exhaustif) :

• Contexte d’utilisation de l’application (secteur d’activité, activité en elle-même, corps de métier)
• Contexte des utilisateurs de l’application (qui, pourquoi faire, qui peut faire quoi, comment)

A mon sens, la meilleure manière d’aborder une activité c’est de la décrire, de la schématiser pour la rendre palpable au « technicien » qui va ensuite coder une application adaptée à ce métier. Une bonne manière d’aborder le « métier » ou d’approfondir ses connaissances à son propos est également de discuter avec les « anciens », qui par le temps passé sur un projet connaissent généralement bien le contexte métier.

Présentation fonctionnelle

Lorsqu’on intègre une nouvelle équipe, l’une des étapes essentielle est d’aller se « promener » dans l’application sur laquelle on interviendra par la suite. C’est un exercice intéressant, à condition d’être passé avant par une étape de présentation fonctionnelle sur les éléments suivants :

• Les entités manipulées (des commandes, des échantillons, des stocks) ?
• Qui les manipule (des commerciaux, des techniciens de laboratoire, des responsables) ?
• Pourquoi ils les manipulent (réaliser des expéditions, un diagnostic immobilier) ?
• Quelles sont les opérations que l’on peut effectuer sur ces entités (réception, enregistrement, traitement, envoi de résultats) ?

Environnements de travail

Les environnements de travail à proprement parler (développement, intégration, qualification interne, qualification client) sont rarement présentés de manière claire. Poser la même question à 3 personnes travaillant sur le même projet aboutit généralement à 3 réponses différentes, il est donc nécessaire de fixer les choses. Ceci complexifie particulièrement l’arrivée sur un nouveau projet et peut mener à des incompréhensions qui ne sont levées qu’au prix de nombreuses interrogations auprès de son équipe ou de prises de tête sans fin. Le projet sur lequel je travaille actuellement compte donc 6 environnements :

• 3 dans le cloud :
  • Intégration
  • Qualification interne
  • Qualification client
• 3 hors cloud :
  • Intégration
  • Qualification interne
  • Qualification client

A force de faire des tests sur un environnement puis un autre, puis encore un autre, hors cloud puis dans le cloud, puis encore ailleurs, autant dire qu’il m’a fallu plusieurs semaines avant de m’y retrouver et trouver une solution durable.

Installation du poste de travail

Une fois la documentation du projet parcourue vient le moment d’installer son poste de travail. Par « installer » j’entends installer les logiciels de développement nécessaires, modifier la configuration de son ordinateur, et demander les accès aux ressources nécessaires (boards, Gitlab, bases de données, proxy etc.). Dans les cas les plus simples cette étape prend un à deux jours, dans ce cas tout ne dépend que de toi et tu n’as pas à faire appel à des acteurs extérieurs. Dans d’autres cas, cette étape peut durer une semaine voire plus. Comment limiter le temps perdu lors de cette phase ?

Une application / 30 sous-projets

Une application est généralement constituée de nombreuses briques applicatives et lorsqu’on arrive sur un nouveau projet on se sent vite perdu face à l’immensité de l’application. Comment éclaircir le fonctionnement interne d’une application sans entrer dans les détails ?

Le jargon

Comme tout métier a son jargon, chaque projet a ses propres acronymes, ses abréviations, ses spécificités. Comme toute langue dispose d’un dictionnaire, pourquoi ne pas disposer d’un lexique pour éclaircir les propos de chacun et éviter de provoquer une avalanche de questions à chaque phrase ?

Les solutions

Accueil

Fournir avant l’arrivée sur un projet le programme de la première journée, le nom de son interlocuteur, le lieu et l’heure du rendez-vous permettra pour le nouveau d’arriver détendu et confiant.

Une documentation à destination des nouveaux arrivants est indispensable, et constitue un bon moyen de fixer les étapes de l’arrivée d’un nouvel arrivant (à moins que la documentation ne soit plus à jour depuis longtemps et comporte des outils qui ne sont plus utilisés depuis longtemps). Une procédure connue de tous et enrichie régulièrement permettra une arrivée fluide sur le poste et sans stress.

Une fiche d’installation de poste n’est utile que si elle est exhaustive et si elle se suffit à elle-même. Sinon, elle n’est qu’un support parmi d’autres et ses insuffisances prennent le pas sur son utilité. Les bugs rencontrés par les derniers arrivants peuvent être répertoriés avec les solutions trouvées.

Les délais de traitement des demandes peuvent également être renseignés afin de coordonner les demandes faites auprès des différents services de l’entreprise.

On pourra structurer le document ainsi :

• matériel (ordinateur, câble de sécurité, souris, clavier, casque)
• logiciels (VS Code, Postman, Java, Node, Git)
• licences (Office, Visual Studio, Gitlab)
• comptes AD (groupes liés à l’équipe)
• accès (emplacements réseau, accès aux ressources client, VPN)
• favoris à importer avec les liens vers : - les boards JIRA - les URLs des applications par environnement - URL Gitlab du projet - les liens utiles vers la documentation JIRA - lien direct vers la fiche d’installation de poste

Une fiche d’installation de poste doit être exhaustive et doit indiquer quels logiciels installer, si les sources sont sur le réseau (et dans ce cas où les trouver) ou à récupérer sur le net. Dans l’idéal un poste de développeur devrait être installé à partir d’une image disque comportant les logiciels nécessaires à la prise de poste au sein de l’équipe et nécessiter un minimum de configuration.

Présenter le métier

En reprenant l’exemple de mon précédent contexte professionnel, on peut présenter rapidement l’activité amiante d’un laboratoire comme suit :

Description d’un contexte applicatif, de son contexte métier, des acteurs concernés

En une image on aura décrit dans son ensemble le processus dans lequel s’inscrit l’activité et le cheminement des entités que l’on manipule (ici des échantillons). Lors de sa création cette image pourra être validée ou modifiée par les connaisseurs du domaine d’activité. Une fois construite, elle pourra être enrichie et servir de support afin d’expliquer le domaine d’activité dans lequel on s’inscrit, comment on intervient et auprès de quels acteurs/utilisateurs. Dans la pratique, même si on peut décrire précisément chaque étape mais ce n’est pas le but ici, on reste dans la présentation d’un contexte de travail.

Présenter le contexte fonctionnel

Créer avec les acteurs du projet une page de description de l’application, du contexte métier aux principales fonctionnalités. Pas besoin d’en faire des tonnes, quelques phrases agrémentées de quelques schémas et on aura déjà fait un tour d’horizon non-négligeable. Une étape de relecture permettra d’éliminer les erreurs ou incohérences possibles. Par ailleurs les intervenants gravitant autour du projet seront incités à apporter des précisions en cas de changement ou s’ils identifient des manques.

Au-delà du projet lui-même, une présentation claire de l’ensemble des projets quand on intègre une équipe d’une vingtaine de personnes permet également de mieux intégrer une équipe, d’avoir une idée claire du contexte dans lequel elle évolue. Cela évitera les milliers de questions qui peuvent émerger face à des conversations incompréhensibles pour le commun des mortels et de réaliser après quelques mois seulement qu’on n’a aucune idée du contexte global de l’équipe dans laquelle on évolue.

Des environnements de travail clairs

De même que pour décrire une application, quelques schémas suffisent, pour présenter les environnements de travail ainsi que leurs interactions avec les bases de données ou les serveurs associés. Le mieux quand le contexte de l’application le permet, une page d’accès (type page web) séparant les différents environnements de manière claire et univoque.

Si elle n’existe pas elle peut être créée simplement sur un outil comme Jira avec quelques liens intégrés, ou bien dans mon cas, la création d’une page html simple qui renvoie directement sur les environnements concernés sans aucune ambiguïté.

Une cartographie visuelle permettra de mettre au clair une bonne fois pour toutes quels sont les environnements sur lesquels vous êtes amenés à travailler et vous ne serez plus confrontés au dilemme amené par deux interlocuteurs vous indiquant le même endroit en vous disant « à gauche » pour l’un et « à droite » pour l’autre.

Installer le poste de travail

Comme un meuble d’une marque suédoise bien connue, tout projet nécessite des outils ET un mode d’emploi, sans quoi on ne peut rien faire, ou le faire mal. La réponse souvent apportée à ce manque de documentation est souvent « comme tu as rencontré ces difficultés, tu pourras les retracer dans la doc’ ». C’est compréhensible, mais lorsqu’on débarque sur un nouveau projet, on a malheureusement peu de temps pour le faire et quand on a du temps pour le faire on n’a plus les idées claires car le temps a passé.

Pour être plus efficace et précis n’hésitez pas à croiser vos sources, cela évitera de lever les incohérences. Prendre des notes quotidiennement permet de décharger son cerveau de toutes ces infos et donne la possibilité de les réunir ensuite pour les rendre digestes. Les partager à l’ensemble de l’équipe permet également de fluidifier les échanges et de gagner en efficience en limitant la perte de temps liée à la perte d’informations.

Une application / 30 sous-projets en une image

Une fois de plus, une image valant mieux qu’un long discours, une représentation graphique d’un projet permettra d’expliciter facilement la manière dont s’articule le projet. Un arrêt rapide sur l’architecture de l’application permettra d’éclaircir les idées et de mieux appréhender les eaux dans lesquelles on navigue. Dans le cas de mon projet actuel voici un schéma présentant l’ensemble des éléments du projet :

On comprendra ainsi mieux les rouages de l’application (et les discussions des collègues !) sans pour autant mettre les mains dans le cambouis.

Le jargon du milieu

Quelques acronymes reviennent régulièrement dans le jargon du développement, mais lorsqu’on ajoute un métier par-dessus cela il devient nécessaire pour la compréhension des collaborateurs d’expliciter ces acronymes. Un bon moyen d’éclaircir ces sigles incompréhensibles pour le commun des mortels est de créer une page (sur Jira par exemple ^^) de lexique où chaque acronyme sera explicité par une phrase succincte.

Conclusion

Un nouveau ça se chouchoute, et ça ne s’abandonne pas devant une montagne de démarches à faire, un nouveau ça se guide, sinon ça se perd et l’inconfort des débuts perdure et crée des entraves qui ne feront que se renforcer si l’on agit pas pour les combattre.

Quand il y a des demandes d’accès à réaliser en début de parcours, autant créer un document regroupant l’ensemble des demandes à effectuer avec les modèles de demandes et une identification claire des acteurs auprès desquels les faire. Ainsi, dès le premier jours les demandes seront effectuées et le nouveau sera opérationnel beaucoup plus vite que le précédent. Dans mon cas, nous sommes passés d’une dizaine de jours pour être totalement opérationnel à 2-3 jours pour les nouveaux arrivants arrivés plus récemment.

Le guidage est bien entendu essentiel pour accueillir les nouveaux, mais les nouveaux ont également un rôle primordial dans cette démarche. Charge aux développeurs suivants de perpétuer la tradition et d’améliorer l’arrivée sur un nouveau projets pour ceux qui leur succéderont. Quant à la forme sous laquelle le faire c’est votre affaire (et n’oubliez pas que le visuel est un outil très puissant).

Quel que soit le support que vous utiliserez, surtout, ne perdez pas de vue la simplicité que le propos doit conserver, cela le rendra d’autant plus percutant et efficace !