Je voulais en parler depuis un bon moment, mais j’attendais d’avoir un peu de recul avant de le faire. Depuis septembre dernier, j’ai commencé le cycle Executive MBA d’Epitech. Pour ceux qui ne savent pas ce qu’est un MBA, il s’agit de cursus ouvert à ceux qui ont un diplôme…
Durée d’étude et expérience professionnelle
Il existe globalement 3 types de filières de formation :
- Les études «classiques», en université ou en école d’ingénieur, sur des cursus cours (2 ou 3 ans) ou longs (5 ans).
- Les études en alternance, avec différentes formules sur des rythmes très cadencés (4 jours en entreprise / 1 jour à l’école) ou très séquencés (3 semaines en entreprise / 1 semaine à l’école).
- L’autoformation (il ne faut pas négliger les autodidactes, il y en a de très brillants).
Oui, je sais, je simplifie beaucoup les choses, mais c’est pour le bien de mon propos.
Intéressons-nous aux deux premiers types d’études. Elles comportent, l’une comme l’autre, des périodes d’enseignement scolaire magistral (cours en amphi, TD), des périodes d’application pratique (projets) et des périodes de découverte du milieu professionnel (stages ou apprentissage). La seule différence, c’est l’équilibre qui est tenu entre ces trois aspects.
Si je continue à schématiser, ça donne quelque chose comme ça :
- En université, les cours magistraux forment l’essentiel de la formation.
- En école d’ingénieur, les projets sont souvent prépondérants, ou tout au moins très importants.
- En alternance, c’est l’expérience acquise en entreprise qui constitue la majeure partie du temps de formation.
Notez bien que je ne porte pas le moindre jugement sur ces différences. J’en parlerai peut-être dans un autre article, mais ce n’est pas le sujet pour le moment. Sachez juste qu’ayant passé 3 ans à la fac, 4 ans en école d’ingénieur, pour avoir embauché des informaticiens de tous profils et pour avoir donné des conférences dans des établissements assez différents, j’ai une vision assez précise de tout ça.
La chose qui ne cesse de m’étonner, c’est la perception que les informaticiens ont de leurs cursus, et comment ils les présentent lors des entretiens d’embauche.
Ma méthode «musicale»
Je n’en ai jamais parlé sur ce blog, mais j’ai quelques activités en dehors de l’informatique et de l’entrepreneuriat. L’une d’elles est la musique. Je joue de la basse depuis l’âge de 16 ans, de la basse 6 cordes depuis 10 ans, et de la basse fretless depuis 2 ans.…
Et si Gordon Ramsay était informaticien ?
Depuis quelques temps je ne rate pas un épisode de l’émission Cauchemar en cuisine, qui est diffusée sur plusieurs chaînes télévisées françaises de la TNT ou du câble.
Le concept de cette émission est assez simple : Gordon Ramsay, un chef cuisinier écossais renommé, vient en aide à des restaurateurs au bord de la faillite. Là où ça devient amusant, c’est que Gordon n’a vraiment pas sa langue dans sa poche ; il n’hésite pas à s’énerver très fort quand il le faut, pour faire prendre conscience aux gens qu’il sont sur la mauvaise voie.
Bon, la traduction française a tendance à édulcorer son langage. Ainsi, la phrase «I will smash this plate on your fuking head» est devenu «Je vais casser cette assiette sur ta tête de bois»…
Au fil des épisode, on peut voir des cuisiniers sans talent, des gérants à l’égo stratosphérique, des restaurants complètement vides, des engueulades à côté des clients, …
Gordon goûte les plats, regarde comment fonctionne l’organisation du personnel, étudie les comptes financiers. Il met ensuite les responsables − le propriétaire, le gérant de salle, le chef cuisinier − face à leurs lacunes, leurs faiblesses, leur fainéantise, leur désorganisation. Quand les problèmes ont été compris (au bout de quelques bonnes engueulades hautes en couleur), il met en place un plan de bataille qui permet de remonter les résultats du restaurant.
Il utilise souvent les mêmes recettes (au sens figuré du terme, désolé je n’ai pas pu m’en empêcher) d’un restaurant à l’autre, mais à chaque fois avec des résultats différents. Ce qui est vraiment intéressant, c’est qu’il met en application des principes qui tiennent plus de l’entrepreneuriat que de la restauration. Il y a beaucoup d’inspiration à trouver là pour une équipe technique.
L’étude de marché
À chaque fois, Gordon fait un petit tour dans la ville où il est tombé. Il fait attention aux autres restaurants existants, et essaye de trouver le type de restauration qui n’est pas représenté. Il regarde aussi la clientèle existante (ou ce qu’il en reste), et à partir de tout ça il invente un nouveau visage au restaurant pour lui faire trouver une nouvelle clientèle.
Cette nouvelle identité est souvent mal vécue par les patrons qui voient leurs habitudes remises en question. Le menu est complètement revu (je vais y revenir), le restaurant est redécoré, parfois même renommé. Mais ce nouveau positionnement est gagnant, et l’augmentation des bénéfices lui donne toujours raison.
La R&D : pour ne pas confondre développement et veille techno
Il y a quelques temps, je vous ai parlé de la veille technologique. Je vous ai expliqué en quoi c’est un élément important de nos vies professionnelles.
Je voudrais cette fois-ci vous mettre en garde contre une dérive finalement assez commune chez les jeunes développeurs, qui est d’utiliser les projets professionnels comme un terrain de jeu pour réaliser leurs expérimentations. Ensuite nous réfléchirons aux moyens de canaliser la fougue qui conduit à ces dérapages.
Les expérimentations au boulot
Il y a quelques années, alors que j’étais chef de projet, un de mes développeurs – un prestataire externe, en fait – avait demandé une demi-journée de congé pour assister à une conférence organisée par Google France. J’étais content de voir qu’il prenait à coeur sa veille technologique.
À son retour, je lui ai évidemment demandé de me faire une présentation rapide de ce qu’il avait vu. Il s’agissait des premières versions des toolkits de Google, et ça avait l’air vraiment intéressant.
Nous étions alors en train de démarrer un nouveau projet, et ce développeur était en charge de certaines spécifications techniques. Quand j’ai vu dans ses specs qu’il envisageait d’utiliser les technologies Google qu’il venait d’entrapercevoir, j’ai eu une petite discussion avec lui.
Le message tient en 2 points :
- Bien qu’absolument nécessaire, la veille technologie est une démarche personnelle. C’est à chacun de se trouver ses propres petits projets qui lui permettront de tester de nouvelles technos ou de nouveaux outils.
- Un projet mené au sein de l’entreprise répond à des contraintes contractuelles et financières. Vouloir y glisser des technologies qui ne sont encore qu’à l’état de bêta, ou qu’on ne maîtrise absolument pas, est une erreur assez grave.
Canaliser et organiser
Il n’empêche qu’il n’est pas logique d’inciter à la veille tout en la réprimant dans le cadre de l’entreprise. L’entreprise a certains devoirs de formation vis-à-vis de ses employés, il faut s’en occuper de manière raisonnée et planifiée.
La veille : préparer votre futur
Je discutais récemment avec un développeur que je viens d’embaucher, et je lui expliquais entre autres pourquoi il est important de maintenir une veille active. La conversation avait commencé quand je lui ai donné plusieurs magazines à lire (en l’occurrence des Linux Format et PHP Architect), pour l’aider à se plonger dans la « culture informatique » dans laquelle il allait travailler. Cela l’a laissé un peu perplexe au début, mais il a fini par reconnaître mes arguments.
Par le terme de « veille », on pense habituellement à la veille technologique ; c’est le fait de se tenir au courant des nouveautés concernant une technique ou un champ de technologies. La plupart des informaticiens sont férus d’informatique (oui, ça paraît évident), et se tiennent au courant des dernières informations. Dans certains cas, ce sera les news concernant le monde du logiciel libre, ou celles de tout ce qui gravite autour d’un langage de programmation ou d’une plate-forme particulière ; éventuellement, on trouvera des gens qui suivent avec précision les évolutions des processeurs ou les sorties des jeux vidéos. Bref, on voit de tout.
Mais une des choses qui font la différence entre un ingénieur qui fera évoluer sa carrière, et un autre qui stagnera au même niveau, c’est entre autres l’implication personnelle qu’il met dans son travail. Ce qui veut dire aussi qu’il faut prendre du temps pour mettre à jour nos connaissances et élargir nos compétences sans arrêt.
Le mauvais exemple
Je connais des développeurs qui considèrent qu’ils possèdent le savoir nécessaire et suffisant pour faire leur travail. Leur instruction et leur expérience leur permettent de résoudre la plupart des tâches habituelles, et quand ils sont face à un problème, ils cherchent un peu sur Internet et ça suffit bien souvent.
Préparer votre évaluation annuelle
La plupart des entreprises effectuent des entretiens annuels ou bi-annuels de leurs collaborateurs. Il sont habituellement réalisés par les managers, parfois avec l’assistance du DRH.
À quoi servent ces entretiens ?
Tout le monde attend ces entretiens avec impatience, mais souvent pour de mauvaises raisons. Un grand nombre de salariés n’y voient que le moment où va leur être annoncée leur augmentation de salaire. C’est évidemment un élément important de ces discussions, mais il ne faut pas que cela devienne une obsession qui occulte les autres aspects.
Les entretiens annuels sont un moment privilégié, pendant lequel on peut prendre un peu de recul par rapport à l’année (ou le semestre) écoulée. Le but est de récapituler les points forts et les points faibles, de revenir sur notre évolution au fil du temps ; comment on a réussi à s’améliorer, à progresser dans l’exécution de nos tâches.
Préparer l’entretien
Quelques jours avant l’entretien, prenez le temps de vous poser ces quelques questions :
- Où en étais-je il y a un an, il y a 6 mois ? Mes supérieurs étaient-ils satisfait de mon travail ? Pourquoi ?
- Quelle était l’évolution qu’on attendait de mois durant cette période ? Est-ce que mes objectifs étaient clairement définis ?
- Quelles sont mes forces et mes faiblesses aujourd’hui ? En quoi sont-elles différentes d’auparavant ?
- En toute honnêteté, quels sont mes coups d’éclats et mes ratages complets ?
- Globalement, en suis-je là où je voudrais être ? Ai-je développé les connaissances et les capacités que je voudrais avoir ?
Quand vous avez répondu à ces questions, demandez-vous où vous voulez aller :
- Suis-je satisfait de l’environnement technique dans lequel j’évolue, des projets sur lesquels je travaille ?
- Dans quelle direction ma carrière doit-elle évoluer ? Qu’est-ce que je veux faire dans 6 mois, dans 1 an, dans 2 ans ?
- De quelle aide ai-je besoin pour progresser ?
Une fois que vous avez fait le tour de ces questions (et seulement à ce moment-là), vous pouvez vous poser d’autres questions :
Lenny’s golden rule of management
Dans mon dernier billet, je vous parlais de la règle d’or du management de Loïc. Je vais maintenant vous parler d’une autre règle qui, sous son aspect – et son origine – humoristique, possède une réelle profondeur : « Tout le monde peut faire des erreurs, c’est pour ça qu’il y a…
L’encadrement des juniors
L’encadrement de juniors (stagiaires et jeunes diplômés) est un sujet assez vaste, et je vais juste aborder ici un point de détail qui concerne la manière dont les entreprises abordent leur productivité.
Il existe un principe de base qui est valable pour tout le monde :
« Comprendre ce qu’on fait et ce sur quoi on travaille »
Quand on embauche une personne qui a de l’expérience, c’est souvent pour la faire travailler sur des projets assez pointus. Dans ce cas, on s’attend communément à ce que la complexité de la tâche implique un « temps de démarrage » conséquent.
Il est assez logique que les juniors, pour leur part, se voient affecter des tâches plus accessibles d’un point de vue technique. Mais de nombreuses personnes voudraient qu’un junior soit immédiatement opérationnel. La réflexion qui est faite est du style : « Ce n’est pas bien compliqué, franchement, il devrait avoir terminé dans 2 jours, non ? ».
Le problème, c’est que n’importe quel travail doit se faire en ayant une maîtrise de son environnement et de ses impacts potentiels.
On ne peut pas demander à un jeune embauché de faire du bon boulot, si on n’a pas pris le temps de le former correctement sur les méthodes et outils spécifiques employés dans l’entreprise. Même si le travail demandé semble mineur, il faut se souvenir que l’expérience du collaborateur est limitée elle aussi. Un défaut d’encadrement peut conduire à des situations désagréables. La plus commune est que le junior, après avoir travaillé 3 jours sans avoir reçu de formation interne, doit recommencer tout le travail parce qu’il n’a pas respecté les directives qu’il n’a pourtant pas eues. On voit aussi fréquemment des personnes qui commencent à modifier du code sans le comprendre, générant un nombre incroyable de bugs de régression.
La pire situation que j’ai vue, c’est une entreprise qui formait ses jeunes « à la dure » : aucune formation, directement affectés aux débuggages ! Autant vous dire que ce n’était pas très efficace…
Si vous encadrez un junior
Vous devez lui fournir toutes les informations nécessaires. On ne laisse pas les gens se débrouiller tous seuls ; cela revient à les laisser dans la merde. Prenez le temps d’expliquer les méthodes, outils et usages qui ont cours dans votre entreprise. Faites leur faire un premier projet pour se faire la main, sur lequel vous les encadrerez de très près.