OK donc rapidement en introduction
ce lightning talk est vaguement un cours d'histoire sans l'être
parce que déjà en 5 minutes j'ai du mal, en plus je suis pas prof d'histoire
j'suis pas non plus prof de gestion de projet même si c'est un peu de ça dont ça parle aussi
Donc prenez pas non plus ça trop au sérieux
c'est plus pour vous faire réfléchir à comment on peut gérer un projet correctement, etc.
C'est pas non plus une vengeance personnelle contre des clients foireux
ou des chefs de projet qui auraient lamentablement planté des projets
merci de ne pas me jeter de pierres.
Alors rapidement, le Vasa
que je prononce probablement très mal mais je ne sais pas du tout le prononcer en suédois,
en 60 secondes ...
C'est un navire de guerre suédois qui a été construit entre 1625 et 1628
après plusieurs revers maritimes … de la marine suédoise
et il devait symboliser le renouveau, la magnificence de la marine suédoise pour contrecarrer ça
Et donc le truc c'est qu'il a fait naufrage moins de 5 minutes après le début de son voyage inaugural en fait
Il y a eu un petit coup de vent et pouf ça y est il a sombré quoi
Il a été renfloué 300 ans plus tard en très bon état
puisqu'il n'y avait aucun problème sur le bateau lui même, il a juste coulé
on va voir pourquoi et comment
Donc, pourquoi ?
D'abord le premier problème du Vasa c'était son client
(rires)
oui j'ai des blagues à la con dans mes slides :)
le client c'était le roi, le roi Gustave II Aldophe de Suède
et il a imposé des spécifications qui relevaient de la compétence du constructeur
donc par exemple les dimensions, le nombre de canons, etc.
et en plus de ça il a compressé les deadlines
il a envoyé pas mal de lettres pour mettre de la pression sur le constructeur
il était Roi donc par conséquent assez difficile à contredire comme client
et paradoxalement il n'aura visité le chantier qu'une seule fois
Et pour ne rien arranger le cahier des charges, entre guillemets,
n'était pas très bien établi et une grand partie n'était pas du tout écrite
des parties cruciales ont changé en cours de route
et l'un des constructeurs est même décédé avant la fin
ce qui n'aide pas quand on a pas écrit les specs
Manque d'expérience des constructeurs par rapport aux demandes aussi
puisque les suédois étaient pas habitués à construire ce genre de bateau
n'a pas aidé et du coup le bateau était mal équilibré
et c'est pour ça qu'il a coulé entres autres.
Et le pire dans tout ça, c'est les avertissements
puisqu'il y a eu une démonstration notamment de la stabilité du bateau
qui a été effectuée pas très longtemps avant le naufrage
et cette démonstration a été rapidement avortée en fait
puisque le navire commencer à se renverser, à tanguer, etc.
Donc le vice-amiral qui était présent
il a constaté le problème
il a fait annulé le test
et il a pas du tout fait remonter le problème
il avait peur de faire contredire le roi
et de l'autre côté le capitaine du bateau
qui était présent pendant les manoeuvres
il a pas tenu compte du problème plus tard dans le voyage inaugural
et donc pendant le voyage inaugural la première chose qu'il a fait
il a fait tirer une salve de canons sur un des côtés du bateau
et ça a pas aidé à l'équilibre du bateau
puisque c'est comme ça qu'il a commencé à pencher.
Donc tout ça pour dire : pour éviter que votre projet coule
il faudrait essayer d'établir un cahier des charges précis et clair
alors j'ai pas utilisé le mot spécification
parce qu'on disait ce matin que les specs de toute façons
il faut pas vraiment en faire c'est cadeau
ce qui est important c'est de savoir ce qu'on fait
et surtout si on se rend compte qu'on est en train de partir en live
au lieu d'ignorer les problèmes
ou au lieu d'ignorer les implications que ça peut avoir
il faut essayer de remettre en cause
le bout qu'il faut remettre en cause
pour éviter donc que ça aille complètement en live
donc par exemple l'un des problèmes c'était
les historiens sont pas forcément d'accord avec ça donc je vais faire une
je vais comment dire… tordre un peu l'histoire
l'un des débats c'était de savoir est-ce que le nombre de canons
était prévu initialement comme ça ou pas
et ce genre de trucs a empêché comment dire …
a conduit au final au déséquilibre du bateau.
Dans les autres trucs, quelle que soit votre responsabilité, il faut l'exercer
il faut la faire remonter dans la hiérarchie,
et aussi à l'inverse si vous êtes responsables de quoi que ce soit
ben il faut écouter les gens qui sont en dessous
et s'ils vous font remonter des problèmes, il faut en tenir compte
Par exemple, j'avais dit que j'allais pas faire de vengeance
mais il y a un chef de projet passé qui m'a fait une réflexion à un moment donné
et qui me disait "toi tu n'es que simple développeur"
oui ben je suis que simple développeur
mais je suis quand même bien placé pour me rendre compte des problèmes du projet
donc s'il vous plaît écoutez vos développeurs
écoutez vos intégrateurs
écoutez vos graphistes
ils sont les mieux placés pour vous parler des problèmes de votre projet
Et donc testez, dialoguez, soyez réactifs
essayez de bien réagir à ce genre de choses
voilà, c'est tout