Au coude à coude

Cycle en V : mais pourquoi ?

Ca vaut le coup d'aller lire mon précédent post sur le côté obscur du cycle en V en préambule.

La question qui reste, c'est pourquoi est-il toujours autant utilisé ?

D'accord, il y a quand même des cas où il est réellement nécessaire...

Si vous construisez un pont, vous êtes relativement assuré qu'on ne vous le demandera pas de le déplacer dans un an. En revanche on supportera mal qu'il se casse en deux, même dans 20 ans.
Non seulement vous n'aurez pas à être très ouvert au changement en cours de construction, mais en plus vous serez partis depuis longtemps quand les vrais problèmes se poseront.

Alors d'accord, on regarde tous les détails avant de commencer, on se met d'accord sur un process en béton armé, on documente un peu tout ce qu'on on peut, et on laisse un service qualité controler à fond toutes les étapes de réalisation.

Si vous travaillez à la NASA, à mettre au point depuis 2 ans un satellite qui embarquera en 2014 pour être mis en service en 2020 autour de Saturne. Vous n'avez pas le droit à l'erreur, genre pas du tout. Ce n'est alors pas choquant qu'un tiers du budget soit consacré à vérifier 3 fois le boulot de chacun. 
C'est bien pour ça que la NASA a grandement contribué à formaliser la méthode CMMI, rouleau compresseur de gestion de projet ultra-blindé que beaucoup d'entreprises s'escriment à mettre en place.

Bon, si vous ne travaillez ni chez Bouygues ni à la NASA, les raisons de la survie du cycle en V chez vous sont peut-être moins valables...

1. Le cycle en V rassure.

C'était en intro de la première session de l'Institut Agile : la survie de ces méthodes s'explique avant tout par l'impression de controle.

C'est vrai que sur le papier, c'est beau, c'est rassurant.
C'est beau de voir un planning ou un diagramme de Gantt. On change un chiffre et tout l'enchainemnet se met à jour.

C'est beau de voir défiler slide après slide ce qu'il se passera dans 6 mois, les inconnues sagement rangées, la marge de manoeuvre soigneusement calculée.

Merci Microsoft, c'est la magie de Project, Excel et PowerPoint : les outils liés au cycle en V donnent une grande impression de maitrise.

Les outils ne font peut-être pas tout : qui a déjà respecté un de ces jolis plannings ?

2. Au final, le produit sort.

... alors, de quoi se plaint-on ? 

La démocratie a ses défauts mais c'est finalement de loin le moins pire des systèmes. Pareil pour le cycle en V ? 

J'entends régulièrement dire que ce cycle en V, malgré tous ses défauts, a l'immense mérite d'endiguer l'anarchie et de faire en sorte que les projets finissent par aboutir. A coup de chair à canon façon Stalingrad, peut-être, mais aboutir quand même.

Une petite question : à quand faut-il remonter dans votre entreprise pour trouver une projet stratégique ayant couté une fortune ( des milliers de jours-hommes, dans les boites du CAC 40) et ayant été finalement abandonné pour limiter le désastre ? 

Sans doute pas 50 ans, toutes les boites ont eu le leur. Alors non, avec ce cycle en V, le produit ne sort pas forcément.

3. Personne n'est responsable dans un cycle en V

... et c'est carrément confortable.
Comme je le disais dans le dernier post, on fait plus confiance au processs qu'aux individus dans un cycle en V.
Donc quand un projet plante, on n'aura pas trop de mal à se dédouaner en prouvant qu'on a suivi le process. 

Et pour les quelques cas les plus chauds on pourra toujours dégainer le redoutable outil de consensus/auto-validation "ben quoi patron, t'étais en copie ! ".

4. Deux tonnes d'habitudes

Classique le poids de l'habitude mais on ne s'en lasse pas. On se fait à tout, même à avoir l'impression d'accoucher tous les mois, forceps à la clef. Les endorphines sont vraiment bien foutues...

5. Une louche de fatalisme 

"Les projets informatiques ont toujours fait mal. Si il y avait un remède miracle, ça se saurait !"
Et bien non, justement, pour toutes les raisons listées au-dessus, ça ne se sait pas...

Bon, OK, tout ça, ça se convainc, ça s'argumente, ça se retourne. Je termine maintenant par la raison la plus difficile à attaquer : 

6. Parce que ce sont les mieux placés pour changer de système qui ont le plus à y perdre.

et hop, ce sera pour un prochain post.

L’agilité, c’est quoi ?

 Finis les préliminaires ici et là, rentrons dans le vif du sujet.

L’agilité en une phrase, c’est faire « mieux, plus vite, et avec les mêmes personnes ».

Pour moi l’agilité, c’est simple comme cette petite histoire :

Il était une fois une petite équipe de développeurs.
Ils rencontrent leur client, qui leur raconte la vision qu’il a en tête.
Ils discutent de cette vision.
Ils discutent encore pour connaître ses toutes premières priorités.
Ils s’engagent sur un petit périmètre très concret de deux semaines de travail.
Ils le réalisent, dans la joie et la bonne humeur.
Ils montrent le résultat au client.
Ils le font parler pour comprendre la suite, et pour savoir ce en quoi sa vision a changé.
Et ils recommencent, une fois, deux fois, 10 fois.
Et le projet grossit, et la vision évolue. Ensemble.

Tout simplement.

« Pas de quoi en faire une formation... » me disent les équipes que je propose d'accompagner. 

Si, parce que finalement le plus clair de mes formations consiste à casser la carapace des pratiques classiques pour laisser respirer le bon sens.
Si, parce que le bon sens en management fait parfois un peu peur.
Si, parce que vous ne mesurez pas encore que chaque mot a son poids dans cette petite histoire.

 

agilité ? archétype du projet non agile

Agilité, Scrum, Xtreme programming... Ca fait deux ans que j'en entendais parler, et deux ans que je me disais que c'était vraiment un truc pour les geeks les plus furieux, pas trop fait pour moi.

Et puis j'ai vu la lumière. Le fameux bouquin Getting Real ( toujours lui) n'y est surement pas pour rien...

Pour faire court, il faut retenir que l'approche "agile" est faite pour palier les défauts de la gestion de projet informatique classique : dérapages en coûts et en délais quasi systématiques, et produit final souvent aussi figé qu'éloigné des besoins concrets des utilisateurs.

Avant de rentrer dans le détail ça vaut le coup de décrire l'approche classique de la conduite de projet informatique :

Acte 1 : le Chef de Projet
Un intermédiaire est baptisé Chef de Projet. Il n'est ni expert métier, ni expert informatique. Disons qu'il est interprète.

Acte 2 : les Spécifications
Ce chef de projet fait le tour des popotes dans la mesure de ses possibilités pour savoir qui est l'utilisateur final, et ce qu'il voudrait.
Il en tire un document souvent aussi épais qu'excitant qu'on appelle des Spécifications Fonctionnelles ( les majuscules comptent, comme dans Cahier des Charges).
Le Chef de Projet est brillant, il a tout prévu, il va donc de soi que ces Spécifications sont exhaustives et définitives.

Acte 3 : le tunnel
Il confie cette bible à des développeurs qui jurent sur leurs ancêtres qu'ils réaliseront ces commandements à la virgule prêt, et dans des délais bien entendus respectés 'puisqu'ils savent déjà ce qu'ils ont à faire' (sic).
3 mois plus tard, l'équipe se réunit pour un Comité de Pilotage.
Les développeurs regardent le capuchon de leur stylo en demandant un léger délai supplémentaire, la dernière petite ligne des Spécifications leur demandant malheureusement 15 jours de travail.

Acte 4 : Le dérapage
30% de dérapage plus tard, le chef de projet est donc livré d'un magnifique site ou logiciel. Il s'en estime heureux, la fois précédente, c'était 70% de dérapage...
Il profite quand même de l'occasion pour expliquer à ses développeurs en regardant à son tour le capuchon de son stylo que le besoin exprimé dans les Saintes Spécifications a "un peu" évolué.

Acte 5 : le conflit
Ce à quoi le développeur répond que cette petite évolution coutera en fait 1 mois de boulot de plus, qui n'était évidemment pas budgeté.
... et que ce n'est d'ailleurs pas la première fois que ça se produit.
... et que la prochaine fois ce serait bien que la demande soit ferme et définitive dès le départ.

Acte 5 : le dénouement
Si le projet est vital, les grognements finissent par cesser et les modifications sont faites à grands renforts de "vraiment c'est pas normal".
Si le projet n'est pas si vital, il est mis en production en l'état, c'est-à-dire utile à personne.

Mais pourquoi tout le monde fait comme ça ?

Disons que l'Enteprise s'est mis à gérer des projets informatiques dans les années 80 avec les méthodes qu'elle avait sous la main, c'est-à-dire celles qui servaient à construire des ponts.
...sans bien se rendre compte que la construction d'un pont est assez différente de celle d'un projet informatique :
- tout le monde est bien conscient que ce sera compliqué de le déplacer une fois construit, donc on se met vraiment d'accord avant.
- une fois qu'il sera fait, personne n'aura l'idée saugrenue de le transformer en hotel
- les pratiques séculaires du BTP font que, même comme ça, ça prendra du retard. Mais apparemment un mois de retard sur un pont qui servira 50 ans, ça fait partie du folklore et ce n'est pas si grave.

30 ans ont passé, il est temps de prendre conscience qu'un projet informatique est tout l'inverse :
- je vous promets que vous ne savez pas aujourd'hui ce que vous voudrez en faire demain
- votre site va servir au maximum un an en l'état. Un mois de dérapage dans ces conditions, c'est lourd.

Partant de ces constats, pas mal d'acteurs du milieu se sont mis d'accord petit à petit sur des pratiques un peu plus pragmatiques : les méthodes agiles.

Ca y est, vous êtes mûrs, on en reparle dans un prochain post :-)

300g de bon sens

300g de bon sens pour 18€. Le livre Getting Real, de 37 Signals, est sûrement l'investissement le plus rentable que puisse faire un entrepreneur, web ou pas.

37Signals, c'est l'équipe qui est derrière l'excellent framework Rails.
Getting Real, c'est leur retour d'expérience sur le lancement d'une série de produits web à succès : comment aller vite et bien, le plus simplement possible.

L'idée, le produit, le code, le design, l'équipe, la com', les clients, etc. Tout y passe, sous forme de bon sens massif, le plus souvent à contre-courant.

Chaque page m'explique calmement pourquoi j'ai planté mon premier projet... C'est un peu comme le Founder Institute -que vous devez commencer à connaitre- : ça ne prend que quelques heures, et ça vous fait gagner un an minimum.

Feuilletez-le ici ou achetez-le maitenant !

J'insiste : c'est valable pour tous les entrepreneurs. Quelle que soit l'entreprise que vous créez, "ignorez-le à vos risques et périls" et c'est l'autre incontournable Seth Godin qui vous le dit ! (j'attaque ses bouquins de ce pas, feedback à suivre...)

 

Je cherche un bon développeur agile

Tout tient dans le titre. Les détails sont ici.

La techno sera celle où il est le meilleur.
Idéalement un salarié intéressé au capital de la boite.
Pourquoi pas un associé si il partage les risques avec moi.
A défaut une agence à la tête bien faite, au moins pour commencer -et plus si affinités.

La loclisation géographique n'est pas un problème.

Le projet s'appelle Opportuner, c'est un Meetic professionnel.
Il est incubé au Founder Institute dont je parle souvent ici.

Contactez-moi : nicolas (at) opportuner (point) com

Statuts et faux problèmes

Dans la longue listes de problèmes sur lesquels les entrepreneurs perdent un temps précieux dès leurs premiers pas, il y a la tarte à la crème du statut juridique.

Pas besoin d'y passer un mois, la décision est vite vue :

1. Pour tester une idée/se lancer en restant salarié, devenez auto-entrepreneur.

2. Pour continuer :

• EURL si tu vous êtes tout seul
• SAS si vous voulez lever des fonds à court/moyen terme
• SARL sinon

Choisissez en fonction de ça et acceptez ensuite sans trop vous poser de questions les contraintes que ça implique ! elles sont listées sur le site de l'APCE.

Ne faites pas l'inverse en commençant par analyser les contraintes, ça vous embrouillera et vous verrez que vous finirez par choisir à partir des 3 lignes que j'ai écrites au-dessus.

Quelques infos à savoir :
- difficile/dangereux de créer sa première SAS sans avocat tellement le cadre est souple. C'est 1000 euros avec Juris Innovation.
- on peut être auto-entrepreneur et président de SAS
- on ne peut pas être auto-entrepreneur et gérant de SARL
- transformer une SARL en SAS, ça coute en gros 4000€. Pas si simple que la rumeur le dit.

Qu'en pensent ceux qui sont passés par là ? combien de temps avez-vous passé à choisir votre statut ? était-ce du temps utile ?

Trouver un développeur : la dure réalité

Que ce soit à travers les soirées SeedNetworking ou via tous les porteurs de projet que je croise, force est de constater la dure réalité : pas facile de trouver un "main developper" quand on lance un projet web. Qu'il soit associé ou non, d'ailleurs. 

J'écris cet article parce que je suis toujours étonné de voir quasiment tous les porteurs de projet tomber de l'escabeau devant la difficulté de cette recherche.

Concrètement, la plupart des porteurs de projet en début de parcours n'ont pas les moyens de payer un développeur pour faire le boulot. Ils lui offrent donc souvent une récompense "à terme" (des parts, un intéressement au résultat).
Etape 1 : pour comprendre le point de vue du développeur, commencez par remplacer "récompenses à terme" par "si jamais ça marche" et "dans longtemps".

Etape 2 : acceptez le fait que le nombre développeurs réceptifs par rapport aux porteurs de projet demandeurs est de 1 pour 10. Il faudra faire avec.

Il y a au moins 2 raisons  :

- "Moi aussi je porte un projet"
Un mois de travail suffit pour s'auto-proclamer "porteur de projet", c'est donc plus ou moins à la portée de n'importe qui.
En revanche il faut minimum 3 ans d'expérience pour être autonome sur un projet informatique. Ca s'improvise un peu moins.

- Le dilemne du développeur
La plupart des développeurs vont se mettre vite au chaud dans une grosse SSII/ DSI.
Une bonne partie de ceux qui restent deviennent freelances. Ce sont eux les lead developpers de rêve. N'oubliez pas cependant leurs contraintes :
. Leur statut signifie qu'ils doivent gagner leur vie, et qu'ils n'ont pas -contrairement aux porteurs de projet- 24 mois d'assedic devant eux pour "essayer".
. les meilleurs d'entre eux sont extrêmement courtisés, et payés cher (600€/j).

Ca ne laisse plus grand monde disponible pour nos entrepreneurs...

Manque de développeurs ou manque de bons projets ?

Les porteurs de projet parlent souvent très fort, on les entend donc beaucoup. "C'est vraiment dur de trouver un bon développeur". En fait c'est dur de trouver un développeur, tout court.

Les développeurs sont plus discrets et ça s'entend donc moins, mais ils sont tous d'accord pour dire que c'est extrêmement difficile de trouver un bon projet.

Les échos des développeurs et des business angels se rejoignent : il y a 1 bon projet sur 50, peut-être même sur 100. C'est à dire un projet suffisamment convaincant pour que le développeur accepte de mettre son salaire à 0 pendant quelques mois.

Et quelle technologie choisir ? ( update 23/04)

Drupal, c'est bien. Rails, c'est beau. Mais préparez-vous à vous battre encore plus pour trouver les compétences.
Là aussi la raison est simple : aucun développeur ne commence par ça. Il y a va parce qu'il maitrise déjà très bien un socle plus standard ( un CMS simple, PHP, etc). Ce sont les meilleurs, ils sont rares et ils le savent très bien. Ils ne partiront que sur un excellent projet.

Au-delà de la querelle de clochers, le boulevard c'est PHP.

Concrètement, comment faire ?

Solution 1 : Networkez, tout le temps, partout. Cf le tag networking ce ce blog.

Solution 2 : payez une agence/petite SSII/un freelance pour faire un prototype un peu sale, trouvez de l'argent sur la base de ce prototype, et embauchez un bon avec un vrai salaire.

Mais comment trouver un salarié ?

Solution 1 : networkez... :-)

Pas vraiment de solution 2.
Les bons développeurs qui aiment les petites structures ont tout simplement créé la leur, et sont freelances.
Les RH des groupes informatiques s'occupent quasiment de tous les autres, avec une puissance de feu contre laquelle vous ne pouvez rien.

Et SeedNetworking dans tout ça ?

SeedNetworking est là pour aider les entrepreneurs web early stage à démarrer : trouver des compétences pour monter un premier produit. Ce n'est qu'un coup de pouce dans votre recherche, mais il se trouve que c'est la seule initiative qui braque le projecteur sur ce problème. Nous arrivons à ramener le temps d'une soirée la proportion à 1 dév pour 2 projets, et même 1 pour 1 régulièrement.

On est loin du 1 pour 10 de la vraie vie, mais on est loin aussi de la garantie de résultats. Si c'était le cas, nous ne serions pas une association mais un cabinet de recrutement, et nous facturerions 10k€/tête la soirée :-) !

Nous estimons qu'une dizaine de boites se sont créées directement grâce à une rencontre lors de nos soirées, soit environ une boite par événement.
Nous savons que beaucoup de projets ont considérablement avancé grâce à nos soirées, suite à une mise en relation, un nouveau regard, une remarque en passant, etc.

Oui il y a (entre autres) des petites SSII, oui il y a (entre autres) des projets fumeux. Tant mieux, c'est aussi pour ça que ça marche.

Nous ne filtrons pas les projets :
- parce que tout projet early stage commence par être fumeux, et c'est dans nos soirées qu'il devient un projet solide.
- parce que même les porteurs moins avancés ont un carnet d'adresse, et qu'ils en font profiter les autres.

Nous ne filtrons pas les compétences :
- parce que même les petites SSII peuvent prendre des parts,
- parce que présenter son projet à une SSII permet de se rendre compte de ce que ça coutera si on doit le payer cash, et de ce que vaut le boulot de son futur associé.

Soyez lucide : il y a très peu de chances pour que vous trouviez l'âme soeur directement dans une de nos soirées. Mais beaucoup de chances en revanche que quelqu'un dans la salle connaisse votre âme soeur.
C'est pour ça que faisons du speed networking. A vous de trouver le chemin vers ce contact...

Bonne recherche !

Blue ocean & disruption

Un petite note dédiée au Blue Ocean, que plusieurs mentors du Founder Institute ont évoqué.

Quasiment personne ne le connait... et c'est mal :-).

Mon interprétation de la Blue Ocean Strategy ( par opposition au red ocean), c'est :
- de tout faire pour ne pas aller jouer sur un terrain où tout le monde est déjà en train de s'étriper
- si vraiment on ne peut pas faire autrement, n'y aller que si on a des armes qui ridiculisent les guerriers déjà en place.

Attention, ça ne veut donc pas dire aller nécessairement sur un marché où il n'y pas de concurrence, ça peut vouloir dire aller sur un terrain connu mais en réinventant radicalement les règles du jeu.

C'est une contrainte forte, mais pas du tout irréaliste.

Apple a créé son blue ocean en vendant des titres en ligne et à l'unité face à des majors qui s'accrochaient coute que coute à leur modèle d'album CD.
EasyJet a cassé les prix et facturé tout le superflu dans les services des avions.
Enterprise ( loueur de voiture) a compris que LE marché de la location de voiture, c'était celui de la location à la journée en remplacement d'un véhicule laissé au garage. Il a donc implanté toutes ses agences près des garages et pas dans les aéroports. C'est le plus gros loueur aujourd'hui.
Toyota a fait confiance aux neurones de ses ouvriers. C'est très simple, mais pendant 50 ans ils ont une qualité inégalée dans le secteur automobile, ce qui équivaut à des prix de revient impressionnants.
Wikipedia a eu l'intuition qu'une foule d'internautes pouvait être intelligente.
Etc...

Mais quel est le dénominateur commun de ces Blue Oceans ?

Les exemples ci-dessus le prouvent : il n'est pas nécessairement issu d'une innovation technologique ou même d'usage.

L'innovation aide, bien sûr, mais elle ne fait pas tout. Par exemple, à mon avis l'iphone n'est pas tant que ça un Blue Ocean, c'est simplement une innovation de rupture : Apple a pris une longueur d'avance, c'est certain, mais la concurrence était quand même dans les starting blocks.

Mon impression, c'est qu'on ne crée pas un Blue Ocean en faisant différemment. On le crée en pensant différemment.

Il y a un joli mot pour dire ça : disruptif.

Ca veut dire changer le cadre, l'angle de vue, la façon de poser le problème, changer le paradigme.

On ne pense pas différemment par hasard, ça se travaille. Ca implique de se retenir un peu avant de penser comme tout le monde. Ou plus précisément de remettre systématiquement en cause la façon dont tout le monde pense avant de se faire sa propre opinion

SeedNetworking 21 avril : 50 projets web cherchent développeurs

Plus de 50 projets sont inscrits pour le SeedNetworking de mercredi soir, c'est donc complet pour cette catégorie.

En revanche il reste encore un peu de places pour les développeurs. Faites passer le message !

Détails et inscription en ligne sur SeedNetworking.fr, PAF de 10€.

Road map : ça sert à quelque chose ?

A nouveau une très bonne session du Founder Institute Paris, sur le thème de la road map, disons "plan de développement" pour ceux à qui ça parle mieux.
Quand mon produit est-il prêt à être lancé ? Que contiendra mon produit demain ? quelle stratégie pour toucher de nouveaux clients ? conserver les anciens ? comment contrer mes concurrents ? dans quel pays lancer mon produit ? etc

Trois intervenants français à succès : une boite de jeux sur Facebook basée à New York, et une superbe solution de data mining basée à San Francisco, et le boss de LaCie.

Les témoignages de nos mentors n'étaient vraiment pas clairs sur le concept de "roadmap". A les écouter :
- la road map est indispensable, car elle donne à la fois la direction et le chemin
- mais il est déjà arrivé qu'elle leur coûte très cher, en temps et en argent
- et il faut savoir la changer tous les jours...

Je n'ai pas eu le temps d'approfondir plus avec eux sur ce paradoxe, et je ne trouve que maintenant les mots pour le dire : je n'aime pas vraiment ce concept de road map ! Ce sera l'objet de ce premier post.

Tout d'abord, il donne à mon avis une impression de sécurité et de maitrise des événements qui me semble complètement fausse.
Les entrepreneurs qui parlent de road map semblent se voir plutot comme des voyageurs qui prévoient un trip hardcore... en 4x4. Il y aura des imprévus ( panne, etc), mais dans l'ensemble ils pensent pouvoir s'y préparer, il pensent même les voir venir.
Poussons la métaphore un peu plus loin : ils sont relativement protégés de leur environnement, leur voiture leur donne une impression de sécurité énorme quand ils sont dans un mauvais pas. Au pire ils trouveront un mécano, d'où l'impression qu'avec de l'argent, ils se tireront de quasiment toutes les situations.

Je pense plutôt que l'entrepreneur voyage à pied, et que proportionnellement, il n'a généralement en poche que de quoi faire des sauts de puce en bus, disons s'acheter un vélo si il est vraiment riche.
Il est donc beaucoup plus vulnérable, face à la fatigue, aux maladies, aux reliefs, aux autres hommes, aux animaux, etc. Même si il peut fixer à l'avance des lignes directrices, il devra les faire évoluer quasiment tous les jours face à des événements dans l'ensemble imprévisibles (lancement d'un concurrent, rencontre de LA bonne personne, innovation technologique, etc)
C'est très vrai pour le bon entrepreneur, qui a des ambitions dépassant largement ses moyens.
C'est très vrai pour les entrepreneurs en lancement, mais pas uniquement. On a eu une belle illustration vécue du boss de LaCie : un an à peaufiner une roadmap, pour que le principal client visé dépose le bilan le lendemain du lancement du produit.

Second biais de la "road map" : une fois que c'est écrit, c'est plus difficile à remettre en question.
Les sociologues connaissent bien ce phénomène : une fois qu'une décision a été prise, qui plus est une fois qu'un peu d'argent a été dépensé, un décideur aura besoin d'arguments 10 fois plus lourds pour faire marche arrière. Exemple type : on voit bien que de gros doutes apparaissent, mais on a déjà dépensé 10 000 euros dans cette direction qui devrait nous en couté 100 000 en tout, on ne va pas gâcher ce qu'on a déjà dépensé... Sauf que souvent ça finit par couter 500 000€, toujours avec les mêmes doutes.

Regardez dans les grands groupes industriels : ce n'est quasiment jamais le pdg qui a initié un gouffre financier qui aura le courage de dire "on arrête les frais", même si tout le monde le pense. C'est son successeur.

C'est pareil pour la road map. Au mieux elle donne la direction et le trajet à l'instant T, mais il faut accepter humblement qu'elle soit a priori périmée dès l'instant T+1.

La solution telle que je la vois, surtout dans un projet web, c'est sans doute :
- d'avoir plusieurs road maps, c'est-à-dire avant tout un éventail de possibilités,
- de rester très léger sur ses appuis, c'est à dire de ne pas jouer à quitte ou double ( ceux qui vous disent le contraire font partie des rares qui ont joué ET gagné. Tous ceux qui ont perdu n'ont plus de voix pour le dire) 
- d'expérimenter en permanence, à moindre coût, peut-être même consacrer 10% du temps exclusivement à explorer de nouvelles voies.

Plus facile à dire qu'à faire quand on a peu d'argent, d'autant plus que la stratégie communément admise est de mettre le paquet sur un sujet.
Mais c'est ce que font les boites les plus résistantes à long terme ( ma boite favorite Semco excelle dans ce domaine).
En d'autres termes, poussez "à la main" dans toutes les directions, et avancez là où c'est le plus facile.
Pour info, Google n'a pas fait autrement. Gmail est un projet "bac à sable" qui a donné naissance de façon imprévisible à AdSense et au modèle économique de Google. Créer des bacs à sable, c'est ça leur road map.

Je finis par en conclure que la road map telle que tout le monde l'entend ressemble pas mal au business plan : c'est la phase de construction qui compte, pas le résultat ( que de toute façon vous ne réaliserez jamais). Pour faire une road map, vous allez vous poser des questions, nécessairement LES bonnes questions, et c'est ça qui compte.

Petite parenthèse en passant : "oui mais si il n'y a pas de direction claire on ne saura pas motiver nos équipes". C'est faux, la meilleure motivation d'une équipe, c'est de partager une vision, pas un objectif de parts de marchés ou le lancement d'une fonctionnalité.

Malgré ce paradoxe un peu flou sur la road map, nos mentors nous ont abreuvés de très bons conseils sur le développement d'une boite, du stratégique à l'opérationnel. Next post...