Chères DSI,
Ne nous voilons pas la face, vous ne comprenez pas le travail des informaticiens. Cela peut paraître paradoxal mais avez-vous déjà programmé ? Savez-vous ce que coûtent réellement vos demandes ? Pas besoin, vous avez des outils de gestion.
Des vidéastes spécialisés ironisent sur le télétravail et les tickets Jira traités. La réalité ? Le propre d’un informaticien est d’automatiser le domaine de son employeur. Et il est normal qu’il cherche à automatiser son travail.
En sera-t-il récompensé, reconnu ? Non. Il sera traité de feignant car au lieu de taper frénétiquement sur son clavier et de finir à 20h, il se promène sur Internet et consulte des sites obscurs, nullement en relation avec l’entreprise.
S’il perd du temps en apparence, cela ne l’empêche pas de répondre avec efficacité à vos demandes. Cela pourrait être l’occasion de comprendre comment il travaille. Mais vous préférez le définir dans une fiche de poste dont vous maîtrisez le vocabulaire.
Quelles sont vos métriques qui définissent les critères de productivité d’un développeur ?
Le nombre de lignes de code produits ? Si la qualité d’un code se mesurait à cela, la maintenance deviendrait impossible. Au contraire, la factorisation et l’usage de frameworks modernes sont essentiels.
Les points de fonction ? Mesurer la taille fonctionnelle d’un projet par rapport aux entrées, sorties et traitements de ce dernier, estimer la charge de travail et le nombre de points traités par jour par un développeur est une métrique pertinente.
Cependant, cette méthode implique un cadre de travail maîtrisé et son application systématique à tout nouveau projet ou chantier. En pratique, cette méthode est encore plus négligée que la documentation d’un projet.
Une vraie métrique pour juger le travail d’un développeur est le nombre d’incidents suite à la livraison de la fonctionnalité. Je distingue le développeur de son équipe. Les parasites dans un groupe ne doivent pas passer avant la compétence individuelle.
Mais cette compréhension fine du travail d’un informaticien demande beaucoup de temps. Si seulement était-il possible de l’outiller ? Et vous multipliez les rapports à produire, comme si on écrivait un code comme on plante des clous.
Si à qualité égale pour un même programme, un développeur met 2 heures et son collègue 2 jours, vous devriez laisser le premier développeur expliquer sa méthode de travail, et le valoriser dans sa carrière.
En tout cas, c’est ce que font les compagnies américaines. Il semble qu’en France, le côté relationnel soit préféré. L’informaticien n’est pas du genre expressif. Ne le dérangeons pas. Et vous passez à côté des automatismes auxquels il pense quotidiennement.
Si vous vous demandiez ce qu’il fait sur ces sites étranges dans son coin au lieu de taper frénétiquement des lignes de code … il s’évade, il se projette. Dans ses projets personnels, dans ses futures vacances, …
Et parfois même, il pense à ces technologies qu’il aimerait mettre en place pour améliorer les programmes livrés, à ces outils qui éviteraient bien des problèmes de maintenance. Faudrait-il encore que vous l’écoutiez au lieu de le considérer comme un plieur de serviettes ?