Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions

3,297 views

Published on

Quelques histoires qui illustrent comment utiliser Real Options et autres outils intellectuels pour décider quand et comment décider

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

No Downloads
Views
Total views
3,297
On SlideShare
0
From Embeds
0
Number of Embeds
1,382
Actions
Shares
0
Downloads
24
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions

  1. 1. Real Options:Quand et comment (ne pas) prendre des décisions 13:30h – 14:20h - Salle La Seine A
  2. 2. Real Options:Quand et comment (ne pas) prendre des décisions Pascal Van Cauwenberghe NAYIMA We make play work @pascalvc 27 au 29 mars 2013
  3. 3. Donne des conseilsGère des projetsProgrammeCrée des JeuxOrganise des Conférences http:/www.xpday.net 27 au 29 mars 2013
  4. 4. http://www.cafepress.com/+true-story+mugs 27 au 29 mars 2013
  5. 5. Il était une fois... 27 au 29 mars 2013
  6. 6. Le projet (1) Site Social Jeu Video http://www.flickr.com/photos/rohdesign/3307874546http://www.flickr.com/photos/seandreilinger/2187892869
  7. 7. Le site http://www.flickr.com/photos/rohdesign/3307874546
  8. 8. A la une Redesign de tous les sites! Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair
  9. 9. Le Redesign http://www.flickr.com/photos/rohdesign/3307874546
  10. 10. La reaction http://browse.deviantart.com/art/Edvard-Munchs-Homer-71026771
  11. 11. 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
  12. 12. 1. Cost of Delay€ t 27 au 29 mars 2013
  13. 13. Les redesigns précedents
  14. 14. Creative Process Generer des Tester et choisir options des options Problème Implémenter MOA MOE Maitrise d’ouvrage Maitrise d’oeuvre
  15. 15. Creative Process
  16. 16. Creative Process chez nous
  17. 17. N’essayez pas de décider trop vite!
  18. 18. 2.The Creative Process 27 au 29 mars 2013
  19. 19. Entretemps... http://browse.deviantart.com/art/Edvard-Munchs-Homer-71026771
  20. 20. http://www.flickr.com/photos/miagant/5203621384
  21. 21. Real Options Team to the Rescue! Olav Chris Chris “Donnez nous un jour et on vous dira quand et comment décider”
  22. 22. Quel est le problème? Cost of Delay: un retard (même d’un jour) peut nous couter 50% des ventes
  23. 23. 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
  24. 24. 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 1. 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
  25. 25. Comparons les optionsOption Cout Prix Valeur ExpirationBleu ??? / Design ??? consistentJaune + Bleu ??? Redesign en Cost of ??? bleu Delay == 0
  26. 26. 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
  27. 27. 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” 
  28. 28. Quand est-ce qu’il faut décider? On est ici! Option jaune + bleu Production DVD Design et test Stockage (2M) Magasin Serveurs Option bleu Mars Août Oct Nov Dec
  29. 29. 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 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
  30. 30. 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.
  31. 31. 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”
  32. 32. Quand est-ce qu’il faut décider? On est ici! Option jaune + bleu Production DVD Design et test Stockage (2M) Magasin Serveurs Option bleu Mars Août Oct Nov Dec
  33. 33. Quand est-ce qu’il faut décider? On est ici! Option jaune + bleu Production DVD Design Stockage et test Magasin (1M) Serveurs Option bleu Mars Sep Oct Nov Dec
  34. 34. 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
  35. 35. Comparons les optionsOption Cout Prix Valeur ExpirationJaune + 1 semaine de Redesign en Cost of 01/09/20XXBleu refactoring bleu (1 mois) Delay == 0 + 2h de suivi / 2 semainesBleu 1 semaine de / Design 01/09/20XX refactoring consistent + 2h de suivi / 2 semaines
  36. 36. 3. Real Options Optimal Decision Process Décisions Deadline Option Implementer Option Optionhttp://commitment-thebook.com/ 27 au 29 mars 2013
  37. 37. 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:
  38. 38. Et ils vécurent heureux à tout jamais 27 au 29 mars 2013
  39. 39. Le projet (2) Internet Banking Internet Banking servers http://www.flickr.com/photos/seeminglee/8276505285 http://en.wikipedia.org/wiki/File:Rack001.jpg p.s. La banque n’est pas HSBC
  40. 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 • 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?
  41. 41. Notre problème On est ici! Decision Plateforme A Pas assez de Implementer temps Plateforme B
  42. 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. 43. Notre solution On est ici! Decision Implémenter Plateforme A Finir implementation de la plateforme choisie Implémenter Plateforme B
  44. 44. Set-based development 3 implementations en parallèle : APP •Plateforme A •Plateforme B •Environnement de développement et test API A B Server Test Server Server
  45. 45. 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...
  46. 46. 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! C A BB
  47. 47. 4. Set-based development Option Option B Option A C 27 au 29 mars 2013
  48. 48. 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?
  49. 49. 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€
  50. 50. 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
  51. 51. 5. Sunk Cost FallacyMarginal Economics 27 au 29 mars 2013
  52. 52. 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?
  53. 53. Mais ce n’est pas logique, capitaine!
  54. 54. 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?
  55. 55. 6. On n’est pas rationnels,mais on peut faire semblant 27 au 29 mars 2013
  56. 56. Encore une histoire?OUI NON 27 au 29 mars 2013
  57. 57. Le projet (4) Vendeurs Fabricants EDI http://www.flickr.com/photos/caseorganic/3216853440 http://www.flickr.com/photos/danielfoster/4725849931
  58. 58. La situation (avant) IMPL IMPL EDI Fabricant Vendeur
  59. 59. 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
  60. 60. 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
  61. 61. La situation (après) - Technique IMPL IMPL IMPL EDI IMPL Fabricant IMPL Vendeur IMPL IMPL IMPL IMPL
  62. 62. 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
  63. 63. 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
  64. 64. 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”
  65. 65. Hola Hop, Barbatruc “Et si on changait de plateforme et langage? Sans arreter le système, bien sur!” “Impossible!” Vendeurs Fabricants EDI Gestion
  66. 66. 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
  67. 67. 7. Quelle est la valeur ajoutée pour le client de votre architecture et votre processus? 27 au 29 mars 2013
  68. 68. 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
  69. 69. 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
  70. 70. Décisions architecturales “Le principe du bon moment” Décisions faciles à changer: décidez tôt Décisions difficiles à changer: décidez tard “Le principe de l’effort minimal” Ne faites pas le travail de demain aujourd’hui Ne faites rien aujourd’hui qui entrave le travail de demainUne bonne architecture crée des options pour votre équipe, votre organisation et vos clientsLes systèmes patrimoniaux ont de moins en moins options 27 au 29 mars 2013
  71. 71. “Dans chaque mauvaisedécision, il se cache unebonne décision”Donald Reinertsen 27 au 29 mars 2013
  72. 72. MERCI !Si vous voulez en savoir plus... 27 au 29 mars 2013
  73. 73. 27 au 29 mars 2013
  74. 74. 27 au 29 mars 2013

×