Pourquoi ne peut-on pas cloner les programmeurs IBM i comme on clone des moutons?

Pourquoi ne peut-on pas cloner les programmeurs IBM i comme on clone des moutons?

12:00 01 mai dans Blogue, Productivité des développeurs IBM i, Ressources, personnel, formation et expertise, Services Applications
0 Commentaires

blogpic2Quand j’ai vu que des chercheurs avaient réussi à cloner un mouton, j’ai immédiatement pensé : « Si c’était possible de cloner les développeurs IBM i, on n’aurait plus aucun problème! » Le bassin existant de développeurs s’amenuise rapidement, et lorsqu’il ne reste qu’une poignée de développeurs RPG ou COBOL, la perspective d’en remplacer un est décourageante. Bon, je n’ai pas encore réussi à en cloner, mais j’ai trouvé une solution au problème de dotation pour les projets de nos clients.

Commençons par imaginer une situation où, alors que vous avez besoin d’une ressource de confiance en particulier pour un projet spécial, la personne annonce qu’elle prend sa retraite – ou encore qu’elle a gagné à la loterie et qu’elle quitte l’entreprise (ça revient au même!). Qu’importe, vous avez maintenant deux problèmes : trouver un remplacement, et intégrer cette nouvelle ressource. À ce stade, vous vous tapez sur les doigts de ne pas avoir anticipé la situation.

Pourquoi l’intégration est si pénible

L’intégration d’une ressource technique peut s’avérer coûteuse et perturbatrice, puisqu’elle nécessite une formation rapide et efficace qui demande souvent le temps et l’énergie de beaucoup de personnes, y compris d’autres précieuses ressources. À cela s’ajoute le fait que le nouvel employé peut vite perdre sa motivation lorsque le processus d’intégration est inefficace, et vous risquez d’obtenir tout… sauf le résultat escompté.

Avez-vous déjà vu ou vécu une formation où le développeur n’avait au départ qu’à se connecter à l’application et à fouiner dedans? Un tel processus repose sur l’apprentissage par essais et erreurs, qui peut être très stressant et ardu. Autrement dit, ce n’est pas l’idéal.

Imaginez maintenant que cette ressource nouvellement formée se décourage et quitte l’entreprise après six mois. Hélas, le processus pénible d’autoapprentissage est à recommencer. Le prochain développeur devra lui aussi se démener dans ce même processus rébarbatif. S’en sortira-t-il, ou partira-t-il lui aussi? Décidément, il doit bien exister un moyen d’intégrer des professionnels hautement spécialisés sans monopoliser d’autres employés ou utiliser des techniques inefficaces!

Comment faciliter l’intégration

Après avoir vu trop de nouveaux employés peiner à s’adapter à leur nouveau rôle, j’ai noté quelques idées pour rendre le processus plus simple :

  • À l’arrivée d’un nouveau développeur, surtout s’il a déjà de l’expérience, vous devez d’abord l’aider à se familiariser avec l’entreprise. Il devrait passer du temps avec chacune des grandes unités d’affaires pour comprendre leurs besoins et leurs difficultés au quotidien. Ce n’est qu’à ce moment qu’il pourra commencer à comprendre les applications.
  • Chaque système hérité est un organisme complexe qui a été personnalisé, ajusté, amélioré et réorganisé avec le temps pour répondre à des exigences et à des objectifs précis. C’est beaucoup de choses à savoir. Des connaissances qui ne servent à personne quand elles ne sont détenues que d’un développeur – à plus forte raison si celui-ci est déjà parti. Et les quelques documents rédigés il y a 10 ans? Tout aussi inutiles. La meilleure façon pour une nouvelle ressource de connaître le passé d’une application (et son avenir), c’est d’avoir accès à des documents tenus à jour par tous les développeurs qui y contribuent. Ainsi, si le nouveau développeur doit visualiser tous les détails de l’application et les interactions entre ses fichiers, son code, ses variables et ses règles opérationnelles, il pourra trouver toute cette information – ou presque – facilement.

 

Avec ces deux approches d’intégration simples, développeurs, clients et employeurs s’épargneront bien du temps, de l’argent et du stress. Évidemment, il existe d’autres moyens de rendre l’intégration et la formation encore plus efficaces (pensons par exemple au jumelage ou à une liste de vérification détaillée), mais si j’ai appris une chose de tous les maux de tête que m’ont donné mes tentatives de faire adopter des applications existantes aux nouveaux développeurs, c’est que ces deux étapes étaient les plus importantes.

Vous voulez en savoir plus sur nos solutions aux problèmes de ressources? Communiquez avec nous!

À propos de Robert Rheault

Robert Rheault joined Fresche in 2012 as the director of application services and is enjoying every minute of it. He is now VP of Application Services, thanks to the experience he gained working at IBM for 18 years. While at IBM, he worked in a variety of management and IBM i support roles. When he’s not working, he enjoys running and every kind of skiing – water, cross-country and downhill.

Pas de commentaires

Écrire un commentaire