Cette semaine j’ai été pas mal inspiré par la lecture de cette article (how to become an expert). Ce que l’on peut retenir de cet article, c’est que tout le monde peut devenir un expert. Pour cela il faut : de la détermination, de la rigueur et du travail. A force de travail tous le monde peut devenir expert au bout de quelques années (contrairement à devenir un champion ce qui requiert en plus des aptitudes particulières).
De plus, l’article propose une méthode pour aller vers cet objectif. La méthode proposée et je trouve très interessante, elle propose de définir les domaines à travailler, d’identifier le but de tavailler ce domaine, puis de définir un ensemble d’actions concrètes. Rien de bien nouveau, cependant, j’ai trouvé intéressant la méthode qui est de travailler de manière incrémental, plutôt que de travailler full time un sujet. Mieux vaux travailler un ensemble de sujet et d’itérer dessus pour monter en compétence. Cela donne plus de recul et une meilleure vision d’ensemble. A titre d’exemple, l’année dernière en travaillant Spring, je travaillais en parallèle les design pattern, le fait de comprendre des design pattern comme le “template” ou le “stategy” m’ont aidé à avoir une meilleure compréhension de Spring et de son utilisation.
Après avoir lu l’article j’ai créé mon propre tableau d’objectif, je vous le livre dans sa version alpha :
|
Domaine |
Importance/But |
Objectifs/Sujets couverts |
Actions |
|---|---|---|---|
|
Pratiques de développement |
Etre un développeur expérimenté. | Conception UML
Design Pattern Test AOP |
Lire « clean code », « design pattern J2EE », « refactoring des applications J2EE ». |
|
Développement -Java |
Etre expert java/J2EE. | Améliorer sa connaissance des API et framework. | Essayer Terracotta
Continuer d’apprendre Spring en vue de la certification Améliorer les compétences Maven Creuser les API de concurrence |
|
Développement - autres |
Garder une ouverture nécessaire. | .net | Suivre les nouveautés |
| BPM / BI | Avoir les connaissances de bases | ||
| Persistance O/R | Développer les compétences sur JPA et hibernate. | ||
| Travailler le design de BDD relationnel | |||
| Connaître les intérêts des portal | Installer et essayer LifeRay | ||
|
Architecture |
S’orienter vers un poste d’architecte d’ici 3/ 5 ans. | Maîtriser les différents styles d’architectures :
- Avantages, inconvénients - Connaissance rapide des principales solution pour chaque. |
Se baser sur le contenu de wikipedia pour dégrossir le sujet, cibler les plus importantes et intéressantes :
http://fr.wikipedia.org/wiki/Cat%C3%A9gorie:Architecture_logicielle Développer REST |
| Apprendre à monter un dossier d’architecture :
- savoir exprimer des exigences non fonctionnelles. |
Travailler les domaines ci-dessous | ||
| Préparer la certification SCEA pour 2010 ou 2011 | Voir la liste des objectifs | ||
|
Méthodes agiles |
Pouvoir guider une équipe autour de la mise en place de projet agile d’ici 2/3 ans. | Améliorer les compétences sur XP/SCRUM. | Article veille techno
Vidéo sur l’université du SI, infoQ |
| Creuser Lean | |||
|
Formation |
Savoir donner des formations dans le cadre d’un projet ou dans le cadre de formations professionnelles. | Synthétiser du contenu
Améliorer les techniques d’expression. |
Ecrire du contenu sur le blog.
Donner une nouvelle formation chez BT d’ici juillet 2009. |
|
Autres |
Développer ses connaissances périphériques, améliorer l’ouverture d’esprit. | Fonctionnel finance | Acquérir les bases de la finance de marché |
| Management d’équipe | |||
| Expression de besoin |
Je pense que cela vaut le coup de se définir des objectifs et d’y travailler quotidiennement. En effet, on a malheureusement tendance à ne se focaliser que sur les sujets que l’on connait ou qu’y sont les plus faciles. Or, être expert c’est justement avoir l’esprit ouvert et connaître tous les sujets connexes au sujet maitrisé.
Lorsque l’on atteint un niveau correct dans un domaine on a tendance à s’arrêter sur cet acquis et à ne plus voir le reste. Le schéma ci-dessous que j’ai piqué à Kathy Sierra l’illustre bien :

D’un autre coté, le premier article nous fait bien comprendre que l’on ne peut pas se reposer sur nos employeurs pour nous prendre la main et nous guider vers ce genre d’objectif. Nos buts ne sont pas les mêmes :
Your company expects results from your work: reliable, with minimal mistakes and focused on the company main goal - make money. Your employer could provide minimal training to help you with job requirements. However, your growth will be constrained by company needs, timelines, work assignments and acceptable methods.
En développement logiciel les technologies vont tellement vite que l’on ne peut surtout pas se permettre de se reposer sur une compétence acquise.
Enfin, je terminerai sur cet article, qui nous explique les qualités qui font selon lui un véritable expert :
- les connaissances
- l’expérience
- des capacités de communications
- un réseau
- la curiosité
Pour y parvenir, il nous propose de travailler sur ces axes :
- travailler continuellement
- pratiquer
- se faire un réseau
- acquérir des capacité de présentation (plutôt au sens marketing, savoir en mettre plein la vue)
- partager son expertise
Rendez-vous dans 2, 3 ans pour voir si la méthode marche
avril 2nd, 2009 at 12:15
C’est intéressant.
J’essaie moi aussi de définir mes objectifs tous les quelques mois et tous les ans (les fameuses bonnes résolutions)
Je vais lire les liens annexes pour compléter sur le rapport généraliste/spécialiste. Le 2ème paye plus mais n’est pas forcément le plus fun.
Tom
avril 5th, 2009 at 12:20
Un spécialiste paye plus, je n’en suis pas sur.
En tout cas à court terme uniquement je pense. On ne va rarement chez un client pour traiter un seul domaine en particulier. On y va en tant qu’expert Spring et on se retrouve à faire des spécifications, à accompagner la MOA, à mettre en place Hibernate, Maven, à proposer des pratiques agiles, à faire du bench…
Plus le risque de s’enfermer dans un domaine et de mourir avec celui-ci 5/10 ans après.
Ravie de voir que tu passes par ici, à bientôt aux Jug et autres.