Qualités requises pour un informaticien ou une informaticienne

Un informaticien n’est pas uniquement celui qui tape du code derrière son écran, ou encore celui qui administre des centaines de serveurs Linux, ou encore celui qui est pro en bases de données. Un informaticien doit développer d’autres compétences que ses compétences techniques. Il doit être capable d’apprendre vite et de se mettre à jour côté technique, mais pas seulement.

Que doit-il connaître ? Comment doit-il se comporter ?

Je vois tous les jours des profils d’informaticiens fermés, enfermés dans leur techno, enfermés dans leur jargon. Je suis informaticienne, donc je les comprends à peu près mais que dire des personnes qui les entourent… Que dire de la personne côté MOA, ou encore, côté qualité, est-ce que cette personne comprend cet informaticien ? Est-ce que cette personne a envie d’aller vers cet informaticien ? Pas tant que ça.

J’ai envie de dire à ces informaticiens de développer d’autres qualités que leur technicité, d’autres qualités que leur ténacité, … Lesquelles me direz-vous ?

Une des qualités que doit avoir un informaticien est sans aucun doute l’ouverture. Il faut s’ouvrir aux autres, comprendre leur domaine, comprendre leurs besoins, comprendre leurs langages.

Il faut être capable de vulgariser ce qu’on fait. Perdre un interlocuteur au bout de 10 secondes de réunion n’est pas un but en soi, une victoire, un succès. Il faut au contraire se mettre à la place de notre interlocuteur et parler son langage. A quoi ça sert de parler technique si en face c’est silence radio. C’est bien beau de faire un monologue mais ce n’est pas comme ça qu’on fait avancer les choses. Ce n’est pas comme ça qu’on garde un projet ou qu’on en gagne un nouveau.

Ces soi-disant experts, ne le sont pas tant que ça. Ils sont experts dans leur bulle, dans leur cercle d’experts uniquement. Ils ne sont pas experts en communication. Quand vous lisez leurs mails, ils n’ont aucune structure. Ils se doivent d’être brefs et concis, clairs et pédagogues. C’est loin d’être le cas de certains.

Je ne dis pas que j’ai un bon relationnel, mais je fais des efforts, contrairement à la plupart d’entre eux.

Donc je lance un cri d’alarme, « Ô vous informaticiens, soyez de bons communicants, soyez pédagogues, soyez ouverts, un autre monde existe autour de vous, alors arrêtez avec votre jargon technique ! ».




mika

Entièrement d’accord avec toi.
Il ne faut pas oublier qu’il faut travailler AVEC la MOA, ce n’est pas une équipe à part qui spécifie/valide nos projets dans leur coin ce sont des collègues qui vont nous aider à fournir un travail de qualité aux utilisateurs.

Je dois avouer que j’ai pas mal évolué sur le sujet, j’étais avant plus dans les exemples négatifs que vous décrivez: de plus il y avait un peu de friction avec notre MOA (tant sur les spécifications que sur la qualité des tests)
Mais on a changé petit à petit le staff avec lequel on travaille, et une relation s’est initiée avec la nouvelle équipe: en déjeunant/passant de bons moment ensemble: on travaille plus naturellement ensemble
Au dev, on pense plus à la MOA qu’avant: je suis plus transparent sur mon travail pour bien expliquer/vulgariser les différentes briques pour qu’ils voient plus facilement les potentiels problèmes qu’ils pourraient y avoir.

Un autre exemple tout bête: les Test Unitaires
A la base c’est censé être uniquement coté dev, depuis peu, j’inclus la MOA, je montre mes tests unitaires et leur propose de me donner d’autre cas limites : ça entre dans un objectif simple: plus de test unitaire mieux cadré, le plus exhaustif possible, ça limite les retours de tests
Pour ceux qui connaissent: pyramide de tests (http://softmethods.fr/la-pyramide-de-tests/)

Et honnêtement, c’est plus simple de rajouter N tests unitaire (surtout avec les dataProvider) que de demander à la MOA de re-tester plusieurs fois un batch, une application avec N combinaison possibles
On travaille aussi avec eux pour voir comment simplifier les tests, les automatiser pour certains (selenium, batch de vérification..)

Mais la transparence n »est pas utile qu’avec la MOA, je me souviens que sur un ancien projet, les personnes spécifiant le besoin n’avait pas du tout idée de l’architecture du projet, ça donnait des demandes qui semblait simple dans leur esprit en réunion, et qui, à l’implémentation posait de gros soucis

Ça me fait penser à cette video: https://www.youtube.com/watch?v=vH0rhNx3dok
C’est drôle, mais c’est très proche de la réalité: plus on est transparent/communiquant, plus on peut arriver à mieux réfléchir/trouver des solutions ou déceler des soucis

Fatiha

Ton commentaire apporte beaucoup de précisions. Je t’en remercie.
Ta vidéo est tout simplement hiralante et très proche de la réalité !

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *