Belle performance que ce TiddlyWiki : il fonctionne avec un seul fichier html qui embarque tout le javascript nécessaire pour fonctionner, éditer, sauvegarder, visualiser.

A découvrir sur le site de TiddlyWiki

Business traditionnel

Plan à 3 ans (voire plus …), business plan de (beaucoup trop de) pages, super-équipe de techniciens, marketeurs, administratifs (etc.), et de conseils extérieurs, entraînant un impressionnant burn rate (rythme de consommation des capitaux apportés par les investisseurs), le moment venu super-conférence de presse avec le hype (exagération) de rigueur, voici enfin le lancement officiel du produit (ou service).

Beaucoup de temps (pendant ce temps, des concurrents s’agitent, la demande du marché a évolué, de nouvelles solutions techniques sont apparues)

Beaucoup d’argent

Beaucoup de risque : on n’a toujours pas, à ce stade, de jugement réaliste sur les usages, les utilisateurs, le marché, etc.

De nombreuses start-up, encore aujourd’hui, fonctionnent de cette façon. Le découpage de l’arrivée des capitaux en “tranches conditionnelles” ne change rien au fond de l’affaire : on pilote une jeune pousse comme si c’était un pétrolier géant, alors qu’il faudrait la manier comme un dériveur en régate.

Projet moderne

En reprenant la méthode appliquée par l’ouvre-boîte :

– Environnement créatif de concurrence / génération d’idées ==> maturation rapide
– Des maquetteurs se saisissent d’une idée ==> maquettage rapide (et peu coûteux)
– Maquettes d’usages : Observer “en vrai” usages, utilisateurs. Dialoguer avec utilisateurs et commentateurs (la maquette est d’origine pourvue des outils de dialogue comme ceux des blogs) sur usages, fonctionnalités …, susciter et accueillir suggestions commerciales, marketing, RP, techniques. Observer les réactions sur le Web, et réagir (la maquette est d’origine pourvue de RSS et trackback comme ceux des blogs, ou elle est bâtie autour d’un blog).

Parmi les utilisateurs ou commentateurs (locaux ou repérés sur le Net) se trouvent de futurs partenaires pour l’écosystème [*] du projet. A noter que l’écosystème peut croître dès le lancement de la maquette si elle est pourvue de RSS, API … et accélérer encore l’utilité de la maquette. Parmi ces utilisateurs ou commentateurs, se trouvent aussi de futurs collaborateurs, distributeurs, financiers …

Toute “bonne” maquette est dès l’origine dotée de RSS et d’API.

[*] Ecosystème : thème abordé à de nombreuses reprises sur ce blog ou sur l’ouvre-boîte (par ex. ici). En bref : un produit ou service bénéficie de l’existence d’autres produits ou services. Les services utilisant le Net peuvent de plus collaborer entre eux (RSS, API, etc.) pour produire plus de valeur et une meilleure existence. En ce qui concerne une maquette, la multiplication et croissance de services “liés”, dès la naissance de la maquette, fournit aux initiateurs du projet, et à des investisseurs, une excellente indication de potentiels (d’usages, techniques, commerciaux, financiers) et de la “valeur du projet.

Il est très important de noter qu’une maquette n’a pas besoin d’être parfaite. Par exemple, elle ne présente pas (pas toujours) toutes les fonctionnalités qui seraient jugées intéressantes. Les seuls juges des fonctionnalités, ce sont les utilisateurs. Il vaut mieux présenter moins de fonctionnalités que plus, parce que plus de fonctionnalités :

– c’est plus lent et coûteux à mettre en place
– plus il y a de fonctionnalités, plus il y a de bugs, à court et à long terme
– plus il y a de fonctionnalités, plus le design est difficile
– plus il y en a, plus l’utilisateur s’y perd (bad user experience, dommageable pour le projet) … et moins il en utilise (cf. l’usage réel des traitements de texte)
– il est beaucoup plus facile pour un utilisateur de réclamer une fonctionnalité (la maquette est d’ailleurs là pour écouter ses suggestions) que de proposer sa suppression (et on peut difficilement compter sur l’équipe maquette pour supprimer une fonctionnalité dont elle est si fière)

La “mécanique” derrière la maquette n’a pas non plus besoin d’être parfaite à la date de lancement de la maquette. Par exemple, pas besoin d’algorithmes ultraperformants. Tant mieux s’ils sont là. L’optimisation (ou le remplacement par une mécanique flambant neuve) viendra ensuite. Et les signaux pour indiquer la nécessité d’améliorer ou changer la mécanique sont déclenchés par l’usage de la maquette. Par exemple, par une montée continue et rapide du nombre d’utilisateurs. Tout ce qu’on demande à une maquette, c’est de “marcher”.

Idéation rapide, Maquette rapide, Synthèse rapide : En peu de temps, en ayant peu dépensé, on a tous les éléments de décision pour “la suite” :

– Usages et marchés
– Concurrence
– Fonctionnalités : lesquelles améliorer, créer. Avec, éventuellement, quels outils ou services proposés par les utilisateurs et commentateurs
– Partenaires de l’écosystème, distributeurs, …
– Etc.

Un projet ayant démontré :
– sa capacité à produire “beaucoup” avec des ressources limitées
– sa validité “en vrai”
– son potentiel d’usages, de marchés, de partenariat
– sa réactivité
… a une valeur intrinsèque importante. Les initiateurs du projet sont en bonne position pour inspirer confiance à des investisseurs, et négocier la valorisation du projet.

Open Business ?

En somme, tout ceci une application aux processus d’innovation et de business de l’adage release early, release often, titre d’un chapitre de The Cathedral and the Bazaar (Eric S. Raymond, technicien, écrivain, prophète et … parfois provocateur). Dans ce chapitre d’un ouvrage synthétisant une “anatomie du développement d’un logiciel”, l’auteur écrivait d’ailleurs aussi : Release early. Release often. And listen to your customers.

Eric S. Raymond défend ardemment les avantages du Open Source, notamment l’incroyable efficacité des boucles cybernétiques (rétroactions) entre développeurs, entre développeurs et utilisateurs, entre utilisateurs. Un business moderne, à ses débuts comme ensuite, devrait sans arrêt installer, entretenir, favoriser toutes sortes de rétroactions. Et les analyser.

Le côté “Open” du business moderne, où pourrait on le trouver ? Dans le processus collectif d’idéation à l’origine d’une maquette. Dans l’ouverture d’esprit et le dialogue public permanent avec les utilisateurs et tous partenaires. Dans la création et le développement de l’écosystème du projet. Dans l’ouverture des usages : foisonnement combinatoire. Dans les processus de matching entre personnes, projets, investisseurs, fournisseurs et autres partenaires. Open Business ?

Le côté Open, on le trouve encore dans les implications stratégiques d’une démarche de projet en environnement ouvert (écosystème). La combinaison de valeurs des services permet un effet long tail : couvrir les besoins personnalisés de la plus petite niche de marché, sans que cela augmente le dimensionnement de la logistique générale.

Nota : cet article aura une suite, traitant des financements rapides pour des projets rapides

Cela ferait-il un slogan pertinent et enthousiasmant, ou bien son côté provocateur pourrait il provoquer des rejets ?source