SlideShare une entreprise Scribd logo
1  sur  74
Real Options:
Quand et comment (ne pas)
  prendre des décisions
     13:30h – 14:20h - Salle La Seine A
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
Donne des conseils
Gère des projets
Programme

Crée des Jeux
Organise des Conférences



      http:/www.xpday.net




                            27 au 29 mars 2013
http://www.cafepress.com/+true-story+mugs
                                            27 au 29 mars 2013
Il était une fois...




                       27 au 29 mars 2013
Le projet (1)
                                                            Site Social
                              Jeu Video




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



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




          http://www.flickr.com/photos/rohdesign/3307874546
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é)
         #




http://en.wikipedia.org/wiki/File:Sinterklaas_2007.jpg
 http://commons.wikimedia.org/wiki/File:Jonathan_G_Meath_portrays_Santa_Claus.jpg
                                                                                    t
1. Cost of Delay


€




                   t
                       27 au 29 mars 2013
Les redesigns précedents
Creative Process

            Generer des          Tester et choisir
            options              des options

 Problème                                       Implémenter




            MOA                     MOE
            Maitrise d’ouvrage      Maitrise d’oeuvre
Creative Process
Creative Process chez nous
N’essayez pas de décider trop vite!
2.The Creative Process




                         27 au 29 mars 2013
Entretemps...




 http://browse.deviantart.com/art/Edvard-Munchs-Homer-71026771
http://www.flickr.com/photos/miagant/5203621384
Real Options Team to the Rescue!




      Olav               Chris                Chris


    “Donnez nous un jour et on vous dira quand et comment décider”
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
 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
Comparons les options
Option       Cout   Prix          Valeur       Expiration
Bleu         ???    /             Design       ???
                                  consistent
Jaune + Bleu ???    Redesign en   Cost of      ???
                    bleu          Delay == 0
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
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?
                 On est ici!




       Option jaune + bleu
                                                    Production
                                                    DVD

                                  Design et test                   Stockage
                                  (2M)                             Magasin
                                                     Serveurs
       Option bleu




     Mars                      Août                Oct           Nov          Dec
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
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?
                 On est ici!




       Option jaune + bleu
                                                    Production
                                                    DVD

                                  Design et test                   Stockage
                                  (2M)                             Magasin
                                                     Serveurs
       Option bleu




     Mars                      Août                Oct           Nov          Dec
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
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 +   1 semaine de      Redesign en Cost of        01/09/20XX
Bleu      refactoring       bleu (1 mois) Delay == 0
          + 2h de suivi /
          2 semaines
Bleu      1 semaine de      /            Design        01/09/20XX
          refactoring                    consistent
          + 2h de suivi /
          2 semaines
3. Real Options
                Optimal Decision Process
                                               Décisions                 Deadline



                                 Option                    Implementer




                                 Option



                                      Option




http://commitment-thebook.com/                                                      27 au 29 mars 2013
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:
Et ils vécurent heureux à tout
             jamais




                                 27 au 29 mars 2013
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
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
           On est ici!




                         Decision


     Plateforme A
                                    Pas assez de
                                    Implementer temps

     Plateforme B
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
           On est ici!




                                 Decision


      Implémenter Plateforme A
                                            Finir implementation de
                                            la plateforme choisie
      Implémenter Plateforme B
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
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!
                                             C
             A          BB
4. Set-based development




      Option   Option B   Option
        A                   C




                                   27 au 29 mars 2013
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
5. Sunk Cost Fallacy
Marginal Economics




                       27 au 29 mars 2013
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?
6. On n’est pas rationnels,
mais on peut faire semblant




                              27 au 29 mars 2013
Encore une histoire?



OUI         NON


                       27 au 29 mars 2013
Le projet (4)

          Vendeurs                                                               Fabricants


                                                       EDI



 http://www.flickr.com/photos/caseorganic/3216853440         http://www.flickr.com/photos/danielfoster/4725849931
La situation (avant)

                            IMPL
               IMPL


                      EDI          Fabricant
     Vendeur
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
                            IMPL
               IMPL
                            IMPL


                      EDI   IMPL
                                   Fabricant
               IMPL
     Vendeur                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
  “Et si on changait de plateforme et langage?
  Sans arreter le système, bien sur!”

  “Impossible!”
     Vendeurs                       Fabricants
                       EDI



                     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
7. Quelle est la valeur ajoutée pour
 le client de votre architecture et
          votre processus?




                                       27 au 29 mars 2013
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
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 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
27 au 29 mars 2013

Contenu connexe

Tendances

Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
Pierre E. NEIS
 
Gestion de projets agiles avec scrum
Gestion de projets agiles avec scrumGestion de projets agiles avec scrum
Gestion de projets agiles avec scrum
Pierre E. NEIS
 

Tendances (19)

Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016
Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016
Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016
 
The Agilists ou "Duo de retour d’expérience sauce aigre douce"
The Agilists ou "Duo de retour d’expérience sauce aigre douce"The Agilists ou "Duo de retour d’expérience sauce aigre douce"
The Agilists ou "Duo de retour d’expérience sauce aigre douce"
 
The agilists
The agilistsThe agilists
The agilists
 
Idées reçues sur l’eXtreme Programming en particulier et sur l’agilité en gén...
Idées reçues sur l’eXtreme Programming en particulier et sur l’agilité en gén...Idées reçues sur l’eXtreme Programming en particulier et sur l’agilité en gén...
Idées reçues sur l’eXtreme Programming en particulier et sur l’agilité en gén...
 
La gestion de projet Agile
La gestion de projet AgileLa gestion de projet Agile
La gestion de projet Agile
 
UX Days 2019 by Flupa - Conférence : Jean-Yves Rigal
UX Days 2019 by Flupa - Conférence : Jean-Yves RigalUX Days 2019 by Flupa - Conférence : Jean-Yves Rigal
UX Days 2019 by Flupa - Conférence : Jean-Yves Rigal
 
Rôles product-owner
Rôles product-ownerRôles product-owner
Rôles product-owner
 
La solution-a-la-dette-technique
La solution-a-la-dette-techniqueLa solution-a-la-dette-technique
La solution-a-la-dette-technique
 
Design Challenge - workshop UX DAYS 2019 - Nicolas CATHERIN
Design Challenge - workshop UX DAYS 2019 - Nicolas CATHERINDesign Challenge - workshop UX DAYS 2019 - Nicolas CATHERIN
Design Challenge - workshop UX DAYS 2019 - Nicolas CATHERIN
 
Retour d'expérience : Un Design Sprint de virtuoses - UX
Retour d'expérience : Un Design Sprint de virtuoses - UXRetour d'expérience : Un Design Sprint de virtuoses - UX
Retour d'expérience : Un Design Sprint de virtuoses - UX
 
Genielogiciel
GenielogicielGenielogiciel
Genielogiciel
 
Et si je rythmais mon kanban ?
Et si je rythmais mon kanban ?Et si je rythmais mon kanban ?
Et si je rythmais mon kanban ?
 
The Agilists Agile Tour Bordeaux
The Agilists Agile Tour BordeauxThe Agilists Agile Tour Bordeaux
The Agilists Agile Tour Bordeaux
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
Gestion de projets agiles avec scrum
Gestion de projets agiles avec scrumGestion de projets agiles avec scrum
Gestion de projets agiles avec scrum
 
#15MinPasPlus sur le Sprint
#15MinPasPlus sur le Sprint#15MinPasPlus sur le Sprint
#15MinPasPlus sur le Sprint
 
La régression continue - Une méthode pour bien faire rater l'adoption agile ...
La régression continue - Une méthode pour bien faire rater l'adoption agile ...La régression continue - Une méthode pour bien faire rater l'adoption agile ...
La régression continue - Une méthode pour bien faire rater l'adoption agile ...
 

En vedette

Présentation Bug Busters
Présentation Bug BustersPrésentation Bug Busters
Présentation Bug Busters
Bug Busters
 
Chouette! Encore un bug!
Chouette! Encore un bug!Chouette! Encore un bug!
Chouette! Encore un bug!
AgileCoach.net
 
Le groupe paul et ses activités
Le groupe paul et ses activitésLe groupe paul et ses activités
Le groupe paul et ses activités
Paul Bonnoure
 

En vedette (20)

Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013
 
Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013
 
Agreeing on business value
Agreeing on business valueAgreeing on business value
Agreeing on business value
 
Vous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionVous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestion
 
Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/Agile
 
Great! another bug
Great! another bugGreat! another bug
Great! another bug
 
Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012
 
Will Agile Change The World ?
Will Agile Change The World ?Will Agile Change The World ?
Will Agile Change The World ?
 
Real Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsReal Options: How and When (not) to take Decisions
Real Options: How and When (not) to take Decisions
 
Présentation Bug Busters
Présentation Bug BustersPrésentation Bug Busters
Présentation Bug Busters
 
Bug, un "objet" du numérique
Bug, un "objet" du numériqueBug, un "objet" du numérique
Bug, un "objet" du numérique
 
Agile introduction
Agile introductionAgile introduction
Agile introduction
 
Chouette! Encore un bug!
Chouette! Encore un bug!Chouette! Encore un bug!
Chouette! Encore un bug!
 
Paul
PaulPaul
Paul
 
Python debugger
Python debuggerPython debugger
Python debugger
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation Games
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinking
 
Atelier facebook pour les débutants
Atelier facebook pour les débutantsAtelier facebook pour les débutants
Atelier facebook pour les débutants
 
Présentation Sage CRM
Présentation Sage CRMPrésentation Sage CRM
Présentation Sage CRM
 
Le groupe paul et ses activités
Le groupe paul et ses activitésLe groupe paul et ses activités
Le groupe paul et ses activités
 

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

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

Formation créativité
Formation créativitéFormation créativité
Formation créativité
 
Lean & Agile UX - afterwork Axance
Lean & Agile UX - afterwork AxanceLean & Agile UX - afterwork Axance
Lean & Agile UX - afterwork Axance
 
UX Days 2019 by Flupa - Conférence : Pauline Thomas
UX Days 2019 by Flupa - Conférence : Pauline ThomasUX Days 2019 by Flupa - Conférence : Pauline Thomas
UX Days 2019 by Flupa - Conférence : Pauline Thomas
 
Afterworkshop #4 : Appréhender son premier design sprint
Afterworkshop #4 : Appréhender son premier design sprintAfterworkshop #4 : Appréhender son premier design sprint
Afterworkshop #4 : Appréhender son premier design sprint
 
Agile Wake Up #3 : Lean UX
Agile Wake Up #3 : Lean UXAgile Wake Up #3 : Lean UX
Agile Wake Up #3 : Lean UX
 
Traou arvorig-methodologie-design-textile
Traou arvorig-methodologie-design-textileTraou arvorig-methodologie-design-textile
Traou arvorig-methodologie-design-textile
 
10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx10 ans de Code (Agile Bordeaux 2019).pptx
10 ans de Code (Agile Bordeaux 2019).pptx
 
Une expérience agile
Une expérience agileUne expérience agile
Une expérience agile
 
Techniques d’UX & UI Design
Techniques d’UX & UI DesignTechniques d’UX & UI Design
Techniques d’UX & UI Design
 
Le Rapid Prototyping, ça marche !
Le Rapid Prototyping, ça marche !Le Rapid Prototyping, ça marche !
Le Rapid Prototyping, ça marche !
 
Talk - Devenir un Lead Dev : Echecs et Succès - FR - 20 mins
Talk - Devenir un Lead Dev : Echecs et Succès - FR - 20 minsTalk - Devenir un Lead Dev : Echecs et Succès - FR - 20 mins
Talk - Devenir un Lead Dev : Echecs et Succès - FR - 20 mins
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 
Et si on jouait au tdd 20131017
Et si on jouait au tdd 20131017Et si on jouait au tdd 20131017
Et si on jouait au tdd 20131017
 
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
Webinar TDD / BDD : Comment mieux délivrer et s'entendre pour le Product Owne...
 
15 conseils pour s'assurer une expérience utilisateur optimale
15 conseils pour s'assurer une expérience utilisateur optimale15 conseils pour s'assurer une expérience utilisateur optimale
15 conseils pour s'assurer une expérience utilisateur optimale
 
cipe jeu gestion de projet.pdf
cipe jeu gestion de projet.pdfcipe jeu gestion de projet.pdf
cipe jeu gestion de projet.pdf
 
Conférence Paris Web 2015 - Vers une bonne pratique du Pair Design
Conférence Paris Web 2015 - Vers une bonne pratique du Pair DesignConférence Paris Web 2015 - Vers une bonne pratique du Pair Design
Conférence Paris Web 2015 - Vers une bonne pratique du Pair Design
 
Forum sur l'innovation BI 2013 - Atelier "Design Thinking" - Nouvelle ère de ...
Forum sur l'innovation BI 2013 - Atelier "Design Thinking" - Nouvelle ère de ...Forum sur l'innovation BI 2013 - Atelier "Design Thinking" - Nouvelle ère de ...
Forum sur l'innovation BI 2013 - Atelier "Design Thinking" - Nouvelle ère de ...
 
Leslnfiltrés
LeslnfiltrésLeslnfiltrés
Leslnfiltrés
 
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDDWebinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
 

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

  • 1. Real Options: Quand et comment (ne pas) prendre des décisions 13:30h – 14:20h - Salle La Seine A
  • 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. Donne des conseils Gère des projets Programme Crée des Jeux Organise des Conférences http:/www.xpday.net 27 au 29 mars 2013
  • 5. Il était une fois... 27 au 29 mars 2013
  • 6. Le projet (1) Site Social Jeu Video http://www.flickr.com/photos/rohdesign/3307874546 http://www.flickr.com/photos/seandreilinger/2187892869
  • 7. Le site http://www.flickr.com/photos/rohdesign/3307874546
  • 8. A la une Redesign de tous les sites! Le “vieux” design jaune sera remplacé par un design bleu cool, fresh et clair
  • 9. Le Redesign http://www.flickr.com/photos/rohdesign/3307874546
  • 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. 1. Cost of Delay € t 27 au 29 mars 2013
  • 14. Creative Process Generer des Tester et choisir options des options Problème Implémenter MOA MOE Maitrise d’ouvrage Maitrise d’oeuvre
  • 17. N’essayez pas de décider trop vite!
  • 18. 2.The Creative Process 27 au 29 mars 2013
  • 21. Real Options Team to the Rescue! Olav Chris Chris “Donnez nous un jour et on vous dira quand et comment décider”
  • 22. Quel est le problème? Cost of Delay: un retard (même d’un jour) peut nous couter 50% des ventes
  • 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. 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. Comparons les options Option Cout Prix Valeur Expiration Bleu ??? / Design ??? consistent Jaune + Bleu ??? Redesign en Cost of ??? bleu Delay == 0
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Comparons les options Option Cout Prix Valeur Expiration Jaune + 1 semaine de Redesign en Cost of 01/09/20XX Bleu refactoring bleu (1 mois) Delay == 0 + 2h de suivi / 2 semaines Bleu 1 semaine de / Design 01/09/20XX refactoring consistent + 2h de suivi / 2 semaines
  • 36. 3. Real Options Optimal Decision Process Décisions Deadline Option Implementer Option Option http://commitment-thebook.com/ 27 au 29 mars 2013
  • 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. Et ils vécurent heureux à tout jamais 27 au 29 mars 2013
  • 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. 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. Notre problème On est ici! Decision Plateforme A Pas assez de Implementer temps Plateforme B
  • 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. Notre solution On est ici! Decision Implémenter Plateforme A Finir implementation de la plateforme choisie Implémenter Plateforme B
  • 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. 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. 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. 4. Set-based development Option Option B Option A C 27 au 29 mars 2013
  • 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. 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. 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. 5. Sunk Cost Fallacy Marginal Economics 27 au 29 mars 2013
  • 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. Mais ce n’est pas logique, capitaine!
  • 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. 6. On n’est pas rationnels, mais on peut faire semblant 27 au 29 mars 2013
  • 56. Encore une histoire? OUI NON 27 au 29 mars 2013
  • 57. Le projet (4) Vendeurs Fabricants EDI http://www.flickr.com/photos/caseorganic/3216853440 http://www.flickr.com/photos/danielfoster/4725849931
  • 58. La situation (avant) IMPL IMPL EDI Fabricant Vendeur
  • 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. 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. La situation (après) - Technique IMPL IMPL IMPL EDI IMPL Fabricant IMPL Vendeur IMPL IMPL IMPL IMPL
  • 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. 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. 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. Hola Hop, Barbatruc “Et si on changait de plateforme et langage? Sans arreter le système, bien sur!” “Impossible!” Vendeurs Fabricants EDI Gestion
  • 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. 7. Quelle est la valeur ajoutée pour le client de votre architecture et votre processus? 27 au 29 mars 2013
  • 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. 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. 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 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
  • 71. “Dans chaque mauvaise décision, il se cache une bonne décision” Donald Reinertsen 27 au 29 mars 2013
  • 72. MERCI ! Si vous voulez en savoir plus... 27 au 29 mars 2013
  • 73. 27 au 29 mars 2013
  • 74. 27 au 29 mars 2013