Real Options: quand et comment

(ne pas) prendre des décisions Pascal Van Cauwenberghe

Donne des conseils

Gère des projets

Programme

Crée des Jeux

Raconte des histoires

Organise des Conférences @pascalvc

http://blog.nayima.be http:/www.xpday.net

http:/www.atbru.be

Agile Open

http://agileopen.net

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

Il était une fois...

http://www.flickr.com/photos/seandreilinger/2187892869

http://www.flickr.com/photos/rohdesign/3307874546

Jeu Video

Site Social

Le projet (1)

http://www.flickr.com/photos/rohdesign/3307874546

Le site

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.

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

CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES

LE NIOUZE

Redesign

de tous les

sites!

Le “vieux” design jaune

sera remplacé par un

design bleu cool, fresh et

clair

Template:

www.presentationmagazine.com

Le Redesign

http://www.flickr.com/photos/rohdesign/3307874546

La réaction

Chiffre de vente (estimé)

t

#

http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg

http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg

1. Cost of Delay

t

€

Les redesigns précédents

Creative Process

Problème

Générer des

options

Tester et choisir

des options

Implémenter

MOA

Maitrise d’ouvrage

MOE

Maitrise d’oeuvre

Creative Process

Creative Process chez nous

N’essayez pas de décider

trop vite!

2. The Creative Process

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

Real Options Team to the

Rescue!

“Donnez nous un jour et on vous dira quand et comment décider”

Olav Chris Chris

Quel est le problème? Cost of Delay: un retard (même d’un jour)

peut nous coûter 50% des ventes

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

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

Comparons les options

Option Valeur Coût Prix Expiration

Bleu Design

consistent

??? / ???

Jaune +

Bleu

Risque

réduit de

délai

??? Redesign

en bleu

???

Quand est-ce qu’il faut

décider?

Option jaune + bleu ???

Option bleu ???

Dec Nov

Stockage

Magasin

Oct

Production

DVD

Serveurs

???? Mars

On est ici!

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”

Quand est-ce qu’il faut

décider?

Option jaune + bleu ???

Option bleu ???

Dec Nov

Stockage

Magasin

Oct

Production

DVD

Serveurs

Août Mars

On est ici!

Design et

test

(2M)

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

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.

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”

Quand est-ce qu’il faut

décider?

Option jaune + bleu ???

Option bleu ???

Dec Nov

Stockage

Magasin

Oct

Production

DVD

Serveurs

Août Mars

On est ici!

Design et

test

(2M)

Quand est-ce qu’il faut

décider?

Option jaune + bleu ???

Option bleu ???

Dec Nov

Stockage

Magasin

Oct

Production

DVD

Serveurs

Sept Mars

On est ici!

Design

et test

(1M)

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

Comparons les options

Option Valeur Coût Prix Expiration

Bleu Design

consistent

1 semaine de

refactoring

+ 2h de suivi /

2 semaines

/ 01/09/20XX

Jaune +

Bleu

Risque

réduit de

délai

1 semaine de

refactoring

+ 2h de suivi /

2 semaines

Redesign en

bleu (1 mois)

01/09/20XX

3. Real Options

Optimal Decision Process

Option Implement

er

Option

Option

Décisions Deadline

http://commitment-thebook.com/

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:

Et ils vécurent heureux à tout jamais

Encore une petite histoire?

Le projet (2)

http://www.flickr.com/photos/seeminglee/8276505285

p.s. La banque n’est pas HSBC

http://en.wikipedia.org/wiki/File:Rack001.jpg

Internet Banking Internet Banking servers

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?

Notre problème

Plateforme A

Implementer

Plateforme B

Decision

On est ici!

Pas assez de

temps

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

Notre solution

Implémenter

Plateforme A Finir

implementation

de la plateforme

choisie Implémenter

Plateforme B

Decision

On est ici!

Set-based development

APP

API

A

Server

B

Server

Test

Server

3 implementations en parallèle :

•Plateforme A

•Plateforme B

•Environnement de développement et test

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

Et ils vécurent...

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.

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

CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVES

LE NIOUZE

Redesign

de tous les

sites!

Le “vieux” design jaune

sera remplacé par un

design bleu cool, fresh et

clair

Template:

www.presentationmagazine.com

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!

A B B

C

Et ils vécurent heureux

4. Set-based development

Option

A

Option

B

Option

C

Mais c’est logique, capitaine!

Ce n’est que du bon sens!

Irrationnel, mais prévisible

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

Comment est-ce vous avez

survécu aussi longtemps?

5. On n’est pas rationnels,

mais on peut faire

semblant

Oui mais…

Les Options sont trop

chères

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

Le problème

Nouveau Système

On est ici

01/01/XXXX

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€

L’option “Plan B”

Nouveau Système

Mise à jour ancien

système ???

Décision

On est ici

01/01/XXXX

Implémenter

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

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

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

Décisions

architecturales

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.

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

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”

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

“Dans chaque mauvaise

décision, il se cache une

bonne décision.

Mais il faut chercher pour

la trouver.”

Mr Nobody

A boy faced with the consequences of choices...

A boy faced with the consequences of choices...

Chooses not to choose

“Mr. Nobody” a movie by Jaco Van Dormael

MERCI !

• Si vous voulez en savoir plus...

pascal@nayima.be

http://blog.nayima.be