Real Options - Agile France 2013

1,873 views
1,752 views

Published on

How to use Real Options and related thinking tools to take architectural decisions and bring a happy ending to your project

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,873
On SlideShare
0
From Embeds
0
Number of Embeds
371
Actions
Shares
0
Downloads
25
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Real Options - Agile France 2013

  1. 1. Real Options: quand et comment(ne pas) prendre des décisionsPascal Van Cauwenberghe11:40h – 12:40h Salle Belvédère#AgileFrance
  2. 2. Donne des conseilsGère des projetsProgrammeCrée des JeuxOrganise des Conférences@pascalvchttp://blog.nayima.behttp:/www.xpday.nethttp:/www.atbru.be
  3. 3. http://www.cafepress.com/+true-story+mugs
  4. 4. Il était une fois...
  5. 5. http://www.flickr.com/photos/seandreilinger/2187892869http://www.flickr.com/photos/rohdesign/3307874546Jeu VideoSite SocialLe projet (1)
  6. 6. http://www.flickr.com/photos/rohdesign/3307874546Le site
  7. 7. NOUVEAU DESIGN !!Lanalyse par les Options Réelles estune technique qui permet de prendredes décisions sur les décisions. Cestcool, cest meta.Mais quel est lintéret pour léquipe auquotidien ?Vous prenez plein de décisionschaque jour comme développeur ouarchitecte. Des décisions qui peuventcouter cher.Les Options Réelles ne sont pas trèscompliquées, cela sexplique enquelques minutes. Mais en appliquantles Options Réelles sur les projetsinformatiques et sur larchitecture deslogiciels jai découvert que plein dechoses que je croyais vraies ou quime semblaient intuitivementcorrectes étaient fausses.Jillustre chaque technique avec desexemples qui viennent de projetsauxquels jai participé les dernièresannées, ou bien de la vie de tous lesjours.Découvrez une autre façon de voir lesdécisions, des techniques simplespour gérer des projets ou définir unearchitecture de logiciel. Vousdécouvrirez peut-être que vous aussicroyez des choses qui sont fausses.Au minimum vous entendrezquelques histoires belges... :-)CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVESLE NIOUZERedesignde tous lessites!Le “vieux” design jaunesera remplacé par undesign bleu cool, fresh etclairTemplate:www.presentationmagazine.com
  8. 8. Le Redesignhttp://www.flickr.com/photos/rohdesign/3307874546
  9. 9. La réaction
  10. 10. Chiffre de vente (estimé)t#http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpghttp://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg
  11. 11. 1. Cost of Delayt€
  12. 12. Les redesigns précédents
  13. 13. Creative ProcessProblèmeGénérer desoptionsTester et choisirdes optionsImplémenterMOAMaitrise d’ouvrageMOEMaitrise d’oeuvre
  14. 14. Creative Process
  15. 15. Creative Process chez nous
  16. 16. N’essayez pas de décidertrop vite!
  17. 17. 2. The Creative Process
  18. 18. http://www.flickr.com/photos/miagant/5203621384
  19. 19. Real Options Team to theRescue!“Donnez nous un jour et on vous dira quand et comment décider”Olav Chris Chris
  20. 20. Quel est le problème?• Cost of Delay: un retard (même d’un jour) peut nouscoûter 50% des ventes
  21. 21. Real OptionsLes Real OptionsOnt un coût (= le prix de l’option)Ont une valeurOnt un prix (“strike price”) quand on exerce l’optionOnt une date/condition d’expiration~ “Call Option”Une option n’est pas une obligationCeci est une métaphore
  22. 22. Quelles sont nos options?1. Aller en production avec le design bleu• Oui mais, on risque d’être en retard s’il faut attendre quele design bleu soit stabilisé• Oui mais, entre temps il y aura plein de changementsdans le design2. Aller en production avec le design jaune, puisretravailler avec le design bleu• Oui mais, ce ne sera pas consistent• Oui mais, le retravail va augmenter le budget
  23. 23. Comparons les optionsOption Coût Prix Valeur ExpirationBleu ??? / Designconsistent???Jaune +Bleu??? Redesignen bleuCost ofDelay == 0???
  24. 24. Quand est-ce qu’il fautdécider?Option jaune + bleu ???Option bleu ???DecNovStockageMagasinOctProductionDVDServeurs????MarsOn est ici!
  25. 25. Quelques questions auxdé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 faireplus tard”• Combien de temps est-ce qu’il faut pour appliquer ledesign jaune?• “A peu près un mois”• Combien de temps pour un design vraimentcompliqué?• “Moins de 2 mois”• Imaginez le pire design que les créatifs peuventinventer• Rire. “Deux mois. On a de l’expérience avec ce type dedesign” 
  26. 26. Quand est-ce qu’il fautdécider?Option jaune + bleu ???Option bleu ???DecNovStockageMagasinOctProductionDVDServeursAoûtMarsOn est ici!Design ettest(2M)
  27. 27. Comment est-ce qu’on vadécider?• SI le nouveau design bleu est complètement stable• ET si l’estimation de la charge de travail du designbleu est moins que deux mois• ALORS on applique le design bleu• SINON on applique l’ancien design jaune et onplanifiera le redesign bleu quand il sera stable• Rendez vous: 1er Août
  28. 28. Et entre temps...• On développe le site en “noir et blanc”• Un membre de l’équipe participe aux réunions de suividu redesign (2h toutes les 2 semaines) et tient l’équipeau courant de la situation.
  29. 29. La journée n’est pas encorefinie• On a encore quelques questions:• Développeurs, qu’est-ce qu’il faut changer quandle 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’unmois”
  30. 30. Quand est-ce qu’il fautdécider?Option jaune + bleu ???Option bleu ???DecNovStockageMagasinOctProductionDVDServeursAoûtMarsOn est ici!Design ettest(2M)
  31. 31. Quand est-ce qu’il fautdécider?Option jaune + bleu ???Option bleu ???DecNovStockageMagasinOctProductionDVDServeursSeptMarsOn est ici!Designet test(1M)
  32. 32. L’avantage de réduire letemps de cycle• On peut décider encore un mois plus tard• On a un mois de plus pour implémenter lafonctionnalité• Un redesign jaune -> bleu ne coûte plus qu’un mois aulieu de deux• Rendez-vous pour la décision: 1er septembre
  33. 33. Comparons les optionsOption Coût Prix Valeur ExpirationJaune +Bleu1 semaine derefactoring+ 2h de suivi /2 semainesRedesignen bleu (1mois)Cost ofDelay == 001/09/20XXBleu 1 semaine derefactoring+ 2h de suivi /2 semaines/ Designconsistent01/09/20XX
  34. 34. 3. Real OptionsOptimal Decision ProcessOption ImplementerOptionOptionDécisions Deadlinehttp://commitment-thebook.com/
  35. 35. Retro• 1 septembre: le design bleu n’est pas stable (ce n’étaitpas une surprise). On utilise le design jaune• Projet livré à temps• “Ce projet était beaucoup moins stressant que lesprécédents”• Fonctionnalité:• Design:
  36. 36. Et ils vécurent heureuxà tout jamais
  37. 37. Encore une petite histoire?
  38. 38. Le projet (2)http://www.flickr.com/photos/seeminglee/8276505285p.s. La banque n’est pas HSBChttp://en.wikipedia.org/wiki/File:Rack001.jpgInternet Banking Internet Banking servers
  39. 39. Votre mission, si vousl’acceptez...• On lance notre service online banking leDD/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 vousdevez utiliser• On est en train de rédiger le cahier des charges• “Mais commencez déjà à développer, car on n’a pasbeaucoup de temps!”• Accepteriez vous cette mission?
  40. 40. Notre problèmePlateforme AImplementerPlateforme BDecisionOn est ici!Pas assez detemps
  41. 41. Notre solution• Si on n’a pas assez de temps pour implémenterplateforme A OU plateforme B• On va implémenter plateforme A ET B• C’est logique... En Belgique 
  42. 42. Notre solutionImplémenterPlateforme AFinirimplementationde la plateformechoisieImplémenterPlateforme BDecisionOn est ici!
  43. 43. Set-based developmentAPPAPIAServerBServerTestServer3 implementations en parallèle :•Plateforme A•Plateforme B•Environnement de développement et test
  44. 44. Retro• Décision: plateforme A• Implémentation A est allée en production à temps• Implémentation dev/test continue à être utiliséependant le développement• Implémentation B na servi à rien• A suivre...
  45. 45. Et ils vécurent...Ce n’est pas encore fini
  46. 46. EDITEUR B BOUFFE EDITEUR ALanalyse par les Options Réelles estune technique qui permet de prendredes décisions sur les décisions. Cestcool, cest meta.Mais quel est lintérêt pour léquipe auquotidien ?Vous prenez plein de décisionschaque jour comme développeur ouarchitecte. Des décisions qui peuventcouter cher.Les Options Réelles ne sont pas trèscompliquées, cela sexplique enquelques minutes. Mais en appliquantles Options Réelles sur les projetsinformatiques et sur larchitecture deslogiciels jai découvert que plein dechoses que je croyais vraies ou quime semblaient intuitivementcorrectes étaient fausses.Jillustre chaque technique avec desexemples qui viennent de projetsauxquels jai participé les dernièresannées, ou bien de la vie de tous lesjours.Découvrez une autre façon de voir lesdécisions, des techniques simplespour gérer des projets ou définir unearchitecture de logiciel. Vousdécouvrirez peut-être que vous aussicroyez des choses qui sont fausses.Au minimum vous entendrezquelques histoires belges... :-)CELEBRITY NEWS AND GOSSIP WORLD EXCLUSIVESLE NIOUZERedesignde tous lessites!Le “vieux” design jaunesera remplacé par undesign bleu cool, fresh etclairTemplate:www.presentationmagazine.com
  47. 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é. Lesupport sera arrêté bientôt.Veuillez migrer vers la plateforme B.”• Facile!A BBC
  48. 48. Et ils vécurent heureux
  49. 49. 4. Set-based developmentOptionAOptionBOptionC
  50. 50. Mais c’est logique, capitaine!
  51. 51. Ce n’est que du bon sens!
  52. 52. Irrationnel, mais prévisible
  53. 53. Sunk Cost(*) fallacy(*) coûts irrécupérables, coûts échoués• Tout ce qui est déjà investi est perdu• On ne devrait pas en tenir compte pour décider si oncontinue• Mais on accorde beaucoup de valeur à l’argent (et letemps) déjà investi• Solution: regarder les “deltas” de valeur et coût• “Marginal Economics” (Reinertsen, Flow)• Aussi: “Emotional Sunk Cost”
  54. 54. On ne sait pas estimer• On a du mal avec des chiffres absolus• On utilise des estimations relatives pourprendre des décisions• On surestime les coûts vs. bénéfice• Une fois qu’on a décidé on a peur de perdre cequ’on a• On surestime la valeur de ce qu’on a• Pour confirmer qu’on a fait un bon choix• On surestime la valeur dans le présent vs le futur• => Décisions qui favorisent le court terme
  55. 55. L’embarras du choix• Quand il y a beaucoup de choix on bloque• Plus de choix, plus de chance de setromper• Quand on a beaucoup d’options on perd devue le but• On passe tout son temps à la “chasse auxoptions”• Ne créez pas des solutions « génériques »
  56. 56. Et surtout...
  57. 57. On n’aime pas l’incertitude• Surtout en moments de stress• Ces outils m’aident à rester calme• Au lieu de décider on établit un plan pour décider:• Quand on prend quelles décisions• Comment on va prendre les décisions• Sur base de quelles données• Qui est impliqué• => On prend ces décisions rapidement et surement• Mon outil préféré pour gérer mes Real Options: moncalendrier
  58. 58. Comment est-ce vous avezsurvécu aussi longtemps?
  59. 59. 6. On n’est pas rationnels,mais on peut fairesemblant
  60. 60. Encore une histoire
  61. 61. Le projet (3)http://www.flickr.com/photos/caseorganic/3216853440 http://www.flickr.com/photos/danielfoster/4725849931EDIVendeurs Fabricants
  62. 62. La situation (avant)EDIVendeursIMPLFabricantsIMPL
  63. 63. Les problèmes de nos clients• Ceux qui veulent utiliser la plateforme doiventconnecter leurs systèmes et implémenter 1 API• Et puis nous configurons/customisons la plateforme• Pour les vendeurs et fabricants de cette industrie c’estun “grand projet”• Les vendeurs et fabricants ne tiennent pas leurplanning• Donc notre planning de customisation ne sert à rien• Une intégration dure longtemps, donc retour surinvestissement tardif
  64. 64. Et si c’était notre problème?• Si chaque flux est indépendant, chaque intégration estun petit projet• Si on peut customiser rapidement un flux pour unclient, on n’a plus besoin du planning du client• Si on peut mettre les customisations rapidement enproduction, le client a un retour sur investissementrapide et incrémental
  65. 65. La situation (avant)EDIVendeursIMPLFabricantsIMPL
  66. 66. La situation (après) -TechniqueEDIVendeursIMPLFabricantsIMPLIMPLIMPLIMPLIMPLIMPLIMPLIMPL
  67. 67. La situation (après)• Chaque flux est un composant indépendant.Mais si le client en a implémenté plus qu’un ilscoopèrent.• Par exemple: il y a un flux pour les données catalogue etun flux pour les commandes qui sont indépendants. Si on ales deux, le composant “catalogue” peut faire desvalidations 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
  68. 68. La situation (après) - clients• Le client a l’option de faire une intégrationincrémentale• Dans l’ordre qu’il veut• Le client ne doit plus nous donner de planning, ilsannoncent 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
  69. 69. 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 des décisions difficiles à changer• Ou bien on rend la décision facile à changer• Ou bien on retarde le point de décisionJe suis prêt à payer pour des options qui ont de lavaleur• “Oui mais... Il y a des choses qu’on ne peut paschanger”
  70. 70. Hola Hop, BarbatrucEDIVendeurs Fabricants“Et si on changait de plateforme et langage?Sans arreter le système, bien sur!”“Impossible!”Gestion
  71. 71. Changer de plateforme et delangage• 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 latransition• On peut toujours revenir un (petit) pas en arrière• Déploiement continu et développement incrémentalréduisent la complexité et le risque
  72. 72. Oui mais... L’optioncoûte trop cher
  73. 73. Le projet (4)• Projet avec deadline dur: loi change le 01/01/YYYY• Le système actuel n’est pas compatible• On développe un nouveau système compatible• Qu’est-ce qui se passe si on livre en retard?• On n’a pas voulu dépenser < 1000€ pour créer uneoption “backup”• “Combien ça coûte pour adapter le système actuel?”• “Failure is not an option”• Le système est livré en retard• Chaque mois d’indisponibilité: X00,000€ par mois
  74. 74. Faites attention auxfausses économies
  75. 75. Quelle est la valeurajoutée pour le clientde votre architecture etvotre processus?
  76. 76. 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 sélectionner les options• Options:• Cout, valeur, prix, date/condition d’expiration• Optimal Decision Process:• Moment de décision = deadline – temps d’implémentation
  77. 77. 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 cherqu’une• Sunk Cost Fallacy:• Oubliez combien vous avez déjà investi• Créez des options pour vos clients
  78. 78. Décisionsarchitecturales
  79. 79. Principe du bon momentDécision facile à changer: décidez tôtDécision difficile à changer:• Rendez la plus facile à changer• Décidez le plus tard possible
  80. 80. Principe de l’effort minimalNe faites pas le travail de demainaujourd’hui (YAGNI)ETNe faites rien aujourd’hui qui entrave letravail de demain“Le principe du fainéant”
  81. 81. Une bonne architecture...Une bonne architecture crée des optionspour votre équipe, votre organisation etvos clientsCréer et maintenir les options ce fait tousles jours, à petits pasSinon, vous créez des systèmes legacyqui ont de moins en moins options
  82. 82. “Dans chaque mauvaisedécision, il se cache unebonne décision”Donald Reinertsen
  83. 83. MERCI !• Si vous voulez en savoir plus...pascal@nayima.behttp://blog.nayima.be
  84. 84. Questions#AgileFrance

×