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

3.
http://www.cafepress.com/+true-story+mugs

4.
Il était une fois...

5.
Le projet (1)
Site Social
Jeu Video
http://www.flickr.com/photos/rohdesign/3307874546
http://www.flickr.com/photos/seandreilinger/2187892869

6.
Le site
http://www.flickr.com/photos/rohdesign/3307874546

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

8.
Le Redesign
http://www.flickr.com/photos/rohdesign/3307874546

9.
La réaction

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

11.
1. Cost of Delay
€
t

12.
Les redesigns précédents

13.
Creative Process
Générer des
options
Problème
MOA
Maitrise d’ouvrage
Tester et choisir
des options
Implémenter
MOE
Maitrise d’oeuvre

14.
Creative Process

15.
Creative Process chez nous

16.
N’essayez pas de décider
trop vite!

17.
2. The Creative Process

18.
http://www.flickr.com/photos/miagant/5203621384

19.
Real Options Team to the
Rescue!
Olav
Chris
Chris
“Donnez nous un jour et on vous dira quand et comment décider”

20.
Quel est le problème?
Cost of Delay: un retard (même d’un jour)
peut nous coûter 50% des ventes

21.
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

22.
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

23.
Comparons les options
Option
Valeur
Bleu
Jaune +
Bleu
Coût
Prix
Expiration
Design
???
consistent
/
???
Risque
réduit de
délai
Redesign ???
en bleu
???

24.
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

25.
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” 

26.
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

27.
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

28.
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.

29.
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”

30.
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

31.
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

32.
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

33.
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

34.
3. Real Options
Optimal Decision Process
Décisions
Option
Option
Option
http://commitment-thebook.com/
Implement
er
Deadline

35.
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:

36.
Et ils vécurent heureux à tout jamais

37.
Encore une petite histoire?

38.
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

39.
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?

40.
Notre problème
On est ici!
Decision
Plateforme A
Pas assez de
Implementer
temps
Plateforme B

41.
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 

42.
Notre solution
On est ici!
Decision
Implémenter
Plateforme A
Implémenter
Plateforme B
Finir
implementation
de la plateforme
choisie

43.
Set-based development
APP
3 implementations en parallèle :
•Plateforme A
•Plateforme B
•Environnement de développement et test
API
A
Server
B
Server
Test
Server

44.
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...

45.
Et ils vécurent...

46.
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

47.
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

48.
Et ils vécurent heureux

49.
4. Set-based development
Option
A
Option
B
Option
C

50.
Mais c’est logique, capitaine!

51.
Ce n’est que du bon sens!

52.
Irrationnel, mais prévisible

53.
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!”

54.
Comment est-ce vous avez
survécu aussi longtemps?

55.
5. On n’est pas rationnels,
mais on peut faire
semblant

56.
Oui mais…
Les Options sont trop
chères

57.
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..

58.
Le problème
On est ici
Nouveau Système
01/01/XXXX

59.
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€

60.
L’option “Plan B”
On est ici
Décision
Nouveau Système
Mise à jour ancien
système ???
Implémenter
01/01/XXXX

61.
NON !
“L’échec n’est pas une option”

62.
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...

63.
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

64.
Décisions
architecturales

65.
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.

66.
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

67.
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”

68.
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

69.
“Dans chaque mauvaise
décision, il se cache une
bonne décision.
Mais il faut chercher pour
la trouver.”

70.
Mr Nobody
A boy faced with the consequences of choices...

71.
A boy faced with the consequences of choices...
Chooses not to choose
“Mr. Nobody” a movie by Jaco Van Dormael

72.
MERCI !
• Si vous voulez en savoir plus...
pascal@nayima.be
http://blog.nayima.be