1. Real Options: quand et comment
(ne pas) prendre des décisions
Pascal Van Cauwenberghe
2. Donne des conseils
Gère des projets
Programme
Agile Open
http://agileopen.net
http:/www.atbru.be
@pascalvc
http://blog.nayima.be
Crée des Jeux
Raconte des histoires
Organise des Conférences
http:/www.xpday.net
7. LE NIOUZE
CELEBRITY NEWS AND GOSSIP
WORLD EXCLUSIVES
NOUVEAU DESIGN !!
L'analyse par les Options Réelles est
une technique qui permet de prendre
des décisions sur les décisions. C'est
cool, c'est meta.
Redesign
de tous les
sites!
Le “vieux” design jaune
sera remplacé par un
design bleu cool, fresh et
clair
Mais quel est l'intéret pour l'équipe au
quotidien ?
Vous prenez plein de décisions
chaque jour comme développeur ou
architecte. Des décisions qui peuvent
couter cher.
Les Options Réelles ne sont pas très
compliquées, cela s'explique en
quelques minutes. Mais en appliquant
les Options Réelles sur les projets
informatiques et sur l'architecture des
logiciels j'ai découvert que plein de
choses que je croyais vraies ou qui
me semblaient intuitivement
correctes étaient fausses.
J'illustre chaque technique avec des
exemples qui viennent de projets
auxquels j'ai participé les dernières
années, ou bien de la vie de tous les
jours.
Découvrez une autre façon de voir les
décisions, des techniques simples
pour gérer des projets ou définir une
architecture de logiciel. Vous
découvrirez peut-être que vous aussi
croyez des choses qui sont fausses.
Au minimum vous entendrez
quelques histoires belges... :-)
Template:
www.presentationmagazine.com
10. Chiffre de vente (estimé)
#
http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg
http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg
t
20. Real Options Team to the
Rescue!
Olav
Chris
Chris
“Donnez nous un jour et on vous dira quand et comment décider”
21. Quel est le problème?
Cost of Delay: un retard (même d’un jour)
peut nous coûter 50% des ventes
22. Real Options
Les Real Options
Ont une valeur
Ont un coût (= le prix de l’option)
Ont un prix (“strike price”) quand on exerce l’option
Ont une date/condition d’expiration
~ “Call Option”
Une option n’est pas une obligation
Ceci est une métaphore
23. Quelles sont nos options?
1. Aller en production avec le nouveau design bleu
•
•
Oui mais, on risque d’être en retard s’il faut attendre que
le design bleu soit stabilisé
Oui mais, entre temps il y aura plein de changements
dans le design
2. Aller en production avec le design jaune existant,
puis retravailler avec le design bleu
•
•
Oui mais, ce ne sera pas consistent
Oui mais, le retravail va augmenter le budget
25. Quand est-ce qu’il faut
décider?
On est ici!
Option jaune + bleu ???
Production
DVD
Stockage
Magasin
Serveurs
Option bleu ???
Mars
????
Oct
Nov
Dec
26. Questions aux développeurs
• Est-ce qu’il faut appliquer le design immédiatement?
• “On l’a toujours fait dès le début, mais on pourrait le faire
plus tard”
• Combien de temps est-ce qu’il faut pour appliquer le
design jaune?
• “A peu près un mois”
• Combien de temps pour un design vraiment
compliqué?
• “Moins de 2 mois”
• Imaginez le pire design que les créatifs peuvent
inventer
• Rire. “Deux mois. On a de l’expérience avec ce type de
design”
27. Quand est-ce qu’il faut
décider?
On est ici!
Option jaune + bleu ???
Production
DVD
Design et
test
(2M)
Serveurs
Option bleu ???
Mars
Stockage
Magasin
Août
Oct
Nov
Dec
28. Comment est-ce qu’on va
décider?
• SI le nouveau design bleu est complètement stable
• ET si l’estimation de la charge de travail du design
bleu est moins que deux mois
• ALORS on applique le design bleu
• SINON on applique l’ancien design jaune et on
planifiera le redesign bleu quand il sera stable
• Rendez vous: 1er Août
29. Et entre temps...
• On développe le site en “noir et blanc”
• Un membre de l’équipe participe aux réunions de suivi
du redesign (2h toutes les 2 semaines) et tient l’équipe
au courant de la situation.
30. La journée n’est pas encore
finie
• On a encore quelques questions:
• Développeurs, qu’est-ce qu’il faut changer quand
le design change?
• Développeurs montrent l’architecture et le code
• Et s’il y avait moins à changer?
• Petit spike architectural: séparation, déduplication...
• Ca coûte combien pour améliorer l’architecture?
• “On peut faire cela en quelques jours”
• “Après, un redesign ne coûtera jamais plus qu’un
mois”
31. Quand est-ce qu’il faut
décider?
On est ici!
Option jaune + bleu ???
Production
DVD
Design et
test
(2M)
Serveurs
Option bleu ???
Mars
Stockage
Magasin
Août
Oct
Nov
Dec
32. Quand est-ce qu’il faut
décider?
On est ici!
Option jaune + bleu ???
Production
DVD
Design
et test
(1M)
Serveurs
Option bleu ???
Mars
Stockage
Magasin
Sept
Oct
Nov
Dec
33. L’avantage de réduire le
temps de cycle
• On peut décider encore un mois plus tard
• On a un mois de plus pour implémenter la
fonctionnalité
• Un redesign jaune -> bleu ne coûte plus qu’un mois au
lieu de deux
• Rendez-vous pour la décision: 1er septembre
34. Comparons les options
Option
Valeur
Coût
Prix
Bleu
Design
1 semaine de /
consistent refactoring
+ 2h de suivi /
2 semaines
Jaune +
Bleu
Risque
réduit de
délai
Expiration
01/09/20XX
1 semaine de Redesign en 01/09/20XX
refactoring
bleu (1 mois)
+ 2h de suivi /
2 semaines
35. 3. Real Options
Optimal Decision Process
Décisions
Option
Option
Option
http://commitment-thebook.com/
Implement
er
Deadline
36. Retro
• 1 septembre: le design bleu n’est pas stable (ce n’était
pas une surprise). On utilise le design jaune
• Projet livré à temps
• “Ce projet était beaucoup moins stressant que les
précédents”
• Fonctionnalité:
• Design:
39. Le projet (2)
Internet Banking
http://www.flickr.com/photos/seeminglee/8276505285
p.s. La banque n’est pas HSBC
Internet Banking servers
http://en.wikipedia.org/wiki/File:Rack001.jpg
40. Votre mission, si vous
l’acceptez...
• On lance notre service online banking le
DD/MM/YYYY
• Société X va développer l’application web
• Vous devez livrer l’application serveur à temps
• Petits détails...
• On est en train de décider sur quelle plateforme
• On est en train de la documenter la DB que vous
devez utiliser
• On est en train de rédiger le cahier des charges
• “Mais commencez déjà à développer, car on n’a pas
beaucoup de temps!”
• Accepteriez vous cette mission?
41. Notre problème
On est ici!
Decision
Plateforme A
Pas assez de
Implementer
temps
Plateforme B
42. Notre solution
• Si on n’a pas assez de temps pour implémenter
plateforme A OU plateforme B
• On va implémenter plateforme A ET B
• C’est logique... En Belgique
43. Notre solution
On est ici!
Decision
Implémenter
Plateforme A
Implémenter
Plateforme B
Finir
implementation
de la plateforme
choisie
45. Retro
• Décision: plateforme A
• Implémentation A est allée en production à temps
• Implémentation dev/test continue à être utilisée
pendant le développement
• Implémentation B na servi à rien
• A suivre...
47. LE NIOUZE
CELEBRITY NEWS AND GOSSIP
WORLD EXCLUSIVES
EDITEUR B BOUFFE EDITEUR A
L'analyse par les Options Réelles est
une technique qui permet de prendre
des décisions sur les décisions. C'est
cool, c'est meta.
Redesign
de tous les
sites!
Le “vieux” design jaune
sera remplacé par un
design bleu cool, fresh et
clair
Mais quel est l'intérêt pour l'équipe au
quotidien ?
Vous prenez plein de décisions
chaque jour comme développeur ou
architecte. Des décisions qui peuvent
couter cher.
Les Options Réelles ne sont pas très
compliquées, cela s'explique en
quelques minutes. Mais en appliquant
les Options Réelles sur les projets
informatiques et sur l'architecture des
logiciels j'ai découvert que plein de
choses que je croyais vraies ou qui
me semblaient intuitivement
correctes étaient fausses.
J'illustre chaque technique avec des
exemples qui viennent de projets
auxquels j'ai participé les dernières
années, ou bien de la vie de tous les
jours.
Découvrez une autre façon de voir les
décisions, des techniques simples
pour gérer des projets ou définir une
architecture de logiciel. Vous
découvrirez peut-être que vous aussi
croyez des choses qui sont fausses.
Au minimum vous entendrez
quelques histoires belges... :-)
Template:
www.presentationmagazine.com
48. Un peu plus tard
• Editeur de plateforme B envoit une lettre à la banque:
“Bonne nouvelle! Nous venons d’acquérir la plateforme A.
Tout développement sur cette plateforme est arrêté. Le
support sera arrêté bientôt.
Veuillez migrer vers la plateforme B.”
• Facile!
C
A
B
B
55. Predictably Irrational
• Sunk Cost Fallacy
• “Il ne faut pas mettre du bon argent sur du mauvais”
• On ne sait pas estimer des valeurs absolues
• Mais l’estimation relative, ça va
• Nous sur-estimons la valeur de ce qu’on a
• Et nous sur-estimons le coût du changement
• Notre modèle d’escompte est buggé
• Aujourd’hui versus demain
• Trop de choix nous rend angoissé
• On n’aime pas l’incertitude
• “Je préfère une mauvaise décision à pas de décision!”
59. Un autre projet
• Une loi européenne sur la TVA change le 01/01/YYYY
• Le système actuel n’est pas compatible avec la loi
• On construit un système de remplacement
• Qu’est-ce qui se passe si on livre en retard?
• Cost of Delay?
• La fin de l’année n’est plus loin..
61. Est-ce qu’on peut acheter
une option “Plan B”?
• Est-ce qu’il y a un “Plan B” ?
• Option: on demande à l’éditeur un prix et une date
d’expiration pour mettre à jour l’ancienne application
• Mon estimation: cette option coûte < 1000€
62. L’option “Plan B”
On est ici
Décision
Nouveau Système
Mise à jour ancien
système ???
Implémenter
01/01/XXXX
64. Et puis...?
• Le nouveau système n’est pas prêt en décembre
• On ne peut plus facturer nos clients
• Chaque mois de délai: perte de X00.000€
• Mais on a économisé quelques milliers d’euros sur les
options...
65. Qu’est-ce qu’on a appris ?
•
•
•
•
Il faut gérer le processus créatif
Voir les décisions difficiles comme des options
Ne décidez pas. Decidez quand et comment décider.
Parfois, faire tout est la bonne option
• Pour avoir plus d’information
• Considérez d’abord valeur, puis le coût
• Ce outils m’aident à rester calme dans des situations
stressantes
• Keep it simple:
• Mon outil de gestion d’options: Google Calendar
67. Tout ce que vous avez appris
sur l’architecture est faux!
“L’Architecture c’est toutes les décisions
qu’il faut prendre tôt parce qu’elles sont
difficiles à défaire”
Le problème: tôt dans chaque projet on
n’a pas assez d’information pour prendre
les décisions correctes. Et puis, le
monde change.
68. Principe du bon moment
Décision facile à changer: décidez tôt
Décision difficile à changer:
• Rendez la plus facile à changer
• Décidez le plus tard possible
69. Principe de l’effort minimal
Ne faites pas le travail de demain
aujourd’hui (YAGNI)
ET
Ne faites rien aujourd’hui qui entrave le
travail de demain
“Le principe du fainéant”
70. Une bonne architecture...
Une bonne architecture crée des options
pour votre équipe, votre organisation et
vos clients
Créer et maintenir les options ce fait tous
les jours, à petits pas
Sinon, vous créez des systèmes legacy
qui ont de moins en moins options