Comment \u00e9valuer la performance de mon \u00e9quipe de D\u00e9veloppement TI ?<\/p>\n
La question n’est pas simple; comment pourriez-vous \u00e9valuer la performance de votre \u00e9quipe de D\u00e9veloppement TI avec certitude ?<\/p>\n
Il est moins simple qu\u2019il y para\u00eet d\u2019\u00e9valuer la performance d\u2019une \u00e9quipe de D\u00e9veloppement TI. Le fait est que les projets TI varient beaucoup en scope, en budget et \u00e9ch\u00e9ancier; dans ce contexte, il est difficile de comparer !<\/p>\n
Dans ce billet, nous ne parlerons pas de m\u00e9thodes \u00ab\u00a0math\u00e9matiques\u00a0\u00bb comme celle des \u00ab\u00a0points de fonction\u00a0\u00bb (FFP) qui permettent d\u2019\u00e9valuer la charge n\u00e9cessaire associ\u00e9e \u00e0 un d\u00e9veloppement en termes de points.\u00a0 Cette \u00e9valuation donne des r\u00e9sultats constants, ce qui change est le nombre d\u2019heures n\u00e9cessaire par l\u2019\u00e9quipe de d\u00e9veloppent pour programmer un point de fonction. Malheureusement ces m\u00e9thodes ne sont pas tr\u00e8s r\u00e9pandues.<\/p>\n
Nous parlerons de quelques \u00e9l\u00e9ments de base\u2026<\/p>\n
Les r\u00e9sultats parlent souvent d\u2019eux-m\u00eames; le client est satisfait, votre \u00e9quipe n\u2019a pas d\u00e9pass\u00e9 le budget, les livrables ont \u00e9t\u00e9 livr\u00e9s dans l\u2019\u00e9ch\u00e9ancier, etc.<\/p>\n
Quand c\u2019est le cas, alors Bravo, m\u00eame si ces r\u00e9sultats ne disent pas tout car ils peuvent \u00eatre trompeurs\u00a0\u00e0 plusieurs \u00e9gards\u00a0:<\/p>\n
Bref, en avez-vous pour votre argent avec votre \u00e9quipe de D\u00e9veloppement ?<\/p>\n
Et lorsqu\u2019on s\u2019interroge, c\u2019est qu\u2019on a un doute\u2026<\/p>\n
<\/p>\n
Bien que cela ne soit pas simple, il y a quelques pistes qui peuvent vous \u00e9clairer en tant que Directeur TI. Et la premi\u00e8re question \u00e0 se poser est\u00a0: qu\u2019est-ce qu\u2019il faut regarder ?<\/p>\n
Voici trois param\u00e8tres de base que tout Directeur TI devrait pourvoir \u00e9valuer\u00a0sans trop de difficult\u00e9 :<\/p>\n
<\/p>\n
La M\u00e9thodologie Agile est \u00e0 l\u2019heure du jour depuis plus de 10 ans maintenant. Elle met l\u2019emphase sur la valeur livr\u00e9e de tout projet TI, principalement en termes de fonctionnalit\u00e9s.<\/p>\n
La m\u00e9thodologie Agile repose sur quelques principes fondamentaux\u00a0:<\/p>\n
<\/p>\n
En adaptant une bonne m\u00e9thodologie de d\u00e9veloppement logiciel, on assure une bonne communication et on s\u2019assure donc qu\u2019il n\u2019y aura pas de d\u00e9viation des priorit\u00e9s au cours du Projet TI, tant du c\u00f4t\u00e9 Client que du c\u00f4t\u00e9 D\u00e9veloppement. La m\u00e9thodologie Agile offre des b\u00e9n\u00e9fices clairs\u00a0:<\/p>\n
<\/p>\n
Mais il y a un b\u00e9n\u00e9fice intangible de la m\u00e9thodologie Agile qui se voudra tr\u00e8s utile \u00e0 tout Directeur TI, c\u2019est qu\u2019elle r\u00e9v\u00e8le rapidement l\u2019incomp\u00e9tence<\/em><\/strong> par le fait qu\u2019il est rapidement visible qu\u2019une ressource n\u2019est pas en mesure de livrer ou pas en mesure de livrer dans le temps allou\u00e9\u2026<\/p>\n N.B.\u00a0 Et si vous visez une Performance et une Qualit\u00e9 sup\u00e9rieure de vos Projets TI, alors inscrivez vos King Pins \u00e0 une formation \u00e0 la m\u00e9thodologie SCRUM.<\/p>\n <\/p>\n Doit-on souligner l\u2019importance de la D\u00e9finition du Projet et de son \u00ab\u00a0scope\u00a0\u00bb; de l\u2019impact de d\u00e9finir clairement le Projet et de bien communiquer les objectifs vis\u00e9s et les priorit\u00e9s ?<\/p>\n \u00c9tonnamment, oui !<\/p>\n Une bonne d\u00e9finition initiale implique que tout le monde comprend bien les objectifs, priorit\u00e9s <\/strong>et livrables<\/strong> du Projet; ce qui vous assurera que tous comprennent bien ce qu\u2019il faut suivre<\/strong>, mesurer<\/strong> et livrer<\/strong>.<\/p>\n Et pourtant, on ne compte plus le nombre de Projets TI qui d\u00e9marre dans une direction et qui bifurque \u00e0 mi-parcours pour ensuite revenir \u00e0 l\u2019essentiel\u2026 avec des r\u00e9sultats mitig\u00e9s.<\/p>\n La faute \u00e0 qui ?\u00a0 La faute aux DDC (Demandes De Changement).<\/p>\n INDICE\u00a0: les DDC (Demandes De Changement) sont le pire ennemi d\u2019un Projet TI et la principale cause de d\u00e9rive d\u2019un Projet TI \u00e0 cause d\u2019un mauvais suivi des DDC et de la mauvaise attribution du niveau de priorit\u00e9 de certaines DDC.<\/p>\n Exemple\u00a0: une DDC qui entra\u00eene un changement de scope dans un Sprint !!!<\/p>\n Il est donc primordial de cr\u00e9er les demandes de changement.\u00a0 De plus, le lien suivant<\/a><\/strong> \u00e9num\u00e8re 5 \u00e9tapes pour faire de meilleures demandes de changement.<\/p>\n <\/p>\n Ce qui nous am\u00e8ne \u00e0 l\u2019importance de la d\u00e9finition des R\u00f4les<\/strong>\u00a0prioritaires : Gestionnaire de Projet & Product Owner (Business Analyst)<\/p>\n Le Gestionnaire de Projets travaillera main dans la main avec le Product Owner et ce travail d\u00e9butera d\u00e8s la d\u00e9finition du Projet.<\/p>\n Incidemment donc, cette \u00e9troite collaboration se poursuivra au fil du projet et surtout, lors de l\u2019\u00e9mergence de DDC, car il en va de la responsabilit\u00e9 du Gestionnaire de Projets d\u2019\u00e9tablir clairement les canaux de communication et de dicter les protocoles de gestion des DDC.<\/p>\n Le bon Gestionnaire de Projets aura d\u00e9velopp\u00e9 avec le temps un sens de l\u2019anticipation de l\u2019impact des DDC. Il sera aussi capable d\u2019anticiper la performance de ses d\u00e9veloppeurs et les d\u00e9lais de livraison en regard des DDC.<\/p>\n C\u2019est le genre de facult\u00e9 que l\u2019on acquiert avec l\u2019exp\u00e9rience mais qui peut aussi nous venir plus facilement avec de bons outils…<\/p>\n <\/p>\n La r\u00e9ussite d\u2019un Projet de D\u00e9veloppement TI s\u2019appuiera sur une bonne m\u00e9thodologie, une d\u00e9finition claire du scope du Projet, un Gestionnaire de Projets exp\u00e9riment\u00e9 et de bons outils (DevOps \/ Jira) dans un environnement ad\u00e9quat de d\u00e9veloppement.<\/p>\n \u00c0 cela, il faudrait ajouter un Tableau de Bord bien s\u00fbr et peut-\u00eatre aussi un autre outil qui en s\u2019int\u00e9grant \u00e0 DevOps \/ Jira permettrait au Gestionnaire de non seulement suivre le Reste-\u00c0-Faire pour chacune des t\u00e2ches de son Projet mais aussi de conna\u00eetre en temps r\u00e9el, le nombre d\u2019heures r\u00e9ellement ex\u00e9cut\u00e9es. Ainsi, le Gestionnaire sera en mesure de comparer le Travail ex\u00e9cut\u00e9 avec le Reste-\u00e0-Faire.<\/p>\n Le Gestionnaire de Projets, \u00e0 l\u2019aide cet outil, serait en mesure de suivre ses Projets en temps r\u00e9el et de mesurer la Performance r\u00e9elle de ses D\u00e9veloppeurs, de son \u00e9quipe de D\u00e9veloppement.<\/p>\n\u00a0<\/strong><\/h2>\n
Gestion & D\u00e9finition du Projet<\/strong><\/h2>\n
M\u00e9triques & Outils<\/strong><\/h2>\n