5 tendances de fond dans le monde des Devs en 2018
Il me restait jusqu'au 30 janvier pour faire un article avec écrit 2018 dans le titre. L'idée est de proposer un article très court avec les principaux thèmes qui vont rythmer cette année, au moins sur notre publication medium. Ce sont des sujets que nous essaierons d'approfondir au cours des prochaines interviews et articles. J'espère pouvoir donner un article de fond à chacun d'entre eux.
J'ai retenu 5 axes, mais vous verrez que ce sont des choses assez liées.
Craftsmanship 2.0
Le Manifesto for Software Craftsmanship fête ses 10 ans cette année. C'est un document intéressant par sa concision. Aujourd'hui, on en observe encore des interprétations très étroites.
Nous avons vu beaucoup de choses changer dans le monde des développeurs. Aujourd'hui de grands groupes qui avaient jusqu'ici pris uniquement des prestataires ouvrent des postes en CDI et de manière assez quantitative.
C'est la convergence de deux phénomènes. D'une part, une entreprise qui a besoin d'un développeur à un instant T en aura encore besoin d'un dans 10 ans. Ce n'est pas nouveau, mais pendant longtemps on a aligné les développeurs à jeter après la livraison du projet (en accord avec la maxime de gestion de projet, toujours non-vérifiée en 40 ans "Si un dev peut faire le bébé en 9 mois, 9 devs peuvent le faire en un mois"). Maintenant on se rend compte qu'à la fin du projet, on a encore besoin d'eux, que les développeurs qui font le code ont plus de valeur que le code en lui-même. La finalité du projet devient l'expérience utilisateur, la "digitalisation" du processus, la performance de l'organisation et plus uniquement le code en lui-même. Et ça change beaucoup de chose.
Il y a donc d'une part ce changement dans la gestion des ressources humaines, mais aussi une prise de conscience post-transfo numérique. Beaucoup d'organisations se demandent comment prendre le virage du numérique et se rendent compte qu'il faudrait commencer par embaucher des développeurs.
Les rémunérations augmentent aussi. Si la perception de la valeur créée change, la rémunération des développeurs change aussi. Autrefois une entité sans ROI direct, un centre coût à piloter, l'IT devient une source de création de valeur non-quantifiable. La valeur créée devient aussi spéculative que celle d'un bitcoin et s'envole doucement.
J'ai envie de revenir sur “No Silver Bullet — Essence and Accident in Software Engineering” qui a été écrit par Fred Brooks en 1986. C'est un écrit qui est antérieur au test de Joël, et qui explique que notre métier n'évolue pas en terme de complexité. Même si on invente des outils de plus en plus évolués pour produire du logiciel, au final notre métier reste de résoudre des problèmes et leur complexité n'augmente pas. En 86, le sujet c'est l'offshoring en Inde et les méthodes MDAs. Aujourd'hui, le contexte a changé, mais le débat reste le même.
Si le Craftsmanship signifie que les développeurs sont de plus en plus valorisés ("Parce qu'on en a gros"), la dimension "communauté de professionnels" mentionnée par le manifesto est aujourd'hui encore restreinte. Nous avons tendance à mépriser les non-devs qui nous disent comment faire notre travail. Cependant tout n'est pas si simple. Notre communauté de professionnels a pour finalité la création de logiciel de qualité, et pour arriver à ce but, le code ne suffit pas. Probablement 60% de notre activité consiste à faire comprendre notre métier aux utilisateurs finaux, aux décideurs etc… Les Agilistes, les MO(E/A), les graphistes et les DAs, les chefs de projets, les UX designers font partie de notre communauté de professionnels, ils doivent être nos alliés dans notre mission et doivent être estimés en tant que tels. Haut les coeurs ! 💙
Agilité, sortir de la prison du sprint. Not Only Scrum #NOScrum
Donc l'éléphant dans la pièce est le suivant : Tout le monde fait du Scrum sans réfléchir à pourquoi. On a pas de méthode ? Ben on a qu'à faire du Scrum.
Scrum et toutes les méthodes itératives sont synonyme de pilotage par les délais. On livrera le soft dans les temps quoi qu'il arrive. Oui, mais qu'est-ce que l'on sacrifie pour tenir le délai ? Qualité du logiciel, Dette Technique, Sécurité, vie privée des utilisateurs, expérience utilisateur.
Le chef de projet scrum satisfait avec l'équipe lors de la release :
Clairement c'est un truc bien, on a livré dans les délais, on a pas débordé du budget, mais on a livré du logiciel de mauvaise qualité et personne ne sait comment l'utiliser. Bravo ! 👏
Le Sprint est une prison dans laquelle nous perdons toute agilité. La seule agilité que nous avons c'est de savoir dans quelle ordre nous feront les fonctionnalités dans un ensemble borné.
Le Backlog est un outil fantastique pour avoir une vue d'ensemble du logiciel que l'on veut produire. Orienté fonctionnalité, il permet de gérer les Specifications du projets de manières features-centric. Mais est-ce vraiment utile d'avoir une vision globale du logiciel si on a pas vraiment compris comment on apporte de la valeur à l'utilisateur ?
Bref, cette année, je vais vous faire rencontrer des gens qui font du logiciel, qui sont agiles et qui ne font pas de Sprints. 😙
DataScientist, l’informaticien qui faisait des maths
Le DataScientist devient une nouvelle chimère. On ne sait pas trop ce que c'est, mais on en a besoin pour faire de l'IA.
Je discutais avec un non-tech qui parle d'IA et travaille pour une grande entreprise américaine qui vend beaucoup d'IA et je lui demande ce qu'est un DataScientist. Il m'a répondu avec beaucoup d'amabilité : "Si tu en avais, tu saurais". Il m'a ensuite décrit une espèce de savant fou qui a "des développeurs qui travaillent pour lui".
En pratique, quelqu'un qui sait bricoler avec TensorFlow et qui a lu le Handbook "O'Reilly" se revendique sans soucis DataScientist. Il y a également un énorme décalage avec le continent américain où la majorité des devs sont diplômés d'un BS CS (l'équivalent d'une licence en France). Les professeurs de mon université au Québec avaient un débat concernant leurs diplômés. Plus de la moitié sortent sans savoir ce qu'est ln() ou exponentielle, et ils ne savaient pas si c'était un problème ou non.
En France, on nous explique qu'un DataScientist c'est un Mathématicien qui ne code pas alors que nos développeurs ont quasiment tous fait Mat Sup et Mat Spé.
Bref, l'IA c'est avant tout du Software. Un développeur peut faire déjà beaucoup de Machine Learning et mettre en place des applications prédictives. Analyser et valoriser la donnée ça existait déjà avant la hype IA, on appelle ça le décisionnel ou le BI. Et effectivement au bout d'un certain moment, le monde des mathématiques et de l'informatique se croisent. Il y a tout un monde qui prend racine dans des années de "Data Mining" (aka. forage de données en Québécois). Globalement, quand quelqu'un te dit que faire une régression linéaire pour faire un modèle, c'était rigolo ou facile, c'est que sont cerveau est pas fait pareil.
De manière générale, dans la Data il y a plein d'autres métiers fascinants : Le Data Engineer (il dit des trucs comme CQRS et il se demande comment faire pour prendre 14M de points de données par jour), le Data Manager (il appelle des gens sur Skype pour leur dire que leur flux de donnée est mal formaté), la Dataviz (des développeurs web qui font des graphs avec D3.js) et tous les amis du BI ("Je vous ai posé un cube Olap, c'est de la bonne tuyauterie.")
Bref, c'est un sujet vaste. Je serais content de vous parler plus de tout ces métiers dans d'autres articles.
Maker, Ingénieur et Codeur. Les métiers IT nuancent les formations et les profils. Comment s’ouvrir des opportunités.
Ça fait longtemps que l'on sait qu'il n'y a pas que les ingénieurs qui codent. En France, la formation Epitech a ouvert la porte à pas mal d'école de code. Les Bootcamps comme le Wagon et les formations (O'Clock, IronHack, Greta, Cnam) ont le vent en poupe. Et même si pas mal d'employeurs sont un peu frileux, au final cela fonctionne. On a vu beaucoup de belles histoires en 2017 c'est très excitant !
En fait, avoir un diplôme d'ingénieur pour faire du PCSoft ou du VB6 ça a toujours été overkill. Alors bien sûr dans l'IT, il y a des métiers qui sont plus réservés à des profils ingénieur, mais d'un autre côté, tout le monde peut apprendre à coder. Et les formations ne sont jamais que l'opportunité pour un individu d'apprendre et de s'accomplir professionnellement. Il y a donc des autodidactes qui sont aussi compétents que des profils bardés de diplômes. Cela veut aussi dire que les formations ne sont pas la garantie de trouver en emploi.
Bref, le développeur au sens large, c'est un panel de métiers qui est de plus en plus nuancé. Les recruteurs qui sont moins strictes dans leurs recrutements aujourd'hui ont la chance de saisir de belles opportunités.
IT People Management. Les développeurs heureux font du meilleur logiciel. Qu’est-ce qui va changer dans la gestion des personnes dans l’IT ?
On reboucle avec le premier sujet. Si le Craftsmanship est une lame de fond, sur les berges, ont re-construit de nouvelles bases RH pour accompagner les développeurs.
Le rôle du service va changer aussi. Les SSIIs ne disparaissent pas. Leur position dans la chaîne de valeur change.
Elles restent quand même des cocons de confort sur ce point et savent mettre en oeuvre tout ce qu’il faut pour accompagner les ingénieurs dans leur vie professionnels. Il y a un effet “Boite de tech” / "Boite de devs", où les techs sont entre eux, dans leur zone de confort.
Dans beaucoup d'entreprises, on a du mal à comprendre le projet professionnel d'un développeur et donc on peine à mettre en place le mentoring et l'environnement pour qu'ils puissent s'épanouir. Les bonnes sociétés de service maitrisent ce sujet en général.
Pourtant, notre métier n'a pas de fin en soit, on ne fait pas du logiciel pour faire du logiciel. La proximité avec le "métier" (les gens qui sont dans l'activité de l'entreprise) est importante pour beaucoup d'entre nous. C'est pour ça que je trouve fascinant de voir des équipes métier, des équipes marketing, des équipes commerciales qui embauchent des devs. Ce sont des postes fascinants et j'espère avoir l'occasion de vous faire découvrir des postes comme ceux-ci très vite.
La gestion des personnes dans l'IT va gagner en maturité. C'est un vrai sujet. On comprend de plus en plus qu'un CTO qui ne code pas c'est normal, que le directeur technique n'est pas "le meilleur tech". On voit des développeur qui veulent faire du produit. Bref, les choses évoluent, c'est assez chouette 🙂
On va parler de tout ça ensemble cette année. Si vous me croisez, je suis content de discuter (prévoir un café ou une bière, ça peut être long). Je serais content également de recevoir des invités qui souhaitent publier sur Medium et de les mettre en avant dans cette publication. Hésitez pas à m'envoyer un email pour démarrer la conversation et à vous abonner à cette publication pour découvrir plus de contenus ↓
A très vite ! 💙
