devoxx fr 2013 real options - comment et quand (ne pas) prendre des décisions
DESCRIPTION
Quelques histoires qui illustrent comment utiliser Real Options et autres outils intellectuels pour décider quand et comment déciderTRANSCRIPT
13:30h – 14:20h - Salle La Seine A
Real Options:Quand et comment (ne
pas) prendre des décisions
27 au 29 mars 2013
Real Options:Quand et comment (ne pas)
prendre des décisions
Pascal Van Cauwenberghe
@pascalvc
NAYIMAWe make play work
27 au 29 mars 2013
Donne des conseilsGère des projetsProgramme
Crée des JeuxOrganise des Conférences
http:/www.xpday.net
27 au 29 mars 2013http://www.cafepress.com/+true-story+mugs
27 au 29 mars 2013
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
A la une
Redesign de tous les sites!Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair
Le Redesign
http://www.flickr.com/photos/rohdesign/3307874546
La reaction
http://browse.deviantart.com/art/Edvard-Munchs-Homer-71026771
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
27 au 29 mars 2013
1. Cost of Delay
t
€
Les redesigns précedents
Creative Process
Problème
Generer desoptions
Tester et choisirdes options
Implémenter
MOAMaitrise d’ouvrage
MOEMaitrise d’oeuvre
Creative Process
Creative Process chez nous
N’essayez pas de décider trop vite!
27 au 29 mars 2013
2. The Creative Process
Entretemps...
http://browse.deviantart.com/art/Edvard-Munchs-Homer-71026771
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 couter 50% des ventes
Real Options
Le options• Ont un cout• Ont une valeur• Ont un prix (quand on exerce l’option)• Ont une date d’expiration
Une option n’est pas une obligation
Ceci est une métaphore
Quelles sont nos options?
1. Aller en production avec le 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, 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 Cout Prix Valeur Expiration
Bleu ??? / Design consistent
???
Jaune + Bleu
??? Redesign en bleu
Cost of Delay == 0
???
Quand est-ce qu’il faut décider?
Option jaune + bleu ???
Option bleu ???
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
????Mars
On est ici!
Quelques 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
Design et test(2M)
Option bleu
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
AoûtMars
On est ici!
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
blue est moins que deux moisALORS on applique le design bleuSINON 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 coute combien pour améliorer l’architecture?• “On peut faire cela en quelques jours”• “Après, un redesign ne coutera jamais plus qu’un mois”
Quand est-ce qu’il faut décider?
Option jaune + bleu
Design et test(2M)
Option bleu
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
AoûtMars
On est ici!
Quand est-ce qu’il faut décider?
Option jaune + bleu
Design et test(1M)
Option bleu
DecNov
StockageMagasin
Oct
Production DVD
Serveurs
SepMars
On est ici!
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 coute plus qu’un mois
au lieu de deux
Rendez-vous pour la décision: 1er septembre
Comparons les options
Option Cout Prix Valeur Expiration
Jaune + Bleu
1 semaine de refactoring+ 2h de suivi / 2 semaines
Redesign en bleu (1 mois)
Cost of Delay == 0
01/09/20XX
Bleu 1 semaine de refactoring+ 2h de suivi / 2 semaines
/ Design consistent
01/09/20XX
27 au 29 mars 2013
3. Real Options Optimal Decision Process
Option Implementer
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) => design jaune• Projet livré à temps• “Ce project était beaucoup moins stressant que les
précedents”• Fonctionalité: • Design:
27 au 29 mars 2013
Et ils vécurent heureux à tout jamais
Le projet (2)
http://www.flickr.com/photos/seeminglee/8276505285p.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• On est en train de décider sur quelle platforme• On est en train de la documenter la DB que vous devez utiliser• On est en train de rédiger le cahier de charge
• 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• Implementation A est allée en production à temps• Implementation dev/test continue à être utilisée
pendant le développement• Implementation B na servi à rien
• A suivre...
Un peu plus tard
• Vendeur 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 BBC
27 au 29 mars 2013
4. Set-based development
Option A
Option B
Option C
Le projet (3)
• J’arrive sur le projet• Le projet est déjà en retard: 12 mois au lieu de 9• Exercice rapide de scoping et estimation...• => Il faut encore +/- 6 mois pour compléter le projet• Est-ce qu’on continue ou est-ce qu’on arrête?
Est-ce que ça vaut la peine?
Temps Coût
Déjà investi 12 mois 1,000,000€
A investir 6 mois 500,000€
Valeur 18 mois X€
Sunk Cost(*) Fallacy (*) couts irrécuperables, couts échoués
• Investissement 1,000,000€ => 0€ de valeur• Oubliez l’argent qui a déjà été investi, cet argent est
perdu
• “On a déjà dépensé 1,000,000€”• En comparaison 500,000€ ne semble pas beaucoup
• Comparez delta coût et delta valeur• +500,000€ de coût => +X€ de valeur – 9 mois de cost of delay
27 au 29 mars 2013
5. Sunk Cost FallacyMarginal Economics
Emotional Sunk Cost Fallacy
• Il y a aussi les investissements immateriels:• Temps de l’équipe• Reputation• Investissement emotionnel dans son produit• Sécurité financière
• Tenez compte du sunk cost quand vous proposez un changement• Surtout: quel est votre sunk cost?
Mais ce n’est pas logique, capitaine!
Irrationnel et fier de l’être
• Valeur(ce qu’on a) > Valeur(ce qu’on n’a pas)• Couts > Bénéfices• Valeur = f(prix) + g(nos attentes)• On gere mieux les chiffres relatifs que les chiffres
absoluts• Les options peuvent nous distraire de notre but• On ne sait pas choisir s’il y a trop de choix• ....• Comment prendre des décisions rationelles avec des
êtres (et des groupes) irrationnels?
27 au 29 mars 2013
6. On n’est pas rationnels, mais on peut faire semblant
27 au 29 mars 2013
Encore une histoire?
OUI NON
Le projet (4)
http://www.flickr.com/photos/caseorganic/3216853440 http://www.flickr.com/photos/danielfoster/4725849931
EDI
Vendeurs Fabricants
La situation (avant)
EDIVendeur
IMPL
Fabricant
IMPL
Les problèmes de nos clients
• Ceux qui veulent utiliser la plateforme doivent connecter leurs systèmes et implementer 1 API• Et puis nous configurons/customisons la plateforme
• Pour les vendeurs et fabricants de cette industrie c’est un “grand projet”• Les vendeurs et fabricants ne tiennent pas leur planning•Donc notre planning de customisation ne sert à rien
• Une intégration dure longtemps, donc retour sur investissement tardif
Et si c’était notre problème?
• Si chaque flux est indépendent, chaque integration est un petit projet• Si on peut customiser rapidement un flux pour un
client, on n’a plus besoin du planning du client• Si on peut mettre les customisations rapidement en
production, le client a un retour sur investissement rapide et incremental
La situation (après) - Technique
EDIVendeur
IMPL
Fabricant
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
IMPL
La situation (après) - Technique
• Chaque flux est un composant indépendant. Mais si le client en a implementé plus qu’un ils coopèrent.• Par exemple: il y a un flux pour les données catalogue
et un flux pour les commandes qui sont indépendants. Si on a les deux, le composant “catalogue” peut faire des validations et augmentations pendant la commande• On est passé d’une architecture “pipe et filter” vers
“blackboard”• On avait déjà un système continuous delivery
La situation (après) - clients
• Le client a l’option de faire une intégration incrementale• Dans l’ordre qu’il veut
• Le client ne doit plus nous donner de planning, ils annoncent quand un flux est prêt• On customise, test et met en production immédiatement
• Le client reçoit de la valeur avec chaque flux
• => La plateforme devient plus facile à vendre
C’est quoi l’architecture?
“L’architecture c’est les décisions qui sont difficiles à changer et qu’il faut prendre au début du projet”
Pour de telles décisions• Ou bien on rend la décision facile à changer• Ou bien on retarde le point de décision• Et je suis prêt à payer pour des options qui ont de la
valeur
“Oui mais... Il y a des choses qu’on ne peut pas changer”
Hola Hop, Barbatruc
EDIVendeurs Fabricants
“Et si on changait de plateforme et langage? Sans arreter le système, bien sur!”
“Impossible!”
Gestion
Changer de plateforme et de langage • D’abord des prototypes pour apprendre• Puis on aborde la partie avec le moins de risque
client• On garde et maintient l’ancien composant pendant la
transition• On peut toujours revenir un (petit) pas en arrière• Deployment continu et développement incrémental
réduisent la complexité et le risque
27 au 29 mars 2013
7. Quelle est la valeur ajoutée pour le client de votre architecture et votre
processus?
Techniques utiles (1)
• Cost of Delay:• Quel est l’effet d’une livraison retardée ou avancée?
• Creative Process:• Générer des options, puis selectionner les options
• Options:• Cout, prix, valeur, date d’expiration
• Optimal Decision Process:•Moment de décision = deadline – temps d’implementation
Techniques utiles (2)
• Variation Separation:• Séparez les éléments qui varient à des vitesses différentes
• Set-based design:• Faire la même chose de 3 façons peut être moins cher q’une
• Sunk Cost Fallacy:• Oubliez combien vous avez déjà investi
• Créez des options pour vos clients
27 au 29 mars 2013
Décisions architecturales“Le principe du bon moment”
Décisions faciles à changer: décidez tôtDécisions difficiles à changer: décidez tard
“Le principe de l’effort minimal”
Ne faites pas le travail de demain aujourd’huiNe faites rien aujourd’hui qui entrave le travail de
demain
Une bonne architecture crée des options pour votre équipe, votre organisation et vos clients
Les systèmes patrimoniaux ont de moins en moins options
27 au 29 mars 2013
“Dans chaque mauvaise décision, il se cache une bonne décision”Donald Reinertsen
27 au 29 mars 2013
MERCI !
Si vous voulez en savoir plus...
27 au 29 mars 2013
27 au 29 mars 2013