-
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
