• 17 novembre 2020

Les déjs EDEN School – notre invité Thierry Chevrier – DAVEO

Les déjs EDEN School – notre invité Thierry Chevrier – DAVEO

Les déjs EDEN School – notre invité Thierry Chevrier – DAVEO 1024 768 EDEN School

Comme chaque mois, un ou une professionnel.le de la sphère du digital vient à l’école pour déjeuner et surtout échanger avec les élèves.

Notre invité

Pour notre premier déjeuner parisien de l’année 2020 / 2021, nous avons eu le plaisir d’accueillir Thierry Chevrier, Product Owner chez Daveo, un cabinet de conseil en transformation digitale.

Son parcours

Thierry Chevrier savait une chose depuis son plus jeune âge : il travaillerait dans l’informatique.

Mais le terme est vaste puisque cela va du développeur en passant par l’ingénierie, de la sécurité à la maintenance. Son premier ordi, c’est à la fin des années 80 qu’il en fait l’acquisition. Si aujourd’hui, une majorité de foyers en sont équipés, ce n’est pas si courant à l’époque.

Après un parcours scolaire qu’il qualifie de classique, il intègre l’EFREI (École française d’électronique et d’informatique) à Villejuif. Au bout de 5 ans d’études, il obtient son diplôme. Lui qui voulait à l’origine être développeur, intègre dès sa sortie de l’école une ESN (Entreprise du Service Numérique).

Depuis 2007, Thierry Chevrier est consultant chez Daveo. Un métier qu’il définit comme étant un intérimaire très qualifié “vendu” à la journée par une société. Les missions sont pourtant généralement longues. Il a travaillé entre autre pour SNCF et BNP Paribas.

Un peu d’histoire

Jusque dans les années 2000 : un process lourd et compliqué

Les développeurs informatiques avaient hérité des processus et des méthodes utilisés dans le bâtiment. On fonctionnait comme pour la construction d’une maison. D’ailleurs, les termes sont restés : maîtrise d’oeuvre, maîtrise d’ouvrage, architecture d’un site…

Une entreprise exprimait un besoin qu’il transférait à la maîtrise d’ouvrage (MO) qui à son tour rédigeait des spécificités en traduisant le besoin en détails. Ensuite, il les transmettait au maître d’oeuvre qui établissait toutes les spécificités techniques ( langages, serveurs…). Et enfin, à l’issue de tout ce process, le développeur entrait en scène et définissait les normes de développement. En un mot, il codait la solution parfois des mois voire une année après la demande du client.

C’est ce que l’on appelle le modèle du cycle en V.

Depuis les années 2000: l’avènement de la méthode Agile

On s’est dit, c’est long et compliqué et finalement ce qui marche pour le bâtiment ne fonctionne pas forcément pour un logiciel. On va fonctionner petit bout par petit bout, par petites itérations. On n’attend plus d’avoir toute la solution pour commencer mais au contraire, on se lance tout de suite et on teste.

On a donc créé une méthode de travail propre au développement informatique : la méthode Agile comme celle bien connue, le Scrum ou mêlée en rugby. Toute l’équipe devient polyvalente, tout le monde sait tout faire et doit monter en compétences dans toutes les technologies. C’est un fonctionnement plus transversal que hiérarchique où tout le monde même les nouveaux partagent les responsabilités. L’équipe est souvent regroupée au même endroit.

Et mon métier dans tout ça?

Être PO (Product Owner), c’est jauger de la complexité des tâches à effectuer et la mettre dans la balance avec la business value, c’est à dire la valeur de ce que je vais produire. En clair, je dois hiérarchiser les priorités tout au long du processus de développement. On va du plus technique au plus fonctionnel avec une question en tête en permanence : qu’est ce qui est important pour les utilisateurs ?

Mon équipe et moi sommes engagés dans une chose et une seule : donner au client ce dont il a besoin. C’est un engagement de moyens car souvent je ne sais pas à quoi ressemblera le résultat final, je sais seulement que cela sera conforme au besoin initial de mon client. La méthode Agile permet de s’adapter en cours de route. Car bien sûr, les choses se passent rarement comme prévu. Il y a ce qui a été prévu et ce qui a été fait… Et il faut se remettre en question en permanence. C’est la différence entre la théorie et la vraie vie de développeur!

Les conseils de notre invité

Quand on pense développeur, on pense au logiciel en vente dans les rayons des magasins. Mais il faut savoir que le gros du métier n’a pas vocation à être commercialisé. Il s’agit simplement de répondre au besoin précis d’une entreprise. Par exemple, une société peut avoir besoin d’un site web pour gérer les congés, les absences et les présences des salariés.

Conseil n°1

Que l’on soit développeur, webdesigner ou tout autre métier lié à l’informatique, on passe des moments difficiles techniquement et/ou humainement. Il arrive qu’on se dise, je vais tout laisser tomber et partir élever des chèvres dans le Larzac. Par chance, on réalise que c’est la passion qui nous guide et on continue.

Donc, il faut s’accrocher et se rappeler souvent qu’on aime ce que l’on fait.

Conseil n°2 à l’intention des développeurs

Soyez conscients de votre importance. Si avant on n’écoutait qu’assez peu les développeurs, aujourd’hui les méthodes collaboratives mettent la technique au même niveau que le besoin. Dans les équipes où le partage de responsabilités est de mise, les développeurs ont leur mot à dire au même titre que les autres membres.

Ne l’oubliez pas !

Conseil n°3

L’humilité et la modestie. Il faut apprendre (et ce n’est pas facile!) qu’on travaille parfois sur des projets qui ne servent à rien ou qui évoluent tellement en cours de route qu’ils n’ont plus rien à voir avec l’objectif de départ. Dans ce cas-là, on remballe et on recommence.

Sans compter les projets qui mettent tellement de temps à voir le jour qu’ils sont obsolètes le jour de leur sortie. Ça rend modeste!

Conseil n°4

La bienveillance ! Une notion qui n’a l’air de rien mais qui contient beaucoup de choses. Les modèles de travail d’aujourd’hui ont (par chance) considérablement évolué. Par exemple, les lead-développeurs  se doivent d’être des personnes ouvertes et tolérantes qui font en sorte que tout le monde évolue dans l’équipe (y-compris eux-mêmes), que tout le monde progresse et travaille dans une bonne ambiance. On n’attend plus simplement un résultat immédiat mais un travail d’équipe soudée et efficace où chaque individu a sa place et son importance. Plus question de placardiser, aujourd’hui on stimule et on associe à l’effort collectif.

Conseil n°5

La solidarité, un maître-mot en particulier dans la méthode Agile : on s’entraide. Les équipes sont petites mais engagées dans un objectif commun de réussite du projet. Dans une grande équipe, un traîne-savate ne se repère pas forcément mais dans une team restreinte, tout le monde doit être opérationnel pour honorer le contrat passé avec le client. Car au fond, c’est le seul objectif.

Un grand merci à toi Thierry pour cet échange passionné avec nos élèves !