Note de lecture : Service Oriented Java Business Integration, par Binildas C. A.
Note : 7 ; Du concret sur l’ESB, mais un texte qui accuse aussi son âge…
Pas facile de s’y retrouver au sein du concept technico-marketing qu’est l’ESB ! Ce dont on a surtout besoin, c’est du concret. Et c’est exactement ce que l’auteur nous propose ici. Malgré son titre généraliste, le livre se focalise presqu’exclusivement sur la mise en œuvre de l’ESB open-source d’Apache, ServiceMix et de la norme JBI qu’il dessert.
En fait, les 2 premiers chapitres sont consacrés à la vue générale des problématiques d’intégration. Le premier chapitre présente les banalités habituelles sur l’ESB (mais plutôt bien présentées) et le second se focalise sur l’aspect plus technique en introduisant JBI et les « integration patterns ». Ce n’est qu’au chapitre 3 (on est déjà page 57) que ServiceMix, ou plutôt la vue globale de son architecture, est introduit.
A partir du chapitre 4, on passe en revue les différents types de binding, selon une complexité croissante. Tout d’abord un binding simple, dit conventionnel (chapitre 4), puis un binding « contract last » avec XFire (chapitre 5). Un binding plus complexe à trois niveaux est abordé au chapitre 8, mettant en œuvre des EJB, tandis que le binding de POJO est enfin abordé au chapitre 9. Puis c’est le tour de l’approche « gateway » ou « contract first » avec Axis (chapitre 10).
Les chapitres 6 et 7 font figure d’interludes. Il était difficile d’aller bien loin sans aborder les concepts de packaging et de déploiement des services ServiceMix, c’est chose faite au chapitre 6. De même, il est parfois utile de compléter la panoplie de bindings proposés par l’ESB, c’est l’objet du chapitre 7.
La problématique du transport est aussi un domaine où l’ESB permet une certaine souplesse. Le chapitre 11 montre comment accéder un Web Service au travers de JMS. Au chapitre 12, on voit comment effectuer le binding entre Java et XML (le langage natif de l’ESB) en utilisant en autre XStream. Enfin le chapitre 13 aborde le point plus complexe mais aussi plus exotique des proxys JBI.
Les derniers chapitres peuvent être vus comme des aspects avancés, donc pas forcément indispensables de prime abord. Le chapitre 14 aborde la problématique de versioning des Web Services, utile dans le cadre d’un SI « évolutif ». Le très long chapitre 15 traduit en services ServiceMix de nombreux integration patterns. L’agrégation de services est abordée au chapitre 16. Il s’agit d’un sujet plutôt avancé et c’est tant mieux car le propos n’est pas des plus clairs. On finit en ordre dispersé par un chapitre fourre-tout, avec les transactions, la sécurité le clustering et la vie des bêtes au chapitre 17. J’espère qu’il y a mieux ailleurs car ce n’est pas la joie.
Comme on le voit, c’est un tour d’horizon plutôt complet qui nous est proposé sur 400 pages. Il s’adresse clairement aux architectes. On y aborde les concepts et le code. Si le code Java est clair, il est fort dommage (et c’est mon reproche principal) que les configurations ServiceMix pourtant complexes soient aussi peu décortiquées. Leur compréhension reste ardue.
Ce type d’ouvrage est hélas sujet à l’obsolescence. Ne nous voilons pas la face, c’est bien le cas ici. ServiceMix (pour ne parler que de lui) a déjà changé de version majeure depuis un moment. Il n’a plus nécessairement la pertinence qu’il avait au moment de sa sortie…
Référence complète : Service Oriented Java Business Integration – Binildas C. A. – Packt Publishing 2008 – EAN : 978 1 847194 40 4
After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t’ do it
Bas Vodde and Craig Larman
A la conquête du Story Mapping
Il n’y a pas (encore) d’ouvrages traitant du Story Mapping, un technique développée par Jeff Patton. Elle comble une lacune de l’approche fonctionnelle agile basée sur les User Stories qui proposent une manière de cartographier ceux-ci sur des axes orthogonaux : le processus et la réalisation incrémentale.
Pour moi, il s’agit d’un outil supplémentaire à embarquer dans ma besace de pratiques agiles. Je ne vais pas les considérer comme un passage obligé des projets agiles, tout comme je ne suis pas prêt à accepter l’idée que les User Stories sont le moyen unique d’exprimer un besoin utilisateur (ce qui nous conduit par ailleurs à la notion de “story technique” que je rejette purement et simplement).
Le Story Mapping se situe au même niveau d’usage que les Cas d’Utilisation, une technique écartée par la plupart des agilistes, mais pas par moi (je reste en bonne compagnie sur ce point). Cette technique présente certains avantages par rapport aux cas d’utilisation, et ces derniers exhibent d’autres atouts. Nous reviendrons peut-être un autre jour là-dessus : Jean-Claude Grosjean et moi-même avions même évoqué l’idée de faire une présentation commune sur ce sujet un jour !
Pour le story mapping :
- Structuration bottom-up des user stories.
- Agencement des stories dans un processus (quand celui-ci reste simple)
- Agencement par itération visible dans la map.
- Un processus de travail collectif.
Pour les cas d’utilisation :
- Une structuration “divide and conquer” top-down du besoin fonctionnel.
- Une bonne structuration par unité fonctionnelle cohérente en lien avec des acteurs.
- Un bonne structuration fonctionnelle intrinsèque avec l’articulation des scénarios.
- Un niveau de structuration fonctionnel qui peut servir de charnière avec de nombreuses activités : UX, acceptante testing, etc…
A défaut d’avoir la référence ultime, j’ai essayé de collecter ici des ressources sur le sujet. Notons d’ailleurs au passage que la 3ème édition du livre de Claude Aubry évoque cette technique.
L’article de référence de Jeff Patton
Il décrit les étapes de la technique. Il n’a pas simplement un “intérêt historique”. Il reste tout à fait pertinent. En fait, je conseille de commencer par lire cet article !
Jeff Patton présente également son approche sur son site.
Pour ceux qui préfèrent le format “slides”, c’est juste ici:
La présentation de Steve Rogalsky
C’est un peu le “Story Mapping from the Trenches” : une présentation très visuelle sur la façon de faire du story mapping, où le présentateur montre comment lui-même opère concrètement. Une bonne illustration de l’article de Jeff Patton !
Par ailleurs, Steve Rogalsky a développé la matière de cette présentation via une série de posts :
- Comment créer une Story Map ?
- Comment prioriser une Story Map ?
- Comment faciliter une session de Story Mapping ?
- Quelques réflexions sur les dangers de couler les Story Maps dans le béton.
Laurence Hanot : construisez votre produit en racontant des histoires !
J’avais assisté à la présentation de Laurence à Agile France, c’est une occasion de mettre en avant sa présentation qui est une introduction à la technique
De l’impact mapping au Story Mapping
Cette présentation m’a été indiquée par Gojko Adzic. A voir et revoir car elle fait le lien avec l’impact Mapping
Autres ressources
- Un post d’Oana Juncu qui évoque le sujet, mais aussi l’articulation des tests d’acceptance sur cette expression des besoins.
- Un article sur le site de la Scrum Alliance présente aussi l’approche. Je le trouve plutôt moins bien que les ressources précédentes.
Facile à bien utiliser, difficile à mal utiliser, la présentation
En attendant que j’ai le courage de la terminer sous forme d’article, voici les slides de ma présentation à l’Agile Tour Bruxelles.
Cette présentation est directement inspirée d’un conseil de conception de Scott Meyers : “Make your interfaces easy to use correctly and hard to use incorrectly”. Sur ce, je vous laisse vous essayer aux quizz contenus dans cette présentation !
Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features.
Steve Jobs
Worshop Running Lean, avec Ash Maurya (2/2)
Alors que la première journée s’appuyait en grande partie sur Running Lean, cette seconde journée sera d’avantage centrée sur les techniques récemment développées par Ash Maurya.
User cycle
Act 1 : Est-ce un problème qui vaut la peine d’être résolu ?
Nous l’avons évoqué dans le post précédent : la clé est de se concentrer sur l’utilisateur, de rechercher quels sont ses sources de souffrance :
- Son workflow (il ne faut pas l’ignorer, en fait on doit même s’y insérer)
- Ses craintes, ses frustrations
- Ses buts et aspirations.
L’approche à adopter est une alternance de recherche et d’interviews : La recherche permet d’établir des hypothèses et l’interview permet de valider ou invalider ces hypothèses. Il s’agit de “problem interviews” permettant de valider l’identification du problème.
Deux mesure de succès du “problem interview” permettant de vérifier ‘intérêt que l’on suscite:
- L’acceptation d’un “follow up”
- L’obtention d’autres référents avec lesquels travailler.
Deux points que l’on n’obtient pas si l’on a eu qu’un intérêt de politesse.
Acte 2 : Tester la Vision
On n’a pas nécessairement besoin de code pour tester sa Vision. Il faut surtout être capable de faire une démo qui raconte une histoire. On peut utiliser un outil de prototype comme Keynotopia ou Balsamiq .
Là encore la validation passe par une interview, cette fois c’est une Solution Interview, qui s’articule comme suit:
- Attention : En cernant correctement et précisément le problème de départ.
- Intérêt : Avec une démo qui déchire.
- Désire
- Action
L’objectif est de produire un engagement :
- “soft” : c’est obtenir un “oui”. ça vaut ce que ça vaut…
- “dur”: c’est déclencher un pré-vente !
Bien sûr, on a toutes les possibilités intermédiaires…
A propos de la pré-vente : l’ancrage du prix fait partie du solution interview. Il faut le justifier par rapport aux alternatives et bien entendu pouvoir montrer qu’on abaisse en fait le coût avec notre solution, donc changer la perception du client potentiel. Quelques références sur ce sujet :
Positionner le MVP
La première étape consiste, nous l’avons déjà dit, à se concentrer sur un petit nombre de clients, une dizaine peut-être, guère plus, souvent même moins ! On ne cherche pas à collecter d’informations quantitatives, mais qualitatives.
C’est pourquoi on va chercher à rendre ces clients très heureux, pas simplement satisfaits. Adresser le risque marché consiste précisément à identifier si la solution permet ce haut niveau de satisfaction chez des clients. On ne va pas chercher à abaisser le “signup friction” de ces early adopters, on doit cibler des clients pour qui la proposition de valeur représente un besoin important. Autant augmenter ce “signup friction”, au contraire !
Plus tard dans le cycle utilisateurs, on cherchera à élargir la base d’utilisateurs, en s’appuyant de plus en plus sur du self-service. A ce niveau, c’est le risque technique lié à la scalabilité que l’on adressera.
Et le prix ?
Cela semble malin de prime abord de proposer 2, 3 ou 5 “plans”. Mais en réalité, il est préférable de ne pas s’amuser avec ces plans, même s’ils ont pour but de guider le client vers un “plan préféré”. La présence de ces plans multiples peut être un obstacle pour apprendre des choses sur l’adéquation prix-service, car il introduit une dimension supplémentaire.
Le prix est une partie intégrante du MVP. Tant que la proposition de valeur n’est pas payante, sa validité n’est pas établie.
Nous sommes tous dans le “manufacturing business”
… Et ce que nous construisons, ce sont des clients heureux, dont on améliore la chaine de valeur !
En Lean, l’amélioration de la chaine de valeur passer par l’élimination du gaspillage à l’échelle de la totalité de la chaine de valeur. Celle-ci est formée d’un ensemble de processus interconnectés sur lequel il faut identifier la contrainte principale … sans perdre de vue qu’une fois cette contrainte levée, celle-ci se sera déplacée ailleurs dans le système !
Dans le principe, ça parait simple. Dans la pratique il faut prendre en compte la dimension irrationnelle des clients, bien que cette irrationalité soit en fait prédictible (voir Predictably irrationnal)
Ash Maurya gradue le niveau d’engagement des clients ainsi :
1. Acquisition
2. Activation
3. Rétention
4. Revenue
5. Référent
Cette échelle nous permet d’aborder le sujet suivant : la customer factory !
The customer factory
C’est le sujet du prochain livre d’Ash Maurya. Il représente cette Customer Factory ainsi :
Le principe est finalement assez simple :
- L’étape initiale est l’acquisition : les prospects viennent chez vous. Mais attention ! ce doit être plus qu’un simple rebond !
- La rétention : elle est matérialisée par le signoff (activation). C’est l’étape “usine”.
- Le revenu : quand on parvient à faire payer le souscripteur.
- Le référent : quand on parvient à acquérir de nouveaux clients grâce à ces clients existants.
Et le moteur de croissance ?
- Le “paid engine” doit favoriser l’acquisition.
- Le “sticky engine” doit permettre la rétention.
- Le “viral engine” doit engendrer l’acquisition par référent.
Ash Maurya nous recommande pour le “paid engine” : une “life time value” = 3 x le coût d’acquisition.
Pour observer si les moteurs de croissances donnent le résultat escompter, il faut passer par des métriques de cohortes, mais surtout se livrer à de nombreuses expérimentations !
Le validation board
Le Lean Startup Machine a mis au point le “validation board” qui permet de suivre les expérimentations à faire et en cours (c’est une sorte de kanban, si on veut bien…) par rapport à des hypothèses.
Les clés :
- Identifier les expérimentations capables de valider les hypothèses.
- Trouver la mesure adéquate. Ash recommande à ce sujet la lecture de How To Measure Anything.
- Construire une offre.
L’auteur de Running Lean nous propose 3 types d’offres :
- La “Maffia Offer” : comme son nom l’indique, c’est l’offre que l’on ne peut pas refuser !
- Le “Smoke Test Offer” : Une offre dont la complétude s’arrête à ce qu’il faut pour tester une hypothèse de marché.
- Le “Pré-order offer” qui serf à lever des fonds, à la façon Kickstarter.
Les idées clés sont de faire de petites expérimentations (2 semaines maximum) ne testant qu’une seule hypothèse, pour lesquelles on définit les objectifs avant les critères de satisfaction avant, afin d’éviter la rationalisation après coup.
Chaque expérimentation doit être documentée. Mais pas trop, car on est lean…
L’experiment report
L’experiment report est une déclinaison du A3 du Lean. Il va nous permettre de garder la mémoire des expérimentations déjà opérer : faire des erreurs, c’est apprendre. Refaire les mêmes, c’est bien dommage…
La partie du haut nous permet de figurer les mesures, et la partie du bas résume ce que l’on a appris
This is the end…
Nous arrivons au terme de ces 2 jours. Ils furent bien remplis, même si la partie pratique pêche un peu. De toute façon, c’est bien sur du réel qu’il faut mettre tout cela en pratique, et sans trop tarder !
Il me faut remercier non seulement notre orateur, mais aussi Sebastien Saccard qui a rendu ce workshop possible.
Et bien entendu Zenika qui fut l’un des sponsors de cet évènement.
Ressources
Pour compléter ce que nous avons vu, voici 2 présentations. La première est d’Ash Maurya et reprend les éléments de son workshop.
Le seconde est de Camille Roux (qui était aussi présent au workshop) et reprend de manière très synthétique et percutante la démarche Running Lean.
Note de lecture : PostgreSQL, A comprehensive guide par Korry Douglas & Susan Douglas
Note : 7 ; PostgreSQL de haut en bas!
750 pages sur 21 chapitres, voici un livre que l’on ne peut accuser d’être léger ! Les deux premiers chapitres servent surtout à introduire le SQL à la mode PostgreSQL avec ses spécificités. Le tout est plutôt pédagogique et couvre 130 pages. Pour terminer cette première partie, les chapitres 3 et 4 nous emmènent plus loin sur la structure des bases de données, des clusters et des transactions, ainsi que sur les modèles physiques sous-jacent de PostgreSQL pour comprendre comment en optimiser les performances. Du bon boulot !
Avec la seconde partie, fini de rire! On attaque les API en C pour écrire des fonctions permettant d’étendre PostrgreSQL au chapitre 6. Le retour au SQL (PL/pgSQL pour être exact) est bizarre au chapitre 7, surtout que c’est pour retourner à l’API C au chapitre 8 ! Le propos n’est pas très ais à suivre, il se poursuit au chapitre 9, tandis que le chapitre 10 nous en livre la variante C++. Il ne s’agit ni plus ni moins que de la reprise de ce qui est déjà vu au chapitre 8. Et désolé pour ceux qui espéraient du grand C++ ! Le chapitre 11 nous montre une autre variante de l’interfaçage PostgreSQL en C, via le préprocesseur ecpg qui permet d’écrire directement du SQL dans le code source. Je vous le dit: c’est déroutant! Moins déroutant est le chapitre 12 qui traite de cet interfaçage via le désormais classique ODBC. D’ODBC à JDBC il n’y a qu’un pas, ou un chapitre en l’occurrence, car c’est le chapitre 13 qui traite de l’interfaçage Java. Et l’on a donc la joie de voir la même approche se dérouler pour la 6ème fois ! De Java, on passé à Perl au chapitre 14, toujours avec la même structure de chapitre et le mêle exemple (pour la 7ème fois, donc). Au chapitre 15, c’est au tour de PHP, puis de Tcl/Tk au chapitre 16 (je croyais celui-ci mort et enterré). Enfin Python ferme la marche au chapitre 17.
Après la phase “comique de répétition” des interfaçages, la 3ème partie traite de l’administration. Il est assez curieux que l’on doive attendre le chapitre 19 pour voir traité l’installation du serveur ! Ce chapitre traite par ailleurs des très classiques gestion des utilisateurs, créations de bases avec sauvegarde et restauration de celles-ci. On y traite par ailleurs plutôt efficacement de tout ce qui a trait au paramètres d’exécution du serveur. Enfin le chapitre 20 traite de la localisation (pas seulement la langue, mais aussi les unités de mesure, de monnaie, etc…) tandis que les aspect sécurité ferment la marche au chapitre 21.
Dans ce livre, les aspects interfaçage avec différents langage tienne la plus grande part du livre. Aussi celui-ci vous sera surtout utile si vous utilisez la base de données de manière programmatique, surtout en C. Mais j’ai aussi trouvé plutôt bien traité les aspects lies à l’usage interactif, à la configuration et à la maintenance de PostgreSQL.
Référence complète : PostgreSQL, A comprehensive guide to building, programming and administering PostgreSQL databases – Korry Douglas & Susan Douglas – Developer’s Library 2003 – ISBN: 978-0-7357-1257-7
Peu de gens parlent du doute en doutant.
Blaise Pascal
Worshop Running Lean, avec Ash Maurya (journée 1/12)
J’ai eu la chance de pouvoir assister au workshop instruit par l’auteur de Running Lean ce mois-ci. Un workshop qui n’a eu aucun mal à se remplir car ce ne sont pas moins de 45 personnes qui s’y étaient inscrites !
Le temps d’avaler un café et une viennoiserie et on attaque le sujet !
Où l’on commence par casser un mythe…
Et c’est celui du visionnaire ! Certes le produit est important, mais pas SI important. Et comme Ash nous le répètera plusieurs fois durant ces 2 jours :
Votre produit n’est pas votre produit.
Votre Business Model est votre produit.
Ainsi la cause principale d’échec n’est pas un problème de réalisation du produit, mais l’incapacité à trouver des clients. En fait, parmi les startups réussissant à développer leur business, 2/3 d’entre-elles modifient leur plan en cours de route !
Comment savoir quelle direction prendre dans ces conditions ? En écoutant le client, et donc en apprenant à l’écouter : Quel est réellement son problème ? Mérite-t-il d’être adressé ? Le client que nous imaginons est-il celui correspondant au problème, ou devons-nous réévaluer le problème, à moins qu’il faille changer de client ?
Ces questions s’adressent sur les business classiques sur des cycles d’un ou deux ans. Il s’agit ici d’aller plus vite et de maximiser ce que l’on apprends en fonction du temps. Finalement, le développement du produit est une activité qui est en travers de notre route. C’est en évaluant l’usage du produit que l’on apprends des choses sur notre utilisateur, pas en le développant !
Il faut trouver des moyens de gagner du temps à ce niveau et d’optimiser nos moyens d’apprendre
Le Lean Canvas
Le Lean Canvas est un Business Model (il est d’ailleurs inspiré du Canvas du Business Model Generation). Peu importe que nous utilisions ce dernier ou celui de Ash Maurya. Ou même que nous inventions le notre. Mais il faut en faire un (et même plusieurs, en fait), et non un business plan ! Le Business Plan est un travail de fiction postulant sur des gains futurs dont on ne sait rien !
Il faut faire plus simple, un outil qui soit plus synthétique et tenant en une page et qui nous aide à construire nos hypothèses. Le Lean Canvas est cela et plus encore. Il suffit de 20 minutes pour commencer à le construire. Il faut encre moins de temps pour le déchirer et en recommencer un autre !
Le Lean Canvas nous aide à identifier la partie la plus risquée du plan :
- Parviendra-t-on à être suffisamment différent pour acquérir un “unfair advantage” ?
- Sur quelle marge (revenue – coûts) peut-on compter lors du scaling ?
- Quels signes, quelles métriques mettront en lumière la “traction” sur le produit. Attention aux métriques de vanité, il est préférable de s’appuyer sur des métriques dites de cohortes et non des chiffres cumulés.
- Enfin le problème est-il bien compris et bien articulé ? C’est la proposition de valeur. A ce stade, il est préférable de rétrécir le segment de marché auquel on s’adresse ! Geoffray Moore ne dit pas autre chose dans “Crossing the Chasm” !
Le véritable travail de l’entrepreneur
Nous allons le répéter une fois encore : votre produit n’est pas le produit, c’est le business model qui est le produit !
Le boulot de l’entrepreneur est de “dé-risquer” de manière systématique le business model au travers de conversations :
- Avec les (futurs) clients
- Avec l’équipe
- Avec les mentors
- Avec les investisseurs
- … et même avec les compétiteurs !
Bien sûr, on ne parle pas de conversations au coin du feu, mais de conversations structurées, évaluables et capables de nous apprendre quelque chose !
Les 3 étapes de la startup
Dans l’approche “running lean”, Ash Maurya identifie 3 étapes majeures de l’évolution de la startup. Entre chaque étape on trouve un objectif de progression de clients d’un ordre de grandeur 100 ou plus !
1 – Problem / solution fit
- Le problème que l’on cherche à résoudre vaut-il la peine d’être résolu ?
- Est-ce le bon client par rapport à ce problème ?
Comme le résume Ash Maurya :
La vie est trop courte pour développer quelque chose dont personne ne veut !
Durant cette phase on travaille avec très peu de clients, 1 à 10 par exemple. mais on travaille en grande proximité !
Le fameux MVP de Lean Startup prend place à cette étape. L’auteur de Running Lean nous donne 2 exemples de types de MVP :
- Le concierge MVP : vous n’avez pas construit de système et vous effectuez manuellement ce qui sera plus tard automatisé.
- Le magicien d’Oz : Vous laissez croire à vos utilisateurs qu’il existe un système derrière votre site web, alors que tout y est fait manuellement, à la manière du “mécanisa turk” que propose Amazon !
On en trouve d’autres dans le livre d’Eric Ries.
2 – Product / Market fit
Ai-je construit quelque chose dont les clients veulent ? Le tester avec un panel assez large d’utilisateur n’est pas la même chose que le tester avec trois. Il est temps de voir si le marché existe vraiment !
3 – Scale !
Comment accélérer la croissance ? C’est là que la notion de “moteur de croissance” prends tout son sens.
Running Lean as a startup
Tout cela nécessite bien un petit exemple. Prenons celui de la réalisation du livre : Running Lean !
Problème / solution
C’est ce que l’on appelle un “MVP accidentel”. En l’occurrence le Blog de l’auteur (octobre 2009). Il est démarré afin de documenter ses réalisations en mode startup en utilisant le Lean Startup ! A l’époque, l’auteur avait plus de questions que de réponses, une bonne motivation pour démarrer le blog.
Mais en faire un livre ? Pas question !
Customers interviews
Au fur et à mesure, les requêtes des lecteurs du blog s’intensifièrent pour convertir la série de posts en livre. D’où interviews pour en comprendre la raison. Ah ! C’est pour avoir du contenu qui permette de convertir les principes du Lean Startup en techniques applicables…
En mars 2010, Ash teste les clients potentiels via un teaser. Le nom n’est pas définitif (pas d’optimisation prématurée), mais la table des matière en est un élément important (proposition de valeur). L’objectif est de collecter 1000 emails (clients potentiels) afin de voir si il existe un intérêt sur le marché.
Workshop
Si le teaser est la définition de la solution, alors le workshop est la vérification quantitative.
En Juin 2010, l’auteur teste l’intérêt réel des clients potentiels via un workshop gratuit (small batch), puis payant en Juillet / Septembre 2010 (MVP où le prix est une part du produit).
Pré-order
A partir d’octobre 2010, il prend des pré-commandes pour un ebook en PDF (pas la peine de sortir la version Kindle, il n’y a rien à apprendre en la produisant).
On entre alors dans un cycle de release de 2 semaines. En cours de route, un éditeur manifeste d’ailleurs son intérêt (décliné par l’auteur).
Auto-publication
Elle est opérationnelle en Février 2011. S’en suivra une seconde version produite plus classiquement chez O’Reilly.
Un produit n’est jamais fini, juste “releasé”. D’autres étapes ont encore suivi celle-ci…
Objections !
Nous avons vu ce que sont les 3 étapes dans le cas de startups Web. Quelles peuvent être les objections ? L’approche Running Lean est-elle cantonnée à ces profils d’entreprises ?
B2C
Si je veux toucher 1 million de personnes, quel intérêt il y a-t-il à démarrer une première étape avec 1 à 10 utilisateurs ?
Disons que si les 10 premiers utilisateurs ne sont pas intéressés, il faut certainement changer quelque chose. Inutile de monter en échelle si l’on a pas identifié un problème méritant d’être résolu à petite échelle…
B2B
Les cycles de ventes y sont plus long.
Ce sont les signes de rejet qu’il faut écouter avant même de commencer à conclure des ventes. Inutile d’engager des commerciaux trop tôt !
Low Tech
Un exemple “local”, c’est à dire à Austin, Texas : La restauration !
Inutile d’investir dans les murs pour tester son concept, c’est à dire la proposition de valeur. Une simple caravane permet de vérifier l’intérêt de la clientèle et en prime de tester différentes parties de la ville pour appréhender celle qui corresponds le mieux au concept.
En gros, voilà à quoi cela ressemble :
Une fois le concept validé, on peut monter en gamme, donc investir dans les murs !
Hardware
La construction industrielle semble mal se prêter à ce concept. Pourtant il a été mis en oeuvre pour la construction de voitures. Comment ? Simplement en commençant avec un prototype, et en le faisant essayer. Et en itérant !
Unique Value Proposition
Un problème bien exprimé est un problème déjà à moitié résolu !
L’UVP doit se focaliser sur un problème et éviter les promesses marketing vides de sens qui ne sont pas assez spécifiques.
Au contraire, il faut favoriser ce que Ash Maurya appelle “the instant clarity headline”. Par exemple : Youtube = Flickr for video !
Le prix est une partie intégrante de la proposition de valeur. Il ne faut pas hésiter à se comparer à l’alternative, à l’instar de ce que Jack Trout préconise avec son Product Ladder.
Partie complémentaire de l’UVP, le canal de vente est une partie importante qui déterminera si le modèle est scalable
Itérer !
Enfin il ne faut pas se cantonner à un seul canvas, mais au contraire itérer sinon l’on risque de se trouver piégé dans un optimal local. L’UVP doit aller de pair avec le “unfair advantage”, la caractéristique qui ne peut pas facilement être copiée, à l’image du Delivering Happiness de Zappos. Attention, sans cet “unfair advantage”, la proposition de valeur est risquée.
Boire un petit coup c’est agréaaaable !
Première journée terminée. Beaucoup d’informations. Certes, on la retrouve dans le livre en bonne partie, mais Ash Maurya fait un bon boulot pour insister sur ce qui doit l’être et l’illustrer. La partie “workshop” est moins bien gérée : peu de périodes de pratiques, et alors trop longues et peu dirigées…
On se retrouve au bar pour conclure cette première étape.
Software Freethinker 
