Ces deux termes sont souvent confondus. Pour ma part, elles sont différentes sans pour autant s’opposer.
L’expérience s’acquière aux files des années, aucune formation, pilule magique peut données l’expérience. Comme disait mon défunt père, l’expérience s’acquiert : « au pic et la pioche » .
Quant à la compétence, elle peut s’acquérir par de la formation, par le travail, l’étude. Mais, à la base il faut avoir la structure d’esprit, de pensée, nécessaire pour arriver acquérir cette compétence.
Par exemple, j’ai un profond respect pour les programmeurs Cobol. J’ai eu de très bons professeurs, mais malgré cela je reste profondément incompétent dans ce langage. Par contre, fais-te moi parler d’architecture orientée objet et orientée Service, la je crois que je sais de quoi je parle.
Suis-je plus incompétent pour autant, non, c’est juste que mon cerveau est construit d’une certaine manière, qui m’aide dans mon travail. Et j’aurais beau travailler 10 ans, (j’espère que non) en Cobol, je resterai toujours un mauvais programmeur Cobol. Dieu merci, il y a des gens qui l’ont.
Combien de fois, j’ai entendu quelqu’un, et souvent des patrons pour justifier une promotion d’une personne. Il a acquis assez d’années expériences pour ce poste, sans pour autant regarder si la personne avait la compétence nécessaire pour ce poste.
Aux files des années, j’ai connu beaucoup de personnes qui avaient gravi les échelons par expérience sans pour autant en avoir les compétences. Un peu à l’image de principe de Peters.
À l’inverse, j’ai aussi connu beaucoup de gens, qui avaient toutes les compétences pour occuper un poste supérieur. Mais, qui n’avait pas toute « L’EXPÉRIENCE » pour l’obtenir.
Je ne veux pas dire qu’il faut donner à des gens sans expérience, des postes qui en demande. Mais, en plus de regarder l’expérience, qu’il faut regarder d’autre chose. Donc, les compétences, mais aussi l’intérêt. Je n’ai pas les compétences pour le Cobol, mais surtout aucun intérêt pour ce genre de langage.
Il faut donc, arrêter de voir l’informatique comme étant hiérarchique, mais étant compartimenté. Un bon programmeur ne fait pas automatiquement un bon architecte. C’est peut-être notre programmeur moyen qui sera notre meilleur architecte ou analyste. Je pense à coéquipier d’université, l’un pour des meilleurs programmeurs que j’ai connu. Ferais un mauvais architecte ou même pire, un analyste pitoyable. Car, il a de la difficulté à interagir et communiquer avec les autres. Mais, il écrit du code plus vite que sont ombre. Et surtout du code d’une très grande qualité.
Aujourd’hui, il doit cumuler près de 20 ans d’expérience, et aux dernières nouvelles que j’en ai eues, il est toujours programmeur. Et j’en suis sur, un programmeur redoutable. Il aurait l’expérience pour devenir Architecte ou Analyste. Mais, il n’a pas les compétences pour le devenir. Et je ne pense pas l’intérêt non plus.
Beaucoup trop, d’architecte, d’analyste ou chargé de projet qui pense, encore comme quand il était programmeur. Comme, j’ai connu beaucoup de monde, j’ai connu aussi un analyste fonctionnel, qui écrivait des dossiers fonctionnels, de vrai roman, excessivement facile à lire et comprendre. Par contre, il n’était incapable de le programmer ce dossier. A chacun son métier et les vaches seront bien gardé.
Avec les méthodologies agiles, nous offre un environnement assez sur les compétences et l’intérêt des individus plus tôt que par la reconnaissance de l’expérience. Un programmeur de 20 ans d’expérience, au lieu de lui donner un poste d’architecte dans laquelle, il n’aura pas l’expertise nécessaire. Lui donner la chance de continuer à faire ce qui fait de mieux, c'est-à-dire programmer, mais aussi transmettre toutes ces expériences (pas les années, mais la somme des projets et des lignes de codes) qu’il a fait aux autres.
Un bon programmeur, nous permet d’augmenter la qualité de notre logiciel. On veut un logiciel qui fonctionne, mais surtout un logiciel de qualité.
Mettons les bonnes aux bons endroits, tant d’un point de vue des compétences, de l’expérience que des intérêts. On est venu en informatique pour se faire du fun.. ! Pour avoir du Fun ! Donc, c’est en passant, en repassant ce modèle que nous pour arriver à cet objectif ultime, de livrer une application de qualité et surtout qui corresponds aux différents besoins de notre client.
Associons compétence, expérience et intérêt, et je crois sincèrement que nous de meilleurs ressources pour tous nos projets.
Si tout le monde change un seul individu, que cet individu en fait autant. La terre informatique se portera mieux !
Principe de compression des données en mémoire de Prometheus
Il y a 4 jours
1 commentaire:
Il est vrai que trop souvent la compétence est laissée pour compte et que l'expérience domine. Par contre, les méthodes d'évaluation de la compétence ne sont pas plus avancées. Dans la plupart des domaines, le diplôme domine, il est un gage de compétence. De compétence? Oui, de compétence à écouter et prendre des notes, de compétences à pouvoir étudier. Qu'en est-il des compétences directement liées au métier voulu? L'intérêt amène parfois les gens à un niveau de compétence au-delà des études, mais sans l'expérience et le diplôme, ces gens ont de la difficulté à se tailler une place. La compétence, l'expérience et l'intérêt doivent aller de pair, ou de trio, mais pour cela, il faut savoir comment les évaluer, comment les estimer.
Enregistrer un commentaire